custom hierarchy reconfiguration

["Johnson, Clay" <cl...@vignette.com>]

Sorry for the length of this post, but I didn't want to leave out any
details that may be important to the case.

Reference previous topic, cached category coherency, I concluded the
apparent caching was due to my wrapper class.  While that still may be the
case, it is not clear why.

After further investigation, it seems that it may be related to my (mis?)use
of a custom hierarchy.  I extended my test case to include both a default
and a custom hierarchy configured from the same xml file.  This occurs in a
management class like this:

import org.apache.log4j.*;
import org.apache.log4j.spi.*;
import org.apache.log4j.xml.*;

public class LoggingManager
{
	private static Hierarchy hierarchy = 
		new Hierarchy(new
RootCategory(org.apache.log4j.Priority.DEBUG));

	public static org.apache.log4j.Category getRoot()
	{
		return hierarchy.getRoot();
	}

	public static org.apache.log4j.Category getInstance(String name)
	{
		return hierarchy.getInstance(name);
	}

	public static void config(String filename) 
	{
		try {
			// configure default hierarchy
			DOMConfigurator.configure(filename);
			DOMConfigurator d = new DOMConfigurator();
			// configure custom hierarchy
			d.doConfigure(filename, hierarchy);
			configTime = System.currentTimeMillis();
 		} catch (Exception e) {
		 	System.out.println("Exception: " + e);
		}
	}
}

The getRoot and getInstance methods are intended to expose the corresponding
methods of the private custom hierarchy.

Then in the client, I deliberately instantiated the same Category name from
both the default hierarchy and the custom hierachy, via those exposed
methods:

public class ClientTest 
{
	// from custom hierarchy
	private static Category cat = 
		LoggingManager.getInstance(ClientTest.class.getName());

	// from default hierarchy
	private static Category defcat = 
		Category.getInstance(ClientTest.class.getName());
	...
}

What I observe is that, upon reconfiguration, the category instance from the
defaultHierarchy automatically reconfigures, but the one from the custom
hierarchy doesn't.  Rather, it acts as though it is cached; if I explicitly
re-evaluate it by calling the LoggingManager getInstance again, then it is
refreshed to the new configuration.

I'm digging through Category and Hierarchy source (v1.1b1), and so far I
can't find any difference with custom hierarchies that would explain this.
So, like I said at the beginning, the error may be in my wrapping
(LoggingManager), but I don't see it.

Any ideas?

Thanks,
Clay




---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org