On 6/12/11 3:51 PM, Jim Talbut wrote:
Willem,
Am I right in thinking that you are looking at it on the client side?
Both Sun and OpenJDK send "application/octet-stream" as the
content-type, so that functionality isn't working for either of them.
And even if it was the test would be broken becaus
Claus,
It's CAMEL-4094.
Just started a full build again, so we'll see where that breaks :)
Jim
On 11/06/2011 10:57, Claus Ibsen wrote:
Hi Jim
Thanks for diving into this. Fell free to create a JIRA ticket with a patch.
Are the other tests that fail on OpenJDK on your system?
On Fri, Jun 10
Willem,
Am I right in thinking that you are looking at it on the client side?
Both Sun and OpenJDK send "application/octet-stream" as the
content-type, so that functionality isn't working for either of them.
And even if it was the test would be broken because the declared
content-type is not us
It relates to how the FileTypeMap implements.
In CamelFileDataSource you can see the content-type is determined by the
below method.
public String getContentType() {
if (typeMap == null) {
return
FileTypeMap.getDefaultFileTypeMap().getContentType(fileName);
} else
Hi Jim
Thanks for diving into this. Fell free to create a JIRA ticket with a patch.
Are the other tests that fail on OpenJDK on your system?
On Fri, Jun 10, 2011 at 9:14 PM, Jim Talbut wrote:
> I think both the test in camel-jetty and the code in camel-http are wrong.
>
> In camel-http (Defau
I think both the test in camel-jetty and the code in camel-http are wrong.
In camel-http (DefaultHttpBinding) we have:
protected void populateAttachments(HttpServletRequest request,
HttpMessage message) {
// check if there is multipart files, if so will put it into
DataHandler
On 09/06/2011 19:54, Jim Talbut wrote:
On 09/06/2011 15:32, James Talbut wrote:
On Thu, Jun 09, 2011 at 10:13:00PM +0800, Willem Jiang wrote:
Maybe it relates to the openjdk.
Can you try the latest SUN/Oracle JDK 1.6 to run the test ?
That's possible, I should be able to try later today.
I've
On 09/06/2011 15:32, James Talbut wrote:
On Thu, Jun 09, 2011 at 10:13:00PM +0800, Willem Jiang wrote:
Maybe it relates to the openjdk.
Can you try the latest SUN/Oracle JDK 1.6 to run the test ?
That's possible, I should be able to try later today.
I've also tried on Windows 7 and that works
On Thu, Jun 09, 2011 at 10:13:00PM +0800, Willem Jiang wrote:
> Maybe it relates to the openjdk.
> Can you try the latest SUN/Oracle JDK 1.6 to run the test ?
That's possible, I should be able to try later today.
I've also tried on Windows 7 and that works (breaks in camel-ftp, but that's
anothe
Maybe it relates to the openjdk.
Can you try the latest SUN/Oracle JDK 1.6 to run the test ?
On 6/8/11 3:21 PM, Jim Talbut wrote:
Environmet:
Apache Maven 2.2.1 (rdebian-4)
Java version: 1.6.0_22
Java home: /usr/lib/jvm/java-6-openjdk/jre
Default locale: en_GB, platform encoding: UTF-8
OS name:
Oops, just realized my typo about "the same OS" as you reported it under
Linux...
--
View this message in context:
http://camel.465427.n5.nabble.com/Build-break-in-camel-jetty-tp4468084p4472763.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Hi Jim,
running also on Windows-OS as same as you it works well for me on the trunk!
$> mvn -q test -Dtest=MultiPartFormTest
[echo] Maven version: 2.8-SNAPSHOT
[echo] OSGi version: 2.8.0.SNAPSHOT
---
T E S T S
---
On 09/06/2011 05:40, Claus Ibsen wrote:
Hi
Yeah. We have not seen this error on the other OS.
Do you get this error if you run the test multiple times?
On Wed, Jun 8, 2011 at 9:21 AM, Jim Talbut wrote:
Environmet:
Apache Maven 2.2.1 (rdebian-4)
Java version: 1.6.0_22
Java home: /usr/lib/jvm/
Hi
Yeah. We have not seen this error on the other OS.
Do you get this error if you run the test multiple times?
On Wed, Jun 8, 2011 at 9:21 AM, Jim Talbut wrote:
> Environmet:
> Apache Maven 2.2.1 (rdebian-4)
> Java version: 1.6.0_22
> Java home: /usr/lib/jvm/java-6-openjdk/jre
> Default locale
14 matches
Mail list logo
