Blog post

I thought you all might be interested in this - https://www.ralphgoers.com/home/why-was-log4j-2-created. I plan to write a few entries on what is new in Log4J. Ralph

Re: Thoughts on Log4j 3.0

The thing is, I am not sure this is necessary any more. Log4j 2.13.0 and master both now support a log event “builder”. You can add the StackTraceElement by calling the withLocation() method. Ralph > On Dec 16, 2019, at 9:20 PM, Jeffrey Shaw wrote: > > Ralph, I don't know how to do that

Re: Thoughts on Log4j 3.0

Ralph, I don't know how to do that either. The best I can do is link my commits. https://github.com/shawjef3/logging-log4j2/commits/message-location-release-2.x-squashed?author=shawjef3 And then the scala one has only one commit.

Re: Thoughts on Log4j 3.0

I am having trouble figuring out how to see only what you have changed. GitHub doesn’t seem to want to let me compare your branch against master at the point the branch was created. Any ideas? Ralph > On Dec 16, 2019, at 8:41 PM, Jeffrey Shaw wrote: > > Something I created but didn't push to

Re: Thoughts on Log4j 3.0

Something I created but didn't push to get included in 2 is the ability to hard code source code locations. This is useful in contexts where the compiler can provide them. For instance, Scala's macros can do it. I implemented this intending it to improve performance, since run-time stack tracing

Re: Thoughts on Log4j 3.0

I should point out that a lot of the crappy things we did with interfaces prior to Java 8 can now be undone. Some of it already has been. For example, ExtendedLogger was added so we could add new methods to the Logger interface. Those can now all be moved to the Logger interface as default

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

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

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

Re: Thoughts on Log4j 3.0

Ok, I reread the OP -- the breaking changes would be implementation details like jars and minimum JDK dependencies... I always default to using major version changes as an opportunity to standardize things like lambda interfaces, clear up old cruft such as (now) unnecessary API methods, and so

Re: Thoughts on Log4j 3.0

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? Gary On Mon, Dec 16, 2019 at 3:03 PM Gary Gregory wrote: > I'll harp

Re: Thoughts on Log4j 3.0

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 of things ;-) Gary On Mon, Dec 16, 2019 at 2:57 PM Gary

Re: Thoughts on Log4j 3.0

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? On Mon, Dec 16, 2019 at 2:53 PM Ralph Goers wrote: > > > > > On Dec 16, 2019, at 12:41 PM, Gary Gregory wrote: > > > > You cannot control "stratification" any more than

Re: Thoughts on Log4j 3.0

On Mon, Dec 16, 2019 at 1:36 PM Ralph Goers wrote: > > > > 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. > > -

Re: Thoughts on Log4j 3.0

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(...), ...) If we care a lot of about making conversion to 3.0 easier, then we can leave the old cruft in, but

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 certainly missed the proposal and discussion on

Re: Thoughts on Log4j 3.0

On Mon, Dec 16, 2019 at 1:36 PM Ralph Goers wrote: > > > > 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. > > -

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 > wrote: > >> >> >> On Mon, Dec 16, 2019 at 1:36 PM Ralph Goers > > >> wrote: >> >>> >>> On Dec 16, 2019, at 11:13

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

Re: Thoughts on Log4j 3.0

On Mon, Dec 16, 2019 at 2:48 PM Gary Gregory wrote: > > > On Mon, Dec 16, 2019 at 1:36 PM Ralph Goers > wrote: > >> >> >> > 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

Re: Thoughts on Log4j 3.0

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 unintended consequence being jar hell. Gary On Mon, Dec 16, 2019 at

Re: Thoughts on Log4j 3.0

UNSUSCRIBE El lun., 16 dic. 2019 a las 14:47, Ralph Goers () escribió: > > > > 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

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

The compiler already can’t tell the different between MessageSupplier and Supplier where used (this was a problem with Spark’s API when Java 8 came out as well). On Mon, Dec 16, 2019 at 12:36 Ralph Goers wrote: > > > > On Dec 16, 2019, at 11:13 AM, Gary Gregory > wrote: > > > > From the 10,000

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

Re: Thoughts on Log4j 3.0

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 that we cannot capture without breaking our API? Based on recent

Re: Thoughts on Log4j 3.0

I’ve used AssertJ before and really liked it. On Mon, Dec 16, 2019 at 12:10 Carter Kozak wrote: > Regarding unit tests and upgrading from junit 4 to junit 5, I've written > some automation > to ease the transition, including conversion from org.junit.Assert to the > AssertJ[1] library. >

Re: Thoughts on Log4j 3.0

>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 separately. The APIs b/w Log4j 2 and 3 are already not binary compatible

Re: Thoughts on Log4j 3.0

Regarding unit tests and upgrading from junit 4 to junit 5, I've written some automation to ease the transition, including conversion from org.junit.Assert to the AssertJ[1] library. Thisdecouples assertions from the framework, and takes advantage of tab completion for more specific tests with

Re: Thoughts on Log4j 3.0

In 3.x, we can remove a bunch of Logger methods thanks to lambda methods. I'm still working on my personal CDI-light experiment (effectively CDI minus decorators/interceptors/observers/events), though based on the amount of code it has exploded into, I'm still wondering whether or not the end

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

Re: Thoughts on Log4j 3.0

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/), I did note some things that it would be nice to change in the

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

Re: Thoughts on Log4j 3.0

On Sun, Dec 15, 2019 at 5:56 PM Ralph Goers wrote: > > > > 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

Re: Thoughts on Log4j 3.0

On Sun, Dec 15, 2019 at 5:56 PM Ralph Goers wrote: > > > > 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