[jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re: AOP ClassLoader/Scoping needs thoroughly revising

[adrian@jboss.org]

The issue as it appears to me in the AOP config is that it is generally storing
things at the class(loader) level.

This is a reasonable strategy to avoid memory leaks. Once the class(loader)
is GCed the WeakReference is removed.

But in general this leads to the wrong configuration or wrong advices getting
used. What is required is a different strategy where *logically* the advice stacks (and
other info?) are at the scope/class level.

Of course, we should still need to optimize away duplicates where there
is no override at more finer grained scopes. If it just took the simplistic approach
then you have an advice stack per instance which wouldn't scale at all. :-)

I'm not sure what the best way to implement this is efficently.
You obviously don't to be doing a scope access on every method/field call
to see whether there is an override for that scope.
And in fact, that might lead to wrong semantics where an object from
one application is passed to another application.
It could suddenly start using the wrong advices.

That is why I emphasised "logically" above.

It seems to me that the best way to do this would be like MC instance level
aop. 

That is if the config/advices/class are all in the same scope/domain
then we just need a normal Advisor.

If however we are going to override a class's configuration in a child scope/domain
(maybe even the class is not advised in its own scope) then we use the
proxy stuff like the MC work.

Finally, the other advantage of using Scopes when they are integrated into the
deployers is that there is a pretty trivial point during the undeploy when
you know the information can be released and what information needs to be
released.

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

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