[Helma-user] log4j

[Michael Platzer]

hi,
> i'm using log4j together with chainsaw for development for a long time 
> now (using a config similar to [1]), and i don't want to miss it. mainly 
> because i can view all helma log messages (plus those of 
> helmagroups/javagroups which we're using for several apps) in one 
> logviewer application, and filter the messages in chainsaw as i want (no 
> need for tail -f | grep anymore). and i don't have any logfiles on disk 
> anymore.
>   
very interesting. thanks.
hannes and stefan, are you still using log4j ( 
http://www.henso.com/log/2005.11.15/1069/ )?
> yes, that's the major drawback - you would need to create a separate log 
> appenders for every access/event/sql logfile of every application (in 
> our only deployment setup utilizing log4j we're using generic 
> access/event/sql appenders which are used by all applications). plus 
> changing the log4j config doesn't have any effect during runtime, so you 
> have to restart helma (at least i never was able to find a way to 
> circumvent that). which imho makes it a no-go for helma deployment 
> setups that change frequently.
>   
i guess, i could live with a single log-file, since the following two 
statements are not much different anyways:
  tail -f log/helma.appname.event.log
  tail -f log/helma.log | grep appname.event

but no reloading seems to be a real blocker, since i would then never be 
able to trace down a bug on a live-system without restarting the server 
twice (once enabling debug-mode, and once for disabling it).
I took a quick look on the implementation, and tried to find out whether 
there is a quick way to fix it, but didn't come up with a solution.
commons-logging initiates log4j and the method 
OptionConverter.selectAndConfigure is called within that process, which 
subsequently calls configurator.doConfigure (either on a 
PropertyConfigurator or on a DOMConfigurator).
there is the method configureAndWatch [1] which loads a configuration, 
and then watches that particular file for changes. but i guess we would 
need to change Helma to call this method directly.
>> * I would like to use distinct log4j.xml files for each application, and 
>> not have to share one global log4j.xml for the whole Helma installation. 
>> Possible?
>>     
> afaik not.
>   
in Tomcat this seems to be possible [2].

regards,
  michi

p.s. we could consider upgrading commons-logging to 1.1 [3]. It claims 
to be 100% backwards compatible, and fixes a couple of bugs when 
commons-logging is contained multiple times in the classpath.

[1] 
http://logging.apache.org/log4j/docs/api/org/apache/log4j/xml/DOMConfigurator.html#configureAndWatch(java.lang.String,%20long)
[2] http://logging.apache.org/log4j/docs/manual.html  Section: "Default 
Initialization under Tomcat"
[3] http://jakarta.apache.org/commons/logging/RELEASE-NOTES.txt