[
https://issues.apache.org/jira/browse/ONAMI-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14043420#comment-14043420
]
Mikhail Mazursky commented on ONAMI-102:
----------------------------------------
[~simone.tripodi], in example you provided it is not possible to get the
{{DefaultAdvancedStager}} instance BEFORE {{Guice.createInjector()}} call
because it does not exist. So it will not be possible to apply a usage pattern
like in my comment #4. Maybe there is some way to make it all a little bit more
beautiful but... no ideas so far.
I think we can include Jsr250Destroy and Jsr250Construct modules as part of
Onami Lifecycle and that will cover most usage scenarios, hide this boilerplate
and will not prevent anyone from writing modules for other lifecycles.
WDYT?
p.s. Thanks for kind words, I appreciate that!
> Redesign the Modules structure in order to simply APIs usage
> ------------------------------------------------------------
>
> Key: ONAMI-102
> URL: https://issues.apache.org/jira/browse/ONAMI-102
> Project: Apache Onami
> Issue Type: Improvement
> Components: lifecycle
> Affects Versions: lifecycle-0.2.0
> Reporter: Simone Tripodi
> Assignee: Mikhail Mazursky
> Fix For: lifecycle-0.2.0
>
> Attachments: LifeCycleModule.java, LifeCycleStageModule.java
>
>
> We already started discussing about it in the ML, but let's track progresses
> on JIRA.
> I detected few areas of approaching the lifecycle design:
> * IIUC, we want to manage a series of annotations which identify the
> sequence of staging steps in the lifecycle, so IMHO the
> AbstractLifeCycleModule constructor with just one annotation has to
> disappear; it would be nice to have a varargs array, which would simplify the
> signature - and the usage from our users - but it would generate an annoying
> warning to our users; IMHO it is still acceptable, but in case we don't find
> an agreement here, Iterable should be the best way to pass the annotations
> sequence to the module.
> * ListBuilder: as already discussed, this sound too generic: I'd propose
> something like AnnotationsLifecycleSequenceBuilder (maybe it is too verbose
> :P) but I'd opt for something that gives a precise idea, not a generic one;
> * Again on the list builder, as we discussed, IMHO the wrapped data
> structure should be a LinkedHashSet: it preserves the sequence and makes
> efficient the check for duplicates - if the list has a duplicate, I bet the
> lifecycle event would be handled twice;
> * Builder pattern: the way to get the builder is IMHO a little too verbose:
> Builder.newBuilder() is not a pattern that makes me particularly happy, I'd
> rather opt for inner class builder such as {{new ConcreteClass.Builder()}}
> which is used in the AsyncHttpClient - WDYT?
> I can even make a proposal, in order to show you better my ideas, and attach
> a patch to discuss together
--
This message was sent by Atlassian JIRA
(v6.2#6252)
