I am having a problem because the DefaultCategoryFactory is automatically used to instantiate Categories in the Hierarchy class.  Here is the scenario in which I am having the problem.  My question is 1) is this really a problem... or am I just missing something 2) if it is a problem, is there any work around.

I have subclassed the org.apache.log4j.Category and org.apache.log4j.CategoryFactory classes (for the sake of discussion, I will call them MyCategory and MyCategoryFactory).

For the purposes of my organizations logging needs, we will be using the MyCategoryFactory (and passing it to some variation of the MyCategory.getInstance() method) every time we need to create a Category for logging.  The MyCategoryFactory has additional information that is used to create MyCategory object instances and that is in turn sent to the Appender via a MyLoggingEvent (which is created using the MyCategory forceLog method).  In short, we must have every Category be an instance of MyCategory so that the appropriate information is sent to the Appender(s).  There is one case where this is not possible.

I am using the org.apache.log4j.PropertyConfigurator to configure logging.  When the PropertyConfigurator encounters a category in the configuration file, it creates a Category, which in turn instantiates a Hierarchy object.  Because the constructor of the Hierarchy uses the org.apache.log4j.DefaultCategoryFactory to create a Category, our applications can not use this (i.e. They cannot cast it to MyCategory).  Even if they could, the appropriate information would not be sent to our log files.  Our current work around is to define a category in the configuration file that we know will never be requested from our applications (Example: We configure com.whomever and our applications use com.whomever.applicationName).  Has anyone seen this problem?

The solution I might propose it to allow use of a subclass of DefaultCategoryFactory.  This would however require some way to configure the DefaultCategoryFactory from the log4j configuration file.

Cory Updyke
PartNet, Inc.
cupdyke@part.net