[cdi-dev] explicit bean archives discovery-mode 'annotated'

[Antoine Sabot-Durand]

> Le 5 mars 2015 à 09:28, Mark Struberg <struberg at yahoo.de> 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.


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

Yes, that’s why you shouldn’t use annotated discovery mode if you want to do serious stuff in CDI.
Having a mode where PAT are fired but AnnotatedType without Bean Defining annotation wouldn’t become bean might bring more confusion : what happen if I replace the AnnotatedType with one bearing a Bean Defining annotation or if I register a new AnnotatedType without bean defining annotation in BeforeBenDiscovery?

We have to leave with this Annotated mode which already brought it’s issues (https://issues.jboss.org/browse/CDI-377) and recommend users that want do real stuff with CDI to use All discovery mode.

> 
> LieGrue,
> strub
> 
> 
> 
> [1] http://deltaspike.apache.org/documentation/core.html#_messages_and_i18n
> 
> 
>> Am 05.03.2015 um 08:54 schrieb Martin Kouba <mkouba at redhat.com>:
>> 
>> 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 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.
>>> 
>> 
>> --
>> Martin Kouba
>> Software Engineer
>> Red Hat, Czech Republic
> 
> 
> _______________________________________________
> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150305/3a370c1e/attachment-0001.bin