We Keep Coding

XML Parser Class loading issues in Karaf

I have an OSGi bundle that does some LDAP operations. It uses Apache Shared Directory to do these operations. I'm using Maven Bundle Plugin to build my bundle. For lack of time and resources, I have to go with in pom.xml, which includes Apache Shared Directory and other jars it depends on, in the generated bundle. One of the dependencies is Xerces, followed by Xml apis. When I include these two jars in the bundle, Karaf throws a ClassCastException:
java.lang.ClassCastException: org.apache.xerces.jaxp.DocumentBuilderFactoryImpl cannot be cast to javax.xml.parsers.DocumentBuilderFactory
Further investigation revealed that the class javax.xml.parsers.DocumentBuilderFactory is being loaded from two jars - Xml-apis.jar that I included in my bundle and the JRE's rt.jar, which is causing the ClassCastException. Since this class is being loaded from rt.jar, I figured I don't need to include Xml-apis.jar in my bundle and removed it. However, now I see the ClassNotFoundException:
Caused by: java.lang.ClassNotFoundException: javax.xml.parsers.DocumentBuilderFactory not found by mybundle.ldap [149]
at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:812)[org.apache.felix.framework-3.2.2.jar:]
at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:72)[org.apache.felix.framework-3.2.2.jar:]
at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1807)[org.apache.felix.framework-3.2.2.jar:]
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)[:1.6.0_35]
So, if I include the xml-apis.jar, I get the ClassCastException. If I don't include it, I get the ClassNotFoundException. Is there a way I can resolve this issue? Any help would be appreciated.

Import the package javax.xml.parsers.

have you tried commenting out the line
javax.xml.parsers, \
in the etc/jre.properties file? This should prevent loading of the class from rt.jar.

Problem solved!! (at least for me)
You can find a very good explanation of the problem in this link:
Dealing with "Xerces hell" in Java/Maven?
As you can read, actually, it's a problem of Xerces compatibility. Maybe you don't use Xerces, but probably you are using a library that use Xerces.
The solution in my case was to use an old version of xerces (lucene-xercesImpl) and exclude any reference to xml-apis o xerces:
<properties>
<ver.jena>2.10.1</ver.jena>
<ver.jena-sdb>1.3.6</ver.jena-sdb>
<ver.h2>1.3.173</ver.h2>
</properties>
<dependencies>
<dependency>
<groupId>org.apache.jena</groupId>
<artifactId>jena-sdb</artifactId>
<version>${ver.jena-sdb}</version>
<exclusions>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
<exclusion>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.apache.lucene</groupId>
<artifactId>lucene-xercesImpl</artifactId>
<version>3.5.0</version>
</dependency>
<dependency>
<groupId>org.apache.jena</groupId>
<artifactId>apache-jena-libs</artifactId>
<type>pom</type>
<version>${ver.jena}</version>
<exclusions>
<exclusion>
<artifactId>commons-codec</artifactId>
<groupId>commons-codec</groupId>
</exclusion>
<exclusion>
<groupId>org.apache.jena</groupId>
<artifactId>jena-tdb</artifactId>
</exclusion>
</exclusions>
</dependency>
Hope this help!

Maven ejb-client generation dependency exclusion

We have a solution where our UI projects are including quite a bunch of business services by using the EJB client dependencies. The problem with this on Maven is that even though the client .jar usually contains about 1-2 classes, they bring with them the full dependency stack of the entire service application. This can get a bit ugly, when the .ear files start growing up to 50-100Mb a pop and there are from time to time pesky errors thanks to irrelevant dependencies sneaking their way into the UI application.
Of course, we can always exclude the dependencies on the client end, but then we have to write the same bunch of lines to each client project using those services and that's a lot of needless repetition. Plus, people come up with the weirdest error messages and use a lot of time tracking them down before remembering to mention that they included some client jar and didn't check what additional dependencies it brought into the equation.
Example:
<dependency>
<groupId>fi.path.to.service</groupId>
<artifactId>customermanagement-common</artifactId>
<version>2.6</version>
</dependency>
<dependency>
<groupId>fi.path.to.service</groupId>
<artifactId>customermanagement-service</artifactId>
<classifier>client</classifier>
<exclusions>
<exclusion>
<groupId>fi.path.to.dependency</groupId>
<artifactId>internal-dependency-#1</artifactId>
</exclusion>
<exclusion>
<groupId>org.codehaus.castor</groupId>
<artifactId>castor</artifactId>
</exclusion>
<exclusion>
<groupId>fi.path.to.dependency</groupId>
<artifactId>internal-dependency-#2</artifactId>
</exclusion>
<exclusion>
<artifactId>internal-dependency-#3</artifactId>
<groupId>fi.path.to.dependency</groupId>
</exclusion>
<exclusion>
<artifactId>internal-dependency-#4</artifactId>
<groupId>fi.path.to.dependency</groupId>
</exclusion>
<exclusion>
<artifactId>internal-dependency-#5</artifactId>
<groupId>fi.path.to.dependency</groupId>
</exclusion>
<exclusion>
<artifactId>castor-xml</artifactId>
<groupId>org.codehaus.castor</groupId>
</exclusion>
<exclusion>
<artifactId>castor-codegen</artifactId>
<groupId>org.codehaus.castor</groupId>
</exclusion>
<exclusion>
<artifactId>castor-xml-schema</artifactId>
<groupId>org.codehaus.castor</groupId>
</exclusion>
<exclusion>
<artifactId>internal-dependency-#6</artifactId>
<groupId>fi.path.to.dependency</groupId>
</exclusion>
</exclusions>
<version>2.6</version>
</dependency>
That is just one service client being included, imagine having several of these in several different applications and you get the picture, writing up all the excludes each time is quite annoying and the project POMs start getting fairly longwinded.
I would mark the dependency as provided, but there are a couple dependencies that do crash on runtime, if they don't exist. Say ones that include another service call to yet another app with an external Exception class, which isn't for one reason or another wrapped inside the service project and will cause a ClassNotFoundException on runtime, if not present.
Therefore, I know it's possible to exclude/include classes from an ejb client during its generation through the usage of pom.xml specs on the maven-ejb-plugin, but is there any way to exclude dependencies as well?

Seems that Maven just doesn't support building multiple jars out of one module very well.
Thus the only reasonable way around this that we've found is to create another module (break xxx-service into xxx-service and xxx-service-client) and configure the xxx-service-client module to have only the EJB client/delegate class & minimal dependencies. That way the project can be built with a single execution.

I have the same problem here. I think one solution could be using profiles, since in each profile you could specify the dependencies (see http://blog.sonatype.com/people/2010/01/how-to-create-two-jars-from-one-project-and-why-you-shouldnt/)
In my case, this doesn't work, because I need to generate both JARs (ejb and ejb-client) in a single execution of Maven. :)

Missing artifact com.sun.jdmk:jmxtools:jar:1.2.1

I have created simple project from maven-achetype-quickstart under Eclipse Indigo, then I went to pom.xml gui editor and in dependencies tab added dependency log4j by search in appropriate dialog. Now my pom.xml looks like
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org xsd/maven-.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>mygroup</groupId>
<artifactId>Test_Maven_03</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>jar</packaging>
<name>Test_Maven_03</name>
<url>http://maven.apache.org</url>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.15</version>
</dependency>
</dependencies>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
</dependency>
</dependencies>
</dependencyManagement>
</project>
Eclipse says my POM have many problems like
Missing artifact javax.jms:jms:jar:1.1 pom.xml /Test_Maven_03 line 2 Maven Dependency Problem
What does it mean and how to see maven feature of automatic jar downloading.
EDIT 1
If I select log4j 1.2.16 instead of 1.2.15, I get another error: Missing artifact log4j:log4j:bundle:1.2.16. So I see no automatic jar management at all.

It's not included anymore due to licensing issues if I remember correctly. If you don't need jms functionality you can exclude jms from log4j dependency:
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.15</version>
<exclusions>
<exclusion>
<groupId>com.sun.jmx</groupId>
<artifactId>jmxri</artifactId>
</exclusion>
<exclusion>
<groupId>com.sun.jdmk</groupId>
<artifactId>jmxtools</artifactId>
</exclusion>
<exclusion>
<groupId>javax.jms</groupId>
<artifactId>jms</artifactId>
</exclusion>
</exclusions>
</dependency>

Change the version of log4j to 1.2.16.
The metadata for 1.2.15 is bad, as you have discovered, because the dependencies are missing from the central repository. However, there is a policy of not changing artifacts or metadata in the central maven repository, because this can lead to builds being unrepeatable. That is, a build might behave differently if an artifact or its metadata changed.
The reasoning is that it's better to work around bad metadata than cause unreproducible builds.
It's better, of course, if project maintainers are more careful about the metadata that they upload to central.

Use Log4J 1.2.16 (the one I linked to in your earlier question); it doesn't have the older JMX dependency and gets it from Geronimo instead.

The answers above (excluding JMX) are fine, so long as you don't need any of the JMX dependencies. However, you will never be able to download the JMX dependencies' .jar files from a standard maven repository. To quote Jörg Schaible-3 at nabble.com:
This is normal and it will stay so, because Sun/Oracle never granted
distribution rights for those artifacts as separate downloads. You will have
to download them from Oracle, accepting their license, and add them to a
local repository manager.
Therefore, if you want to use JMX, you will need to download the respective jmx zip folder from Oracle's website.

java.lang.IllegalAccessError: tried to access field org.slf4j.impl.StaticLoggerBinder.SINGLETON from class org.slf4j.LoggerFactory

I am facing this error while running my GWT application.
I have these jar files in my classpath: slf4j-api & slf4j-log4j12
Any idea what could be the reason?

This problem is due to a change in slf4j-log4j12 jar. From version 1.5.6 it doesn't allow to access the field org.slf4j.impl.StaticLoggerBinder.SINGLETON.
To resolve it, use the newest jars (or at least version 1.5.6 onward) for both slf4j-api & slf4j-log4j12.
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.5.6</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.5.6</version>
</dependency>

Finally resolved this problem in my SpringBoot application. If updating version is not helping this might help. Sometimes other libraries might bring different versions of this dependencies. These are the steps:
By error stack trace figure out which dependency is giving this issue
Get maven dependency plugin tree. Using this tree details find out if this library is coming as part of the some other dependency. In my case, the logback-classic and log4j-over-slf4j were giving this problem. They came together under spring-boot-starter-web
Use <exclusions><exclusion></exclusion></exclusions> in your pom.xml in that dependency for the libraries that giving this issue. In my case it looks like this:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<exclusions>
<exclusion>
<artifactId>logback-classic</artifactId>
<groupId>ch.qos.logback</groupId>
</exclusion>
<exclusion>
<artifactId>log4j-over-slf4j</artifactId>
<groupId>org.slf4j</groupId>
</exclusion>
</exclusions>
</dependency>
References:
http://www.slf4j.org/faq.html#IllegalAccessError
http://www.slf4j.org/codes.html#multiple_bindings

How to exclude cyclic deprecated dependencies in maven without killing the dependencies completely?

I have a case that I have the following cyclic dependencies in maven:
JAR A version 1.1 depends on JAR B version 1.0
JAR B version 1.1 depends on JAR A version 1.0
For some reason that I don't know, Maven brings all the 4 JARs: A 1.0, A 1.1, B 1.0 and B 1.1, which results in a classpath conflict.
This really sucks. I already ask the developers of both JARs to fix this, however I can't simply sit and wait for the day that they decide to fix this.
I tried this:
<dependency>
<groupId>groupA</groupId>
<artifactId>artifactA</artifactId>
<version>1.1</version>
<type>pom</type>
<scope>compile</scope>
<exclusions>
<exclusion>
<groupId>groupB</groupId>
<artifactId>artifactB</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>groupB</groupId>
<artifactId>artifactB</artifactId>
<version>1.1</version>
<type>pom</type>
<scope>compile</scope>
<exclusions>
<exclusion>
<groupId>groupA</groupId>
<artifactId>artifactA</artifactId>
</exclusion>
</exclusions>
</dependency>
The result is that maven excludes all of the JARs as if none dependency were added, and the project does not compiles because there are missing classes.
So, other than just asking both JARs developers to solve this, what can I do? How can I import both the new dependencies while leaving out both the old ones?

Pragmatic solution would be to redeclare the unwanted dependencies as provided, for example:
<dependency>
<groupId>groupA</groupId>
<artifactId>artifactA</artifactId>
<version>1.0</version>
<scope>provided</scope>
</dependency>
I'm not particularly fond of using provided in such manner, since it leaves the dependency in the compile time and could lead to unwanted compile dependencies, but I see no other way in your case ;(.