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.