Hi Craig,
Some points on @FormParam multipart/form-data support follow:
- we should be able to support the @FormParam("xyz") FormDataBodyPart
so that one can get the meta-data. We probably need
support for @FormParam("xyz") FormDataContentDisposition for
backwards compatibility;
- the default value should not be returned directly and instead should
be passed to the reader as UTF-8 encoded characters. When
there is no reader but there is an extractor then the
extractor.extract(map) will support the default value correctly;
- originally i hacked support for the case where both multipart/form-
data and application/x-www-form-urlencoded can be consumed.
In hindsight i am not sure this is a good idea because there are
limitations to supporting both with one method, namely for form
parameters there is no content type so I defaulted to text/plain.
Thus i think keeping this separate is the right thing to do, and a
resource method should only consume multipart/form-data, consuming
something else in addition means the method should be
rejected.
- dependency on server-side implementation classes, which is something
i need to look at;
Paul.
On Jan 8, 2009, at 10:40 AM, Paul Sandoz wrote:
> HI Craig,
>
> Thanks for doing this. I plan to review and then remove the stuff
> from the jersey-server next week.
>
> Paul.
>
> On Dec 20, 2008, at 2:57 AM, Craig McClanahan wrote:
>
>> I've checked in some initial code to support @FormParam processing
>> in jersey-multipart, modelled extensively on the existing code in
>> jersey-server. To avoid interference between the two environments,
>> I have temporarily told jersey-multipart to recognize media type
>> "multipart/x-form-data" for this purpose.
>>
>> Things seem to work as expected so far (see test method testNine()
>> in MultiPartReaderWriterTest, and the corresponding resource method
>> in MultiPartResource), but I ran across a couple of interesting
>> things:
>>
>> * Ideally, I would like to be able to declare a @FormParam based
>> parameter as an arbitrary Java type, and supply an appropriate
>> MessageBodyReader that will translate automatically based on the
>> media type of that body part. However, when I tried this, Jersey
>> complained that the resource method was not valid. According to the
>> Javadocs for FormParam, it sounds like this use case is not supported
>> in JAX-RS 1.0 ... maybe relaxing this restriction should be
>> considered
>> in some future version.
>>
>> * If you don't include an entity parameter of type FormDataMultiPart
>> (or MultiPart), there is no way to get to the cleanup() method we
>> currently
>> use to clear out any temporary disk files used to buffer large
>> incoming
>> body parts. This increases the priority of finding an alternative
>> approach
>> to requiring the application to make this call.
>>
>> * That being said, you're going to need the FormDataMultiPart entity
>> anyway to deal with things like uploaded files anyway.
>>
>> Paul, could you take a look at the implementation
>> (FormDataMultiPartDispatchProvider) and make sure I'm on the right
>> track?
>>
>> Craig
>>
>> PS: The dispatch provider relies on a whole lot of machinery in
>> jersey-server, so I had to declare this as a dependency of jersey-
>> multipart. Currently it's marked as an optional dependency, but I
>> need to test to make sure you can write a client side application
>> that uses jersey-multipart, but does not include jersey-server, to
>> make sure we're not breaking anything.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>