On Dec 8, 2007 6:44 PM, sebb <[EMAIL PROTECTED]> wrote: > > On 20/11/2007, Phil Steitz <[EMAIL PROTECTED]> wrote: > > On Nov 20, 2007 2:30 AM, Jörg Schaible > > <[EMAIL PROTECTED]> wrote: > > > Phil Steitz wrote: > > > > On Nov 19, 2007 11:46 PM, Jörg Schaible > > > > <[EMAIL PROTECTED]> 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... >
Thanks for the feedback. I agree both should use the same approach. I will translate the JUL stuff that I have for pool to use the c-l API and start committing. Thanks in advance for patches / feedback. Phil --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
