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 <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> 2016-02-05 15:24 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; : > 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. >

Le mar. 16 févr. 2016 à 11:25, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; a écrit : > Hey guys, > > thinking more to it here few more remarks/requests: > > - as an extension writer think having an explicit build is better than an > implicit one in particular when you manage several built instances. The > fact it is sometimes implicit sometimes explicit has these drawbacks: > -- API starts to be huge for a poor gain > +1 > -- you actually don't know what is done more easily if not inline (which > is likely the case for medium/advanced extensions) > +1, I think we should remove this notion on Configurator I intoduced, the question ius do we keep specific SPI method returning a builder to be build in a DSL way or not > - why having Builders class with static methods where we could use the > bean manager as entry point for them. Would be more natural since the BM > already build some instance like AT and easier to find in the IDE and look > less magic. > -1 BM is already bloated with a zillion of methods and as discussed somewhere else some builders (mainly ATB) could be useful from outside CDI, especially in SE to prepare config before starting the container.

-- bonus on this one: would also bind the calls to a CDI context which > makes things easier to track and if we speak later of multiple contexts in > the same classloader we wouldn't be broken > Remember that built meta-data are mainly used during container bootstrap where context are not active... So I'm not sure to get the interest of this idea.

Antoine > > > wdyt? > > > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Tomitriber > <http://www.tomitribe.com> > > 2016-02-05 16:01 GMT+01:00 Romain Manni-Bucau <rmannibucau(a)gmail.com&gt;: > >> 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 <https://twitter.com/rmannibucau> | Blog >> <http://rmannibucau.wordpress.com> | Github >> <https://github.com/rmannibucau> | LinkedIn >> <https://www.linkedin.com/in/rmannibucau> | Tomitriber >> <http://www.tomitribe.com> >> >> 2016-02-05 15:24 GMT+01:00 Antoine Sabot-Durand < >> antoine(a)sabot-durand.net&gt;: >> >>> 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. >>> >> >> >