Skip to main content

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

Ramnivas Laddad <ramnivas@xxxxxxxxx> schrieb am 18.08.2003, 18:52:10:
> Ted,
> 
<snip> 
> 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.

Is this really the right place?
Why do I want to have the pointcut definition in some metadata tag tied
in the source of an method?

I suggest using the concept of extensible pointcuts instead of metadata
here. So you have the choice, if it is the source itself or an
independent aspect tied very closely to the source, which adds the
metadata tag.

kind regards
   Arno
>    
> -Ramnivas
> 
> --- Ted Neward  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  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
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
-- 
************************************************ 
Arno Schmidmeier 
Arno@xxxxxxxxxxxxx 
+49/9151/90 50 30 
Yes, I have realized large scale projects with AspectJ 
Yes, I do provide consulting services for AspectJ


Back to the top