[logback-dev] While you are working on FileAppenders... was: Question about a custom binary file appender.

[Ceki Gulcu]

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;
}

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).

This is all I have time for at this moment but I would really like to
pursue this exchange.

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 <ceki at qos.ch 
> <mailto:ceki at qos.ch>> 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 <jhuxhorn at googlemail.com
>             <mailto:jhuxhorn at googlemail.com>
>             <mailto:jhuxhorn at googlemail.com
>             <mailto:jhuxhorn at googlemail.com>>>
> 
>             *Date: *23. April 2009 18:38:38 MESZ
>             *To: *logback developers list <logback-dev at qos.ch
>             <mailto:logback-dev at qos.ch> <mailto:logback-dev at qos.ch
>             <mailto:logback-dev at qos.ch>>>
> 
>             *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
>         logback-dev at qos.ch <mailto:logback-dev at qos.ch>
>         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
>     logback-dev at qos.ch <mailto:logback-dev at qos.ch>
>     http://qos.ch/mailman/listinfo/logback-dev
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> logback-dev mailing list
> logback-dev at qos.ch
> 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