[
https://issues.apache.org/jira/browse/ONAMI-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14043364#comment-14043364
]
Simone Tripodi commented on ONAMI-102:
--------------------------------------
[~ash2k] that's pretty amazing, thanks also for taking care of JVM backward
compatibility!
Just a minor observation: I just wonder if we could expose even more DSL APIs
to reduce the boilerplate code in the {{configureBindings()}} modules,
something like:
{code}
@Override
protected void configureBindings() {
bindStager(new TypeLiteral<AdvancedStager<PreDestroy>>() {})
.to(new DefaultAdvancedStager<PreDestroy>(PreDestroy.class,
DefaultStager.Order.FIRST_IN_LAST_OUT))
.matching(new AbstractMatcher<TypeLiteral<?>>() {
@Override
public boolean matches(TypeLiteral<?> typeLiteral) {
Package pkg =
typeLiteral.getRawType().getPackage();
return pkg != null &&
pkg.getName().startsWith("com.my.project.");
}
});
}
{code}
It should simplify the binding in one simple sentence, rather than two, and
doing the "magic" under the hood. WDYT?
Thanks *a lot* for your hard work and looking forward to see the code
committed! :)
> 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)
