Re: [Log4j] Appender configuration error

2017-05-03 Thread Remko Popma
Yes, if you search for "ignoring" you should find a few other places where error handling is done similarly. (Shameless plug) Every java main() method deserves http://picocli.info > On May 4, 2017, at 5:20, Gary Gregory wrote: > > The problem is that users see an exception in their log and pa

Re: The Apache Software Foundation Welcomes 64 New Members

2017-05-03 Thread Matt Sicker
Thanks! I'm happy to join the ASF and get more involved across the foundation. On 3 May 2017 at 15:36, Gary Gregory wrote: > Congrats Matt on your Apache Membership! > > Gary > > -- > *From:* Sally Khudairi > *Sent:* Wednesday, May 3, 2017 11:41:34 AM > *To:* Apache

Re: [Log4j] Deprecate SerializedLayout and remove it as default

2017-05-03 Thread Matt Sicker
Remko has a ticket with a proposed binary logging format. Does that include all the relevant data to reconstruct LogEvents by reading the file(s)? On 3 May 2017 at 15:36, Ralph Goers wrote: > While I agree with Gary, my recommendation would be to either come up with > a custom serialization/dese

Fwd: The Apache Software Foundation Welcomes 64 New Members

2017-05-03 Thread Gary Gregory
Congrats Matt on your Apache Membership! Gary From: Sally Khudairi Sent: Wednesday, May 3, 2017 11:41:34 AM To: Apache Announce List Subject: The Apache Software Foundation Welcomes 64 New Members [this announcement is available online at https://s.apache.org/2

Re: [Log4j] Deprecate SerializedLayout and remove it as default

2017-05-03 Thread Ralph Goers
While I agree with Gary, my recommendation would be to either come up with a custom serialization/deserialization format, use one where we can just copy a class or two, or customize the SerializedLayout to not include arbitrary classes. Ralph > On May 3, 2017, at 1:29 PM, Matt Sicker wrote: >

Re: [Log4j] Deprecate SerializedLayout and remove it as default

2017-05-03 Thread Matt Sicker
I suppose serialization would be more important for dependency-free. I don't believe there's any way to make Jackson GC-free, for example, as a use case here. On 3 May 2017 at 15:14, Gary Gregory wrote: > This really feels silly to me. Doing JSON and XML IO is not 100% trivial > and removing the

Re: [Log4j] Appender configuration error

2017-05-03 Thread Gary Gregory
The problem is that users see an exception in their log and panic. I've seen this time and time again. Nothing is wrong with the app; the logging or another component is misconfigured is all. The component tells you something is wrong and the app continues normally. Usually. I'm not sure how to ad

Re: [Log4j] Deprecate SerializedLayout and remove it as default

2017-05-03 Thread Gary Gregory
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

Re: [Log4j] Appender configuration error

2017-05-03 Thread Matt Sicker
Exactly what Ralph said. The established pattern we have right now is StatusLogger.error, return null. Who wants their logging framework blowing up their application anyways? ;) On 3 May 2017 at 10:41, Ralph Goers wrote: > Generally, I would log the error to the status logger and then cause the

Re: [Log4j] Deprecate SerializedLayout and remove it as default

2017-05-03 Thread Matt Sicker
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 wrote: > Thank you for the clarification, Mikael! > We may have to live with an external dependency initially until the JSON > serializer that Mat

Re: [Log4j] Deprecate SerializedLayout and remove it as default

2017-05-03 Thread Remko Popma
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 wrote: > GelfLayout currently lacks markers, context stack and detailed structured > stacktr

Re: [Log4j] Appender configuration error

2017-05-03 Thread Ralph Goers
Generally, I would log the error to the status logger and then cause the factory/builder for the component to return null. Ralph > On May 3, 2017, at 7:52 AM, Mikael Ståldal wrote: > > The main problem I have is that I get two ERROR messages for one problem. > > On Wed, May 3, 2017 at 4:50 P

Re: [Log4j] Appender configuration error

2017-05-03 Thread Mikael Ståldal
The main problem I have is that I get two ERROR messages for one problem. On Wed, May 3, 2017 at 4:50 PM, Gary Gregory wrote: > As I am experiencing now in a different stack, too much is better than too > little ;-) > > Are you thinking that the stack traces make it overwhelming? Or the > messag

Re: [Log4j] Appender configuration error

2017-05-03 Thread Gary Gregory
As I am experiencing now in a different stack, too much is better than too little ;-) Are you thinking that the stack traces make it overwhelming? Or the messages not clear enough? Gary On May 3, 2017 3:23 AM, "Mikael Ståldal" wrote: What is an appender supposed to do when it cannot be created

[Log4j] Appender configuration error

2017-05-03 Thread Mikael Ståldal
What is an appender supposed to do when it cannot be created due to the supplied configuration being invalid? I tried to throw IllegalArgumentException and ConfigurationException, but in both cases I get a bit too much error logging: 2017-05-03 12:17:36,757 main ERROR Unable to inject fields into

Re: Scala API and Java API in the manual

2017-05-03 Thread Mikael Ståldal
Sounds good. On Wed, May 3, 2017 at 3:45 AM, Matt Sicker wrote: > I'd like that idea to give it more visibility as well. > > On 2 May 2017 at 16:16, Gary Gregory wrote: > > > Hi All, > > > > I wonder if we should have two sibling entries in the manual: > > > > - Java API > > - Scala API > > > >

Re: [Log4j] Deprecate SerializedLayout and remove it as default

2017-05-03 Thread Mikael Ståldal
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