[logback-dev] Least-effort logging with bytecode modification

[Thorbjørn Ravn Andersen]

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
> answer.
>   
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 
early, sorry).


-- 
  Thorbjørn Ravn Andersen  "...plus... Tubular Bells!"