commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [pool][dbcp] instrumentation
Date Sun, 09 Dec 2007 01:44:01 GMT
On 20/11/2007, Phil Steitz <phil.steitz@gmail.com> wrote:
> On Nov 20, 2007 2:30 AM, Jörg Schaible
> <Joerg.Schaible@elsag-solutions.com> wrote:
> > 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.
>
> Thanks, Jorg.  I understand now. This is not good.  So, any objections
> to bringing in commons-logging, or alternative ideas?

As a commons project, IMO it should be using commons-logging.

Likewise POOL...

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

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


Mime
View raw message