Craig McClanahan wrote:
> Paul Sandoz wrote:
>>
>>> Paul, the InjectableProvider stuff[1] in Jersey would support this,
>>> right?
>>
>> Possibly... :-)
>>
>>
> Until now I hadn't actually tried building my own injectable
> provider. It turns out to be pretty straightforward, but with only
> one bit of grief ... it doesn't work for me on the client side :-(.
> The complete diff (from the current trunk) that I am playing with is
> attached, but here's the highlights:
>
> * A new JavaBean (MultiPartConfig) that represents the
> configuration data. Right now it's just a dummy with a
> hard coded value, but if this experiment works out we can
> easily make it look up the parameters in a properties file
> or something.
>
> * A new provider annotation (MultiPartConfigParam) to
> declare the injectable type.
>
> * A new provider (MultiPartConfigProvider) that serves as
> a factory for MultiPartConfig instances. I declared the
> scope to be singleton because there only needs to be
> one of these things around.
>
> * Modifications to MultiPartReader to accept injection of the
> configuration parameter bean in the constructor:
>
> public MultiPartReader(@MultiPartConfigParam MultiPartConfig config) {
> this.config = config;
> }
>
> and modifications to call the getThresholdValue() method on
> the config bean when constructing a new BodyPartEntity
> (instead of the hard coded 4096 value).
>
> * Modified unit test (MultiPartReaderWriterTest) to declare this
> additional provider in the configuration of the Jersey client.
> (Side question -- why do I have to configure these at all?
> I'm trying to use the package resources scanner.)
>
> Things seem to work fine on the server side ... the new provider is
> recognized, and a proper injection takes place. But on the client
> side, it injects null (and therefore triggers NPEs in the tests that
> try to parse a multipart response in the client).
>
Paul's fixes this morning made injectable providers work for me on the
client side (thanks Paul!), so I've checked in the code that works as
described above. I also added support for the optional customization of
the buffer threshold value. Simply create a
"jersey-multipart-config.properties" file in your classpath (in a
webapp, put it in WEB-INF/classes), with contents like this:
bufferThreshold=1024
The mechanism is easily generalized if we need to add other parameters
later, by simply supporting them in the MultiPartConfig class which can
get injected wherever it is needed.
Next step for me is to look further into the HeaderValue idea discussed
earlier in this thread, to avoid the need for applications to parse
things like:
Content-Disposition: form-data; name="pics"; filename="file1.txt"
ourselves.
Craig