>
>
> Aspects don't know what other aspects are in effect. This means any
> coordination would have to be done by you. Given that the same
> exception will have the same hashcode you can build something in that
> tracks what has or hasn't been reported already. If the same aspect
> is reporting an exception multiple times, it is possible to use
> cflow/cflowbelow to report it just once.
>
Only one aspect (LoggingAspect) defines the advices, but the pointcut used
in them is abstract and is overridden in the derived aspects. Is this
enough to classify the case as driven by multiple aspects? I had to split
the logic amongst the different aspects in order to have the flexibility in
defining what exactly gets logged. But maybe there is another way to reach
the same goal while keeping a single aspect, which would allow me to use
the cflow/cflowbelow to achieve what I need. Could you share how would you
tackle the exception logging problem?
I am not sure I understand how to exploit your idea about the exception
hashcodes. Could you provide a few hints?
In general, is it possible either from the pointcut definition or from the
advice itself to deduce whether the same advice would be applied lower in
the call stack?
>
> You might want to look at
> http://www.ibm.com/developerworks/rational/library/06/0711_hawkins_january/
> as an article on logging/exception handling with AJ.
>
I have read the article. Very interesting, it has demonstrated to me that
my aspect is unable to log static methods and I have learned several nice
tricks, but it does not contain any hints at how to solve the repeated
exception logging problem.
Thank you very much.
--
View this message in context:
http://aspectj.2085585.n4.nabble.com/How-to-exclude-nested-matching-method-executions-tp4172075p4178304.html
Sent from the AspectJ - users mailing list archive at Nabble.com.
_______________________________________________
aspectj-users mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/aspectj-users
