When trying to use classes of the org.apache.commons.collections4 jar in my web application deployed on TomEE 1.6.0.2 (Tomcat 7.0.53) I get a ClassNotFoundException.
I stripped down the web application to just one simple HttpServlet doing nothing else but calling a method on CollectionUtils. In the pom.xml there's nothing else but the dependency to org.apache.commons.collections4. When deployed, the jar is in WEB-INF/lib. But the exception is still being thrown.
When using the classes from apache commons collections 3.2.1, everything is fine.
Any tips and hints that help to find the problem's origin are much appreciated!
Thanks,
Felix
I had to add openejb.classloader.forced-load=org.apache.commons.collections4 in conf/system.properties
Related
I'm using tomcat for running my webapplication. I'm trying to integrate keycloak through spring security adapter.
Any suggestions will be appreciated...
Use only spring-security-adapter dependency in pom.xml.Add tomcat adapter jars inside lib folder of tomcat.Because of adding two dependencies inside pom conflict araising while loading the classes
I'm using IntelliJ to build a standard java web application on top of Tomcat and Spring. I'm fairly new to IntellJ and feel like I'm missing something setup wise because I cannot seem to resolve resource files from the classpath.
Relevant Info -
IJ 2017.1.4
Tomcat 8.5.15
Java 8
Spring platform-bom:2.0.8.RELEASE
I should also mention I'm using a java only configuration, taking advantage of the Spring's annotations and the servlet 3.0+ spec.
Since I'm pretty sure this is an issue with my IJ configuration, here's a series of screenshots outlining my setup & the error. Appreciate any help on this one, it's had me stumped for a bit.
Modules
Facets
Artifacts
Project src
Exploded War ouptut
Code where I'm attempting to load in a file on the classpath
Error
I am trying to create a maven spring boot application to be deployed in Tomcat. I am following what is suggested in Spring docs and other stackoverflow suggestions- war, Application.java extending SpringBootServletInitializer, removing spring-boot-maven-plugin from build plugins etc. War file is generated and is deployed in tomcat. But what I found is all static files are packaged under /WEB-INF/classes folder and I am not able to access the page. My project structure is as below:
Can anybody tell me how I can package the war properly to be deployed in Tomcat.
That doesn't change anything.
If you put your static assets in src/main/resources/static (and they end up in WEB-INF/classes/static), Spring Boot will serve them properly. So a src/main/resources/static/foo.png will be available at http://localhost:8080/your-context/foo.png if the context of your webapp is your-context.
Regarding the configuration, you can also go on start.spring.io, click advanced and chose war and you'll get an empty project pre-configured.
Or you can click this: https://start.spring.io/#!packaging=war
The issue is because of version issue. I compiled the application with Java 8 and deployed it in tomcat running under JRE 7. It may help someone facing the same issue.
I got the clue from the below post:
Spring boot war file deploy on Tomcat.
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.
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.