You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Christian Müller <ch...@gmail.com> on 2012/03/13 09:01:28 UTC
Upgrading JAXB API/impl to 2.2.x
I'm working on CAMEL-4955 to get our build running in Java 7. Because of an
issue in JAXB 2.1.13 and 2.2.4u1 I need a newer version of JAXB impl. JAXB
impl 2.1.14 is not released yet and I'm wondering whether we should upgrade
to JAXB API/impl 2.2.x. What are our constraints to upgrade Camel from JAXB
API 2.1 to 2.2 and JAXB impl from 2.1.13 to 2.2.5?
[1] http://java.net/jira/browse/JAXB-860
Thanks,
Christian
Re: Upgrading JAXB API/impl to 2.2.x
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Mar 13, 2012 at 12:58 PM, Babak Vahdat
<ba...@swissonline.ch> wrote:
> Claus
>
> What I was talking about was the camel-jaxb dependencies:
>
Ah yeah I think camel-jaxb should use the JDK stuff by default as its
part of JDK6+ now.
People can install a specific version of JAXB if they want to.
> ~/dev/workspace/camel/components/camel-jaxb>mvn dependency:tree
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building Camel :: JAXB 2.10-SNAPSHOT
> [INFO]
> ------------------------------------------------------------------------
> [INFO]
> [INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @ camel-jaxb ---
> [INFO] org.apache.camel:camel-jaxb:bundle:2.10-SNAPSHOT
> [INFO] +- org.apache.camel:camel-core:jar:2.10-SNAPSHOT:compile
> [INFO] | \- org.slf4j:slf4j-api:jar:1.6.1:compile
> [INFO] +- javax.xml.bind:jaxb-api:jar:2.1:compile
> [INFO] | +- javax.xml.stream:stax-api:jar:1.0-2:compile
> [INFO] | \- javax.activation:activation:jar:1.1:compile
> [INFO] +- com.sun.xml.bind:jaxb-impl:jar:2.1.13:compile
> [INFO] +- junit:junit:jar:4.8.1:test
> [INFO] +- org.apache.camel:camel-test-spring:jar:2.10-SNAPSHOT:test
> [INFO] | +- org.apache.camel:camel-test:jar:2.10-SNAPSHOT:test
> [INFO] | \- org.apache.camel:camel-spring:jar:2.10-SNAPSHOT:test
> [INFO] | +- org.springframework:spring-context:jar:3.0.7.RELEASE:test
> [INFO] | | +- org.springframework:spring-beans:jar:3.0.7.RELEASE:test
> [INFO] | | +- org.springframework:spring-core:jar:3.0.7.RELEASE:test
> [INFO] | | | \- commons-logging:commons-logging:jar:1.1.1:test
> [INFO] | | +-
> org.springframework:spring-expression:jar:3.0.7.RELEASE:test
> [INFO] | | \- org.springframework:spring-asm:jar:3.0.7.RELEASE:test
> [INFO] | +- org.springframework:spring-aop:jar:3.0.7.RELEASE:test
> [INFO] | | \- aopalliance:aopalliance:jar:1.0:test
> [INFO] | \- org.springframework:spring-tx:jar:3.0.7.RELEASE:test
> [INFO] +- org.apache.camel:camel-spring-javaconfig:jar:2.10-SNAPSHOT:test
> [INFO] | \-
> org.apache.servicemix.bundles:org.apache.servicemix.bundles.cglib:jar:2.1_3_6:test
> [INFO] +- org.slf4j:slf4j-log4j12:jar:1.6.1:test
> [INFO] | \- log4j:log4j:jar:1.2.16:test
> [INFO] +- org.codehaus.woodstox:woodstox-core-asl:jar:4.1.1:test
> [INFO] | \- org.codehaus.woodstox:stax2-api:jar:3.1.1:test
> [INFO] +- org.mockito:mockito-core:jar:1.8.5:test
> [INFO] | +- org.hamcrest:hamcrest-core:jar:1.1:test
> [INFO] | \- org.objenesis:objenesis:jar:1.0:test
> [INFO] \- org.springframework:spring-test:jar:3.0.7.RELEASE:test
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD SUCCESS
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 1.377s
> [INFO] Finished at: Wed Mar 07 09:03:22 CET 2012
> [INFO] Final Memory: 10M/1011M
> [INFO]
> ------------------------------------------------------------------------
>
> Babak
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Upgrading-JAXB-API-impl-to-2-2-x-tp5560244p5560745.html
> Sent from the Camel Development mailing list archive at Nabble.com.
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Upgrading JAXB API/impl to 2.2.x
Posted by Babak Vahdat <ba...@swissonline.ch>.
Claus
What I was talking about was the camel-jaxb dependencies:
~/dev/workspace/camel/components/camel-jaxb>mvn dependency:tree
[INFO] Scanning for projects...
[INFO]
[INFO]
------------------------------------------------------------------------
[INFO] Building Camel :: JAXB 2.10-SNAPSHOT
[INFO]
------------------------------------------------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @ camel-jaxb ---
[INFO] org.apache.camel:camel-jaxb:bundle:2.10-SNAPSHOT
[INFO] +- org.apache.camel:camel-core:jar:2.10-SNAPSHOT:compile
[INFO] | \- org.slf4j:slf4j-api:jar:1.6.1:compile
[INFO] +- javax.xml.bind:jaxb-api:jar:2.1:compile
[INFO] | +- javax.xml.stream:stax-api:jar:1.0-2:compile
[INFO] | \- javax.activation:activation:jar:1.1:compile
[INFO] +- com.sun.xml.bind:jaxb-impl:jar:2.1.13:compile
[INFO] +- junit:junit:jar:4.8.1:test
[INFO] +- org.apache.camel:camel-test-spring:jar:2.10-SNAPSHOT:test
[INFO] | +- org.apache.camel:camel-test:jar:2.10-SNAPSHOT:test
[INFO] | \- org.apache.camel:camel-spring:jar:2.10-SNAPSHOT:test
[INFO] | +- org.springframework:spring-context:jar:3.0.7.RELEASE:test
[INFO] | | +- org.springframework:spring-beans:jar:3.0.7.RELEASE:test
[INFO] | | +- org.springframework:spring-core:jar:3.0.7.RELEASE:test
[INFO] | | | \- commons-logging:commons-logging:jar:1.1.1:test
[INFO] | | +-
org.springframework:spring-expression:jar:3.0.7.RELEASE:test
[INFO] | | \- org.springframework:spring-asm:jar:3.0.7.RELEASE:test
[INFO] | +- org.springframework:spring-aop:jar:3.0.7.RELEASE:test
[INFO] | | \- aopalliance:aopalliance:jar:1.0:test
[INFO] | \- org.springframework:spring-tx:jar:3.0.7.RELEASE:test
[INFO] +- org.apache.camel:camel-spring-javaconfig:jar:2.10-SNAPSHOT:test
[INFO] | \-
org.apache.servicemix.bundles:org.apache.servicemix.bundles.cglib:jar:2.1_3_6:test
[INFO] +- org.slf4j:slf4j-log4j12:jar:1.6.1:test
[INFO] | \- log4j:log4j:jar:1.2.16:test
[INFO] +- org.codehaus.woodstox:woodstox-core-asl:jar:4.1.1:test
[INFO] | \- org.codehaus.woodstox:stax2-api:jar:3.1.1:test
[INFO] +- org.mockito:mockito-core:jar:1.8.5:test
[INFO] | +- org.hamcrest:hamcrest-core:jar:1.1:test
[INFO] | \- org.objenesis:objenesis:jar:1.0:test
[INFO] \- org.springframework:spring-test:jar:3.0.7.RELEASE:test
[INFO]
------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 1.377s
[INFO] Finished at: Wed Mar 07 09:03:22 CET 2012
[INFO] Final Memory: 10M/1011M
[INFO]
------------------------------------------------------------------------
Babak
--
View this message in context: http://camel.465427.n5.nabble.com/Upgrading-JAXB-API-impl-to-2-2-x-tp5560244p5560745.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: Upgrading JAXB API/impl to 2.2.x
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
camel-core does not have hardcoded dependencies on these JARs in Maven.
All we got is
- the google hashmap gets shaded directly into camel-core
- the slf4j JAR is the *only* 3rd party dependency we have
- osgi is not runtime dep, its set to provided (we use it to include
an OSGi activator in camel-core)
The rest is for unit testing.
[INFO] ------------------------------------------------------------------------
[INFO] Building Camel :: Core 2.10-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @ camel-core ---
[INFO] org.apache.camel:camel-core:bundle:2.10-SNAPSHOT
[INFO] +- com.googlecode.concurrentlinkedhashmap:concurrentlinkedhashmap-lru:jar:1.2:compile
[INFO] +- org.slf4j:slf4j-api:jar:1.6.4:compile
[INFO] +- org.osgi:org.osgi.core:jar:4.2.0:provided
[INFO] +- junit:junit:jar:4.10:test
[INFO] | \- org.hamcrest:hamcrest-core:jar:1.1:test
[INFO] +- org.slf4j:slf4j-log4j12:jar:1.6.4:test
[INFO] | \- log4j:log4j:jar:1.2.16:test
[INFO] +- org.easymock:easymock:jar:3.0:test
[INFO] | +- cglib:cglib-nodep:jar:2.2:test
[INFO] | \- org.objenesis:objenesis:jar:1.2:test
[INFO] \- xml-resolver:xml-resolver:jar:1.2:test
On Tue, Mar 13, 2012 at 12:30 PM, Babak Vahdat
<ba...@swissonline.ch> wrote:
> 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.
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Upgrading JAXB API/impl to 2.2.x
Posted by Br...@toyota-europe.com.
Babak,
Than those dependencies should be indeed removed from POM.
Cheers,
Bruno Barin
Purchasing/Warranty Business Support
Toyota Motor Europe
60 Avenue du Bourget,
1140 Brussels, Belgium
Ph: +32 (0) 2 745 5606
www.toyota-europe.com
Babak Vahdat <ba...@swissonline.ch>
13/03/2012 13:00
Please respond to
dev@camel.apache.org
To
dev@camel.apache.org
cc
Subject
Re: Upgrading JAXB API/impl to 2.2.x
Bruno
Since Camel 2.7 [1] onwards JDK 1.5 is not supported anymore. And our
concern here is Camel 2.10 or maybe even 3.0.
[1] http://camel.apache.org/what-are-the-dependencies.html
Babak
--
View this message in context:
http://camel.465427.n5.nabble.com/Upgrading-JAXB-API-impl-to-2-2-x-tp5560244p5560751.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: Upgrading JAXB API/impl to 2.2.x
Posted by Babak Vahdat <ba...@swissonline.ch>.
Bruno
Since Camel 2.7 [1] onwards JDK 1.5 is not supported anymore. And our
concern here is Camel 2.10 or maybe even 3.0.
[1] http://camel.apache.org/what-are-the-dependencies.html
Babak
--
View this message in context: http://camel.465427.n5.nabble.com/Upgrading-JAXB-API-impl-to-2-2-x-tp5560244p5560751.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: Upgrading JAXB API/impl to 2.2.x
Posted by Br...@toyota-europe.com.
The removal only makes sense if Camel will not support Java 5 anymore.
Because JAXB are only part of JDK as of Java 6.
Otherwise, we should create a profile for Java 5.
Cheers,
Bruno Barin
Purchasing/Warranty Business Support
Toyota Motor Europe
60 Avenue du Bourget,
1140 Brussels, Belgium
Ph: +32 (0) 2 745 5606
www.toyota-europe.com
Babak Vahdat <ba...@swissonline.ch>
13/03/2012 12:30
Please respond to
dev@camel.apache.org
To
dev@camel.apache.org
cc
Subject
Re: Upgrading JAXB API/impl to 2.2.x
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.
Re: Upgrading JAXB API/impl to 2.2.x
Posted by Babak Vahdat <ba...@swissonline.ch>.
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.
Re: Upgrading JAXB API/impl to 2.2.x
Posted by Christian Müller <ch...@gmail.com>.
Because of [1] and the input here in this mail thread, I added a "jdk1.7"
profile which is enabled by default on Java 7. With this profile, we use
JAXB api 2.2 und JAXB impl 2.2.5. With this, I got rid of the
NullpointerExceptions in multiple tests running with Java 7 [2].
Unfortunately we got some other exceptions related to our JAXB model:
org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException:
Line 1613 in XML document from class path resource
[org/apache/camel/component/aws/s3/S3ComponentSpringTest-context.xml]
is invalid; nested exception is org.xml.sax.SAXParseException;
systemId: http://camel.apache.org/schema/spring/camel-spring.xsd;
lineNumber: 1613; columnNumber: 77; src-resolve: Cannot resolve the
name 'converterList' to a(n) 'type definition' component.
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:396)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:334)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:302)
at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:143)
at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:178)
at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:149)
at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:212)
at org.springframework.context.support.AbstractXmlApplicationContext.loadBeanDefinitions(AbstractXmlApplicationContext.java:126)
at org.springframework.context.support.AbstractXmlApplicationContext.loadBeanDefinitions(AbstractXmlApplicationContext.java:92)
at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:130)
at org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:467)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:397)
at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:139)
at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:83)
at org.apache.camel.component.aws.s3.S3ComponentSpringTest.createApplicationContext(S3ComponentSpringTest.java:99)
at org.apache.camel.component.aws.s3.S3ComponentSpringTest.createApplicationContext(S3ComponentSpringTest.java:32)
at org.apache.camel.test.junit4.CamelSpringTestSupport.doPreSetup(CamelSpringTestSupport.java:80)
at org.apache.camel.test.junit4.CamelTestSupport.setUp(CamelTestSupport.java:215)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:119)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:101)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
at $Proxy0.invoke(Unknown Source)
at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150)
at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
Caused by: org.xml.sax.SAXParseException; systemId:
http://camel.apache.org/schema/spring/camel-spring.xsd; lineNumber:
1613; columnNumber: 77; src-resolve: Cannot resolve the name
'converterList' to a(n) 'type definition' component.
at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:198)
at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:134)
at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:437)
at com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.reportSchemaErr(XSDHandler.java:4124)
at com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.reportSchemaError(XSDHandler.java:4107)
at com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.getGlobalDecl(XSDHandler.java:1667)
at com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDElementTraverser.traverseNamedElement(XSDElementTraverser.java:405)
at com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDElementTraverser.traverseLocal(XSDElementTraverser.java:194)
at com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.traverseLocalElements(XSDHandler.java:3580)
at com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.parseSchema(XSDHandler.java:622)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadSchema(XMLSchemaLoader.java:585)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.findSchemaGrammar(XMLSchemaValidator.java:2444)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleStartElement(XMLSchemaValidator.java:1763)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.startElement(XMLSchemaValidator.java:737)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:376)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2715)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:607)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:116)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:488)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:835)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:123)
at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:240)
at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:300)
at org.springframework.beans.factory.xml.DefaultDocumentLoader.loadDocument(DefaultDocumentLoader.java:75)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:388)
... 50 more
[1] http://java.net/jira/browse/JAXB-860
[2]
https://builds.apache.org/view/A-F/view/Camel/job/Camel.trunk.fulltest.java7
Best,
Christian
On Tue, Mar 13, 2012 at 8:59 PM, Babak Vahdat
<ba...@swissonline.ch>wrote:
> Which in other words it means to go all that way consequently to the roots
> you would also depend
> on *other* JAX-WS 2.x (METRO) or JAXP 1.4 Impl-versions than the ones
> coming
> along officially
> with the *core* Java API *since* JDK 6 which is not what we do, do we?
>
> Babak
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Upgrading-JAXB-API-impl-to-2-2-x-tp5560244p5562401.html
> Sent from the Camel Development mailing list archive at Nabble.com.
>
Re: Upgrading JAXB API/impl to 2.2.x
Posted by Babak Vahdat <ba...@swissonline.ch>.
Which in other words it means to go all that way consequently to the roots
you would also depend
on *other* JAX-WS 2.x (METRO) or JAXP 1.4 Impl-versions than the ones coming
along officially
with the *core* Java API *since* JDK 6 which is not what we do, do we?
Babak
--
View this message in context: http://camel.465427.n5.nabble.com/Upgrading-JAXB-API-impl-to-2-2-x-tp5560244p5562401.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: Upgrading JAXB API/impl to 2.2.x
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday, March 13, 2012 09:01:28 AM Christian Müller wrote:
> I'm working on CAMEL-4955 to get our build running in Java 7. Because of
> an issue in JAXB 2.1.13 and 2.2.4u1 I need a newer version of JAXB impl.
> JAXB impl 2.1.14 is not released yet and I'm wondering whether we should
> upgrade to JAXB API/impl 2.2.x. What are our constraints to upgrade Camel
> from JAXB API 2.1 to 2.2 and JAXB impl from 2.1.13 to 2.2.5?
>
> [1] http://java.net/jira/browse/JAXB-860
Upgrading to JAXB 2.2 is not "easy" and not really something that is
possible in Maven. Basically, without using endorsed mechanisms, you will
always get the version of the API that is provided by the JDK. Thus, with
JDK6, you get 2.1, with JDK 7, you get 2.2. The only way to use the 2.2.x
API's (and impl) on JDK6 is to endorse the 2.2 API jar which is not easy in
Maven (and also not something you want all your users doing).
The only real option is to use JDK activated profiles in maven to pull in
the appropriate IMPL. We definitely don't need to pull in an API as it's
pointless without endorsing. In java6, pull in the latest 2.1.13/14 and
on Java7, pull in 2.2.4/5. CXF has ended up doing this. (somewhat, we
have an explicite "jaxws22" profile that is active on Java5 and Java7, but
not on Java6)
BTW: despite the above "issues", I do think pulling in an explicit version
of the impl (and xjc if needed) is a good thing. The versions in the JDK
are always behind the released version and generally have a bunch of bugs,
classloader leaks, performance issues, etc... What's worse, each JDK
version has different issues so a user app may work with one jdk version,
but not another, etc... Making sure the users have a stable (er.. "known")
version in a specific known state is good for us. That's my opinion
though.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com