First question, did you tick the "Ok to remove SecurityManager" in the application preferences? If this is not ticked, particularly with the Webstart version it's impossible load stuff from the plugins directory. By ticking this box, you turn off the SecurityManager, and allow a TCL to be created, which knows how to load classes from the .plugins area.

Having said that, it's possible that the last Webstart build somehow broke VFS compatibility. Scott? If this is the case, I could fast track a new build. Does the same thing happen if you check out log4j- chainsaw SVN project and run it via 'ant chainsaw' ?

cheers,

Paul

On 09/12/2005, at 5:37 PM, Jacob Kjome wrote:


I feel like I should know this, but having never actually trying the VFSLogFilePatternReceiver before and trying to set it up now, I realize that I don't. Here's what I've done....

1.  Installed latest Webstart version of Chainsaw
2.  Created $user.home/.chainsaw/plugins directory
3. Added commons-vfs-1.0-RC7.jar and *all* mandatory + optional dependencies to the plugins directory. See...
http://people.apache.org/~imario/vfs/
http://people.apache.org/~imario/vfs-1.0-RC7/site/download.html

4. Launched chainsaw and looked at the log. Chainsaw reports nothing about loading the VFSLogFilePatternReceiver, but does report finding other receivers, including... "Located known Receiver class org.apache.log4j.varia.LogFilePatternReceiver"

VFSLogFilePatternReceiver comes with Chainsaw, no? It seems to be in the chainsaw jar in the downloadable chainsaw package. Why doesn't it exist for WebStart with all the necessary VFS dependencies available in the plugins directory?

BTW, where do we load a plugin config file? Can it only be loaded upon startup, defined in the global options? The "load file" options under the "file" menu only seem to apply to log files in XML format, not plugin config files. If it is possible to dynamically create receivers using the Chainsaw Receiver panel, why can't I dynamically create them by loading a plugin config file at runtime? I must be missing something.

Also, is there anything that can be done about "logFormat" recognition for the FilePatternReceiver in the case where the log file contains heterogeneous patterns? For instance, under Tomcat, I've got Log4j in common/lib and have defined a Console appender for the default logger repository. I'm using the NT Service for Tomcat (on WinXP) which captures System.out and logs it to file, for which the service (or Tomcat) controls the rolling. Then, in my webapps, I use a console appender for certain logging which also ends up in that file. The patterns that the server use can be different than that of the webapps resulting in more than one pattern in the log file. Not only that, but there might be certain cases where code literally uses System.out (bad code!) and there is no real pattern. Might Chainsaw be enhanced to deal with this by using multiple patterns? I'm not sure it's possible, but it would be nice if it were.

Anyway, I've rambled enough.

thanks,

Jake


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to