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] > > > > > > > > > > > > >
