users@jersey.java.net

Re: [Jersey] Uploading files using Jersey client

From: Imran M Yousuf <imran_at_smartitengineering.com>
Date: Fri, 20 Mar 2009 16:01:18 +0600

On Fri, Mar 20, 2009 at 3:35 PM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
> On Mar 20, 2009, at 5:12 AM, Imran M Yousuf wrote:
>
>> Thanks a lot, I have got the Forms to get working as I want :) and it
>> seems to work quite fine and as expected. You can find the detail code
>> at the end of the mail. Also I made some comments in line.
>>
>
> Great. I am nearly finished with the forms and @FormDataParam. TODO:
>
> - Tweak @FormDataParam to properly support default values
>
> - JavaDoc @FormDataParam
>
> - Add sample
>

Once you are done let me know and I will gladly add the sample :), doc
pointers would be great.

>
>> On Thu, Mar 19, 2009 at 10:44 PM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>>>
>>> On Mar 19, 2009, at 11:20 AM, Imran M Yousuf wrote:
>>>
>>>>          File file = new File("src/test/resources/Splash-resized.jpg");
>>>>          MediaType imageType = new MediaType("image", "jpeg");
>>>>          FormDataMultiPart part = new FormDataMultiPart();
>>>>          FormDataMultiPart bodyPart = part.field("file", file,
>>>> imageType);
>>>>          resource.type(MediaType.MULTIPART_FORM_DATA_TYPE).post(
>>>>              part);
>>>
>>> Note you can already do the above as follows:
>>>
>>>   FormDataMultiPart multiPart = new FormDataMultiPart().
>>>       field(
>>>           "file",
>>>           new File("src/test/resources/Splash-resized.jpg"),
>>>           MediaType.valueOf("image/jpg")).
>>>       build();
>>>   resource.type(MediaType.MULTIPART_FORM_DATA_TYPE).post(multiPart);
>>>
>>> I have just committed the following to the trunk so you can do:
>>>
>>>   FormDataMultiPart multiPart = new FormDataMultiPart().
>>>       field(
>>>
>>>  FormDataContentDisposition.name("file").fileName("userfile").build(),
>>>           new File("src/test/resources/Splash-resized.jpg"),
>>>           MediaType.valueOf("image/jpg")).
>>>       build();
>>>
>>> I might tweak the builder pattern of FormDataContentDisposition because
>>> it
>>> is possible to convert one of the other builder methods in to a
>>> terminated
>>> builder method, but the principle will remain the same.
>>
>> The only thing that I wanted to avoid is creating disposition
>> manually. So basically what I would like to see is some like -
>>
>> new FileDataBodyPart(String formParamName, java.io.File attachment,
>> MediaType mediaType);
>> new FileDataBodyPart(String formParamName, java.io.File attachment);
>> //Will add media type from file name
>>
>
> OK. Can you please log an issue?
>

I can log the issue and also contribute to it since it will be fairly
straight forward implementation, I will work on it this weelend and
will submit a patch on Monday, if all goes well.

>
>> This would basically save a lot of effort. Another think I would like
>> see is the FileDataContentDisposition should respect "Content-Type"
>> header as its "getType"; what do you think?
>>
>
> The ContentDisposition.getType is not related to the Content-Type it is
> related to the type of the disposition. And Content-Disposition is
> orthogonal to Content-Type.
>

hmm, interesting, then how can the server receive the MIME-type of the content?

>
>> Also what do you think about adding a detailed example of file
>> attachment? like the one I implemented that would explain how to
>> submit forms using jersey-client and use Jersey on the server side?
>>
>
> Yes, a sample is important.
>

As mentioned earlier Almighty willing I will try to contribute it :).

>
>> Also another thing I just noticed is, if FormDataContentDisposition
>> had been a part of JAX-RS then my resource would not have to
>> depend on Jersey at all and I think such portability would be
>> appreciated by the community, what do you think?
>>
>
> Unfortunately it is not so simple. There are other additional details too.
> JAX-RS does not specify support for @FormParam with "multipart/form-data".
> One reason i am moving over to @FormDataParam is to avoid confusion when
> overloading.
>
> I agree this is an area that should be considered to standardization.
>

Should I log an issue and if yes where?

Thanks a lot.

Imran

> Paul.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>



-- 
Imran M Yousuf
Entrepreneur & Software Engineer
Smart IT Engineering
Dhaka, Bangladesh
Email: imran_at_smartitengineering.com
Blog: http://imyousuf-tech.blogs.smartitengineering.com/
Mobile: +880-1711402557