DO NOT REPLY [Bug 20500] New: - PropertyConfigurator's Appender Configuration not extensible

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20500>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20500

PropertyConfigurator's Appender Configuration not extensible

           Summary: PropertyConfigurator's Appender Configuration not
                    extensible
           Product: Log4j
           Version: 1.2
          Platform: All
        OS/Version: Other
            Status: NEW
          Severity: Critical
          Priority: Other
         Component: Configurator
        AssignedTo: log4j-dev@jakarta.apache.org
        ReportedBy: brody@gebit.de


The default org.apache.log4j.PropertyConfigurator does not support filters for 
the appenders, although filter support (using a filter chain) is integrated in 
the base class of all Appenders (AppenderSkeleton).
To integrate this needed feature there, I thought about to derive a 
PropertyConfigurator from the log4j base class, which I must do also, to 
integrate additional components and its configuration by a properties file.

I discovered, that the basic log4j configuration part can be done by the 
original PropertyConfigurator. One part of this basic configuration is the 
configuration of the Appenders (except the Filters), so I though about to put 
this additional step into my own PropertyConfigurator after determining, that 
all appenders get saved into a registry - testing this (by an overloaded 
doConfigure() method) as follows:

public void doConfigure(Properties properties,LoggerRepository hierarchy) {
		configureReaderRoot(properties);
		super.doConfigure(properties, hierarchy);
                configureAppenderFilter(properties);
	}

showed me, that the registry object, which is PROTECTED and therefor visible 
for a derived PropertyConfigurator class, is always empty after returning from 
super.doConfigure().
That is my problem and the problem can be found in line 411ff. of the log4j 
PropertyConfigurator class:
    // We don't want to hold references to appenders preventing their
    // garbage collection.
    registry.clear();

I think, there are two possible solutions (which must be done inside log4j, 
there are no workarounds I know):
(1) delete the above mentioned lines and give an official access to the that 
principle useful functionallity, which can be called from outside.
(2) split the doConfigure() method, so additional work can be done before the 
registry gets cleared.

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