Currently the OWB BeanManager does not retain much info about individual Archives (whether they be BDA's or non-BDA's), only the aggregate classes and beanXML's.
For the sake of discussion, consider a WAR with three utility jar's in the lib/ directory. a.jar is a BDA that defines an interceptor binding and an interceptor b.jar is a BDA that defines a managed bean with the aforementioned InterceptorBinding c.jar is a BDA that defines a managed bean with the aforementioned InterceptorBinding. Our current design does not permit either of the following scenarions, AFAICT: b.jar and c.jar both enable the interceptor defined in a.jar (treated as a duplicate) Exactly one of b.jar and c.jar enables the interceptor defined in a.jar (ends up enabled for beans from either archive if enabled in one -- this is in the more troubling neighborhood) This is primarily because between the BeanManager and the ScannerService, we lose all granularity abut the source of classes and beanXML's. This manifests itself in slightly more involved ways, such as when an applications contains multiple modules with multiple classloaders. Neither 1 BeanManager or N BeanManagers seems too appealing in this case. There has been some offline discussion about: * introduce a first-class data structure to represent a Archive (composed of classes, XML's, and Archive references) * teach the ScannService or some successor to return lists of Archives to the deployment code * teach the BeanManager to manage a network of Archives to properly follow the EE accessibility rules I took a crack at illustrating this on top of guess by adding separate sub-modules for the utility jars as described above http://people.apache.org/~covener/owb/ OOTB this results in a disabled (for a specific bean based on the BDA it comes from ) interceptor being run. -- Eric Covener cove...@gmail.com
