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:
>> https://jsr311.dev.java.net/issues/show_bug.cgi?id=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.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.