[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: RE: [aspectj-users] XDoclet integration?
|
--- a@xxxxxxxxxxxxxxx wrote:
>
> 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?
Becuase then I can keep the method's characterisitcs and the
the metadata in sync.
> 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.
As I said, the participant pattern does serve me well, but it
still requires me to ensure that all particpant aspects are
kept up-to-date with the method's characteristics.
IF I had XDoclet/JSR175 integration, I wouldn't need subaspect.
The classes can then be oblivious to the fact that they are
being aspects in so much that the method expose their sematic
metadata.
-Ramnivas
>
> 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
> _______________________________________________
> 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
