you picked a good example: > | 2.6. Alternatives > | An alternative is a bean that must be explicitly declared > in the > beans.xml file if it should be available for lookup, > injection or EL resolution.
There is _nothing_ stated if this alternative bean should a) only be available for this specific bean archive it is defined in or if it b) should be available for _all_ bean archives. Imo a) would make absolutely no sense, so it clearly is b). This is imo also what weld is doing. But for some weird reason Gavin is arguing in exactly the opposite when it comes to interceptors - despite the wording in the spec is exactly the same there... LieGrue, strub --- On Mon, 6/21/10, Eric Covener <[email protected]> wrote: > From: Eric Covener <[email protected]> > Subject: Re: problems with lack of archive-centric BeanManager > To: [email protected] > Date: Monday, June 21, 2010, 11:34 AM > On Mon, Jun 21, 2010 at 5:41 AM, Mark > Struberg <[email protected]> > wrote: > > If you can point me to the paragraph in the spec and > the corresponding TCK test where it is clearly stated that > an interceptor enablement is only meant to work for the > current bean archive bundle, then please provide it. > > I don't know about the TCK, but clearly all the elements of > the > beans.xml are BDA-centric. > > > | 2.6. Alternatives > | An alternative is a bean that must be explicitly declared > in the > beans.xml file if it should be available for lookup, > injection or EL > resolution. > > > | 9.4. Interceptor enablement and ordering > | By default, a bean archive has no enabled interceptors > bound via > interceptor bindings. An interceptor must be explicitly > enabled by > listing its class under the <interceptors> element of > the beans.xml > file of the bean archive. > > > You can't have interceptors enabled (and ordered) anywhere > else, > unless you manufacture a notion of a hierarchy of BDA's, in > which case > we need the very same change to reflect that > relation. I'm not even > considering the idea that the BDA of the interceptor class > itself is > where it ought to be enabled for all other beans, as this > vicarious > enablement would be totally off the charts. > > > -- > Eric Covener > [email protected] >
