Getting closer with Java7....

You likely saw a bunch of commits from me today.    I'm trying to get Camel
to be at least somewhat buildable and testable with Java7.   With the
changes today, Everything except camel-quickfix is compilable with Java7.  
I've slowing beginning to work through the tests.   I just got the camel-
spring stuff passing which is a big step.     I'll start going through more
of them tomorrow.

The three major "problems" are camel-test-blueprint, camel-twitter, and
camel-quickfix.  All three of them rely on libraries that are "Java 1.4
compatible" via the "-target jsr14" compiler flag on a Java5 vm.  This
allowed the code to work with Java 1.4, yet still use the Generics and such.  
Java6 apparently reads those types of classes fine and resolves the
generics.   Java 7 does not.   It sees 1.4 class files and doesn't grab any
generics from them.  

For camel-test-blueprint, I forced the older osgi-core lib in front which
doesn't have the generics.   Thus, both Java6 and 7 see the same non-
generics enabled class files.

For camel-twitter, I changed from mock classes to using
java.lang.reflect.Proxy object to mock the interfaces.  Thus, we don't have
to compile classes that actually implement the troublesome interfaces.

Haven't found a solution for camel-quickfix yet.   Thus, for java7, I've
removed that module from the build for now.  It looks like quickfix builds
with java5 and then retrotranslates to java1.4.   I think the j1.4 version
is what maven is picking up.  May need to find the 1.5 version and get that
into maven.  

Anyway, things are progressing.

--
Daniel Kulp
[hidden email] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

[Claus Ibsen-2]

Hi

Thanks its a good step in the right direction.

For quickfix, there is a new release (1.5.2), we could possible try to
see if that is compatible with Java7
http://www.quickfixj.org/

And we need an osgi bundle for it anyway, so we may publish it in the SMX repo
http://repo2.maven.org/maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles.quickfix/


For the fix in XStreamDataFormat.java, i wonder if the hardcoded namespace to
  @XmlType(name = "converterList", namespace =
"http://camel.apache.org/schema/spring")
would be an issue for Blueprint XML, as we have the schema as:
    "http://camel.apache.org/schema/blueprint" instead




On Tue, May 8, 2012 at 4:56 AM, Daniel Kulp <[hidden email]> wrote:

>
> You likely saw a bunch of commits from me today.    I'm trying to get Camel
> to be at least somewhat buildable and testable with Java7.   With the
> changes today, Everything except camel-quickfix is compilable with Java7.
> I've slowing beginning to work through the tests.   I just got the camel-
> spring stuff passing which is a big step.     I'll start going through more
> of them tomorrow.
>
> The three major "problems" are camel-test-blueprint, camel-twitter, and
> camel-quickfix.  All three of them rely on libraries that are "Java 1.4
> compatible" via the "-target jsr14" compiler flag on a Java5 vm.  This
> allowed the code to work with Java 1.4, yet still use the Generics and such.
> Java6 apparently reads those types of classes fine and resolves the
> generics.   Java 7 does not.   It sees 1.4 class files and doesn't grab any
> generics from them.
>
> For camel-test-blueprint, I forced the older osgi-core lib in front which
> doesn't have the generics.   Thus, both Java6 and 7 see the same non-
> generics enabled class files.
>
> For camel-twitter, I changed from mock classes to using
> java.lang.reflect.Proxy object to mock the interfaces.  Thus, we don't have
> to compile classes that actually implement the troublesome interfaces.
>
> Haven't found a solution for camel-quickfix yet.   Thus, for java7, I've
> removed that module from the build for now.  It looks like quickfix builds
> with java5 and then retrotranslates to java1.4.   I think the j1.4 version
> is what maven is picking up.  May need to find the 1.5 version and get that
> into maven.
>
> Anyway, things are progressing.
>
> --
> Daniel Kulp
> [hidden email] - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>

--
Claus Ibsen
-----------------
CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

[Christian Schneider]

I have created a Java 7 compliant osgi spec bundle in Karaf.

So if we need the generics we could use this. As the module is basically
just a pom we could also simply do the same in camel to avoid
the additional dependency.

<groupId>org.apache.karaf</groupId>
<artifactId>org.osgi.core</artifactId>
<version>3.0.0-SNAPSHOT</version>

Christian


Am 08.05.2012 04:56, schrieb Daniel Kulp:

> You likely saw a bunch of commits from me today.    I'm trying to get Camel
> to be at least somewhat buildable and testable with Java7.   With the
> changes today, Everything except camel-quickfix is compilable with Java7.
> I've slowing beginning to work through the tests.   I just got the camel-
> spring stuff passing which is a big step.     I'll start going through more
> of them tomorrow.
>
> The three major "problems" are camel-test-blueprint, camel-twitter, and
> camel-quickfix.  All three of them rely on libraries that are "Java 1.4
> compatible" via the "-target jsr14" compiler flag on a Java5 vm.  This
> allowed the code to work with Java 1.4, yet still use the Generics and such.
> Java6 apparently reads those types of classes fine and resolves the
> generics.   Java 7 does not.   It sees 1.4 class files and doesn't grab any
> generics from them.
>
> For camel-test-blueprint, I forced the older osgi-core lib in front which
> doesn't have the generics.   Thus, both Java6 and 7 see the same non-
> generics enabled class files.
>
> For camel-twitter, I changed from mock classes to using
> java.lang.reflect.Proxy object to mock the interfaces.  Thus, we don't have
> to compile classes that actually implement the troublesome interfaces.
>
> Haven't found a solution for camel-quickfix yet.   Thus, for java7, I've
> removed that module from the build for now.  It looks like quickfix builds
> with java5 and then retrotranslates to java1.4.   I think the j1.4 version
> is what maven is picking up.  May need to find the 1.5 version and get that
> into maven.
>
> Anyway, things are progressing.
>

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

On Tuesday, May 08, 2012 09:24:43 AM Claus Ibsen wrote:

> Hi
>
> Thanks its a good step in the right direction.
>
> For quickfix, there is a new release (1.5.2), we could possible try to
> see if that is compatible with Java7
> http://www.quickfixj.org/
>
> And we need an osgi bundle for it anyway, so we may publish it in the SMX
> repo
> http://repo2.maven.org/maven2/org/apache/servicemix/bundles/org.apache.se
> rvicemix.bundles.quickfix/

Need to get it into Central, not some unreliable extra repo.....  Need to
find a version that works first though.


> For the fix in XStreamDataFormat.java, i wonder if the hardcoded namespace
> to @XmlType(name = "converterList", namespace =
> "http://camel.apache.org/schema/spring")
> would be an issue for Blueprint XML, as we have the schema as:
>     "http://camel.apache.org/schema/blueprint" instead

Hmm...  Good point.  I'll try moving them out from being nested classes and
seeing if that helps.

Dan

>
> On Tue, May 8, 2012 at 4:56 AM, Daniel Kulp <[hidden email]> wrote:
> > You likely saw a bunch of commits from me today.    I'm trying to get
> > Camel to be at least somewhat buildable and testable with Java7.   With
> > the changes today, Everything except camel-quickfix is compilable with
> > Java7. I've slowing beginning to work through the tests.   I just got
> > the camel- spring stuff passing which is a big step.     I'll start
> > going through more of them tomorrow.
> >
> > The three major "problems" are camel-test-blueprint, camel-twitter, and
> > camel-quickfix.  All three of them rely on libraries that are "Java 1.4
> > compatible" via the "-target jsr14" compiler flag on a Java5 vm.  This
> > allowed the code to work with Java 1.4, yet still use the Generics and
> > such. Java6 apparently reads those types of classes fine and resolves
> > the generics.   Java 7 does not.   It sees 1.4 class files and doesn't
> > grab any generics from them.
> >
> > For camel-test-blueprint, I forced the older osgi-core lib in front
> > which
> > doesn't have the generics.   Thus, both Java6 and 7 see the same non-
> > generics enabled class files.
> >
> > For camel-twitter, I changed from mock classes to using
> > java.lang.reflect.Proxy object to mock the interfaces.  Thus, we don't
> > have to compile classes that actually implement the troublesome
> > interfaces.
> >
> > Haven't found a solution for camel-quickfix yet.   Thus, for java7, I've
> > removed that module from the build for now.  It looks like quickfix
> > builds with java5 and then retrotranslates to java1.4.   I think the
> > j1.4 version is what maven is picking up.  May need to find the 1.5
> > version and get that into maven.
> >
> > Anyway, things are progressing.
> >
> > --
> > Daniel Kulp
> > [hidden email] - http://dankulp.com/blog
> > Talend Community Coder - http://coders.talend.com

--
Daniel Kulp
[hidden email] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

[Claus Ibsen-2]

On Tue, May 8, 2012 at 1:12 PM, Daniel Kulp <[hidden email]> wrote:

> On Tuesday, May 08, 2012 09:24:43 AM Claus Ibsen wrote:
>> Hi
>>
>> Thanks its a good step in the right direction.
>>
>> For quickfix, there is a new release (1.5.2), we could possible try to
>> see if that is compatible with Java7
>> http://www.quickfixj.org/
>>
>> And we need an osgi bundle for it anyway, so we may publish it in the SMX
>> repo
>> http://repo2.maven.org/maven2/org/apache/servicemix/bundles/org.apache.se
>> rvicemix.bundles.quickfix/
>
> Need to get it into Central, not some unreliable extra repo.....  Need to
> find a version that works first though.
>

Thats actually maven central. Its the SMX bundles that Karaf and SMX uses.

Its shown in the maven search page
http://search.maven.org/#search%7Cga%7C1%7Cquickfix

>
>> For the fix in XStreamDataFormat.java, i wonder if the hardcoded namespace
>> to @XmlType(name = "converterList", namespace =
>> "http://camel.apache.org/schema/spring")
>> would be an issue for Blueprint XML, as we have the schema as:
>>     "http://camel.apache.org/schema/blueprint" instead
>
> Hmm...  Good point.  I'll try moving them out from being nested classes and
> seeing if that helps.
>
> Dan
>
>>
>> On Tue, May 8, 2012 at 4:56 AM, Daniel Kulp <[hidden email]> wrote:
>> > You likely saw a bunch of commits from me today.    I'm trying to get
>> > Camel to be at least somewhat buildable and testable with Java7.   With
>> > the changes today, Everything except camel-quickfix is compilable with
>> > Java7. I've slowing beginning to work through the tests.   I just got
>> > the camel- spring stuff passing which is a big step.     I'll start
>> > going through more of them tomorrow.
>> >
>> > The three major "problems" are camel-test-blueprint, camel-twitter, and
>> > camel-quickfix.  All three of them rely on libraries that are "Java 1.4
>> > compatible" via the "-target jsr14" compiler flag on a Java5 vm.  This
>> > allowed the code to work with Java 1.4, yet still use the Generics and
>> > such. Java6 apparently reads those types of classes fine and resolves
>> > the generics.   Java 7 does not.   It sees 1.4 class files and doesn't
>> > grab any generics from them.
>> >
>> > For camel-test-blueprint, I forced the older osgi-core lib in front
>> > which
>> > doesn't have the generics.   Thus, both Java6 and 7 see the same non-
>> > generics enabled class files.
>> >
>> > For camel-twitter, I changed from mock classes to using
>> > java.lang.reflect.Proxy object to mock the interfaces.  Thus, we don't
>> > have to compile classes that actually implement the troublesome
>> > interfaces.
>> >
>> > Haven't found a solution for camel-quickfix yet.   Thus, for java7, I've
>> > removed that module from the build for now.  It looks like quickfix
>> > builds with java5 and then retrotranslates to java1.4.   I think the
>> > j1.4 version is what maven is picking up.  May need to find the 1.5
>> > version and get that into maven.
>> >
>> > Anyway, things are progressing.
>> >
>> > --
>> > Daniel Kulp
>> > [hidden email] - http://dankulp.com/blog
>> > Talend Community Coder - http://coders.talend.com
> --
> Daniel Kulp
> [hidden email] - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>

--
Claus Ibsen
-----------------
CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

On Tuesday, May 08, 2012 01:18:52 PM Claus Ibsen wrote:

> On Tue, May 8, 2012 at 1:12 PM, Daniel Kulp <[hidden email]> wrote:
> > On Tuesday, May 08, 2012 09:24:43 AM Claus Ibsen wrote:
> >> And we need an osgi bundle for it anyway, so we may publish it in the
> >> SMX
> >> repo
> >> http://repo2.maven.org/maven2/org/apache/servicemix/bundles/org.apache.
> >> se
> >> rvicemix.bundles.quickfix/
> >
> > Need to get it into Central, not some unreliable extra repo.....  Need
> > to
> > find a version that works first though.
>
> Thats actually maven central. Its the SMX bundles that Karaf and SMX uses.
>
> Its shown in the maven search page
> http://search.maven.org/#search%7Cga%7C1%7Cquickfix

That's not the one we currently use at compile time though in camel-
quickfix.   It also needs to go someplace so smx can make a bundle out of
it.  

In either case, needs to get to central somehow, but first step is to find a
jar that "works".

--
Daniel Kulp
[hidden email] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

On Tuesday, May 08, 2012 07:12:28 AM Daniel Kulp wrote:

> On Tuesday, May 08, 2012 09:24:43 AM Claus Ibsen wrote:
> > For the fix in XStreamDataFormat.java, i wonder if the hardcoded
> > namespace to @XmlType(name = "converterList", namespace =
> > "http://camel.apache.org/schema/spring")
> >
> > would be an issue for Blueprint XML, as we have the schema as:
> >     "http://camel.apache.org/schema/blueprint" instead
>
> Hmm...  Good point.  I'll try moving them out from being nested classes
> and seeing if that helps.

Actually, this turns out to be the correct thing.   Internally, everything
is in the "spring" namespace.   The package-info.java uses the spring
namespace and the XmlType namespaces need to match that.

The blueprint namespace handler renames all the blueprint namespaces in the
blueprint DOM to the spring namespace prior to parsing so the parsing will
work.  Kind of a hack, but works.


--
Daniel Kulp
[hidden email] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

[Claus Ibsen-2]

On Tue, May 8, 2012 at 3:26 PM, Daniel Kulp <[hidden email]> wrote:

> On Tuesday, May 08, 2012 07:12:28 AM Daniel Kulp wrote:
>> On Tuesday, May 08, 2012 09:24:43 AM Claus Ibsen wrote:
>> > For the fix in XStreamDataFormat.java, i wonder if the hardcoded
>> > namespace to @XmlType(name = "converterList", namespace =
>> > "http://camel.apache.org/schema/spring")
>> >
>> > would be an issue for Blueprint XML, as we have the schema as:
>> >     "http://camel.apache.org/schema/blueprint" instead
>>
>> Hmm...  Good point.  I'll try moving them out from being nested classes
>> and seeing if that helps.
>
> Actually, this turns out to be the correct thing.   Internally, everything
> is in the "spring" namespace.   The package-info.java uses the spring
> namespace and the XmlType namespaces need to match that.
>
> The blueprint namespace handler renames all the blueprint namespaces in the
> blueprint DOM to the spring namespace prior to parsing so the parsing will
> work.  Kind of a hack, but works.
>

Ah perfect.

Yeah I thought that as well, but didn't realize how far the "hack"
goes with the rename.
But better raise a concern that none.

The Camel Karaf commands which spit out the routes in XML, actually
uses the spring namespace,
also if the route is from Blueprint. But that is what the JAXB model
namespaces was designed with in the first
place, when it was created about 5 years ago.

We could do a hack in the Karaf commands and spit out the namespace as
blueprint if its a blueprint route.
That would probably be nicer.


>
> --
> Daniel Kulp
> [hidden email] - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>



--
Claus Ibsen
-----------------
CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

[Christian Mueller]

There is no indication that quickfix 1.5.2 supports Java 7 [1]. But I will
give it a try today later. If it works, I will request a new bundle from
the SMX guys...

[1]
http://www.quickfixj.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&jqlQuery=fixVersion+%3D+%221.5.2%22+AND+project+%3D+QFJ

Best,
Christian

On Tue, May 8, 2012 at 3:36 PM, Claus Ibsen <[hidden email]> wrote:

> On Tue, May 8, 2012 at 3:26 PM, Daniel Kulp <[hidden email]> wrote:
> > On Tuesday, May 08, 2012 07:12:28 AM Daniel Kulp wrote:
> >> On Tuesday, May 08, 2012 09:24:43 AM Claus Ibsen wrote:
> >> > For the fix in XStreamDataFormat.java, i wonder if the hardcoded
> >> > namespace to @XmlType(name = "converterList", namespace =
> >> > "http://camel.apache.org/schema/spring")
> >> >
> >> > would be an issue for Blueprint XML, as we have the schema as:
> >> >     "http://camel.apache.org/schema/blueprint" instead
> >>
> >> Hmm...  Good point.  I'll try moving them out from being nested classes
> >> and seeing if that helps.
> >
> > Actually, this turns out to be the correct thing.   Internally,
> everything
> > is in the "spring" namespace.   The package-info.java uses the spring
> > namespace and the XmlType namespaces need to match that.
> >
> > The blueprint namespace handler renames all the blueprint namespaces in
> the
> > blueprint DOM to the spring namespace prior to parsing so the parsing
> will
> > work.  Kind of a hack, but works.
> >
>
> Ah perfect.
>
> Yeah I thought that as well, but didn't realize how far the "hack"
> goes with the rename.
> But better raise a concern that none.
>
> The Camel Karaf commands which spit out the routes in XML, actually
> uses the spring namespace,
> also if the route is from Blueprint. But that is what the JAXB model
> namespaces was designed with in the first
> place, when it was created about 5 years ago.
>
> We could do a hack in the Karaf commands and spit out the namespace as
> blueprint if its a blueprint route.
> That would probably be nicer.
>
>
> >
> > --
> > Daniel Kulp
> > [hidden email] - http://dankulp.com/blog
> > Talend Community Coder - http://coders.talend.com
> >
>
>
>
> --
> Claus Ibsen
> -----------------
> CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
> FuseSource
> Email: [hidden email]
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
>

[Claus Ibsen-2]

Hi

I installed the Java7 update 4 on my windows xp box.
And gave the latest source code a test spin

Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Maven home: E:\maven\bin\..
Java version: 1.7.0_04, vendor: Oracle Corporation
Java home: E:\jdk1.7.0_04\jre
Default locale: en_GB, platform encoding: Cp1252
OS name: "windows xp", version: "5.1", arch: "x86", family: "windows"

The core + the components has now been tested, and I go only a slights issues
- camel-jibx could not download the JARs needed for its test
compiling. I skipped this
- camel-zookeeper fails with a single test in some assertion
- i had to re-run camel-sql due a transient error, worked the 2nd run

I have not yet run the osgi and itests, but will give them a spin as well.
So far it does look good.



On Tue, May 8, 2012 at 7:23 PM, Christian Müller
<[hidden email]> wrote:

> There is no indication that quickfix 1.5.2 supports Java 7 [1]. But I will
> give it a try today later. If it works, I will request a new bundle from
> the SMX guys...
>
> [1]
> http://www.quickfixj.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&jqlQuery=fixVersion+%3D+%221.5.2%22+AND+project+%3D+QFJ
>
> Best,
> Christian
>
> On Tue, May 8, 2012 at 3:36 PM, Claus Ibsen <[hidden email]> wrote:
>
>> On Tue, May 8, 2012 at 3:26 PM, Daniel Kulp <[hidden email]> wrote:
>> > On Tuesday, May 08, 2012 07:12:28 AM Daniel Kulp wrote:
>> >> On Tuesday, May 08, 2012 09:24:43 AM Claus Ibsen wrote:
>> >> > For the fix in XStreamDataFormat.java, i wonder if the hardcoded
>> >> > namespace to @XmlType(name = "converterList", namespace =
>> >> > "http://camel.apache.org/schema/spring")
>> >> >
>> >> > would be an issue for Blueprint XML, as we have the schema as:
>> >> >     "http://camel.apache.org/schema/blueprint" instead
>> >>
>> >> Hmm...  Good point.  I'll try moving them out from being nested classes
>> >> and seeing if that helps.
>> >
>> > Actually, this turns out to be the correct thing.   Internally,
>> everything
>> > is in the "spring" namespace.   The package-info.java uses the spring
>> > namespace and the XmlType namespaces need to match that.
>> >
>> > The blueprint namespace handler renames all the blueprint namespaces in
>> the
>> > blueprint DOM to the spring namespace prior to parsing so the parsing
>> will
>> > work.  Kind of a hack, but works.
>> >
>>
>> Ah perfect.
>>
>> Yeah I thought that as well, but didn't realize how far the "hack"
>> goes with the rename.
>> But better raise a concern that none.
>>
>> The Camel Karaf commands which spit out the routes in XML, actually
>> uses the spring namespace,
>> also if the route is from Blueprint. But that is what the JAXB model
>> namespaces was designed with in the first
>> place, when it was created about 5 years ago.
>>
>> We could do a hack in the Karaf commands and spit out the namespace as
>> blueprint if its a blueprint route.
>> That would probably be nicer.
>>
>>
>> >
>> > --
>> > Daniel Kulp
>> > [hidden email] - http://dankulp.com/blog
>> > Talend Community Coder - http://coders.talend.com
>> >
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
>> FuseSource
>> Email: [hidden email]
>> Web: http://fusesource.com
>> Twitter: davsclaus, fusenews
>> Blog: http://davsclaus.blogspot.com/
>> Author of Camel in Action: http://www.manning.com/ibsen/
>>

--
Claus Ibsen
-----------------
CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

[Claus Ibsen-2]

Hi

So on the Apache CI servers running Ubuntu on java7 we got the last
missing pieces with SSL.

I had to dig a big and enable logging to System.out, to let it be
visibile in Jenkins what is the problem.
I dugged out this. The "bad record MAC".

Apart from that, then all other pieces seems okay on Java7.
It works on my osx and windows xp etc.



org.eclipse.jetty.io.EofException
        at org.eclipse.jetty.http.HttpParser.fill(HttpParser.java:954)
        at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:274)
        at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:218)
        at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
        at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
        at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
        at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
        at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
        at java.lang.Thread.run(Thread.java:722)
Caused by: javax.net.ssl.SSLException: bad record MAC
        at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
        at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1605)
        at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1573)
        at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:971)
        at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:876)
        at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:750)
        at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
        at org.eclipse.jetty.io.nio.SslSelectChannelEndPoint.unwrap(SslSelectChannelEndPoint.java:557)
        at org.eclipse.jetty.io.nio.SslSelectChannelEndPoint.fill(SslSelectChannelEndPoint.java:397)
        at org.eclipse.jetty.http.HttpParser.fill(HttpParser.java:949)
        ... 8 more




On Fri, May 11, 2012 at 10:14 AM, Claus Ibsen <[hidden email]> wrote:

> Hi
>
> I installed the Java7 update 4 on my windows xp box.
> And gave the latest source code a test spin
>
> Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
> Maven home: E:\maven\bin\..
> Java version: 1.7.0_04, vendor: Oracle Corporation
> Java home: E:\jdk1.7.0_04\jre
> Default locale: en_GB, platform encoding: Cp1252
> OS name: "windows xp", version: "5.1", arch: "x86", family: "windows"
>
> The core + the components has now been tested, and I go only a slights issues
> - camel-jibx could not download the JARs needed for its test
> compiling. I skipped this
> - camel-zookeeper fails with a single test in some assertion
> - i had to re-run camel-sql due a transient error, worked the 2nd run
>
> I have not yet run the osgi and itests, but will give them a spin as well.
> So far it does look good.
>
>
>
> On Tue, May 8, 2012 at 7:23 PM, Christian Müller
> <[hidden email]> wrote:
>> There is no indication that quickfix 1.5.2 supports Java 7 [1]. But I will
>> give it a try today later. If it works, I will request a new bundle from
>> the SMX guys...
>>
>> [1]
>> http://www.quickfixj.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&jqlQuery=fixVersion+%3D+%221.5.2%22+AND+project+%3D+QFJ
>>
>> Best,
>> Christian
>>
>> On Tue, May 8, 2012 at 3:36 PM, Claus Ibsen <[hidden email]> wrote:
>>
>>> On Tue, May 8, 2012 at 3:26 PM, Daniel Kulp <[hidden email]> wrote:
>>> > On Tuesday, May 08, 2012 07:12:28 AM Daniel Kulp wrote:
>>> >> On Tuesday, May 08, 2012 09:24:43 AM Claus Ibsen wrote:
>>> >> > For the fix in XStreamDataFormat.java, i wonder if the hardcoded
>>> >> > namespace to @XmlType(name = "converterList", namespace =
>>> >> > "http://camel.apache.org/schema/spring")
>>> >> >
>>> >> > would be an issue for Blueprint XML, as we have the schema as:
>>> >> >     "http://camel.apache.org/schema/blueprint" instead
>>> >>
>>> >> Hmm...  Good point.  I'll try moving them out from being nested classes
>>> >> and seeing if that helps.
>>> >
>>> > Actually, this turns out to be the correct thing.   Internally,
>>> everything
>>> > is in the "spring" namespace.   The package-info.java uses the spring
>>> > namespace and the XmlType namespaces need to match that.
>>> >
>>> > The blueprint namespace handler renames all the blueprint namespaces in
>>> the
>>> > blueprint DOM to the spring namespace prior to parsing so the parsing
>>> will
>>> > work.  Kind of a hack, but works.
>>> >
>>>
>>> Ah perfect.
>>>
>>> Yeah I thought that as well, but didn't realize how far the "hack"
>>> goes with the rename.
>>> But better raise a concern that none.
>>>
>>> The Camel Karaf commands which spit out the routes in XML, actually
>>> uses the spring namespace,
>>> also if the route is from Blueprint. But that is what the JAXB model
>>> namespaces was designed with in the first
>>> place, when it was created about 5 years ago.
>>>
>>> We could do a hack in the Karaf commands and spit out the namespace as
>>> blueprint if its a blueprint route.
>>> That would probably be nicer.
>>>
>>>
>>> >
>>> > --
>>> > Daniel Kulp
>>> > [hidden email] - http://dankulp.com/blog
>>> > Talend Community Coder - http://coders.talend.com
>>> >
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
>>> FuseSource
>>> Email: [hidden email]
>>> Web: http://fusesource.com
>>> Twitter: davsclaus, fusenews
>>> Blog: http://davsclaus.blogspot.com/
>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>
>
>
>
> --
> Claus Ibsen
> -----------------
> CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
> FuseSource
> Email: [hidden email]
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/

--
Claus Ibsen
-----------------
CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

[Babak Vahdat]

Hi

Most of the currently about 12 failed tests in

- camel-ahc
- camel-jetty
- camel-mina2

have something in common which is SSL ("bad record MAC" or whatnot). I suspect this has to do with a bug in JDK 7 itself.

Here is the same with Netty & JDK7: https://github.com/AtKaaZ/Chatzorz

But maybe I'm wrong.

Babak

I haven't looked at those specific modules, but I do know that to get CXF's
https tests working with Java7, we had to adjust a lot of the algorthims
that were set into the SSL socket factory things.    In Java7, they disabled
some of the algorithms that have been known to be "broken" (easily hacked).  
We had to go through all the failing tests and adjusting the algorithms.

That said, all the camel-jetty, camel-ahc, and camel-mina2 tests DO pass for
me with java 7 update 4 with the unlimited strength crypto stuff installed.  
I don't think the Java7 install on Jenkins has the unlimitted stuff
installed so it could just be related to that.   Not really sure though.  
Haven't had time to look.  


Dan


On Monday, May 28, 2012 01:59:28 AM Babak Vahdat wrote:

> Hi
>
> Most of the currently about 12 failed tests in
>
> - camel-ahc
> - camel-jetty
> - camel-mina2
>
> have something in common which is SSL ("bad record MAC" or whatnot). I
> suspect this has to do with a bug in JDK 7 itself.
>
> Here is the same with Netty & JDK7: https://github.com/AtKaaZ/Chatzorz
>
> But maybe I'm wrong.
>
> Babak
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Getting-closer-with-Java7-tp5692627p571
> 3620.html Sent from the Camel Development mailing list archive at
> Nabble.com.

--
Daniel Kulp
[hidden email] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

[Christian Mueller]

In my environment (see below), I could run
mvn clean install -o
for camel-ahc, camel-jetty, camel-netty, camel-mina2, camel-web and
camel-websocket without any problem.

Do we have Java 1.7.0_04 on Ubuntu?

Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Maven home: /Applications/apache-maven-3.0.4
Java version: 1.7.0_04, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.7.4", arch: "x86_64", family: "mac"

Best,
Christian

On Mon, May 28, 2012 at 10:59 AM, Babak Vahdat
<[hidden email]>wrote:

> Hi
>
> Most of the currently about 12 failed tests in
>
> - camel-ahc
> - camel-jetty
> - camel-mina2
>
> have something in common which is SSL ("bad record MAC" or whatnot). I
> suspect this has to do with a bug in JDK 7 itself.
>
> Here is the same with Netty & JDK7: https://github.com/AtKaaZ/Chatzorz
>
> But maybe I'm wrong.
>
> Babak
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Getting-closer-with-Java7-tp5692627p5713620.html
> Sent from the Camel Development mailing list archive at Nabble.com.
>

[Christian Mueller]

I found the two tickets below which should be fixed with Java version:
1.7.0_02

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7098735
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7031830

Best,
Christian

On Wed, May 30, 2012 at 11:51 PM, Christian Müller <
[hidden email]> wrote:

> In my environment (see below), I could run
> mvn clean install -o
> for camel-ahc, camel-jetty, camel-netty, camel-mina2, camel-web and
> camel-websocket without any problem.
>
> Do we have Java 1.7.0_04 on Ubuntu?
>
> Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
> Maven home: /Applications/apache-maven-3.0.4
>
> Java version: 1.7.0_04, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.7.4", arch: "x86_64", family: "mac"
>
> Best,
> Christian
>
>
> On Mon, May 28, 2012 at 10:59 AM, Babak Vahdat <
> [hidden email]> wrote:
>
>> Hi
>>
>> Most of the currently about 12 failed tests in
>>
>> - camel-ahc
>> - camel-jetty
>> - camel-mina2
>>
>> have something in common which is SSL ("bad record MAC" or whatnot). I
>> suspect this has to do with a bug in JDK 7 itself.
>>
>> Here is the same with Netty & JDK7: https://github.com/AtKaaZ/Chatzorz
>>
>> But maybe I'm wrong.
>>
>> Babak
>>
>> --
>> View this message in context:
>> http://camel.465427.n5.nabble.com/Getting-closer-with-Java7-tp5692627p5713620.html
>> Sent from the Camel Development mailing list archive at Nabble.com.
>>
>
>

[Babak Vahdat]

Hi Christian,

Yeah the good question of yours is what the *exact* version of JDK 7 we've got by the CI-Server box (Ubuntu). Those tests failing on CI-Server do pass by me as well (JDK 7 both on WIN as well as OS X). So why the suspection by my previous post: "I suspect this has to do with a bug in JDK 7 itself. ".. With that I meant on Ubuntu.

Who knows this? And if INFRA could eventuelly upgrade the installed JDK 7 version there? In worst case we should probably put a System.out.println(System.getProperty("java.version")) somewhere in TestSupport or the like to get the answer to this question on Ubuntu :-)

Babak

On Thursday, May 31, 2012 02:03:36 AM Babak Vahdat wrote:

> Hi Christian,
>
> Yeah the good question of yours is what the *exact* version of JDK 7 we've
> got by the CI-Server box (Ubuntu). Those tests failing on CI-Server do
> pass by me as well (JDK 7 both on WIN as well as OS X). So why the
> suspection by my previous post: "I suspect this has to do with a bug in
> JDK 7 itself. ".. With that I meant on Ubuntu.
>
> Who knows this? And if INFRA could eventuelly upgrade the installed JDK 7
> version there? In worst case we should probably put a
> System.out.println(System.getProperty("java.version")) somewhere in
> TestSupport or the like to get the answer to this question on Ubuntu :-)

I asked Olivier to look at this as he has access to this.   It's good to be
the boss... :-)

Dan


>
> Babak
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Getting-closer-with-Java7-tp5692627p571
> 3775.html Sent from the Camel Development mailing list archive at
> Nabble.com.
--
Daniel Kulp
[hidden email] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Ubuntu 3 is now updated.  Build is running:

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

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


Lets hope this works better.

Dan





On Thursday, May 31, 2012 07:25:00 AM Daniel Kulp wrote:

> On Thursday, May 31, 2012 02:03:36 AM Babak Vahdat wrote:
> > Hi Christian,
> >
> > Yeah the good question of yours is what the *exact* version of JDK 7
> > we've got by the CI-Server box (Ubuntu). Those tests failing on
> > CI-Server do pass by me as well (JDK 7 both on WIN as well as OS X). So
> > why the suspection by my previous post: "I suspect this has to do with
> > a bug in JDK 7 itself. ".. With that I meant on Ubuntu.
> >
> > Who knows this? And if INFRA could eventuelly upgrade the installed JDK
> > 7
> > version there? In worst case we should probably put a
> > System.out.println(System.getProperty("java.version")) somewhere in
> > TestSupport or the like to get the answer to this question on Ubuntu :-)
>
> I asked Olivier to look at this as he has access to this.   It's good to
> be the boss... :-)
>
> Dan
>
> > Babak
> >
> >
> > --
> > View this message in context:
> > http://camel.465427.n5.nabble.com/Getting-closer-with-Java7-tp5692627p57
> > 1
> > 3775.html Sent from the Camel Development mailing list archive at
> > Nabble.com.

--
Daniel Kulp
[hidden email] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

[Babak Vahdat]

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

[Christian Mueller]

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
<[hidden email]>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.
>