I am running my application on mule server. Mule server has there own sets of jars and my application that is running on mule server also has few jars. While working on Spring batch I found that JettisonMappedXmlDriver class exists in my application xstream jar as well as mule server jar as well. This class internally refer MappedXMLOutputFactory class that is in jettision jar which is also in my application but some how I am getting classnotfound error for MappedXMLOutputFactory class. This looks like class-loader issue.
If I add jettision jar in mule server then everything work fine but, I can't add this jar on my production environment. Can some body tell me how do I force to load the class from my application jettision jar file. It looks weird to me as classloader should have load MappedXMLOutputFactory class from jettision jar that is in my application folder like it is doing for other classes.
Please let me know if anybody found such issue.
The Mule application classloader is configurable: http://www.mulesoft.org/documentation/display/current/Classloader+Control+in+Mule
So just configure your application's classloader to first look at the JARs it embeds in /lib before deferring to the Mule System classloader.
You will encounter this issue if you have multiple versions of the same class in differnet jars, albeit with different method signatures. The ClassNotFound Error is usually not the only exception that occurs, you will often see another one before that, typically a "NoSuchMethodException" which forces class loader to unload the offending class.
I would suggest using maven or gradle to assemble your application and then use the dependency:tree target to query version conflicts.
Related
I am running a spring application.
My requirement is user will be placing a plugin jar file at run time at designated lib folder location.
This plugin jar file will have spring application context file as well. I want to load this jar, means all the classes - spring beans
and all its dependent beans/components(this is important), from this jar file at run time.
I do not want to create new/child application context and want to use the existing spring bean context loaded at application start up.
I reffered to few other similar threads/questions on SO and could resolve the issue of dynamically loading of spring beans.
But i am not able to resolve issue of loading all the dependent beans for the spring beans.
Could you please provide any pointers/hints to dynamically load all the dependent beans of spring bean(which is also)loaded at run time?
Thanks in advance,
Picku
If you want to be able to load the plugin after startup you are not going to get away with not creating another application context as a child.
I'd suggest you do exactly this and then create some hooks in parent context whereby your plugin will integrate itself.
The alternative is to include that plugin.jar in the main classpath and then restart the application to include the plugin.
I've an EAR with an EJB and WAR project in it. I use Netbeans and the Maven building tool. In my EJB there is one EJB, a singleton class: http://pastebin.com/f8jXw0TK
Here is a screenshot of my project structure in Netbeans: https://gyazo.com/09e075972279f637de2d4d98fe9a1ac7
When I deploy the EAR or the EJB-JAR in Glassfish (localhost). I get the follow error message:
Error occurred during deployment: Exception while deploying the app [arp-auth-business-1.0] : Invalid ejb jar [arp-auth-business-1.0]: it contains zero ejb. Note: 1. A valid ejb jar requires at least one session, entity (1.x/2.x style), or message-driven bean. 2. EJB3+ entity beans (#Entity) are POJOs and please package them as library jar. 3. If the jar file contains valid EJBs which are annotated with EJB component level annotations (#Stateless, #Stateful, #MessageDriven, #Singleton), please check server.log to see whether the annotations were processed properly.. Please see server.log for more details.
I've added a simple stateless bean to the EJB JAR, and then it deployed. But then I saw just the simple stateless bean I created, but not my singleton class.
What could be wrong? The server.log shows the same error I get in Glassfish but with a exception stack from the loader. No error from the singleton class or something like that...
Still trying but can't figure it out. Maybe it's maven? But the jar and war file are in the ear file. And in the jar file there is my singleton class.
Kind regards
I am trying to use to versions of spring in the same application: the first one is a webapp with spring 2.6 and the second it a jar client, with spring 4.0.2. The client communicates with another application and will be a dependency for the webapp. The problem is that the classloader will just load one time the common classes from spring and it will certainly fail.
I tried to use ElasticSearch aproach of using shaded dependencies(maven shade plugin) and relocate spring from the client to a different package (from org.springframework to my.springframework) and the uber jar seems to be constructed fine.
The issue is that Spring is based on spring.schemas and spring.handlers for validating xml config files and loads this files from classpath (META-INF folder and this paths are hardcoded in Spring code - e.q. PluggableSchemaResolver). I modified this files to point from org.srpingframework to my.springframework.
At runtime it seems that the classloader reads these files from the webapp, which has this files but with the real spring path and the exception is something like
org.realsearch.springframework.beans.FatalBeanException: Class [org.springframework.context.config.ContextNamespaceHandler] for namespace [http://www.springframework.org/schema/context] does not implement the [my.springframework.beans.factory.xml.NamespaceHandler] interface.
To me it seems that is impossible to achieve what I am trying (use tho spring versions in the same application with one of them relocated). Any ideas here? Am I wright?:d
I have a webapp running JAX-RS web services using the Jersey implementation. The target app server is a WebLogic 12c whose default JAXRS implementation is Jersey v1.9.
1) when run on Jetty (6.1.26) with jersey-server-1.9 dependency, everything is fine.
2) when run on WebLogic 12c with jersey-core.jar + jersey-server.jar (v1.9) jars both embedded in the WEB-INF/lib of my war, it is also working.
2) when run on WebLogic 12c with the same war amputed from these 2 jars (assuming there are not needed as already provided by the weblogic Java EE stack), it does NOT work anymore. I got the following error:
"weblogic.application.ModuleException: [HTTP:101216]Servlet: "jersey-servlet" failed to preload on startup in Web application: "cachede-newgen.war".
com.sun.jersey.api.container.ContainerException: The ResourceConfig instance does not contain any root resource classes.
at com.sun.jersey.server.impl.application.RootResourceUriRules.(RootResourceUriRules.java:99)"
Needless to say the Jersey version is exactly identical in all three cases:
"Apr 24, 2013 4:10:24 PM com.sun.jersey.server.impl.application.WebApplicationImpl _initiate
INFO: Initiating Jersey application, version 'Jersey: 1.9 09/02/2011 11:17 AM'"
It sounds again (sight!) like a classpath or classloader issue :-(
Any idea or workaround to solve this issue (taking accound that I do NOT want to repeat jersey jars in every deployed war) ?
Ok I found the reason :-) - and "better_use_mkstemp" put me on the right direction (many thx!).
The solution consists in adding a reference to the deployed Jersey version in the weblogic descriptor file:
<library-ref>
<library-name>jersey-bundle</library-name>
<specification-version>1.1.1</specification-version>
<implementation-version>1.1.5.1</implementation-version>
</library-ref>
The strange thing is that, without such ref, the error message (ie "The ResourceConfig instance does not contain any root resource classes") gives the feeling that Jersey is able to start and scan your annotated classes...
NB: Actually, you also need a reference to the JSR-311 api, as explained here:
http://theblasfrompas.blogspot.be/2011/03/time-to-deploy-restful-web-service-from.html
Have you "deployed" the jersey jar to your server? In the admin console go to Deployables (click Customize the table and uncheck exclude libraries). See if Jersey is listed there. If not, you will need to "deploy" it and target whatever servers you need it on. Then try to redeploy your war file.
Jersey should live in:
wlserver_10.3/common/deployable-libraries
Those shared libraries aren't automatically available to your server until they are targetted to it.
Just remove all Jersey jars and add one Jersey Bundle jar it will work. I have faced the same Issue and resolved after adding Jersey Bundle jar into to class path.
I would like to try out Spring Source's "Spring Loaded" class reloading agent, with Tomcat run via IntelliJ.
https://github.com/SpringSource/spring-loaded
I've added the JVM arguments to my Tomcat run configuration, and my webapp starts up without errors and seems to behave normally.
I'm not really sure how to trigger the class reloading though. Do I just need to compile the classes that I modify? I've tried that and that didn't seem to work. Do I need to update Tomcat and deploy classes and resources? That doesn't seem to work either...?
Any specific configuration details would be greatly appreciated.
EDIT: More info, I think my problem may have to do with using two modules, one a core code library, and one the webapp. I use Maven for both, one configured as a jar project and the other as a war project. IntelliJ sets up the Artifact for the exploded war to use the jar module's jar file. I've tried switching the Artifact config to incorporate the jar module's compiled output into WEB-INF/classes instead. Now I see the .class files in target/webapp/WEB-INF/class/etc. But I'm not sure how to get IntelliJ to update a specific class file when I edit it.
If you added the following jvm parameters (as described at the springloaded page) to your tomcat
-javaagent:<pathTo>/springloaded-{VERSION}.jar -noverify SomeJavaClass
you should be fine. It may help to disable auto reloading in tomcat for the webapp you are testing. For exmaple in your server.xml:
<Host appBase="webapps" autoDeploy="true" name="localhost" unpackWARs="true">
<Context docBase="projekt" path="/projekt" reloadable="false" ...
This ensures that only the springloaded classloader loads changed classes.
spring loaded cannot hotswap jars.
Put web fragment output into webapp/WEB-INF/classes
Also spring loaded support only spring 4.1
https://github.com/spring-projects/spring-loaded/issues/139