Hi I think you have already pointed it out. I have moved the boundary parameter to next line in tcpmon and resent the request ( from tcpmon itself ). This seems to have worked as i no longer see boundary not found exception. But, I see a different one now:
org.apache.commons.fileupload.FileUploadBase$UnknownSizeException: the request was rejected because its size is unknown On Tue, Apr 26, 2011 at 4:22 PM, 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 > -- Regards, Shashank Rachamalla
