[logback-dev] While you are working on FileAppenders... was: Question about a custom binary file appender.
jhuxhorn at googlemail.com
Sun Aug 2 19:41:05 CEST 2009
First of all, sorry that I didn't reply earlier. I was pretty occupied.
I'm fine with Maartens Encoder suggestion.
I've done something similar in a different way, see http://sulky.huxhorn.de/projects/de.huxhorn.sulky.codec/apidocs/index.html
mainly because I need the amount of bytes before actually writing them
but I could easily encapsulate my Encoder in the above interface.
I'm creating a byte because one entry consists of <Length of byte
array as int><actual bytes>. This has the downside that it occupies
more memory but can't be circumvented in my case.
I'd need the ability to write a header followed by an arbitrary number
of the above structure, one for each event.
I'm not sure how header (needed) or footers (not needed in my case,
and arguably a bit dangerous) would be implemented, yet.
Thanks for the discussion!
On 02.08.2009, at 17:59, Ceki Gulcu wrote:
> Maarten Bosteels wrote:
>> I guess you forgot to rename the interface itself ;-)
> Yes, I did. :-)
>> 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
> If there is an established terminology for instance in Mina, than that
> should be taken into consideration. However, being unfamiliar with
> Mina, I was a little surprised by the use of the term Encoder.
>> 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 ?
> If you can somehow reasonably express it in XML format, Joran can
> parse it, at least that's my experience so far. So, I would not worry
> about the parsing part and would concentrate on the "programmatic"
> Ceki Gülcü
> Logback: The reliable, generic, fast and flexible logging framework
> for Java.
> logback-dev mailing list
> logback-dev at qos.ch
More information about the logback-dev