[logback-dev] The encoder branch merged with master

[Joern Huxhorn]

Oh, ok, thanks.

This should work. I'll give it a try this evening.

Thanks,
Joern.

On 03.03.2010, at 09:06, Ceki Gülcü wrote:

>
> 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
> _______________________________________________
> logback-dev mailing list
> logback-dev at qos.ch
> http://qos.ch/mailman/listinfo/logback-dev