RE: Log4J vs. java.util.logging
Hi all, thanks a lot for your mails. It seems that Log4J is definitive the right choice. Bye Matthias -- Matthias Petersen ms management systems gmbh Krokamp 29 24539 Neumünster Fon: +49. 4321. 9995-49 Fax: +49. 4321. 9995-41 E-Mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Log4J vs. java.util.logging
Matthias, Admittedly, many of us at here at log4j-user@ are biased in favor of log4j. At 08:14 AM 10/27/2003 +0100, Matthias Petersen wrote: Hi all, thanks a lot for your mails. It seems that Log4J is definitive the right choice. Bye Matthias -- Matthias Petersen -- Ceki Gülcü For log4j documentation consider "The complete log4j manual" ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp import org.apache.Facetime; ApacheCon US 2003, 18-21 November http://apachecon.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Log4J vs. java.util.logging
> Admittedly, many of us at here at log4j-user@ are biased in favor of log4j. Really? Naah. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Log4J vs. java.util.logging
One additional quick thought: someone mentioned using Commons Logging to switch back and forth between JDK logging, Log4j, and potentially other logging solutions. If one wraps Log4j as recommended by Ceki's book using Decorator (GoF), one realizes a similar effect. The wrapper class could even load a particular logging solution at run-time based on system configuration. I get the impression that in general Ceki recommends wrapping Log4j. Note that he strongly recommends against sub-classing Logger, which is often a developer's first direction. Decorator is recommended, although I don't think an interface for Logger exists as such so one must emulate the Log4j interface if so desired. An organization could also of course choose more of an Adapter approach, and make the interface whatever they prefer, potentially shooting for backward compatibility with a logging solution already in existence in the enterprise. This approach mitigates the risk of being tied to a particular solution, while not incurring the potential pains of Commons Logging. Mike -Original Message- From: Tbee [mailto:[EMAIL PROTECTED] Sent: Monday, October 27, 2003 3:59 AM To: Log4J Users List Subject: RE: Log4J vs. java.util.logging > Admittedly, many of us at here at log4j-user@ are biased in favor of log4j. Really? Naah. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- This message and any included attachments are from Siemens Medical Solutions USA, Inc. and are intended only for the addressee(s). The information contained herein may include trade secrets or privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you received this message in error, or have reason to believe you are not authorized to receive it, please promptly delete this message and notify the sender by e-mail with a copy to [EMAIL PROTECTED] Thank you - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Log4J vs. java.util.logging
If I read the commons-logging articles correctly, this is exactly how commons- logging came to be. A wrapper grown dynamic. Tom Quoting Lutz Michael <[EMAIL PROTECTED]>: > > > One additional quick thought: someone mentioned using Commons Logging to > switch back and forth between JDK logging, Log4j, and potentially other > logging solutions. > > If one wraps Log4j as recommended by Ceki's book using Decorator (GoF), one > realizes a similar effect. The wrapper class could even load a particular > logging solution at run-time based on system configuration. > > I get the impression that in general Ceki recommends wrapping Log4j. Note > that he strongly recommends against sub-classing Logger, which is often a > developer's first direction. Decorator is recommended, although I don't > think an interface for Logger exists as such so one must emulate the Log4j > interface if so desired. An organization could also of course choose more > of an Adapter approach, and make the interface whatever they prefer, > potentially shooting for backward compatibility with a logging solution > already in existence in the enterprise. > > This approach mitigates the risk of being tied to a particular solution, > while not incurring the potential pains of Commons Logging. > > Mike > > > -Original Message- > From: Tbee [mailto:[EMAIL PROTECTED] > Sent: Monday, October 27, 2003 3:59 AM > To: Log4J Users List > Subject: RE: Log4J vs. java.util.logging > > > > Admittedly, many of us at here at log4j-user@ are biased in favor of > log4j. > > Really? Naah. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- - > This message and any included attachments are from Siemens Medical Solutions > > USA, Inc. and are intended only for the addressee(s). > The information contained herein may include trade secrets or privileged or > otherwise confidential information. Unauthorized review, forwarding, > printing, > copying, distributing, or using such information is strictly prohibited and > may > be unlawful. If you received this message in error, or have reason to > believe > you are not authorized to receive it, please promptly delete this message and > > notify the sender by e-mail with a copy to [EMAIL PROTECTED] Thank you > > - > 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]
RE: Log4J vs. java.util.logging
Unless I am mistaken, commons-logging was always dynamic. It always used classloader tricks to determine which logging API to use. At 02:26 PM 10/27/2003 +0100, Tbee wrote: If I read the commons-logging articles correctly, this is exactly how commons- logging came to be. A wrapper grown dynamic. Tom Quoting Lutz Michael <[EMAIL PROTECTED]>: > > > One additional quick thought: someone mentioned using Commons Logging to > switch back and forth between JDK logging, Log4j, and potentially other > logging solutions. > > If one wraps Log4j as recommended by Ceki's book using Decorator (GoF), one > realizes a similar effect. The wrapper class could even load a particular > logging solution at run-time based on system configuration. > > I get the impression that in general Ceki recommends wrapping Log4j. Note > that he strongly recommends against sub-classing Logger, which is often a > developer's first direction. Decorator is recommended, although I don't > think an interface for Logger exists as such so one must emulate the Log4j > interface if so desired. An organization could also of course choose more > of an Adapter approach, and make the interface whatever they prefer, > potentially shooting for backward compatibility with a logging solution > already in existence in the enterprise. > > This approach mitigates the risk of being tied to a particular solution, > while not incurring the potential pains of Commons Logging. > > Mike > > > -Original Message- > From: Tbee [mailto:[EMAIL PROTECTED] > Sent: Monday, October 27, 2003 3:59 AM > To: Log4J Users List > Subject: RE: Log4J vs. java.util.logging > > > > Admittedly, many of us at here at log4j-user@ are biased in favor of > log4j. > > Really? Naah. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- - > This message and any included attachments are from Siemens Medical Solutions > > USA, Inc. and are intended only for the addressee(s). > The information contained herein may include trade secrets or privileged or > otherwise confidential information. Unauthorized review, forwarding, > printing, > copying, distributing, or using such information is strictly prohibited and > may > be unlawful. If you received this message in error, or have reason to > believe > you are not authorized to receive it, please promptly delete this message and > > notify the sender by e-mail with a copy to [EMAIL PROTECTED] Thank you > > - > 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] -- Ceki Gülcü For log4j documentation consider "The complete log4j manual" ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp import org.apache.Facetime; ApacheCon US 2003, 18-21 November http://apachecon.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Log4J vs. java.util.logging
Howdy, This is true -- in fact it grew out of a classloader discovery type mechanism into more of a wrapper ;) Yoav Shapira Millennium ChemInformatics >-Original Message- >From: Ceki Gülcü [mailto:[EMAIL PROTECTED] >Sent: Monday, October 27, 2003 8:42 AM >To: Log4J Users List >Subject: RE: Log4J vs. java.util.logging > > >Unless I am mistaken, commons-logging was always dynamic. It always used >classloader tricks to determine which logging API to use. > >At 02:26 PM 10/27/2003 +0100, Tbee wrote: >>If I read the commons-logging articles correctly, this is exactly how >commons- >>logging came to be. A wrapper grown dynamic. >> >>Tom >> >> >> >>Quoting Lutz Michael <[EMAIL PROTECTED]>: >> >> > >> > >> > One additional quick thought: someone mentioned using Commons Logging >to >> > switch back and forth between JDK logging, Log4j, and potentially other >> > logging solutions. >> > >> > If one wraps Log4j as recommended by Ceki's book using Decorator (GoF), >one >> > realizes a similar effect. The wrapper class could even load a >particular >> > logging solution at run-time based on system configuration. >> > >> > I get the impression that in general Ceki recommends wrapping Log4j. >Note >> > that he strongly recommends against sub-classing Logger, which is often >a >> > developer's first direction. Decorator is recommended, although I >don't >> > think an interface for Logger exists as such so one must emulate the >Log4j >> > interface if so desired. An organization could also of course choose >more >> > of an Adapter approach, and make the interface whatever they prefer, >> > potentially shooting for backward compatibility with a logging solution >> > already in existence in the enterprise. >> > >> > This approach mitigates the risk of being tied to a particular >solution, >> > while not incurring the potential pains of Commons Logging. >> > >> > Mike >> > >> > >> > -Original Message- >> > From: Tbee [mailto:[EMAIL PROTECTED] >> > Sent: Monday, October 27, 2003 3:59 AM >> > To: Log4J Users List >> > Subject: RE: Log4J vs. java.util.logging >> > >> > >> > > Admittedly, many of us at here at log4j-user@ are biased in favor of >> > log4j. >> > >> > Really? Naah. >> > >> > - >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> - >- >>- >> > This message and any included attachments are from Siemens Medical >> Solutions >> > >> > USA, Inc. and are intended only for the addressee(s). >> > The information contained herein may include trade secrets or >> privileged or >> > otherwise confidential information. Unauthorized review, forwarding, >> > printing, >> > copying, distributing, or using such information is strictly prohibited >and >> > may >> > be unlawful. If you received this message in error, or have reason to >> > believe >> > you are not authorized to receive it, please promptly delete this >> message and >> > >> > notify the sender by e-mail with a copy to [EMAIL PROTECTED] Thank >you >> > >> > - >> > 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] > >-- >Ceki Gülcü > > For log4j documentation consider "The complete log4j manual" > ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp > > import org.apache.Facetime; > ApacheCon US 2003, 18-21 November http://apachecon.com/ > > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Log4J vs. java.util.logging
> Unless I am mistaken, commons-logging was always dynamic. It always used > classloader tricks to determine which logging API to use. Ok, then I stand corrected (and need to reread the articles ;-). Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
log4j 1.3 domains, anyone?
I was reading the plan page of log4j 1.3 and found this: Domains: "This is a very powerful and innovative concept that extends the notion of hierarchical loggers. It will also allow dynamic logging with pin-point accuracy. It was first suggested to me by Scott Stark of JBoss fame." Is there a writeup somewhere or can someone point me to an archived message that might describe the high level intension of Domains and how they will fit in the current log4j object world of loggers, appenders, levels, filters, etc.? Thanks in advance. doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: log4j 1.3 domains, anyone?
Hi Doug, Domains will be presented at ApacheCon 2003. The slides will be available after the conference. At 03:36 PM 10/27/2003 -0500, you wrote: I was reading the plan page of log4j 1.3 and found this: Domains: "This is a very powerful and innovative concept that extends the notion of hierarchical loggers. It will also allow dynamic logging with pin-point accuracy. It was first suggested to me by Scott Stark of JBoss fame." Is there a writeup somewhere or can someone point me to an archived message that might describe the high level intension of Domains and how they will fit in the current log4j object world of loggers, appenders, levels, filters, etc.? Thanks in advance. doug -- Ceki Gülcü For log4j documentation consider "The complete log4j manual" ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp import org.apache.Facetime; ApacheCon US 2003, 18-21 November http://apachecon.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: log4j 1.3 domains, anyone?
Is there a writeup somewhere or can someone point me to an archived message that might describe the high level intension of Domains and how they will fit in the current log4j object world of loggers, appenders, levels, filters, etc.? > Domains will be presented at ApacheCon 2003. The slides will be > available after the conference. Oh my, now I'm starting to get curious also ;-) Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
