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

[adrian@jboss.org]

"kabir.khan at jboss.com" wrote : 
  | "adrian at jboss.org" wrote : 
  |   | e.g. In your final comment where you want a "global" aspect definition then
  |   | the deployments that want to use it would need to "import" the classloader
  |   | where those aspects are deployed.
  | 
  | I think you are saying just ignore InterceptorB and InterceptorC unless A.jar is set up to import the packages/modules of the interceptors? I think that will be pretty simple to do. 
  | 

It depends what you are talking about. If the aspect definition is in A.jar
but the class is invisible then I think it should be an error.

I don't see why aspects shouldn't follow the same rules as normal class imports?
The fact that AOP is weaving the class reference into bytecode 
(either literally or dynamically via interceptors) shouldn't make any difference.

anonymous wrote : 
  | My suggestion regarding global visibility is to make the classes from the loaders for B.aop and C.aop magically visible from A.jar somehow. But that means we don't get versioning of modules packages, so maybe an explicit import is the best thing. At the same time, I don't know if whoever writes A.jar should need to know that InterceptorB or InterceptorB might be applied later?
  | 

Magically adding a random version of the class is clearly not in sympathy with
the modularization rules of OSGi style classloading.

The issue that I said was upto you is whether InterceptorB defined in B.aop really applies
to A.jar when everything else from B.aop is not visible to it.

I'd say the rule should be that the aop config only applies when A.jar chooses
to import the relevant aspect classes defined in B.aop.

The part I said you might ignore would be where B.aop contains aspect
configuration for other classes that A.jar chooses NOT to import or just isn't relevant.

I don't know whether that helps you resolve the problem, but you certainly shouldn't
be trying to break the class visbility rules in any way. That could be a potential
security hole if nothing else. :-)

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220320#4220320

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220320