-
1. Re: JBoss AOP Integration
adrian.brock Jan 7, 2005 2:01 PM (in response to bill.burke)1) I need to understand why the get[...]Annotation() is not the same
getMetaData.
IMHO we should have one method for retrieving configuration.
Additionally, metadata from the invocation should be able to override static
annotation configuration.
Besides we should start a different thread on this important area?
2) I want the invocation/join point model external to AOP so I don't have to
include jboss-aop.jar in some deployment scenarios. i.e. microcontainer must not
import org.jboss.aop. Instead org.jboss.aop is a possible implementation of this spi.
Also, I see aop using some of the dependency injection features in some
deployment scenarios which means you have a circular reference:
microcontainer imports aop (for container)
aop imports microcontainer (for dependency injection)
3) We are discussing this on a separate thread. I don't think you have understood
my argument there. Interceptors should be added to the microcontainer's container
using dependency injection.
i.e. The container is not available publicly until the interceptors are injected
=> The container waits for interceptors to satisfy dependencies
=> Iterceptors wait for required services to be deployed
Or in summary deployed beans are not available until theire required services
are deployed. The link is via the aspect/interceptor so each service
doesn't have to explicity define all its dependencies.
e.g. a bean automatically gets a dependency on the transaction manager
when it declares transaction demarcation.
The bean@transaction required public doSomething() { }
The interceptorpublic class TransactionDemarcationInterceptor { @Inject public void setTransactionManager(TransactionManager tm) { ... } }
-
2. Re: JBoss AOP Integration
starksm64 Jan 7, 2005 2:26 PM (in response to bill.burke)I agree on the Annotation == MetaData comment. Espcially when you add in annotation overrides, annotations are just a java langague specific form of metadata with java centric scopes.
-
3. Re: JBoss AOP Integration
bill.burke Jan 7, 2005 3:09 PM (in response to bill.burke)"adrian@jboss.org" wrote:
1) I need to understand why the get[...]Annotation() is not the same
getMetaData.
IMHO we should have one method for retrieving configuration.
Additionally, metadata from the invocation should be able to override static
annotation configuration.
I don't care about the interface, but you need to have a distinction from statically defined annotations/metadata from invocation/context overriden annotation/metadata. You don't want the client overriding the allowed roles of the method, do you?
2) I want the invocation/join point model external to AOP so I don't have to
include jboss-aop.jar in some deployment scenarios. i.e. microcontainer must not
import org.jboss.aop. Instead org.jboss.aop is a possible implementation of this spi.
And I don't want AOP to have to include the microcontainer jar since it is separate.
3) We are discussing this on a separate thread. I don't think you have understood
my argument there. Interceptors should be added to the microcontainer's container
using dependency injection.
My point was that Interceptors/Aspects should be bean definitions and referenced via dependencies.
Another problem is that interceptor/Aspects will have dependencies that cannot be resolved until they are bound. If the interceptor is PER_INSTANCE, for example, the interceptor may be interested in having the target's InstanceAdvisor injected. If it is PER_CLASS, then it may be interested in the target's ClassAdvisor.
i.e. The container is not available publicly until the interceptors are injected
=> The container waits for interceptors to satisfy dependencies
=> Iterceptors wait for required services to be deployed
Or in summary deployed beans are not available until theire required services
are deployed. The link is via the aspect/interceptor so each service
doesn't have to explicity define all its dependencies.
e.g. a bean automatically gets a dependency on the transaction manager
when it declares transaction demarcation.
The bean@transaction required public doSomething() { }
The interceptorpublic class TransactionDemarcationInterceptor { @Inject public void setTransactionManager(TransactionManager tm) { ... } }
I think you made need the concept of a DynamicBean in wich the Bean's attributes do not result in a call to a setter, but rather a generic setter. Is there something like this?
Please take a look at:
http://docs.jboss.org/aop/aspect-framework/reference/en/html/xml.html#xml-aspect2
http://docs.jboss.org/aop/aspect-framework/reference/en/html/xml.html#xml-aspect3 -
4. Re: JBoss AOP Integration
starksm64 Jan 7, 2005 3:41 PM (in response to bill.burke)
I don't care about the interface, but you need to have a distinction from statically defined annotations/metadata from invocation/context overriden annotation/metadata. You don't want the client overriding the allowed roles of the method, do you?
The scope at which metadata can be introduced is a property of the metadata. Its not the static nature of the security roles that defines where it can be assigned, its the scope. A client invocation should not be able to override the allowed roles at runtime, but an admin certainly should be able to.
And I don't want AOP to have to include the microcontainer jar since it is separate.
Something needs to be the base library here. Its pointless to have the same functionality in different packages.
My point was that Interceptors/Aspects should be bean definitions and referenced via dependencies.
Its not clear why this must always be the case. If there is a pure contains relationship to any injection, be it an attribute or interceptor why can't it be defined in a embedded manner?
Another problem is that interceptor/Aspects will have dependencies that cannot be resolved until they are bound. If the interceptor is PER_INSTANCE, for example, the interceptor may be interested in having the target's InstanceAdvisor injected. If it is PER_CLASS, then it may be interested in the target's ClassAdvisor.
This is a clear case of not being a pure contains relationship. A security interceptor may depend on a specific security domain being started.
The clear rationale for bean definitions and injection via reference is to allow for canonical configuration files. The syntax argument for this would be simply that the associated schema is more likely able to be validated. -
5. Re: JBoss AOP Integration
adrian.brock Jan 7, 2005 4:10 PM (in response to bill.burke)
I think you made need the concept of a DynamicBean in wich the Bean's attributes do not result in a call to a setter, but rather a generic setter. Is there something like this?
Please take a look at:
http://docs.jboss.org/aop/aspect-framework/reference/en/html/xml.html#xml-aspect2
http://docs.jboss.org/aop/aspect-framework/reference/en/html/xml.html#xml-aspect3
Per instance and per joinpoint is also something JBossMX has.
i.e. you create an interceptor for each attribute or operation.
I didn't implement that in my prototype because I wanted to keep it simple.
This is just a different configuration. The pseudo configs I have shown above
don't include this since I wanted to keep it simple.
My plan was to have Kernel/Container/JoinPoint awareness.
This is a generalization of MBeanRegistration/ContainerPlugin
that can be implemented by the target, but I anticipate it will be more often
implemented by the aspects and subservices
to define their scope and do some optimization at deployment time.
Related is the notion of service/subservice where the microcontainer
handles deployments like the JMXInvoker/interceptors,
EntityContainer/LockManager, EJBContainer/ProxyFactory,
JDBCStoreManager/FieldBridge, etc
rather than each service having to provide its own solution.