Todays Topics: State of the art of AOP-AOSD
Hello, May I know the state of the art of AOP-AOSD in Software Develpoment & in IT industry and also University which offering UG /PG and research in AOP-AOSD. thanking you, s kotrappa On 2/1/08, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote: > > Send aspectj-users mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://dev.eclipse.org/mailman/listinfo/aspectj-users > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of aspectj-users digest..." > > > Today's Topics: > > 1. Re: Re: Access to the aspect in 'pertypewithin' type > (Dean Wampler) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 1 Feb 2008 08:59:28 -0600 > From: Dean Wampler <[EMAIL PROTECTED]> > Subject: Re: [aspectj-users] Re: Access to the aspect in > 'pertypewithin' type > To: [email protected] > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="us-ascii" > > > On Feb 1, 2008, at 2:02 AM, Andreas Mandel wrote: > > > Hello Dean, > > > > instead of: > > > > > static boolean isEnabledFor(Object o) { > > > return aspectOf(o.getClass()).enabled; > > > } > > > before(Object o): if (isEnabledFor(o)) > > > && target(o) && call (* ptw.*.*(..)) { > > > System.out.println("entering: "+thisJoinPointStaticPart); > > > } > > > > I have now: > > > > static boolean isEnabledFor(Object o) { > > return aspectOf(o.getClass()).enabled; > > } > > before : if ( > > isEnabledFor( > > thisJoinPointStaticPart.getSignature() > > .getDeclaringType()).isAspectTracing())) > > && execution (* ptw.*.*(..)) { > > System.out.println("entering: "+thisJoinPointStaticPart); > > } > > > > which should be quite similar in respect to execution time. (Any > > special reason why you used 'call' and not 'execution' pointcut?) > > > > No reason why I used 'call'. 'execution' would be fine, too. > > You should try profiling both versions of the code to see if their is > a noticeable performance impact with the longer method-call chain. > Otherwise, it looks equivalent. > > > > > The Set is what I would expect a (static) member of the JDK Logging > > Logger to keep track of all the Loggers (as a map logger-name -> > > logger-instance). In the if() conditional the access to this logger > > (in a hand coded implementation this would be a static member of the > > logging class) should be as direct (fast) as possible. My target was > > to be able to generate aspect based JSR-47 tracing that is at least > > equal to the one you would write manually in terms of execution > > times (especially if disabled). Without all the pain and the > > probability to make mistakes if you have to write this logging code > > over and over again. Logging is the most used example when talking > > about AOP. > > If you can ask the logging API whether or not to log, so much the > better. Note that look-ups using the name as a key might be slower > than look-ups using the class. Again, a little profiling might be a > good idea. > > Just to expand on what Hermod said, you could use an aspect to > "introduce" a logging flag into the classes you want, etc. That's a > particularly-useful way to implement the Observer pattern, for example. > > > > > > > > > Kind Regards, > > > > Andreas. > > > > > > > > Dean Wampler wrote: > >> I played around with a few workarounds that give you type-specific > >> enablement of tracing with checking of an if() conditional in the > >> pointcut. It may not be as runtime efficient as we might like, but > >> it shouldn't be too bad either. > >> Start with two test classes: > >> package ptw; > >> public class Type1 { > >> public void doit1() { > >> System.out.println("in: Type1.doit1()"); > >> } > >> public void doit2() { > >> System.out.println("in: Type1.doit2()"); > >> } > >> } > >> and > >> package ptw; > >> public class Type2 { > >> public void doit1() { > >> System.out.println("in: Type2.doit1()"); > >> } > >> public void doit2() { > >> System.out.println("in: Type2.doit2()"); > >> } > >> } > >> Here's the first aspect that uses pertypewithin and a static method > >> to make the "enabled" field accessible. It also has a main that > >> exercises the code: > >> package ptw; > >> public aspect TracerPerType pertypewithin(ptw.*) { > >> public boolean enabled = false; > >> static boolean isEnabledFor(Object o) { > >> return aspectOf(o.getClass()).enabled; > >> } > >> // It would be great if we could just pass the type, but we > >> only have the object. (right?) > >> before(Object o): if (isEnabledFor(o)) && target(o) && call (* > >> ptw.*.*(..)) { > >> System.out.println("entering: "+thisJoinPointStaticPart); > >> } > >> public static void main(String[] args) { > >> System.out.println("No tracing enabled:"); > >> callDoits(); > >> System.out.println("Enabling tracing for Type1:"); > >> aspectOf(Type2.class).enabled = true; > >> callDoits(); > >> System.out.println("Enabling tracing for Type2:"); > >> aspectOf(Type2.class).enabled = true; > >> callDoits(); > >> System.out.println("Disabling tracing for Type1:"); > >> aspectOf(Type1.class).enabled = false; > >> callDoits(); > >> System.out.println("Disabling tracing for Type2:"); > >> aspectOf(Type2.class).enabled = false; > >> callDoits(); > >> } > >> private static void callDoits() { > >> Type1 t1 = new Type1(); > >> t1.doit1(); > >> t1.doit2(); > >> Type2 t2 = new Type2(); > >> t2.doit1(); > >> t2.doit2(); > >> } > >> } > >> Here's a second aspect that doesn't use pertypewithin and tracks > >> which types are enabled in a Set. It also has a main: > >> package ptw; > >> import java.util.HashSet; > >> public aspect Tracer { > >> // Don't use the <?> for Java 1.4, of course. > >> static HashSet<Class<?>> enabled = new HashSet<Class<?>>(); > >> static void enableFor(Class<?> clazz) { > >> enabled.add(clazz); > >> } > >> static void disableFor(Class<?> clazz) { > >> enabled.remove(clazz); > >> } > >> before(Object o): if (enabled.contains(o.getClass())) && target(o) > >> && call (* ptw.*.*(..)) { > >> System.out.println("entering: "+thisJoinPointStaticPart); > >> } > >> public static void main(String[] args) { > >> System.out.println("No tracing enabled:"); > >> callDoits(); > >> System.out.println("Enabling tracing for Type1:"); > >> Tracer.enableFor(Type1.class); > >> callDoits(); > >> System.out.println("Enabling tracing for Type2:"); > >> Tracer.enableFor(Type2.class); > >> callDoits(); > >> System.out.println("Disabling tracing for Type1:"); > >> Tracer.disableFor(Type1.class); > >> callDoits(); > >> System.out.println("Disabling tracing for Type2:"); > >> Tracer.disableFor(Type2.class); > >> callDoits(); > >> } > >> private static void callDoits() { > >> Type1 t1 = new Type1(); > >> t1.doit1(); > >> t1.doit2(); > >> Type2 t2 = new Type2(); > >> t2.doit1(); > >> t2.doit2(); > >> } > >> } > >> Both aspects should print out the following: > >> No tracing enabled: > >> in: Type1.doit1() > >> in: Type1.doit2() > >> in: Type2.doit1() > >> in: Type2.doit2() > >> Enabling tracing for Type1: > >> entering: call(void ptw.Type1.doit1()) > >> in: Type1.doit1() > >> entering: call(void ptw.Type1.doit2()) > >> in: Type1.doit2() > >> in: Type2.doit1() > >> in: Type2.doit2() > >> Enabling tracing for Type2: > >> entering: call(void ptw.Type1.doit1()) > >> in: Type1.doit1() > >> entering: call(void ptw.Type1.doit2()) > >> in: Type1.doit2() > >> entering: call(void ptw.Type2.doit1()) > >> in: Type2.doit1() > >> entering: call(void ptw.Type2.doit2()) > >> in: Type2.doit2() > >> Disabling tracing for Type1: > >> in: Type1.doit1() > >> in: Type1.doit2() > >> entering: call(void ptw.Type2.doit1()) > >> in: Type2.doit1() > >> entering: call(void ptw.Type2.doit2()) > >> in: Type2.doit2() > >> Disabling tracing for Type2: > >> in: Type1.doit1() > >> in: Type1.doit2() > >> in: Type2.doit1() > >> in: Type2.doit2() > >> Using a static Set or Map like this is a pretty common idiom. > >> pertypewithin eliminated many cases for it. > >> dean > >> On Jan 31, 2008, at 11:53 AM, Andy Clement wrote: > >>> So, from the advice you can of course just use 'this' as that will > >>> be > >>> the aspect instance. Your question is more about accessing the > >>> instance from the pointcut rather than the advice as you want to > >>> check > >>> a trace guard using if(). If it can be accessed from the if() then > >>> the optimization to lazily build the joinpoint object for passing to > >>> the advice is possible (using what we used to call the lazyTjp > >>> optimization). > >>> > >>> Unfortunately you cannot do that right now - traditionally people > >>> have > >>> used a single global flag as the primary guard for all tracing > >>> across > >>> the system and then within the advice checking on a per type basis. > >>> > >>> before(): execution(public * *(..)) && if(isEnabledAnywhere) { > >>> if (logger.isEnabledFor(getWithinTypeName()) { > >>> logger.log(thisJoinPoint); > >>> } > >>> } > >>> > >>> This gives you the global control to guard building thisJoinPoint > >>> objects - if tracing is not turned on anywhere, there is no cost for > >>> that. But if you enable it for any type you will suffer the > >>> building > >>> of the tjp object across the system. > >>> > >>> It can be optimized and has been mentioned in the past, but I > >>> haven't > >>> gotten around to it. There are a few open bugzilla entries > >>> related to > >>> pertypewithin() but I don't think this requirement has been captured > >>> explicitly - feel free to raise an enhancement request for it. > >>> > >>> Andy > >>> > >>> > >>> On 31/01/2008, Andreas Mandel <[EMAIL PROTECTED] <mailto: > [EMAIL PROTECTED] > >>> >> wrote: > >>>> 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 > >>>>>> [email protected] <mailto:[email protected]> > >>>>>> 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 > >>>>> [email protected] <mailto:[email protected]> > >>>>> https://dev.eclipse.org/mailman/listinfo/aspectj-users > >>>> > >>>> _______________________________________________ > >>>> aspectj-users mailing list > >>>> [email protected] <mailto:[email protected]> > >>>> https://dev.eclipse.org/mailman/listinfo/aspectj-users > >>>> > >>> _______________________________________________ > >>> aspectj-users mailing list > >>> [email protected] <mailto:[email protected]> > >>> 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 > >> [email protected] > >> https://dev.eclipse.org/mailman/listinfo/aspectj-users > > > > _______________________________________________ > > aspectj-users mailing list > > [email protected] > > 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 > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > https://dev.eclipse.org/mailman/listinfo/aspectj-users/attachments/20080201/eeb55130/attachment.html > > ------------------------------ > > _______________________________________________ > aspectj-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users > > > End of aspectj-users Digest, Vol 36, Issue 2 > ******************************************** > -- Prof S Kotrappa Assistant Prof, Department of CSE/MCA KLES's College of Engg., & Technology Belgaum-India.
_______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
