You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Jim Talbut <jt...@spudsoft.co.uk> on 2011/06/08 09:21:08 UTC
Build break in camel-jetty
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: "linux" version: "2.6.38-8-generic" arch: "amd64" Family: "unix"
Source:
URL: https://svn.apache.org/repos/asf/camel/trunk
Repository Root: https://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1133250
Failure:
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.219
sec <<< FAILURE!
testSendMultiPartForm(org.apache.camel.component.jetty.MultiPartFormTest)
Time elapsed: 1.78 sec <<< FAILURE!
java.lang.AssertionError: Get a wrong response status expected:<200> but
was:<500>
at org.junit.Assert.fail(Assert.java:91)
at org.junit.Assert.failNotEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:126)
at org.junit.Assert.assertEquals(Assert.java:470)
at
org.apache.camel.component.jetty.MultiPartFormTest.testSendMultiPartForm(MultiPartFormTest.java:53)
Should I investigate further?
Jim
Re: Build break in camel-jetty
Posted by bvahdat <ba...@swissonline.ch>.
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.
Re: Build break in camel-jetty
Posted by bvahdat <ba...@swissonline.ch>.
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
-------------------------------------------------------
Running org.apache.camel.component.jetty.MultiPartFormTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.875 sec
Results :
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
If you're running ALL the unit-tests from the trunk, setting MVN_OPTS helps
to avoid a possible OutOfMemoryError which maybe is the root cause of the
error you get on your box (HTTP 500 == Internal Server Error), see also
http://camel.apache.org/building.html
Regards, Babak
--
View this message in context: http://camel.465427.n5.nabble.com/Build-break-in-camel-jetty-tp4468084p4472744.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Build break in camel-jetty
Posted by Jim Talbut <jt...@spudsoft.co.uk>.
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<jt...@spudsoft.co.uk> 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: "linux" version: "2.6.38-8-generic" arch: "amd64" Family: "unix"
>>
>> Source:
>> URL: https://svn.apache.org/repos/asf/camel/trunk
>> Repository Root: https://svn.apache.org/repos/asf
>> Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
>> Revision: 1133250
>>
>> Failure:
>> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.219 sec
>> <<< FAILURE!
>> testSendMultiPartForm(org.apache.camel.component.jetty.MultiPartFormTest)
>> Time elapsed: 1.78 sec<<< FAILURE!
>> java.lang.AssertionError: Get a wrong response status expected:<200> but
>> was:<500>
>> at org.junit.Assert.fail(Assert.java:91)
>> at org.junit.Assert.failNotEquals(Assert.java:645)
>> at org.junit.Assert.assertEquals(Assert.java:126)
>> at org.junit.Assert.assertEquals(Assert.java:470)
>> at
>> org.apache.camel.component.jetty.MultiPartFormTest.testSendMultiPartForm(MultiPartFormTest.java:53)
>>
>> Should I investigate further?
>>
>> Jim
>>
>
>
It's failing on this:
assertEquals("Get a wrong content type", "text/plain",
data.getContentType());
Because the content type is application/octet-stream.
Interestingly that assertion is just coming back as a 500 error, the
information from the assertion itself is lost.
It fails every time.
I haven't yet worked out why this is different from
MultiPartFormTestWithCustomFilter, which works.
Jim
Re: Build break in camel-jetty
Posted by Claus Ibsen <cl...@gmail.com>.
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 <jt...@spudsoft.co.uk> 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: "linux" version: "2.6.38-8-generic" arch: "amd64" Family: "unix"
>
> Source:
> URL: https://svn.apache.org/repos/asf/camel/trunk
> Repository Root: https://svn.apache.org/repos/asf
> Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
> Revision: 1133250
>
> Failure:
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.219 sec
> <<< FAILURE!
> testSendMultiPartForm(org.apache.camel.component.jetty.MultiPartFormTest)
> Time elapsed: 1.78 sec <<< FAILURE!
> java.lang.AssertionError: Get a wrong response status expected:<200> but
> was:<500>
> at org.junit.Assert.fail(Assert.java:91)
> at org.junit.Assert.failNotEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:126)
> at org.junit.Assert.assertEquals(Assert.java:470)
> at
> org.apache.camel.component.jetty.MultiPartFormTest.testSendMultiPartForm(MultiPartFormTest.java:53)
>
> Should I investigate further?
>
> Jim
>
--
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: Build break in camel-jetty
Posted by Willem Jiang <wi...@gmail.com>.
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 because the declared
> content-type is not used server side.
Because the multipart attachment is saved as a file, current we can't
get the content type from the request message.
>
> If you mean that should be on the server side I don't think it's right
> for the server to try to guess the mime-type of a file given to it by a
> client when the client has explicitly stated what the mime type should
> be (though it'd be great to have a backup for when the content-type
> isn't sent).
The test is failed because the OpenJDK can't build up right content-type
from the file name. As the server save the multipart attachments into
files rightly, we don't need spend lots of time to find out what
content-type of the attachment is.
>
> So I see the root cause as the fact that jetty doesn't make the declared
> content type available for files accessed via getAttributes.
You are right.
>
> I can't see anywhere that CamelFileDataSource is used.
> The test client uses the commons http client, which just uses a standard
> FileDataSource (one could easily provide a CamelFilePart to use
> CamelFileDataSource).
We are tent to test if the server can build up a right data handler from
multipart attachments. We could comment out assert of conent-type of the
test case by now.
>
> Jim
>
> On 12/06/2011 01:43, Willem Jiang wrote:
>> 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 {
>> return typeMap.getContentType(fileName);
>> }
>> }
>>
>> As you know Sun and OpenJDK has different implementation, so we get
>> the test failure.
>>
>> According to the comments of javax.activation.MimetypesFileTypeMap[1]
>> of the OpenJDK. You can see the content-type of NOTICE.txt should be
>> mapped to "text/plain". But it could be something wrong when it lookup
>> the mime.types file.
>>
>> I think you can fix it by apply a right mime.types file in your
>> environment.
>>
>> [1]http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/javax/activation/MimetypesFileTypeMap.java#MimetypesFileTypeMap
>>
>>
>>
>>
>>
>> On 6/11/11 3:14 AM, Jim Talbut wrote:
>>> 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
>>> Enumeration names = request.getAttributeNames();
>>> while (names.hasMoreElements()) {
>>> String name = (String) names.nextElement();
>>> Object object = request.getAttribute(name);
>>> LOG.trace("HTTP attachment {} = {}", name, object);
>>> if (object instanceof File) {
>>> String fileName = request.getParameter(name);
>>> message.addAttachment(fileName, new DataHandler(new
>>> CamelFileDataSource((File)object, fileName)));
>>> }
>>> }
>>> }
>>>
>>> That creates the DataHandler for the uploaded file without specifying
>>> the content-type.
>>> So different implementations of DataHandler may well have different
>>> defaults (hence the difference between Sun and OpenJDK).
>>> This is wrong, but I can't see how to get the correct content-type for
>>> the uploaded file in order to add it to the constructor args.
>>>
>>> The test is explicitly testing that the DataHandler has the same
>>> defaults as the Sun JDK, which is not helpful.
>>> It ought to test that the content-type is application/octet-stream, but
>>> that would require changing camel-http.
>>>
>>> There are two options:
>>> 1. Fix camel-http so it does set the content-type correctly (though I
>>> couldn't work out where to get it from).
>>> We'd then have to fix the test to check for the correct content-type.
>>> 2. Remove the assertion from the test.
>>>
>>> Jim
>>>
>>>
>>> On 10/06/2011 07:20, Jim Talbut wrote:
>>>> 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 also tried on Windows 7 and that works (breaks in camel-ftp,
>>>>>> but that's another matter).
>>>>>>
>>>>>> Jim
>>>>> That was it, how interesting.
>>>>>
>>>>> I downloaded the Sun JDK, set JAVA_HOME to point to it and ran maven
>>>>> and it went correctly.
>>>>>
>>>>> Should Camel support alternative JVMs?
>>>>>
>>>>> Jim
>>>> Curiouser and curiouser...
>>>>
>>>> I'm starting to think that it's actually the OpenJDK that's right and
>>>> the test is wrong.
>>>> The test has:
>>>> Part[] parts = {
>>>> new StringPart("comment", "A binary file of some kind"),
>>>> new FilePart(file.getName(), file)
>>>> };
>>>> There is nothing there to specify the content-type and there seems to
>>>> be an assumption that it's binary, not text (though it is actually
>>>> text).
>>>>
>>>> The source for FilePart has:
>>>> public static final String DEFAULT_CONTENT_TYPE =
>>>> "application/octet-stream";
>>>> and that is used unless the content type is specified in the
>>>> constructor (which it isn't).
>>>>
>>>> So the string part should have a content type of "text/plain" and the
>>>> file part should have a content type of "application/octet-stream".
>>>>
>>>> The test has:
>>>> DataHandler data = in.getAttachment("NOTICE.txt");
>>>> assertNotNull("Should get the DataHandle NOTICE.txt", data);
>>>> assertEquals("Get a wrong content type", "text/plain",
>>>> data.getContentType());
>>>> Verifying that the file part is "text/plain".
>>>>
>>>> The on-the-wire data with OpenJDK is:
>>>>
>>>> --lDIZtpp0tBIGfhQWzHIZ5kV7QpREJSj-Cmp3Uf8C
>>>> Content-Disposition: form-data; name="comment"
>>>> Content-Type: text/plain; charset=US-ASCII
>>>> Content-Transfer-Encoding: 8bit
>>>>
>>>> A binary file of some kind
>>>> --lDIZtpp0tBIGfhQWzHIZ5kV7QpREJSj-Cmp3Uf8C
>>>> Content-Disposition: form-data; name="NOTICE.txt";
>>>> filename="NOTICE.txt"
>>>> Content-Type: application/octet-stream; charset=ISO-8859-1
>>>> Content-Transfer-Encoding: binary
>>>>
>>>> =========================================================================
>>>>
>>>> == NOTICE file corresponding to the section 4 d
>>>> of ==
>>>> == the Apache License, Version
>>>> 2.0, ==
>>>> == in this case for the Apache Camel
>>>> distribution. ==
>>>> =========================================================================
>>>>
>>>>
>>>> This product includes software developed by
>>>> The Apache Software Foundation (http://www.apache.org/).
>>>>
>>>> Please read the different LICENSE files present in the licenses
>>>> directory of
>>>> this distribution.
>>>>
>>>> --lDIZtpp0tBIGfhQWzHIZ5kV7QpREJSj-Cmp3Uf8C--
>>>>
>>>> The on-the-wire data with Sun JDK is:
>>>>
>>>> --qhLzs_ECq12ft9Tp3B1ayD-jjjzshV
>>>> Content-Disposition: form-data; name="comment"
>>>> Content-Type: text/plain; charset=US-ASCII
>>>> Content-Transfer-Encoding: 8bit
>>>>
>>>> A binary file of some kind
>>>> --qhLzs_ECq12ft9Tp3B1ayD-jjjzshV
>>>> Content-Disposition: form-data; name="NOTICE.txt";
>>>> filename="NOTICE.txt"
>>>> Content-Type: application/octet-stream; charset=ISO-8859-1
>>>> Content-Transfer-Encoding: binary
>>>>
>>>> =========================================================================
>>>>
>>>> == NOTICE file corresponding to the section 4 d
>>>> of ==
>>>> == the Apache License, Version
>>>> 2.0, ==
>>>> == in this case for the Apache Camel
>>>> distribution. ==
>>>> =========================================================================
>>>>
>>>>
>>>> This product includes software developed by
>>>> The Apache Software Foundation (http://www.apache.org/).
>>>>
>>>> Please read the different LICENSE files present in the licenses
>>>> directory of
>>>> this distribution.
>>>>
>>>> --qhLzs_ECq12ft9Tp3B1ayD-jjjzshV--
>>>>
>>>> Note that both have the correct content-type
>>>> (application/octet-stream) for the file.
>>>>
>>>> So I think there is a bug in camel-jetty when used with the Sun JDK.
>>>> Still looking, but please stop me if you think I've gone wrong so far!
>>>>
>>>> Jim
>>>
>>>
>>
>>
>
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
Re: Build break in camel-jetty
Posted by Jim Talbut <jt...@spudsoft.co.uk>.
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 used server side.
If you mean that should be on the server side I don't think it's right
for the server to try to guess the mime-type of a file given to it by a
client when the client has explicitly stated what the mime type should
be (though it'd be great to have a backup for when the content-type
isn't sent).
So I see the root cause as the fact that jetty doesn't make the declared
content type available for files accessed via getAttributes.
I can't see anywhere that CamelFileDataSource is used.
The test client uses the commons http client, which just uses a standard
FileDataSource (one could easily provide a CamelFilePart to use
CamelFileDataSource).
Jim
On 12/06/2011 01:43, Willem Jiang wrote:
> 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 {
> return typeMap.getContentType(fileName);
> }
> }
>
> As you know Sun and OpenJDK has different implementation, so we get
> the test failure.
>
> According to the comments of javax.activation.MimetypesFileTypeMap[1]
> of the OpenJDK. You can see the content-type of NOTICE.txt should be
> mapped to "text/plain". But it could be something wrong when it lookup
> the mime.types file.
>
> I think you can fix it by apply a right mime.types file in your
> environment.
>
> [1]http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/javax/activation/MimetypesFileTypeMap.java#MimetypesFileTypeMap
>
>
>
>
>
> On 6/11/11 3:14 AM, Jim Talbut wrote:
>> 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
>> Enumeration names = request.getAttributeNames();
>> while (names.hasMoreElements()) {
>> String name = (String) names.nextElement();
>> Object object = request.getAttribute(name);
>> LOG.trace("HTTP attachment {} = {}", name, object);
>> if (object instanceof File) {
>> String fileName = request.getParameter(name);
>> message.addAttachment(fileName, new DataHandler(new
>> CamelFileDataSource((File)object, fileName)));
>> }
>> }
>> }
>>
>> That creates the DataHandler for the uploaded file without specifying
>> the content-type.
>> So different implementations of DataHandler may well have different
>> defaults (hence the difference between Sun and OpenJDK).
>> This is wrong, but I can't see how to get the correct content-type for
>> the uploaded file in order to add it to the constructor args.
>>
>> The test is explicitly testing that the DataHandler has the same
>> defaults as the Sun JDK, which is not helpful.
>> It ought to test that the content-type is application/octet-stream, but
>> that would require changing camel-http.
>>
>> There are two options:
>> 1. Fix camel-http so it does set the content-type correctly (though I
>> couldn't work out where to get it from).
>> We'd then have to fix the test to check for the correct content-type.
>> 2. Remove the assertion from the test.
>>
>> Jim
>>
>>
>> On 10/06/2011 07:20, Jim Talbut wrote:
>>> 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 also tried on Windows 7 and that works (breaks in camel-ftp,
>>>>> but that's another matter).
>>>>>
>>>>> Jim
>>>> That was it, how interesting.
>>>>
>>>> I downloaded the Sun JDK, set JAVA_HOME to point to it and ran maven
>>>> and it went correctly.
>>>>
>>>> Should Camel support alternative JVMs?
>>>>
>>>> Jim
>>> Curiouser and curiouser...
>>>
>>> I'm starting to think that it's actually the OpenJDK that's right and
>>> the test is wrong.
>>> The test has:
>>> Part[] parts = {
>>> new StringPart("comment", "A binary file of some kind"),
>>> new FilePart(file.getName(), file)
>>> };
>>> There is nothing there to specify the content-type and there seems to
>>> be an assumption that it's binary, not text (though it is actually
>>> text).
>>>
>>> The source for FilePart has:
>>> public static final String DEFAULT_CONTENT_TYPE =
>>> "application/octet-stream";
>>> and that is used unless the content type is specified in the
>>> constructor (which it isn't).
>>>
>>> So the string part should have a content type of "text/plain" and the
>>> file part should have a content type of "application/octet-stream".
>>>
>>> The test has:
>>> DataHandler data = in.getAttachment("NOTICE.txt");
>>> assertNotNull("Should get the DataHandle NOTICE.txt", data);
>>> assertEquals("Get a wrong content type", "text/plain",
>>> data.getContentType());
>>> Verifying that the file part is "text/plain".
>>>
>>> The on-the-wire data with OpenJDK is:
>>>
>>> --lDIZtpp0tBIGfhQWzHIZ5kV7QpREJSj-Cmp3Uf8C
>>> Content-Disposition: form-data; name="comment"
>>> Content-Type: text/plain; charset=US-ASCII
>>> Content-Transfer-Encoding: 8bit
>>>
>>> A binary file of some kind
>>> --lDIZtpp0tBIGfhQWzHIZ5kV7QpREJSj-Cmp3Uf8C
>>> Content-Disposition: form-data; name="NOTICE.txt";
>>> filename="NOTICE.txt"
>>> Content-Type: application/octet-stream; charset=ISO-8859-1
>>> Content-Transfer-Encoding: binary
>>>
>>> =========================================================================
>>>
>>> == NOTICE file corresponding to the section 4 d
>>> of ==
>>> == the Apache License, Version
>>> 2.0, ==
>>> == in this case for the Apache Camel
>>> distribution. ==
>>> =========================================================================
>>>
>>>
>>> This product includes software developed by
>>> The Apache Software Foundation (http://www.apache.org/).
>>>
>>> Please read the different LICENSE files present in the licenses
>>> directory of
>>> this distribution.
>>>
>>> --lDIZtpp0tBIGfhQWzHIZ5kV7QpREJSj-Cmp3Uf8C--
>>>
>>> The on-the-wire data with Sun JDK is:
>>>
>>> --qhLzs_ECq12ft9Tp3B1ayD-jjjzshV
>>> Content-Disposition: form-data; name="comment"
>>> Content-Type: text/plain; charset=US-ASCII
>>> Content-Transfer-Encoding: 8bit
>>>
>>> A binary file of some kind
>>> --qhLzs_ECq12ft9Tp3B1ayD-jjjzshV
>>> Content-Disposition: form-data; name="NOTICE.txt";
>>> filename="NOTICE.txt"
>>> Content-Type: application/octet-stream; charset=ISO-8859-1
>>> Content-Transfer-Encoding: binary
>>>
>>> =========================================================================
>>>
>>> == NOTICE file corresponding to the section 4 d
>>> of ==
>>> == the Apache License, Version
>>> 2.0, ==
>>> == in this case for the Apache Camel
>>> distribution. ==
>>> =========================================================================
>>>
>>>
>>> This product includes software developed by
>>> The Apache Software Foundation (http://www.apache.org/).
>>>
>>> Please read the different LICENSE files present in the licenses
>>> directory of
>>> this distribution.
>>>
>>> --qhLzs_ECq12ft9Tp3B1ayD-jjjzshV--
>>>
>>> Note that both have the correct content-type
>>> (application/octet-stream) for the file.
>>>
>>> So I think there is a bug in camel-jetty when used with the Sun JDK.
>>> Still looking, but please stop me if you think I've gone wrong so far!
>>>
>>> Jim
>>
>>
>
>
Re: Build break in camel-jetty
Posted by Willem Jiang <wi...@gmail.com>.
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 {
return typeMap.getContentType(fileName);
}
}
As you know Sun and OpenJDK has different implementation, so we get the
test failure.
According to the comments of javax.activation.MimetypesFileTypeMap[1] of
the OpenJDK. You can see the content-type of NOTICE.txt should be mapped
to "text/plain". But it could be something wrong when it lookup the
mime.types file.
I think you can fix it by apply a right mime.types file in your environment.
[1]http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/javax/activation/MimetypesFileTypeMap.java#MimetypesFileTypeMap
On 6/11/11 3:14 AM, Jim Talbut wrote:
> 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
> Enumeration names = request.getAttributeNames();
> while (names.hasMoreElements()) {
> String name = (String) names.nextElement();
> Object object = request.getAttribute(name);
> LOG.trace("HTTP attachment {} = {}", name, object);
> if (object instanceof File) {
> String fileName = request.getParameter(name);
> message.addAttachment(fileName, new DataHandler(new
> CamelFileDataSource((File)object, fileName)));
> }
> }
> }
>
> That creates the DataHandler for the uploaded file without specifying
> the content-type.
> So different implementations of DataHandler may well have different
> defaults (hence the difference between Sun and OpenJDK).
> This is wrong, but I can't see how to get the correct content-type for
> the uploaded file in order to add it to the constructor args.
>
> The test is explicitly testing that the DataHandler has the same
> defaults as the Sun JDK, which is not helpful.
> It ought to test that the content-type is application/octet-stream, but
> that would require changing camel-http.
>
> There are two options:
> 1. Fix camel-http so it does set the content-type correctly (though I
> couldn't work out where to get it from).
> We'd then have to fix the test to check for the correct content-type.
> 2. Remove the assertion from the test.
>
> Jim
>
>
> On 10/06/2011 07:20, Jim Talbut wrote:
>> 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 also tried on Windows 7 and that works (breaks in camel-ftp,
>>>> but that's another matter).
>>>>
>>>> Jim
>>> That was it, how interesting.
>>>
>>> I downloaded the Sun JDK, set JAVA_HOME to point to it and ran maven
>>> and it went correctly.
>>>
>>> Should Camel support alternative JVMs?
>>>
>>> Jim
>> Curiouser and curiouser...
>>
>> I'm starting to think that it's actually the OpenJDK that's right and
>> the test is wrong.
>> The test has:
>> Part[] parts = {
>> new StringPart("comment", "A binary file of some kind"),
>> new FilePart(file.getName(), file)
>> };
>> There is nothing there to specify the content-type and there seems to
>> be an assumption that it's binary, not text (though it is actually text).
>>
>> The source for FilePart has:
>> public static final String DEFAULT_CONTENT_TYPE =
>> "application/octet-stream";
>> and that is used unless the content type is specified in the
>> constructor (which it isn't).
>>
>> So the string part should have a content type of "text/plain" and the
>> file part should have a content type of "application/octet-stream".
>>
>> The test has:
>> DataHandler data = in.getAttachment("NOTICE.txt");
>> assertNotNull("Should get the DataHandle NOTICE.txt", data);
>> assertEquals("Get a wrong content type", "text/plain",
>> data.getContentType());
>> Verifying that the file part is "text/plain".
>>
>> The on-the-wire data with OpenJDK is:
>>
>> --lDIZtpp0tBIGfhQWzHIZ5kV7QpREJSj-Cmp3Uf8C
>> Content-Disposition: form-data; name="comment"
>> Content-Type: text/plain; charset=US-ASCII
>> Content-Transfer-Encoding: 8bit
>>
>> A binary file of some kind
>> --lDIZtpp0tBIGfhQWzHIZ5kV7QpREJSj-Cmp3Uf8C
>> Content-Disposition: form-data; name="NOTICE.txt"; filename="NOTICE.txt"
>> Content-Type: application/octet-stream; charset=ISO-8859-1
>> Content-Transfer-Encoding: binary
>>
>> =========================================================================
>> == NOTICE file corresponding to the section 4 d
>> of ==
>> == the Apache License, Version
>> 2.0, ==
>> == in this case for the Apache Camel
>> distribution. ==
>> =========================================================================
>>
>> This product includes software developed by
>> The Apache Software Foundation (http://www.apache.org/).
>>
>> Please read the different LICENSE files present in the licenses
>> directory of
>> this distribution.
>>
>> --lDIZtpp0tBIGfhQWzHIZ5kV7QpREJSj-Cmp3Uf8C--
>>
>> The on-the-wire data with Sun JDK is:
>>
>> --qhLzs_ECq12ft9Tp3B1ayD-jjjzshV
>> Content-Disposition: form-data; name="comment"
>> Content-Type: text/plain; charset=US-ASCII
>> Content-Transfer-Encoding: 8bit
>>
>> A binary file of some kind
>> --qhLzs_ECq12ft9Tp3B1ayD-jjjzshV
>> Content-Disposition: form-data; name="NOTICE.txt"; filename="NOTICE.txt"
>> Content-Type: application/octet-stream; charset=ISO-8859-1
>> Content-Transfer-Encoding: binary
>>
>> =========================================================================
>> == NOTICE file corresponding to the section 4 d
>> of ==
>> == the Apache License, Version
>> 2.0, ==
>> == in this case for the Apache Camel
>> distribution. ==
>> =========================================================================
>>
>> This product includes software developed by
>> The Apache Software Foundation (http://www.apache.org/).
>>
>> Please read the different LICENSE files present in the licenses
>> directory of
>> this distribution.
>>
>> --qhLzs_ECq12ft9Tp3B1ayD-jjjzshV--
>>
>> Note that both have the correct content-type
>> (application/octet-stream) for the file.
>>
>> So I think there is a bug in camel-jetty when used with the Sun JDK.
>> Still looking, but please stop me if you think I've gone wrong so far!
>>
>> Jim
>
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
Re: Build break in camel-jetty
Posted by Jim Talbut <jt...@spudsoft.co.uk>.
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, 2011 at 9:14 PM, Jim Talbut<jt...@spudsoft.co.uk> wrote:
>> 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
>> Enumeration names = request.getAttributeNames();
>> while (names.hasMoreElements()) {
>> String name = (String) names.nextElement();
>> Object object = request.getAttribute(name);
>> LOG.trace("HTTP attachment {} = {}", name, object);
>> if (object instanceof File) {
>> String fileName = request.getParameter(name);
>> message.addAttachment(fileName, new DataHandler(new
>> CamelFileDataSource((File)object, fileName)));
>> }
>> }
>> }
>>
>> That creates the DataHandler for the uploaded file without specifying the
>> content-type.
>> So different implementations of DataHandler may well have different defaults
>> (hence the difference between Sun and OpenJDK).
>> This is wrong, but I can't see how to get the correct content-type for the
>> uploaded file in order to add it to the constructor args.
>>
>> The test is explicitly testing that the DataHandler has the same defaults as
>> the Sun JDK, which is not helpful.
>> It ought to test that the content-type is application/octet-stream, but that
>> would require changing camel-http.
>>
>> There are two options:
>> 1. Fix camel-http so it does set the content-type correctly (though I
>> couldn't work out where to get it from).
>> We'd then have to fix the test to check for the correct content-type.
>> 2. Remove the assertion from the test.
>>
>> Jim
>>
>>
>> On 10/06/2011 07:20, Jim Talbut wrote:
>>> 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 also tried on Windows 7 and that works (breaks in camel-ftp, but
>>>>> that's another matter).
>>>>>
>>>>> Jim
>>>> That was it, how interesting.
>>>>
>>>> I downloaded the Sun JDK, set JAVA_HOME to point to it and ran maven and
>>>> it went correctly.
>>>>
>>>> Should Camel support alternative JVMs?
>>>>
>>>> Jim
>>> Curiouser and curiouser...
>>>
>>> I'm starting to think that it's actually the OpenJDK that's right and the
>>> test is wrong.
>>> The test has:
>>> Part[] parts = {
>>> new StringPart("comment", "A binary file of some kind"),
>>> new FilePart(file.getName(), file)
>>> };
>>> There is nothing there to specify the content-type and there seems to be
>>> an assumption that it's binary, not text (though it is actually text).
>>>
>>> The source for FilePart has:
>>> public static final String DEFAULT_CONTENT_TYPE =
>>> "application/octet-stream";
>>> and that is used unless the content type is specified in the constructor
>>> (which it isn't).
>>>
>>> So the string part should have a content type of "text/plain" and the file
>>> part should have a content type of "application/octet-stream".
>>>
>>> The test has:
>>> DataHandler data = in.getAttachment("NOTICE.txt");
>>> assertNotNull("Should get the DataHandle
>>> NOTICE.txt", data);
>>> assertEquals("Get a wrong content type",
>>> "text/plain", data.getContentType());
>>> Verifying that the file part is "text/plain".
>>>
>>> The on-the-wire data with OpenJDK is:
>>>
>>> --lDIZtpp0tBIGfhQWzHIZ5kV7QpREJSj-Cmp3Uf8C
>>> Content-Disposition: form-data; name="comment"
>>> Content-Type: text/plain; charset=US-ASCII
>>> Content-Transfer-Encoding: 8bit
>>>
>>> A binary file of some kind
>>> --lDIZtpp0tBIGfhQWzHIZ5kV7QpREJSj-Cmp3Uf8C
>>> Content-Disposition: form-data; name="NOTICE.txt"; filename="NOTICE.txt"
>>> Content-Type: application/octet-stream; charset=ISO-8859-1
>>> Content-Transfer-Encoding: binary
>>>
>>>
>>> =========================================================================
>>> == NOTICE file corresponding to the section 4 d
>>> of ==
>>> == the Apache License, Version
>>> 2.0, ==
>>> == in this case for the Apache Camel
>>> distribution. ==
>>>
>>> =========================================================================
>>>
>>> This product includes software developed by
>>> The Apache Software Foundation (http://www.apache.org/).
>>>
>>> Please read the different LICENSE files present in the licenses
>>> directory of
>>> this distribution.
>>>
>>> --lDIZtpp0tBIGfhQWzHIZ5kV7QpREJSj-Cmp3Uf8C--
>>>
>>> The on-the-wire data with Sun JDK is:
>>>
>>> --qhLzs_ECq12ft9Tp3B1ayD-jjjzshV
>>> Content-Disposition: form-data; name="comment"
>>> Content-Type: text/plain; charset=US-ASCII
>>> Content-Transfer-Encoding: 8bit
>>>
>>> A binary file of some kind
>>> --qhLzs_ECq12ft9Tp3B1ayD-jjjzshV
>>> Content-Disposition: form-data; name="NOTICE.txt"; filename="NOTICE.txt"
>>> Content-Type: application/octet-stream; charset=ISO-8859-1
>>> Content-Transfer-Encoding: binary
>>>
>>>
>>> =========================================================================
>>> == NOTICE file corresponding to the section 4 d
>>> of ==
>>> == the Apache License, Version
>>> 2.0, ==
>>> == in this case for the Apache Camel
>>> distribution. ==
>>>
>>> =========================================================================
>>>
>>> This product includes software developed by
>>> The Apache Software Foundation (http://www.apache.org/).
>>>
>>> Please read the different LICENSE files present in the licenses
>>> directory of
>>> this distribution.
>>>
>>> --qhLzs_ECq12ft9Tp3B1ayD-jjjzshV--
>>>
>>> Note that both have the correct content-type (application/octet-stream)
>>> for the file.
>>>
>>> So I think there is a bug in camel-jetty when used with the Sun JDK.
>>> Still looking, but please stop me if you think I've gone wrong so far!
>>>
>>> Jim
>>
>
>
Re: Build break in camel-jetty
Posted by Claus Ibsen <cl...@gmail.com>.
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 <jt...@spudsoft.co.uk> wrote:
> 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
> Enumeration names = request.getAttributeNames();
> while (names.hasMoreElements()) {
> String name = (String) names.nextElement();
> Object object = request.getAttribute(name);
> LOG.trace("HTTP attachment {} = {}", name, object);
> if (object instanceof File) {
> String fileName = request.getParameter(name);
> message.addAttachment(fileName, new DataHandler(new
> CamelFileDataSource((File)object, fileName)));
> }
> }
> }
>
> That creates the DataHandler for the uploaded file without specifying the
> content-type.
> So different implementations of DataHandler may well have different defaults
> (hence the difference between Sun and OpenJDK).
> This is wrong, but I can't see how to get the correct content-type for the
> uploaded file in order to add it to the constructor args.
>
> The test is explicitly testing that the DataHandler has the same defaults as
> the Sun JDK, which is not helpful.
> It ought to test that the content-type is application/octet-stream, but that
> would require changing camel-http.
>
> There are two options:
> 1. Fix camel-http so it does set the content-type correctly (though I
> couldn't work out where to get it from).
> We'd then have to fix the test to check for the correct content-type.
> 2. Remove the assertion from the test.
>
> Jim
>
>
> On 10/06/2011 07:20, Jim Talbut wrote:
>>
>> 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 also tried on Windows 7 and that works (breaks in camel-ftp, but
>>>> that's another matter).
>>>>
>>>> Jim
>>>
>>> That was it, how interesting.
>>>
>>> I downloaded the Sun JDK, set JAVA_HOME to point to it and ran maven and
>>> it went correctly.
>>>
>>> Should Camel support alternative JVMs?
>>>
>>> Jim
>>
>> Curiouser and curiouser...
>>
>> I'm starting to think that it's actually the OpenJDK that's right and the
>> test is wrong.
>> The test has:
>> Part[] parts = {
>> new StringPart("comment", "A binary file of some kind"),
>> new FilePart(file.getName(), file)
>> };
>> There is nothing there to specify the content-type and there seems to be
>> an assumption that it's binary, not text (though it is actually text).
>>
>> The source for FilePart has:
>> public static final String DEFAULT_CONTENT_TYPE =
>> "application/octet-stream";
>> and that is used unless the content type is specified in the constructor
>> (which it isn't).
>>
>> So the string part should have a content type of "text/plain" and the file
>> part should have a content type of "application/octet-stream".
>>
>> The test has:
>> DataHandler data = in.getAttachment("NOTICE.txt");
>> assertNotNull("Should get the DataHandle
>> NOTICE.txt", data);
>> assertEquals("Get a wrong content type",
>> "text/plain", data.getContentType());
>> Verifying that the file part is "text/plain".
>>
>> The on-the-wire data with OpenJDK is:
>>
>> --lDIZtpp0tBIGfhQWzHIZ5kV7QpREJSj-Cmp3Uf8C
>> Content-Disposition: form-data; name="comment"
>> Content-Type: text/plain; charset=US-ASCII
>> Content-Transfer-Encoding: 8bit
>>
>> A binary file of some kind
>> --lDIZtpp0tBIGfhQWzHIZ5kV7QpREJSj-Cmp3Uf8C
>> Content-Disposition: form-data; name="NOTICE.txt"; filename="NOTICE.txt"
>> Content-Type: application/octet-stream; charset=ISO-8859-1
>> Content-Transfer-Encoding: binary
>>
>>
>> =========================================================================
>> == NOTICE file corresponding to the section 4 d
>> of ==
>> == the Apache License, Version
>> 2.0, ==
>> == in this case for the Apache Camel
>> distribution. ==
>>
>> =========================================================================
>>
>> This product includes software developed by
>> The Apache Software Foundation (http://www.apache.org/).
>>
>> Please read the different LICENSE files present in the licenses
>> directory of
>> this distribution.
>>
>> --lDIZtpp0tBIGfhQWzHIZ5kV7QpREJSj-Cmp3Uf8C--
>>
>> The on-the-wire data with Sun JDK is:
>>
>> --qhLzs_ECq12ft9Tp3B1ayD-jjjzshV
>> Content-Disposition: form-data; name="comment"
>> Content-Type: text/plain; charset=US-ASCII
>> Content-Transfer-Encoding: 8bit
>>
>> A binary file of some kind
>> --qhLzs_ECq12ft9Tp3B1ayD-jjjzshV
>> Content-Disposition: form-data; name="NOTICE.txt"; filename="NOTICE.txt"
>> Content-Type: application/octet-stream; charset=ISO-8859-1
>> Content-Transfer-Encoding: binary
>>
>>
>> =========================================================================
>> == NOTICE file corresponding to the section 4 d
>> of ==
>> == the Apache License, Version
>> 2.0, ==
>> == in this case for the Apache Camel
>> distribution. ==
>>
>> =========================================================================
>>
>> This product includes software developed by
>> The Apache Software Foundation (http://www.apache.org/).
>>
>> Please read the different LICENSE files present in the licenses
>> directory of
>> this distribution.
>>
>> --qhLzs_ECq12ft9Tp3B1ayD-jjjzshV--
>>
>> Note that both have the correct content-type (application/octet-stream)
>> for the file.
>>
>> So I think there is a bug in camel-jetty when used with the Sun JDK.
>> Still looking, but please stop me if you think I've gone wrong so far!
>>
>> Jim
>
>
--
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: Build break in camel-jetty
Posted by Jim Talbut <jt...@spudsoft.co.uk>.
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
Enumeration names = request.getAttributeNames();
while (names.hasMoreElements()) {
String name = (String) names.nextElement();
Object object = request.getAttribute(name);
LOG.trace("HTTP attachment {} = {}", name, object);
if (object instanceof File) {
String fileName = request.getParameter(name);
message.addAttachment(fileName, new DataHandler(new
CamelFileDataSource((File)object, fileName)));
}
}
}
That creates the DataHandler for the uploaded file without specifying
the content-type.
So different implementations of DataHandler may well have different
defaults (hence the difference between Sun and OpenJDK).
This is wrong, but I can't see how to get the correct content-type for
the uploaded file in order to add it to the constructor args.
The test is explicitly testing that the DataHandler has the same
defaults as the Sun JDK, which is not helpful.
It ought to test that the content-type is application/octet-stream, but
that would require changing camel-http.
There are two options:
1. Fix camel-http so it does set the content-type correctly (though I
couldn't work out where to get it from).
We'd then have to fix the test to check for the correct content-type.
2. Remove the assertion from the test.
Jim
On 10/06/2011 07:20, Jim Talbut wrote:
> 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 also tried on Windows 7 and that works (breaks in camel-ftp,
>>> but that's another matter).
>>>
>>> Jim
>> That was it, how interesting.
>>
>> I downloaded the Sun JDK, set JAVA_HOME to point to it and ran maven
>> and it went correctly.
>>
>> Should Camel support alternative JVMs?
>>
>> Jim
> Curiouser and curiouser...
>
> I'm starting to think that it's actually the OpenJDK that's right and
> the test is wrong.
> The test has:
> Part[] parts = {
> new StringPart("comment", "A binary file of some kind"),
> new FilePart(file.getName(), file)
> };
> There is nothing there to specify the content-type and there seems to
> be an assumption that it's binary, not text (though it is actually text).
>
> The source for FilePart has:
> public static final String DEFAULT_CONTENT_TYPE =
> "application/octet-stream";
> and that is used unless the content type is specified in the
> constructor (which it isn't).
>
> So the string part should have a content type of "text/plain" and the
> file part should have a content type of "application/octet-stream".
>
> The test has:
> DataHandler data =
> in.getAttachment("NOTICE.txt");
> assertNotNull("Should get the DataHandle
> NOTICE.txt", data);
> assertEquals("Get a wrong content type",
> "text/plain", data.getContentType());
> Verifying that the file part is "text/plain".
>
> The on-the-wire data with OpenJDK is:
>
> --lDIZtpp0tBIGfhQWzHIZ5kV7QpREJSj-Cmp3Uf8C
> Content-Disposition: form-data; name="comment"
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: 8bit
>
> A binary file of some kind
> --lDIZtpp0tBIGfhQWzHIZ5kV7QpREJSj-Cmp3Uf8C
> Content-Disposition: form-data; name="NOTICE.txt";
> filename="NOTICE.txt"
> Content-Type: application/octet-stream; charset=ISO-8859-1
> Content-Transfer-Encoding: binary
>
>
> =========================================================================
> == NOTICE file corresponding to the section 4 d
> of ==
> == the Apache License, Version
> 2.0, ==
> == in this case for the Apache Camel
> distribution. ==
>
> =========================================================================
>
> This product includes software developed by
> The Apache Software Foundation (http://www.apache.org/).
>
> Please read the different LICENSE files present in the licenses
> directory of
> this distribution.
>
> --lDIZtpp0tBIGfhQWzHIZ5kV7QpREJSj-Cmp3Uf8C--
>
> The on-the-wire data with Sun JDK is:
>
> --qhLzs_ECq12ft9Tp3B1ayD-jjjzshV
> Content-Disposition: form-data; name="comment"
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: 8bit
>
> A binary file of some kind
> --qhLzs_ECq12ft9Tp3B1ayD-jjjzshV
> Content-Disposition: form-data; name="NOTICE.txt";
> filename="NOTICE.txt"
> Content-Type: application/octet-stream; charset=ISO-8859-1
> Content-Transfer-Encoding: binary
>
>
> =========================================================================
> == NOTICE file corresponding to the section 4 d
> of ==
> == the Apache License, Version
> 2.0, ==
> == in this case for the Apache Camel
> distribution. ==
>
> =========================================================================
>
> This product includes software developed by
> The Apache Software Foundation (http://www.apache.org/).
>
> Please read the different LICENSE files present in the licenses
> directory of
> this distribution.
>
> --qhLzs_ECq12ft9Tp3B1ayD-jjjzshV--
>
> Note that both have the correct content-type
> (application/octet-stream) for the file.
>
> So I think there is a bug in camel-jetty when used with the Sun JDK.
> Still looking, but please stop me if you think I've gone wrong so far!
>
> Jim
Re: Build break in camel-jetty
Posted by Jim Talbut <jt...@spudsoft.co.uk>.
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 also tried on Windows 7 and that works (breaks in camel-ftp, but
>> that's another matter).
>>
>> Jim
> That was it, how interesting.
>
> I downloaded the Sun JDK, set JAVA_HOME to point to it and ran maven
> and it went correctly.
>
> Should Camel support alternative JVMs?
>
> Jim
Curiouser and curiouser...
I'm starting to think that it's actually the OpenJDK that's right and
the test is wrong.
The test has:
Part[] parts = {
new StringPart("comment", "A binary file of some kind"),
new FilePart(file.getName(), file)
};
There is nothing there to specify the content-type and there seems to be
an assumption that it's binary, not text (though it is actually text).
The source for FilePart has:
public static final String DEFAULT_CONTENT_TYPE =
"application/octet-stream";
and that is used unless the content type is specified in the constructor
(which it isn't).
So the string part should have a content type of "text/plain" and the
file part should have a content type of "application/octet-stream".
The test has:
DataHandler data = in.getAttachment("NOTICE.txt");
assertNotNull("Should get the DataHandle
NOTICE.txt", data);
assertEquals("Get a wrong content type",
"text/plain", data.getContentType());
Verifying that the file part is "text/plain".
The on-the-wire data with OpenJDK is:
--lDIZtpp0tBIGfhQWzHIZ5kV7QpREJSj-Cmp3Uf8C
Content-Disposition: form-data; name="comment"
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
A binary file of some kind
--lDIZtpp0tBIGfhQWzHIZ5kV7QpREJSj-Cmp3Uf8C
Content-Disposition: form-data; name="NOTICE.txt"; filename="NOTICE.txt"
Content-Type: application/octet-stream; charset=ISO-8859-1
Content-Transfer-Encoding: binary
=========================================================================
== NOTICE file corresponding to the section 4 d
of ==
== the Apache License, Version
2.0, ==
== in this case for the Apache Camel
distribution. ==
=========================================================================
This product includes software developed by
The Apache Software Foundation (http://www.apache.org/).
Please read the different LICENSE files present in the licenses
directory of
this distribution.
--lDIZtpp0tBIGfhQWzHIZ5kV7QpREJSj-Cmp3Uf8C--
The on-the-wire data with Sun JDK is:
--qhLzs_ECq12ft9Tp3B1ayD-jjjzshV
Content-Disposition: form-data; name="comment"
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
A binary file of some kind
--qhLzs_ECq12ft9Tp3B1ayD-jjjzshV
Content-Disposition: form-data; name="NOTICE.txt"; filename="NOTICE.txt"
Content-Type: application/octet-stream; charset=ISO-8859-1
Content-Transfer-Encoding: binary
=========================================================================
== NOTICE file corresponding to the section 4 d
of ==
== the Apache License, Version
2.0, ==
== in this case for the Apache Camel
distribution. ==
=========================================================================
This product includes software developed by
The Apache Software Foundation (http://www.apache.org/).
Please read the different LICENSE files present in the licenses
directory of
this distribution.
--qhLzs_ECq12ft9Tp3B1ayD-jjjzshV--
Note that both have the correct content-type (application/octet-stream)
for the file.
So I think there is a bug in camel-jetty when used with the Sun JDK.
Still looking, but please stop me if you think I've gone wrong so far!
Jim
Re: Build break in camel-jetty
Posted by Jim Talbut <jt...@spudsoft.co.uk>.
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 (breaks in camel-ftp, but that's another matter).
>
> Jim
That was it, how interesting.
I downloaded the Sun JDK, set JAVA_HOME to point to it and ran maven and
it went correctly.
Should Camel support alternative JVMs?
Jim
Re: Build break in camel-jetty
Posted by James Talbut <jt...@tardis.spudsoft>.
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 another matter).
Jim
Re: Build break in camel-jetty
Posted by Willem Jiang <wi...@gmail.com>.
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: "linux" version: "2.6.38-8-generic" arch: "amd64" Family: "unix"
>
> Source:
> URL: https://svn.apache.org/repos/asf/camel/trunk
> Repository Root: https://svn.apache.org/repos/asf
> Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
> Revision: 1133250
>
> Failure:
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.219
> sec <<< FAILURE!
> testSendMultiPartForm(org.apache.camel.component.jetty.MultiPartFormTest) Time
> elapsed: 1.78 sec <<< FAILURE!
> java.lang.AssertionError: Get a wrong response status expected:<200> but
> was:<500>
> at org.junit.Assert.fail(Assert.java:91)
> at org.junit.Assert.failNotEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:126)
> at org.junit.Assert.assertEquals(Assert.java:470)
> at
> org.apache.camel.component.jetty.MultiPartFormTest.testSendMultiPartForm(MultiPartFormTest.java:53)
>
>
> Should I investigate further?
>
> Jim
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang