"[EMAIL PROTECTED]" wrote : anonymous wrote : | | anonymous wrote : | | | It also unclear how the current AOP annotations/xml will feed into the configuration | | | in particular with relation to dependencies. | | | | | | | The security aspect is a perfect example here. The way I have it implemented now in my aspect code is that the security aspect is allocated via a JBoss AOP aspect factory. When the factory goes to create the aspect (on a per class or per EJB container basis) it queries the container for the @SecurityDomain annotation and based on that annotation, looks up the domain in JNDI. | | | | But you don't know at the aop level that the SecurityDomain has been deployed yet. | |
No you don't, but you need to query some service for the dependency. Here's why: AOP works with classes instances that may not be registered as beans in the kernel. Consider this: | <bind expr="* @SecurityDomain->@Unchecked(..)"> | <interceptor-ref name="AuthenticationInterceptor"/> | </bind> | This states that any @Unchecked method of any class annotated with @SecurityDomain should have an authentication interceptor attached to it. The Authentication interceptor cannot be created without knowing the securit domain. So, the interceptor factory needs to ask the class for its @SecurityDomain annotation so that it can lookup the security domain. Another thing I'm not sure you understand yet is that aspect definitions are declared before the beans, classes, or object instances they aspectize are even known. The advice bindings themselves(as in the above example) can be declared before beans and classes are loaded as well. Without this ability there's no way to have an aspect library that are based on annotations. The advice/interceptor bind process does not happen until a class is loaded. The main problem here being is that sometimes the aspect cannot specify or know its dependencies until it is bound into the thing it is aspectizing. anonymous wrote : | anonymous wrote : | | So how will this work with XML? The way I'm going to implement is that the EJB 3 deployer creates the container and then parses the XML. It will see the <security-domain> element and allocate an instance of the @SecurityDomain annotation and add it as an override to the class. That way there is a consistent Object model for configuration (the annotation class). This also allows you to totally mix and match XML and annotations together. | | | | Incorrect. There should be no dependency on XML. All configuration should be | turned into generic MetaData java Object graph. | | That not what I'm saying at all. I'm saying config COULD come from XML and that the common meta objects are instances of annotations rather than YET ANOTHER metamodel. Annotations in and of themsleves are meta objects. anonymous wrote : | The join point model I wrote does not require classloading. In fact, I deliberatly | removed all notion of class/method/etc from the abstraction at the top level | so you can create any sort of join point. | Even for those class/method/field join points I keep to a String representation | of the join point since the classes may not actually be loaded at DESCRIBE | (define the deployment) time. | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3861457#3861457 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3861457 ------------------------------------------------------- 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
