commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <Joerg.Schai...@Elsag-Solutions.com>
Subject RE: [pool][dbcp] instrumentation
Date Tue, 20 Nov 2007 09:30:29 GMT
Phil Steitz wrote:
> On Nov 19, 2007 11:46 PM, Jörg Schaible
> <Joerg.Schaible@elsag-solutions.com> wrote:
>> 
>> Phil Steitz wrote:
[snip]
>>> Any other comments on the naming, levels, use of JUL before I start?
>> 
>> Why not using commons-logging? It supports trace level. JUL
> is really a pain. It is applicable for applications like
> Tomcat, but not really for components. Everybody that tried
> to use an own JUL-formatter knows what I mean. Big enterprise
> companies normally hesitate or simply do not permit to add
> 3rd party jars to the JVM classpath.
> 
> Can you explain more what you mean about third party jars here?  It
> was general pushback / hesitancy to bring in dependency on
> commons-logging (or anything else) that led us to think about just
> using jdk logging.  I was going to add a simple formatter (all that I
> need is to expose the thread ID) and bundle it with pool, making it
> also available to dbcp. 
> 
> I am open to either approach and don't particularly care which API we
> use.  I just want to minimize conflict / configuration hassles for
> users. 

Since the JUL loggers sit in the system class path, any formatter implementation *must* be
available also in the system class path. For simple Java applications this is no issue, simply
set the VM class path at startup, but this is no longer true if the app deals with classloaders.
I was bitten the first time using the uberjar mechanism of Maven1 that uses an own classloader
to extract the classes from the embedded jars, my JUL formatter was simply no longer available.
In a Java EE environment your "simple" formatter is never used - unless you put your jar with
the formatter implementation into the JRE's ext directory or setup the app server accordingly.
However, I don't have to tell you, that as consequence no web or enterprise app will be able
to use its own version of this jar.

There is a reason why JUL was never a real success story.

- Jörg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message