[cdi-dev] New builders API

Tue Apr 26 03:05:35 EDT 2016

Hi Martin,

You’re right. As backward compatibility is a major constraint in API evolvability though I preferred sharing my needs / ideas as I see there are connected to the current work and may not be possible to meet afterward.

My point was that for the current new bean builder API that can be retrieved from AfterBeanDiscovery:

NewBeanConfigurator AfterBeanDiscovery.addBean();

A subset could be accessed for discovered beans, e.g.:

ExistingBeanConfigurator bean = AfterBeanDiscovery.forBean(manager.getBean(...));
bean.addQualifier(...);
...

If the current design for the new bean builder API won’t impede that future evolution then all is good :)

Antonin

> On 26 Apr 2016, at 08:44, Martin Kouba <mkouba at redhat.com> wrote:
> 
> Hi Antonin,
> 
> both ideas sound reasonable. However, I would rather focus on the current proposal of builders/configurators right now. Once we agree on basics we can think of other improvements ;-)
> 
> Please create separate issues for both, the possibility to modify a bean during AfterBeanDiscovery and "functional helpers".
> 
> Thanks,
> 
> Martin
> 
> Dne 25.4.2016 v 17:28 Antonin Stefanutti napsal(a):
>> Hi All,
>> 
>> Two points connected to that new builder API.
>> 
>> In a number of use cases, for example the Camel CDI extension that John has looked at (https://github.com/cdi-spec/cdi/pull/287#issuecomment-213834213), a bean is added to actually mutate an existing bean in the AfterBeanDiscovery lifecycle event. Indeed, quite often, the information that’s necessary to mutate the bean isn’t available at the time the BeanAttributes lifecycle event is triggered. It is recurrent that a first phase is required to capture a set of information that’s larger than the sole bean to be changed. So the AfterBeanDiscovery is the perfect time to do that as the developer can query the bean manager. Unfortunately, there is no way to mutate an existing so the work-around is to actually veto the existing one and add a new one or an alternative to it.
>> 
>> So I’m wondering whether a subset of the new builder API could be exposed so that the developer can mutate an existing bean, for example adding extra qualifiers to it.
>> 
>> So in the second Camel CDI example that John has pointed out, instead of doing:
>> 
>> https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L248-L255
>> 
>> having to just recreate an existing bean artificially:
>> 
>> https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L301-L307
>> 
>> It would make a lot more sense just to iterate over the existing beans and add the qualifiers to them.
>> 
>> Another point, less structuring: as the developers use the stream API over the CDI SPI, the need arises to have Predicate and other functional interfaces for it, like:
>> 
>> - check the type of a Bean:
>> https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L267-L268
>> https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L250
>> - check the type of a qualifier:
>> https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L280-L284
>> https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L245
>> 
>> I’m wondering whether the CDI API could provide the more recurrent functional interfaces to avoid each developer having to redeclare her/his own pretty much as it used to be the case the build-in qualifier literals:
>> 
>> https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiSpiHelper.java#L49-L57
>> 
>> Antonin
>> 
>>> On 25 Apr 2016, at 09:30, Martin Kouba <mkouba at redhat.com> wrote:
>>> 
>>> 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.
>> 
> 
> -- 
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic