[slf4j-dev] Repost

[Thorbjørn Ravn Andersen]

Ceki Gulcu skrev  den 25-08-2008 22:18:
>
> 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.
>
>   
I am thinking this over as I am trying to identify which problem it is 
that is being solved, instead of just seeing the tool.

>> 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?
>   
I believe so.  The reason why slf4j API does not have to be present is 
because it is not needed inside the agent to add the java snippets, but 
it must be available to the program being instrumented to be able to 
resolve the instrumented byte code in the classloader.  This to me means 
that either a full slfj4 + backend must be provided or the usual 
responsibilities must be obeyed by the deployer.

The agent needs javaassist to run at all.

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