Re: [aspectj-users] Matching on one of an annotation's values in a multivalued property?
I could not agree more. Sugared variant is wrong and misleading, violates
the rule of least surprise since it overloads "=" with something other than
either "assign" or "equals" (namely "contains/includes").
_
Sent over RFC-1149 compliant transport - please excuse occasionnal packet
loss
Le 5 avr. 2013 à 21:59, Alexander Kriegisch a
écrit :
My spontaneous impulse upon reading the sugared variant was to dislike it
more than the other one which at least bears schematic similarity to known
method parameter matching patterns.
Alexander Kriegisch
Am 05.04.2013 um 21:53 schrieb Andy Clement :
As we kind of chatted about earlier on Skype, I don't think you can do this
right now. The support for annotation array values isn't all in place and
even then the support for class literal annotation values isn't all there
either. There is so much to annotations that the various use cases are
addressed as they come up. You seem to have come up with this one so it is
time to look at filling it in.
The syntax for matching one element of an array value is probably something
like you propose:
declare parents: (@Gimme(value = {..,Serializable.class,..}) *) implements
Serializable;
even though I don't really like the look of it.
But perhaps a syntax sugared variant of:
declare parents: (@Gimme(value = Serializable.class) *) implements
Serializable;
would be OK for a single value being located, even though strictly speaking
'=' is wrong and it should be something that suggests 'contains/includes'.
(I'm open to suggestions).
cheers,
Andy
On 5 April 2013 09:21, Matthew Adams wrote:
> Dunno. I used Nabble's "raw" tags. I'll reply to original post without
> them.
>
>
>
> --
> View this message in context:
> http://aspectj.2085585.n4.nabble.com/Matching-on-one-of-an-annotation-s-values-in-a-multivalued-property-tp4650839p4650841.html
> Sent from the AspectJ - users mailing list archive at Nabble.com.
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
smime.p7s
Description: S/MIME cryptographic signature
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
Re: [aspectj-users] context information in aspect fields
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 a écrit :
> 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 Map is still empty. Same goes for the
> perthis approach if the non-static member is created inside the advice,
> correct?
>
>
> On Tue, Nov 6, 2012 at 11:31 AM, Romain Muller
> wrote:
> You can't do this with a "final" TIMER field. You may want to have a "private
> final Map 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.
>
> [ Romain Muller | Software Development Engineer | +33 (0)6 48 25 66 70 |
> romain.mul...@esial.net ]
>
> Le 6 nov. 2012 à 11:29, Reik Schatz a écrit :
>
>> Hi,
>>
>> I am working on a timer example using AspectJ similar to this logging
>> example:
>> http://adamgent.com/post/5479576926/the-python-decorator-pattern-for-java-using-aspectj
>>
>> However the Timer (not Logger) I am using takes among others a String
>> argument which describes the context of the place where you are timing (i.e.
>> if you are timing a save method in a DAO class, the argument would be
>> "save"). Now that the Timer is defined in the Aspect, is it possible to
>> retrieve some context information outside of the pointcut or advice
>> definition? Ideally I want to do something like:
>>
>> public aspect TimedAspect {
>>
>> private final Timer TIMER = Metrics.newTimer(getClass(), "TARGET METHOD
>> NAME HERE");
>>
>> pointcut timedExecution() : execution(@Timed * * (..)); // execution of
>> a annotated method
>>
>> Object around() : timedExecution() {
>> final TimerContext context = TIMER.time();
>> try {
>> return proceed();
>> } finally {
>> context.stop();
>> }
>> }
>> }
>>
>> For me it looks like the only way is to create the Timer object inside the
>> advice and use the context information available.
>> ___
>> aspectj-users mailing list
>> aspectj-users@eclipse.org
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
smime.p7s
Description: S/MIME cryptographic signature
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
Re: [aspectj-users] context information in aspect fields
You can't do this with a "final" TIMER field. You may want to have a "private
final Map 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.
[ Romain Muller | Software Development Engineer | +33 (0)6 48 25 66 70 |
romain.mul...@esial.net ]
Le 6 nov. 2012 à 11:29, Reik Schatz a écrit :
> Hi,
>
> I am working on a timer example using AspectJ similar to this logging
> example:
> http://adamgent.com/post/5479576926/the-python-decorator-pattern-for-java-using-aspectj
>
> However the Timer (not Logger) I am using takes among others a String
> argument which describes the context of the place where you are timing (i.e.
> if you are timing a save method in a DAO class, the argument would be
> "save"). Now that the Timer is defined in the Aspect, is it possible to
> retrieve some context information outside of the pointcut or advice
> definition? Ideally I want to do something like:
>
> public aspect TimedAspect {
>
> private final Timer TIMER = Metrics.newTimer(getClass(), "TARGET METHOD
> NAME HERE");
>
> pointcut timedExecution() : execution(@Timed * * (..)); // execution of a
> annotated method
>
> Object around() : timedExecution() {
> final TimerContext context = TIMER.time();
> try {
> return proceed();
> } finally {
> context.stop();
> }
> }
> }
>
> For me it looks like the only way is to create the Timer object inside the
> advice and use the context information available.
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
smime.p7s
Description: S/MIME cryptographic signature
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
Re: [aspectj-users] Problems with a basic staticinitialization pointcut in AJDT and Maven
BTW - were the annotation classes with the errors marked with
a RUNTIME @Retention? I'm guessing maybe the non-runtime annotations
probably don't get a clinit...
_
Sent over RFC-1149 compliant transport - please excuse occasionnal packet loss
Le 26 oct. 2012 à 22:31, Andy Clement a écrit :
> Bizarre that you get the missing clinit message when AspectJ is the
> only reason one got inserted... I wonder if there is something wrong
> (maybe flags or something) about the clinit that it inserts in this
> case. Could be worth raising an issue about:
> https://bugs.eclipse.org/bugs/enter_bug.cgi?product=AspectJ
>
> I guess if it isn't triggering when you expect you are probably just
> going to avoid weaving annotations? (which also gets around this
> problem)
>
> cheers,
> Andy
>
> On 26 October 2012 06:49, Timothy Armstrong wrote:
>> Hi,
>>
>> I think you're probably right about the annotations. In the tests, I'm just
>> mentioning them by name with their .class object, such as
>> "myAnnotation.class". It's unfortunate the aspect doesn't trigger then, but
>> I can work around it. There are hits on Google for 'is missing ',
>> but only one for 'AspectJ "is missing "'. I couldn't figure it out
>> based on the hits. Yes, when I remove the staticinitialization aspect, it
>> compiles. I'm compiling all the annotations from source, if that's what you
>> mean.
>>
>> Thanks,
>> Tim
>>
>>
>>
>> On 10/25/2012 08:21 PM, Andy Clement wrote:
>>>
>>> Hi,
>>>
>>> You will only see your message when the static initializer runs. The
>>> class may get loaded and used (to some degree) without that happening.
>>> For example, here are some simple types:
>>>
>>> @Retention(RetentionPolicy.RUNTIME)
>>> @interface Foo {
>>> }
>>>
>>> public class Code {
>>> @Foo
>>> public static void main(String []argv) throws Exception {
>>> }
>>> }
>>>
>>> I can compile that and run 'Code' without the Foo static initializer
>>> running.
>>>
>>> But if I change Code to do something with it, then we will see the
>>> initializer running:
>>>
>>> public class Code {
>>> @Foo
>>> public static void main(String []argv) throws Exception {
>>> Foo f =
>>> Code.class.getDeclaredMethod("main",String[].class).getAnnotation(Foo.class);
>>> }
>>> }
>>>
>>> Can it be that some of your code just isn't exercising the annotations
>>> enough to see their static initializers run?
>>>
>>> I've never seen the "is missing " message before, but I see it
>>> is classified as a bit odd:
>>> https://forums.oracle.com/forums/thread.jspa?messageID=4824974
>>>
>>> I don't speak Maven very well - is AspectJ being used to build those
>>> annotation types? (I'm not sure if you are building everything from
>>> source or just weaving via a post compile step).
>>>
>>> If you remove your aspect the "is missing" messages all disappear?
>>>
>>> cheers,
>>> Andy
>>>
>>> On 25 October 2012 08:24, Timothy Armstrong wrote:
>>>>
>>>> Hello,
>>>>
>>>> Thanks for your replies. Yes, I get the same behavior when I put version
>>>> 1.6.11 in the POM, just without the "bad version number" warning. I
>>>> should
>>>> have posted that version. I always get the "advice defined in ... has not
>>>> been applied" warnings for the other aspects, but they still work. It
>>>> does
>>>> compile when I specify an annotation, such as
>>>> "staticinitialization(@OWLClass *)". I posted the only lines in the POM
>>>> having to do with AspectJ, so I don't know where else filters would be
>>>> that
>>>> ignore the test tree.
>>>>
>>>> Thanks,
>>>> Tim
>>>>
>>>>
>>>>
>>>> On 10/25/2012 09:19 AM, Krzysztof Dębski wrote:
>>>>>
>>>>> aspectj-maven-plugin doesn't support aspectj 1.7
>>>>>
>>>>> see: http://jira.codehaus.org/browse/MASPECTJ-108
>>>>>
>>>>> Krzysztof Debski
>>>>>
>>>>> 2012/10/24 Romain MULLER :
>>>>>>
>>
Re: [aspectj-users] Problems with a basic staticinitialization pointcut in AJDT and Maven
I surely am no maven guru and I won't risk myself in trying to comment your POM. That said, on the Maven error, I think the following line could be of some relevance: [WARNING] bad version number found in /home/tim/.m2/repository/org/aspectj/aspectjrt/1.7.0/aspectjrt-1.7.0.jar expected 1.6.11 found 1.7.0 This looks dodgy, I would try to arrange things so that this warning isn't produced anymore before digging any further on the maven errors. On the eclipse side, I'd recommend checking that your AspectJ compiler options don't have filters that get your test tree ignored by the compile-time weaver. I know it's kind of an "are you sure your computer is plugged to a power socket" check, but they very often give good results ;) _ Sent over RFC-1149 compliant transport - please excuse occasionnal packet loss Le 24 oct. 2012 à 22:08, Timothy Armstrong a écrit : > [WARNING] bad version number found in > /home/tim/.m2/repository/org/aspectj/aspectjrt/1.7.0/aspectjrt-1.7.0.jar > expected 1.6.11 found 1.7.0 smime.p7s Description: S/MIME cryptographic signature ___ aspectj-users mailing list aspectj-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/aspectj-users
Re: [aspectj-users] Intercepting field access and thread-safety
Yes! Right :)
And there is no point in fiddling with proceedingJoinPoint.proceed(); when you
use .aj files (as opposed to annotated-pojo-based), it's not wired to anything.
Regards,
[ Romain Muller | Software Development Engineer | +33 (0)6 48 25 66 70 |
romain.mul...@esial.net ]
Le 19 oct. 2012 à 13:18, "Sertic Mirko, Bedag" a écrit :
> And the solution seems to be:
>
>Object around() : get(@Annotation * *.*) {
>
>try {
>Object theReturnValue = proceed();
>
> // Do something here
>
>return theReturnValue;
>} catch (Throwable e) {
>throw new RuntimeException("Something went wrong", e);
>}
>}
>
> Greets
> Mirko
>
> -Ursprüngliche Nachricht-
> Von: aspectj-users-boun...@eclipse.org
> [mailto:aspectj-users-boun...@eclipse.org] Im Auftrag von Sertic Mirko, Bedag
> Gesendet: Freitag, 19. Oktober 2012 13:13
> An: aspectj-users@eclipse.org
> Betreff: Re: [aspectj-users] Intercepting field access and thread-safety
>
> Hi there again
>
> This pointcut sounds right, but the aspect is not applied at all.
>
> around() : get(@Annotation * *.*) -> Matches everything correctly, but no
> return value bound
> around(Object val) : get(@Annotation * *.*) && args(val) -> Matches nothing
>
> I tried to fiddle with the proceedingJoinPoint.proceed() to get the field
> access return value, but this always returns null.
>
> Any ideas?
>
> Regards
> Mirko
>
> -Ursprüngliche Nachricht-
> Von: aspectj-users-boun...@eclipse.org
> [mailto:aspectj-users-boun...@eclipse.org] Im Auftrag von Sertic Mirko, Bedag
> Gesendet: Freitag, 19. Oktober 2012 08:53
> An: aspectj-users@eclipse.org
> Betreff: Re: [aspectj-users] Intercepting field access and thread-safety
>
> argg, yes, of course, you are right.
>
> Regards
> Mirko
>
> -Ursprüngliche Nachricht-
> Von: aspectj-users-boun...@eclipse.org
> [mailto:aspectj-users-boun...@eclipse.org] Im Auftrag von Romain MULLER
> Gesendet: Freitag, 19. Oktober 2012 08:14
> An: aspectj-users@eclipse.org
> Betreff: Re: [aspectj-users] Intercepting field access and thread-safety
>
> You'll want to use:
>
> around(Object val) : get(@Annotation * *.*) && args(val) {...}
>
> _
> Sent over RFC-1149 compliant transport - please excuse occasionnal packet loss
>
> Le 19 oct. 2012 à 08:09, "Sertic Mirko, Bedag" a
> écrit :
>
>> Hi Andy
>>
>> No problem, and yes, this is exactly what i want. I didn't know that it is
>> possible to use an around advice with field get access. Thank you. What
>> would be the pointcut for every field get access, regardless of the field
>> type? I need to pass also the original value of the field, so i can change
>> it in advice.
>>
>> I think the expression would be:
>>
>> get(@MyAnnotation * *.*)
>>
>> but how do i pass original value?
>>
>> Regards
>> Mirko
>>
>> -Ursprüngliche Nachricht-
>> Von: aspectj-users-boun...@eclipse.org
>> [mailto:aspectj-users-boun...@eclipse.org] Im Auftrag von Andy Clement
>> Gesendet: Freitag, 19. Oktober 2012 04:53
>> An: aspectj-users@eclipse.org
>> Betreff: Re: [aspectj-users] Intercepting field access and
>> thread-safety
>>
>> Hi,
>>
>> Sorry for the late reply, we are all at Spring One 2GX. How about:
>>
>> public class Code {
>> int i = 5;
>> public static void main(String[] argv) {
>> new Code().foo();
>> }
>> public void foo() {
>> System.out.println(i);
>> }
>> }
>>
>> aspect X {
>> int around(): get(int Code.i) {
>> return 42;
>> }
>> }
>>
>> Does that do what you want?
>>
>> Andy
>>
>> On 16 October 2012 12:16, Sertic Mirko, Bedag wrote:
>>> Hi there
>>>
>>> I'd like to know if it's possible to incercept a get field access
>>> using AspectJ and modify the returned value.
>>>
>>> Of course i could modify the field and set a new value using a before
>>> advice, but if the affected instance would be used in a multi
>>> threaded environment, this could lead to unwanted race conditions. So
>>> it is possible to intercept a field get access and return a defined
>>> value without modifying the original value of the field?
>>>
>>> Thanks a lot
>>>
>>> Mirko
>>>
>>>
>>> __
Re: [aspectj-users] Intercepting field access and thread-safety
BTW - I think it'd be good practice to exclude final fields from your advice,
and possibly declare a warning when a final field is annotated with your marker
annotation.
[ Romain Muller | Software Development Engineer | +33 (0)6 48 25 66 70 |
romain.mul...@esial.net ]
Le 19 oct. 2012 à 08:53, "Sertic Mirko, Bedag" a écrit :
> argg, yes, of course, you are right.
>
> Regards
> Mirko
>
> -Ursprüngliche Nachricht-
> Von: aspectj-users-boun...@eclipse.org
> [mailto:aspectj-users-boun...@eclipse.org] Im Auftrag von Romain MULLER
> Gesendet: Freitag, 19. Oktober 2012 08:14
> An: aspectj-users@eclipse.org
> Betreff: Re: [aspectj-users] Intercepting field access and thread-safety
>
> You'll want to use:
>
> around(Object val) : get(@Annotation * *.*) && args(val) {...}
>
> _
> Sent over RFC-1149 compliant transport - please excuse occasionnal packet loss
>
> Le 19 oct. 2012 à 08:09, "Sertic Mirko, Bedag" a
> écrit :
>
>> Hi Andy
>>
>> No problem, and yes, this is exactly what i want. I didn't know that it is
>> possible to use an around advice with field get access. Thank you. What
>> would be the pointcut for every field get access, regardless of the field
>> type? I need to pass also the original value of the field, so i can change
>> it in advice.
>>
>> I think the expression would be:
>>
>> get(@MyAnnotation * *.*)
>>
>> but how do i pass original value?
>>
>> Regards
>> Mirko
>>
>> -Ursprüngliche Nachricht-
>> Von: aspectj-users-boun...@eclipse.org
>> [mailto:aspectj-users-boun...@eclipse.org] Im Auftrag von Andy Clement
>> Gesendet: Freitag, 19. Oktober 2012 04:53
>> An: aspectj-users@eclipse.org
>> Betreff: Re: [aspectj-users] Intercepting field access and
>> thread-safety
>>
>> Hi,
>>
>> Sorry for the late reply, we are all at Spring One 2GX. How about:
>>
>> public class Code {
>> int i = 5;
>> public static void main(String[] argv) {
>> new Code().foo();
>> }
>> public void foo() {
>> System.out.println(i);
>> }
>> }
>>
>> aspect X {
>> int around(): get(int Code.i) {
>> return 42;
>> }
>> }
>>
>> Does that do what you want?
>>
>> Andy
>>
>> On 16 October 2012 12:16, Sertic Mirko, Bedag wrote:
>>> Hi there
>>>
>>> I'd like to know if it's possible to incercept a get field access
>>> using AspectJ and modify the returned value.
>>>
>>> Of course i could modify the field and set a new value using a before
>>> advice, but if the affected instance would be used in a multi
>>> threaded environment, this could lead to unwanted race conditions. So
>>> it is possible to intercept a field get access and return a defined
>>> value without modifying the original value of the field?
>>>
>>> Thanks a lot
>>>
>>> Mirko
>>>
>>>
>>> ___
>>> aspectj-users mailing list
>>> aspectj-users@eclipse.org
>>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>> ___
>> aspectj-users mailing list
>> aspectj-users@eclipse.org
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>> ___
>> aspectj-users mailing list
>> aspectj-users@eclipse.org
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
Re: [aspectj-users] Intercepting field access and thread-safety
You'll want to use:
around(Object val) : get(@Annotation * *.*) && args(val) {...}
_
Sent over RFC-1149 compliant transport - please excuse occasionnal packet loss
Le 19 oct. 2012 à 08:09, "Sertic Mirko, Bedag" a écrit :
> Hi Andy
>
> No problem, and yes, this is exactly what i want. I didn't know that it is
> possible to use an around advice with field get access. Thank you. What would
> be the pointcut for every field get access, regardless of the field type? I
> need to pass also the original value of the field, so i can change it in
> advice.
>
> I think the expression would be:
>
> get(@MyAnnotation * *.*)
>
> but how do i pass original value?
>
> Regards
> Mirko
>
> -Ursprüngliche Nachricht-
> Von: aspectj-users-boun...@eclipse.org
> [mailto:aspectj-users-boun...@eclipse.org] Im Auftrag von Andy Clement
> Gesendet: Freitag, 19. Oktober 2012 04:53
> An: aspectj-users@eclipse.org
> Betreff: Re: [aspectj-users] Intercepting field access and thread-safety
>
> Hi,
>
> Sorry for the late reply, we are all at Spring One 2GX. How about:
>
> public class Code {
> int i = 5;
> public static void main(String[] argv) {
>new Code().foo();
> }
> public void foo() {
>System.out.println(i);
> }
> }
>
> aspect X {
> int around(): get(int Code.i) {
>return 42;
> }
> }
>
> Does that do what you want?
>
> Andy
>
> On 16 October 2012 12:16, Sertic Mirko, Bedag wrote:
>> Hi there
>>
>> I'd like to know if it's possible to incercept a get field access using
>> AspectJ and modify the returned value.
>>
>> Of course i could modify the field and set a new value using a before
>> advice, but if the affected instance would be used in a multi threaded
>> environment, this could lead to unwanted race conditions. So it is possible
>> to intercept a field get access and return a defined value without modifying
>> the original value of the field?
>>
>> Thanks a lot
>>
>> Mirko
>>
>>
>> ___
>> aspectj-users mailing list
>> aspectj-users@eclipse.org
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
smime.p7s
Description: S/MIME cryptographic signature
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
Re: [aspectj-users] A way to generate a static arrays of annoted classes.
In a way, that looks a bit like a problem that may be better solved using APT
(Annotation Processing Toolkit) and Java SPI (Service Provider Interfaces).
Essentially, you'd use APT tools to compile-time list all classes with your
annotation and dump their names in the appropriate file in META-INF for
java.util.ServiceLoader to pick up all the classes.
AFAIK, there isn't a way to achieve what you're trying to do with AspectJ.
Le 14 août 2012 à 09:16, Jean-Jacques Peyronel a écrit :
> Hi all,
>
> I would like to generate a static arrays of annoted classes.
>
> For exemple :
>
> @PutInArray
> Class A
>
> @PutInArray
> Class B
>
> @PutInArray
> Class C
>
> Class Tools{
> static Class getAllClasses() {
> throw new runtimeException("Not yet implemented");
> }
> }
>
> Do you have an idea how to make it by aspectj ?
>
> Best regards.
> Jean-Jacques.
>
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
Re: [aspectj-users] Getting time of invocation from return
It appears to me that what you're really trying to achieve is what an "around"
advise is made for...
around() : SomePointCut() {
final long startTime = System.currentTimeInMillis();
proceed();
System.out.println("Call to " + thisJoinPoint + " took " +
(System.currentTimeInMillis() - startTime + " milliseconds to return.");
}
You could of course capture the result of "proceed()" if you want to inspect it.
Le 9 août 2012 à 14:45, Srinivas S Tamvada a écrit :
> Hi
> I have a point cut to capture the return of a method.
> In this point cut, can I get the time when the method was invoked? ( I would
> of course get this if I put a point cut on the invocation rather than return).
>
> More generally, if I have a point cut on a method for entry and return , is
> there any way to correlate them together ? This should work even if there are
> multiple simultaneous invocations of the method.
>
> Thanks.
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
Re: [aspectj-users] Duplicate entries in logging in AspectJ
What does the advise(s) look like? -Romain. Le 9 août 2012 à 11:18, Jeevitha Muthusamy a écrit : > Hi, > We are using AspectJ to log the trace of our API execution. > When enabling Aspects we receive duplicate entries of messages. > We are not using any framework or annotations. > > Herewith I have given the sample Pointcut we used to trace method exceution > : > >pointcut test(): > execution(* com.test.mail..*.*(..)); > >pointcut test1(): > execution(* com.test.mail.*.*(..)); > > pointcut test1(): > execution(* com.test.mail..*(..)); > > We used the three versions but we receive only duplicate entries. > > Sample Log Message: > Invoking method test. > Invoking method test. > Returning from method test > Returning from method test > > Please let me know how to resolve this issue!! > > Regards, > Jeevitha > > > > > > ___ > aspectj-users mailing list > aspectj-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/aspectj-users ___ aspectj-users mailing list aspectj-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/aspectj-users
Re: [aspectj-users] Pointcut not being executed...
EntityManager.persist() accepts an Obect argument. This static typing is
all that AspectJ will look at. You will have to intercept *all* calls to
the method, regardless of the argument type, then inspect
thisJoinPoint.getArgs()[0] to see if it's the type you're looking for, and
acting if it is the case.
_
Sent over RFC-1149 compliant transport - please excuse occasionnal packet
loss
Le 2 août 2012 à 17:44, Julien Martin a écrit :
Hello,
I mean to intercept only calls of *EntityManager.persist* when the argument
is of type *trc.suivi.domain.Pli*
I have tried the following code:
* pointcut catchIt(Pli pli) : (call(*
javax.persistence.EntityManager.persist(trc.suivi.domain.Pli)));*
* after(Pli pli) returning: catchIt(pli) {*
* log.debug("catchIt");*
* Evenement ev = new Evenement();*
* ev.setDateCreation(new Date());*
* ev.setIdObjetProprietaire(pli.getId());*
* evenementRepository.save(ev);*
* }*
and nothing happens.
Can anyone please help?
Regards,
J.
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
smime.p7s
Description: S/MIME cryptographic signature
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
Re: [aspectj-users] Advising javax.persistence.EntityManager with AspectJ not working
So your problem might be that classes in javax.* aren't woven.
It could also be that the EntityManager method you're calling is actually not
defined in javax.persistence.EntityManager itself, but by a subclass thereof,
in which case you'd use the following pointcut instead:
execution(* javax.persistence.EntityManager+.persist(..));
[ Romain Muller | Software Development Engineer | +33 (0)6 48 25 66 70 |
romain.mul...@esial.net ]
Le 2 août 2012 à 15:55, Julien Martin a écrit :
> Using "call" works and "execution" does not.
> Thanks a lot Romain!
>
> 2012/8/2 Romain Muller
> Have you tried switching your pointcut from "execution" to "call" and see if
> that works any better?
>
> [ Romain Muller | Software Development Engineer | +33 (0)6 48 25 66 70 |
> romain.mul...@esial.net ]
>
> Le 2 août 2012 à 15:49, Julien Martin a écrit :
>
>> Hello,
>>
>> I am trying to advise javax.persistence.EntityManager with AspectJ and
>> Spring. It just does not work: no error and no "caught" on the console...
>>
>> Here is my aspect:
>>
>> package trc.suivi.aspects;
>>
>>
>>
>> public aspect EventManagerAspect {
>>
>>
>>
>> public EventManagerAspect() {}
>>
>>
>>
>> pointcut catchIt() : (execution(*
>> javax.persistence.EntityManager.persist(..)));
>>
>>
>>
>> after() returning: catchIt() {
>>
>>
>> System.out.println("caught");
>>
>>
>> }
>>
>>
>>
>> }
>>
>>
>> Here is how I configured my aspect in Spring:
>>
>> > factory-method="aspectOf"/>
>> Can anyone please help?
>> Regards,
>> Julien.
>> ___
>> aspectj-users mailing list
>> aspectj-users@eclipse.org
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
Re: [aspectj-users] Advising javax.persistence.EntityManager with AspectJ not working
Have you tried switching your pointcut from "execution" to "call" and see if
that works any better?
[ Romain Muller | Software Development Engineer | +33 (0)6 48 25 66 70 |
romain.mul...@esial.net ]
Le 2 août 2012 à 15:49, Julien Martin a écrit :
> Hello,
>
> I am trying to advise javax.persistence.EntityManager with AspectJ and
> Spring. It just does not work: no error and no "caught" on the console...
>
> Here is my aspect:
>
> package trc.suivi.aspects;
>
>
> public aspect EventManagerAspect {
>
>
> public EventManagerAspect() {}
>
>
> pointcut catchIt() : (execution(*
> javax.persistence.EntityManager.persist(..)));
>
>
> after() returning: catchIt() {
>
> System.out.println("caught");
>
> }
>
>
> }
>
> Here is how I configured my aspect in Spring:
>
>
> Can anyone please help?
> Regards,
> Julien.
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
Re: [aspectj-users] Keeping advice code DRY when using ambiguous bindings
I forgot the "return" only in email. It is there in the code I tested...
Good catch though :)
_
Sent over RFC-1149 compliant transport - please excuse occasionnal packet
loss
Le 28 juil. 2012 à 09:07, Gopinathan Balaji a
écrit :
Hi,
Does, maybe, a
"return pjp.proceed()"
in the place of
"pjp.proceed()"
help?
-B.
------
*From:* Romain Muller
*To:* aspectj-users@eclipse.org
*Sent:* Friday, July 27, 2012 5:46 PM
*Subject:* [aspectj-users] Keeping advice code DRY when using ambiguous
bindings
Hi,
Given the following high-level pointcuts:
* AnyMethod() : execution(* *(..));
* AnyThrowing() : execution(* *(..) throws (!RuntimeException+));
* AnnotatedClass(SomeAnnotation annotation) : within(@SomeAnnotation *) &&
@within(annotation);
* AnnotatedMethod(SomeAnnotation annotation) : execution(@SomeAnnotation *
*(..)) && @annotation(annotation);
I want to around-advise some logic on the following join points:
1. AnnotatedClass(annotation) && AnyMethod() && !AnyThrowing() &&
!AnnotatedMethod(*);
2. AnnotatedClass(annotation) && AnyThrowing() && !AnnotatedMethod(*);
3. AnnotatedMethod(annotation) && !AnyThrowing();
4. AnnotatedMethod(annotation) && AnyThrowing();
The advise needs the information on the "most specific" @SomeAnnotation,
and in case the advised method throws checked exceptions, I need to
re-throw them unchanged.
Now, for all of these advises, I need to apply the exact same logic around
"proceed();", but I currently have to write it four times. I could reduce
it to two if I didn't care about re-throwing checked exceptions unchanged
(or would be OK to use Unsafe#throwException(Throwable)).
The advises pretty much look like the following (comments to call out the
pointcut specifics):
Object around(final SomeAnnotation annotation)
throws Exception // if it's a checked-throwing pointcut
: SomePointCut(annotation) {
try {
return SomeClass.doSomeStuff(new Callable(){
@Override public final Object call() throws Exception {
proceed();
}
});
} catch(final RuntimeException re) {
throw re;
} catch(final Exception e) {// if it's **not** a checked-throwing pointcut
throw new AssertionError("Shouldn't have caught checked exception"); // if
it's **not** a checked-throwing pointcut
} // if it's **not** a checked-throwing pointcut
}
So, SomeClass.doSomeStuff expects a callable, and will ".call()" it and let
thrown exceptions go out unchanged. I'm very annoyed having to create the
"new Callable" in every one of the four advises, so I've tried to have a
static method that gets a ProceedingJoinPoint in, to which I'd pass
"(ProceedingJoinPoint)thisJoinPoint", like so:
private static final Object doSomeStuffAroundProceed(final
ProceedingJoinPoint pjp) {
return SomeClass.doSomeStuff(new Callable(){
@Override public final Object call() throws Exception {
pjp.proceed();
}
});
}
But it turns out that when I do this, "pjp.proceed()" does nothing. Is
there anything i'm doing wrong.
Other than that, is there a way I could write a single advice that'd advise
the four cases at once?
*
*
*Thanks in advance,
[* Romain Muller *| *Software Development Engineer *|*
romain.mul...@esial.net *]*
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
smime.p7s
Description: S/MIME cryptographic signature
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
[aspectj-users] Keeping advice code DRY when using ambiguous bindings
Hi,
Given the following high-level pointcuts:
* AnyMethod() : execution(* *(..));
* AnyThrowing() : execution(* *(..) throws (!RuntimeException+));
* AnnotatedClass(SomeAnnotation annotation) : within(@SomeAnnotation *) &&
@within(annotation);
* AnnotatedMethod(SomeAnnotation annotation) : execution(@SomeAnnotation *
*(..)) && @annotation(annotation);
I want to around-advise some logic on the following join points:
1. AnnotatedClass(annotation) && AnyMethod() && !AnyThrowing() &&
!AnnotatedMethod(*);
2. AnnotatedClass(annotation) && AnyThrowing() && !AnnotatedMethod(*);
3. AnnotatedMethod(annotation) && !AnyThrowing();
4. AnnotatedMethod(annotation) && AnyThrowing();
The advise needs the information on the "most specific" @SomeAnnotation, and in
case the advised method throws checked exceptions, I need to re-throw them
unchanged.
Now, for all of these advises, I need to apply the exact same logic around
"proceed();", but I currently have to write it four times. I could reduce it to
two if I didn't care about re-throwing checked exceptions unchanged (or would
be OK to use Unsafe#throwException(Throwable)).
The advises pretty much look like the following (comments to call out the
pointcut specifics):
Object around(final SomeAnnotation annotation)
throws Exception // if it's a checked-throwing pointcut
: SomePointCut(annotation) {
try {
return SomeClass.doSomeStuff(new Callable(){
@Override public final Object call() throws Exception {
proceed();
}
});
} catch(final RuntimeException re) {
throw re;
} catch(final Exception e) {// if it's **not** a checked-throwing
pointcut
throw new AssertionError("Shouldn't have caught checked
exception"); // if it's **not** a checked-throwing pointcut
} // if it's **not** a checked-throwing pointcut
}
So, SomeClass.doSomeStuff expects a callable, and will ".call()" it and let
thrown exceptions go out unchanged. I'm very annoyed having to create the "new
Callable" in every one of the four advises, so I've tried to have a static
method that gets a ProceedingJoinPoint in, to which I'd pass
"(ProceedingJoinPoint)thisJoinPoint", like so:
private static final Object doSomeStuffAroundProceed(final ProceedingJoinPoint
pjp) {
return SomeClass.doSomeStuff(new Callable(){
@Override public final Object call() throws Exception {
pjp.proceed();
}
});
}
But it turns out that when I do this, "pjp.proceed()" does nothing. Is there
anything i'm doing wrong.
Other than that, is there a way I could write a single advice that'd advise the
four cases at once?
Thanks in advance,
[ Romain Muller | Software Development Engineer | romain.mul...@esial.net ]
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
