I've removed the bodge/changed api that tries to "inject" the aspect manager
into the PropertyKernelConfig.
The KernelConfig is intended as a bootstrap object. i.e. it is self contained
in the policy it provides on bootstraping the kernel.
If you want to "inject" things into the kernel config, create your own kernel
config by subclassing, don't mung the existing implementations.
I already provided mechanisms where the policy can be overridden,
See AspectTestKernelConfig.createDefaultClassAdapter()
Additionally, for core JBoss use, we are not going to create an AspectManager
before starting the kernel. The AspectManager should be under the control
of the kernel for configuration/management purposes.
This raises an interesting issue in how we provide aspects onto the core
kernel objects (I assume the AspectManager will be the first object installed).
This is a similar "chicken and egg" on how you apply a security advice to the
security manager.
I believe the Dynamic AOP of JBossAOP helps here?
Finally, this AspectManager context used by the ClassAdapter (or whatever it is going to be replaced with) needs considering in the context of scoping/domains.
