look at CDI-129. Imo this is really tied to our modularisation and visibility. Think about
EAR deployments.
Imo each ClassLoader 'module' should have an own BeanManager forming a hierarchy
1:1 wich the ClassLoaders. And each BeanManager has it's own set of Extension
instances.
LieGrue,
strub
On Tuesday, 11 March 2014, 19:29, Pete Muir <pmuir(a)redhat.com> wrote:
Well, its not clear what the current behaviour should be, and it’s not clear what we want
the behaviour to be in the future!
On 10 Mar 2014, at 14:17, John D. Ament <john.d.ament(a)gmail.com> wrote:
> So, if I'm getting you guys right.
>
> - An extension applies to the entire application.
> - An extension should apply to the entire application even if it has
> been defined within a bean archive that is within the application
> (e.g. a JAR inside a WAR).
>
> I'm happy to create an issue (if none exists) and reword the spec to
> clarify this in 11.5, if it makes sense.
>
> - John
>
> On Mon, Mar 10, 2014 at 7:25 AM, Pete Muir <pmuir(a)redhat.com> wrote:
>> The only real reference is 11.5
>>
>> "The container instantiates a single instance of each extension at the
beginning of the application initialization process and maintains a reference to it until
the application shuts down. The container delivers event notifications to this instance by
calling its observer methods.
>>
>> For each service provider, the container must provide a bean of scope
@ApplicationScoped and qualifier@Default, supporting injection of a reference to the
service provider instance. The bean types of this bean include the class of the service
provider and all superclasses and interfaces."
>>
>> This is a known place in the spec where more detail should be provided and there
should be a (number of) open CDI issue(s).
>>
>> On 24 Feb 2014, at 10:09, Antoine Sabot-Durand <antoine(a)sabot-durand.net>
wrote:
>>
>>> Hi John,
>>>
>>> Yes it doesn't seem to be explicitly written (I'm still looking) but
reading at the beginning of chapter 12, it's implicit that there's one container
that do one bean discovery and fire on set of events for type discovered. So IMO, it's
implicit that extensions are not limited to their current archive and have the same
<< visibility >> level than the CDI container : i.e. the current application.
>>> This said, it couldn't hurt to write it explicitly.
>>>
>>> Antoine
>>>
>>> Le 22 févr. 2014 à 21:51, John D. Ament <john.d.ament(a)gmail.com> a
écrit :
>>>
>>>> Hi all,
>>>>
>>>> Quick question. This is mostly from playing around with Weld SE
>>>> 2.1.2, so I'm not sure if my question is going to be Weld SE
specific
>>>> or be generally applied.
>>>>
>>>> Looking through the spec, I did not see any obvious indications of
>>>> this. What is the scope of the application of an Extension class?
>>>> Suppose I had a JAR file that had
>>>> META-INF/services/javax.enterprise.inject.spi.Extension with the
>>>> contents of some extension class. Should the application of that
>>>> extension class apply to all JARs within the same classpath? If that
>>>> extension were listed in a WAR file, would it apply to the WAR and all
>>>> JAR modules?
>>>>
>>>> John
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev