Re: Lifecycle options

From: Dhanji R. Prasanna <>
Date: Tue, 10 Jul 2007 20:05:08 +1000

On 7/10/07, Marc Hadley <> wrote:
> We decided that the default lifecycle for a resource class would be
> per-request but didn't rule out others. Another obvious candidate is
> a per-application singleton and, while its possible for resource
> class methods to defer to an application-managed singleton, I think
> it would be worth going the extra-mile to offer that option in the
> API. I propose to add a @Scope annotation as follows:
> @Target({ElementType.TYPE})
> public @interface Scope {
> public enum Lifecycle {REQUEST, APPLICATION};
> public Lifecycle value() default Lifecycle.REQUEST;
> }

Hmm. a couple of issues:

- scoping and lifecycle have very different connotations wrt to DI
containers, a scope is a period of validity (an umbrella of time over the
instance). Lifecycle connotes specific events in the life (and role) of the
object, such as init, destroy, pause, etc... and is thus specific to a use
case/deployment env.
- this sorta leads back to my other post regarding 3rd party containers.
springframework, guice, pico et al, provide very robust scoping and
lifecycle support (spring + webflow provides 7 disparate layerable scopes).
Scoping is trivially extensible in all three of those containers to
arbitrary semantics (Disk scope? cluster scope?).
- Faces2.0 is pushing strongly (I'm doing the pushing =) toward a variety of
scopes and a fairly sophisticated DI container of its own. There are vocal
opinions about exposing JaxRs resources via JSF2.
- JSR-220/EJB3 provides its own limited IoC in collaboration with the JEE5
- JSR-315/Servlet 3.0 will have a much more full featured IoC container than
2.5 currently does, including sophisticated support for things like scope
and lifecycle.

Considering all this, I strongly think we should be wary of reinventing the
proverbial wheel and try to make this a user-managed idiom--where a user can
choose to rely on spring etc. Or register a "scoping" factory of their own
that simply provides an instance from their own strategy. We can provide
canned cases for request and singleton scoping factories.

I'll post some more thoughts on my 3rd party containers thread if that