On Mon, Jun 21, 2010 at 7:53 AM, Mark Struberg <[email protected]> wrote: > 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... >
In the modularity section: An alternative is not available for injection, lookup or EL resolution to classes or JSP/JSF pages in a module unless the module is a bean archive ___and the alternative is explicitly selected in that bean archive____ There is IMO an option C that is a pretty reasonable behavior Assume a WAR with three bean archives. bda1.jar contains a bean that also has an alternative. bda2.jar has no enabled alternatives bda3.jar has the alternative enabled. Injection into beans from bda2 behave differently than injections into beans from bda2. The biggest confusion for me here is the way that 299 tries to define a WAR + beans.xml as something different than just a BDA in section 5, without going so far as to actually saying it really is intended to behave differently (relative to BDA's "inside" of it). -- Eric Covener [email protected]
