dev@jsr311.java.net

Re: API feedback

From: Dhanji R. Prasanna <dhanji_at_gmail.com>
Date: Thu, 12 Jul 2007 08:37:31 +1000

On 7/12/07, Marc Hadley <Marc.Hadley_at_sun.com> wrote:
>
> Paul and I presented the current API to a group of Sun folks
> including specification leads for other technologies in Java EE. We
> received some useful feedback that I'd like to share and get your
> thoughts on:
>
> - Consider use of @Resource instead of @HttpContext. The @Resource
> annotation defined by JSR 250 (part of EE 5) is designed as a generic
> solution to the problem that @HttpContext solves. A downside is that
> @Resource cannot be used on method parameters so UriInfo, HttpHeaders
> and PreconditionEvaluator couldn't be used as parameters as is
> currently the case.


This is something I brought up very early on but would tend to discourage as
we cannot provide a coherent implementation of @Resource without confusing
the hell out of developers working in SE environments or (future) EE
profiles that are not of the "kitchen sink" ilk.
It may be worthwhile to support it as an "also possible" in certain EE
profiles (enabled with jndi registries).

- Consider adding a set of static methods to Response for common use
> cases. These would defer to the full Response.Builder.xxx.build()
> method. This is mainly a convenience thing to cut down the amount of
> code required to create a common response.


+1

- Resource injection needs to happen in one place. JAX-RS, Servlet,
> JSF, JAX-WS, WebBeans, Persistence, EJB, ... all perform resource
> injection and its possible to mix annotations from multiple
> technologies in a single class. It would be useful to have some
> common infrastructure across EE for performing the injection, perhaps
> coupled with infrastructure for instance creation and management.


Aha! This is what Ive been trying to say, somewhat less than eloquently
(apparently!) in other threads of late. I think this needs careful
consideration and leadership from either JSF2 and Web beans as their IoC
concerns will be the most robust and wide-ranging. We would also need
careful coordination with the Umbrella EE JSR to make everything happen.

This topic is of particular interest to me so Im willing to pursue it with
those other JSRs over the next few weeks and coordinate a bit with our own
needs.

- Consider supporting the standard security annotations defined by
> JSR 250 and examine JSRs 196 and 115. JSR 196 offers support for
> pluggable authentication and JSR 115 for authorization. JSR 115 may
> need a revision to accommodate the more flexible URI patterns
> supported by @UriTemplate.


javax.interceptor is also a possible candidate (perhaps best done via
external instance creation, cf. 3rd party containers thread).

The feedback you've received is excellent, I commend you guys for taking the
initiative--we could perhaps do something similar with the open community at
a later stage?

Dhanji.