[jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - AOP ClassLoader/Scoping for the VFSClassLoader

[adrian@jboss.org]

Now that I've done my "brain dump" on where I really want to get to
for the AOP scoping, here' s another one on some more immediate changes I need
to make for the VFSClassLoader integration.

The problem with the AOPScopedClassLoaderHelper and the
ScopedClass[Pool/Factory/Repository]
is that is assuming a simple hierarchical model.

That works for typical J2SE usage (with hierarchical classloaders)
or the JBoss UnifiedClassLoader (with hierarchical loader repositories)
but it doesn't work with the new classloader that has OSGi classloading rules.

With the OSGI style classloading rules a class can be deployed multiple times
(at different versions or as a private class to a deployment that is not shared).

The classloaders are also peers of each other and delegate to each other
(in a consistent way). This is similar to the JBoss UnifiedClassLoader
but it is not a delegate to everybody, there's no equivalent of a global repository
that defines the classloading space.

NOTE: In fact, the VFSClassLoader can emulate the old UnifiedClassLoader
rules with export/importAll policies but that is beside the point here.

So, as far as I can tell there needs to be the following changes in
the AOPSharedClassLoaderHelper abstraction.

1) All policy decisions need to be done inside the abstraction.
Currently the abstraction is too low level with some decisions being made
inside the AOP classes themselves.

2) The ScopedClassPool needs replacing with something that
doesn't assume that all  classes are visible from the caller classloader.

I'm thinking that this can probably be done with the already existing
javassist ClassPath api, if we make an implement of this that hooks into
the ClassLoaderPolicy abstraction of the new classloader (the apis
are pretty similar at least in the concept of resource location).

3) I'm not sure the idea of "repository", at least at is it used by AOP, is rich enough. 
I do have a notion of "ClassLoadingSpace" 
(which is all classloaders that interact with each other consistently)
so maybe that is what could be used? 

But it still doesn't really encapsulate the idea that classes can be deployed twice 
inside a "space" if they are only used privately.
e.g. think two deployments that interact but they each have their own
version (possibly different version) of commons logging that isn't part of
their interaction api.

I'm going to try to implement it this way and see what problems I find.

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

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