I'm just curious, but why do this with an aspect? It's a standard feature in Log4j.
Use %c for the classname and %M for the method name in the conversion pattern in log4j.xml or log4j.properties There is probably also some placeholder for the line number, but I cannot remember which from the top of my head. Olle Hallin Senior Java Developer and Architect [email protected] www.crisp.se http://www.linkedin.com/in/ollehallin 2011/5/30 Andy Clement <[email protected]> > Hi, > > So you are not loadtime weaving, you are just compile time weaving. > The weaveinfo messages indicate the bytecode is being modified. I > guess you could check the woven output from the compile and verify the > calls to the logger have been advised. Using 'javap -private > -verbose' against a class in the woven output you should see wherever > there is a call to getLogger there is a call to the advice? > > Actually, one thing does seem unusual. Is your pointcut definetly just > this: > > call(* org.apache.log4j.Logger.*(..)) && !within(*..*Aspect); > > and in a singleton aspect? > > Because that can be fully statically matched, so I don't understand > why your weaveinfo message is suffixed with '[with runtime test]'. If > the runtime test (whatever it is) is failing it will not be running > your advice. If you want to post the snippet of bytecode around the > calls to getLogger we can check what the runtime test is. > > Andy > > On 27 May 2011 15:07, Abhijit Inamdar <[email protected]> wrote: > > I am trying to use AspectJ for tracing and I have hit the wall trying to > figure out this problem. I have a prototype where my code works but it does > not work with the "real" project. What I am trying to do is to prefix log > statements with some additional information(class, line number etc). > > Here is the code: > > pointcut logCall() : call(* org.apache.log4j.Logger.*(..)) && > !within(*..*Aspect); > > > > before() : logCall() { > > MDC.put(MDC_KEY, " (" + > thisEnclosingJoinPointStaticPart.getSourceLocation() > > + ") " + > thisEnclosingJoinPointStaticPart.getSignature().toShortString()); > > } > > > > after() : logCall() { > > MDC.remove(MDC_KEY); > > } > > > > In the prototype this works fine giving the following output(for > example): > > 2011-05-27 14:44:04,474 [main] WARN - (CommChannel.java:18) > CommChannel.doComm(..) Delivering message by channel > > > > where "Delivering message by channel" is the original logged message and > "(CommChannel.java:18) CommChannel.doComm(..)" was prefixed by the aspect > code shown above. > > > > However when I move this to my "real" project this does nothing. > > > > Compiler output seems to indicate that it is finding the right join > points. For example: > > > > [INFO] Join point 'method-call(org.apache.log4j.Logger > org.apache.log4j.Logger.getLogger(java.lang.Class))' in Type > 'com.mycompany.myapp.plugins.MyClass' (MyClass.java:55) advised by after > advice from ''com.mycompany.myapp.aspects.tracing.MyAspect' > (myaspects-2.0-SNAPSHOT.jar!MyAspect.class:65(from MyAspect.aj)) [with > runtime test] > > > > However the original log statement is logged without my aspect prefix. > Attaching a debugger to the process shows that it never enters the before > or after advice. This means if I remove the MDC code and simply enter log > statements into the before & after advice they are still never hit(i.e. the > issue is NOT with MDC). > > > > I am running: > > Ubuntu 10.4 (Kernel Linux 2.6.32-31-generic) > > Tomcat 6.0.32 > > Maven 2.2.1 with AspectJ dependencies > > <dependency> > > <groupId>org.aspectj</groupId> > > <artifactId>aspectjweaver</artifactId> > > <version>1.6.10</version> > > <scope>compile</scope> > > </dependency> > > <dependency> > > <groupId>org.aspectj</groupId> > > <artifactId>aspectjrt</artifactId> > > <version>1.6.10</version> > > </dependency> > > > > <plugin> ... > > > <artifactId>aspectj-maven-plugin</artifactId> > > <version>1.3.1</version> ... etc > > > > > > > > PLEASE NOTE: I am able to get tracing to work in the "real" app. It > just doesn't work with the above log4j pointcut. > > > > Sorry about the very long post but I am really out of ideas, so any > pointers for further investigation will the great. > > _______________________________________________ > > 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 >
_______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
