This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
How do you have the dependency declared in your POM?
The second error seems to indicate that you may have a different version of the library loaded first from different location - see the JBoss ClassLoader HowTo for a description of all the places a class may be loaded from.
Is there anything indicating a similar problem in the first exception, such as the class can't be loaded because there are multiple versions? Or it just can't locate the class?
Write once, run anywhere, because there's nowhere to hide! - /. A.C.
Joined: Feb 02, 2009
I noticed that I do have apache commons dependencies, which themselves might rely on their commons logging, I don't know if that is causing any issue; I looked up on slf4j page, it asks me to put an "slf-nop.jar' and only ONE slf4j-noop.jar (or any one from slf4j api); I am using above dependency declaration ... That should have taken care of it already, but it hasn't
I am a little lost on this one, as jars are clearly present (eclipse project shows jars), and in any case I do:
to generate war file ... that should package everything correct? I don't know what's up
It should work - but there are some things that can mess it up.
If the project changed names of their groupId or artifactId in maven, you could have a dependency using an old transient dependency somewhere - maven will think this is a completely different dependency, but if classes and packages are named the same, there will be collisions when the classloader tries to load it.
Usually you don't see this in maven-ized dependencies, but if you may have system dependencies declared... There are some cases where someone did something stupid like unpacked another jar into their project and then packaged up their project + dependencies into a jar. I've seen this problem in one old version of Sun's J2EE.jar where they had packaged the classes of an apache xml parser in with their code. My project had dependencies on the j2ee.jar (system dependency) and a newer version of the apache xml parser as a regular dependency - and suddenly classloader problems.
It could also be something on the system classpath or in a global library directory of the app servers.
To troubleshoot this - you can try to use the -verbose option with the java command launching your app server - this will show where each class is actually loaded from. You'll need to redirect output to a log file too - so much output will be printed, you'll have to open it later as a text file and search for the specific classes you're interested in.