[slf4j-dev] Repost

[Thorbjørn Ravn Andersen]

Ceki Gulcu skrev  den 25-08-2008 15:53:
>
>> I still keep the "if (log.isDebugEnabled()) log.debug("a=" + a + ", b=" 
>> + b))" approach as it avoids having to do the equivalent of autoboxing 
>> when creating the objects to pass.  Also it works for me :)
>>     
>
> Have you looked at the code in org.slf4j.ext.XLogger? There is some overlap in 
> intent or even complementarity. In particular, you could pass on the intercepted 
> method parameters to XLogger.enrty(Object... argArray) and the intercepted 
> return value to XLogger.exit(Object result).
>
>   
No, I have not, but have now had a quick peek at 
http://svn.slf4j.org/viewvc/slf4j/trunk/slf4j-ext/src/main/java/org/slf4j/XLogger.java?revision=1091&view=markup&pathrev=1091

I see that your intent is to provide some standard encapsulation of 
logging statements, but I am not certain that this is the right approach 
as opposed to the crystal clear feeling I have that the slf4j approach 
is the right way to solve the log backend selection.

And I still have to autobox...


>> Please note that each Java agent must be present in an executable jar, 
>> which in turn means that you can maximally have one agent in a given 
>> jar.    There is also the issue of the supportive javassist library, so 
>> if the license permits I suggest that this agent jar is a single 
>> download containing only the agent code with the javassist library 
>> enclosed, and that it is kept seperate and named accordingly.
>>     
>
> I have not used javassist before. AFAIL, Cglib and ASM are better known. Cglib 
> ships with Hibernate, so many application may already have it as a dependency. 
> ASM is very well documented and powerful. Was a there a particular reason for 
> choosing javassist instead of the more popular cglib? Looking at Hibernate 3.3, 
> it seems that both javaassist and cglib have become optional dependencies. Go 
> figure.
>   
Yes.  Javassist contains a java snippet compiler which makes it very 
easy to add new code for a byte code illiterate like me.  Hence I could 
get something working quickly which was the original intent, and which 
was just carried over for the article.



> Are you suggesting that the contents of javassit.jar be merged into 
> slf4j-ext.jar (assuming your instrumentation code goes into slf4j-ext.jar)?
>
>   
I don't think a suitable place would be slf4j-ext.jar as previously 
mentioned.

For this to be self-contained a suitable javassist.jar must be present 
on the classpath (as the agent.jar is treated like an executable jar the 
Class-Path line in the manifest is respected).  This is detailled in the 
fine article.

The easiest way to do this would be to have it embedded in a "suitable" 
way in the downloadable jar (regardless of the actual package used).
>   
>> A thing that might be interesting to have on the slf4j web site is a new 
>> section to the user guide named "Best practices" or similar.  This might 
>> get suitable attention and give some suitable help.  I have dug up the 
>> XML-snippet that makes Eclipse insert a logger defintiion when creating 
>> a new class. That would be perfect.
>>     
>
> We already have an FAQ. Please post a patch with the changes you have in mind.
>
>   
I will look at this later then.

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