[logback-dev] The encoder branch merged with master

[Joern Huxhorn]

Hm, Lilith couldn't handle this at the moment and it would be pretty  
hard to implement it, too.

There would be a rather big magic value instead of the amount of bytes  
the next event consists of.

That magic value is actually written by a FileHeaderStrategy  
implementation, DefaultFileHeaderStrategy. Due to that separation, my  
FileBuffer has no idea what a header might look like, making it more  
or less impossible to support an additional file header between two  
events.

Wouldn't it be possible to add something like
boolean isFresh or
boolean writeHeader
as an argument for the init method?

This could be used to determine if a file header should be written or  
not.
In case of an empty file, init would be called with that argument set  
to true, meaning that init should write a file-header. Otherwise it  
would simply init the required stream and wouldn't write anything into  
it.

Beside me needing this desperately, I think it makes sense in a  
general way.

Rgards, Joern.

On 02.03.2010, at 15:55, Ceki Gülcü wrote:

>
> My initial reaction is to let the encoder/decoder deal with this  
> issue. Since the encoder can always write its header when its init()  
> method is called, the decoder should check for file headers when it  
> is reading in the stream.
>
> On 02/03/2010 2:26 PM, Joern Huxhorn wrote:
>> Hi Ceki,
>>
>> did you have the chance to think about a solution concerning the
>> remaining issue of http://jira.qos.ch/browse/LBCORE-128 - namely the
>> missing info about whether the stream is a fresh one or one that is
>> appending to an already existing one?
>>
>> Regards & Thanks,
>> Joern.
>>
>> On 02.03.2010, at 13:12, Ceki Gülcü wrote:
>>
>>> Hello,
>>>
>>>
>>> This is to inform you that I have merge the encoder branch into the
>>> master branch. I am still documenting the changes. In short,
>>> WriterAppeder has been renamed as OutputStreamAppender, FileAppender
>>> now sub-classing the latter. OutputStreamAppender and sub-classes  
>>> now
>>> take an Encoder instead of a Layout.
>>>
>>> Contrary to Layouts which simply transform a logging event into a
>>> String, an encoder is responsible for writing the actual event or  
>>> more
>>> accurately the representation of the event into the output stream.  
>>> The
>>> role of the enclosing appender now only manages the output stream
>>> (opening/closing) but not the actual contents written onto the  
>>> stream.
>>>
>>> --
>>> Ceki
> _______________________________________________
> logback-dev mailing list
> logback-dev at qos.ch
> http://qos.ch/mailman/listinfo/logback-dev