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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> wrote: >>> How would such an Encoder look like? >>> >>>> On Wed, Apr 13, 2016 at 12:40 AM, Remko Popma <[email protected]> >>>> 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 <[email protected]> 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: [email protected] | [email protected] >>>>> 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 >>> [email protected] >>> 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. >
