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: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
