Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [aspectj-users] XDoclet integration?

Ted,

Overuse of tags is indeed a big concern. (in general, it will 
be interesting to see how metadata in JSR 175 gets used in 
practice. I think it will be a chaotic situation for a while :-( ). 
If developer start tagging code instead of thinking what poincut 
could capture the intended join points would go contrary to the 
obliviousness.

That said, there are a few cases where metadata is useful, 
especially when it is impossible to extract the characteristics 
of a join point based on method names etc.

The question then is how to best express the metadata. 
Following is the guideline I have been using:
1. Global concern: 
  "Authenticate all public methods in banking module".

   Solution:
   Use a hand-written (sub)aspect that defines pointcut using
   wildcards. No explicit metadata used.

2. Class level concern:
   "Lazy initialize that field".
    
   Solution:
   Use a nested hand-written aspect that defines pointcut using
   explicit name of the enclosing class.

3. Global concern with class level control:
   "Ensure thread safe access" translated into "Surround the 
    state access methods with a synchronized block" or
    "use read-write lock pattern" etc.

   Solution:
   Use the participant pattern. The base aspect contain one
   or more abstract pointcuts and each class contains a nested
   subaspect that extends the base aspect and provides a definition 
   for each abstract pointcut.
  
   (Variations such as packages level participant are also useful).

4. Global concern with method level control:
   "Execute the following method in transaction context" or
   "Surround slow running methods with a wait cursor".

    Solution:
    Currently I still use the participant pattern. In doing
    so I am fusing together characteristics of all methods
    in a aspect. While this style has served well so far,
    I do think the information expressed in the participant
    subaspect isn't quite right place.

    This is the case where XDoclet/JSR175 metadata can be
    helpful. I can now declare the "participation" by adding
    metadata where it belongs -- the method themselves.
   
-Ramnivas

--- Ted Neward <tneward@xxxxxxxxxxxxx> wrote:
> I think this is a bad road to go down.
> 
> Aspects have traditionally been useful because the aspect itself
> contains the knowledge of which classes/methods/fields/etc to weave
> against, rather than deferring that to the class or component itself.
> This helps keep the intelligence regarding how and when the aspect
> should weave within one place, rather than scattering it all over the
> codebase. Aspects are somewhat intrusive by nature, and shouldn't be
> considered across component boundaries.
> 
> In contrary, interception-based frameworks work best when they are
> established at component boundaries, allowing the components to
> declare
> which sorts of services they wish provided at the interception
> points.
> This is where 175 will have its best success, IMHO, since it will
> provide a natural replacement for deployment descriptors in J2EE
> applications, allowing components to declare which services should be
> injected into the thread's call flow.
> 
> Frankly, I understand the desire to make AspectJ fit in with both
> paradigms, but I think in the long run we're going to regret going
> down
> that road; I think it would create a situation in which complex use
> of
> aspects in this manner would create more problems than using aspects
> would solve. Case in point: given this "declarative" style of
> aspects,
> how would dominates clauses be honored and/or specified?
> 
> Ted Neward
> Author, Instructor, Presenter: Java and .NET
> http://www.neward.net/ted/weblog
> http://www.javageeks.com
> http://www.clrgeeks.com
> 
> 
> > -----Original Message-----
> > From: aspectj-users-admin@xxxxxxxxxxx 
> > [mailto:aspectj-users-admin@xxxxxxxxxxx] On Behalf Of Ramnivas
> Laddad
> > Sent: Saturday, August 16, 2003 1:27 PM
> > To: aspectj-users@xxxxxxxxxxx
> > Subject: Re: [aspectj-users] XDoclet integration?
> > 
> > 
> > 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 
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx 
> > http://dev.eclipse.org/mailman/listinfo/aspect> j-users
> > 
> 
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users


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


Back to the top