Re: [aspectwerkz-user] Re-visitng AspectWerkz

My answers inlined in your email below.
Alex

On 4/22/05, [email protected]
<[email protected]> wrote:

> I use the term "interceptor" instead of "aspect" (that are self-contained in
> AW) because in my case the "binding" of an advice to one or more pointcuts
> should be external or at least easy to accomplish without having to
> re-deploy the aspect. 

That is an important difference especially in AW 2.
Aspects contains advice and can be hotdeployed programmatically
We also provide "interceptors" thru the "Advisable" API and aop.xml element.
The difference in AW is that for "interceptor" you really "new" them
and register them thru an API like addAdvice(poincut,
interceptorInstance), removeAdvice(pointcut, interceptorClass), but
those are attached to one and only one target instance (per instance
interception), while aspects have predefined life cycle (perJVM,
perClass, etc ) and don't provide an API to bind them to one single
instance.
We still name the interceptor "advice" some time since we provide
before / after / around interception.
Another difference is that Aspect can expose arbitrary context (f.e.
the first argument only, as an "int"), while interceptor will expose
only the "JoinPoint" thus providing boxed (arguments boxed as
Object[]) access to the context.
See package org.codehaus.aspectwerkz.intercept
http://cvs.aspectwerkz.codehaus.org/viewrep/aspectwerkz/aspectwerkz4/src/main/org/codehaus/aspectwerkz/intercept/AroundAdvice.java?r=1.1
http://aspectwerkz.codehaus.org/new_features_in_2_0.html#Per_instance_interception


> We are using AOP as a "tool" and not as "coding style" for the purposes of
> policy enforcement on our EJBs. Our policy enforcement mechanism is expected
> to allow binding at run-time any number of "interceptors" to one or more
> "pointcuts" where these pointcuts would basically reflect individual
> operations on the EJB. Similarly there should be capability to detach these
> interceptor bindings and swap them for something else. It would be a bonus
> if there was a capability to compose one or more commonly used interceptors
> inside a stack and attaching this stack to a pointcut. 

Aspects' advice are executed like a stack as long as there is 2 or
more bound to the same joinpoint (ie same pointcut, or 2 pointcuts or
more whose intersection is not empty). The precedence rule is clearly
defined.
For interceptor (Advisable as explained just before), precedence is
porgrammatically controlled.

> a)       At deployment time of the EJB I would like to pre-compile the
> classes based on the pointcuts which are one for each of the operations.
> There may be some or no interceptor binding definitions at this point but in
> essence "preparing" the target to accommodate interceptors for the future. 

I would use a "deployment scope" (see doc below) to hot deploy aspects
(this means "prepare" for later aspect binding), or I would use the
"advisable" for later interceptor programmatic binding. Both will
appear in your aop.xml
The difference is again the difference between "aspect" and "interceptor"
http://aspectwerkz.codehaus.org/new_features_in_2_0.html#Hot_deployment_and_undeployment_of_aspects
http://aspectwerkz.codehaus.org/new_features_in_2_0.html#Per_instance_interception

> b)       To be able to deploy a new "interceptor" at run-time which means
> class-loading the code, etc and make it available for attaching and
> detaching them to already "deployed" pointcuts. 

Our hot deployment API for aspects or our Advisable API for
interceptor allow that but without class loading the code. This is a
purely runtime operation.
For hot deployment of aspects it is performant on Java 5 JVM since it
is using the HotSwap API in the VM. Prior to Java 5 you have to use
the -Xdebug flag and use our own dll / so native port of this API, so
it s probably not good for production - again prior to Java 5.
For Advisable there is no such constraints (mainly because the
interceptor contract is defined as rock solid thru the
org.codehaus.aspectwerkz.intercept.* interfaces as explained in the
first part of my reply).


> c)       To be able to swap one or more interceptors at run-time from
> pointcut binding. This is basically the capability to attach and detach
> interceptors to and from pointcuts that are essentially EJB operations. And
> at the time of the service invocation, the effect of interception is
> realized instantly. 

Nothing to add there. Both hot deploy / undeploy aspect and add/remove
interceptor will do the job. With interceptor you really attach to one
instance. With aspect, it will crosscut according to the aspect
contract (deployment per clause and pointcuts)
 
> d)       To be able to define one or more attributes/parameters on an
> Interceptor that is nothing but ad-hoc name-value pairs and should be
> visible inside the interceptor code. 

We provide that for aspects thru the aop.xml
See http://aspectwerkz.codehaus.org/xml_definition.html#Passing_parameters_to_aspects
with http://aspectwerkz.codehaus.org/implementation.html#Aspects
For interceptor, you implement and interface and "new" your
interceptor, so pass whatever you need, including rich structures.

> e)       To be able to define one or more attributes/parameters as
> "meta-data" at the class and method level and there should be a capability
> to read this meta-data from within the interceptor code assuming it is bound
> to the right pointcut. 

See our Annotation API (works for both Java 5 annotations and doclet
styled annotation providing you use AnnotationC).
See also http://backport175.codehaus.org
Pointcut fully support matching on annotation (class level, method /
constructor level / field level).

> f)         To be able to "name" interceptors borne out of the same class so
> that I could create an "Interceptor1(class=com.xyz.Interceptor) and
> Interceptor2(class=com.xyz.Interceptor) and have different attribute values
> for each of them to be used for different purposes. 

Not tied to AspectWerkz. "Advisable" API for  interceptor should fit.

 
> I was able to do a good deal of this in AW 0.9 but the strategy considerably
> changed after that and I switched to JBoss-AOP which allowed me to do all of
> this. But for various reasons I'm also interested in AW considering there is
> a lot of interest around it and with AspectJ integration. 
> 

Take care. The 0.9 aspect model was really different from what it is now.
Take time to wonder if you want aspects or if you want "interceptor"
as per AspectWerkz 2.x wordings.

Alex





>   
> 
> It wasn't obvious to me as to what I can or cannot do with 2.0. Your
> analysis and inputs are greatly appreciated. 
> 
>   
> 
> Thanks 
> 
> Rajiv Kadayam 
> 
>