Am 07.10.12 21:47 schrieb "Christian Müller" unter
:
>That's great!
After the three consecutive successful runs, they all failed again just
right before and have got no idea why:
https://builds.apache.org/job/Camel.trunk.fulltest.java7/307/#showFailuresL
ink
Babak
>
>Thanks,
>Christian
>
That's great!
Thanks,
Christian
On Sun, Oct 7, 2012 at 11:31 AM, Babak Vahdat
wrote:
> Hi
>
> Just a short Head-Up regarding the camel-quickfix test failures on JDK7
> being mentioned by this thread (profile "Camel.trunk.fulltest.java7"):
>
> As a side effect of:
>
>https://issues.apache.org
Hi
Just a short Head-Up regarding the camel-quickfix test failures on JDK7
being mentioned by this thread (profile "Camel.trunk.fulltest.java7"):
As a side effect of:
https://issues.apache.org/jira/browse/CAMEL-5686
Now this module's tests do pass under JDK7 as well, following the last 3 run
Hi
Just a short Head-Up about the status of this:
The INFRA did kindly broadcast the same JDK 7 version on all nodes (for
details see the ticket) which now made all those SSL/TLS test failures
(camel-ahc, camel-jetty, etc.) to disappear:
https://builds.apache.org/job/Camel.trunk.fulltest.java7/2
I created a ticket: https://issues.apache.org/jira/browse/INFRA-5343
Thanks for looking into it.
Best,
Christian
On Tue, Oct 2, 2012 at 3:32 PM, Babak Vahdat wrote:
> Hi
>
> The test results of "Camel.trunk.fulltest.java7" profile is again there
> where it used to be, as an example looking at th
Hi
The test results of "Camel.trunk.fulltest.java7" profile is again there
where it used to be, as an example looking at the latest camel-jetty test
results:
https://builds.apache.org/job/Camel.trunk.fulltest.java7/295/org.apache.camel$camel-jetty/testReport/
It fails *exactly* by the same 3
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. Howev
Am 09.06.12 14:13 schrieb "Babak Vahdat" unter
:
>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:
>
>
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:
javax.activation
activation
On Sat, Jun 9, 2012 at 12:50 PM, 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/CAM
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:
>
> ht
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 di
On Sat, Jun 2, 2012 at 6:01 PM, Daniel Kulp 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 figu
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.ap
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.
Ther
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
wrote:
> Bingo! look at this... seems to be promising, as those 3 camel-jetty httpS
> related tests (failing since ages) did s
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.JettyHttpsProdu
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+)
Maven home: /x1/jenkins/jenkins-slave/tools/Maven/maven-3.0.4
Java version: 1.7.0_04, vendor: Oracle Corporation
Java home: /x1
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
> s
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
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 <
christian.muel...@gmail.com>
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-mav
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 ha
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
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
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
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+
On Tue, May 8, 2012 at 3:26 PM, Daniel Kulp 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
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";)
> >
> >
On Tuesday, May 08, 2012 01:18:52 PM Claus Ibsen wrote:
> On Tue, May 8, 2012 at 1:12 PM, Daniel Kulp 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/
On Tue, May 8, 2012 at 1:12 PM, Daniel Kulp 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
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 anyw
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.
org.apache.karaf
org.osgi.core
3.0.0-SNAPSHOT
Christian
Am 08.05.201
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
34 matches
Mail list logo
