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