Microcontainer and AOP integration
The page contains the a list of requirements for the Microcontainer (MC) and AOP integration. It also tries to explain the reasoning behind these requirements with the following caveats:
All XML shows is pseudo xml. The real requirement is to have a metadata model which could be created via an XML file or some other mechanism
Some of the assumptions/potential problems have not been verified and maybe non problems, but they remain problems until proved otherwise.
Assumptions
The integration is just an "opening up" of AOP to meet the MC requirements. In no way should this work break or change existing users of AOP.
This integration is mainly necessary to meet the requirements of using the MC to build JBoss, most user applications will not need some of the complex dependency requirements. Though they can/will take advantage of them either programmatically/adminstratively or just through plain ease of use of having their code/lifecycle managed by a container.
History
A meeting was held in Boston to thrash out these requirements. The conclusions of this meeting are summarised here and the associated posts/JIRA tasks:
Requirement 1 - Unified Interceptors by AOP
This is a general requirement to use the AOP interceptor/advice model in all our work with different technologies sharing the same advice implementations to import/export their functionality at integration time.
This has been a known problem for a long time, it was previously called "Unified Interceptors". Basically, each project was writing their own interceptor/invocation model and couldn't take advantage of the excellent work done in AOP.
It also avoids the tendancy for each project to do "NOT INVENTED HERE" work where they write
their own advices and effectively do their own integrations in similar but incompatible ways, or just increase the complexity changing implementations/integrations as new features are added.
Related
Requirement 2 - Instance Level containers
This also is a general requirement in that the "UnifiedInterceptors" work needs the ability to provide instance/proxy level advisors to support instance level metadata.
At the MC level, the requirement is mainly there to support annotation overrides. Where there is no requirement to override annotations, a
ClassAdvisor
can be used.
e.g. being able to deploy multiple instances of a class with different annotations
<bean class="org.example.Bean"></bean> <!-- No annotation override --> <bean class="org.example.Bean"> <!-- Use the other security domain <annotation name="SecurityDomain" value="other"></annotation> </bean> <bean class="org.example.Bean"> <!-- Use the xxx security domain <annotation name="SecurityDomain" value="xxx"></annotation> </bean>
Requirement 3 - Annotation Overrides
Related to the above requirement, AOP allows for annotation overrides through its deployment descriptors, however there is no way to apply these to specific instances.
Requirement 4 - Annotation driven dependencies
The main purpose of the MC is to ensure that all dependencies are satisfied before trying to
create objects. The main problem this gives with AOP is that it is "pull" driven by the classloading mechanism, whereas the MC is IOC based and "push" driven.
As mentioned above, the existing "pull" driven mechanism is usually satisfatory for user applications and in no way should "push" break the "pull".
The dependencies that need to come from annotations are:
classloading - ensuring that all classes (the pojo class, introductions, mixins, interceptors/advices and annotation classes themselves) are available for attempting to anything
advice factories - ensuring that advice factories are deployed before trying to construct the advisor
annotation dependencies - some annotations hold references to other objects (either through
@Inject
or less directly e.g.
@SecurityDomain
. These need to fully constructed before the advisor is created through classloading/instantiation.
others - there are others, and these will only increase as the dependency model/capabilities of the MC improves over time.
Requirement 5 - Limited environment usage
It is still open to discussion whether AOP (because of some of its usage of
Javassist
) can be used in limited environments, e.g. a security manager is installed. Until this problem is decided one way or another, there needs to be the ability to run the MC without AOP.
This will obviously reduce the capabilities of the MC, though some of the simpler capabilities could be reintroduced via the
ClassAdapter
integration point if this is an issue for someone.
The reason for it being open to discussion, is whether AOP can actually provide some of these capabilities with the
ProxyAdvisor
. Additionally, it could be that the intersection of
features disabled by not using AOP and capable of being replaced by for example a reflection based
model is empty and that this discussion is moot.
Comments