The encoder branch merged with master
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
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@qos.ch http://qos.ch/mailman/listinfo/logback-dev
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
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@qos.ch http://qos.ch/mailman/listinfo/logback-dev
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
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@qos.ch http://qos.ch/mailman/listinfo/logback-dev
participants (2)
-
Ceki Gülcü -
Joern Huxhorn