I think I understand what Jordan tries to solve. I had a similar problem in Autobind.
In my projects I often have stages where I have to make sure that objects are initialized in the right order. For example in Autobind a configuration be loaded and afterwards injected, which is used in the next stage, where modules are going to bind something. For example I don't want to have each module to load the configuration by itself. For example binding a specific implementation based on the decision of a customer. In the module itself I want to use @Inject for configuration binding. Due to the fact that I'm scanning the classpath, I need a way to specify when each class has to be bound. The staging implemented by Jordan would also allow to know what is missing. If your application is not starting and you have 100's of guice problems, you often don't know where to start. In most cases only a little configuration was missing. With staging you are able to determine the real phase and problem what caused the issue. Bye, Daniel 2013/3/3 Simone Tripodi (JIRA) <j...@apache.org> > > [ > https://issues.apache.org/jira/browse/ONAMI-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13591690#comment-13591690] > > Simone Tripodi commented on ONAMI-97: > ------------------------------------- > > Hi Jordan, > > I haven't had a look at the zip package yet but I am curious to see which > are the reasons behind handling more events, in order to provide to the > injectee more entry points - with "plain-old" Guice we should be already > able to handle all injection situations, but I could have missed something. > > Many thanks in advance! > > > > Refactoring/generalization of Onami LifeCycle. > > ---------------------------------------------- > > > > Key: ONAMI-97 > > URL: https://issues.apache.org/jira/browse/ONAMI-97 > > Project: Apache Onami > > Issue Type: Brainstorming > > Components: lifecycle > > Reporter: Jordan Zimmerman > > Attachments: lifecycle.zip > > > > > > Currently, Onami LifeCycle supports multiple post injection annotations > that are > > invoked after instantiated by Guice. It also supports a Dispose > container that > > holds references to injected objects whereby annotated methods will be > invoked > > in reverse injection order when the user calls a container method. > > I'd like to generalize both post injection and container to support > > more open-ended features. The features are being driven by functionality > in Governator. > > For post injection, Governator supports ordering of annotations. i.e. > @PreConfiguration > > methods are invoked before @PostConstruct methods. For the life cycle > container, > > Governator supports a @Warmup annotation and others. @Warmup methods are > invoked by user > > direction after the Guice Injector has been created. > > The change to post injection is straightforward. Instead of specifying a > single post > > injection annotation, an ordered list of annotations is specified. The > Guice > > injection listener is modified to iterate over the annotation list in > order looking > > for matching methods. > > The change to the life cycle container is more involved. For clarity, > the various classes > > and methods are renamed from "Dispose*" to "Stage*". The DefaultStager > (formerly DefaultDisposer) > > takes a new argument that determines if objects are processed > first-in-first-out or > > first-in-last-out. The Stager interface is now parameterized with the > Annotation > > that represents the "stage". The LifeCycleStageModule now binds with its > parameterized > > annotation so that Stagers of each stage type can be injected. i.e. > > @Inject > > public Foo( Stager<Dispose> disposer ) > > > > ... > > @Inject > > public Bar( Stager<Warmup> warmups ) > > > > Obviously this is a very big change. My goal is to enhance Onami > Lifecycle so that I > > can use it in Governator. I've enclosed the implementation as a zip file > instead of a > > patch to make things easier to look at. > > I look forward to discussion/ideas on this! > > -- > This message is automatically generated by JIRA. > If you think it was sent incorrectly, please contact your JIRA > administrators > For more information on JIRA, see: http://www.atlassian.com/software/jira > -- Viele Grüße/Best Regards Daniel Manzke
