Re: [aspectj-users] XDoclet integration?

[Ramnivas Laddad <ramnivas@xxxxxxxxx>]

Ron,

I have been looking into it, but haven't ventured into implementing 
so far. My thinking has been pretty much along the line you specified
(an alternative to the participant pattern).

The main aim for such integration would be to automatically create
subaspects for implementing concerns such as transaction management.
I think keeping the input source intact and generate additional
files (aspects) will be a simpler and more explainable solution.

For example, if I had a class as follows:
public class Account {
    /**
     * @transaction required
     */
     public void credit(float amount) {
        ...
     }

    /**
     * @transaction required
     */
     public void debit(float amount) {
        ...
     }

     ...
}

And the base transaction aspect as follows:

public abstract aspect AbstractTransactionAspect {
    abstract poitncut transactedOperations();

    Object around() : transactedOperations() {
          // begin, commit, rollback logic
    }
}

XDoclet integration would generate the following concrete 
aspect to create a system specific subaspect:

/** XDoclet generated -- do not hand-modify **/
public aspect SystemTransactionAspect 
      extends AbstractTransactionAspect {
    public pointcut transactedOperations()
         : execution(void Account.credit(float amount))
           || execution(void Account.debit(float amount))
}

Now users won't need to understand the details of the 
transaction aspects; simply understanding the tags and
XDoclet task will suffice.

Asides: 
1. Use of semantically meaningful tags such as @atomic instead 
   of @transaction may be better suited
2. More sophisticated transaction management may be supported 
   such as required-new vs. required. Perhaps AspectJ/XDoclet
   integration for transaction management may use the same
   tags as EJB/XDoclet integration.

-Ramnivas

--- Ron Bodkin <rbodkin@xxxxxxxxxxx> wrote:
> Has anyone looked at integrating AspectJ with XDoclet? I was thinking
> this could be helpful to prototype uses of metadata with AspectJ
> programs. With JSR-175 now available for community review, this seems
> like an opportune time. It should also be instructive in thinking
> about what pointcuts and compiler support will be required for 175...
>  
> I think it would be possible to use XDoclet to generate code like
> this:
>  
> /**
> @tag attr="val"
> */
> class Foo {...}
>  
> ->
>  
> public interface tagMarker {}
> class Foo implements tagMarker { ... }
>  
> and
>  
> class Foo {
>     /** @tag */ void methodA(int x) { ... }
>     /** @tag */ int methodB() { ... }
>     /** @tag */ int field;
> }
>  
> ->
>  
> public abstract aspect tagReader { 
>     abstract public pointcut tagExecution();
>     abstract public pointcut tagGet();
>     abstract public pointcut tagSet();
> }
>  
> /** empty class that contains any user-defined code to access these
> pointcuts */
> public abstract aspect tagReaderExtension extends tagReader {
> }
>  
> class Foo {
>     // use the participant pattern: an alternative is to generate
> concrete
>     // pointcuts in the tagReader aspect that contains all the
> pointcuts
>     static aspect MetadataParticipant extends tagReaderExtension { 
>         public pointcut tagExecution() : 
>             execution(void Foo.methodA(int)) || execution(int
> Foo.methodB());
>         public pointcut tagGet() : get(int Foo.field);
>         public pointcut tagSet() : set(int Foo.field);
>      }
>      void methodA(int x) { ... }
>      int methodB() { ... }
> }
>  
> This would allow writing pointcuts that refer to tagged methods,
> interfaces, or classes. From a first look at how XDoclet generation
> works, this looks like it would be relatively straightforward.
> However, I've not tried to write custom XDoclet code before, so I'm
> curious if anyone who has could comment on the feasibility and ease
> of doing this. Would it be easier if we limited it to only generating
> new files instead of adding code to existing ones?
>  
> Ron
>  
> p.s. I believe it would also be possible to generate a way of
> accessing attributes for the tags as follows. However, this seems
> rather klunky, so I'd sooner wait til there's a primitive pointcut
> descriptor to access them than use XDoclet code generation...
>  
> /**
> @tag attr="val"
> */
> class Foo {...}
>  
> ->
>  
> interface tagMarkerInterface {
>     String getAttr();
> }
>  
> aspect tagReaderMarkerInterface {
>     String tagMarkerInterface.attr;
>  
>     public String tagMarkerInterface.getAttr() {
>         return attr;
>     }
>  
>     before(Foo obj) : initialization(Foo.new(..)) && target(obj) {
>         obj.attr = "val";
>     }
> }
>  
> class Foo implements tagMarkerInterface { ... }
>  
> and
>  
> class Foo {
>     /** @tag attr="val1" */ void methodA(int x) { ... }
>     /** @tag attr="val2" */ int methodB() { ... }
> }
>  
> ->
>  
> class Foo {
>    static aspect MetadataParticipant { 
>        ThreadLocal attrHolder = new ThreadLocal();
>        pointcut tagExecution() : 
>            execution(void Foo.methodA(int)) || execution(int
> Foo.methodB());
>        String getAttr() { return (String)(attrHolder.get()); }
>        before() : execution(void Foo.methodA(int)) {
>            attrHolder.set("val1");
>        }
>        before() : execution(int Foo.methodB()) {
>            attrHolder.set("val2");
>        }
>     }
>     void methodA(int x) { ... }
>     int methodB() { ... }
> }
>  
> Ron Bodkin
> Chief Technology Officer
> New Aspects of Security
> 


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com