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