[cdi-dev] Full rewrite for CDI 558 / PR 270

Tue Feb 16 06:45:59 EST 2016

2016-02-16 12:14 GMT+01:00 Antoine Sabot-Durand <antoine at sabot-durand.net>:

>
>
> Le mar. 16 févr. 2016 à 11:25, Romain Manni-Bucau <rmannibucau at gmail.com>
> a écrit :
>
>> Hey guys,
>>
>> thinking more to it here few more remarks/requests:
>>
>> - as an extension writer think having an explicit build is better than an
>> implicit one in particular when you manage several built instances. The
>> fact it is sometimes implicit sometimes explicit has these drawbacks:
>> -- API starts to be huge for a poor gain
>>
>
> +1
>
>
>> -- you actually don't know what is done more easily if not inline (which
>> is likely the case for medium/advanced extensions)
>>
>
> +1, I think we should remove this notion on Configurator I intoduced, the
> question ius do we keep specific SPI method returning a builder to be build
> in a DSL way or not
>
>
>> - why having Builders class with static methods where we could use the
>> bean manager as entry point for them. Would be more natural since the BM
>> already build some instance like AT and easier to find in the IDE and look
>> less magic.
>>
>
> -1 BM is already bloated with a zillion of methods and as discussed
> somewhere else some builders (mainly ATB) could be useful from outside CDI,
> especially in SE to prepare config before starting the container.
>
>

Not a fan of BeanManager but it is the single entry point today. That said
most of them are for boot work so events are a good alternative to put them.

> -- bonus on this one: would also bind the calls to a CDI context which
>> makes things easier to track and if we speak later of multiple contexts in
>> the same classloader we wouldn't be broken
>>
>
> Remember that built meta-data are mainly used during container bootstrap
> where context are not active... So I'm not sure to get the interest of this
> idea.
>
>
don't want to use too much space/time on it since it is not yet on our
plate but just to answer the idea was:

// time execution
CdiContainer c1 = .....provider(WeldProvider.class).start();
// c1 lifecycle as expected

CdiContainer c2 = .....provider(OpenWeabBeansProvider.class).start();
// extension in c2 using OWB cause events - or BM in my first mail - are
OWB ones and not Weld ones

There are few builders we can use at runtime to integrate with 3rd party
libs - main thing you want is an InjectionTarget - but guess we have most
of them already in CDI 1.2 so think the event proposal works and wouldnt
constrained too much integrations.

> Antoine
>
>
>>
>>
>> wdyt?
>>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>> <http://www.tomitribe.com>
>>
>> 2016-02-05 16:01 GMT+01:00 Romain Manni-Bucau <rmannibucau at gmail.com>:
>>
>>> Why not making all Annotated* mutable during boot lifecycle?
>>>
>>> Would allow to get rid of the annotated root in the modification code,
>>> for instance we could convert:
>>>
>>>     type.getMethods().stream().filter(m ->
>>> m.isAnnotationPresent(Foo.class)).forEach(m
>>> ->event.setAnnotatedType().addToMethod(m, MyInterceptor.BINDING));
>>>
>>> to
>>>
>>>     type.getMethods().stream().filter(m ->
>>> m.isAnnotationPresent(Foo.class)).forEach(m ->
>>> m.mutate().add(MyInterceptor.BINDING));
>>>
>>> or if we don't want to add mutate in the existing types we could use
>>> configurator as root for type type and recreate a Configurator graph
>>> matching annotated graph.
>>>
>>> Advatage is first code i a bit awkward in the sense you can call
>>> setAnnotatedType() multiple type (what would happen? only last modification
>>> will be saved? or you have to keep a reference to the configurator once
>>> called which breaks the fluent API provded by streams IMO.
>>>
>>> wdyt?
>>>
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>> <http://rmannibucau.wordpress.com> | Github
>>> <https://github.com/rmannibucau> | LinkedIn
>>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>>> <http://www.tomitribe.com>
>>>
>>> 2016-02-05 15:24 GMT+01:00 Antoine Sabot-Durand <
>>> antoine at sabot-durand.net>:
>>>
>>>> Hi all,
>>>>
>>>> Following discussion during last meeting, I rewrote most of my PR for
>>>> builders.
>>>>
>>>> We now have 2 clean and distinct ways of using them
>>>>
>>>> 1) in DSL style (with a Configurator interface without build() method)
>>>>
>>>> public void processAT(@Observes ProcessAnnotatedType<?> pat) {
>>>>   pat.setAnnotatedType().read(pat.getAnnotatedType()).addToType(new
>>>> AnnotationLiteral<MyInterceptor>() {};);
>>>> }
>>>>
>>>>
>>>> 2) In classical reusable builder mode (builders extends configurator
>>>> and only add build() method)
>>>>
>>>> public void processAT(@Observes ProcessAnnotatedType<?> pat) {
>>>>  AnnotatedTypeBuilder atb = Builders.annotatedTypeBuilder();
>>>>  atb.read(pat.getAnnotatedType()).addToType(new
>>>>  AnnotationLiteral<MyInterceptor>() {};);
>>>>   pat.setAnnotatedType(atb.build());
>>>> }
>>>>
>>>>
>>>> As Configurators don't have build() method there's no risk that users
>>>> mix them with standard builders.
>>>> For clarity sake, builders are no more available in lifecycle event but
>>>> in Builders class for consistency.
>>>>
>>>> I'm quite happy with the result, but I'm sure you'll have comment ;).
>>>> So thanks for your feedback
>>>>
>>>> https://github.com/cdi-spec/cdi/pull/270
>>>>
>>>> Antoine
>>>>
>>>> _______________________________________________
>>>> 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/20160216/f98ec0ff/attachment.html 