Hi! I think I’ve implemented the behavour the spec defines - but it does not make much sense. First let’s look at the spec: 11.5.6. ProcessAnnotatedType event The container must fire an event, before it processes a type, for every Java class, interface (excluding the special kind of interface declaration annotation type) or enum DISCOVERED as defined in Section 12.4.1, “Type discovery” 12.4.1 defines… First the container must discover types. The container discovers: • each Java class with a bean defining annotation in an implicit bean archive. And in 2.5 we can read "f the bean discovery mode is annotated then: • bean classes that don’t have bean defining annotation (as defined in Section 2.5.1, “Bean defining annotations”) and are not bean classes of sessions beans, are NOT DISCOVERED“ Which to me means that for a BDA with discovery-mode = „annotated“ we ONLY must fire ProcessAnnotatedType for classes with bean defining annotations, and NOT for interfaces or enums. If this is true, then it is a huge mess for lots of CDI Extensions. It basically renders the ‚annotated‘ mode pretty much useless. What we really need instead is a mode which will not automatically make a @Dependent bean out of every class later. But I really would ‚discover‘ all classes in a BDA and pass them to ProcessAnnotatedType. Some way to fix this or do we have to wait for CDI-2.0 to repair CDI-1.1? LieGrue, strub _______________________________________________ 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.

Am 05.03.2015 um 09:28 schrieb Mark Struberg <struberg(a)yahoo.de&gt;: 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 [1] http://deltaspike.apache.org/documentation/core.html#_messages_and_i18n > Am 05.03.2015 um 08:54 schrieb Martin Kouba <mkouba(a)redhat.com&gt;: > > Hi Mark, > > First of all you're talking about _implicit_ bean archives - explict bean archive contains a beans.xml with bean-discovery-mode of all, with no version number or an empty file. > > With regard to usability (from the extension developer point of view) - could you give some practical examples? AFAIK it's really useful from the app developer point of view. > > Dne 4.3.2015 v 20:25 Mark Struberg napsal(a): >> Hi! >> >> I think I’ve implemented the behavour the spec defines - but it does not make much sense. >> >> First let’s look at the spec: >> >> 11.5.6. ProcessAnnotatedType event >> The container must fire an event, before it processes a type, for every Java class, interface >> (excluding the special kind of interface declaration annotation type) or enum DISCOVERED >> as defined in Section 12.4.1, “Type discovery” >> >> 12.4.1 defines… >> First the container must discover types. The container discovers: >> • each Java class with a bean defining annotation in an implicit bean archive. >> >> >> And in 2.5 we can read >> "f the bean discovery mode is annotated then: >> • bean classes that don’t have bean defining annotation (as defined in Section 2.5.1, “Bean defining annotations”) and are not bean classes of sessions beans, are NOT DISCOVERED“ >> >> >> >> Which to me means that for a BDA with discovery-mode = „annotated“ we ONLY must fire ProcessAnnotatedType for classes with bean defining annotations, and NOT for interfaces or enums. >> If this is true, then it is a huge mess for lots of CDI Extensions. It basically renders the ‚annotated‘ mode pretty much useless. >> >> >> What we really need instead is a mode which will not automatically make a @Dependent bean out of every class later. But I really would ‚discover‘ all classes in a BDA and pass them to ProcessAnnotatedType. >> Some way to fix this or do we have to wait for CDI-2.0 to repair CDI-1.1? >> >> LieGrue, >> strub >> >> >> _______________________________________________ >> 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. >> > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic _______________________________________________ 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.

Am 05.03.2015 um 14:14 schrieb Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt;: > Le 5 mars 2015 à 09:28, Mark Struberg <struberg(a)yahoo.de&gt; a écrit : > > 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? > It’s the other way around. Implicit bean archive behave as if they have a beans.xml with version 1.1 and “annotated” bean-discovery mode.

Yes, that’s why you shouldn’t use annotated discovery mode if you want to do serious stuff in CDI.

Am 05.03.2015 um 16:06 schrieb Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt;: > It’s the other way around. Implicit bean archive behave as if they have a beans.xml with version 1.1 and “annotated” bean-discovery mode. We are saying the same. what’s your point here ?

Le 6 mars 2015 à 08:00, Jozef Hartinger <jharting(a)redhat.com&gt; a écrit : Are you really telling people to use beans.xml with bdm="all" again? Is that based on this particular issue or did you reach the conclusion before based on some other issues? On 03/05/2015 02:14 PM, Antoine Sabot-Durand wrote: > Yes, that’s why you shouldn’t use annotated discovery mode if you want to do serious stuff in CDI.

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

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&gt; 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 > 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.

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&gt; 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&gt;: > > 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&gt; 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 >> 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(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.

Am 06.03.2015 um 09:15 schrieb Jozef Hartinger <jharting(a)redhat.com&gt;: 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.

Am 06.03.2015 um 09:48 schrieb Romain Manni-Bucau <rmannibucau(a)gmail.com&gt;: that's not the issue of none. None was mainly designed for not cdi libs I think...which will never get modified for cdi *by design*. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-03-06 9:44 GMT+01:00 Mark Struberg <struberg(a)yahoo.de&gt;: While we are at it: the ’none’ mode is broken as well ;) Imagine you have a jar in say DeltaSpike with a bean-discovery-mode=„none“. Now let’s run this in CDI-1.1++ containers: all fine jar gets ignored But in CDI-1.0 containers: whoops, due to having a beans.xml at all (marker interface) the container must scan this jar. There is simply no backward compatible way to tell the container that it should ignore a jar. LieGure, strub