Re: Log4J - Downsides?

[Curt Smith <chsmith@speakeasy.net>]

Log4j works great, has lots of appeners for interfacing TCP, mail,

files JMS etc.

As with any logging API, you have to be smart about what and how
much you log.


> However, has anyone seen any problems using this API?
> Things like performance issues, security...


Your best practice should include the skip logic if logging is
not enabled:

if (log.isDebugEnabled())
	log.debug( ... expensive stuff and lots of String objs ... );

Std practice should also include all state variables and context info
needed to debug the problem.  I require that all classes over ride the
toString() and provide a pretty print dump of internal state.


> 
> This will used with servlets, and other backend code, running on JRun 2.3.2
> 


It's no problem, works great.  Your log4j.lcf [config] file should create
at least one log file in a standard place.  Preferably a log file per
sub-system etc.  Use the rolling log file appender, it's great.

The start of every class starts with:

     // Std logging string  === DON'T FORGET TO EDIT THE CLASS BELOW WHEN COPYING THIS CLASS
     //                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

     protected static String     PKGNAME = OffenderDAOImpl.class.getName();
     protected static Category   log     = Category.getInstance(PKGNAME);

     public static final String _cc_gdc_VersionHeader = "$Header$";

... Then in logs:

     log.debug (PKGNAME + ".yourMethodName(): start, args="+ ...);


> 
> My company is open-source unfriendly to start with, so it will be an 
> uphill fight..


Ask your decission makers if they've ever heard of a few market leading
products like [Apache (picked up as their own HTTPD; IBM, Oracle etc),
Linux (factually the most reliable OS on the planet),
X11 (_the_ Unix GUI API),  Samba (best MS file share accessor around),
Jakarta/Xcerses XML APIs etc ......

:)

curt

Curt Smith
chsmith@speakeasy.net
(w) 404-463-0973
(h) 404-294-6686