[cdi-dev] New builders API

Mon Apr 25 11:57:18 EDT 2016

This request sounds very familiar to Spring's post-processor framework.
Spring allows post-processors to modify/augment bean definitions before the
definition is locked for instantiation.

Cheers,
Paul

On Mon, Apr 25, 2016 at 10:28 AM, Antonin Stefanutti <antonin at stefanutti.fr>
wrote:

> 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.
>
>
> _______________________________________________
> 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/20160425/675f58f2/attachment-0001.html 