[logback-dev] The encoder branch merged with master

[Ceki Gülcü]

Hello Joern,

You check whether a file is new within the call to your encoders init methsod. 
Here is an example:

class MyEncoder implements Encoder {

  void init(OutputStream os) throws IOException {

     // this should be always true
     if(os instanceof ResilientFileOutputStream) {
       ResilientFileOutputStream rfos = (ResilientFileOutputStream ) os;
       File file = rfos.getFile();
       if (file.size() == 0) {
         // write header
       }
     }
    ...
   }
}

HTH,

On 02/03/2010 6:06 PM, Joern Huxhorn wrote:
> 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