[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [aspectj-users] XDoclet integration?
|
I find myself in the odd position of defending the use of tags in AOP in
general and AspectJ in particular.
I think the Xdoclet experiment is worth doing. The key is where to fit
the tags into AspectJ. And I think there is one answer that seems best.
It has, among its many attractive properties, that answers to questions
like how dominates works are clear.
- there should be no new join points
- tags should be an additional property on which pointcuts can
use to discriminate
- there should be no new advice
That's all in the pointcuts and advice part of the language. I haven't
thought about the open class (introduction part), but I bet it has the
same flavor.
In addition, programmers should adopt a style where the tag names they
use describe a property of the declaration the tag is on (class, method
etc.), and NOT a property of the aspect they want to have apply there.
(This is what Arno is suggesting in his message.)
With the language design and usage style above, using tags becomes a
natural extension of existing AspectJ. Programmers can write things
like:
pointcut foo(): execution(@foo * *(..))
There is still a slightly harder language design question, which is whether tags
should be incorporated into existing pointcuts (as in the code above), or whether
there should be a new pointcut, called something like tag, that is 'kindless' but
that just checks tags (like this, target and args).
In such an approach, the above would be something like
pointcut foo(): execution(* *(..)) && tag(@foo) or
pointcut foo(): execution(* *(..)) && tag(foo)
Probably it has to be both a new tag pointcut and additions to call/execution etc.
to get both static and dynamic testing of tags. That could make some examples ugly,
as in:
execution(@foo * @bar *.*(..))
(at least that's how I think that would look).
> -----Original Message-----
> From: aspectj-users-admin@xxxxxxxxxxx
> [mailto:aspectj-users-admin@xxxxxxxxxxx] On Behalf Of Ted Neward
> Sent: Monday, August 18, 2003 4:30 AM
> To: aspectj-users@xxxxxxxxxxx
> 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() { ... }
> > > }
> > >
> > > 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
>
