> those classes are visible to the WAR/EAR/JAR > etc. according to the classloader rules.
The classes for sure, but not the <alternatives> etc according to some JBoss guys who reread the spec. See section 12.1 > The WEB-INF/classes directory of a war is a bean archive if there is a > file named beans.xml in the WEB-INF directory of the war. Which means the term BDA for a WAR only affects the WEB-INF/classes directory and _not_ subsequently all the libs in WEB-INF/lib! This is also confirmed by JBoss guys. Eric yesterday also pointed me to section 5.1 or the spec: > 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. An alternative is never available for > injection, lookup or EL resolution in a module that is not a bean > archive. But this definition is _completely_ sick from a real world apps view! I'm still in favour of providing an 'order' attribute to <interceptors order="3">, <alternatives> and <decorators> sections which defines the 'importance' of a definition. Higher importance means that it gets applied later, and thus overriding previous settings. With this trick you could easily define the final ordering for your interceptors in the beans.xml of your WAR by simply writing <interceptors order="100">... LieGrue, strub --- On Tue, 6/22/10, Gurkan Erdogdu <[email protected]> wrote: > From: Gurkan Erdogdu <[email protected]> > Subject: Re: problems with lack of archive-centric BeanManager > To: [email protected] > Date: Tuesday, June 22, 2010, 5:38 AM > >>>>..... it just > shouldn't automatically get the > >>>>decorators, interceptors & alternatives > enabled that other BDA. > > I think this is not correct behaviour. Spec. clearly > defines that interceptors, decorators and alternatives are > enabled by the bean archive's bean.xml. Therefore, if those > ar enabled, those classes are visible to the WAR/EAR/JAR > etc. according to the classloader rules. > > > For OWB Case > -------------------- > In our case, we collect all beans.xml and classes > regardless of BDA's and setup > interceptors/decorators/alternatives. I think this is not a > correct behaviour. As Eric already has shown us > > if you put X.jar into WEB-INF/lib with disabled interceptor > in its beans.xml but you enable it in WEB-INF/beans.xml, OWB > enables the interceptor and this is not correct regarding > the spec. > > > Thanks; > > --Gurkan > > > ________________________________ > From: Joseph Bergmark <[email protected]> > To: [email protected] > Sent: Tue, June 22, 2010 12:08:19 AM > Subject: Re: problems with lack of archive-centric > BeanManager > > I explicitly pointed out 12.1 in my e-mail earlier today > and I agree that is > the key section. > > If it is a good idea or not is important and is feedback we > should probably > probably take back to the EG, but implementation wise don't > we basically > have to implement the spec as it is defined now, possibly > with properties to > give non-default behavior if desired? > > I think this really only affects enabled decorators, > interceptors and > alternatives. If 1 BDA has class loader visibility > into another BDA it can > still inject those classes, it just shouldn't automatically > get the > decorators, interceptors & alternatives enabled that > other BDA. > > Sincerely, > > Joe > > > On Mon, Jun 21, 2010 at 4:53 PM, Mark Struberg <[email protected]> > wrote: > > > Folks, please reread section 12.1 of the spec (first > bullet list). > > > > According to this spec section, any jar with a > beans.xml is an OWN bean > > archive. > > > > So if any section in the spec is talking about a > certain functionality > > should only work in the bean archive the configuration > is done in, then all > > other jars are not affected. And this is imo not a > good idea... > > > > LieGrue, > > strub > > > > > > --- On Mon, 6/21/10, Gurkan Erdogdu <[email protected]> > wrote: > > > > > From: Gurkan Erdogdu <[email protected]> > > > Subject: Re: problems with lack of > archive-centric BeanManager > > > To: [email protected] > > > Date: Monday, June 21, 2010, 3:59 PM > > > > > > >>>What would happen if your WAR files > do NOT > > > contain those jars, but they > > > are part of the EAR and shared between ALL WARs? > > > If those jars are visible to WARs then they can > be injected > > > into WARs. Point is the visibility of the classes > regarding > > > to modules. If those JARs are put into EAR/lib > folder, and > > > those jars contains META-INF/beans.xml, all of > them are > > > visible to all WARs and EJBs and RARs. > > > > > > > > > >>>And thus the interceptors, > alternatives and all > > > this stuff simply WONT > > > WORK? > > > I think they work. > > > > > > --Gurkan > > > > > > > > > ________________________________ > > > From: Mark Struberg <[email protected]> > > > To: [email protected] > > > Sent: Mon, June 21, 2010 6:09:23 PM > > > Subject: Re: problems with lack of > archive-centric > > > BeanManager > > > > > > oki, take it one step further. > > > > > > What would happen if your WAR files do NOT > contain those > > > jars, but they are part of the EAR and shared > between ALL > > > WARs? > > > > > > Then (according to the definition in the spec) > those JARs > > > are _not_ part of the WARs BDA, isn't? > > > > > > And thus the interceptors, alternatives and all > this stuff > > > simply WONT WORK? > > > > > > > > > LieGrue, > > > strub > > > > > > --- On Mon, 6/21/10, Joseph Bergmark <[email protected]> > > > wrote: > > > > > > > From: Joseph Bergmark <[email protected]> > > > > Subject: Re: problems with lack of > archive-centric > > > BeanManager > > > > To: [email protected] > > > > Date: Monday, June 21, 2010, 3:00 PM > > > > I'm not entirely sure I agree that > > > > BDAs are only centered around EE > > > > classloader rules. For example in > section 12.1 > > > where > > > > it talks about > > > > deployment rules: > > > > > > > > " > > > > In an application deployed as a war, the > container > > > searches > > > > every bean > > > > deployment archive bundled with or > referenced > > > > by the war. The bean deployment archives > might be > > > library > > > > jars or the > > > > WEB-INF/classes directory. > > > > " > > > > > > > > This is a simple war case, but the spec > talks about > > > > searching "every" bda > > > > and "bean deployment archives". I > interpret > > > "library > > > > jars" here to mean jar > > > > files in the lib directory of the war, which > in OWB > > > we > > > > treat as part of one > > > > big "bda" including the war itself. > > > > > > > > As far as Mark's point about the TCK, I > think there > > > may be > > > > holes in the > > > > TCK. For example we passed the > Decorator tests > > > before > > > > we ever had support > > > > for Abstract Decorators, despite that being > pretty > > > clearly > > > > declared as an > > > > option in section 8.1.3. > > > > > > > > Would you be against investigating code that > keeps > > > track of > > > > which BDAs (in > > > > the war case I mean jars or WEB-INF/classes > > > directories) > > > > beans were found > > > > in, and then using that information during > > > > interceptor/decorator/alternative > > > > resolution? If nothing else it might > segue > > > nicely > > > > into WAR + EJB scenarios > > > > later. > > > > > > > > Sincerely, > > > > > > > > Joe > > > > > > > > On Mon, Jun 21, 2010 at 8:59 AM, Gurkan > Erdogdu < > > [email protected]>wrote: > > > > > > > > > Hello, > > > > > > > > > > Currently OWB has not implemented the > BDA > > > related > > > > semantic. BDAs are > > > > > related with the Java EE classloader > rules. For > > > > example, if you have a EAR > > > > > file with EJB and WAR, then EAR will > have bean > > > > deployment archive that > > > > > contains two other BDAs. > > > > > > > > > > EAR BDA --> WAR BDA + EJB BDA > > > > > > > > > > But EJB BDA does not see the WAR BDA > archive. But > > > both > > > > of them see the > > > > > common BDA that is located in anywhere > in the > > > > Application Server ClassPath, > > > > > META-INF/Mainifest.MF ClassPath etc. > > > > > > > > > > In summary, BDA is written to work with > current > > > Java > > > > EE classloader > > > > > semantics. You can look at Java EE > specification > > > > version 6 section "EE 8.3 > > > > > ClasLoading Requirements" to get > how > > > classloader > > > > works. > > > > > > > > > > > > > > > Currently OWB does not support BDAs. > > > Because we > > > > do not integrate the OWB > > > > > with full profie Java EE server. > > > > > > > > > > This is an one area that OWB needs > contribution. > > > > > > > > > > I hope this clears the discussion; > > > > > > > > > > --Gurkan > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > From: Eric Covener <[email protected]> > > > > > To: [email protected] > > > > > Sent: Mon, June 21, 2010 3:45:02 PM > > > > > Subject: Re: problems with lack of > > > archive-centric > > > > BeanManager > > > > > > > > > > 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] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
