We have attempted to package and deploy GridGain 6 as a custom static module within our JBoss 7.1.1-Final application server. When run locally, the configuration appears to work and grid jobs are executed by the local node, but when a job is executed on a remote node we get a ClassNotFoundException which appears to indicate that the module code cannot find a class that is contained within the EAR file that is deployed in that instance of JBoss.
Caused by: java.lang.ClassNotFoundException: com.our.company.CustomGridJob from [Module "com.gridgain:main" from local module loader #5e48a0e1 (roots: /path/to/jboss/modules)]
From initial debugging it looks like the GridGain module is attempting to un-marshal the serialized message it receives from the network and is looking for the class to construct to initiate the job that it was sent. When the same job is executed locally we assume the serialization/un-marshalling part doesn't happen as there is no network to traverse, so local execution works.
The class it is looking for is present in the EAR deployed to the server so it would appear to be a classloading visibility issue. Is it possible to make modules 'aware' of code that is deployed to the container? If so, how?
If this approach of deploying GridGain isn't possible are there any other alternatives to simply packing GridGain with our EAR deployment in the /lib directory of the EAR? (Which would really bloat the deployment). How have others deployed GridGain 6 in JBoss 7?
Any advice appreciated.
Thanks.
According to JBoss classloading documentation, every module can declare dependencies on other modules. I am not sure if static module can declare a dependency on dynamic module (if yes, problem is solved). If not, then you can deploy GridGain as a separate dynamic module, and declare a dependency from GridGain module to your EAR module. The EAR module would have to declare a dependency on the GridGain module (I believe that circular dependencies are supported).
This way all classes declared in the EAR module should be visible to the GridGain module.
Let me know if this works for you.
Related
I have a mule application where I have added the external jar files as dependencies and invoking java classes. Now I am working on a different application where I need to use the same external jar files as dependency.
Is there a way I could reuse the first application(with java code) in the second one without added the external jars again as dependencies?
Thanks in advance
You should not add the Mule application as a dependency if you only need to use the Jar files for the Java libraries. Just add the dependencies for the Java libraries to the second application.
If you want to reuse the dependency in an onprem Mule deployment you can add it to a common Mule domain.
I' starting to use ServiceMix and Camel and I've run through many examples.
It seems that the examples that are OSGi can be deployed in ServiceMix via hot deploy or via console, but I don't know how to deploy a project that is not an OSGI. Can it be done?
For example, I'm looking at the example project from Camel 2.10.0 called camel-example-cxf-proxy. I did some alterations and now I wanted to load it in ServiceMix. If I copy/paste to the deploy directory it is loaded but when I try to run it via osgi:start id it fails.
However if I run it from the IDE as a standalone it runs just fine and I can send and receive requests via SoapUI.
When I'm done with the examples I'll want to create my own project in eclipse and do tests in the IDE and in ServiceMix. I don't really understand the advantage of OSGi yet. SO I'm not too compelled to use OSGi for my project.
My main question is: Can I deploy a non-OSGi non-JBI compliant project in servicemix? Something like the camel-example-cxf-proxy. If yes, how can I do it? If no, how can I OSGi-fy the camel-example-cxf-proxy?
Thank you :)
Apache ServiceMix which uses Apache Karaf as its kernel, support pluggable deployment units. Though OSGi is the main unit.
You can deploy JBI artifacts (eg JBI was used as deployment units for Apache ServiceMix 3.x). So we offer that as a migration path to run JBI in SMX 4.x.
A plain WAR file can be deployed as well. You can for example just drop a .war file in the deploy directory. If you deploy from the shell, you need to prefix the deployer with war so it knows to use the war deployer.
There is some documentation about the various pluggable deployers here
http://fusesource.com/docs/esbent/7.0/esb_deploy_osgi/UrlHandlers.html
For example to install an Apache Wicket WAR example using Maven you can do from the shell:
osgi:install war:mvn:org.apache.wicket/wicket-examples/1.4.7/war?Web-ContextPath=wicket
The Apache documentation about deployer is mainly documented at Apache Karaf
http://karaf.apache.org/manual/2.2.9/users-guide/deployer.html
Now to deploy OSGi applications can be a bit of pain to assemble. And that is why FuseSource created FAB to make it much easier. I blogged about this a bit, which references to videos and more material: http://www.davsclaus.com/2012/08/osgi-deployment-made-easy-with-fab.html
With FAB you can just deploy regular Maven projects out of the box without any OSGi pain.
If your project is a maven project, you can try :
mvn install
Then start your servicemix, and in servicemix command line :
install mvn:groupId/artifactId/version
This will prompt a bundle ID. Then, juste start the bundle :
start <bundle_id>
You can check the state of your bundle with command "list"
The project has to be a bundle to be installed in servicemix / karaf. So the steps to make a camel project work in OSGi are the following.
Use the maven bundle plugin in the pom and configure it to import / export the necessary packages if necessary.
Make sure your camel context is defined in a way that OSGi can start. This is either in the activator of the bundle or in a spring config in the right location or with a blueprint config in the right location.
See two of my karaf tutorials for the details:
CXF: http://www.liquid-reality.de/x/EoBk
Camel: http://www.liquid-reality.de/x/G4Bk
In a project I have put together, I need set up some JMS queues in order to run my integration tests.
Where is best to store my scripts to set the environment up?
I have a parent project, and typical modules like EAR and WAR modules.
More than likely your JMS queues are defined in the application's EAR file. If so, the EAR module would be the best place to store the creation scripts for testing. Now exactly where to store them in the module (or project if you so choose) is really up to you. But the folks over at Apache Maven do give some guidelines for standard directory layout here.
According to that page and the fact that this is for testing, the best place should be src/test/resources.
I haven't found a Maven plugin or target that will package my app and deploy it to Glassfish without error. I get this exception:
[ERROR] com.sun.enterprise.admin.cli.CommandException: remote failure: Exception while preparing the app : java.lang.RuntimeException: Could not resolve a persistence unit corresponding to the persistence-unit-ref-name [org.us.impl.MyClass/entityManagerFactory] in scope of the module called [man-java-really-stinks-app]. Please verify your application.
This isn't a Spring/Hibernate/EntityManagerFactory/Jpa problem. The app runs fine in the embedded Maven Glassfish container.
I changed packaging to ear in my pom.xml and got this when I deployed to Glassfish
Error during deployment : org.xml.sax.SAXParseException: The content of element type "application" is incomplete, it must match "(icon?,display-name,description?,module+,security-role*)".
IS there a plugin that will take care of the J2EE packaging requirements?
Bonus question: Since the Entities (just POJOS!) and the application need to be packaged differently, is it best to separate these into Maven sub-projects?
I haven't found a Maven plugin or target that will package my app and deploy it to Glassfish without error.
For the packaging, there is everything you need: the maven-jar-plugin for JARs (including JARs packaging JPA entities), the maven-war-plugin for WARs, the maven-ejb-plugin for EJB-JARs, the maven-ear-plugin for EARs, the maven-rar-plugin for resource adapters.
This isn't a Spring/Hibernate/EntityManagerFactory/Jpa problem. The app runs fine in the embedded Maven Glassfish container.
Well, I'm still tempted to say that there is a JPA configuration problem somewhere anyway, the container is clearly failing at finding a (default?) persistence unit. But since I have no idea of the kind of app you're running (I guess it's a webapp but would like to get confirmation), what your persistence.xml looks like, how you inject the EntityManager, how you configured the database access, how you configured Spring, the version of GlassFish you're running, etc, etc, it will be hard to say anything more.
I changed packaging to ear in my pom.xml and got this when I deployed to Glassfish
That's not that easy. Building an EAR typically involves a multi-modules build, and you are expected to provide a special deployment descriptor. But I'm not convinced you need an EAR packaging and if you can avoid it, don't use it.
IS there a plugin that will take care of the J2EE packaging requirements?
As I said, there are plugins for everything you need, from J2EE to Java EE 6. Just provide the details requested above.
Bonus question: Since the Entities (just POJOS!) and the application need to be packaged differently, is it best to separate these into Maven sub-projects?
Entities and the application do NOT (always) need to be packaged differently, you can package entities directly inside a WAR (I'm extrapolating but I suspect this is your case). I just think you have a configuration problem somewhere, even if the application is running in GF Embedded.
By the way, almost Everything is POJO in Java EE (Entities, Session Beans, Message Driven Beans, etc), but there is no direct consequence on packaging, packaging and POJOness are unrelated.
org.us.impl.MyClass had a #PersistenceUnit annotation. The persistince is managed by Spring, but Glassfish takes a sweep of the annotation classes and tries to resolve it itself. You can tell Glassfish to knock it off by adding
metadata-complete="true"
to your web.xml, like so
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
metadata-complete="true">
Further reading: https://glassfish.dev.java.net/issues/show_bug.cgi?id=4204
My shop has been running Oracle's Application Server for several years. As such, before we knew better, we have developed a norm of having application config files stored outside of the WAR file and the app-specific config directory is added to each application using an Oracle-specific deployment descriptor. This deployment descriptor allows us to add classpath elements at the application layer rather than having to include all dependencies in the WAR.
Now we are faced with upgrading to WebLogic 10.3 and I need to find an alternative for our applications that depend on external configs.
Is there a way in WebLogic to add external jars or directories to the classloader at the application level? I've found ways to add them to the system classloader, but I'd prefer to add them to the application level to avoid having to re-work the applications beyond modifying deployment descriptors.
Is such a thing possible in WebLogic 10?
After further research, we've learned about WebLogic's Generic File Loading Overrides feature.
This feature allows us to use a Deployment Plan for our application and specify a "config-root" for the application. Within the config-root, we can create a directory called "AppFileOverrides" and override any file in the WEB-INF/classes or WEB-INF/lib directories.
This feature works by injecting a classloader just in front of the Web Application classloader, thus any resource loaded from the classpath will be found in this classloader before anything bundled into the web application archive.
Using this feature, we are able to add configuration files (and in theory, classes) that don't exist in the war file at all. Thus, we are able to mimic the functionality of keeping configuration files outside the war.
Moving forward, I'm encouraging our developers to include the configurations inside the war file, but this will work nicely for legacy apps and for situations where we need to change the configuration for a given deployment target (dev vs production)
External jars can be referenced by deployments using the shared libraries.
Roughly, the external jars should be 'deployed' as libraries. Then they can be referenced from your app's weblogic-application.xml using library-ref descriptors.
refer to this doc.
Though, I dont think you can provide external directories/config files other than by using system classpath.
To my knowledge, this is not possible with Weblogic. External configuration files need indeed to be added to the system classpath. You can tweak a bit the classloader (see filtering and loading order) but there is nothing allowing to add dependencies at the "application level" a la OAS. For this, you'll have to run separated domains if the scenario mentioned above is not an option.