[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: AOP/Metadata integration config

[<bil...@jb...>]

"ad...@jb..." wrote : I'm confused again. We always seem to be on completely different wavelengths :-)
  | 
  | 1) I already had a MAP in the original implementation, but changed it to Annotation
  | since we agreed that all config will come from annotations (as opposed to ad hoc
  | invocation payload)
  | 

THis metadata I added has nothing to do with ad hoc invocation payloads.  The metadata is needed by the ClassAdapter to resolve aspect dependencies and for the ConstructorJoinpoint so that it can either create a proxy or modify the object instance's InstanceAdvisor. 

anonymous wrote : 
  |  and this would make it easier for construct/configure from xml. 
  | 

JBoss AOP already has an annotation override facility.  What I added allows MC to take advantage of this facility without also tying MC to this facility.

anonymous wrote : 
  | In fact, there is an open issue on whether the MC should just use AOP's annotation
  | metadata model.
  | 

This sure would make things easier.

anonymous wrote : 
  | There is even a test in the jboss-aspects module using AbstractAnnotationMetaData:
  | http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-aspects/src/tests/org/jboss/test/aspects/microcontainer/test/InterceptorTestCase.java?rev=1.1&view=markup
  | 

If you want to fully redo what JBoss AOP already does, be my guest, but count me out...

anonymous wrote : 
  | Did you know that about FeatureMetaData or even the tasks I created after our Boston
  | meetings?
  | http://cvs.sourceforge.net/viewcvs.py/jboss/microkernel/src/main/org/jboss/beans/metadata/plugins/AbstractFeatureMetaData.java?r1=1.4&r2=1.5
  | http://jira.jboss.com/jira/browse/JBMICROCONT-18
  | 

Sure saw it, but again, didn't want to rewrite the entire JBoss AOP annotation facility.  

anonymous wrote : 
  | 2) It is too late to pass this in the join point constructor isn't it? I need to tell JBoss/AOP
  | about the annotations to find out what they mean in terms of dependencies????
  | 
You mean for dependencies like the SecurityDomain example?  I don't see why you need to tell JBoss AOP these dependencies.  JBoss AOP doesn't care about dependencies.  It really depends on who is analyzing the annotations for the @DependsAttribute annotation (or whatever it will be).  If it is the microcontainer, then no, it is not too late as the microcontainer can just add these to the dependency list itself.

anonymous wrote : 
  | This cannot be done at the construction stage, it must be done during DESCRIBE.
  | Otherwise, the MC/AOP integration serves no purpose.
  | 
  | 
  |   |    
  |   |    /**
  |   |     * Get a constructor join point
  |   |     * 
  |   |     * @param constructorInfo the constructor info
  |   |     * @param metadata // THIS IS TOO LATE
  |   |     * @return the constructor join point
  |   |     * @throws JoinpointException when no such constructor
  |   |     */
  |   |    ConstructorJoinpoint getConstructorJoinpoint(ConstructorInfo constructorInfo, Map metadata) throws JoinpointException;
  |   | 
  | 
  | Maybe you have simplied this or found a way around the problem? But it
  | seems pretty fundamental to me?
  | 

Did you see that I added passing metadata to ClassAdapter.getDependencies()?  getConstructorJoinpoint needs to know about annotation overrides, mixin definitions, etc... because the ConstructorJoinpoint itself needs to know about this information so that it knows wheter or not to create a proxy (if the class is not weaved) or to interact with the per-instance InstanceAdvised interface.  If you do not pass in these annotation overrides into the ConstructorJoinpoint, then the ConstructorJoinpoint does not have the exact information it needs to make its decisions.

anonymous wrote : 
  | To repeat the only reasons for the reflection model are:
  | a) I need to be convinced that JBoss/AOP (really javassist) can be used in all environments
  | 

THis idea that everything has to work in all environments with the 1st iteration or even the first release of MC, MC+AOP is just stupid.  Iterate!

I've taken out the Javassist requirement for the MC /AOP integration.  I've posted how/why on architecture council email list, I'll repost here.

Load-time AOP probably just will not work on all environments.  AOPC precompilation should work in all environments because Javassist is take out of the equation.  If you have look at my MC/AOP integration code and tests you'll see that it supports a proxy based model.  Currently proxies are created by Javassist for performance and flexibility reasons, but this could be changed to be fully java.lang.reflect.Proxy based if you so desire.

anonymous wrote : 
  | b) AOP's ClassAdapter wasn't finished but I needed to work on other things
  | 

AOP's ClassAdapter is not fully finished.  I'll talk about this in another post.

anonymous wrote : 
  | If (a) can be satisfied, (i.e. in all circumstances no matter what the security/memory
  | restrictions are JBoss/AOP/Javasssit can be used) then I don't have any problem
  | with predecating JBoss/MC on JBoss/AOP and the need for an abstract
  | integration "ClassAdapter" disappears.

(a) cannot uniformily be solved by JBoss AOP unless AOPC precompilation is a requirement.  If you dislike AOPC precompilation as a requirement, then you just have to deal with less AOP funtionality and use proxies.  JBoss AOP can support this and does partially support it now.

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

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