[cdi-dev] New builders API

Tue May 3 10:28:03 EDT 2016

Thanks Antonin, for your feedback.

Camel CDI is a good example to test this new API. Would you be ok to set up
a meeting IRL to work on these points with your framework ?

Antoine

Le mar. 3 mai 2016 à 15:48, Antonin Stefanutti <antonin at stefanutti.fr> a
écrit :

> Hi All,
>
> Not sure what’s the best form to share my feedback, so here it is :)
>
> I’ve tested CDI 2.0.Alpha4 / Weld 3.0.0.Alpha3 and the new "builder API"
> on the Camel CDI extension and here are the points I’ve had gathered:
>
> - There is a read(AnnotatedType<U> type) API: equivalent API for
> AnnotatedField and AnnotatedMethod would be useful
> - Having the ability to customise the toString method by providing a
> Supplier<String> would be useful
> - There are API (createWith, produceWith, ...) that are basically the
> decomposition of what an injection target is: in the Camel CDI use case,
> It’d be useful to be able to reuse some InjectionTarget that are used for
> discovered beans as well directly instead of having to call instantiate the
> injection target and call produceWith and destroyWith separately
> - I found a bit cumbersome to work with addObserverMethod: as the type
> parameter is not driven by the observedType, generics hiccups come into
> play with the notifyWith API. In my example, I had to rely on an extra
> method to have the type parameter provided:
> https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L263-L271
>
> Unfortunately, I haven’t been able to get rid of the boilerplate code
> (like SyntheticBean [1], SyntheticBeanAttributes [2],
> SyntheticInjectionTarget [3]) that the new builder API would have permitted
> to eliminate. Indeed, while the "Metadata configuration API" probably
> solves the majority / simplest use cases, it does not address the one in
> Camel CDI (as already illustrated by John and I from different angles).
>
> IMO, it’d be worth investigating on an unified Builder and configurator
> API bringing the best of both worlds.
>
> The rewrite of Camel CDI on CDI 2.0 is available here:
> https://github.com/astefanutti/camel-cdi/commits/cdi-2.0.
>
> [1]:
> https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/SyntheticBean.java#L34
> [2]:
> https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/SyntheticBeanAttributes.java#L31
> [3]:
> https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/SyntheticInjectionTarget.java#L29
>
> Antonin
>
> > On 03 May 2016, at 15:14, Antoine Sabot-Durand <antoine at sabot-durand.net>
> wrote:
> >
> > Thanks for all the feedback on the API.
> >
> > Before going into detail I wanted to put the accent on the Weld
> 3.0.Alpha16 release post[1] which give a good explanation regarding this
> API. Its the best starting point to discover this new API IMO. Thanks
> Martin, Tomas and Matej for this release.
> >
> > @John. The debate Configurator vs Builder is still open. At the moment
> we focused on configurator since they are easier to limit to a given
> container lifecycle, but having builders to reuse the configuration could
> make sense as well. AnnotatedType is a special case since it could make
> sense to use it at runtime (to ease creation of an InjectionTarget for
> instance, so perhaps it will require a Builder.
> > If we keep the API in this spirit for the release, it should be better
> to talk about Configurator API vs Builder API to avoid confusion for
> missing build() methods ;)
> >
> > @Antonin the enhancement you propose is very interesting but as Martin
> said we could imagine a solution to load an existing bean after decision on
> the API (a mute(Bean) method in ABD perhaps).
> >
> > For me the goal is to decide if we are on the right path and avoid
> decision that will prevent future enhancement. I think having this API
> perfect and complete in one PR is almost impossible. So we should validate
> something to move on missing features or enhancements.
> >
> > Antoine
> >
> > [1] http://weld.cdi-spec.org/news/2016/04/28/weld-300Alpha16/
> >
> > Le jeu. 28 avr. 2016 à 10:43, Martin Kouba <mkouba at redhat.com> a écrit :
> > Hi all,
> >
> > we've just released Weld 3.0.0.Alpha16. So anyone can start playing with
> > the API, discover possibilities and find potential issues:
> >
> > http://weld.cdi-spec.org/news/2016/04/28/weld-300Alpha16/
> >
> > Any feedback is appreciated!
> >
> > Martin
> >
> > Dne 25.4.2016 v 09:30 Martin Kouba napsal(a):
> > > Hi all,
> > >
> > > me and Matej, we've already tried to explain some points in
> cdi/pull/287
> > > discussion. Anyway, we're going to release Weld 3.0.0.Alpha16 (base on
> > > 2.0.Alpha4) later this week so that everyone can start playing with the
> > > new API. And we'd like to prepare some simple examples to help people
> > > get started as well.
> > >
> > > Martin
> > >
> > >
> > > Dne 23.4.2016 v 12:56 John D. Ament napsal(a):
> > >> Hey guys
> > >>
> > >> Based on the last f2f I was in, I took an action item to look at how
> > >> applications can leverage the new builder methods/classes from this
> PR:
> > >> https://github.com/cdi-spec/cdi/pull/287
> > >>
> > >> To do this, I took some existing OSS CDI extensions and converted
> parts
> > >> to use the new APIs instead of the old ones.
> > >>
> > >> The results were iffy to be honest.  Here's some of the key issues I
> > >> noticed:
> > >>
> > >> - AfterBeanDiscovery#addBean - vs AfterBeanDiscovery.addBean(Bean<?>
> bean)
> > >> In the latter, it's clearer to a developer which attributes are
> required
> > >> vs optional.  Builders typically use sensible defaults.  Maybe that
> was
> > >> the intention here, but I couldn't really get that sense when
> converting
> > >> over.  It also wasn't clear what to do when done.  I suspect I just
> > >> leave it, but without some kind of closing "build()" or "done()"
> method,
> > >> it becomes ambiguous.
> > >>
> > >> - Annotated*Configurator
> > >> TBH, I have no idea what I was configuring in this one at the first
> > >> pass.  I started with a method.  I wanted to replace the method's
> > >> annotations.  It seemed like I could set that up using the
> configurator,
> > >> but I ended up having to do setAnnotated at the end anyways, so I'm
> not
> > >> sure what the configurator bought me.
> > >>
> > >> The one nice thing I saw was the simpler to use lambda functions.
> Being
> > >> able to stream through things like annotated method made the code much
> > >> cleaner.
> > >>
> > >> For the open source code, I'll try to get some gists together that
> show
> > >> the changes.  Maybe there's something I'm missing, so wouldn't mind a
> > >> second set of eyes on the changes to see.
> > >>
> > >> John
> > >>
> > >>
> > >> _______________________________________________
> > >> cdi-dev mailing list
> > >> cdi-dev at 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.
> > >>
> > >
> >
> > --
> > Martin Kouba
> > Software Engineer
> > Red Hat, Czech Republic
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev at 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.
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev at 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160503/ede734e5/attachment-0001.html 