[jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re: Reimplementing AspectManager/Domains to understand jboss

Coming back to this IV is not a good solution. As far as I can tell it means that you can never have "external" aspects (aspects in packages not declared in the loaders import or the loader itself) applied to classes in classloaders using importAll=false. I think we need a way to make it possible to have aspects deployed globally and applied to loaders using importAll=false, but maybe in reality it isn't as important as I think? I'm just thinking loud, hopefully that will help me organise my thoughts later... A simple solution would be to include the packages of aspects that might be applied in the target classloader's optional imports. But that might be a step in the wrong direction, limiting the scope of dynamic aop? For II and III we need some way to identify classloaders that contain aspects. That could be done if we make it a requirement that aspects which should apply to more than one deployment are deployed in a top-level .aop archive. Nested .aop archives could only apply to that deployment if import/export is used, but again the bindings contained in its jboss-aop.xml might be referencing aspects from outside that loader? If we have a way to identify aspect deployments something needs doing to make the classes globally visible within the domain. A few initial ideas: -Have "special" classloaders within the domain for aspects which are checked even by classloaders using importAll=false -Have AOP stuff deployed in a parent domain (if this is actually checked when importAll=false) of the real domain, something like: | AOPDefaultDomain | DefaultDomain | AOPChildDomain1 | ChildDomain1 | AOPChildDomain2 | ChildDomain2 | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220270#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...