On Sat, Aug 1, 2009 at 8:33 PM, Ceki Gulcu <[email protected]> wrote: > > Thank you for reminding us about the prototype. I find it very > informative and helpful. > > As I see things, the Encoder interface and the various implementations > you have written show that it is not sufficient to return a byte array > for a given ILoggingEvent, the "encoder" also needs to know how to > write to the underlying OutputStream, it may also need to decorate the > underlying OutputStream with its own (e.g. ObjectOutputStream for > serialization). > > Consequently, I'd propose to rename the Encoder interface as > ILoggingEventWriter. (In my mind at least, an Encoder is associated with > transforming data into bytes.) > > So here is my revised interface: > > public interface Encoder <T extends OutputStream> { > void write(ILoggingEvent event, T output) throws IOException; > T decorate(OutputStream os) throws IOException; > }
I guess you forgot to rename the interface itself ;-) >From http://en.wikipedia.org/wiki/Encoder "An encoder is a device, circuit, transducer, software program, algorithm or person that converts information from one format, or code to another..." So I think calling it Encoder is appropriate, but I have no string feeling about the name of the interface. The terminology also used in MINA: http://mina.apache.org/report/trunk/apidocs/org/apache/mina/filter/codec/ProtocolEncoder.html > > What should be done about methods such as getFileHeader(), > getFileFooter(), getPresentationHeader() and getPresentationFooter() > from the Layout interface? My first reaction would be to rename getX() > as writeX(OutputStream). Sounds OK to me. > > > This is all I have time for at this moment but I would really like to > pursue this exchange. That's cool ! I have no idea how much work it is to support encoders in the logback.xml file. I mean, we should be able to tell logback to use a XXXAppender with a ZZZEncoder ? Regards Maarten > > > Cheers, > > Maarten Bosteels wrote: > >> Hi Ceki and Joern, >> >> Remember the Encoder interface we discussed in the past ? >> To make the aspect of encoding a LoggingEvent pluggable, and thus the >> Appender implementation more reusable. >> >> I have small prototype here : >> http://tinyurl.com/encoder-interface >> http://tinyurl.com/encoder-example >> >> regards, >> Maarten >> >> On Fri, Jul 31, 2009 at 5:51 PM, Ceki Gulcu <[email protected] <mailto: >> [email protected]>> wrote: >> >> >> Hi Joern, >> >> Plese enter a bug report with as much information as you can about the >> code you'd like to see changed. In principle, very little code is >> involved in actually writing to the file so the task would seem rather >> easy. However, WriterAppender on which FileAppender and >> RollingFileAppender are built upon uses a Writer to write whatever it >> is that needs to be written. Unfortunately, a Writer knows how to >> writes String or chars, but not bytes. >> >> Nevertheless, I think it's feasible with some work... >> >> Joern Huxhorn wrote: >> >> Hi Ceki. >> >> I've seen that you are working on the FileAppenders again. Have >> you seen this mail I wrote? What do you think about it? >> >> Joern. >> >> Begin forwarded message: >> >> *From: *Joern Huxhorn <[email protected] >> <mailto:[email protected]> >> <mailto:[email protected] >> <mailto:[email protected]>>> >> >> *Date: *23. April 2009 18:38:38 MESZ >> *To: *logback developers list <[email protected] >> <mailto:[email protected]> <mailto:[email protected] >> <mailto:[email protected]>>> >> >> *Subject: **Question about a custom binary file appender.* >> >> Hi Ceki. >> >> I'd like to implement a file appender that writes the binary >> Lilith >> format, i.e. gzipped protobuf-serialized events, instead of >> Strings. >> I'd also like to have the same functionality that's supported >> by >> RollingFileAppender right now. >> >> Unfortunately, there seems to be no way to simply write >> bytes instead of >> a String. How would you go from here? >> Reimplementing everything from the start seems to be a >> pretty bad idea. >> >> What do you think about enhancing the RFA so it's using >> byte[] instead >> of Strings? The current behavior could be implemented using >> those >> methods + string.getBytes("UTF-8") or CharsetEncoder... >> >> Any idea, suggestions? >> >> Regards, >> Joern. >> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> logback-dev mailing list >> [email protected] <mailto:[email protected]> >> http://qos.ch/mailman/listinfo/logback-dev >> >> >> -- Ceki Gülcü >> Logback: The reliable, generic, fast and flexible logging framework >> for Java. >> http://logback.qos.ch >> _______________________________________________ >> logback-dev mailing list >> [email protected] <mailto:[email protected]> >> http://qos.ch/mailman/listinfo/logback-dev >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> logback-dev mailing list >> [email protected] >> http://qos.ch/mailman/listinfo/logback-dev >> > > -- > Ceki Gülcü > Logback: The reliable, generic, fast and flexible logging framework for > Java. > http://logback.qos.ch > _______________________________________________ > logback-dev mailing list > [email protected] > http://qos.ch/mailman/listinfo/logback-dev >
_______________________________________________ logback-dev mailing list [email protected] http://qos.ch/mailman/listinfo/logback-dev
