-
15. Re: AOP/Metadata integration config
The reason for knowing about the SecurityDomain is a fundamental difference
in the deployment strategies of AOP vs MC
In AOP if the advice is not deployed it is not included in the stack.
If a depdendency of the advice is not deployed you find out after requests are
being processed with a runtime exception.
I don't think you understand how I am doing this AOP/MC integration.
When the AOP deployer sees an Aspect declaration, it will create a GenericBeanFactory and install it into the Microconatiner. It will also register AOP specific metadata about the Aspect into the AspectManager.
When a binding is defined, the AOP Deployer creates an InterceptorFactory and registers the metadata for binding the advice/aspect to the class. This InterceptorFactory has a reference to the Kernel. When a Class is statically initialized, it tries to create advice chains. This is when the InterceptorFactory tries to lookup the GenericBeanFactory.
In the MC if the advice and its dependencies are not installed the object is not created
and the user is told to deploy the missing dependency.
And this works, so what is the problem? ClassAdapter.getDependencies() is currently called before class static initialization and the aspect dependencies propagated. Did you see that I implemented and tested this?
The SecurityDomain example is a different example. This is because knowledge of the dependency is hidden in the annotations. So, I thought our agreement was that this annotation would have a @Dependency annotation on it:@Dependency(attribute="value") public @Interface SecurityDomain { String value(); }
Either the MC or AOP is gonna have to look at every single annotation attached to the class (and superclass) for this @Dependency annotation and add it to the BeanMetaData dependency list. Correct? I'm fine with adding this to the AspectAdapter. -
16. Re: AOP/Metadata integration config
"adrian@jboss.org" wrote:
"bill.burke@jboss.com" wrote:
I think you are going way overboard with dependency management here.
I think this goes to heart of the disagreement.
My vote is for using picocontainer with limited ability to support hot-deployment
or correctly startup a disparate group of loosy couple modules.
Leaving me to get on with doing something more useful than arguing about DI.
The "overboard" I'm talking about is publishing dependencies before the class is loaded so that class loading is aware of aspect dependencies as well.
I think publishing aspect dependencies after the class is loaded and before class static initialization, will work just fine without to much disruption in so many codebases. -
17. Re: AOP/Metadata integration config
"adrian@jboss.org" wrote:
On the joinpoint model:
This is serving more than just a dialogue between the MC and AOP.
It is acting as a cache for the reflection style objects.
Then cache these objects. AOP still has to intercept bean allocation. I can't get around that. Also resolving dependencies also needs to be aware of additional annotations and metadata that is attached to the bean.
Resolving reflection objects is much more expensive than using them
which is why the current EJB/JMX containers preresolve these objects.
Yes, AOP caches the same information as well to speed up invocations.
Bill -
18. Re: AOP/Metadata integration config
"bill.burke@jboss.com" wrote:
I don't think you understand how I am doing this AOP/MC integration.
It is more likely I don't understand your own description of what you have done :-)
In the MC if the advice and its dependencies are not installed the object is not created
and the user is told to deploy the missing dependency.
And this works, so what is the problem? ClassAdapter.getDependencies() is currently called before class static initialization and the aspect dependencies propagated. Did you see that I implemented and tested this?
Yes.
The SecurityDomain example is a different example. This is because knowledge of the dependency is hidden in the annotations.
I thought you had started arguing that this could not be done?
So, I thought our agreement was that this annotation would have a @Dependency annotation on it:
Yes.
Either the MC or AOP is gonna have to look at every single annotation attached to the class (and superclass) for this @Dependency annotation and add it to the BeanMetaData dependency list. Correct? I'm fine with adding this to the AspectAdapter.
I don't think it matters who does it as long as it gets done. I thought we agreed
that it would be done by MC since it could be potentially looking at classes
that AOP doesn't care about.
The main issue now I think is how the MC gets hold of the annotations if there
is no ClassInfo. It looks like it falling back on reflection. -
19. Re: AOP/Metadata integration config
"adrian@jboss.org" wrote:
It will take me a while to digest your proposal.
I don't see the meat of it (how it could possibly work) at the moment.
But, don't you see it already works? The only situation I didn't handle was the factory. The AspectAdapter solves this.
At first blush, this looks like my original proposal, which was that the MC would
push all the metadata to the AspectManager, but we decided against that solution
because
I thought your original proposal was to write your own AOP abstraction SPI that AOP had to somehow fit into, or to write your own "lightweight" AOP model to support all the JMX stuff.
1) it would require the MC understanding all the point cut expressions, etc.
It doesn't. Metadata would be created like any other attribute, map, list, etc...You'd be creating JBoss AOP metadata instances like you would with any other embedded bean attribute. The MC doesn't know about anything, it is just creating a bunch of beans and attaching them to the BeanMetaData instance. It is up to the AspectAdapter to to make sense of the metadata, not the MC.
i.e. understanding the cross cutting.
2) users can still deploy using jboss-aop.xml which the MC wouldn't know about.
And I assumed from the beginning that users would deploy using jboss-aop.xml. It would be the job of the AOP Deployer to interact with the MC and create the required extra metadata and bean registrations. This is actually how I have it implemented in the tests.
Instead, we decided on the query approach where the MC asks the AOP
layer "what would it mean if I created an instance of this object" during the
describe stage.
And again, this is how I have it implemetned currently. What is missing is factory support. Again, AOP needs to intercept construction for any bean. It needs BeanMetadata (the annotation overrides and per-bean aspect bindings)
I don't see why the ClassAdapter inside the BeanInfo creates a problem.
The BeanInfo is just a description of the class after AOP has played with it
and it is per ClassAdapter (which could be instance level) not per Class.
Then come up with another interface where AOP can intercept bean allocation (whether it be by a constructor or a factory) and have knowledge of Beanmetadata. -
20. Re: AOP/Metadata integration config
The "overboard" I'm talking about is publishing dependencies before the class is loaded so that class loading is aware of aspect dependencies as well.
I think publishing aspect dependencies after the class is loaded and before class static initialization, will work just fine without to much disruption in so many codebases.
Ok, we will have to disagree on this one (but not about the disruption).
Would you care to make a wager on whether this problem ever comes up on the forums
or as a support case? :-) -
21. Re: AOP/Metadata integration config
"bill.burke@jboss.com" wrote:
I thought your original proposal was to write your own AOP abstraction SPI that AOP had to somehow fit into, or to write your own "lightweight" AOP model to support all the JMX stuff.
That was actually a later argument on whether we should support other peoples
invocation models which we rejected.
The JMX stuff was about mapping jmx invocations
JMXGetAttribute("UpperCaseStyle") to AOPMethodInvocation("getUpperCaseStyle");
which we also rejected as too complicated and unnecessary since a DynamicMBean
can do this without the need for JMXGetAttribute objects. -
22. Re: AOP/Metadata integration config
"adrian@jboss.org" wrote:
The "overboard" I'm talking about is publishing dependencies before the class is loaded so that class loading is aware of aspect dependencies as well.
I think publishing aspect dependencies after the class is loaded and before class static initialization, will work just fine without to much disruption in so many codebases.
Ok, we will have to disagree on this one (but not about the disruption).
Would you care to make a wager on whether this problem ever comes up on the forums
or as a support case? :-)
I think the price is going to be too high, both in performance hits and development cycles, which is why I am not interested in solving this problem. -
23. Re: AOP/Metadata integration config
"adrian@jboss.org" wrote:
I don't mind the MC using the AOP annotation metadata format. My only concern would be
the potential in future for an annotation to include data that also requires DI.
An interesting use case, but I have no desire to rewrite an entire annotation override facility just to support this. -
24. Re: AOP/Metadata integration config
"bill.burke@jboss.com" wrote:
Then come up with another interface where AOP can intercept bean allocation (whether it be by a constructor or a factory) and have knowledge of Beanmetadata.
With your latest qualifications the AspectAdapter[Factory] sounds like it will work.
But there is a big assumption that class resolution and/or not yet deployed classes
isn't going to be cause problem.
I just want to confirm the following lifecycle. It is nearly equivalent to the original
proposal but with different objects.
MC DESCRIBE:
Use AspectAdapterFactory to get an AspectAdapter for the Class and its metadata.
Use getDependencies to retrieve all dependencies (whether this is just what AOP thinks is important and MC needs to do extra work on top is unimportant)
MC INSTANTIATE:
Use AspectAdapter to get the joinpoint and dispatch the construct/factory request. -
25. Re: AOP/Metadata integration config
"adrian@jboss.org" wrote:
Use AspectAdapterFactory to get an AspectAdapter for the Class and its metadata.
metadata == BeanMetaData including annotations. -
26. Re: AOP/Metadata integration config
"adrian@jboss.org" wrote:
But there is a big assumption that class resolution and/or not yet deployed classes
isn't going to be cause problem.
I think this is virtually certain by the way, but mostly in use cases that
involve either our own core services or where one top level deployment is
referencing another and hot deployment is required.
In fact, without this knowledge, automatic redeployment of related top level deployments
because they share a classloader space becomes very difficult, if not impossible.
And we are back with the all the stupid forums questions about ClassCasts, etc. -
27. Re: AOP/Metadata integration config
"adrian@jboss.org" wrote:
"adrian@jboss.org" wrote:
But there is a big assumption that class resolution and/or not yet deployed classes
isn't going to be cause problem.
I think this is virtually certain by the way, but mostly in use cases that
involve either our own core services or where one top level deployment is
referencing another and hot deployment is required.
In fact, without this knowledge, automatic redeployment of related top level deployments
because they share a classloader space becomes very difficult, if not impossible.
And we are back with the all the stupid forums questions about ClassCasts, etc.
Besides the ammount of effort it would take to implement this, do you really think this would ever perform well? Not only do you have to analyze the class and create parallel java.lang.reflect datastrucutres (which takes an absorbent amount of time), but what if the component does dynamic class loading?
Because of has, hasfield, and annotations, AOP needs a lot of the information of the structure of a class so I don't see much optimization that can be done here. -
28. Re: AOP/Metadata integration config
"bill.burke@jboss.com" wrote:
Besides the ammount of effort it would take to implement this, do you really think this would ever perform well? Not only do you have to analyze the class and create parallel java.lang.reflect datastrucutres (which takes an absorbent amount of time), but what if the component does dynamic class loading?
Because of has, hasfield, and annotations, AOP needs a lot of the information of the structure of a class so I don't see much optimization that can be done here.
First, I'm not saying we do all the effort now, especially if we have known
performance problems. My concern (as I said earlier) is that it does not become
impossible, e.g. because we are locked into an api that requires the classes loaded.
Like you I develop iteratively, so the first implementation will be based on manifest
references (this jar needs this other jar) and package demands to capture
non-obvious dependencies.<deployment> <demand type="package">com.acme.blah</demand> etc.
this will solve most problems for the initial bootstrap, and force a full teardown
of the deployment and restart.
But there are other requirements (down the road)
that make this "belt and braces" approach undesirable.
1) Near seemless redeployment (redeploy in the background then cutover the gateway to the service, e.g. the jndi binding/socket or whatever)
2) Transactional redeploy (similar to 1 - but only do the cutover when all machines/services are sucessfully redeployed).
3) etc.
Fundamentally, it is being able to spot the difference between doing a full redeploy
because the classes changed (redeploy the jdbc driver) and an almost instantaneous cutover if you just change config (the datasource).
Although the jdbc driver is a bad example since you are hardly ever going to switch driver
versions on a running machine unless you are developing one.
Other more user orientated examples are not.
Finally, I don't necessarily need all the ClassInfo to do this, just the ability not to the load class.
We mainly went down the ClassInfo road because it gives an extended reflection
model that could be used by both AOP and MC. If it is bad, lets replace it with
something else.
Finally 2, I also don't believe that the performance problems are something that
cannot be overcome. The JDK does a pretty good job at analysing byte code
(probably doing more work than javassist) in a performant fashion.
This is all moot for 4.0.3 since the JMX MC will be handling classloading. -
29. Re: AOP/Metadata integration config
Incidently, I would prefer the AspectAdapterFactory had a similar api to the others
in the container model:public interface ClassAdapterFactory { ClassAdapter getClassAdapter(String name, ClassLoader cl) throws ClassNotFoundException; ClassAdapter getClassAdapter(Class clazz); }
Then the underlying implementation can choose whether it actually needs to load
the class on the first method.
i.e. whether classloading is required is then a quality of implementation detail.