I am about to look into whether refactoring the AspectManager/Domains is possible, and here are my initial thoughts.
One problem with the current way the AspectManager/Domains work, which has been bugging me for ages, is that there is no interface, we are working on the plain implementing classes. This becomes a problem when working with PER_INSTANCE aspects in the new weaving model. These require access to the instance advisor, which is backed by an instance domain. An instance domain is quite costly to create, since it has extends AspectManager. Although I was able to improve performance by making some of these maps lazy initialise, it still slows things down considerably. I want to update the current aop trunk to have an AOPManager interface (with the same methods as AspectManager/Domain) and to use this with AOP 2.0. In most cases the creation of these domains are unnecessary, since in the case of PER_INSTANCE aspects we are just reading data, i.e. the data is the same as the parent data. Basically the idea is to replace the initial domains for Class- and InstanceAdvisors with something that is more lightweight that just delegates onto the parent AOPManager UNTIL we add some dynamic information to the current domain.
The old AspectManager/Domain's will become facades onto the new structures, so that code woven with AOP 1.5.x will still be usable with the new structures, and I will provide a new way of accessing the main AOPManager singleton. AspectManager.instance() will still exist, but be deprecated.
I'll flesh out this thread once I start looking into this a bit more.
