Further to what Daniel is saying. I can think of other uses of stages. One could create a validation stage that could be executed multiple times throughout the run of an application. The app can get the injected Stage<Validate> instance and run it periodically.
-JZ On Mar 3, 2013, at 2:56 AM, Daniel Manzke <daniel.man...@googlemail.com> wrote: > 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
