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

Mark Struberg struberg at yahoo.de
Thu Mar 5 04:09:17 EST 2015


Just figured that I already reported this a year ago: https://issues.jboss.org/browse/CDI-420




> Am 05.03.2015 um 09:28 schrieb Mark Struberg <struberg at yahoo.de>:
> 
> 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 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.




More information about the cdi-dev mailing list