[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: RE: [aspectj-users] XDoclet integration?
|
Hi Ted,
I have been campaigning for the ability to tag for quite some time. When
the Sun team started work on the JVMPI replacement API I was hopeful
that profiling would be much easier (and performant) if the release
conicided with JSR 175 implementation. The problem with profiling (and
even modeling) tools is that they are so generic and have little
application context. It is this context which is so important to
understand the complexity of execution runtimes. Luckily there has been
some adoption of component architectures which makes the job somewhat
easier (session, entity, persistence, transactions...) but not all
companies have standard systems and some require further abstractions
ontop of what is available. Tagging needs to be done at the source level
and then accessible from the runtime and aspect engines. Tagging is
simply a crosscutting classification. I would like to be able to see my
system and its metrics in terms of its reponsbilities (persistence...)
and not particular classe and methods. This tagging has to be done by
developers as its such a hard job to tag classes and method after the
fact.
I hope that AspectJ will in the future allow pointcuts to be defined in
terms of method attributes (tags).
Regards,
William Louth
JDBInsight Product Architect
www.jinspired.com
-----Original Message-----
From: a@xxxxxxxxxxxxxxx [mailto:a@xxxxxxxxxxxxxxx]
Sent: Monday, August 18, 2003 3:14 PM
To: aspectj-users@xxxxxxxxxxx
Cc: tneward@xxxxxxxxxxxxx
Subject: Re: RE: [aspectj-users] XDoclet integration?
Hello All,
Hi Ted,
I made similar expirences. During my time at Sirius Software, when I
developed and deployed new components in an component based
architecture, the components published ONLY with some kind of
attributes:
*which methods were reading method,
*which methods were writing methods
*or which methods were idempontent methods (state and/or sessionless)
from the point of view of the businesscode.
The transaction aspect "knew", that it had to advice all writing and
reading methods but not the idempotent ones,
the auditing aspect, knew that it had to advice all writing methods,
etc.
The components never knew and never cared, if they must be adviced by
transaction handling, etc.
IMHO all these deployment descriptors and JSR 175 stuff is an artificial
attemt to work around the lack of an aspect oriented programming
environment. So I believe we do not need it when we go down the road.
kind regards
Arno Schmidmeier
************************************************
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
developed While writing
Ted Neward <tneward@xxxxxxxxxxxxx> schrieb am 18.08.2003, 13:30:14:
> 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
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users
