[ 
https://issues.apache.org/jira/browse/ONAMI-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13591796#comment-13591796
 ] 

Jordan Zimmerman commented on ONAMI-97:
---------------------------------------

Governator was created to solve a real-world problem we had at Netflix. 
Internally, there is a lot of code sharing at Netflix. This is done via Jars. 
By convention, the Jars have embedded property files and expose a common 
interface. Prior to Guice/Governator, clients of the Jars had to manually 
configure the libraries. Governator solved this by introducing lifecycle:

* Guice injects the library's interface implementation
* Governator loads the properties (@PreConfiguration)
* Governator assigns configuration values (@Configuration)
* Governator initializes the library (@PostConstruct)

This shows the post injection features of Governator that I'd like to add to 
Onami. After all objects' post injection completes, Governator also supports a 
WarmUp feature. Many of these libraries have things like caches, etc. that need 
to be warmed up before the object can be useful. Users of these libraries want 
to wait for warm up to complete. Additionally, most of the warmups can be done 
concurrently. In practice, this is very similar to Onami's Disposer container. 
It's a container of objects that have particular annotated methods. There is a 
special rule for how this container of objects should run. This is why I want 
to generalize Onami's Disposer functionality.

So, all of the features I'm proposing here are being used today at Netflix and 
a other companies that use Governator.
                
> 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

Reply via email to