Hello Paul.
Thanks for your answers. I'm glad to see, that the concept of storing LoggingEvents is not too uncommon. However, the two implementations you found are neither documented in the API docs on the website, nor are they contained in the distribution jars. (At least they are not in the log4j jars I have around, but probably those are just not recent enough.) Also, they are a little bit less generic, then my proposed ListAppender.
But the existence of those similar Appenders shows, that the concept is commonly used. Therefore, I would suggest, to consider including a generic ListAppender into the log4j core. It could either be derived from my proposed version or refactored from one of the existing Adapters mentioned below.
Paul Smith wrote:
I think I already have just such an appender within the Chainsaw package. I might refactor it out into the main log4j core too. The appender implementation exposes a ListModel of it's events it is given.
You can see it here:
http://cvs.apache.org/viewcvs.cgi/logging-log4j/src/java/org/apach e/log4j/chainsaw/messages/MessageCenterAppender.java?view=markup
The semantics of that MessageCenterAppender seem to by quite the same as those of my ListAppender. But even though the ListModel interface seems very light-weight, I think the List interface from the collections framework is preferable for general use.
Paul Smith wrote:
There is also the org.apache.log4j.VectorAppender which is already there (I think it was mainly used for test case purposes, but it's still useful).
That one also seems very similar to my proposal. But aditionally, it offers support for delays, which is probably only usefull for testing purposes. Here is how it could be refactored to make use of the ListAppender:
// imports and package declaration omitted
public class VectorAppender extends ListAppender {long delay = 0;
public VectorAppender() {
super(new Vector());
} public void append(LoggingEvent event) {
if(delay > 0) {
try {
Thread.sleep(delay);
} catch (Exception e) {
}
}
super.append(event);
} public Vector getVector() {
return (Vector) getLoggedEvents();
}// getter and setter for delay omitted }
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Saturday, October 16, 2004 6:32 AM To: [EMAIL PROTECTED] Subject: Yet another Apender proposal: ListAppender
Hello folks!
Probably this is getting too frequent now, but I'd like to propose a new Appender, too. I guess it is not so sophisticated and usefull as the MultiplexAppender proposed recently, but therefore it is small and simple. It's only one class, so I've simply attached it to this mail. The Javadoc coments are rather low quality, but they should give a good idea about how it works.
My motivation was, to store some LoggingEvents in my application, so that they could be presented in its GUI later. In particular, was writing some complex import filter, and was logging all import steps with Log4j. But I also wanted to give the user some direct feedback about the progress. Instead of accumulating messages for the GUI seperately, I decided to use the existing Log4j infrastructure for this. This would reduce the additional logging code in the import.
However the GUI is asynchronous to the import, so I needed to store the LoggingEvents somewhere, and retrive them, whenever they should be rendered. Of course, I could have used some Appender writing to a file, and parse that file to display the events. But in fact the GUI didn't need to make the events persistent, it just needed them in memory. So I wrote that simple ListAppender, which buffers the LoggingEvents in a List. The application using this Appender has full control of the List, and can retrive or modify the stored LoggingEvent whenever it wants.
I could't find any similar Appender in the Log4j API docs. So either you're in need of it, or it is completely unusefull for anyone else. Please have a look at it, and decide yourself. If you think any of the code could be usefull for Log4j, please feel free to use it.
Regards, Michael
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
