The Artima Developer Community
Sponsored Link

Weblogs Forum
Logging configuration using Jini

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Logging configuration using Jini (View in Weblogs)
Posted: Dec 30, 2004 11:02 AM
Reply to this message Reply
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.

Topic: Web Services vs Jini Previous Topic   Next Topic Topic: Heron.NET or JHeron?


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us