Re: JSR311: Re: ResponseBuilder

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Fri, 13 Jun 2008 09:45:37 -0400

On Jun 13, 2008, at 9:32 AM, Stephan Koops wrote:
> Marc Hadley schrieb:
>> Bill Burke wrote:
>>> type(MediaType)
>>> type(String)
>>> language(Locale)
>>> language(String)
>> +1 to having both variants.
> also +1
>> The issue, if I understood correctly, is what type to expect in a
>> message body writer if you get the value of a header from the
>> httpHeaders parameter.
> yes Marc, exactly.
> A problem is, that one resource method could give a String, but
> another method (perhaps in another class) could give a MediaType. So
> the message body writer must check if it is not null, must check the
> type and perhaps do a conversion. If the message body writer ever
> uses toString(), than you get a NPE, if the value isn't set.
> So you have to use the following code in the message body writer:
> MediaType mediaType;
> Object mt = httpHeaders.getFirst("Content-Type");
> if(mt == null)
> mediaType = null;
> else if (mt instanceof MediaType)
> mediaType = (MediaType)mt;
> else
> mediaType = MediaType.valueOf(mt.toString());
In the case of MediaType (likely the most common use case), the
writeTo method has a mediaType parameter anyway.

> This is a silly.
> It is nice, if I ever get the higher level object, but for pratical
> reasons, it could be good to return ever a String (or null). ->
> MultivaluedMap<String, String> httpHeaders. The back conversion
> could be done by the valueOf methods.

Using Object allows an application to set an arbitrary header using a
custom Java type, if we always convert to string then an application
supplied message body writer won't be able to take advantage of the
custom type without first reparsing the string representation.

I could go either way on this one, both alternatives has plusses and
minuses and its not clear to me that one is better than the other.

> BTW: What should a HeaderDelegate do with a given null (in
> valueOf(String) and in toString(T) )? It's not explicit defined in
> the javadoc. For this case it is useful to allow null and return
> null than, and not throw an IllegalArgumentException.
I don't like that, null should be an error IMO - you can't parse it
and you can't serialize it.


Marc Hadley <marc.hadley at>
CTO Office, Sun Microsystems.