Dhanji,
> It doesnt forbid annotations as such, but the ejb container
> specification (i.e. spec on how to implement JSR-220) does
> speak about what an EJB should be and what it *should*
> support, i.e. JAX-WS services via WSDL--"simplified" support.
> If the container does not support jsr311 annotations
> (obviously none do), you cant deploy a session EJB as a
> jsr311 end point. This is also true for JPA entities managed
> within the EJB container (as opposed to a JSE-deployed JPA provider).
Agreed. Thanks for clarifying this.
> You can kludge your way around this using interception
> (javax.interceptor) but this is not ideal and certainly on
> par with JWS support. A better solution would be proposing an
> extension to JSR-220 when we're ready. This will probably be
> painful as EJB is a very slow-moving framework with a lot of
> flow-on impact. Most app servers still lack a compliant,
> production-worthy EJB3 container and JSR-220 has been final
> for some time now (as has JEE 5).
OK.
> This is a matter of taste mostly. Here are my preferences:
> 1) @Resource -> conflict with common JEE annotation
> 2) @WebResource -> potential conflict with JWS API
> 3) @RwsResource (clearer than @RWSResource)
> 4) @RsResource (clearer than @RSResource)
> 5) @HttpResource -> too HTTP-centric
>
> @RsResource would be my choice (assuming the api title is
> locked in as "rs").
> Im against @WebMethod, @WebResource and plain @Resource or
> @Method (yuck!), not just because they may conflict but also
> because they are non-specific.
I understand your point of view. Personnaly, I'm considering REST/HTTP as
the de facto architecture style/procol of the Web, so prefixing annotations
with "Web" seems fine and specific enough. If you also take the package name
into account, @javax.rws.Resource would be even better for me, despite the
name conflict with JEE's @Resource annotation.
Best regards,
Jerome