2016-02-16 12:14 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net>:
Le mar. 16 févr. 2016 à 11:25, Romain Manni-Bucau <rmannibucau(a)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(a)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(a)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(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.
>>>
>>
>>
>