-
30. Re: AOP asintegration WITHOUT the integration :-)
"adrian@jboss.org" wrote:
"kabir.khan@jboss.com" wrote:
Are you saying "don't use it", or "use it and we'll retrofit an SPI"? :-) As far as I can tell I will need information from the ClassLoaderPolicy.
I'm saying any use of the classloading metadata for the AOP domain construction
would be a hack until we have a real solution based on metadata context
rather than the classloader of the aspectized class/aspect class/joinpoint.
The latter (classloader solution) is just a temporary solution to reproduce
what jboss4 does. I don't think we need to create a SPI (which we will need to
support forever) for something that is a temporary hack.
If we created a SPI, it wouldn't be the Unified ClassLoader or the new classloader
it would have to cover all possible classloading models that people might want
to plugin to the deployers.
I am thinking about if we need to create special classpools understanding the new loaders. Let's ignore this for now until I am sure that these pools will be needed -
31. Re: AOP asintegration WITHOUT the integration :-)
"kabir.khan@jboss.com" wrote:
I am thinking about if we need to create special classpools understanding the new loaders. Let's ignore this for now until I am sure that these pools will be needed
That was my original guess. i.e. we would have some kind of plugin
that would recognise the classloader type and use the metadata available from
the classloader (and the knowledge of its internal assumptions/mechanisms) to
create the pools.
e.g. The default would just be a hierarchical version that looked at
ClassLoader.getParent() for the normal classloader rules
but there would be others that recognised the UCL and the new classloader
and asked them for how they are configured, e.g. which loader repository
or exported packages, etc.
But, like I said, I don't think the tying of the aop definition to the classloader
is the correct solution.