You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Gary Gregory <ga...@gmail.com> on 2016/04/12 22:30:09 UTC
Layout extends Encoder
Now that Layout extends Encoder and Encoder is new in 2.6, why not fold
Encoder in Layout?
Doesn't Layout extending a new type (Encoder) break BC anyway?
Gary
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Layout extends Encoder
Posted by Ralph Goers <ra...@dslextreme.com>.
I am not really sure when the data is written. I suppose it could also be named ByteBufferLayout.
Ralph
> On Apr 13, 2016, at 12:33 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> Just by its name, BufferedLayout sounds like a Layout with an internal buffer that is flushed once is a while and on close. Is that what it would be?
>
> G
>
> On Wed, Apr 13, 2016 at 11:42 AM, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
> I guess I do have one issue with Encoder. Logback essentially replaced Layout with Encoder. However, my recollection is that it was done as part of converting to having Layouts write to outputStreams using character encoding. The Encoder interface we have is confusing in that regard as it doesn’t really “encode” anything. In fact, this has me wondering if it wouldn’t make more sense to create a BufferedLayout interface that extends Layout (instead of the inheritance being the other way around). This would not break binary compatibility and the name would make more sense.
>
> Ralph
>
>> On Apr 13, 2016, at 9:36 AM, Remko Popma <remko.popma@gmail.com <ma...@gmail.com>> wrote:
>>
>> One usage is the StringBuilderEncoder class I just committed (it implements Encoder<StringBuilder>).
>>
>> For binary layouts, this still needs more thinking, but log4j could have a registry of custom encoders. Then, when a client logs an Order object we do a lookup, find the Encoder<Order> and use that encoder to write the binary data for the Order into the ByteBufferDestination.
>>
>> On Wed, Apr 13, 2016 at 9:37 PM, Mikael Ståldal <mikael.staldal@magine.com <ma...@magine.com>> wrote:
>> How would such an Encoder look like?
>>
>> On Wed, Apr 13, 2016 at 12:40 AM, Remko Popma <remko.popma@gmail.com <ma...@gmail.com>> wrote:
>> It does break binary compatibility, but since it's log4j-core (not api) we agreed that this is acceptable here.
>>
>> The reason it's a separate super interface is that I plan to have other Encoder implementations (perhaps user-specified) for binary logging.
>>
>> The Jira may have more details: https://issues.apache.org/jira/browse/LOG4J2-1274 <https://issues.apache.org/jira/browse/LOG4J2-1274>
>>
>> Sent from my iPhone
>>
>> On 2016/04/13, at 5:30, Gary Gregory <garydgregory@gmail.com <ma...@gmail.com>> wrote:
>>
>>> Now that Layout extends Encoder and Encoder is new in 2.6, why not fold Encoder in Layout?
>>>
>>> Doesn't Layout extending a new type (Encoder) break BC anyway?
>>>
>>> Gary
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@apache.org>
>>> Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/>
>>> Home: http://garygregory.com/ <http://garygregory.com/>
>>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
>>
>>
>> --
>>
>>
>> Mikael Ståldal
>> Senior software developer
>>
>> Magine TV
>> mikael.staldal@magine.com <ma...@magine.com>
>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com <http://www.magine.com/>
>>
>> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
>> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
>> you should destroy this message and kindly notify the sender by reply email.
>>
>
>
>
>
> --
> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@apache.org>
> Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/>
> Home: http://garygregory.com/ <http://garygregory.com/>
> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
Re: Layout extends Encoder
Posted by Gary Gregory <ga...@gmail.com>.
Just by its name, BufferedLayout sounds like a Layout with an internal
buffer that is flushed once is a while and on close. Is that what it would
be?
G
On Wed, Apr 13, 2016 at 11:42 AM, Ralph Goers <ra...@dslextreme.com>
wrote:
> I guess I do have one issue with Encoder. Logback essentially replaced
> Layout with Encoder. However, my recollection is that it was done as part
> of converting to having Layouts write to outputStreams using character
> encoding. The Encoder interface we have is confusing in that regard as it
> doesn’t really “encode” anything. In fact, this has me wondering if it
> wouldn’t make more sense to create a BufferedLayout interface that extends
> Layout (instead of the inheritance being the other way around). This would
> not break binary compatibility and the name would make more sense.
>
> Ralph
>
> On Apr 13, 2016, at 9:36 AM, Remko Popma <re...@gmail.com> wrote:
>
> One usage is the StringBuilderEncoder class I just committed (it
> implements Encoder<StringBuilder>).
>
> For binary layouts, this still needs more thinking, but log4j could have a
> registry of custom encoders. Then, when a client logs an Order object we do
> a lookup, find the Encoder<Order> and use that encoder to write the binary
> data for the Order into the ByteBufferDestination.
>
> On Wed, Apr 13, 2016 at 9:37 PM, Mikael Ståldal <mikael.staldal@magine.com
> > wrote:
>
>> How would such an Encoder look like?
>>
>> On Wed, Apr 13, 2016 at 12:40 AM, Remko Popma <re...@gmail.com>
>> wrote:
>>
>>> It does break binary compatibility, but since it's log4j-core (not api)
>>> we agreed that this is acceptable here.
>>>
>>> The reason it's a separate super interface is that I plan to have other
>>> Encoder implementations (perhaps user-specified) for binary logging.
>>>
>>> The Jira may have more details:
>>> https://issues.apache.org/jira/browse/LOG4J2-1274
>>>
>>> Sent from my iPhone
>>>
>>> On 2016/04/13, at 5:30, Gary Gregory <ga...@gmail.com> wrote:
>>>
>>> Now that Layout extends Encoder and Encoder is new in 2.6, why not fold
>>> Encoder in Layout?
>>>
>>> Doesn't Layout extending a new type (Encoder) break BC anyway?
>>>
>>> Gary
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> <http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>
>>
>> --
>> [image: MagineTV]
>>
>> *Mikael Ståldal*
>> Senior software developer
>>
>> *Magine TV*
>> mikael.staldal@magine.com
>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>
>> Privileged and/or Confidential Information may be contained in this
>> message. If you are not the addressee indicated in this message
>> (or responsible for delivery of the message to such a person), you may
>> not copy or deliver this message to anyone. In such case,
>> you should destroy this message and kindly notify the sender by reply
>> email.
>>
>
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Layout extends Encoder
Posted by Remko Popma <re...@gmail.com>.
Ralph,
After rereading your email I see I may have missed your point. Layout
deliberately extends Encoder and not the other way around because Layouts
have additional responsibilities like header, footer, content type etc.
Remko
On Thursday, 14 April 2016, Remko Popma <re...@gmail.com> wrote:
> I'm actually quite attached to this name. It took several iterations to
> come up with, I think it's intuitive and descriptive and I'm very happy
> with this name.
>
> I don't see any confusion: Logback's Encoder interface writes the
> resulting bytes to a stream where log4j 2 writes the resulting bytes to a
> nio ByteBuffer.
>
> Their role and responsibility are identical: converting any generic object
> into bytes.
>
> Furthermore this name is in line with naming conventions in the JDK,
> looking at CharEncoder/Decoder for example.
>
> So I'm very reluctant to change this.
>
> Remko
>
> Sent from my iPhone
>
> On 2016/04/14, at 3:42, Ralph Goers <ralph.goers@dslextreme.com
> <javascript:_e(%7B%7D,'cvml','ralph.goers@dslextreme.com');>> wrote:
>
> I guess I do have one issue with Encoder. Logback essentially replaced
> Layout with Encoder. However, my recollection is that it was done as part
> of converting to having Layouts write to outputStreams using character
> encoding. The Encoder interface we have is confusing in that regard as it
> doesn’t really “encode” anything. In fact, this has me wondering if it
> wouldn’t make more sense to create a BufferedLayout interface that extends
> Layout (instead of the inheritance being the other way around). This would
> not break binary compatibility and the name would make more sense.
>
> Ralph
>
> On Apr 13, 2016, at 9:36 AM, Remko Popma <remko.popma@gmail.com
> <javascript:_e(%7B%7D,'cvml','remko.popma@gmail.com');>> wrote:
>
> One usage is the StringBuilderEncoder class I just committed (it
> implements Encoder<StringBuilder>).
>
> For binary layouts, this still needs more thinking, but log4j could have a
> registry of custom encoders. Then, when a client logs an Order object we do
> a lookup, find the Encoder<Order> and use that encoder to write the binary
> data for the Order into the ByteBufferDestination.
>
> On Wed, Apr 13, 2016 at 9:37 PM, Mikael Ståldal <mikael.staldal@magine.com
> <javascript:_e(%7B%7D,'cvml','mikael.staldal@magine.com');>> wrote:
>
>> How would such an Encoder look like?
>>
>> On Wed, Apr 13, 2016 at 12:40 AM, Remko Popma <remko.popma@gmail.com
>> <javascript:_e(%7B%7D,'cvml','remko.popma@gmail.com');>> wrote:
>>
>>> It does break binary compatibility, but since it's log4j-core (not api)
>>> we agreed that this is acceptable here.
>>>
>>> The reason it's a separate super interface is that I plan to have other
>>> Encoder implementations (perhaps user-specified) for binary logging.
>>>
>>> The Jira may have more details:
>>> https://issues.apache.org/jira/browse/LOG4J2-1274
>>>
>>> Sent from my iPhone
>>>
>>> On 2016/04/13, at 5:30, Gary Gregory <garydgregory@gmail.com
>>> <javascript:_e(%7B%7D,'cvml','garydgregory@gmail.com');>> wrote:
>>>
>>> Now that Layout extends Encoder and Encoder is new in 2.6, why not fold
>>> Encoder in Layout?
>>>
>>> Doesn't Layout extending a new type (Encoder) break BC anyway?
>>>
>>> Gary
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com
>>> <javascript:_e(%7B%7D,'cvml','garydgregory@gmail.com');> | ggregory@apache.org
>>> <javascript:_e(%7B%7D,'cvml','ggregory@apache.org');>
>>> Java Persistence with Hibernate, Second Edition
>>> <http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>
>>
>> --
>> [image: MagineTV]
>>
>> *Mikael Ståldal*
>> Senior software developer
>>
>> *Magine TV*
>> mikael.staldal@magine.com
>> <javascript:_e(%7B%7D,'cvml','mikael.staldal@magine.com');>
>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>
>> Privileged and/or Confidential Information may be contained in this
>> message. If you are not the addressee indicated in this message
>> (or responsible for delivery of the message to such a person), you may
>> not copy or deliver this message to anyone. In such case,
>> you should destroy this message and kindly notify the sender by reply
>> email.
>>
>
>
>
Re: Layout extends Encoder
Posted by Remko Popma <re...@gmail.com>.
I'm actually quite attached to this name. It took several iterations to come up with, I think it's intuitive and descriptive and I'm very happy with this name.
I don't see any confusion: Logback's Encoder interface writes the resulting bytes to a stream where log4j 2 writes the resulting bytes to a nio ByteBuffer.
Their role and responsibility are identical: converting any generic object into bytes.
Furthermore this name is in line with naming conventions in the JDK, looking at CharEncoder/Decoder for example.
So I'm very reluctant to change this.
Remko
Sent from my iPhone
> On 2016/04/14, at 3:42, Ralph Goers <ra...@dslextreme.com> wrote:
>
> I guess I do have one issue with Encoder. Logback essentially replaced Layout with Encoder. However, my recollection is that it was done as part of converting to having Layouts write to outputStreams using character encoding. The Encoder interface we have is confusing in that regard as it doesn’t really “encode” anything. In fact, this has me wondering if it wouldn’t make more sense to create a BufferedLayout interface that extends Layout (instead of the inheritance being the other way around). This would not break binary compatibility and the name would make more sense.
>
> Ralph
>
>> On Apr 13, 2016, at 9:36 AM, Remko Popma <re...@gmail.com> wrote:
>>
>> One usage is the StringBuilderEncoder class I just committed (it implements Encoder<StringBuilder>).
>>
>> For binary layouts, this still needs more thinking, but log4j could have a registry of custom encoders. Then, when a client logs an Order object we do a lookup, find the Encoder<Order> and use that encoder to write the binary data for the Order into the ByteBufferDestination.
>>
>>> On Wed, Apr 13, 2016 at 9:37 PM, Mikael Ståldal <mi...@magine.com> wrote:
>>> How would such an Encoder look like?
>>>
>>>> On Wed, Apr 13, 2016 at 12:40 AM, Remko Popma <re...@gmail.com> wrote:
>>>> It does break binary compatibility, but since it's log4j-core (not api) we agreed that this is acceptable here.
>>>>
>>>> The reason it's a separate super interface is that I plan to have other Encoder implementations (perhaps user-specified) for binary logging.
>>>>
>>>> The Jira may have more details: https://issues.apache.org/jira/browse/LOG4J2-1274
>>>>
>>>> Sent from my iPhone
>>>>
>>>>> On 2016/04/13, at 5:30, Gary Gregory <ga...@gmail.com> wrote:
>>>>>
>>>>> Now that Layout extends Encoder and Encoder is new in 2.6, why not fold Encoder in Layout?
>>>>>
>>>>> Doesn't Layout extending a new type (Encoder) break BC anyway?
>>>>>
>>>>> Gary
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> Java Persistence with Hibernate, Second Edition
>>>>> JUnit in Action, Second Edition
>>>>> Spring Batch in Action
>>>>> Blog: http://garygregory.wordpress.com
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>>
>>> --
>>>
>>>
>>> Mikael Ståldal
>>> Senior software developer
>>>
>>> Magine TV
>>> mikael.staldal@magine.com
>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>
>>> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
>>> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
>>> you should destroy this message and kindly notify the sender by reply email.
>
Re: Layout extends Encoder
Posted by Ralph Goers <ra...@dslextreme.com>.
I guess I do have one issue with Encoder. Logback essentially replaced Layout with Encoder. However, my recollection is that it was done as part of converting to having Layouts write to outputStreams using character encoding. The Encoder interface we have is confusing in that regard as it doesn’t really “encode” anything. In fact, this has me wondering if it wouldn’t make more sense to create a BufferedLayout interface that extends Layout (instead of the inheritance being the other way around). This would not break binary compatibility and the name would make more sense.
Ralph
> On Apr 13, 2016, at 9:36 AM, Remko Popma <re...@gmail.com> wrote:
>
> One usage is the StringBuilderEncoder class I just committed (it implements Encoder<StringBuilder>).
>
> For binary layouts, this still needs more thinking, but log4j could have a registry of custom encoders. Then, when a client logs an Order object we do a lookup, find the Encoder<Order> and use that encoder to write the binary data for the Order into the ByteBufferDestination.
>
> On Wed, Apr 13, 2016 at 9:37 PM, Mikael Ståldal <mikael.staldal@magine.com <ma...@magine.com>> wrote:
> How would such an Encoder look like?
>
> On Wed, Apr 13, 2016 at 12:40 AM, Remko Popma <remko.popma@gmail.com <ma...@gmail.com>> wrote:
> It does break binary compatibility, but since it's log4j-core (not api) we agreed that this is acceptable here.
>
> The reason it's a separate super interface is that I plan to have other Encoder implementations (perhaps user-specified) for binary logging.
>
> The Jira may have more details: https://issues.apache.org/jira/browse/LOG4J2-1274 <https://issues.apache.org/jira/browse/LOG4J2-1274>
>
> Sent from my iPhone
>
> On 2016/04/13, at 5:30, Gary Gregory <garydgregory@gmail.com <ma...@gmail.com>> wrote:
>
>> Now that Layout extends Encoder and Encoder is new in 2.6, why not fold Encoder in Layout?
>>
>> Doesn't Layout extending a new type (Encoder) break BC anyway?
>>
>> Gary
>>
>> --
>> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@apache.org>
>> Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/>
>> Home: http://garygregory.com/ <http://garygregory.com/>
>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
>
>
> --
>
>
> Mikael Ståldal
> Senior software developer
>
> Magine TV
> mikael.staldal@magine.com <ma...@magine.com>
> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com <http://www.magine.com/>
>
> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply email.
>
Re: Layout extends Encoder
Posted by Remko Popma <re...@gmail.com>.
One usage is the StringBuilderEncoder class I just committed (it implements
Encoder<StringBuilder>).
For binary layouts, this still needs more thinking, but log4j could have a
registry of custom encoders. Then, when a client logs an Order object we do
a lookup, find the Encoder<Order> and use that encoder to write the binary
data for the Order into the ByteBufferDestination.
On Wed, Apr 13, 2016 at 9:37 PM, Mikael Ståldal <mi...@magine.com>
wrote:
> How would such an Encoder look like?
>
> On Wed, Apr 13, 2016 at 12:40 AM, Remko Popma <re...@gmail.com>
> wrote:
>
>> It does break binary compatibility, but since it's log4j-core (not api)
>> we agreed that this is acceptable here.
>>
>> The reason it's a separate super interface is that I plan to have other
>> Encoder implementations (perhaps user-specified) for binary logging.
>>
>> The Jira may have more details:
>> https://issues.apache.org/jira/browse/LOG4J2-1274
>>
>> Sent from my iPhone
>>
>> On 2016/04/13, at 5:30, Gary Gregory <ga...@gmail.com> wrote:
>>
>> Now that Layout extends Encoder and Encoder is new in 2.6, why not fold
>> Encoder in Layout?
>>
>> Doesn't Layout extending a new type (Encoder) break BC anyway?
>>
>> Gary
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> <http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior software developer
>
> *Magine TV*
> mikael.staldal@magine.com
> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>
> Privileged and/or Confidential Information may be contained in this
> message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not
> copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply
> email.
>
Re: Layout extends Encoder
Posted by Mikael Ståldal <mi...@magine.com>.
How would such an Encoder look like?
On Wed, Apr 13, 2016 at 12:40 AM, Remko Popma <re...@gmail.com> wrote:
> It does break binary compatibility, but since it's log4j-core (not api)
> we agreed that this is acceptable here.
>
> The reason it's a separate super interface is that I plan to have other
> Encoder implementations (perhaps user-specified) for binary logging.
>
> The Jira may have more details:
> https://issues.apache.org/jira/browse/LOG4J2-1274
>
> Sent from my iPhone
>
> On 2016/04/13, at 5:30, Gary Gregory <ga...@gmail.com> wrote:
>
> Now that Layout extends Encoder and Encoder is new in 2.6, why not fold
> Encoder in Layout?
>
> Doesn't Layout extending a new type (Encoder) break BC anyway?
>
> Gary
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
--
[image: MagineTV]
*Mikael Ståldal*
Senior software developer
*Magine TV*
mikael.staldal@magine.com
Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.
Re: Layout extends Encoder
Posted by Remko Popma <re...@gmail.com>.
It does break binary compatibility, but since it's log4j-core (not api) we agreed that this is acceptable here.
The reason it's a separate super interface is that I plan to have other Encoder implementations (perhaps user-specified) for binary logging.
The Jira may have more details: https://issues.apache.org/jira/browse/LOG4J2-1274
Sent from my iPhone
> On 2016/04/13, at 5:30, Gary Gregory <ga...@gmail.com> wrote:
>
> Now that Layout extends Encoder and Encoder is new in 2.6, why not fold Encoder in Layout?
>
> Doesn't Layout extending a new type (Encoder) break BC anyway?
>
> Gary
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory