Lifecycle support

[GoogleCodeExporter]

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 reported on code.google.com by h...@formicary.net on 14 Mar 2007 at 1:22

[GoogleCodeExporter]

When you folks create features out of this request, please enable me to do 
custom initialization.

I have always ended up in needing several initialization phases, not only a 
single @PostConstruct.

What I've needed, is at least a "now you've got all your dependencies and 
configuration, do your init code", and then a "now you can do listener 
registration with each other".

So my ideal solution to this is to get a list (preferably in instantiation 
order) so that I can invoke my different init methods on the relevant objects. 
This could be fetched by user code when the injector was finished setting up 
the entire graph (and have invoked @PostConstruct?) - and then the user could 
would do what life cycling it needs to do.

What I currently do, is to have a LifeCycle service which instances can depend 
on. There is also the LifeCycled interface. The objects register with the 
LifeCycle service, either in constructor (which is bad according to JCIP), or 
in the method injecting the LifeCycle service (better). After injector is 
finished, I run through all the instances that have registered with the 
LifeCycle service, all of which shall implement the LifeCycled interface. I 
then invoke method "phase1" on all objects, then method "phase2" on all 
objects, etc. (On application shutdown, I have corresponding phase-destroy 
methods on the LifeCycled interface, which are invoked in the opposite order).

Original comment by endre.st...@gmail.com on 15 Mar 2012 at 3:12

[GoogleCodeExporter]

It would be nice to see some help in Guice to build a service framework but it 
isn't needed, since startup order of services could be possibly different from 
injection dependecy order.

In my framework I made it something like Bob meantioned. I used an the 
InjectionListenr / ProvisionListener to collect services implementing the 
frameworks service interface and after injection finished the frameworks 
ServiceManager collects and orders the services startup dependencies, searches 
for postConstruct() handlers and finally calls the startup() method of every 
service.
When the framework is shutting down first all services preDestroy() method is 
called and finally the destroy() method.
Right after that point the ServiceManager and the Injector are destroyed.

It was a bit tricky at some small points but that is more a problem of the 
framework, which can be sticked together from plugins (all have their own 
AbstractModule) and a plugin descriptor, not a Guice problem.

Original comment by noctariushtc@googlemail.com on 15 Mar 2012 at 5:17