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

Mikhail Mazursky commented on ONAMI-97:
---------------------------------------

> In Java, you don't want to do much work in the constructor. Just allocating 
> an object is not enough to make the object useful. In SOA, service-type 
> objects generally need to load resources, register with other services, etc. 
> This is why we need @PostConstruct.

I think "register with other services" is not a responsibility of the object 
itself, but of it's creator (inversion of control). But i see now what it can 
be used for. I'm +1 on the idea.

Haven't reviewed patch very thoroughly but here are some minor things about it:
- registration is done with "stageables.offer( stageable );" - i think it's 
better to use add() method to provide more explicit semantics. offer() adds 
optionally (if enough space), add() adds always. Queue is backed by LinkedList 
and it will always add element so it's easier to follow simple add();
- it's cleaner to use switch in DefaultStager constructor with default option 
that should throw AssertionError();
- i think it's better to avoid holding any locks while calling .stage( 
stageHandler ) in DefaultStager.stage(). The method may block on other thread 
and those thread can block on stager's register() method. This will result in 
deadlock;
- i suppose DefaultStager was meant to have protected constructor?

As a whole i like the patch, thanks! =)
                
> Refactoring/generalization of Onami LifeCycle.
> ----------------------------------------------
>
>                 Key: ONAMI-97
>                 URL: https://issues.apache.org/jira/browse/ONAMI-97
>             Project: Apache Onami
>          Issue Type: Improvement
>          Components: lifecycle
>            Reporter: Jordan Zimmerman
>            Assignee: Jordan Zimmerman
>         Attachments: lifecycle.zip, ONAMI-97.patch
>
>
> 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