Here is what I'm seeing in my test:

POST /bookstore/books/fileform2 HTTP/1.1
Content-Type: multipart/form-data;
boundary=---------------------------1774014288799809133756375422
User-Agent: Jakarta Commons-HttpClient/3.1
Host: localhost:8081
Content-Length: 331

-----------------------------1774014288799809133756375422
Content-Disposition: form-data; name="title"

test
-----------------------------1774014288799809133756375422
Content-Disposition: form-data; name="file"; filename="test.txt"
Content-Type: text/plain

file content

-----------------------------1774014288799809133756375422--

Response (number of parts, as in your test code):

HTTP/1.1 200 OK
Content-Type: text/plain
Date: Wed, 27 Apr 2011 11:15:54 GMT
Content-Length: 1
Server: Jetty(7.3.1.v20110307)

2


There is only difference, Content-Length in my test is '331', in your
case it is 342.
The question is, where is the difference coming from ? If you save the
part of the log starting from the first part,

"-----------------------------1774014288799809133756375422",
immediately after Content-Length and the empty line,
and ending with the final closing boundary,
"-----------------------------1774014288799809133756375422--", to a
file, then you can see its length is 331.

Can you look into it ?

Cheers, Sergey



On Tue, Apr 26, 2011 at 11:52 AM, Shashank Rachamalla
<[email protected]> wrote:
>
>
> On Tue, Apr 26, 2011 at 4:18 PM, Sergey Beryozkin <[email protected]>
> wrote:
>>
>> Hi
>>
>> On Tue, Apr 26, 2011 at 11:11 AM, Shashank Rachamalla
>> <[email protected]> wrote:
>> > Hi
>> >
>> > i have made the following changes but the exception still gets caught:
>> >
>> >    @Override
>> >    @POST
>> >    @Consumes(MediaType.MULTIPART_FORM_DATA)
>> >    public Response saveForm(MultipartBody body) {
>> >        System.out.println(body.getAllAttachments().size());
>> >        return Response.status(Response.Status.OK).build();
>> >    }
>> >
>> >
>>
>> I have a nearly identical test resource (a single file case), please see
>>
>>
>> http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/resources/attachmentFormJsonFile
>
> thanks. will check it out.
>
>>
>> Can you please send me the tcpmon log as an attachment ? There must be
>> some extra space somewhere or something like that, but it can be
>> spotted during the debugging process...
>
> i have attached the log
>
>>
>> Cheers, Sergey
>>
>> > On Tue, Apr 26, 2011 at 3:19 PM, Shashank Rachamalla <
>> > [email protected]> wrote:
>> >
>> >> Hi
>> >>
>> >> thanks for replying. comments inline.
>> >>
>> >>
>> >> On Tue, Apr 26, 2011 at 2:52 PM, Sergey Beryozkin
>> >> <[email protected]>wrote:
>> >>
>> >>> Hi
>> >>>
>> >>> On Tue, Apr 26, 2011 at 9:58 AM, Shashank Rachamalla
>> >>> <[email protected]> wrote:
>> >>> > Hi
>> >>> >
>> >>> > Can anyone please let me know if I have done something wrong here..
>> >>> >
>> >>> > *I have exposed the following simple service method ( using cxf
>> >>> > 2.3.3 )
>> >>> *
>> >>> >
>> >>> >    @Override
>> >>> >    @POST
>> >>> >    @Consumes(MediaType.MULTIPART_FORM_DATA)
>> >>> >    public Response saveForm() {
>> >>> >
>> >>> >  System.out.println(AttachmentUtils.getAttachments(mc).size());
>> >>> >        return Response.status(Response.Status.OK).build();
>> >>> >    }
>> >>>
>> >>> I think the problem might be related to the fact you are calling
>> >>>
>> >>> AttachmentUtils.getAttachments(mc) directly, I'm assuming 'mc' is
>> >>> referring to injected MessageContext.
>> >>>
>> >>> yes, mc is referring to injected MessageContext
>> >>
>> >>
>> >>> I can actually see few tests where AttachmentUtils is called directly
>> >>> in the tests, ex, for simple form-data submissions:
>> >>>
>> >>> MultivaluedMap<String, String> data =
>> >>> AttachmentUtils.populateFormMap(context);
>> >>> and
>> >>> AttachmentUtils.getMultipartBody(context)
>> >>>
>> >>> but may be you have to explicitly add MultipartBody as a method
>> >>> parameter - this will ensure MultipartProvider is invoked and it does
>> >>> some multipart/form-data related processing, so it may help.
>> >>>
>> >>
>> >> fine. i will try this out now.
>> >>
>> >>
>> >>> More comments inline
>> >>>
>> >>> >
>> >>> > *The following is a request ( captured through tcpmon ) to the above
>> >>> defined
>> >>> > service method:* ( it is a form post )
>> >>> >
>> >>> > POST /api/v1/rest HTTP/1.1
>> >>> > Host: localhost:8081
>> >>> > User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.3)
>> >>> > Gecko/20100423 Ubuntu/10.04 (lucid) Firefox/3.6.3
>> >>> > Accept:
>> >>> > text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>> >>> > Accept-Language: en-us,en;q=0.5
>> >>> > Accept-Encoding: gzip,deflate
>> >>> > Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>> >>> > Keep-Alive: 115
>> >>> > Connection: keep-alive
>> >>> > Referer: http://localhost/form.html
>> >>> > Content-Type: multipart/form-data;
>> >>> > boundary=---------------------------91021093918280655661679102041
>> >>>
>> >>
>> >> tcpmon shows boundary on the same line.
>> >>
>> >>
>> >>>  Can it be a problem ? I'm not sure if the boundary parameter is shown
>> >>> on the next line by tcpmon or actually located on the next line, which
>> >>> is probably correct, but may be it's confusing CXF a bit ?
>> >>>
>> >>> > Content-Length: 345
>> >>> >
>> >>> > -----------------------------91021093918280655661679102041
>> >>> > Content-Disposition: form-data; name="title"
>> >>> >
>> >>> > test
>> >>> > -----------------------------91021093918280655661679102041
>> >>> > Content-Disposition: form-data; name="file"; filename="test.txt"
>> >>> > Content-Type: text/plain
>> >>> >
>> >>> > file content
>> >>> >
>> >>> > -----------------------------91021093918280655661679102041--
>> >>> >
>> >>>
>> >>> Can it be that the extra line between 'file content' and the final
>> >>> boundary is present ?
>> >>>
>> >>> >
>> >>> > *The following is the response received for above request:*
>> >>> >
>> >>> > <ns1:XMLFault>
>> >>> > <ns1:faultstring>
>> >>> > java.io.IOException: Couldn't find MIME boundary:
>> >>> > -----------------------------91021093918280655661679102041
>> >>> > </ns1:faultstring>
>> >>> > </ns1:XMLFault>
>> >>> >
>> >>> > Thanks in advance !
>> >>> >
>> >>>
>> >>> Please try adding MultipartBody to the method signature and I'll do a
>> >>> test a bit later on too,
>> >>>
>> >>> thanks, Sergey
>> >>>
>> >>>
>> >>> >
>> >>> > Regards,
>> >>> > Shashank Rachamalla
>> >>> >
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Regards,
>> >> Shashank Rachamalla
>> >>
>> >
>> >
>> >
>> > --
>> > Regards,
>> > Shashank Rachamalla
>> >
>>
>>
>>
>> --
>> Sergey Beryozkin
>>
>> Application Integration Division of Talend
>> http://sberyozkin.blogspot.com
>
>
>
> --
> Regards,
> Shashank Rachamalla
>



-- 
Sergey Beryozkin

Application Integration Division of Talend
http://sberyozkin.blogspot.com

Reply via email to