Umm, but how would you then 'switch' a Service which is defined in a jar you only use (for example a common utilities jar in your company) to behave different in your project? For what I understand
mycomp-utils.jar <- contains MailServiceImpl.java is being used by mycomp-myprj.jar <- contains MyAlternativeMailServiceImpl.java Then there is no way (other than to modify mycomp-utils.jar) to switch to the alternate mail service for classes defined in mycomp-utils.jar? Either I'm getting this wrong, or this is _completely_ bullsh**ish... 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, 12:45 PM > 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] >
