On Jul 11, 2007, at 6:37 PM, Dhanji R. Prasanna wrote:
> - 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).
>
I note that @Resource is included in SE 6, is your concern that
@Resource will only work with certain types in certain contexts/
profiles ? If so I think we can counter that problem by being very
clear about what is guaranteed to work where.
> - 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.
>
FWIW, I think JAX-RS has the same need for robust and wide-ranging
IoC. The key thing (IMO) is to have some consistency across the
platform specs. E.g. it seems reasonable for a JAX-RS resource class
to be able to benefit from injection of Java persistence artifacts,
EJB references etc.
> 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).
>
Yes, that's another thing we should consider.
> 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?
>
Sounds good, perhaps around the time we publish an early review
draft. That would be a good opportunity to get feedback.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.