[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [aspectj-users] XDoclet integration?
|
Metadata tags will be useful for writing good pointcuts. It's NOT the first choice; if there's sufficient structure to write a good pointcut without attributes that's better because it avoids scattering tags. But in practice there are cases where it would be the best option. I previously posted an analysis that explained this more fully (http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg00802.html). I agree with Gregor and Arno that tags should be used to describe the declaration, and not describe how an aspect should operate on it; this is somewhat like using naming patterns.
Moreover, when JSR-175 comes to Java, AspectJ needs to account for it. To me, this means both allowing pointcuts to refer to tags and their attributes, and inter-type declarations "declare tag/attribute". I agree with Cedric that when JSR-175 arrives, marker interfaces will be deprecated. And notice that marker interfaces are a very common and useful idiom in AspectJ. Metadata will allow more fine-grained and powerful analogs.
I think aspects are going to be very useful for inter-component interactions; AOP will allow J2EE a la carte (and extensibly). I see it as natural to apply AOP across multiple components and multiple cooperating applications. E.g., consider writing aspects to handle compensating transactions or initiate a planning process in a multi-application integration. There is some great research ongoing about using AOP for components and many of the proposals do include this kind of tagging.
This also raises an interesting question about describing deployment configuration separate from code. It would be nice to allow external deployment descriptors to define the scope of application of an aspect rather than requiring code to instantiate (or override) pointcuts.
Ron
Ron Bodkin
Chief Technology Officer
New Aspects of Security
m: (415) 509-2895
> ------------Original Message-------------
> From: "Ted Neward" <tneward@xxxxxxxxxxxxx>
> To: <aspectj-users@xxxxxxxxxxx>
> Date: Mon, Aug-18-2003 4:35 AM
> Subject: RE: [aspectj-users] XDoclet integration?
>
> 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() { ... }
> > > }
