So, once this change (use the correct classloader instead of guessing the TCL)
is done throughout AOP there will be no need for ScopedClassLoaderDomains
or any other integration code beyond the javassist ScopedClassPool.

With just the few changes I've done already, all the tests I've written pass
including the ones that have unexported classes and multiple versions
of the classes which are some of the more complicated OSGi use cases.

There's one caveat which is that to make the multiple version test work,
I had to make the interceptor PER_CLASS scope.

The notion of PER_VM needs redefining such that it takes into account
multiple versions of the advice in different classloaders, but it should not have to
do complicated things like the ScopedClassLoaderDomain to do that.

The PER_VM advices should just be indexed by the classloader of the advice class.

I've reverted the pushClassLoader change.

This was only working because the two different versions of the classes had the
same -aop.xml

I've updated the tests to show what the real problem is,
i.e. the pointcut matching doesn't understand the classloading.

The mock classloader isn't documented anywhere AFAIR,
I only created it for testing purposes.

The importAll and exportAll (not in the MockClassLoader)
are meant to duplicate what the old UCL does.
In the example you quote, it does do "importAll" so it will load from the whole
domain that the classloader belongs to.

The mock classloader has two important properties.

setPackages() - what is exported
setPaths() - what is part of the classloader (but not necessarily exported to other classloaders)

There is a convience method to do both, setPackagesAndPaths()

In the api you show, the "PACKAGE_A" is what is included in the classloader and
what is exported.

The "true" means it will "importAll", i.e. look at all other classloaders in the
order they were registered to find the class before looking at its own
private (non-exported) classes.

Try adding enableTrace("org.jboss.classloader") to the test
and you will see in detail where it is trying to load classes from
and where it found it.

"kabir.khan@jboss.com" wrote:

I am thinking of the following line:

bPolicy.setDelegates(createDelegates(supportPolicy));

To reproduce all the OSGi rules and old JBoss rules you would need
to look at the classloading rules and create AOP Domains that delegate to each other.

Think of A1, A2 and Support1/2 as applications. They are the
same application(s) deployed multiple times
(possibly different versions of the classes or just so the user can get their own singletons).

The AOPDeployer could use the classloading config and create domains
to match. i.e. A1 can see AOP configuration from A1 and Support1

For the old JBoss rules (importAll=true) then the visibilty would depend on the
domain name and parent policy like the old ScopedDomain.

The real work is going on in the "incomplete"
org.jboss.deployers.plugins.classloading.Module.

My preferred solution to use the scopes. i.e. you can choose
to deploy aop config at the SERVER, SUBSYSTEM, APPLICATION level, etc.
but this requires doing a lot work fixing everything to make sure
it sets the correct thread local MetaData for AOP to know which Scope
applies at runtime.

i.e. somebody could apply default aop config for some interception
at the server/global level and an application could override it.
Which AOP config applies when creating the object depends on the context of the
invocation NOT what classloader loads the aspect
(which could be in a different/global deployment) or the intercepted class (same reason)
to the application doing the work.

"adrian@jboss.org" wrote:

My preferred solution to use the scopes. i.e. you can choose
to deploy aop config at the SERVER, SUBSYSTEM, APPLICATION level, etc.
but this requires doing a lot work fixing everything to make sure
it sets the correct thread local MetaData for AOP to know which Scope
applies at runtime.

MetaData metadata = MetaDataStack.peek();
AspectManager manager = metadata.getMetaData(AspectManager.class);