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

[Antoine Sabot-Durand]

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.


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

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/c273045a/attachment-0001.html