users@jersey.java.net

Re: [Jersey] Proposed refinement to jersey-multipart header processing

From: Craig McClanahan <Craig.McClanahan_at_Sun.COM>
Date: Thu, 13 Nov 2008 10:53:34 -0800

Paul Sandoz wrote:
> Hi Craig,
>
> This looks good to me.
>
Cool ... committed (r1698).
> Slightly related. I think we can improve the HttpHeaders class to
> reuse stuff from the core rather than duplicating functionality. But
> to do that i need to provide a class such as
> KeyComparatorMultivaluedMap<K, V>, and then you can do:
>
> class HeadersMaps extends KeyComparatorMultivaluedMap<String,
> String> { ... }
>
> or just use an instance of KeyComparatorMultivaluedMap.
>
That would be nice. Last time I looked, core had both InboundHeaders
and OutboundHeaders, and neither did quite what I wanted since in
jersey-multipart the API is used in both directions. The BodyPart APIs
are just in terms of MultivaluedMap so we should be able to tweak
implementations under the covers without breaking any user applications.
> Paul.
Craig

>
> On Nov 12, 2008, at 2:36 AM, Craig McClanahan wrote:
>
>> A while back, Gili asked[1] about the possibility of enhancing the
>> jersey-multipart APIs to make it easier to deal with parameters. An
>> example of where this would be handy is a header like:
>>
>> Content-Type: application/xml; charset=UTF-8
>>
>> Currently, you can get "application/xml; charset=UTF-8" back as a
>> string by calling
>>
>> bodyPart.getHeaders().getFirst("Content-Type")
>>
>> but that leaves parsing out the parameter names and values as an
>> exercise left to the reader.
>>
>> Here is my proposal to enhance the current code to make things like
>> this easier to deal with. In the BodyPart class, add an *additional*
>> method with this signature:
>>
>> public MultivaluedMap<String,ParameterizedHeader>
>> getParameterizedHeaders()
>>
>> so that people who don't care about parameters can still use the
>> underlying string based headers -- plus, they don't have to pay the
>> parsing overhead unless they actually need it. This also avoids
>> breaking backwards compatibility for anyone currently using the
>> jersey-multipart code, since we're not changing any existing method
>> signatures. Given this call, you can do things like (assuming the
>> content type header is set as shown above):
>>
>> ParameterizedHeader header =
>> bodyPart.getParameterizedHeaders().getFirst("Content-Type");
>> String contentType = header.getValue(); // Returns "application/xml"
>> String charset = header.getParameters().get("charset"); // Returns
>> "UTF-8"
>>
>> Note that ParameterizedHeader is the class that Paul recently
>> refactored and created in jersey-core. It has *much* more robust
>> parsing than the HeaderValues class I was playing with, so we should
>> use ParameterizedHeader instead.
>>
>> I've got this implemented (with tests) locally, but wanted to get
>> some feedback before checking it in. What do you think?
>>
>> Craig
>>
>> [1]
>> http://n2.nabble.com/Hello-World!-and-Welcome-to-jersey-multipart-td1343189.html#a1452334
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>