Due-to in changes.xml

Gary, I am wondering why you have recently gotten in the habit of adding yourself to the due-to field of changes.xml. Historically we have always used that to give credit to non-committers who provide patches or significantly contribute to them. As committers we get credit in the source contro

Re: Due-to in changes.xml

giving yourself credit twice. Ralph > On Aug 13, 2019, at 8:13 PM, Ralph Goers wrote: > > Gary, > > I am wondering why you have recently gotten in the habit of adding yourself > to the due-to field of changes.xml. Historically we have always used that to > give credit to

Re: Due-to in changes.xml

. It is over the top. Ralph > On Aug 13, 2019, at 8:51 PM, Matt Sicker wrote: > > Can the “By” column contain real names instead of usernames? > > On Tue, Aug 13, 2019 at 22:18, Ralph Goers > wrote: > >> I should also add that the changes report already gives credi

Re: Due-to in changes.xml

>> Talph, >> >> Feel free to edit changes.xml as you best see fit. >> >> Gary >> >> On Tue, Aug 13, 2019, 22:37 Ralph Goers >> wrote: >> >>> The “By” column is a link to the team list that includes all your >>> i

Re: [logging-log4j2] branch release-2.x updated: [LOG4J2-2673] OutputStreamAppender.Builder ignores setFilter().

Any update on this? I’d like my builds to work again. Ralph > On Aug 13, 2019, at 4:29 PM, Ralph Goers wrote: > > Gary, > > It seems this change broker compatibility. Please see the Jenkins failure. > You either need to resolve the code so compatibility is ma

Re: [logging-log4j2] branch release-2.x updated: [LOG4J2-2673] OutputStreamAppender.Builder ignores setFilter().

Gary, Are you going to look into this? Ralph > On Aug 14, 2019, at 9:17 AM, Ralph Goers wrote: > > Any update on this? I’d like my builds to work again. > > Ralph > >> On Aug 13, 2019, at 4:29 PM, Ralph Goers wrote: >> >> Gary, >> >> It se

Re: [logging-log4j2] branch release-2.x updated: [LOG4J2-2673] OutputStreamAppender.Builder ignores setFilter().

reverting the breakage or by adding the recommended changes to revapi.json to document why compatibility was broken. Ralph > On Aug 15, 2019, at 4:54 PM, Gary Gregory wrote: > > I fixed it already in both branches. > > Gary > > On Thu, Aug 15, 2019, 10:42 Ralph Goers wrote: &

Re: [logging-log4j2] branch release-2.x updated: [LOG4J2-2673] OutputStreamAppender.Builder ignores setFilter().

World!" ); >Builder builder = OutputStreamAppender.newBuilder(); >} > } > > Then I ran that class against 2.13.-SNAPSHOT Core without recompiling and > it ran fine. > > What am I missing? > > Gary > > On Thu, Aug 15, 2019 at 5:03 PM Ralph Goers &g

Re: "fat" JARs plus custom plugins?

I think you need to try with a SNAPSHOT of 3.0. As I mentioned in a previous email 3.0 now longer generates a .dat file but generates a Java source file that gets compiled with your source code instead. It also requires a .service file for ServiceLoader but those should be handled out of the bo

Re: "fat" JARs plus custom plugins?

lph, that makes sense as a way forward. > > Do you have any estimates on when 3.0 might be GA and/or an estimate of the > stability of the current snapshot release? We'll likely stick with our fork > in production until 3.0 is GA. > > On Wed, Aug 21, 2019 at 12:58 PM Ralph G

Re: "fat" JARs plus custom plugins?

Plus the story of how we approach backward compatibility with 2.x in > 3.x (e.g., renamed package, compatibility shims, etc.) > > On Wed, 21 Aug 2019 at 12:19, Ralph Goers wrote: >> >> The stability should be fine. We have continually port all bug fixes and >> enhan

Re: "fat" JARs plus custom plugins?

g > formats similarly manageable depending on how far the idea can > stretch). I'm still thinking of how it would work before I write any > proof of concept, though. > > On Wed, 21 Aug 2019 at 13:30, Ralph Goers wrote: >> >> That may be more of a documentation task. Al

Re: [Travis] Build failure in a github pull request

I tried to fix the Travis build but I don’t know what to specify for the JDK paths for the toolchains.xml and don’t know who to ask. Ralph > On Aug 25, 2019, at 12:15 PM, Matt Sicker wrote: > > This is a known issue with our Travis config. I'm surprised that we > don't have Jenkins configured

Re: [Java] New NVMe ByteBuffer API in Java 14, potential super fast appender?

FWIW, the memory mapped file appender fails when you run the perf tests. I had to comment it out. I don’t recall what the problem was. Ralph > On Aug 25, 2019, at 9:27 AM, Carter Kozak wrote: > > JEP 352: Non-Volatile Mapped Byte Buffers: https://openjdk.java.net/jeps/352 > This sounds interes

Re: [Java] GitHub usage stats seem interesting

I’d have to look at it again but I suspect there might be a way that we could create a version of AppenderSkeleton that works with Log4j 2. The problem is that people were accessing the internals of Log4j so that even if we could provide support for those signatures I am not sure they would real

Re: Jenkins build became unstable: Log4j 2 3.x #476

Because it isn’t a PatternConverter? Look at what it does. The newInstance method creates a DatePatternConverter. The FileDatePatternConverter and IntegerPatternConverter are both used for the filePattern in the rolling file appender, not for a pattern layout. Ralph > On Aug 31, 2019, at 12

Re: Jenkins build became unstable: Log4j 2 3.x #476

he one class. > Generic type erasure avoided this from cropping up before. > > On Sat, Aug 31, 2019 at 20:50, Ralph Goers > wrote: > >> >> Because it isn’t a PatternConverter? Look at what it does. The >> newInstance method creates a DatePatternC

Re: [Java] Proposal: replacing plugin annotations with javax.inject ones

IIUC this will require a dependency on a Java EE jar? For that reason alone, no. Ralph > On Oct 8, 2019, at 1:23 PM, Gary Gregory wrote: > > That sounds good Matt, I say go for it. > > Gary > > On Tue, Oct 8, 2019, 16:08 Matt Sicker wrote: > >> I've been doing some experiments with the pl

Re: [Java] Proposal: replacing plugin annotations with javax.inject ones

t 8, 2019, at 1:26 PM, Ralph Goers wrote: > > IIUC this will require a dependency on a Java EE jar? For that reason alone, > no. > > Ralph > >> On Oct 8, 2019, at 1:23 PM, Gary Gregory wrote: >> >> That sounds good Matt, I say go for it. >> >>

Re: [Java] Proposal: replacing plugin annotations with javax.inject ones

I don’t see how that relates. The proposal as I understand it is to replace the existing annotations with annotations from javax.inject, which would require a JEE jar. Ralph > On Oct 8, 2019, at 1:31 PM, Jochen Wiedmann wrote: > > On Tue, Oct 8, 2019 at 10:26 PM Ralph Goers

Re: [Java] Proposal: replacing plugin annotations with javax.inject ones

nfiguration into a plugin. > > On Tue, 8 Oct 2019 at 15:40, Ralph Goers wrote: >> >> I don’t see how that relates. The proposal as I understand it is to replace >> the existing annotations with annotations from javax.inject, which would >> require a JEE jar. &

Log4j and Spring

Recently I added support for Spring Cloud Config to Log4j. In an effort to continue to persuade Spring to use Log4j as the default Logging implementation I would like to consider other ways we could improve our Spring integration. The problem is, I am not really sure what that would be. Curre

Re: [Java] Proposal: replacing plugin annotations with javax.inject ones

3.x API to use an annotation model similar to that. I’ll >> show a proof of concept sometime soon. >> >> On Tue, Oct 8, 2019 at 18:50, Ralph Goers wrote: >>> >>> I don’t understand. You can’t add javax.inject stuff into our namespace >>> without

Re: Log4j and Spring

att Sicker wrote: > > Can we provide a log4j configuration facade API for doing common > programmatic configuration tasks like that? Think Configurator but for > manipulating certain aspects of a Configuration that's already > running. > > On Wed, 9 Oct 2019 at 12:49, Ralph

Re: Log4j and Spring

g > wrong with that approach. > > On Wed, Oct 9, 2019 at 13:41, Ralph Goers > wrote: > >> I am sure we could, but I am not sure how that helps the usage in Spring. >> >> Another thought would be to have Log4j reconfigure when it finally has >> access to a

Re: [Java] Proposal: replacing plugin annotations with javax.inject ones

etermining what to do based on the return type of the factory method was > already an established idea. I think it made sense to combine them all into > @PluginFactory, and because of that, I noticed the correspondence between > that and @Inject. > > On Wed, Oct 9, 2019 at 13:

Re: [Java] Proposal: replacing plugin annotations with javax.inject ones

think that is what you are intending. Ralph > On Oct 9, 2019, at 1:38 PM, Ralph Goers wrote: > > Ok, but given @Scope and @Qualifier can only be used to annotate the existing > PluginElement, PluginAttribute and PluginValue annotations I am not sure what > they buy you. They c

Re: [LOG4PHP] Abandoned? Contributing?

Several of the logging services projects are in need of attention and need more volunteers to help maintain them. Log4PHP is one of those. Any help you can provide would be most welcome! Ralph > On Oct 26, 2019, at 2:36 PM, Kate Gray wrote: > > Hello, > > Has log4php been abandoned? > > Lo

Re: [LOG4PHP] Abandoned? Contributing?

g the license > the same on contributed code. > > I have no ability to clean up docs, or close issues, so I'm limited in what I > can do there. > > Kate > > From: Ralph Goers > Sent: Sunday, October 27, 2019 12:26:14 AM > T

Re: [LOG4PHP] Abandoned? Contributing?

Kate, I’ve gone ahead and merged the two PRs you submitted. If you wouldn’t mind, could you review some of the outstanding PRs for correctness? If they look good I would be happy to merge those as well. Ralph > On Oct 27, 2019, at 9:36 PM, Ralph Goers wrote: > > You should subm

Re: [LOG4PHP] Site Generation

FWIW, https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Site discusses how the logging services web site and the individual logging projects are built. I’ve heard

Re: [LOG4PHP] Site Generation

I think it had something to do with >> not supporting UTF-8 correclty. Most likely this is gone by now and I would >> be fine to move on. >> >> >> -- >> Christian Grobmeier >> grobme...@gmail.com >> >> On Wed, Oct 30, 2019, at 05:04, Ralph

Re: [LOG4PHP] Site Generation

a blocker using Phing, I think it had something to do with not > supporting UTF-8 correclty. Most likely this is gone by now and I would be > fine to move on. > > > -- > Christian Grobmeier > grobme...@gmail.com > > On Wed, Oct 30, 2019, at 05:04, Ralph Goers w

Re: [Java] Proposal: replacing plugin annotations with javax.inject ones

nning parts of the system should help reduce the >> complexity of many tests as well, and it may also help reduce the time >> taken running tests, though that will still likely be affected by the >> various integration tests regardless. >> >> On Wed, 9 Oct 2019

Re: [Java] Proposal: replacing plugin annotations with javax.inject ones

gt; identify the various logical scopes in the library, I think that could lead >> to less potential bugs. >> >> On Sun, Nov 3, 2019 at 14:14 Ralph Goers >> wrote: >> >>> I have a couple of comments: >>> It isn’t really possible for me to know what

Re: proposal/idea for enhancement to log4j audit

If I understand what you are asking for is you want to define an event attribute that has a constant value? Ralph > On Nov 25, 2019, at 7:21 PM, Bob wrote: > > I would like to propose an enhancement to allow the catalog to be extended to > include 'properties' for events. > > A property bei

Re: [Meta] Article about syslog security limitations

I am unable to view that web site as it has certificate problems. Ralph > On Dec 2, 2019, at 8:48 AM, Matt Sicker wrote: > > https://www.myname.website/whats-wrong-with-syslog-a-lot-actually > > This article seems fairly interesting. I know that we support TLS for > syslog, though I didn't kno

Re: [Meta] Article about syslog security limitations

ions. Sure lots of them have their > own issues, but let's take it one step at a time. JDBC is a good one. It's > a pull not a push, so as long as your SIEM can remember where it left off, > it will always get the missing logs after the dust settles. Many Windows >

Re: [Meta] Article about syslog security limitations

> On Dec 2, 2019, at 9:25 AM, Gary Gregory wrote: > > On Mon, Dec 2, 2019 at 11:24 AM Ralph Goers > wrote: > >> All of this would apply to the original BSD syslog format. RFC 5424 solves >> most of his problems - presuming the SIEM supports it. Nowadays I am

Log4j 2.13.0

I have finished all the work on new features I wanted to add for the next release. The latest feature I added is Log4j 2 will now support Log4j 1 xml and properties file configurations. I have flagged it as experimental - it either requires a system property to explicitly enable auto detecting

Re: Log4j 2.13.0

he asynchronous queue is full. > > Best, > -ck > > On Mon, Dec 2, 2019, at 11:32, Ralph Goers wrote: >> I have finished all the work on new features I wanted to add for the next >> release. The latest feature I added is Log4j 2 will now support Log4j 1 xml >> and p

Re: [Meta] Article about syslog security limitations

> On Dec 2, 2019, at 10:41 AM, Gary Gregory wrote: > > On Mon, Dec 2, 2019 at 11:34 AM Ralph Goers > wrote: > >> >> >>> On Dec 2, 2019, at 9:25 AM, Gary Gregory wrote: >>> >>> On Mon, Dec 2, 2019 at 11:24 AM Ralph Goers >>&g

Re: [jira] [Closed] (LOG4J2-2418) NullPointerException when closing never used RollingRandomAccessFileAppender

Gary, it looks like you merged this but I don’t see an entry for it in changes.xml. Ralph > On Dec 2, 2019, at 11:18 AM, Jonas Rutishauser (Jira) wrote: > > > [ > https://issues.apache.org/jira/browse/LOG4J2-2418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > >

Re: [Meta] Article about syslog security limitations

> On Dec 2, 2019, at 12:35 PM, Matt Sicker wrote: > > On Mon, 2 Dec 2019 at 13:00, Ralph Goers wrote: >>> It's hard to find the right balance between not enough and too much coffee >>> ;-) >>> >> >> For me that balance is easy - I hate

Re: [jira] [Closed] (LOG4J2-2418) NullPointerException when closing never used RollingRandomAccessFileAppender

OK, thanks. Ralph > On Dec 2, 2019, at 1:55 PM, Gary Gregory wrote: > > On Mon, Dec 2, 2019 at 2:02 PM Ralph Goers > wrote: > >> Gary, it looks like you merged this but I don’t see an entry for it in >> changes.xml. >> > > I do, here: > htt

Re: Log4j 2.13.0

Carter, If you are going to fix LOG4J2-2725 you need to do it quickly. I have been applying patches this evening and will probably do some more tomorrow but may start the release process tomorrow night or Sunday morning. Ralph > On Dec 2, 2019, at 10:16 AM, Ralph Goers wrote: > &g

[VOTE] Release Log4j 2.13.0-rc1

This is a vote to release Log4j 2.13.0, the next version of the Log4j 2 project. Please download, test, and cast your votes on the log4j developers list. [] +1, release the artifacts [] -1, don't release because... The vote will remain open for 72 hours (or more if required). All votes are welco

Re: [VOTE] Release Log4j 2.13.0-rc1

n: 643, Failures: 1, Errors: 0, Skipped: 3 > > Maybe this test has some hard-coded EOLs? > > Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) > Maven home: C:\Java\apache-maven-3.6.3\bin\.. > Java version: 1.8.0_231, vendor: Oracle Corporation, runtime: C:\Program >

Re: [VOTE] Release Log4j 2.13.0-rc1

Oh wait, I am looking at the wrong class. Let me check again. Ralph > On Dec 9, 2019, at 8:40 PM, Ralph Goers wrote: > > That test class hasn’t been modified since the last release. I obviously > don’t get that error on my Mac and I have run the build many times, so it > mu

Re: [VOTE] Release Log4j 2.13.0-rc1

OK, that test was added 2 days after the last release in August. I guess that means you haven’t done a full build since then? Ralph > On Dec 9, 2019, at 8:42 PM, Ralph Goers wrote: > > Oh wait, I am looking at the wrong class. Let me check again. > > Ralph > >> On

Re: [VOTE] Release Log4j 2.13.0-rc1

Having looked at the test it is checking for “\n\t” in the result. The test should not do that. I will modify it but I don’t think that is a reason to block the release, assuming it gets enough votes. Ralph > On Dec 9, 2019, at 8:44 PM, Ralph Goers wrote: > > OK, that test was add

Re: [VOTE] Release Log4j 2.13.0-rc1

Dec 9, 2019 at 10:49 PM Ralph Goers > wrote: > >> Having looked at the test it is checking for “\n\t” in the result. The >> test should not do that. I will modify it but I don’t think that is a >> reason to block the release, assuming it gets enough votes. >> &g

Re: [VOTE] Release Log4j 2.13.0-rc1

candidate? Ralph > On Dec 10, 2019, at 7:57 AM, Gary Gregory wrote: > > I'm not OK with that kind of workaround, as a user it does not inspire > confidence. I won't -1 though. > > Gary > > On Tue, Dec 10, 2019 at 12:21 AM Ralph Goers > wrote:

Re: [VOTE] Release Log4j 2.13.0-rc1

I just noticed that Jenkins also has a unit test failing in log4j-1.2-api. Ralph > On Dec 10, 2019, at 8:06 AM, Carter Kozak wrote: > > I'm planning to test and benchmark with several projects I'm responsible for > today. > > On Tue, Dec 10, 2019, at 10:03, Ralph

Re: [VOTE] Release Log4j 2.13.0-rc1

Given that there have been no other responses I am going to close this vote. I will create a new release candidate as soon as I can. Ralph > On Dec 10, 2019, at 8:23 AM, Ralph Goers wrote: > > I just noticed that Jenkins also has a unit test failing in log4j-1.2-api. > > Ral

[VOTE] Log4j 2.13.0-rc2

This is a vote to release Log4j 2.13.0, the next version of the Log4j 2 project. Please download, test, and cast your votes on the log4j developers list. [] +1, release the artifacts [] -1, don't release because... The vote will remain open for 72 hours (or more if required). All votes are welco

Re: [VOTE] Log4j 2.13.0-rc2

This vote has now been open for 2 days with no feedback. Please vote. Ralph > On Dec 11, 2019, at 11:11 PM, Ralph Goers wrote: > > This is a vote to release Log4j 2.13.0, the next version of the Log4j 2 > project. > > Please download, test, and cast your votes on the log

Re: [VOTE] Log4j 2.13.0-rc2

t; Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > > Gary > > On Thu, Dec 12, 2019 at 1:11 AM Ralph Goers > wrote: > >> This is a vote to release Log4j 2.

[RESULT][VOTE] Release Log4j 2-13.0-rc2

The release vote has passed with +1 votes from Carter Kozak, Remko Popma, Gary Gregory, and Ralph Goers. No other votes were cast. I will continue with the release process. Ralph

[ANNOUNCEMENT] Log4j 2.13.0 released!

The Apache Log4j 2 team is pleased to announce the Log4j 2.13.0 release! Apache Log4j is a well known framework for logging application behavior. Log4j 2 is an upgrade to Log4j that provides significant improvements over its predecessor, Log4j 1.x, and provides many other modern features such as

Re: Is there any chance that there will be a security fix for log4j-v1.2.17?

While Gary is correct that we wouldn’t want to discuss a specific security vulnerability in public we can discuss the policy here. For a number of reasons I would say the answer is “No”: It gives the impress that Log4j 1.x is not End-of-Life and that future enhancements and bug fixes could be ac

Thoughts on Log4j 3.0

Now that 2.13.0 is pushed out I would like to focus again on 3.0. The primary driver was to make it “compatible” with JPMS, i.e. properly define each of the jars as a Java module. Some of our dependencies, like Jackson, have implemented support so that we can now properly reference them, which i

Re: Is there any chance that there will be a security fix for log4j-v1.2.17?

> On Dec 15, 2019, at 3:06 PM, Andrew Marlow wrote: > > On Sun, 15 Dec 2019 at 21:47, Gary Gregory > wrote: > >> Thanks for bring up policy Ralph. For me, a new Log4j 1 release would have >> to patch a pretty catastrophic security vulnerability. >> > > Yes, I

Re: Thoughts on Log4j 3.0

> On Dec 15, 2019, at 2:44 PM, Gary Gregory wrote: > > All good thoughts. > > I suspect that now that 2.x is on Java 8 there are some clean ups we will > want to do. What comes to mind immediately is deprecating our functional > interfaces in favor of the ones in java.util.function. Then we c

Re: Thoughts on Log4j 3.0

> On Dec 16, 2019, at 7:01 AM, Gary Gregory wrote: > > On Sun, Dec 15, 2019 at 5:56 PM Ralph Goers <mailto:ralph.go...@dslextreme.com>> > wrote: > >> >> >>> On Dec 15, 2019, at 2:44 PM, Gary Gregory >> wrote: >>> >>>

Re: Thoughts on Log4j 3.0

> On Dec 16, 2019, at 9:42 AM, Raman Gupta wrote: > > If there are API incompatibilities, an slf4j-like 2.x api bridge to > 3.x would probably be the way to go. > > Its been a while since I looked at it, but IIRC, while implementing > the Kotlin logger (https://logging.apache.org/log4j/kotlin

Re: Thoughts on Log4j 3.0

> On Dec 16, 2019, at 11:13 AM, Gary Gregory wrote: > > From the 10,000 ft level, within one app: > > - Log4j 2 configures itself by finding a log4j2.xml file. > - Log4j 3 configures itself by finding a log4j3.xml file. > - Both can co-exist happily > - The bridge exercise can be done separat

Re: Thoughts on Log4j 3.0

> On Dec 16, 2019, at 11:32 AM, Carter Kozak wrote: > > Before we make large API changes for 3.x, I think it's worth considering the > benefit compared to the churn (both for us, and log4j consumers) is worth it. > Can we articulate the benefits of our API break, particularly the benefits >

Re: Thoughts on Log4j 3.0

> On Dec 16, 2019, at 12:41 PM, Gary Gregory wrote: > > You cannot control "stratification" any more than how people architect > their apps ;-) It's just the nature of the success Java's tooling like > Maven that allows people to put together apps based on transitive > dependencies. The uninte

Re: Thoughts on Log4j 3.0

> On Dec 16, 2019, at 12:52 PM, Gary Gregory wrote: > > On Mon, Dec 16, 2019 at 2:48 PM Gary Gregory <mailto:garydgreg...@gmail.com>> wrote: > >> >> >> On Mon, Dec 16, 2019 at 1:36 PM Ralph Goers > <mailto:ralph.go...@dslextreme.com>> >

Re: Thoughts on Log4j 3.0

> On Dec 16, 2019, at 12:48 PM, Gary Gregory wrote: > > On Mon, Dec 16, 2019 at 1:36 PM Ralph Goers > wrote: >> >> We just added that in 2.13.0. Did you miss that? >> > > Oh, I see org.apache.logging.log4j.spi.AbstractLogger.atInfo()... > I certainl

Re: Thoughts on Log4j 3.0

> On Dec 16, 2019, at 12:57 PM, Gary Gregory wrote: > > Now that I see atInfo(), atWarn() and so on, for 3.0, I _expect_ to get rid > of the 400+ methods in Logger that repeat the exact same args but with > different method names (info(...), debug(...), ...) -1. Lots of code will continue to

Re: Thoughts on Log4j 3.0

> On Dec 16, 2019, at 1:03 PM, Gary Gregory wrote: > > I'll harp on one more thing :-( Why is LogBuilder called as such? It does > not "build()" a "Log", we do not even define a "Log". It does not build > anything right? It actually logs... oh well. Bummer for me that I like > discussing names

Re: Thoughts on Log4j 3.0

> On Dec 16, 2019, at 12:59 PM, Raman Gupta wrote: > > What is the point of releasing log4j 3.x if you only intend to make > non-breaking changes? Is it just a marketing thing then? We will be significantly impacting the implementation. We are breaking up core into smaller modules. Until we

Re: Thoughts on Log4j 3.0

> On Dec 16, 2019, at 1:06 PM, Gary Gregory wrote: > > And, so for 3.0: Move org.apache.logging.log4j.internal.DefaultLogBuilder > to org.apache.logging.log4j.spi since it is the only place seems to be used > from and make it package private unless I am misunderstanding the layout? > Yes, it

Re: Thoughts on Log4j 3.0

methods. But ExtendedLogger still needs to stick around even if it is an empty interface as a lot of code references it. I already did that for LifeCycle2, MessageFactory2, AbstractMessageFactory and possibly others. Ralph > On Dec 16, 2019, at 1:14 PM, Ralph Goers wrote: > > >

Re: Thoughts on Log4j 3.0

tracing is no longer necessary. > > https://github.com/shawjef3/logging-log4j2/tree/message-location-release-2.x-squashed > https://github.com/shawjef3/logging-log4j-scala/tree/message-location-squashed > > On Mon, Dec 16, 2019 at 3:34 PM Ralph Goers > wrote: > >> I sh

Re: Thoughts on Log4j 3.0

2d6bef80ef4f0334c2ed7043299ddbad > <https://github.com/shawjef3/logging-log4j-scala/commit/dd9a5dd2d6bef80ef4f0334c2ed7043299ddbad4> > > On Mon, Dec 16, 2019 at 11:02 PM Ralph Goers > wrote: > >> I am having trouble figuring out how to see only what you have changed. &

Re: Blog post

> On Dec 17, 2019, at 12:59 PM, Andrew Marlow wrote: > > yes Ralph that was great! I was particularly interested to learn that the > LMAX disruptor came later. I had always assumed async logging was the prime > motivation. Thanks, No. As I recall that was Remko’s addition. I had never heard

Re: Feature request/possible contribution

David, Can you please create a Jira issue with this feature request in it? I am not particularly happy with the JsonLayout at the moment as I think what it does is too limited. I’d like there to be a lot more flexibility as to what the resulting JSON should look like, not just dumping the log

Re: Thoughts on XML/JSON/YAML layout in Log4j 3.0 (Was: Feature request/possible contribution)

ttps://github.com/vy/log4j2-logstash-layout/issues/17 > [4] https://github.com/vy/log4j2-logstash-layout#performance > > On Mon, Dec 23, 2019 at 12:24 AM Ralph Goers > wrote: >> I am not particularly happy with the JsonLayout at the >> moment as I think what it does is too lim

Re: slf4j-1.8 and the event logger

I have no concerns. Ralph > On Dec 23, 2019, at 8:09 PM, Carter Kozak wrote: > > Hi all, > > Any concerns with deleting the slf4j EventLogger support in > log4j-slf4j18-impl given it's still in beta, and no longer supports the event > logger? My proposed change is pushed here: > https://git

Re: Thoughts on XML/JSON/YAML layout in Log4j 3.0 (Was: Feature request/possible contribution)

> On Dec 23, 2019, at 7:50 PM, Gary Gregory wrote: > > On Mon, Dec 23, 2019 at 6:25 PM Ralph Goers > wrote: > >> Thanks, >> >> What I was thinking was that I would just like a more flexible way to >> specify what should be included in the JSON. In i

Re: Thoughts on XML/JSON/YAML layout in Log4j 3.0 (Was: Feature request/possible contribution)

Comments inline > On Dec 24, 2019, at 2:09 AM, Volkan Yazıcı wrote: > > This is easier said than done. Customizing the schema and injected > content is the raison d'être of LogstashLayout. Would you people > accept a PR re-branding LogstashLayout as the new JsonLayout where the > default JSON sc

Re: Thoughts on XML/JSON/YAML layout in Log4j 3.0 (Was: Feature request/possible contribution)

> On Dec 24, 2019, at 2:06 PM, Volkan Yazıcı wrote: > > Indeed ColumnMapping is an alternative approach. I believe due to its > origin, i.e., RDBMSes, it facilitates a 1-to-1 mapping particularly > targeted at table column names, e.g., > > timestamp -> instant > message -> summary > > One c

Re: Thoughts on XML/JSON/YAML layout in Log4j 3.0 (Was: Feature request/possible contribution)

at 3:17 PM, Matt Sicker wrote: > > I’m not sure if any existing template libraries are garbage free, though I > like the idea in general at least. > > On Wed, Dec 25, 2019 at 14:42 Volkan Yazıcı wrote: > >> On Wed, Dec 25, 2019 at 7:38 AM Ralph Goers >> wrot

Re: The convention for thread-local allocations (TLAs)

Many of the ThreadLocals were added in the effort to make much of Log4j be garbage free. As I recall Remko did some performance tests on various alternatives and what we have is a result of that. But that is just my recollection. Ralph > On Dec 28, 2019, at 2:39 PM, Volkan Yazıcı wrote: >

Re: Constants in 3.0

Can you provide a PR that demonstrates what you would like to do? It is easier for me to evaluate the pros and cons of that then guessing what the implementation would look like. Ralph > On Dec 31, 2019, at 2:43 PM, Volkan Yazıcı wrote: > > A majority of the Log4j 2.0 constants are structure

Getting the most out of the Log4j 2 API

https://www.ralphgoers.com/post/getting-the-most-out-of-the-log4j-2-api

Re: [log4cxx] Contributing

The project to which PMC members belong is Apache Logging Services. When a committer is invited they have access to all the logging project repositories except for the one area that is limited to PMC members. If you plan on making significant contributions you should sign an ICLA. Yes, there

Re: The convention for thread-local allocations (TLAs)

I am not against making a change but I would need to see performance results before it gets merged. Ralph > On Jan 6, 2020, at 2:20 PM, Carter Kozak wrote: > > Let's give it a try and see how we like it :-) I probably won't have time to > prototype it for a month or two, but I think we could

Re: [log4cxx] Contributing a CMkae build system

Robert Middleton has also offered to help. I would suggest you collaborate here and in either a combined or individual forks. Ralph > On Jan 6, 2020, at 7:33 PM, Stephen Webb wrote: > > Hi All, > I am prepared to commit time to helping progress log4cxx to a release. > > I would like to add a

Re: Thoughts on XML/JSON/YAML layout in Log4j 3.0 (Was: Feature request/possible contribution)

Are you still considering contributing this? Ralph > On Jan 8, 2020, at 2:42 PM, Volkan Yazıcı wrote: > > On Tue, Dec 24, 2019 at 10:48 PM Volkan Yazıcı > wrote: >> In its current form, LogstashLayout can (almost) very well render the >> GELF layout[1]. There are only two shortcomings: 1) epo

Re: The convention for thread-local allocations (TLAs)

The requirement for core is, and will always be, that it can work without any additional libraries. In the places we use Thread Locals we would require that the Object Pooling logic be part of Log4j, not in another jar. Ralph > On Jan 8, 2020, at 4:32 PM, Gary Gregory wrote: > > Can we plea

Re: Thoughts on XML/JSON/YAML layout in Log4j 3.0 (Was: Feature request/possible contribution)

d templating solution would work, since you were the one > proposing this idea in the first place. Would you rather first see the > current LogstashLayout replacing JsonLayout in log4j-core? If so, I > can first focus on integrating LogstashLayout into log4j-core. > > On Thu, Jan 9,

Re: [log4cxx] Contributing a CMkae build system

The current PMC chair is Matt Sicker. I believe no release vote took place because a release build has not successfully been completed. Ralph > On Jan 11, 2020, at 11:38 PM, Stephen Webb wrote: > > Hi Thorsten, > > I saw in the mailing lists you have previously (July 2017, January 2018) > at

Re: [log4cxx] Contributing a CMkae build system

> On Jan 12, 2020, at 2:00 AM, Thorsten Schöning wrote: > > Guten Tag Stephen Webb, > am Sonntag, 12. Januar 2020 um 07:38 schrieben Sie: > >> Could you tell us why the vote did not happen on these occasions? > > Because things stopped at the point before for mostly two reasons: The > first

Re: PluginAttributeBuilder-vs-PluginAttribute

Builders haven’t gone away, if that is what you are thinking. I think all Matt did was make it so you could use @PluginAttribute wherever you would have used @PluginBuilderAttribute. I am not really sure why. Nothing else should have changed. Ralph > On Jan 16, 2020, at 8:35 AM, Volkan Yazıcı

Re: PluginAttributeBuilder-vs-PluginAttribute

> >> On Jan 16, 2020, at 10:54 AM, Ralph Goers wrote: >> >> Builders haven’t gone away, if that is what you are thinking. I think all >> Matt did was make it so you could use @PluginAttribute wherever you would >> have used @PluginBuilderAttribute. I am not reall

Re: final modifier in method args and local variables

That is a convention Gary imitated. If you don’t add the final keywords you can be sure Gary will do it. Ralph > On Jan 17, 2020, at 3:55 AM, Volkan Yazıcı wrote: > > Hello, > > I don't want to turn this into a religious war, but is having final > modifier on both method arguments and local

<    2   3   4   5   6   7   8   9   10   11   >