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 <shawj...@gmail.com> wrote: > > 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. > https://github.com/shawjef3/logging-log4j-scala/commit/dd9a5dd2d6bef80ef4f0334c2ed7043299ddbad > <https://github.com/shawjef3/logging-log4j-scala/commit/dd9a5dd2d6bef80ef4f0334c2ed7043299ddbad4> > > On Mon, Dec 16, 2019 at 11:02 PM Ralph Goers <ralph.go...@dslextreme.com> > wrote: > >> 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 <shawj...@gmail.com> wrote: >>> >>> 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 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 <ralph.go...@dslextreme.com> >>> wrote: >>> >>>> 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 >>>> 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 <ralph.go...@dslextreme.com> >>>> wrote: >>>>> >>>>> >>>>> >>>>>> On Dec 16, 2019, at 12:59 PM, Raman Gupta <rocketra...@gmail.com> >>>> 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 upgraded 2.13.0 to Java 8 we had >>>> added stuff to the API that couldn’t be implemented in Java 7. Since >> 2.13.0 >>>> is now on Java 8 a lot of the new API stuff has been back ported, so I >>>> don’t expect much difference there. >>>>> >>>>> The main driver for 3.0 was always to break it up so that core didn’t >>>> have so many optional dependencies. That dove-tailed with JPMS in Java >> 9 so >>>> that most of Log4j could be proper JPMS modules. >>>>> >>>>> I have also modified the plugin system to address problems that occur >>>> with JPMS in finding them across modules - the plugin system no longer >> has >>>> a Log4jPlugins.dat file. Instead it generates a class file containing >> the >>>> plugin definitions which is loaded by the ServiceLoader. >>>>> >>>>> So 3.0 really will be a significant change. But it should still support >>>> anything that was compiled against 2.x. >>>>> >>>>> Ralph >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >> >> >>
