Martin, > In a nutshell, I want to configure two different appenders, let's say a > DB appender and a file appender. One of them would be active by > default, but the user could switch to the other, referring to it by name > as specified in the props, without having to create a new > appender from scratch.
What do you mean by "switch" to the other? Is this to provide some kind of active monitoring option when you want it? If so, you might want to look into using a SocketHubAppender which allows you to "connect" to the logging source and view the logging events. When you are not connected to it, it does not consume much in the way of resources. > Now looking more closely, appenders seem not to be named resources (as > the properties format suggests), but rather one-shot instances. > In fact attaching an existing appender to another Logger > programmatically would be a mistake since detaching that appender from > either > Logger would close it. Cannot argue there. It surprised me when I learned that the appenders have this behavior. I think that at least supporting some kind of reference count would solve this problem. It would allow an individual logger to "drop" an appender but leave the appender active and usable by other referencing loggers. But that is not how it works today. > A more solid architecture would separate the concerns of appender > specification (e.g. through XML or properties), appender instances and > appender resources. What I would be most interested in are named > appender specifications, whether instantiated or not, which I could then > instantiate dynamically and which would share the resource (data sink) > specified with any other existing instances of the specification. I think Ceki is more qualified to speak to this point. However, there is nothing stopping you in the current architecture to using the current appender design as a "front-end" to something more like you are talking about. You could write your own appender classes that use/reuse resources/sinks independent of how they are started/closed with a given logger. If you want to discuss this in more detail, I would be interested in hearing about it. -Mark -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
