Summary
The LogManager implementation in J2SE has some issues with dynamic logging configuration. I've implemented a Jini service that provides remote configuration control plus some other capabilities.
Advertisement
A Jini enabled LogManager for remote access
The logman project at logman.jini.org
was created to provide the ability to remotely set the log levels in the JVM. The webpage details most of the important things about using this stuff,
so I won't recreate that information here.
Which Logger Instances Can I Turn Up?
One of the more interesting things about this LogManager service
is that it provides access to the list of registered Logger instances
so that you can see all of the Logger instances active in the JVM. This can make
it quicker to see what is happening in parts of the software.
Logger Profiles
The LogManager service also provides the ability to configure up front, and later add
and/or alter sets of Logger profiles. These profiles let you predefine certain Logger instances and associated LogLevel settings in groups. These groups can be named and
you can thus select one of these profiles dynamically to get insight into particular
behaviors. It has caused me to start being finer grained about my Logger instance
definitions so that I can more exactly control what I see in the logs.
Remote Handler Access
One of the things that I did not provide is the ability to register a remote
java.util.logging.Handler implementation. I've thought about doing this,
but I am still thinking about the details. A simple thing to do would be to add
a method such as
public InputStream listenToLogger( String loggerName ) throws IOException;
This method could be implemented in a smart proxy style where it actually used an
internal method that talked to the remote service, and got back a socket address
to connect to. It could then return the Socket.getInputStream() value and let the
remote application listen to a logging stream that is fully formatted.
The reason to do it this way is because LogRecord is not serialization safe. It
has two methods which take parameters which do not have to be Serializable, namely
the setParameters(Object[]) method and the
setThrown(Throwable) method.
The problem with this is that the remote formatting may not be what the local client would like to see, or needs.
So, the next thought would be to add a java.util.logging.Formatter to
the parameter list of our method so that it would be:
public InputStream listenToLogger( String loggerName,
Formatter fmtr ) throws IOException;
But, since this is not already a Serializable class, it might not be safe to subclass
it and declare the subclass as Serializable.
So, I am trying to think through this to decide on a useful implementation of remote
logging access that will provide the remote user some benefitial formmating control.
More Thoughts
As I think about this more, it seems like a factory pattern is probably the best bet.
I could have an interface such as the following.
public interface FormatterFactory extends java.io.Serializable {
public Formatter getFormatter();
}
I could then add a method such as the following to my service definition.
public InputStream listenToLogger( String loggerName,
FormatterFactory fact ) throws IOException;
This would provide a good definition of the needed behaviors and allow
for the fact that the Formatter might not be Serializable. Instead, the codebase for the client would need to include the FormatterFactory and its returned Formatter so that it could be instantiated on the server and operate there.
Previous Topic
