This really feels silly to me. Doing JSON and XML IO is not 100% trivial and removing the dep is not a driver for me and not a "feature". Well, the parsing is not trivial, generation is simple even with escaping. But why? I really don't see the point for the apps I write at least. I mean, I have my jar, a pile of third party jars including at least 2 log4j jars, api and core.
The point of this feature is that for the smallest app, I have my jar, 2 log4j jars instead of the those plus jackson or gson (if we wanted to redo JSON)? Seems like a small gain at a high increase in complexity. IMO. Gary On May 3, 2017 12:49 PM, "Matt Sicker" <[email protected]> wrote: I'll make a ticket for adding dependency-free JSON serialization and deserialization (probably separate tickets). On 3 May 2017 at 12:57, Remko Popma <[email protected]> wrote: > Thank you for the clarification, Mikael! > We may have to live with an external dependency initially until the JSON > serializer that Matt mentioned is ready. > > > > On Wed, May 3, 2017 at 5:22 PM, Mikael Ståldal <[email protected]> > wrote: > > > GelfLayout currently lacks markers, context stack and detailed structured > > stacktrace (it has a string formatted stacktrace), thread id, location, > > etc. > > > > The GELF standard i extensible, but only with key-value pairs with string > > or numeric values, it cannot be extended with an arbitrary JSON > structure. > > > > GelfLayout currently have two Log4j specific extensions for loggerName > and > > threadName. We could add some more, but it is not feasible to store a > > detailed structured stacktrace there. > > > > If we aim for complete reconstruction of a LogEvent, with all details, > then > > GELF is not a suitable format (and neither is Syslog/RFC5424). > > > > On Wed, May 3, 2017 at 3:44 AM, Matt Sicker <[email protected]> wrote: > > > > > GelfLayout follows the standard from Graylog, similar in idea to the > > syslog > > > standard. > > > > > > On 2 May 2017 at 19:34, Remko Popma <[email protected]> wrote: > > > > > > > That sounds good! > > > > Essentially we want a layout that allows the receiver to reconstruct > > the > > > > LogEvent (assuming the receiver has all required classes for custom > > > > messages etc). > > > > > > > > Isn't GelfLayout quite close? What info does it leave out? > > > > > > > > > > > > > > > > (Shameless plug) Every java main() method deserves > http://picocli.info > > > > > > > > > On May 3, 2017, at 0:44, Matt Sicker <[email protected]> wrote: > > > > > > > > > > I added some minimal code in the escape pattern converter for > > handling > > > > JSON > > > > > string encoding. We can probably include a minimal JSON > serialization > > > > > "library" inside log4j-core which could also be included in the > > general > > > > > GC-free ecosystem we have going on. > > > > > > > > > >> On 2 May 2017 at 10:14, Mikael Ståldal <[email protected] > > > > > > wrote: > > > > >> > > > > >> Oh, I did not think about that aspect. Both JsonLayout and a > > potential > > > > new > > > > >> AvroLayout (will) have external dependency. > > > > >> > > > > >> Without external dependency, we currently have GelfLayout, > > > PatternLayout > > > > >> and RFC5424Layout. > > > > >> > > > > >> GelfLayout and RFC5424Layout would be useful in some cases, but > they > > > do > > > > not > > > > >> have all information present in SerializedLayout and JsonLayout. > > > > >> > > > > >> RFC5424Layout and PatternLayout can be configured to include all > > > > >> information, but that's quite involved. > > > > >> > > > > >>> On Tue, May 2, 2017 at 4:11 PM, Remko Popma < > [email protected] > > > > > > > wrote: > > > > >>> > > > > >>> What layout do we have available that does not require an > external > > > > >>> dependency? > > > > >>> > > > > >>> On Tue, May 2, 2017 at 8:38 PM, Mikael Ståldal < > > > > >> [email protected]> > > > > >>> wrote: > > > > >>> > > > > >>>> Given the inherent security problems with Java object > > serialization > > > > >>>> (highlighted by CVE-2017-5645), I do suggest that we deprecate > > > > >>>> SerializedLayout and remove it as default for SocketAppender, > and > > > all > > > > >>> other > > > > >>>> appenders which currently have it as default. (We can still keep > > > > >>>> SerializedLayout, with a warning about security issues in > > > > >> documentation, > > > > >>>> but users will have to enable it explicitly.) > > > > >>>> > > > > >>>> Some people have missed the fact that you can configure > > > SocketAppender > > > > >>> with > > > > >>>> another layout. > > > > >>>> > > > > >>>> I suggest we do this in the 2.9 release. > > > > >>>> > > > > >>>> I know this will break some existing configurations, but given > the > > > > >>> security > > > > >>>> problems, I think that is a price we have to pay in this case. > > > > >>>> > > > > >>>> We have a JIRA ticket for a new Avro based binary layout: > > > > >>>> https://issues.apache.org/jira/browse/LOG4J2-1871 > > > > >>>> > > > > >>>> If we implement that in time for 2.9, we can recommend it as a > > > > >>> replacement > > > > >>>> for SerializedLayout. If not, we could recommend JsonLayout > which > > > > >> should > > > > >>>> contain all necessary information. > > > > >>>> > > > > >>>> -- > > > > >>>> [image: MagineTV] > > > > >>>> > > > > >>>> *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. > > > > >>>> > > > > >>> > > > > >> > > > > >> > > > > >> > > > > >> -- > > > > >> [image: MagineTV] > > > > >> > > > > >> *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. > > > > >> > > > > > > > > > > > > > > > > > > > > -- > > > > > Matt Sicker <[email protected]> > > > > > > > > > > > > > > > > -- > > > Matt Sicker <[email protected]> > > > > > > > > > > > -- > > [image: MagineTV] > > > > *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. > > > -- Matt Sicker <[email protected]>
