You can't do this with a final TIMER field. You may want to have a private
final MapString, Timer timers in which you'd associate Timers to MethodNames.
The MethodName you can get from thisJoinPoint(StaticPart) - you may even be
able to use thisJoinPointStaticPart.toString() for that purpose.
As an alternative if you do not lile the Map idea, you might want to use a
non-singleton instantiation model like perthis or pertarget in combination
with a normal (non-static) member variable for the Timer.
Alexander Kriegisch
http://scrum-master.de
Am 06.11.2012 um 11:31 schrieb Romain
Thanks, both approaches are good i think. However if you want to code this
really clean, I guess even with a ConcurrentHashMap in the Map approach
you'd still have to do some locking for the situation where 2 threads are
calling the annotated method and MapString, Timer is still empty. Same
goes
Yes. And for non-static members you ought not to forget the use of volatile for
the member... ;)
[ Romain Muller | Software Development Engineer | +33 (0)6 48 25 66 70 |
romain.mul...@esial.net ]
Le 6 nov. 2012 à 11:47, Reik Schatz reik.sch...@gmail.com a écrit :
Thanks, both approaches are
Hi,
It may or may not be useful to you, but the Perf4j project[1] uses
AspectJ to instrument code with stopwatches, providing generic
around-method timing via an @Profiled annotation. There's also an
unreleased enhancement in github which allows methods to be timed
without annotating them (by
