[cdi-dev] New builders API

Tue May 3 09:48:39 EDT 2016

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.