-
1. Re: Proxy implementation and advisors
bill.burke Apr 18, 2005 2:26 PM (in response to adrian.brock)Look at the EJB3 code for examples, but it uses something called a ClassContainer. (I know the names are confusing).
My thinking was a proxy (java.lang.reflect or a javassist one) that creates an invocation and delegates to this ClassContainer.Eventually, the InstanceAdvisor will be replaced by some extension of the ClassContainer and we'll have unified APIs for adding advices/interceptors to a proxy or to an instance.
As far as your problem goes, if you want to use @MBean with weaving you DO NOT have to have control over classloading. Just use the AOPC compiler. For @Mbean anyways, we should pick one or the other. Either weave or don't weave.
BTW, why don't you finish GenericBeanFactory instead of looking at this stuff? -
2. Re: Proxy implementation and advisors
adrian.brock Apr 18, 2005 2:40 PM (in response to adrian.brock)"bill.burke@jboss.com" wrote:
Look at the EJB3 code for examples, but it uses something called a ClassContainer. (I know the names are confusing).
My thinking was a proxy (java.lang.reflect or a javassist one) that creates an invocation and delegates to this ClassContainer.Eventually, the InstanceAdvisor will be replaced by some extension of the ClassContainer and we'll have unified APIs for adding advices/interceptors to a proxy or to an instance.
As far as your problem goes, if you want to use @MBean with weaving you DO NOT have to have control over classloading. Just use the AOPC compiler. For @Mbean anyways, we should pick one or the other. Either weave or don't weave.
My thinking was the class adapter would go through something like the following logic:
Object implements Advised -> InstanceAdvisor
(!Object implements Advised) && canWeave -> Runtime Weaving
(!Object implements Advised) && canWeave == false -> ProxyAdvisor
With this being transparent to the "user", i.e. me JMX.
My problem with using AOPC is that I cannot predicate a standalone MBeanServer
on the user using AOPC. They just do:MBeanServer server = MBeanServerFactory.createMBeanServer(); server.registerMBean(objectName, new MyMBean());
In this case, MyMBean.class is not weaved for AOP and it is too late
to do it in registerMBean because they already loaded the class.
What I want to do inside registerMBean is use an AOP domain configuration
to wrap the MBean in advices, but regardless of the advisor implementation.
This is one of those backward compatibility requirements. -
3. Re: Proxy implementation and advisors
adrian.brock Apr 18, 2005 2:44 PM (in response to adrian.brock)"bill.burke@jboss.com" wrote:
BTW, why don't you finish GenericBeanFactory instead of looking at this stuff?
Because it is already done:
http://jira.jboss.com/jira/browse/JBMICROCONT-21
http://cvs.sourceforge.net/viewcvs.py/jboss/microkernel/src/main/org/jboss/beans/metadata/plugins/factory/GenericBeanFactory.java?rev=1.1&view=markup
but the xml deployment is outstanding:
http://jira.jboss.com/jira/browse/JBXB-5 -
4. Re: Proxy implementation and advisors
adrian.brock Apr 18, 2005 2:53 PM (in response to adrian.brock)"adrian@jboss.org" wrote:
What I want to do inside registerMBean is use an AOP domain configuration
to wrap the MBean in advices, but regardless of the advisor implementation.
Well actually, going forward, this will more annotation driven rather than thepublic class XXX implements XXXMBean
pattern.
But the class still might not be pre-weaved. -
5. Re: Proxy implementation and advisors
adrian.brock Apr 18, 2005 3:01 PM (in response to adrian.brock)"bill.burke@jboss.com" wrote:
BTW, why don't you finish GenericBeanFactory instead of looking at this stuff?
To more completely answer your question, I am at an impass waiting for:
AOP integration
JBossXB parsing
and to a lesser extent classloading.
So I've moved up the stack and I'm now looking at how we integrate JMX/MicroContainer
which basically involves using the same advice stack to wrap the POJOs regardless of which api is used to register/invoke them.
Which has come back to the AOP integration again :-) -
6. Re: Proxy implementation and advisors
bill.burke Apr 18, 2005 3:07 PM (in response to adrian.brock)"adrian@jboss.org" wrote:
My thinking was the class adapter would go through something like the following logic:
Object implements Advised -> InstanceAdvisor
(!Object implements Advised) && canWeave -> Runtime Weaving
(!Object implements Advised) && canWeave == false -> ProxyAdvisor
With this being transparent to the "user", i.e. me JMX.
In your example the Class adaptor not only has to do the above, but also is it already woven. We do not want to do all this pre-processing at class load time or this "lightweight" container will take forever to boot up. The slow pre-processing is the same reason I did not want to have javassist create ClassInfo structures.
This is one of those backward compatibility requirements.
This is far from a backward compatibility requirement considering we don't have an official @MBean implementation. -
7. Re: Proxy implementation and advisors
bill.burke Apr 18, 2005 3:20 PM (in response to adrian.brock)The hard part about the GenericBeanFactory is creating all the metadata. Also, how about all the metadata overrides? I think this should be a separate API with the ClassAdapter instead of the way we proposed it in Boston. Not only would this get rid of the need for javassist to preprocess and create ClassInfo's, but it would also not force me to totally refactor (practically rewrite) jboss AOP to use ClassInfo's to bind aspects.
-
8. Re: Proxy implementation and advisors
adrian.brock Apr 18, 2005 3:29 PM (in response to adrian.brock)
In your example the Class adaptor not only has to do the above, but also is it already woven. We do not want to do all this pre-processing at class load time or this "lightweight" container will take forever to boot up. The slow pre-processing is the same reason I did not want to have javassist create ClassInfo structures.
I thought you already had an option for whether it does the weaving at runtime?<mbean code="org.jboss.aop.deployment.AspectManagerService" name="jboss.aop:service=AspectManager"> <!-- HERE --> <attribute name="EnableTransformer">false</attribute>
This is far from a backward compatibility requirement considering we don't have an official @MBean implementation.
I'm talking about when it doesn't (that's why I said "going forward")
i.e. it follows the old fashioned Standard MBean pattern described above.
1) I want to be able to register it in the mbean server (backwards compatibility) but also
make it available via injection in the MC.
2) Vice-versa, register a javabean written for the MC and add @MBean (not backwards compatible because this obviously didn't exist previously like you say).
Whichever method is used, I only want to maintain one implementation of the advices
and adding things like role based security should just be done with the standard aop advice.
OFF-TOPIC:
Even though in practice I cannot even do that because for a while (a few versions hence)
because I have to maintain XMBean (along with its inteceptor model)
but as just another ModelMBean implementation
(this also for backwards compatibility since we have users using it). -
9. Re: Proxy implementation and advisors
adrian.brock Apr 18, 2005 3:34 PM (in response to adrian.brock)"bill.burke@jboss.com" wrote:
The hard part about the GenericBeanFactory is creating all the metadata. Also, how about all the metadata overrides? I think this should be a separate API with the ClassAdapter instead of the way we proposed it in Boston. Not only would this get rid of the need for javassist to preprocess and create ClassInfo's, but it would also not force me to totally refactor (practically rewrite) jboss AOP to use ClassInfo's to bind aspects.
I've got to the stage where I don't care and just want something that works. :-)
Even if it is just the simple use cases.
Without something concrete to build on and write test cases to show missing features, it
is just lots of arguments in the forums and more delays.
I've already been through a couple of refactors (both the Bean model and xml)
and still don't know what the final api looks like, that's why I call it an impass and started
working on other things. -
10. Re: Proxy implementation and advisors
adrian.brock Apr 18, 2005 3:51 PM (in response to adrian.brock)Simple usecase tests for AOP/MC integration:
http://jira.jboss.com/jira/browse/JBAOP-109
Assigned to me.... -
11. Re: Proxy implementation and advisors
adrian.brock Apr 19, 2005 12:51 PM (in response to adrian.brock)I've started this - commit message:
Some kernel/aspect tests for annotations. To run: compile for Java5 then ant -f build-test50.xml run-tests TODO: Fix the dependency aspect so it works, I'm only doing this to simulate field field injection which isn't *yet* in the BeanInfo model. TODO: Didn't realise until too late that there is already is a test50 source directory and associated build (needs consolidating)
I'll fix the dependency aspect later today, I've got to look at a bug that is
holding up Francisco.