[logback-dev] Least-effort logging with bytecode modification
Thorbjørn Ravn Andersen
ravn at runjva.com
Tue Nov 18 19:09:50 CET 2008
Ceki Gulcu skrev:
> Hello Robert,
> Robert Elliot wrote:
> > Thanks - I checked the slf4j-ext project when I started, but not the
> > Subversion repository. I presume this is a post-compile step rather
> > than runtime byte code alteration?
> No, the Agent extensions perform byte code engineering at
> runtime. BTW, the subject of this thread is "Least-effort logging with
> *bytecode* modification".
The javaagent interface allows bytecode modification on the way through
the JVM just before the class loader magically converts the flat bytes
to a REAL object. Hence the title is quite fitting (if you know all
the dirty details).
> > Out of curiousity (not criticising!) what was the reason for picking
> > javassist rather than aspectj?
> I think the goal was to add logging at runtime. Can you do byte code
> engineering with AspectJ? I'll let Thorbjørn give a more authoritative
I too thought that AspectJ was a compile-time byte code instrumentation,
but it was brought to my attention when the article had been published
where I made javassist do the work, that it can do classload-time byte
code instrumentation too. I then looked somewhat into it, but didn't
reach a satisfactory result so I went with what worked for the
implementation currently in Subversion.
The idea of aspects here and there and everywhere inside Eclipse didn't
agree with me (but that is a completely different issue, I think that
for _debugging_ purposes aspects are a god send, but not for normal
"progress"-logging) so I left it again - I have this puristic approach
saying that given a JDK on a freshly installed machine and one of ant or
eclipse (and recently maven) available to you - depending on the needs
of the project - you should be able to build and deploy your stuff
without jumping through hoops to get there. I have a few things to
make my life easier but then I try to move them into the distributions
of ant or eclipse (and recently maven) to allow the above. This allows
me to throw away installations and workspaces easily, and migrate to
other machines as it is just another install-configure-build-deploy
circle. This spartan way of thinking has worked well for me - others
may find it too much work with too little return. It is a matter of taste.
I believe that the current java agent in slf4j-ext is great for getting
the low fruit - those using slf4j can just include the two jars in their
deployments - and if needed add the javaagent to get instant logging. A
few more options may be relevant if it can be kept in this very simple
current approach (the hard part is getting the information out of the
byte code framework), but not more than that. This is not designed to
grow to be a full aspect implementation, but it is a great way to SEE
the benefit of aspects for _debugging_ (which accidentially also easily
extends to _profiling_).
At this point of time it would be great if the initial effort to get to
instrumented logging with slf4j-ext could lead directly into an AspectJ
trail that would start with a script that does exactly the same as the
slf4j-ext version, and potentially lead to something much bigger.
Frankly I have no idea what _can_ be done, but I believe that one
possible outcome could be combining this with the XLogger and the
profiling stuff plus a new XMLAppender which can produce output suitable
for other tools. I have SEEN descriptions of such XML but I cannot
remember where now. It is on my "put a bookmark if it shows up again"-list.
Robert, please feel encouraged to present your findings - I'd much
rather see some unfinished stuff now than a polished presentation next
year - and let us see what you can do :) This might very well be
something very useful even though it is very simple (Ceki probably has a
lot to tell about making simple code useful) All AOP material I have
seen say that it is GREAT for injecting log statements, but I have
mostly seen words and very little code.
I have spent literaly hours today writing log.debug() statements for a
performance plagued application so here I would have loved to have a
tool to help me do SOME of it (except it was for Java 1.4 sigh).
(and it appears that my Thunderbird at work has a hard time picking the
right sender address, so my answers cannot catch a debate like this
Thorbjørn Ravn Andersen "...plus... Tubular Bells!"
More information about the logback-dev