Hi Paul,
Sorry it took so long to respond. Given the 1.2.9 situation I don't have the time to look into MultiplexAppender. However, I'll do so after 1.2.9 is released.
Nevertheless, from a cursory look I can say that given the number of appenders in log4j, it looks unrealistic to have as many appender factory classes as there are appender types. Moreover, dealing in a one-to-one basis with the combinations of the different appenders and their options would very quickly become intractable.
JoranConfigurator, as do the other Configurators, have the ability to manufacture appeders on demand. In other words, your idea of appenderFactory is already incorporated in the existing implementations of the Configrator. Perhaps there is no need to reeinvent the wheel?
The gist of my suggestion would be to use Joran to fabricate appender instances as demanded by the multiplex selector.
There are two important enhancements in 1.3 that you should consider.
First, the JoranConfigurator can be fed a property list, much like Ant can. Joran will perform variable substitution accordingly. Log4j 1.2 Configurators have a similar capability, but support in Joran is much more complete.
So, imagine the following config file:
<log4j:configuration debug="true">
<appender-template name="DB" appender-name="DB-${User}"
class="org.apache.log4j.rolling.RollingFileAppender">
<param name="Append" value="false" /><rollingPolicy class="org.apache.log4j.rolling.SlidingWindowRollingPolicy">
<param name="activeFileName" value="output/parser3-${User}"/>
<param name="fileNamePattern" value="output/parser3-${User}.%i"/>
</rollingPolicy>
<triggeringPolicy class="org.apache.log4j.rolling.SizeBasedTriggeringPolicy">
<param name="maxFileSize" value="10MB"/>
</triggeringPolicy>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%-5p %c{2} - %m%n"/>
</layout>
</appender-template><appender name="Multiplex" class="org.apache.log4j.multiplex.MultiplexAppender">
<selector class="org.apache.log4j.multiplex.MDCKeySelector" >
<param name="mdcKey" value="User" />
<appender-template-ref ref="DB"/>
</selector>
</appender>
<root> <level value ="debug"/> <appender-ref ref="Multiplex" /> </root> </log4j:configuration>
The main idea is to have the MultiplexAppender named "Multiplex" and its MDCKeySelector to create new Joran instances (with restricted parsing rules) which parse the <appender-template> element to create new RollingFileAppender instances as new users are encountered. Note that the ${User} parameter would be set by MDCKeySelector and Joran would perform the appropriate variable substitution so that the newly RollingFileAppender would append to a file specific to the user.
Finer details:
1) We don't want a run a full JoranConfigurator each time a new user-specific appender is created. In other words, we do not want to have a the whole configuration file to be parsed, but only the section within the <appender-template> element.
2) The freshly created appender can be accessed from the objectStack of the executionContext (of the Joran Interpreter).
See Interpreter.getExecutionContext();
ExecutionContext.getObjectStact();3) If there are more than one appender-templates, the interpreter should be instructed to process only the appender-template with the appropriate name, e.g. "DB" and ignore the other templates.
I'll stop here to allow you to digest what has been said so far.
Does any of the above make sense?
At 01:42 AM 10/18/2004, Paul Smith wrote:
Hi all,
I have committed an early look at my efforts with MultiplexAppender. Yes it is pretty raw at this stage.
My stumbling block is currently Joran related (I think), so this might be Ceki's domain.
My question here relates to the tests/input/multiplex/configTest-1.xml file which is now in CVS. It's not complete, but there for this discussion.
I started creating a Unit test first to represent the use case of a user who wanted to create the MDC multiplexing Appender using a Time-based rolling file appender. I thought I would try and think like the user first, trying to configure it, and see what implementation changes would be needed.
As you can probably see from this config file it creates the MDCKeySelector and configures it with the MDC key of "User". It then sets the AppenderFactory to use for this MultiplexAppender, and it is here that I am now confused.
I started to think that I would need an AppenderFactory implementation (TimeBasedRollingAppenderFactory in the config, doesn't exist yet, probably won't), but maybe I don't need this, I'm not sure. I couldn't get my mind past the fact that the AppenderFactory only knows about the MDC value at the point of needing to create the appender, so it's not something that can be embedded in the configuration.
Then I started to look at the whole Rolling file name tokeniser stuff. This use-case requires that the User be able to configure the Time-based rolling stuff, as well as embedding a token that represents the MDC key that needs to be on each file. I started thinking that I could use the %i as in:
output/MultiplexAppenderTest-%i.log.%d{yyyy.MM.dd}
to represent the value of the MDC value, but I think it's wrong, and I'm not sure what to do, or how to solve it.
The AppenderFactory needs to take this fileNamePattern and replace a token with the MDC Value, and then create a RollingFileAppender with the newly-replaced pattern (it would look something like 'output/MultiplexAppenderTest-Bob.log.%d{yyyy.MM.dd}').
Anyone got any suggestions?
cheers,
Paul Smith
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Ceki G�lc�
For log4j documentation consider "The complete log4j manual"
http://www.qos.ch/shop/products/eclm/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
