Lifecycle support

[gissuebot]

From hani@formicary.net on March 14, 2007 09:22:31

Support for JSR-250 (javax.annotation) would also be very useful for all those people using init()
methods and the list.

The mapping I think is:

@PostConstruct -> Called right after construction
@Resource -> Analogous to @Inject
@PreDestroy -> No concept of destruction, is there?
@Generated -> Doesn't apply

Original issue: http://code.google.com/p/google-guice/issues/detail?id=62

[gissuebot]

From dhanji on March 14, 2007 16:36:02

Couldnt @Inject be made available on zero-arg methods (and invoked after all other
@Injects)? That would solve @PostConstruct

That being said, I feel that lifecycle methods are a legacy of setter-injection and
are superfluous in guice, especially as constructor injection is now on par with
spring-style setter injection (auto-wire with annotations).

It's also significant (different from guice) that @Resource (with no name=..)
connotes field names being used as ids. Should that be considered an implicit @Named?

[gissuebot]

From peter.royal@pobox.com on March 14, 2007 16:43:44

lifecycle (which is what this is) will certainly be needed. +1 to hani's JSR-250 suggestion.

(and its bogus to say that cxtor injection is now "on par" with setting injection. picocontainer has been doing
cxtor injection just as long as spring has been doing setter (trivial to tweak pico to use annotations). guice just
does it in a super-elegant and java5-friendly way)

[gissuebot]

From hani@formicary.net on March 14, 2007 17:39:38

Nooo!

@Inject on no-arg methods is a hack. Nothing is being injected, it'd be an abuse of the annotation.

I do think that @Resource should work the way it's supposed to too (via field name). Guice should be flexible
enough to be able to plug in different resolution mechanisms, and this is just one of them.

[gissuebot]

From dhanji on March 14, 2007 18:27:15

proper lifecycle is much more of an app-server/container issue. IMO I think lifecycle
is overkill (you can currently do it just fine with ctors and @Inject-ed methods).
just imho of course. =)

yes I am well aware pico did ctor injection long before anyone else, that's not what
I was referring to.

[gissuebot]

From dhanji on March 14, 2007 18:29:00

yea come to think @Inject on no arg was a terrible idea

[gissuebot]

From kevinb9n on March 15, 2007 07:55:42

I am also deeply suspicious of the entire idea of "initialization" as separate from
object construction. I think I'm lacking that great example that shows me why
construction is sometimes not enough.

That said, I can imagine some real value in an object being notified when its Scope
has let it go.  (Or, sometime after its Scope has let it go; and perhaps individual
Scopes themselves need the flexibility to govern how strong their guarantee is in
this regard.)  Some objects, while 'alive', consume resources. You might for example
need to close yourself some closeables.

I wonder if this could be accomplished by having Guice or the Scope detect that your
object implements Closeable.

Status: Accepted

[gissuebot]

From hani@formicary.net on March 15, 2007 07:58:59

Here's a very simple example.

You have field injection, and would like to do some init work.

You can't do it in the ctor since the fields can't be injected until after the ctor has run.

If you want concrete 'init' work, imagine I want to cache some data from an injected DataSource, if it's a field,
how would I do this caching?

[gissuebot]

From kevinb9n on March 15, 2007 11:04:51

Stock answer: then don't use field injection?  Now I need more meat to the example to
tell me why it has to be field injection. :)

[gissuebot]

From crazyboblee on March 15, 2007 14:03:26

I'm inclined to lean on garbage collection for finalization logic. Or to delegate
responsibility to something like OSGi.

We really need an external post-injection/pre-scoping hook. Then you could do
whatever you want in a generic fashion:

1. Call an init() method or some annotated method.
2. Create a phantom reference to an object so you can close its resources before
   garbage collection when the scope goes away.
3. Peform ad hoc injections. For example, Struts calls setters on interceptors with
   parameters from the config file.

Maybe something like this:

interface ProviderInterceptor<T> {
  T intercept(Key<T> key, Provider<T> next);  
}

Then you could apply them like this:

void bindInterceptor(Matcher<Key<...>> keyMatcher, ProviderInterceptor<...> interceptor);

[gissuebot]

From dhanji on March 15, 2007 17:45:01

Im with kevin--use ctor injection its safer (final publication), better (obvious to
non-guice factories) and has a tight contract (cannot partially inject a ctor like u
can with fields).

the only reason I use field inj is convenience/laziness.

gc is probably a different stage of the lifecycle than closing/shutting down--we have
no control over gc, but my canonical example is: a servlet container may conceivably
want to signal a close hook to its beans (perhaps to cleanup the session), i.e.
injector.close(), which would be totally different to when those beans actually get
finalize()-d.

That having been said I still think proper lifecycle should be managed by an
appserver. Pico does both but clearly states them as disparate features in the doc.

[gissuebot]

From crazyboblee on March 15, 2007 17:54:09

I think we need more use cases. I've never actually needed to run code when the
session ends. If I really need to do this, I can always use the servlet API directly.
Sometimes I wonder if other frameworks support lifecycle methods just because it's so
easy to do.

[gissuebot]

From dhanji on March 15, 2007 18:00:38

I suppose ctor injection would be out if you were "reinjecting" an object (with
injectMembers) and wanted to rerun the init--in that case you could still fall back
on a setter/psuedo-ctor without needing an independent "init" method.

[gissuebot]

From dhanji on March 15, 2007 18:05:21

You may want to release resources on hotdeploys (like datasources)--which REALLY
shouldnt count on the gc but yea I cant think of many use-cases outside of
appserver-style ones.

I dont really like the idea of lifecycle in DI anyway.

[gissuebot]

From james.strachan on March 16, 2007 00:04:08

Here's a use case.

Being able to DI any POJO developed for use in Spring or EJB3. There's a ton of code
out there which relies on the Spring IoC model (injecting optional properties then
having a validation step after injection to double check things are OK). Most
libraries I'm aware of (Jetty, ActiveMQ et al) all tend to have their own
initialisation hooks. Indeed I'm not aware of any IoC container apart from Guice
which does not support at the very least an initialisation callback mechanism.

If you're writing really simple POJOs which only have a set of mandatory
dependencies, then sure constructor injection avoids the need for an init step (as
the Pico folks promoted years ago).

However as soon as you have complex objects with multiple optional properties which
may or may not be set, some of which may be mutually exclusive and need some kind of
on-start validation, its much much cleaner to have a single well defined init method
called (where you can check all the various optional parameters are fine and do any
on-start-up caching & calculation etc).

The great thing about the init method is its called by the IoC container in context
immediately after injection; so if there are any configuration issues (mostly the
init callback is used to double check configuration when optional injections are used
after-all) then the IoC container is capable of giving a better error message as its
aware of the module/binder/injector being used. This avoids a runtime barf later on
when the injection context & information is lost.

[gissuebot]

From crazyboblee on March 16, 2007 08:23:24

Sorry, I meant use cases for the "tear down"/"stop" side of things.

The general ProviderInterceptor mechanism I suggested above should be able to support
any type of "init" design--calling a method on an interface, calling an annotated
method, running external logic, etc.