Bill, we are going in circles. You asked me to show you where this metadata is defined in the current xml It is not, that is what we are discussing how to do here. That was my question earlier in the thread.
You say the aspect needs to get metadata from the bean class/joinpoint. I agree, that is the purpose of describe. Again annotations aren't implemented in my prototype. What I'm trying to understand is why we need two apis to get metadata at runtime. I haven't since a convincing argument for this so I will assume there isn't one. Let's take a trivial example: Somebody says they want to deploy a bean: They also want a container. There are two ways to do this. 1) They explicity wrap it in a container, either using xml or programatic definition of the equivalent bean metadata (see examples earlier). This is the long winded approach for people who want total control of what is happening (5% of cases). 2) The SAME metadata comes from the "DESCRIBE" stage. i.e. when it loads the class it discovers there are annotations and augments the metadata. i.e. it adds the metadata and interceptors into the container definition. Maybe it even adds a container to the definition if one wasn't present. This is what most people will use (95% of cases). Later, the aspect will use getMetaData() to retrieve this information. There is also a hybrid approach where there maybe both tags on the class and metadata already present in the bean metadata - e.g. the "xml" override of annotations. What I'm trying to get to is what changes do we need to plug in JBoss AOP into the MC. My conclusions so far are: 1) We need to remove all notion of container from MC. We discussed this on a different thread. 2) We need to add to the DESCRIBE stage of the MC to allow a hook where a container can be plugged. It will register back additional bean metadata like what aspects needs constructing, what metadata is present and whether these have dependencies. I see this more as a container factory since I want it to describe to MC what needs constructing using Bean MetaData rather trying to create the container objects. annotations -> BeanMetaData Letting the container factory create the container directly may not be possible because other dependencies are not satisifed (classloading, jndi binding or just plain IOC dependency). 3) The user has the option to use their own container metadata definition (long winded metadata description) to get exactly what they want rather than using the container factory. This is transparent to the MC since all it sees is Bean MetaData to contruct the container objects in the correct order. 4) We need to consider a mixture of (2) and (3) where the user wants to override what is coming from the class annotations, e.g. add an aspect, change a metadata config, etc. In (3) this may not even be an AOP container. But to take advantage of JBoss aspects it needs to follow our container spi that defines the join points/invocation/etc. Using the AOP container gives a lot more functionality than say a simple Proxy container. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3861629#3861629 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3861629 ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
