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(a)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/310ac823376d086c2c3a9a1b2da...
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/310ac823376d086c2c3a9a1b2da...
[2]:
https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2da...
[3]:
https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2da...
Antonin
> On 03 May 2016, at 15:14, Antoine Sabot-Durand <antoine(a)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(a)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(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.
> >>
> >
>
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
> _______________________________________________
> 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.
> _______________________________________________
> 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.