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:
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:
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.