Re: Parsing headers, was: Abstract from HTTP <was> Re: Welcome to JSR 311

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Wed, 11 Apr 2007 07:29:09 +0200

On Apr 11, 2007, at 12:15 AM, Dhanji R. Prasanna wrote:

> On 4/11/07, Paul Sandoz <> wrote:
> Dhanji R. Prasanna wrote:
> >
> > I dont think I get this--how would a parameterized List of MediaType
> > indicate to the runtime that index 0 is a component type
> > [foo/bar;ext="a,b"] and index 1 is [text/plain].
> > I think Im missing something basic here...
> >
> Because:
> 1) the runtime knows the Accept header value can be a comma separated
> list of media type values; and
> I thought Julian's point was that knowing it's a comma separated
> list is not enough? That a separate component-specific parser must
> be installed by the user--or is this what you mean by the runtime
> knowing? If so that makes sense...

Yes, which is the second point.

> 2) either MediaType or the runtime, via the knowledge of the MediaType
> class, knows how to parse a media type as specified by the HTTP
> grammar.
> Yea this I saw in the javadoc, which I think is a very good idea. I
> like the use of the static factory "valueOf" too--also, mightn't it
> be prudent to annotate the factory rather than relying on a naming
> convention (same applies for the ctor)?
> That will make it explicit, type-safe and self-documented, in the
> case where it's a user-provided class:
> @HeaderProducer(Headers.ACCEPT)
> public static MyClass valueOf(String header) { .. }

How can one annotate Integer/BigInteger/Decimal/URI/URL? or other
classes that cannot be modified?

The same well-known conventions are used for Query/Matrix/UriParam.
IMHO such annotations just create unnecessary additional work for the
developer i.e. the existing information obtained via Java reflection
is sufficient.