[ http://issues.apache.org/jira/browse/LOG4NET-3?page=comments#action_62552 ] Nicko Cadell commented on LOG4NET-3: ------------------------------------
This issue is really about a single application instance logging separate files for each user. For example, an authenticated web service knows the identity of the calling user, actions performed by the service on behalf of the use could be logged into separate files for each user. There are two ways to achieve this. Firstly to evaluate the file name on a per event basis and open the appropriate file per event. This can be optimised by only closing and reopening the file if the name changes from one event to the next. This still could cause quite a large overhead. This is technically possible using the FileAppender's pluggable locking model objects, however this would 'confuse' the appender with respect to headers and footers. Secondly to create a FileAppender for each output file, these appenders are held open behind a router appender that selects the appropriate appender to write to. If no appropriate appender currently exists then one is created. This requires a second level of templating and the ability to parse a fragment of XML config. This has been implemented in log4j 1.3. > Support per event patterns in FileAppender File name > ---------------------------------------------------- > > Key: LOG4NET-3 > URL: http://issues.apache.org/jira/browse/LOG4NET-3 > Project: Log4net > Type: Improvement > Components: Appenders > Versions: 1.2.9 > Environment: From sourceforge: 812999 > Reporter: Nicko Cadell > > If I could specify file name patter for > (Rolling)FileAppender that would be filled by the > appender prior to openning the file, I could let many > individuals run the same applikation (on terminal > server) and still log to file (not RemotingAppender or > ADONetAppernder) > I guess, pattern like "rootLog%U.log" would do, if > appender replaced %U with > Thread.CurrentThread.CurrentPrincipal.Identity.Name ... > Or %T with thread id and so on... > Anonymous -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
