From: <bil...@jb...> - 2005-04-28 01:53:56
|
"ad...@jb..." 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. anonymous wrote : | 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. anonymous wrote : | 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. anonymous wrote : | 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. anonymous wrote : | 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) anonymous wrote : | 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. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875702#3875702 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875702 |