Re: Lifecycle options

From: Dhanji R. Prasanna <>
Date: Tue, 10 Jul 2007 22:22:04 +1000

On 7/10/07, Paul Sandoz <> wrote:
> Dhanji R. Prasanna wrote:
> >
> > //this factory is semantically a singleton provider but JaxRs knows
> > nothing about scope nor forces a developer to learn a new IoC profile
> > public class PersonFactory implements ObjectProvider<PersonResource> {
> > private final PersonResource res = new PersonResource(...);
> >
> > public PersonResource get() {
> > return res;
> > }
> > }
> >
> What instantiates the factory? What is the scope of the factory? Is
> there only one instance of the factory per Web application or per JVM?
> It seems at least for a common case that you have made the developer do
> more work.

Yea this was only a trivial example off the top of my head, as I said. The
general ResourceFactory/Resolver interface whose specific implementation(s)
can be registered to the runtime at bootstrap (upto the impl how--like via a
config option). Then you can register a Jsf2ResourceResolver for example,
which is given a key (.class) and must resolve an instance of it to whatever
scope and creation semantics it engenders.

We can provide a standard one of these ResourceResolvers out-of-the-box.

But yet this approach can overcome the restriction you pointed out when
> using an empty constructor,

Yes particularly if using an external resolver such as Jsf2's, EE or even
spring's ioc container. No primary restrictions need be made on Resource

> > Now it is easy to conceive of:
> >
> > @URITemplate("/person/{id}")
> > @ProvidedBy(SpringPersonFactory.class)
> > public class PersonResource {
> >
> > //http methods and so on...
> > }
> >
> > Or perhaps a general ResourceFactory that can be implemented to hook
> > into spring.
> >
> BTW in the original API/SPI we had a resolver SPI that allows pluggable
> container-based resolving according to scope e.g. i implemented HTTP
> session scope as a test using a proprietary annotation on a root
> resource class. (However, i do not think we should encourage the use of
> session scope since it breaks an important constraint in REST.)

Yea that is a good point, I agree session-scoping is not a great idea.
However (as an aside) I think it's a losing battle we will be fighting in
the real world =)

JAX-WS impl supports pluggable scope by use of a meta-annotation [1].
> > I'll post a more detailed example on why we should let spring (or
> > <insert_ioc_flavor_of_month>) create these objects in the 3rd party
> > containers thread.
> >
> OK. I don't disagree with you on letting spring etc create instances.
> But i am not sure we have to do anything in 311 and it could be left up
> to 311 implementations to decide how best to integrate with Spring,
> given that Spring is not part of EE.

Im suggesting that we dont mandate our own invented superset of an IoC
profile (with scopes, injectors, and restrictions like nullary ctors,
etc.,), and instead allow this to be made more transparent. Spring is only
one example I gave. The more immediate one is Jsf2 which has stated on its
proposal (and several of my colleagues in the EG have echoed) that alignment
with Jsr311 is a core goal. The EE5 container itself provides injection
semantics (cf. @Resource annotation). This is something that I hope we will
improve on in EE6 (current restrictions on JNDI lookup etc.). Servlet3.0 is
another one.

In that light I feel each component API (jsr311 particularly) of the EE
platform should try to take cognizance of where it can more easily fit into
what is now a dominant idiom (ioc) rather than attempt to define a prodigal
contract that will need to be retrofitted into even the standard
specification. I cite a real world example: the ugliness of where JPA honors
limited forms of injection in SE environments and how this is inconsistent
with its EJB (and general) contract. Even though, in that particular case,
it relies on JEE5 annotations.

Another one: JSF1's ioc container is unable to hook into the EJB3 injection
contract and has (in part) prompted the rise of libraries like Jboss Seam
and its inspired JSR Web Beans (299).

As to being cognizant of spring (among others), I believe that even
disregarding its widespread use, it influences JEE enough that its idioms
are worth considering (they eventually make their way into the EE standard).
I think all this is a solid enough argument without me bringing up aop or
method security as a use case.