Why not making all Annotated* mutable during boot lifecycle?
Would allow to get rid of the annotated root in the modification code, for
instance we could convert:
type.getMethods().stream().filter(m ->
m.isAnnotationPresent(Foo.class)).forEach(m
->event.setAnnotatedType().addToMethod(m, MyInterceptor.BINDING));
to
type.getMethods().stream().filter(m ->
m.isAnnotationPresent(Foo.class)).forEach(m ->
m.mutate().add(MyInterceptor.BINDING));
or if we don't want to add mutate in the existing types we could use
configurator as root for type type and recreate a Configurator graph
matching annotated graph.
Advatage is first code i a bit awkward in the sense you can call
setAnnotatedType() multiple type (what would happen? only last modification
will be saved? or you have to keep a reference to the configurator once
called which breaks the fluent API provded by streams IMO.
wdyt?
Romain Manni-Bucau
@rmannibucau <
2016-02-05 15:24 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net>:
Hi all,
Following discussion during last meeting, I rewrote most of my PR for
builders.
We now have 2 clean and distinct ways of using them
1) in DSL style (with a Configurator interface without build() method)
public void processAT(@Observes ProcessAnnotatedType<?> pat) {
pat.setAnnotatedType().read(pat.getAnnotatedType()).addToType(new
AnnotationLiteral<MyInterceptor>() {};);
}
2) In classical reusable builder mode (builders extends configurator and
only add build() method)
public void processAT(@Observes ProcessAnnotatedType<?> pat) {
AnnotatedTypeBuilder atb = Builders.annotatedTypeBuilder();
atb.read(pat.getAnnotatedType()).addToType(new
AnnotationLiteral<MyInterceptor>() {};);
pat.setAnnotatedType(atb.build());
}
As Configurators don't have build() method there's no risk that users mix
them with standard builders.
For clarity sake, builders are no more available in lifecycle event but in
Builders class for consistency.
I'm quite happy with the result, but I'm sure you'll have comment ;). So
thanks for your feedback
https://github.com/cdi-spec/cdi/pull/270
Antoine
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the
code under the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
provided on this list, the provider waives all patent and other
intellectual property rights inherent in such information.