You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Claus Ibsen <cl...@gmail.com> on 2012/06/02 14:05:47 UTC

Re: Getting closer with Java7....

Hi

Ah this is good. Yeah I really wonder why Jenkins dont in the top of
its log, logs the exact version numbers of the JDK it uses.
Apparently its a " trade secret" to figure out.

I tired an Ubuntu 12.04 image running in 32bit mode, with the _03
OpenJDK version. And that worked fine as well.
There was failures in camel-fop and camel-jsch due some other issues,
not related to SSL.

Well all together we should now be in shape for getting the last
pieces done for Camel 2.10.



On Thu, May 31, 2012 at 7:12 PM, Christian Müller
<ch...@gmail.com> wrote:
> We did it! The Java 7 build passed:
> https://builds.apache.org/job/Camel.trunk.fulltest.java7/118/
>
> Thank you all,
> Christian
>
>
> On Thu, May 31, 2012 at 4:33 PM, Babak Vahdat
> <ba...@swissonline.ch>wrote:
>
>> Bingo! look at this... seems to be promising, as those 3 camel-jetty httpS
>> related tests (failing since ages) did suddenly pass NOW:
>>
>>
>> https://builds.apache.org/job/Camel.trunk.fulltest.java7/118/org.apache.camel$camel-jetty/testReport/
>>
>>
>> org.apache.camel.component.jetty.jettyproducer.JettyHttpsProducerRouteSetupWithSystemPropsTest.testEndpoint
>>
>> org.apache.camel.component.jetty.jettyproducer.JettyHttpsProducerSslContextInUriTest.testEndpoint
>>
>> org.apache.camel.component.jetty.jettyproducer.JettyProducerHttpsRouteTest.testEndpoint
>>
>> Babak
>>
>>
>> --
>> View this message in context:
>> http://camel.465427.n5.nabble.com/Getting-closer-with-Java7-tp5692627p5713790.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.com
Author of Camel in Action: http://www.manning.com/ibsen

Re: Getting closer with Java7....

Posted by Babak Vahdat <ba...@swissonline.ch>.
Hi

The build failed again however this time by camel-quickfix:

https://builds.apache.org/job/Camel.trunk.fulltest.java7/132/org.apache.camel$camel-quickfix/testReport/

All of the 5 failures are because of the SAME reason that a quickfixj
specific MBean should not have been enlisted in JMX. However after the
upgrade to QuickFIX/J 1.5.2 this module did always pass! So to me the test
failure here seems very strange. Maybe some race condition in QuickFIX/J
code itself and whatnot.

Anyway the newest build was a success again:

https://builds.apache.org/job/Camel.trunk.fulltest.java7/133/

Babak


--
View this message in context: http://camel.465427.n5.nabble.com/Getting-closer-with-Java7-tp5692627p5714270.html
Sent from the Camel Development mailing list archive at Nabble.com.

Re: Getting closer with Java7....

Posted by Babak Vahdat <ba...@swissonline.ch>.
The other option could be also to modify the tests like:

if (jdk7) {
   assertEquals("application/octet-stream ...", handler.getContentType());
} else {
   assertEquals("image/jpeg ...", handler.getContentType());
}


Babak Vahdat wrote
> 
> Hi
> 
> The latest JDK 7 build went ALMOST well:
> 
> https://builds.apache.org/job/Camel.trunk.fulltest.java7/131/#showFailuresLink
> 
> The cause of the failed 5 tests in camel-mail is because of:
> 
> https://issues.apache.org/jira/browse/CAMEL-5339
> 
> As the built-in activation API inside JDK 7 itself behaves differently
> than the one coming through the maven transitive dependency:
> 
> javax.activation:activation:jar:1.1
> 
> As we intend to support both the JDK 6 & JDK 7 I think we should revert
> the change here (doing so on my own workspace resolves while building on
> JDK 7 / OS X).
> 
> Any thoughts?
> 
> Babak
> 


--
View this message in context: http://camel.465427.n5.nabble.com/Getting-closer-with-Java7-tp5692627p5714253.html
Sent from the Camel Development mailing list archive at Nabble.com.

Re: Getting closer with Java7....

Posted by Babak Vahdat <ba...@swissonline.ch>.

Am 09.06.12 14:13 schrieb "Babak Vahdat" unter
<ba...@swissonline.ch>:

>Yeah that makes sense, however what they say on their sites is
>contradictory
>to what they do provide (the parent POM of javax.mail:mail):
>
>http://search.maven.org/#artifactdetails%7Ccom.sun.mail%7Call%7C1.4.5%7Cpo
>m
>
>which brings:
>
>    <dependencies>
>        <dependency>
>            <groupId>javax.activation</groupId>
>            <artifactId>activation</artifactId>
>            <version>${activation-api.version}</version>
>        </dependency>
>    </dependencies>
>
>on the classpath to camel-mail and the version 1.4.5 is released in 2012!
>
>And better they had already cleaned up the JDK 1.4 & 5 stuff inside these
>POMs which are both EOL since ages!
>
>Anyway I'll try to fix the tests tomorrow.

O.K. That's already fixed. I did also kick another JDK 7 build. So let's
see how it will go this time.

Babak

>
>Babak
>
>
>--
>View this message in context:
>http://camel.465427.n5.nabble.com/Getting-closer-with-Java7-tp5692627p5714
>256.html
>Sent from the Camel Development mailing list archive at Nabble.com.



Re: Getting closer with Java7....

Posted by Babak Vahdat <ba...@swissonline.ch>.
Yeah that makes sense, however what they say on their sites is contradictory
to what they do provide (the parent POM of javax.mail:mail):

http://search.maven.org/#artifactdetails%7Ccom.sun.mail%7Call%7C1.4.5%7Cpom

which brings:

    <dependencies>
        <dependency>
            <groupId>javax.activation</groupId>
            <artifactId>activation</artifactId>
            <version>${activation-api.version}</version>
        </dependency>
    </dependencies>

on the classpath to camel-mail and the version 1.4.5 is released in 2012!

And better they had already cleaned up the JDK 1.4 & 5 stuff inside these
POMs which are both EOL since ages!

Anyway I'll try to fix the tests tomorrow.

Babak


--
View this message in context: http://camel.465427.n5.nabble.com/Getting-closer-with-Java7-tp5692627p5714256.html
Sent from the Camel Development mailing list archive at Nabble.com.

Re: Getting closer with Java7....

Posted by Claus Ibsen <cl...@gmail.com>.
On Sat, Jun 9, 2012 at 12:50 PM, Babak Vahdat
<ba...@swissonline.ch>wrote:

> Hi
>
> The latest JDK 7 build went ALMOST well:
>
>
> https://builds.apache.org/job/Camel.trunk.fulltest.java7/131/#showFailuresLink
>
> The cause of the failed 5 tests in camel-mail is because of:
>
> https://issues.apache.org/jira/browse/CAMEL-5339
>
> As the built-in activation API inside JDK 7 itself behaves differently than
> the one coming through the maven transitive dependency:
>
> javax.activation:activation:jar:1.1
>
> As we intend to support both the JDK 6 & JDK 7 I think we should revert the
> change here (doing so on my own workspace resolves while building on JDK 7
> /
> OS X).
>
> Any thoughts?
>
>
No the unit tests should be adjusted so they support both java 6 and 7.


When people use camel-mail on Java 7, in eg Tomcat / JEE server etc. then
activation JAR is already part of the JDK.
This is also what Oracle/SUN says on their website, that you only need
activation JAR if you use Java5 or older.




> Babak
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Getting-closer-with-Java7-tp5692627p5714252.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.com
Author of Camel in Action: http://www.manning.com/ibsen

Re: Getting closer with Java7....

Posted by Babak Vahdat <ba...@swissonline.ch>.
Hi

The latest JDK 7 build went ALMOST well:

https://builds.apache.org/job/Camel.trunk.fulltest.java7/131/#showFailuresLink

The cause of the failed 5 tests in camel-mail is because of:

https://issues.apache.org/jira/browse/CAMEL-5339

As the built-in activation API inside JDK 7 itself behaves differently than
the one coming through the maven transitive dependency:

javax.activation:activation:jar:1.1

As we intend to support both the JDK 6 & JDK 7 I think we should revert the
change here (doing so on my own workspace resolves while building on JDK 7 /
OS X).

Any thoughts?

Babak


--
View this message in context: http://camel.465427.n5.nabble.com/Getting-closer-with-Java7-tp5692627p5714252.html
Sent from the Camel Development mailing list archive at Nabble.com.

Re: Getting closer with Java7....

Posted by Claus Ibsen <cl...@gmail.com>.
On Sat, Jun 2, 2012 at 6:01 PM, Daniel Kulp <dk...@apache.org> wrote:
> On Saturday, June 02, 2012 02:05:47 PM Claus Ibsen wrote:
>> Hi
>>
>> Ah this is good. Yeah I really wonder why Jenkins dont in the top of
>> its log, logs the exact version numbers of the JDK it uses.
>> Apparently its a " trade secret" to figure out.
>
> It does print that out.   See:
>
> https://builds.apache.org/view/A-F/view/Camel/job/Camel.trunk.fulltest.java7/119/consoleText
>
> All the maven version info, java version, java home, etc....  Might be maven 3 only, not sure though.
>

Ah nice. It must have been improved since.

For example the 116 build only says

Started by an SCM change
Building remotely on ubuntu3 in workspace
/home/jenkins/jenkins-slave/workspace/Camel.trunk.fulltest.java7
Updating http://svn.apache.org/repos/asf/camel/trunk
U         parent/pom.xml
At revision 1344413
No emails were triggered.
Parsing POMs
Modules changed, recalculating dependency graph
[camel-trunk-java7] $ /home/hudson/tools/java/latest1.7/bin/java -da
-dsa -XX:MaxPermSize=512m -Xmx1200m -cp
/home/jenkins/jenkins-slave/maven3-agent.jar:/home/hudson/tools/maven/latest/boot/plexus-classworlds-2.4.jar
org.jvnet.hudson.maven3.agent.Maven3Main
/home/hudson/tools/maven/latest /x1/jenkins/jenkins-slave/slave.jar
/home/jenkins/jenkins-slave/maven3-interceptor.jar 44800
<===[JENKINS REMOTING CAPACITY]===>


And the latest one from the link from Dan, now includes the details.

[camel-trunk-java7] $ /home/hudson/tools/java/latest1.7/bin/java -da
-dsa -XX:MaxPermSize=512m -Xmx1200m -cp
/home/jenkins/jenkins-slave/maven3-agent.jar:/home/jenkins/jenkins-slave/tools/Maven/maven-3.0.4/boot/plexus-classworlds-2.4.jar
org.jvnet.hudson.maven3.agent.Maven3Main
/home/jenkins/jenkins-slave/tools/Maven/maven-3.0.4
/x1/jenkins/jenkins-slave/slave.jar
/home/jenkins/jenkins-slave/maven3-interceptor.jar 36097
<===[JENKINS REMOTING CAPACITY]===>���channel started
log4j:WARN No appenders could be found for logger
(org.apache.commons.beanutils.converters.BooleanConverter).
log4j:WARN Please initialize the log4j system properly.
Executing Maven:  -B -f
/home/jenkins/jenkins-slave/workspace/Camel.trunk.fulltest.java7/camel-trunk-java7/pom.xml
-Dmaven.repo.local=/home/jenkins/jenkins-slave/maven-repositories/1
-Dnoassembly -fae -B -e -U clean install -Dmaven.compiler.fork=true -V
Apache Maven 3.0.4 (r1232337; 2012-01-17 08:44:56+0000)
Maven home: /x1/jenkins/jenkins-slave/tools/Maven/maven-3.0.4
Java version: 1.7.0_04, vendor: Oracle Corporation
Java home: /x1/jenkins/tools/java/jdk1.7.0_04/jre
Default locale: en_US, platform encoding: ANSI_X3.4-1968
OS name: "linux", version: "2.6.32-32-server", arch: "amd64", family: "unix"
[INFO] Error stacktraces are turned on.
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective
model for org.apache.camel:camel-itest:jar:2.10-SNAPSHOT
[INFO] [WARNING] 'dependencies.dependency.systemPath' for
org.apache.camel:camel-validator-test-resources:jar should not point
at files within the project directory,
${basedir}/src/test/lib/camel-validator-test-resources.jar will be
unresolvable by dependent projects @ line 315, column 19
[WARNING]
[WARNING] It is highly recommended to fix these problems because they
threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer
support building such malformed projects.
------------------------------------------------------------------------[WARNING]

[INFO] Reactor Build Order:
[INFO]
[INFO] Camel
[INFO] Apache :: Camel Buildtools



> Dan
>
>
>
>>
>> I tired an Ubuntu 12.04 image running in 32bit mode, with the _03
>> OpenJDK version. And that worked fine as well.
>> There was failures in camel-fop and camel-jsch due some other issues,
>> not related to SSL.
>>
>> Well all together we should now be in shape for getting the last
>> pieces done for Camel 2.10.
>>
>>
>>
>> On Thu, May 31, 2012 at 7:12 PM, Christian Müller
>>
>> <ch...@gmail.com> wrote:
>> > We did it! The Java 7 build passed:
>> > https://builds.apache.org/job/Camel.trunk.fulltest.java7/118/
>> >
>> > Thank you all,
>> > Christian
>> >
>> >
>> > On Thu, May 31, 2012 at 4:33 PM, Babak Vahdat
>> >
>> > <ba...@swissonline.ch>wrote:
>> >> Bingo! look at this... seems to be promising, as those 3 camel-jetty
>> >> httpS related tests (failing since ages) did suddenly pass NOW:
>> >>
>> >>
>> >> https://builds.apache.org/job/Camel.trunk.fulltest.java7/118/org.apache
>> >> .camel$camel-jetty/testReport/
>> >>
>> >>
>> >> org.apache.camel.component.jetty.jettyproducer.JettyHttpsProducerRouteS
>> >> etupWithSystemPropsTest.testEndpoint
>> >>
>> >> org.apache.camel.component.jetty.jettyproducer.JettyHttpsProducerSslCon
>> >> textInUriTest.testEndpoint
>> >>
>> >> org.apache.camel.component.jetty.jettyproducer.JettyProducerHttpsRouteT
>> >> est.testEndpoint
>> >>
>> >> Babak
>> >>
>> >>
>> >> --
>> >> View this message in context:
>> >> http://camel.465427.n5.nabble.com/Getting-closer-with-Java7-tp5692627p5
>> >> 713790.html Sent from the Camel Development mailing list archive at
>> >> Nabble.com.
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>



-- 
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

Re: Getting closer with Java7....

Posted by Daniel Kulp <dk...@apache.org>.
On Saturday, June 02, 2012 02:05:47 PM Claus Ibsen wrote:
> Hi
> 
> Ah this is good. Yeah I really wonder why Jenkins dont in the top of
> its log, logs the exact version numbers of the JDK it uses.
> Apparently its a " trade secret" to figure out.

It does print that out.   See:

https://builds.apache.org/view/A-F/view/Camel/job/Camel.trunk.fulltest.java7/119/consoleText

All the maven version info, java version, java home, etc....  Might be maven 3 only, not sure though.

Dan



> 
> I tired an Ubuntu 12.04 image running in 32bit mode, with the _03
> OpenJDK version. And that worked fine as well.
> There was failures in camel-fop and camel-jsch due some other issues,
> not related to SSL.
> 
> Well all together we should now be in shape for getting the last
> pieces done for Camel 2.10.
> 
> 
> 
> On Thu, May 31, 2012 at 7:12 PM, Christian Müller
> 
> <ch...@gmail.com> wrote:
> > We did it! The Java 7 build passed:
> > https://builds.apache.org/job/Camel.trunk.fulltest.java7/118/
> > 
> > Thank you all,
> > Christian
> > 
> > 
> > On Thu, May 31, 2012 at 4:33 PM, Babak Vahdat
> > 
> > <ba...@swissonline.ch>wrote:
> >> Bingo! look at this... seems to be promising, as those 3 camel-jetty
> >> httpS related tests (failing since ages) did suddenly pass NOW:
> >> 
> >> 
> >> https://builds.apache.org/job/Camel.trunk.fulltest.java7/118/org.apache
> >> .camel$camel-jetty/testReport/
> >> 
> >> 
> >> org.apache.camel.component.jetty.jettyproducer.JettyHttpsProducerRouteS
> >> etupWithSystemPropsTest.testEndpoint
> >> 
> >> org.apache.camel.component.jetty.jettyproducer.JettyHttpsProducerSslCon
> >> textInUriTest.testEndpoint
> >> 
> >> org.apache.camel.component.jetty.jettyproducer.JettyProducerHttpsRouteT
> >> est.testEndpoint
> >> 
> >> Babak
> >> 
> >> 
> >> --
> >> View this message in context:
> >> http://camel.465427.n5.nabble.com/Getting-closer-with-Java7-tp5692627p5
> >> 713790.html Sent from the Camel Development mailing list archive at
> >> Nabble.com.
-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com