[slf4j-dev] Repost

[Ceki Gulcu]

Thorbjørn Ravn Andersen wrote:
> Ceki Gulcu skrev  den 25-08-2008 15:53:

> 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...

If your are uncomfortable with incorporating XLogger in the instrumentation 
code, that's fine with me. However, if you are uncomfortable with XLogger by 
itself, regardless of instrumentation, then I welcome any constructive criticism 
you might have, as would, I am sure, Ralph Goers. Do not hesitate to start a new 
thread if you do voice criticism.

[snip]

>> 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.

Duly noted.

> 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.

Yes, fine 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).

Let's start simple by ignoring the javassist.jar dependency. We can always 
incorporate it later if and when it really becomes an issue. To be honest, I 
have always found it repulsive the way BEA repackages jars left and right in 
Weblogic. It's just lame, me thinks.

As I see it, if someone is willing to instrument their code using byte-code 
enhancements, they can add javassist.jar on the classpath.Moreover, if we can 
get away by not incorporating slf4j-api.jar, then why should javassist.jar be 
any different, or am I missing something?

-- 
Ceki Gülcü