Re: Scala API and Java API in the manual

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 > > Instead of "Scala API" under "API". > > Gary > > -- > E-Mail: garydgreg...@gmail.com | g

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

GelfLayout follows the standard from Graylog, similar in idea to the syslog standard. On 2 May 2017 at 19:34, Remko Popma 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 >

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

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://

Scala API and Java API in the manual

Hi All, I wonder if we should have two sibling entries in the manual: - Java API - Scala API Instead of "Scala API" under "API". Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition

Re: Apache HttpComponents HttpClient

On Tue, May 2, 2017 at 12:05 PM, Matt Sicker wrote: > I added my little sales pitch. This goes back to the other goal I had in > mind while experimenting with a Log4j Boot idea: emphasis on log4j-api as a > logging facade. I feel like we could do better in our "marketing message" > regarding both

Re: Apache HttpComponents HttpClient

I added my little sales pitch. This goes back to the other goal I had in mind while experimenting with a Log4j Boot idea: emphasis on log4j-api as a logging facade. I feel like we could do better in our "marketing message" regarding both log4j-api and log4j-core being separate. On 2 May 2017 at 13

Apache HttpComponents HttpClient

Hi all, A while back, I ported Apache HttpComponents [1] HttpClient's trunk from Apache Commons Logging to Log4j 2 for the upcoming HttpClient 5 Alpha release. This was discussed and approved of the ML of course. Now, one developer is making a fuss. I'd like some help from our community explainin

Re: [Log4j] Plans for modularization

So let's have a look at Git branch LOG4J2-1889. On Tue, May 2, 2017 at 5:45 PM, Matt Sicker wrote: > Google has a serious case of NIH syndrome which is why I tend to avoid > their Java libraries. ;) > > Splitting log4j-kafka sounds like a good first step. Hopefully we can > figure out a manageab

[GitHub] logging-log4j2 issue #75: trim levels read from properties file to remove tr...

Github user jvz commented on the issue: https://github.com/apache/logging-log4j2/pull/75 No worries about the travis bit, something is broken there at the moment. The PR looks good, ready for merge, though I myself will not get a chance to do this for at least a few hours if anyone el

Re: [Log4j] Plans for modularization

Google has a serious case of NIH syndrome which is why I tend to avoid their Java libraries. ;) Splitting log4j-kafka sounds like a good first step. Hopefully we can figure out a manageable way to handle the docs over time. On 2 May 2017 at 03:19, Mikael Ståldal wrote: > Sounds good. > > I thin

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

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 wrot

[GitHub] logging-log4j2 issue #75: trim levels read from properties file to remove tr...

Github user thuri commented on the issue: https://github.com/apache/logging-log4j2/pull/75 Hi, so what can we do about the problem with the travis-ci build? Is there any chance this PR can be part of the next release? --- If your project is set up for it, you can reply to this email

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

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 i

Re: Effective use of logging with Graylog and other log aggregators

Chainsaw is still alive; we just need to cut a release. ;) On 2 May 2017 at 03:09, Mikael Ståldal wrote: > I made some tests with Graylog a couple of days ago. I was able to get > Log4j 2.8.2 to work with UDP socket and Kafka. > > After implementing LOG4J2-1854 >

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

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 wrote: > Given the inherent security problems with Java object serialization > (highlighted by CVE-2017-5645), I do suggest that we deprecate > SerializedLayout and remov

Re: Timing tasks

Maybe implement an AutoClosableTimer that implements the AutoClosable interface [1]? I often take use of the using(something){} directive in C# and find it quite readable. [1] https://docs.oracle.com/javase/8/docs/api/java/lang/AutoCloseable.html On 2 May 2017 1:59 p.m., "Mikael Ståldal" wrote:

Re: Timing tasks

As far as I can see, the Timer class is in test only? On Tue, May 2, 2017 at 1:58 PM, Mikael Ståldal wrote: > Why is this class duplicated? Can't we remove the one in log4j-core? > > On Tue, May 2, 2017 at 4:59 AM, Ralph Goers > wrote: > >> We have had this since I started log4j. It is in both

Re: Timing tasks

Why is this class duplicated? Can't we remove the one in log4j-core? On Tue, May 2, 2017 at 4:59 AM, Ralph Goers wrote: > We have had this since I started log4j. It is in both core and api as > Timer. > > You can do > > Timer timer = new Timer(“Step1”); > …. > …. > timer.start() > … > … > … > t

[Log4j] Deprecate SerializedLayout and remove it as default

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 wa

Re: [Log4j] Plans for modularization

Sounds good. I think a first step would be for us to cooperate on completing the separation of log4j-kafka that I started, and then use that as a template for others. On Sun, Apr 30, 2017 at 10:23 PM, Matt Sicker wrote: > Just to make sure this sounds reasonable, here's my idea for a roadmap: >

Re: [Log4j] Plans for modularization

Google does not use Git, I think they use some internally developed VCS. On Sun, Apr 30, 2017 at 6:56 PM, Matt Sicker wrote: > I doubt Google uses Git then. > > One of the main goals of separating repositories is to make release > management easier so we can RERO more! Though part of the problem

Re: Effective use of logging with Graylog and other log aggregators

I made some tests with Graylog a couple of days ago. I was able to get Log4j 2.8.2 to work with UDP socket and Kafka. After implementing LOG4J2-1854 , TCP socket also works. I have updated the documentation of GelfLayout to show how to use both UD