I think that percflow(execution(...)) would not yield the desired result because in between executions one would lose cache state.
As for important information being scattered across README files per release or even across Bugzilla tickets vs. making it a habit to update documentation alongside releases, I want to recommend opting for the latter. Sorry for requestion something without contributing, but I am a mere user, not an AspectJ committer/maintainer. I do hope I am not requesting too much even so. I always thought that it was part of developet professionalism to do that. Probably development resources are being spread on this project like too little butter on too much bread, so I see the problem with my request. OTOH, most parts of the documentation seem not to have been updated since AspectJ 5. (2005? I am unsure.) This situation creates more work for developers on this mailing list, which is also time-consuming. After having been such a smart-ass, I want to ask if there is any way I can be of assistance. Andy? -- Alexander Kriegisch > Am 22.07.2014 um 19:06 schrieb Andy Clement <[email protected]>: > > In https://eclipse.org/aspectj/doc/released/README-164.html there is a > section on "Optimizing support for maintaining per join point state" which > talks about how to avoid using a map when you could use an array (using the > id number available from a join point). > > Just thinking in a hurry - maybe a percflow(execution(...)) might also be > possible, but I haven't thought that fully through. > > cheers, > Andy > > >> On 22 July 2014 07:25, Alexander Kriegisch <[email protected]> wrote: >> Hi Jon. >> >> I think there is no per-clause for distinct methods. I think your solution >> plus a Map, as you said, probably with keys generated from >> >> thisJoinPointStaticPart.getSignature().toLongString() >> >> or similar should do. Sorry for not having any better ideas than you by >> yourself. >> >> Regards >> -- >> Alexander Kriegisch >> http://scrum-master.de >> >> >> Jon Mann schrieb am 22.07.2014 15:54: >> >> > I have a simple aspect for caching the result of a method call. >> > >> > An annotation is used to mark a method which should be cached: >> > >> > public @interface CacheResult { } >> > >> > The aspect is implemented like this: >> > >> > @Aspect("perthis(targetMethod())") >> > public class CacheResultAspect { >> > >> > private Object result; >> > >> > @Pointcut("execution(@CacheResult * *.*())") >> > public void targetMethod() { } >> > >> > @Around("targetMethod()") >> > public Object aroundMethod(ProceedingJoinPoint thisJoinPoint) >> > throws Throwable { >> > if (result == null) { >> > result = thisJoinPoint.proceed(); >> > } >> > return result; >> > } >> > } >> > >> > This works great for target classes with only one @CacheResult method. >> > >> > But the problem is target classes which have multiple different >> > @CacheResult methods: >> > >> > class Target { >> > @CacheResult String method1() { return "method1"; } >> > @CacheResult String method2() { return "method2"; } >> > } >> > >> > Target target = new Target(); >> > target.method1(); // Caches and returns "method1" >> > target.method2(); // Returns cached "method1" but should >> > separately cache and return "method2" >> > >> > Currently, one instance of CacheResultAspect is created for each >> > instance of a target class, so the cache result is (incorrectly) shared >> > across all the @CacheResult methods of the target object. >> > >> > Is there a way to make AspectJ create a separate instance of >> > CacheResultAspect for each @CacheResult method in a target object? >> > >> > I could use a Map to work around this, but perhaps there is a better or >> > more performant solution? >> >> _______________________________________________ >> aspectj-users mailing list >> [email protected] >> To change your delivery options, retrieve your password, or unsubscribe from >> this list, visit >> https://dev.eclipse.org/mailman/listinfo/aspectj-users > > _______________________________________________ > aspectj-users mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________ aspectj-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/aspectj-users
