Re: JSR311: Draft of 1.1 Maintenance Release for review

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Fri, 30 Jan 2009 13:57:29 -0500

On Jan 27, 2009, at 4:58 PM, Bill Burke wrote:
> Marc Hadley wrote:
>> On Jan 27, 2009, at 10:33 AM, Bill Burke wrote:
>>> Initial Comments:
>>> * EJB Singletons should be a required integration point as well.
>>> Resources need to be able to hold state sometimes.
>> It that still a requirement with JSR 299 (the spec formally know as
>> WebBeans) in the picture. Wouldn't that enable this anyway ?
> I don't know. Does JSR 299 still say EJBs are Web Beans? I think
> its safer to require EJB Singletons explicitly in the text.
Done in latest version. I also made it more explicit about what kind
of EJB can be used for what (resource, provider) and what scope JSR
299 beans can be used for what.

>>> * @OPTIONS should be added as an http method with a default
>>> behavior defined.
>> You are the second person to request that, see issue 67:
>> I recall that we didn't add a @OPTIONS in the first place as we
>> thought it wouldn't be used much but I can't see any harm in adding
>> it other than cluttering the API a bit. Anyone opposed to adding
>> it ? Either way I think we should avoid adding @TRACE or @CONNECT.
> What about PATCH, MERGE, WebDav? Does it really hurt to add these
> too? Only thing I can think of is that the introduced methods might
> have some default response code semantics that are different than
> other HTTP methods.
> PATCH seems to be gaining momentum and I'd hate for all of us JAX-RS
> guys to have our own @PATCH, or worse, each application have its own
> version of @PATCH.
We made it extensible so anyone could add new methods, I don't see the
need to define annotations in the JAX-RS packages for every
conceivable method. A better solution IMO would be to have some kind
of JAX-RS commons project where implementation-agnostic stuff like
this could live.


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