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... > Phil > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
