Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[aspectj-users] Re: Access to the aspect in 'pertypewithin' type

Hello Hermond,

I'm not sure if I understand your proposal. The sample code I gave was just do demonstrate the access issue. Target is to use JSR-47 standard JDK logging. (not a boolean flag in the aspect)

Something like:

aspect ...
{
  public static String com.foo.*.mClassname;
  public static Logger com.foo.*.mLoger;
  [..]
}

is also not possible it requires that I know the concrete class where I want to add tracing to already when writing the aspect. But this is not the case in my intended setup.


Do you have a different proposal?

Kind Regards,

Andreas.
	


hermod.opstvedt@xxxxxxxxx wrote:
Hi

Why don't you just add a member to the class - I have similar stuff that
I do where I add a enabled-member to the class (Logger)

Hermod

-----Original Message-----
From: aspectj-users-bounces@xxxxxxxxxxx
[mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Andreas Mandel
Sent: Thursday, January 31, 2008 5:32 PM
To: aspectj-users@xxxxxxxxxxx
Subject: [aspectj-users] Re: Access to the aspect in 'pertypewithin'
type


Hello Dean,

thanks for your answer. Actually I already found the documents you pointed me to. And pertypewithin works fine with 1.4JDK, at least for what I did till now.

My point is not the usage of 'pertypewithin' but the overhead that is generated if an condition wants to access the object instance of the aspect, related to the current class (DeclaringType).


I try it differently:

If a class gets a pertypewithin aspect is gets a private static transient <aspect-class> ajc$<package>$ptwAspectInstance; member and a method public static <aspect-class> ajc$<package>$localAspectOf() weaved

in. But accessing these static information is - as far as I found out - not directly possible from within a if(..) condition. The only way to get the assigned aspect is to call: aspectOf(thisJoinPointStaticPart.getSignature().getDeclaringType()) which is very costly compared to the direct access.



A sample:

public aspect Tracing pertypewithin(*.*)
{
   public boolean mEnabled;
   public boolean isEnabled ()
   {
      return mEnabled;
   }

   [...]

   before() : !within(Tracing)
//   && if(mEnabled) not possible, needs static
      && aspectOf(
        thisJoinPointStaticPart
           .getSignature().getDeclaringType()).isEnabled()
   {
     [...]
     ... thisJoinPoint.getArgs() ...
     [...]
   }
}


So the question remains: Is this somehow possible today?



Kind Regards,

Andreas.




Dean Wampler schrieb:
It goes with the aspect declaration:

public aspect Foo pertypewithin(...mypackage.*) {  // All the types in
"mypackage".
...
}

Here's the manual page for it, which is not as easy to get to with a
google search as you would think (aspectj list traffic comes up
first...)
http://www.eclipse.org/aspectj/doc/released/adk15notebook/pertypewithin.
html
Here's a very long message on the aspectj-dev list that shows an example: http://dev.eclipse.org/mhonarc/lists/aspectj-dev/msg01259.html

Also, I couldn't remember if pertypewithin actually works with JDK 1.4,
but apparently it does:
http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg03995.html

Can you give us some more details about what you're trying to do?

Hope this helps!
dean

On Jan 31, 2008, at 2:10 AM, Andreas Mandel wrote:

Hello,

I'm quite new to AspectJ so please apologize that some terms might not fully hit the target.

I tried hard to find the 'pertypewithin' keyword which allows me to do exactly what I wanted. (Guess what - debug logging and tracing). I'm working with a 1.4 JDK. Inspecting the generated code there is one thing that makes me unhappy because it is not as good as it could

be:

To access the DeclaringType's aspect instance in the advice I need to
call
aspectOf(thisJoinPointStaticPart.getSignature().getDeclaringType()).
This generates code that calls the static aspectOf(Class) method of
the
aspect to look up the DeclaringType's aspect instance via
reflection. This simply returns a pointer back to the member that is already statically accessible in the DeclaringType
(ajc$<...>$ptwAspectInstance).
This could be directly accessible even in the static arrear (if(...))

allowing some major improvements - but unfortunately it not exposed
to
the advice.

Am I just missing an other key word to get direct access? Or is this a feature that needs to be coded?

If needed I can give more details.


Thanks for any feedback,

Andreas.

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/aspectj-users
Dean Wampler, Ph.D.
dean at objectmentor.com
http://www.objectmentor.com
See also:
http://www.aspectprogramming.com  AOP advocacy site
http://aquarium.rubyforge.org     AOP for Ruby
http://www.contract4j.org         Design by Contract for Java5




----------------------------------------------------------------------
--

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/aspectj-users

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

This email with attachments is solely for the use of the individual or
entity to whom it is addressed. Please also be aware that the DnB NOR Group
cannot accept any payment orders or other legally binding correspondence with
customers as a part of an email.
This email message has been virus checked by the anti virus programs used
in the DnB NOR Group.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



Back to the top