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]
