On Nov 4, 2008, at 4:22 PM, Gili wrote:
>
>
> Paul Sandoz wrote:
>>
>> We could do the following:
>>
>> 1) Have a class in jersey core called FeatureAndProperties;
>>
>> 2) The ClientConfig and ResourceConfig extend this class.
>>
>> 3) FeaturesAndProperties can be injected.
>>
>> Then message body readers/writers requiring access to config
>> information are independent of client/server.
>>
>
> I like the general idea of injecting the configuration. You could then
> optionally provide a separate class that reads a configuration file
> when
> building the injected class.
>
I like the idea of general support for configuration using a Java class.
If say there was a property name:
com.sun.jersey.multipart.config
whose value was an instance or a fully qualified class name that is
the class of the instance then it would be very easy to inject such an
instance.
@JerseyProperty("com.sun.jersey.multipart.config") MailConfig cg;
Or perhaps define the property name on the MailConfig class instead.
>
> Paul Sandoz wrote:
>>
>> I have made changes to the life-cycle management of Jersey to support
>> @PostConstruct and @PreDestroy of resource classes (plan to do the
>> same for providers). What we could support is a way for the mail
>> support to register the multi-part instance it creates for clean up
>> when the request/response is done. One way to do this is to support a
>> @PerInstance life-cycle and the mail support asks Jersey to create an
>> instance of the MultiPart which will get destroyed when the request
>> goes out of scope. It should also work for Jersey clients working
>> within the server environment.
>>
>
> I like this idea too, though I would suggest the following:
>
> - Provide Jersey-specific integration on top of a generic core. Other
> implementations (maybe not even JAX-RS related) would provide their
> own
> integrations.
> - Keep MultiPart.cleanup() -- though I would rename it to dispose()
> -- for
> deployments without integrations. If you use an integrated solution
> it would
> call dispose() at the end of the request automatically.
>
OK.
>
> Paul Sandoz wrote:
>>
>> I would be inclined to build on JavaMail and take the fork-and-copy
>> approach. It should be possible to extend JavaMail for multipart/
>> form-
>> data then the Jersey layers above that becomes easier to support.
>>
>
> Are you saying that Javamail doesn't currently support multipart/
> form-data?
>
No, not as far as i know, there is no specific API on top of JavaMail.
It of course supports it as a general multipart message but i had to
add support for processing the content disposition so that i could do
look up of a body part by name.
Paul.