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.

Talk Back!

Have an opinion? Be the first to post a comment about this weblog entry.

RSS Feed

If you'd like to be notified whenever Gregg Wonderly adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Gregg Wonderly graduated from Oklahoma State University in 1988 with an MS in COMSCI. His areas of concentration include Operating Systems and Languages. His first job was at the AT&T Bell Labs facilities in Naperville IL working on software retrofit for the 5ESS switch. He designed a procedure control language in the era of the development of Java with similar motivations that the Oak and then Java language development was driven by. Language design is still at the top of his list, but his focus tends to be on application languges layered on top of programming languages such as Java. Some just consider this API design, but there really is more to it! Gregg now works for Cyte Technologies Inc., where he does software engineering and design related to distributed systems in highly available environments.