Hi

IMHO we should completley *remove* both an explicit JAXB-API as well as
JAXB-IMPL dependencies we claim to have. Let me shortly explain why:

As an example while running camel-jaxb's own unit-tests one would expect the
JVM to pick the JAXB classes from the jars (both API & IMPL) we claim to
be dependend on. But this is not the case, as per default the JVM
Class-Loading-Policy is PARENT_FIRST!

To verify that add the -verbose:class parameter to your MAVEN_OPTS:

set MAVEN_OPTS=-Xms512m -Xmx512m -XX:MaxPermSize=512m -verbose:class

Then run the tests and look where for example JVM picks up the class
javax.xml.bind.JAXBException from:

[Loaded javax.xml.bind.JAXBException from C:\Program
Files\Java\jdk1.6.0_31\jre\lib\rt.jar]

However there're also weird ways to make an AppServer make use of the
PARENT_LAST policy [2] but all these are just workarounds of the JAR-HELL
problem
we all are facing in pure Java world which apparently OSGi as well as JSR
294 (Project Jigsaw postponed to JDK 8 or later) have already solved / will
solve.

So all in one, IMHO Camel should depend on whatever JAXB version the JDK
ships with and if there's currently a bug in JDK 7, well then we should wait
until that gets fixed with a newer JDK 7 build (no matter how long it would
take for Oracle to fix it). And *first* then we should / could go live with
"Camel supports JDK 7".

I know what I'm saying here is contradictory to what I used to say by the
ticket [3] you're working on, but thinking a bit more about it that's what
my personal opinion is.

Another example of this is also Camel dependency to SLF4J which of course is
not part of Java-Core-API. And now running a Camel Web-App inside JBoss
would
not pick slf4j-api-1.6.1.jar under /WEB-INF/lib/slf4j-api-1.6.1.jar of your
WAR but the version of SLF4J JBoss ships with (uses it). Again changing the
Class-Loading-Policy [4] could resolve this if one faces problems at runtime
like NoSuchMethodError, ClassCastException etc.

Right before on my workspace I just did remove the following dependencies
inside camel-jaxb and still compilation as well as running all the tests
went well (mvn clean install):

        <dependency>
            <groupId>javax.xml.bind</groupId>
            <artifactId>jaxb-api</artifactId>
        </dependency>
        <dependency>
            <groupId>com.sun.xml.bind</groupId>
            <artifactId>jaxb-impl</artifactId>
        </dependency>


[1] http://openjdk.java.net/projects/jigsaw/
[2]
http://www.webspheretools.com/sites/webspheretools.nsf/docs/How%20to%20set%20the%20class%20loading%20policy%20to%20parent%20last%20using%20configuration%20files%20shipped%20within%20the%20EAR
[3] https://issues.apache.org/jira/browse/CAMEL-4955
[4] https://community.jboss.org/wiki/ClassLoadingConfiguration

Babak


--
View this message in context: 
http://camel.465427.n5.nabble.com/Upgrading-JAXB-API-impl-to-2-2-x-tp5560244p5560685.html
Sent from the Camel Development mailing list archive at Nabble.com.

Reply via email to