Hi Julius,
My 2cents from mostly a "let's help the support staff" view:
-The Wabbit
>> Greppable Logs
>> [+ Separate files of different areas of interest]
To me this eliminates a whole world of log diagnostic tools.
Limiting support tools to 'grep' makes sense of very controlled
applications on dedicated hardware/systems. If however, your
company invests $$$ into additional logging tools, application
developers should ensure their logs can feed into these systems
as well. (If your application is one of many that interact in
a long-lived or distributed transaction for instance, support
needs to walk the transaction through other applications not
just yours even if they're all housed on the system back-end.)
Having said that...I agree with the premise that log statements
meant for support should have a planned consistent pattern to
them if possible.
>> Always log to a local disk.
>> [+ Separate files of different areas of interest]
I think you're assuming a single use for log4j. Example:
I've used log4j as the foundation of a usage tracking system that
has worked perfectly in a cross-machine/cross-location/clustered
web services deployment. Using a disk-based sink would have been
a pretty bad idea (speed/sync aside, the cost of the (SAN)disk
and other HA/DR requirements far exceeded the code of additional
db storage). I find local-disk a good sink for "turn everything
on modes" but by no means a best-choice for all kinds of logging.
>> Timestamps
I actually disagree with the timezone customization option. I
think logs should be normalized and the UI viewers can be
adjusted by the human wherever he/she is located to display the
local times. I suppose like the 'greppable' logs, it's a matter
of complexity of the application(s) and tools available to
the support staff.
>> Use Log4j 1.2.x (or a competitor)
You're missing slf4j+friends here....some interesting bits wrt
eliminating the horrid: "if (isDebugEnabled(...)) { ... }" crud.
Also the ability to dynamically create filters. Now *that's*
interesting.
>> Programming with log4j
>> Every class must contain this line:
>> private static Logger log = Logger.getLogger( MyClass.class )
Oh lord, please no! Why would I have a Logger in my exception
classes? Put loggers where they're explicitly used and no place
else. You can't magically start using loggers that are declared
but never used (the compilers are probably just stripping these
unused things out anyway...)
>> DO NOT: create a single class "com.foo.app.Log" and run
>> all logging calls through that! You are severely impairing
>> log4j's flexibility if you do that.
This to me is a weird statement. Log4J is a tool that helps you
implement your strategy for logging. If that strategy works with
a single log class so be it. Log4J works with name hierarchies
-- the fact that the original examples used class names to
indicate hierarchy has become this myth of implementation using
log4j. Configuration is linked to the logger/category not the
class; the developer creates that coupling not log4j. Log4J's
own MDC is an example of a logging pattern that is not
hierarchy bound. I also use task-based logging (a logger
that transcends a single class but is linked to a set of classes
-- or instances-- performing a single task) to good effect daily.
>> Logging Exceptions...[sending stacktraces to a separate log]
This might be accomplished more cleanly using a custom
filter and appender that "tees" the exception to an additional
appender...just a thought...no idea how it would work.
>> Cosmetic considerations
You might just try padding the more human-readable level
labels to take up the same (mono)spaces:
'DEBUG', 'INFOM', 'WARNG' 'ERROR' 'FATAL' 'TRACE'
Also just create a custom Level object and use that in your
log4j configuration instead of altering log4j levels directly.
>> A Log Rotation Best Practice That Is Currently Not Possible
I don't see why you cannot do most of this today yourself?
If you can change log4j's level labels, why can't you just on
application startup log some information? Am I missing something
here? If it's a WAR put in a lifecycle listener; if an EAR
put in a bootstrap servlet no? Perhaps you could
extend the current rotating log file appender to do the custom
stamp also?
HTH
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
