> My scenario demands a clear demarcation of log files for > different services > and these services may be provisioned at run-time. This calls > for creating > "loggers" and a default file appender with a defaul log level > and ideally > would prefer the newly created properties to be persisted > back into the > configuration file. So the next time the admin has a chance > to modify the > properties file in which case that would be taken into > effect. Its mostly a > convenience feature to "generate" properties from default when needed. > > I managed to implement the first requirement as well but did > it in a hurry > and had to carefully loop through appenders,etc and was > wondering if this > has ever been investigated or already implemented??
I am not aware of it. If you would like to submit your code as an example, I am sure others would be interested. Might lead to some useful support classes. > Another requirement was to be able to trace the method call > and stick it in > the log message automatically which I managed to implement using > Throwable.printStackTrace and sub-classing Logger Why did you not use the LocationInfo feature already implemented in the LoggingEvent? This will generate a stack trace for the location the log message was called from. We are working on some filters that will make it possible to more accurately choose when this information is generated (because it can be a performance hit to generate it for all events). > the log4J index page states : "...strongly discourage casual > users from > sub-classing Logger/Category". May I ask why? and what are > the implications? > Is my case an exception or is there a better way to do it? Ceki can probably answer that better than me. -Mark -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
