Hey, someone in my timezone! Excellent!
> private static final Logger CONFIG = Logger.getLogger("Config." +
> MyConfigurableObject.class);
This is the method I use to log the PERF level (inside my wrapper), because
I always want to redirect these to another appender (like a remote JDBC
appender). A fixed name logger might have been better because I have never
needed to filter per package as well, nor to increase/decrease the global
log level and have perf logging affected; it really does exist in isolation.
For CONFIG though, it still doesn't seem quite right. At the moment in our
code (with the wrapper stripped out) we have
logger.log(OurLevels.CONFIG, "Some useful config info....");
Under the scenario you described we would have
logger.log(OurLevels.INFO, "Some useful config info....");
I have chosen info here, but the level used is completely arbitrary which to
me raises a warning. Also to do something like "Set package
com.mycomp.package1 to show DEBUG level", which includes CONFIG as well,
would take two lines in the prop file, or logFactor5 viewer - i.e. have to
keep them in synch.
Also using a real level is easier for deployment/support staff, as they
certainly dont and shouldnt understand the package structure of an app, but
they can (on a good day!) get their heads around setting the level of
logging info on a global basis for an app, or at least displaying/not
displaying actual log lines using a simple html tool we developed.
> I think those that see TRACE as NOT useful are probably doing something
> like the above, where those that do see TRACE as useful are probably
> struggling with how to filter things. I could be wrong though.
For similar reasons I still definitely think its a huge advantage to have
High/Med/Low levels (dont care as much what they are called,
INFO/DEBUG/TRACE would probably do). Being able to set the non error
logging, app wide, at three levels gives plenty of control and flexibility
for deployers, support staff and developers to effectively deal with prod
issues, and developers to use during developement.
Thanks
Simon
GOLDMAN SACHS JBWERE PTY LTD DISCLAIMER
Goldman Sachs JBWere Pty Ltd and its related entities distributing this document and
each of their respective directors, officers and agents ("the Goldman Sachs JBWere
Group") believe that the information contained in this document is correct and that
any estimates, opinions, conclusions or recommendations contained in this document are
reasonably held or made as at the time of compilation. However, no warranty is made
as to the accuracy or reliability of any estimates, opinions, conclusions,
recommendations (which may change without notice) or other information contained in
this document and, to the maximum extent permitted by law, the Goldman Sachs JBWere
Group disclaims all liability and responsibility for any direct or indirect loss or
damage which may be suffered by any recipient through relying on anything contained or
omitted from this document.
Goldman Sachs JBWere does not represent or warrant the attached files are free from
computer viruses or other defects. The attached files are provided, and may only be
used, on the basis that the user assumes all responsibility for any loss, damage or
consequence resulting directly or indirectly from use.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
