Le 6 mars 2015 à 11:06, Romain Manni-Bucau
<rmannibucau(a)gmail.com> a écrit :
that's not fully true Antoine, EJB does at least - but some guice extensions as well.
If you have a EE 5/6/7 ejb lib then you can now break where you were not before. On CDI
alone side it is fine but not for EE globally.
Nice feedback if we were march 6th 2014 before end of CDI 1.2 work. CDI-377 and CDI-404
were debated by a lot of people...
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/>
2015-03-06 11:01 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net
<mailto:antoine@sabot-durand.net>>:
I checked that no other IoC framework was using @Interceptor before proposing the fix in
CDI-377
> Le 6 mars 2015 à 09:22, Romain Manni-Bucau <rmannibucau(a)gmail.com
<mailto:rmannibucau@gmail.com>> a écrit :
>
> Well @Interceptor is widely used elsewhere - that's the main one I can think
about.
>
>
>
> 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/>
> 2015-03-06 9:15 GMT+01:00 Jozef Hartinger <jharting(a)redhat.com
<mailto:jharting@redhat.com>>:
>
> On 03/06/2015 09:03 AM, Romain Manni-Bucau wrote:
>> Hi
>>
>> Well you cant ask libs to change their programming model for it IMO. It is
clearly a regression.
>>
> Why not? Existing applications (empty beans.xml) will still work as before so there
is no regression. If a lib wants to support bean-discovery-mode="annotated" then
it has to adapt. It would be better if they did not have to but it's too late at this
point.
>> Another broken case is if any other IoC uses some of these annotations but doesnt
rely on scanning. Now you scan the jar and can get surprises and even an Error.
> Yes, this was a risk when implicit bean archives were introduced. This was in the end
mitigated by only making CDI annotations as bean defining (most likely other IoC won't
use CDI annotations) plus introducing bdm="none" mode.
>>
>> Le 6 mars 2015 08:12, "Jozef Hartinger" <jharting(a)redhat.com
<mailto:jharting@redhat.com>> a écrit :
>> This interface/enum discovery use-case very often uses a marker
>> annotation (e.g. @MessageBundle). Such extension can work around this
>> limitation by making the marker annotation a @Stereotype. Can you see
>> any other scenarios where implicit bean archives are a problem?
>>
>> On 03/05/2015 09:28 AM, Mark Struberg wrote:
>> > Well, the terms ‚explicit‘ and ‚implicit‘ BDA are blurry as well.
I_explicitly_ add a beans.xml with version=1.1 and bean-discovery-mode=„annotated“ and
still it is an ‚implicit‘ BDA according to those definitions. Not very self-explaining but
anyway. Has not much to do with the current topic as well, so not sure why you mentioned
it?
>> >
>> > An example of usability would e.g. be the DeltaSpike @MessageBundle feature.
Seam3 has had something similar afair.
>> > For those who don’t know it see [1]. You basically have an interface and
DeltaSpike automatically picks those up and provides implementations for them which are
registered as Beans.
>> >
>> > But in the ‚annotated‘ mode we wont get any PAT for those interfaces
anymore. The same mechanism is used tor JPA archives, PropertyFileConfig, etc…
>> > Just grep DeltaSpike and check where PAT gets used. It’s all over the
place…
>> >
>> > LieGrue,
>> > strub
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
>>
https://lists.jboss.org/mailman/listinfo/cdi-dev
<
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
<
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(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/cdi-dev
<
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
<
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.