I found the built-in java.util.logging to be adequate insofar as logging went. I'd like the following pieces to go into the log:

* xmlrpc server start/stop timestamp
* client IP making a request + datetime + PID of the java process
* name of the handler & parm list

It's that last item that's proving the most difficult. It looks like I need to tweak XmlRpcRequestProcessor.java to bring in my Logger object and redirect the debugging messages in it to my logfile. The problem is that it's tightly wedded to the package.

Whether I use java.util.logging or the commons logger, am I just going to have to rebuild essentially the whole package? Thanks.

-Paul Bramscher

Henri Gomez wrote:

You're not using commons-loggin-api wrapper ?

2006/2/14, Paul Bramscher <[EMAIL PROTECTED]>:
Greetings--

I've created a couple new singleton pattern objects:

XmlRPCLogger.java (using java.util.logging).
XmlRPCConf.java (uses java.util.proprerties to read vars out of a conf
file).

The conf file is named xmlrpc.conf and contains port number, log file
name, and whether the logging should be turned on or not (boolean).

The logging feature required a couple changes to WebServer.java
* Need to fetch the IP address of the client making the request, and
write this to the log file.
* Needed to also create a constructor, dealing with the port number/etc.
indicated in the conf file.

The logfile writes a message in this format:
2006-02-09T14:49:44-06:00 laotzu [10421]: INFO accepted client request
from 127.0.0.1

I find this format useful:
time in ISO8601 | servername | java PID | logger severity | message | IP.

Now for my question!

I want more data to go into the logs.  Using my XmlRPCLogger singleton,
if logging is set to "true", then I want to set xmlrpcdebug to true
also.  No problem.

The problem is that I want to redirect the system.out's to my logger
file, and these are scattered throughout the project package in various
classes.  Do I need to rip apart the entire package, replace and
rebuild, or does someone have a better idea?  Thanks!

Paul Bramscher
[EMAIL PROTECTED]





.


Reply via email to