On 4/13/07, Jerome Louvel <jerome.louvel_at_noelios.com> wrote:
>
>
> Dhanji,
>
> Should I understand that JSR-220 prevents the usage of other annotations,
> or
> even mandates the usage of JWS API. Could I say that my EJB session isn't
> supporting the JWS API but instead uses JSR-311 API?
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).
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).
>
> 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.
Dhanji.