You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Ralph Goers <ra...@dslextreme.com> on 2019/12/15 21:17:29 UTC
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 is one of the main reasons I believe things have been moving slow.
Now that we have moved the 2.x releases to Java 8 I am wondering if we shouldn’t make Java 11 the minimum for 3.0. It would simplify the build as we would no longer need multiple Java versions installed, we would no longer need toolchains, and we could simply move the code from the Java 9 specific modules into their respective modules and clean up that code. It would also make it much easier to implement a few other features that require Java 9+.
Obviously, if we have a minimum of Java 11 then we would need to continue to support both the main and release-2.x branches for some time to come as it is going to be quite a while before Java 8 falls out of favor.
Thoughts?
Ralph
Re: Thoughts on Log4j 3.0
Posted by Remko Popma <re...@gmail.com>.
That all makes sense to me.
Remko.
(Shameless plug) Every java main() method deserves http://picocli.info
> On Dec 16, 2019, at 6:17, Ralph Goers <ra...@dslextreme.com> wrote:
>
> 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 is one of the main reasons I believe things have been moving slow.
>
> Now that we have moved the 2.x releases to Java 8 I am wondering if we shouldn’t make Java 11 the minimum for 3.0. It would simplify the build as we would no longer need multiple Java versions installed, we would no longer need toolchains, and we could simply move the code from the Java 9 specific modules into their respective modules and clean up that code. It would also make it much easier to implement a few other features that require Java 9+.
>
> Obviously, if we have a minimum of Java 11 then we would need to continue to support both the main and release-2.x branches for some time to come as it is going to be quite a while before Java 8 falls out of favor.
>
> Thoughts?
>
> Ralph
Re: Thoughts on Log4j 3.0
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Dec 16, 2019, at 12:48 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> On Mon, Dec 16, 2019 at 1:36 PM Ralph Goers <ra...@dslextreme.com>
> 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 the this ML, I must have
> been asleep at the wheel, bummer for me. Because the API names... ugh :-(
> What would have been wrong with simply naming the API by level name, like
> info(). I don't see much precedent for "at" as a prefix.
>
> Gary
The original method name was info(). I believe it was Remko who brought up good points as to why he preferred atInfo so I changed it. You would have to search the archives for the discussion.
Ralph
Re: Thoughts on Log4j 3.0
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Dec 16, 2019, at 12:52 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> On Mon, Dec 16, 2019 at 2:48 PM Gary Gregory <garydgregory@gmail.com <ma...@gmail.com>> wrote:
>
>>
>>
>> On Mon, Dec 16, 2019 at 1:36 PM Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>>
>> wrote:
>>
>>>
>>>
>>>> On Dec 16, 2019, at 11:13 AM, Gary Gregory <ga...@gmail.com>
>>> 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 separately.
>>>
>>> No, no, no. Nobody wants more than one logging implementation active.
>>> Nobody. And so far we haven’t talked about changing the logging
>>> configuration syntax, nor do I see any reason to do that. So there is no
>>> need for a log4j3.xml.
>>>
>>
>
> You don't get to choose. Some libs use JUL, some use Log4j, some cook up
> their own thing and that's fine as long as the write log files get written
> in the right places, as users expect. Just because Log4j is on the
> classpath does not mean that all logging must go through it.
And your point is? Very few people want multiple logging configurations in their application. Finding one that doesn’t mind doesn’t mean that we shouldn’t solve for the 98% that do mind.
Ralph
Re: Thoughts on Log4j 3.0
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Dec 16, 2019 at 2:48 PM Gary Gregory <ga...@gmail.com> wrote:
>
>
> On Mon, Dec 16, 2019 at 1:36 PM Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>>
>>
>> > On Dec 16, 2019, at 11:13 AM, Gary Gregory <ga...@gmail.com>
>> 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 separately.
>>
>> No, no, no. Nobody wants more than one logging implementation active.
>> Nobody. And so far we haven’t talked about changing the logging
>> configuration syntax, nor do I see any reason to do that. So there is no
>> need for a log4j3.xml.
>>
>
You don't get to choose. Some libs use JUL, some use Log4j, some cook up
their own thing and that's fine as long as the write log files get written
in the right places, as users expect. Just because Log4j is on the
classpath does not mean that all logging must go through it.
Gary
>
>> If we go down that road you will just piss off users and have them switch
>> to other logging choices.
>>
>>
>> >
>> > The APIs b/w Log4j 2 and 3 are already not binary compatible WRT to
>> > appenders at least, I know I've removed deprecated methods, not sure
>> about
>> > the log4j-api module.
>>
>> There is a big difference between the API and implementation. While we
>> should make every attempt to allow Plugins written for 2.x to continue to
>> work against 3.x we can require that plugins may have to be modified to
>> compile against 3.x. That is the route I have been taking with all the
>> changes I have made, including the changes I made to the plugin system
>> itself. Of course, we will need to verify that 2.x plugins actually run
>> with 3.x and fix any bugs we find.
>>
>>
>> >
>> > IMO: A major version let's us break things and provide a better API,
>> > otherwise, we can keep on the 2.x branch.
>>
>> Yes, we can improve the API, but code compiled against 2.x still needs to
>> run against 3.x. While we can break things inside the implementation we
>> should avoid breaking the API. Otherwise our users will hate us. You have
>> to remember how much code there is out there that uses the API. If you
>> make it incompatible you are just giving users a reason to use SLF4J.
>>
>> If you want an improved API you can create a new interface, but users
>> probably won’t love that either.
>>
>>
>> >
>> > For example, this API and all like it should be gone from 3.0:
>> >
>> > org.apache.logging.log4j.Logger.debug(Marker,
>> > org.apache.logging.log4j.util.Supplier<?>)
>> >
>> > and replaced with:
>> >
>> > org.apache.logging.log4j.Logger.debug(Marker,
>> > java.util.function.Supplier<T><?>)
>>
>> Why? A user coding a Lambda doesn’t care what the underlying class is.
>> Only people actually coding to that interface (nobody?) would care.
>>
>>
>> >
>> > Everywhere we have org.apache.logging.log4j.util.Supplier in 2.0,
>> should be
>> > replaced by java.util.function.Supplier in 3.0.
>>
>> -1 unless you can give me some benefit to doing that besides - “it is the
>> standard Java interface”.
>>
>>
>> >
>> > In fact, we could (should IMO), now that we are on Java 8, in 2.14.0,
>> add
>> > java.util.function.Supplier version of all methods and _deprecate_ all
>> > org.apache.logging.log4j.util.Supplier methods.
>>
>> Umm, I am doubtful you can do that. I’d be surprised if the compiler can
>> figure out which one to use when it is compiling a lambda.
>>
>> >
>> > We can also explore other kinds of logging APIs. One maybe goofy example
>> > was my attempt a long time ago maybe even still in some branch of having
>> > log methods on levels so you can say "Level.DEBUG.log(levellogger, ...)"
>> > which I did to avoid the explosion of methods on Logger whenever you
>> want
>> > to add a new API (you need to duplicate it for debug, info, warn, and so
>> > on.)
>>
>> 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 the this ML, I must have
> been asleep at the wheel, bummer for me. Because the API names... ugh :-(
> What would have been wrong with simply naming the API by level name, like
> info(). I don't see much precedent for "at" as a prefix.
>
> Gary
>
>
>>
>> Ralph
>>
>
Re: Thoughts on Log4j 3.0
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Dec 16, 2019, at 1:06 PM, Gary Gregory <ga...@gmail.com> 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 should not be overridden. Putting it in a package named internal gives an indication of that. Putting it in the spi package is not a good idea as that package will be exported in the module.info <http://module.info/>.
Ralph
Re: Thoughts on Log4j 3.0
Posted by Gary Gregory <ga...@gmail.com>.
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 <ga...@gmail.com> 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 of things ;-)
>
> Gary
>
> On Mon, Dec 16, 2019 at 2:57 PM Gary Gregory <ga...@gmail.com>
> 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(...), ...)
>>
>> If we care a lot of about making conversion to 3.0 easier, then we can
>> leave the old cruft in, but offer a new Logger interface that does not
>> contain the old stuff. We or at least I've heard the complaint in the past
>> on the size of Logger (Ctrl-space and boom! So many choices!), this would
>> really clean things up (for my definition of "clean" of course :-)
>>
>> Gary
>>
>> On Mon, Dec 16, 2019 at 2:48 PM Gary Gregory <ga...@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Mon, Dec 16, 2019 at 1:36 PM Ralph Goers <ra...@dslextreme.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> > On Dec 16, 2019, at 11:13 AM, Gary Gregory <ga...@gmail.com>
>>>> 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 separately.
>>>>
>>>> No, no, no. Nobody wants more than one logging implementation active.
>>>> Nobody. And so far we haven’t talked about changing the logging
>>>> configuration syntax, nor do I see any reason to do that. So there is no
>>>> need for a log4j3.xml.
>>>>
>>>> If we go down that road you will just piss off users and have them
>>>> switch to other logging choices.
>>>>
>>>>
>>>> >
>>>> > The APIs b/w Log4j 2 and 3 are already not binary compatible WRT to
>>>> > appenders at least, I know I've removed deprecated methods, not sure
>>>> about
>>>> > the log4j-api module.
>>>>
>>>> There is a big difference between the API and implementation. While we
>>>> should make every attempt to allow Plugins written for 2.x to continue to
>>>> work against 3.x we can require that plugins may have to be modified to
>>>> compile against 3.x. That is the route I have been taking with all the
>>>> changes I have made, including the changes I made to the plugin system
>>>> itself. Of course, we will need to verify that 2.x plugins actually run
>>>> with 3.x and fix any bugs we find.
>>>>
>>>>
>>>> >
>>>> > IMO: A major version let's us break things and provide a better API,
>>>> > otherwise, we can keep on the 2.x branch.
>>>>
>>>> Yes, we can improve the API, but code compiled against 2.x still needs
>>>> to run against 3.x. While we can break things inside the implementation we
>>>> should avoid breaking the API. Otherwise our users will hate us. You have
>>>> to remember how much code there is out there that uses the API. If you
>>>> make it incompatible you are just giving users a reason to use SLF4J.
>>>>
>>>> If you want an improved API you can create a new interface, but users
>>>> probably won’t love that either.
>>>>
>>>>
>>>> >
>>>> > For example, this API and all like it should be gone from 3.0:
>>>> >
>>>> > org.apache.logging.log4j.Logger.debug(Marker,
>>>> > org.apache.logging.log4j.util.Supplier<?>)
>>>> >
>>>> > and replaced with:
>>>> >
>>>> > org.apache.logging.log4j.Logger.debug(Marker,
>>>> > java.util.function.Supplier<T><?>)
>>>>
>>>> Why? A user coding a Lambda doesn’t care what the underlying class is.
>>>> Only people actually coding to that interface (nobody?) would care.
>>>>
>>>>
>>>> >
>>>> > Everywhere we have org.apache.logging.log4j.util.Supplier in 2.0,
>>>> should be
>>>> > replaced by java.util.function.Supplier in 3.0.
>>>>
>>>> -1 unless you can give me some benefit to doing that besides - “it is
>>>> the standard Java interface”.
>>>>
>>>>
>>>> >
>>>> > In fact, we could (should IMO), now that we are on Java 8, in 2.14.0,
>>>> add
>>>> > java.util.function.Supplier version of all methods and _deprecate_ all
>>>> > org.apache.logging.log4j.util.Supplier methods.
>>>>
>>>> Umm, I am doubtful you can do that. I’d be surprised if the compiler
>>>> can figure out which one to use when it is compiling a lambda.
>>>>
>>>> >
>>>> > We can also explore other kinds of logging APIs. One maybe goofy
>>>> example
>>>> > was my attempt a long time ago maybe even still in some branch of
>>>> having
>>>> > log methods on levels so you can say "Level.DEBUG.log(levellogger,
>>>> ...)"
>>>> > which I did to avoid the explosion of methods on Logger whenever you
>>>> want
>>>> > to add a new API (you need to duplicate it for debug, info, warn, and
>>>> so
>>>> > on.)
>>>>
>>>> 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 the this ML, I must
>>> have been asleep at the wheel, bummer for me. Because the API names... ugh
>>> :-( What would have been wrong with simply naming the API by level name,
>>> like info(). I don't see much precedent for "at" as a prefix.
>>>
>>> Gary
>>>
>>>
>>>>
>>>> Ralph
>>>>
>>>
Re: Thoughts on Log4j 3.0
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Dec 16, 2019, at 1:03 PM, Gary Gregory <ga...@gmail.com> 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 of things ;-)
Not just discussing. ;-) I’m guessing that more than 25% of your commits have comments like “Better ivar name”.
Ralph
Re: Thoughts on Log4j 3.0
Posted by Gary Gregory <ga...@gmail.com>.
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 Gregory <ga...@gmail.com> 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(...), ...)
>
> If we care a lot of about making conversion to 3.0 easier, then we can
> leave the old cruft in, but offer a new Logger interface that does not
> contain the old stuff. We or at least I've heard the complaint in the past
> on the size of Logger (Ctrl-space and boom! So many choices!), this would
> really clean things up (for my definition of "clean" of course :-)
>
> Gary
>
> On Mon, Dec 16, 2019 at 2:48 PM Gary Gregory <ga...@gmail.com>
> wrote:
>
>>
>>
>> On Mon, Dec 16, 2019 at 1:36 PM Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>
>>>
>>>
>>> > On Dec 16, 2019, at 11:13 AM, Gary Gregory <ga...@gmail.com>
>>> 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 separately.
>>>
>>> No, no, no. Nobody wants more than one logging implementation active.
>>> Nobody. And so far we haven’t talked about changing the logging
>>> configuration syntax, nor do I see any reason to do that. So there is no
>>> need for a log4j3.xml.
>>>
>>> If we go down that road you will just piss off users and have them
>>> switch to other logging choices.
>>>
>>>
>>> >
>>> > The APIs b/w Log4j 2 and 3 are already not binary compatible WRT to
>>> > appenders at least, I know I've removed deprecated methods, not sure
>>> about
>>> > the log4j-api module.
>>>
>>> There is a big difference between the API and implementation. While we
>>> should make every attempt to allow Plugins written for 2.x to continue to
>>> work against 3.x we can require that plugins may have to be modified to
>>> compile against 3.x. That is the route I have been taking with all the
>>> changes I have made, including the changes I made to the plugin system
>>> itself. Of course, we will need to verify that 2.x plugins actually run
>>> with 3.x and fix any bugs we find.
>>>
>>>
>>> >
>>> > IMO: A major version let's us break things and provide a better API,
>>> > otherwise, we can keep on the 2.x branch.
>>>
>>> Yes, we can improve the API, but code compiled against 2.x still needs
>>> to run against 3.x. While we can break things inside the implementation we
>>> should avoid breaking the API. Otherwise our users will hate us. You have
>>> to remember how much code there is out there that uses the API. If you
>>> make it incompatible you are just giving users a reason to use SLF4J.
>>>
>>> If you want an improved API you can create a new interface, but users
>>> probably won’t love that either.
>>>
>>>
>>> >
>>> > For example, this API and all like it should be gone from 3.0:
>>> >
>>> > org.apache.logging.log4j.Logger.debug(Marker,
>>> > org.apache.logging.log4j.util.Supplier<?>)
>>> >
>>> > and replaced with:
>>> >
>>> > org.apache.logging.log4j.Logger.debug(Marker,
>>> > java.util.function.Supplier<T><?>)
>>>
>>> Why? A user coding a Lambda doesn’t care what the underlying class is.
>>> Only people actually coding to that interface (nobody?) would care.
>>>
>>>
>>> >
>>> > Everywhere we have org.apache.logging.log4j.util.Supplier in 2.0,
>>> should be
>>> > replaced by java.util.function.Supplier in 3.0.
>>>
>>> -1 unless you can give me some benefit to doing that besides - “it is
>>> the standard Java interface”.
>>>
>>>
>>> >
>>> > In fact, we could (should IMO), now that we are on Java 8, in 2.14.0,
>>> add
>>> > java.util.function.Supplier version of all methods and _deprecate_ all
>>> > org.apache.logging.log4j.util.Supplier methods.
>>>
>>> Umm, I am doubtful you can do that. I’d be surprised if the compiler
>>> can figure out which one to use when it is compiling a lambda.
>>>
>>> >
>>> > We can also explore other kinds of logging APIs. One maybe goofy
>>> example
>>> > was my attempt a long time ago maybe even still in some branch of
>>> having
>>> > log methods on levels so you can say "Level.DEBUG.log(levellogger,
>>> ...)"
>>> > which I did to avoid the explosion of methods on Logger whenever you
>>> want
>>> > to add a new API (you need to duplicate it for debug, info, warn, and
>>> so
>>> > on.)
>>>
>>> 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 the this ML, I must
>> have been asleep at the wheel, bummer for me. Because the API names... ugh
>> :-( What would have been wrong with simply naming the API by level name,
>> like info(). I don't see much precedent for "at" as a prefix.
>>
>> Gary
>>
>>
>>>
>>> Ralph
>>>
>>
Re: Thoughts on Log4j 3.0
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Dec 16, 2019, at 12:57 PM, Gary Gregory <ga...@gmail.com> 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 use the current API.
>
> If we care a lot of about making conversion to 3.0 easier, then we can
> leave the old cruft in, but offer a new Logger interface that does not
> contain the old stuff. We or at least I've heard the complaint in the past
> on the size of Logger (Ctrl-space and boom! So many choices!), this would
> really clean things up (for my definition of "clean" of course :-)
Feel free but don’t call it Logger2 or BetterLogger or AdvancedLogger, etc.
Ralph
Re: Thoughts on Log4j 3.0
Posted by Gary Gregory <ga...@gmail.com>.
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 offer a new Logger interface that does not
contain the old stuff. We or at least I've heard the complaint in the past
on the size of Logger (Ctrl-space and boom! So many choices!), this would
really clean things up (for my definition of "clean" of course :-)
Gary
On Mon, Dec 16, 2019 at 2:48 PM Gary Gregory <ga...@gmail.com> wrote:
>
>
> On Mon, Dec 16, 2019 at 1:36 PM Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>>
>>
>> > On Dec 16, 2019, at 11:13 AM, Gary Gregory <ga...@gmail.com>
>> 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 separately.
>>
>> No, no, no. Nobody wants more than one logging implementation active.
>> Nobody. And so far we haven’t talked about changing the logging
>> configuration syntax, nor do I see any reason to do that. So there is no
>> need for a log4j3.xml.
>>
>> If we go down that road you will just piss off users and have them switch
>> to other logging choices.
>>
>>
>> >
>> > The APIs b/w Log4j 2 and 3 are already not binary compatible WRT to
>> > appenders at least, I know I've removed deprecated methods, not sure
>> about
>> > the log4j-api module.
>>
>> There is a big difference between the API and implementation. While we
>> should make every attempt to allow Plugins written for 2.x to continue to
>> work against 3.x we can require that plugins may have to be modified to
>> compile against 3.x. That is the route I have been taking with all the
>> changes I have made, including the changes I made to the plugin system
>> itself. Of course, we will need to verify that 2.x plugins actually run
>> with 3.x and fix any bugs we find.
>>
>>
>> >
>> > IMO: A major version let's us break things and provide a better API,
>> > otherwise, we can keep on the 2.x branch.
>>
>> Yes, we can improve the API, but code compiled against 2.x still needs to
>> run against 3.x. While we can break things inside the implementation we
>> should avoid breaking the API. Otherwise our users will hate us. You have
>> to remember how much code there is out there that uses the API. If you
>> make it incompatible you are just giving users a reason to use SLF4J.
>>
>> If you want an improved API you can create a new interface, but users
>> probably won’t love that either.
>>
>>
>> >
>> > For example, this API and all like it should be gone from 3.0:
>> >
>> > org.apache.logging.log4j.Logger.debug(Marker,
>> > org.apache.logging.log4j.util.Supplier<?>)
>> >
>> > and replaced with:
>> >
>> > org.apache.logging.log4j.Logger.debug(Marker,
>> > java.util.function.Supplier<T><?>)
>>
>> Why? A user coding a Lambda doesn’t care what the underlying class is.
>> Only people actually coding to that interface (nobody?) would care.
>>
>>
>> >
>> > Everywhere we have org.apache.logging.log4j.util.Supplier in 2.0,
>> should be
>> > replaced by java.util.function.Supplier in 3.0.
>>
>> -1 unless you can give me some benefit to doing that besides - “it is the
>> standard Java interface”.
>>
>>
>> >
>> > In fact, we could (should IMO), now that we are on Java 8, in 2.14.0,
>> add
>> > java.util.function.Supplier version of all methods and _deprecate_ all
>> > org.apache.logging.log4j.util.Supplier methods.
>>
>> Umm, I am doubtful you can do that. I’d be surprised if the compiler can
>> figure out which one to use when it is compiling a lambda.
>>
>> >
>> > We can also explore other kinds of logging APIs. One maybe goofy example
>> > was my attempt a long time ago maybe even still in some branch of having
>> > log methods on levels so you can say "Level.DEBUG.log(levellogger, ...)"
>> > which I did to avoid the explosion of methods on Logger whenever you
>> want
>> > to add a new API (you need to duplicate it for debug, info, warn, and so
>> > on.)
>>
>> 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 the this ML, I must have
> been asleep at the wheel, bummer for me. Because the API names... ugh :-(
> What would have been wrong with simply naming the API by level name, like
> info(). I don't see much precedent for "at" as a prefix.
>
> Gary
>
>
>>
>> Ralph
>>
>
Re: Thoughts on Log4j 3.0
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Dec 16, 2019 at 1:36 PM Ralph Goers <ra...@dslextreme.com>
wrote:
>
>
> > On Dec 16, 2019, at 11:13 AM, Gary Gregory <ga...@gmail.com>
> 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 separately.
>
> No, no, no. Nobody wants more than one logging implementation active.
> Nobody. And so far we haven’t talked about changing the logging
> configuration syntax, nor do I see any reason to do that. So there is no
> need for a log4j3.xml.
>
> If we go down that road you will just piss off users and have them switch
> to other logging choices.
>
>
> >
> > The APIs b/w Log4j 2 and 3 are already not binary compatible WRT to
> > appenders at least, I know I've removed deprecated methods, not sure
> about
> > the log4j-api module.
>
> There is a big difference between the API and implementation. While we
> should make every attempt to allow Plugins written for 2.x to continue to
> work against 3.x we can require that plugins may have to be modified to
> compile against 3.x. That is the route I have been taking with all the
> changes I have made, including the changes I made to the plugin system
> itself. Of course, we will need to verify that 2.x plugins actually run
> with 3.x and fix any bugs we find.
>
>
> >
> > IMO: A major version let's us break things and provide a better API,
> > otherwise, we can keep on the 2.x branch.
>
> Yes, we can improve the API, but code compiled against 2.x still needs to
> run against 3.x. While we can break things inside the implementation we
> should avoid breaking the API. Otherwise our users will hate us. You have
> to remember how much code there is out there that uses the API. If you
> make it incompatible you are just giving users a reason to use SLF4J.
>
> If you want an improved API you can create a new interface, but users
> probably won’t love that either.
>
>
> >
> > For example, this API and all like it should be gone from 3.0:
> >
> > org.apache.logging.log4j.Logger.debug(Marker,
> > org.apache.logging.log4j.util.Supplier<?>)
> >
> > and replaced with:
> >
> > org.apache.logging.log4j.Logger.debug(Marker,
> > java.util.function.Supplier<T><?>)
>
> Why? A user coding a Lambda doesn’t care what the underlying class is.
> Only people actually coding to that interface (nobody?) would care.
>
>
> >
> > Everywhere we have org.apache.logging.log4j.util.Supplier in 2.0, should
> be
> > replaced by java.util.function.Supplier in 3.0.
>
> -1 unless you can give me some benefit to doing that besides - “it is the
> standard Java interface”.
>
>
> >
> > In fact, we could (should IMO), now that we are on Java 8, in 2.14.0, add
> > java.util.function.Supplier version of all methods and _deprecate_ all
> > org.apache.logging.log4j.util.Supplier methods.
>
> Umm, I am doubtful you can do that. I’d be surprised if the compiler can
> figure out which one to use when it is compiling a lambda.
>
> >
> > We can also explore other kinds of logging APIs. One maybe goofy example
> > was my attempt a long time ago maybe even still in some branch of having
> > log methods on levels so you can say "Level.DEBUG.log(levellogger, ...)"
> > which I did to avoid the explosion of methods on Logger whenever you want
> > to add a new API (you need to duplicate it for debug, info, warn, and so
> > on.)
>
> 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 the this ML, I must have
been asleep at the wheel, bummer for me. Because the API names... ugh :-(
What would have been wrong with simply naming the API by level name, like
info(). I don't see much precedent for "at" as a prefix.
Gary
>
> Ralph
>
Re: Thoughts on Log4j 3.0
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Dec 16, 2019 at 1:36 PM Ralph Goers <ra...@dslextreme.com>
wrote:
>
>
> > On Dec 16, 2019, at 11:13 AM, Gary Gregory <ga...@gmail.com>
> 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 separately.
>
> No, no, no. Nobody wants more than one logging implementation active.
> Nobody. And so far we haven’t talked about changing the logging
> configuration syntax, nor do I see any reason to do that. So there is no
> need for a log4j3.xml.
>
> If we go down that road you will just piss off users and have them switch
> to other logging choices.
>
>
> >
> > The APIs b/w Log4j 2 and 3 are already not binary compatible WRT to
> > appenders at least, I know I've removed deprecated methods, not sure
> about
> > the log4j-api module.
>
> There is a big difference between the API and implementation. While we
> should make every attempt to allow Plugins written for 2.x to continue to
> work against 3.x we can require that plugins may have to be modified to
> compile against 3.x. That is the route I have been taking with all the
> changes I have made, including the changes I made to the plugin system
> itself. Of course, we will need to verify that 2.x plugins actually run
> with 3.x and fix any bugs we find.
>
>
> >
> > IMO: A major version let's us break things and provide a better API,
> > otherwise, we can keep on the 2.x branch.
>
> Yes, we can improve the API, but code compiled against 2.x still needs to
> run against 3.x. While we can break things inside the implementation we
> should avoid breaking the API. Otherwise our users will hate us. You have
> to remember how much code there is out there that uses the API. If you
> make it incompatible you are just giving users a reason to use SLF4J.
>
> If you want an improved API you can create a new interface, but users
> probably won’t love that either.
>
>
> >
> > For example, this API and all like it should be gone from 3.0:
> >
> > org.apache.logging.log4j.Logger.debug(Marker,
> > org.apache.logging.log4j.util.Supplier<?>)
> >
> > and replaced with:
> >
> > org.apache.logging.log4j.Logger.debug(Marker,
> > java.util.function.Supplier<T><?>)
>
> Why? A user coding a Lambda doesn’t care what the underlying class is.
> Only people actually coding to that interface (nobody?) would care.
>
>
> >
> > Everywhere we have org.apache.logging.log4j.util.Supplier in 2.0, should
> be
> > replaced by java.util.function.Supplier in 3.0.
>
> -1 unless you can give me some benefit to doing that besides - “it is the
> standard Java interface”.
>
>
> >
> > In fact, we could (should IMO), now that we are on Java 8, in 2.14.0, add
> > java.util.function.Supplier version of all methods and _deprecate_ all
> > org.apache.logging.log4j.util.Supplier methods.
>
> Umm, I am doubtful you can do that. I’d be surprised if the compiler can
> figure out which one to use when it is compiling a lambda.
>
> >
> > We can also explore other kinds of logging APIs. One maybe goofy example
> > was my attempt a long time ago maybe even still in some branch of having
> > log methods on levels so you can say "Level.DEBUG.log(levellogger, ...)"
> > which I did to avoid the explosion of methods on Logger whenever you want
> > to add a new API (you need to duplicate it for debug, info, warn, and so
> > on.)
>
> We just added that in 2.13.0. Did you miss that?
>
Yes I must have as I do not see log methods
in org.apache.logging.log4j.Level. Where should I look?
Gary
>
> Ralph
>
Re: Thoughts on Log4j 3.0
Posted by Matt Sicker <bo...@gmail.com>.
The compiler already can’t tell the different between MessageSupplier and
Supplier<Message> 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 <ra...@dslextreme.com>
wrote:
>
>
> > On Dec 16, 2019, at 11:13 AM, Gary Gregory <ga...@gmail.com>
> 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 separately.
>
> No, no, no. Nobody wants more than one logging implementation active.
> Nobody. And so far we haven’t talked about changing the logging
> configuration syntax, nor do I see any reason to do that. So there is no
> need for a log4j3.xml.
>
> If we go down that road you will just piss off users and have them switch
> to other logging choices.
>
>
> >
> > The APIs b/w Log4j 2 and 3 are already not binary compatible WRT to
> > appenders at least, I know I've removed deprecated methods, not sure
> about
> > the log4j-api module.
>
> There is a big difference between the API and implementation. While we
> should make every attempt to allow Plugins written for 2.x to continue to
> work against 3.x we can require that plugins may have to be modified to
> compile against 3.x. That is the route I have been taking with all the
> changes I have made, including the changes I made to the plugin system
> itself. Of course, we will need to verify that 2.x plugins actually run
> with 3.x and fix any bugs we find.
>
>
> >
> > IMO: A major version let's us break things and provide a better API,
> > otherwise, we can keep on the 2.x branch.
>
> Yes, we can improve the API, but code compiled against 2.x still needs to
> run against 3.x. While we can break things inside the implementation we
> should avoid breaking the API. Otherwise our users will hate us. You have
> to remember how much code there is out there that uses the API. If you
> make it incompatible you are just giving users a reason to use SLF4J.
>
> If you want an improved API you can create a new interface, but users
> probably won’t love that either.
>
>
> >
> > For example, this API and all like it should be gone from 3.0:
> >
> > org.apache.logging.log4j.Logger.debug(Marker,
> > org.apache.logging.log4j.util.Supplier<?>)
> >
> > and replaced with:
> >
> > org.apache.logging.log4j.Logger.debug(Marker,
> > java.util.function.Supplier<T><?>)
>
> Why? A user coding a Lambda doesn’t care what the underlying class is.
> Only people actually coding to that interface (nobody?) would care.
>
>
> >
> > Everywhere we have org.apache.logging.log4j.util.Supplier in 2.0, should
> be
> > replaced by java.util.function.Supplier in 3.0.
>
> -1 unless you can give me some benefit to doing that besides - “it is the
> standard Java interface”.
>
>
> >
> > In fact, we could (should IMO), now that we are on Java 8, in 2.14.0, add
> > java.util.function.Supplier version of all methods and _deprecate_ all
> > org.apache.logging.log4j.util.Supplier methods.
>
> Umm, I am doubtful you can do that. I’d be surprised if the compiler can
> figure out which one to use when it is compiling a lambda.
>
> >
> > We can also explore other kinds of logging APIs. One maybe goofy example
> > was my attempt a long time ago maybe even still in some branch of having
> > log methods on levels so you can say "Level.DEBUG.log(levellogger, ...)"
> > which I did to avoid the explosion of methods on Logger whenever you want
> > to add a new API (you need to duplicate it for debug, info, warn, and so
> > on.)
>
> We just added that in 2.13.0. Did you miss that?
>
> Ralph
>
--
Matt Sicker <bo...@gmail.com>
Re: Thoughts on Log4j 3.0
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Dec 16, 2019, at 11:13 AM, Gary Gregory <ga...@gmail.com> 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 separately.
No, no, no. Nobody wants more than one logging implementation active. Nobody. And so far we haven’t talked about changing the logging configuration syntax, nor do I see any reason to do that. So there is no need for a log4j3.xml.
If we go down that road you will just piss off users and have them switch to other logging choices.
>
> The APIs b/w Log4j 2 and 3 are already not binary compatible WRT to
> appenders at least, I know I've removed deprecated methods, not sure about
> the log4j-api module.
There is a big difference between the API and implementation. While we should make every attempt to allow Plugins written for 2.x to continue to work against 3.x we can require that plugins may have to be modified to compile against 3.x. That is the route I have been taking with all the changes I have made, including the changes I made to the plugin system itself. Of course, we will need to verify that 2.x plugins actually run with 3.x and fix any bugs we find.
>
> IMO: A major version let's us break things and provide a better API,
> otherwise, we can keep on the 2.x branch.
Yes, we can improve the API, but code compiled against 2.x still needs to run against 3.x. While we can break things inside the implementation we should avoid breaking the API. Otherwise our users will hate us. You have to remember how much code there is out there that uses the API. If you make it incompatible you are just giving users a reason to use SLF4J.
If you want an improved API you can create a new interface, but users probably won’t love that either.
>
> For example, this API and all like it should be gone from 3.0:
>
> org.apache.logging.log4j.Logger.debug(Marker,
> org.apache.logging.log4j.util.Supplier<?>)
>
> and replaced with:
>
> org.apache.logging.log4j.Logger.debug(Marker,
> java.util.function.Supplier<T><?>)
Why? A user coding a Lambda doesn’t care what the underlying class is. Only people actually coding to that interface (nobody?) would care.
>
> Everywhere we have org.apache.logging.log4j.util.Supplier in 2.0, should be
> replaced by java.util.function.Supplier in 3.0.
-1 unless you can give me some benefit to doing that besides - “it is the standard Java interface”.
>
> In fact, we could (should IMO), now that we are on Java 8, in 2.14.0, add
> java.util.function.Supplier version of all methods and _deprecate_ all
> org.apache.logging.log4j.util.Supplier methods.
Umm, I am doubtful you can do that. I’d be surprised if the compiler can figure out which one to use when it is compiling a lambda.
>
> We can also explore other kinds of logging APIs. One maybe goofy example
> was my attempt a long time ago maybe even still in some branch of having
> log methods on levels so you can say "Level.DEBUG.log(levellogger, ...)"
> which I did to avoid the explosion of methods on Logger whenever you want
> to add a new API (you need to duplicate it for debug, info, warn, and so
> on.)
We just added that in 2.13.0. Did you miss that?
Ralph
Re: Thoughts on Log4j 3.0
Posted by Raman Gupta <ro...@gmail.com>.
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 forth. However, for a project as
widely used as log4j2, I can see how the equation is a bit different,
and agree that maintaining API compat has compelling advantages.
Regards,
Raman
On Mon, Dec 16, 2019 at 2:59 PM Raman Gupta <ro...@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?
>
> On Mon, Dec 16, 2019 at 2:53 PM Ralph Goers <ra...@dslextreme.com> wrote:
> >
> >
> >
> > > On Dec 16, 2019, at 12:41 PM, Gary Gregory <ga...@gmail.com> 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 unintended consequence being jar hell.
> > >
> >
> > I don’t get the point of this message. There are certainly things we cannot control and things we can control. Backwards compatibility of our code is one of the things we can control.
> >
> > Ralph
> >
> >
Re: Thoughts on Log4j 3.0
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <sh...@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 <ra...@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 <sh...@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 <ra...@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 <ra...@dslextreme.com>
>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On Dec 16, 2019, at 12:59 PM, Raman Gupta <ro...@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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
Re: Thoughts on Log4j 3.0
Posted by Jeffrey Shaw <sh...@gmail.com>.
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 <ra...@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 <sh...@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 <ra...@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 <ra...@dslextreme.com>
> >> wrote:
> >>>
> >>>
> >>>
> >>>> On Dec 16, 2019, at 12:59 PM, Raman Gupta <ro...@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
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
>
>
>
Re: Thoughts on Log4j 3.0
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <sh...@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 <ra...@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 <ra...@dslextreme.com>
>> wrote:
>>>
>>>
>>>
>>>> On Dec 16, 2019, at 12:59 PM, Raman Gupta <ro...@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
>>>
>>>
>>>
>>>
>>
>>
>>
Re: Thoughts on Log4j 3.0
Posted by Jeffrey Shaw <sh...@gmail.com>.
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 <ra...@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 <ra...@dslextreme.com>
> wrote:
> >
> >
> >
> >> On Dec 16, 2019, at 12:59 PM, Raman Gupta <ro...@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
> >
> >
> >
> >
>
>
>
Re: Thoughts on Log4j 3.0
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ra...@dslextreme.com> wrote:
>
>
>
>> On Dec 16, 2019, at 12:59 PM, Raman Gupta <ro...@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
>
>
>
>
Re: Thoughts on Log4j 3.0
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Dec 16, 2019, at 12:59 PM, Raman Gupta <ro...@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
Re: Thoughts on Log4j 3.0
Posted by Raman Gupta <ro...@gmail.com>.
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 <ra...@dslextreme.com> wrote:
>
>
>
> > On Dec 16, 2019, at 12:41 PM, Gary Gregory <ga...@gmail.com> 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 unintended consequence being jar hell.
> >
>
> I don’t get the point of this message. There are certainly things we cannot control and things we can control. Backwards compatibility of our code is one of the things we can control.
>
> Ralph
>
>
Re: Thoughts on Log4j 3.0
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Dec 16, 2019, at 12:41 PM, Gary Gregory <ga...@gmail.com> 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 unintended consequence being jar hell.
>
I don’t get the point of this message. There are certainly things we cannot control and things we can control. Backwards compatibility of our code is one of the things we can control.
Ralph
Re: Thoughts on Log4j 3.0
Posted by Gary Gregory <ga...@gmail.com>.
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 1:32 PM Carter Kozak <ck...@ckozak.net> 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 that we cannot capture without breaking our API? Based on recent
> dev list traffic, we still have consumers on log4j 1.2, it would be great
> if we could avoid similar stratification as we move forward. The value
> proposition moving from log4j1.2 to log4j2 is substantial, we support
> orders of magnitude higher throughput and eliminated entire classes of bugs
> through the new architecture/threading model, and that hasn't been enough
> to push many consumers to upgrade from 1.2. I suppose my question is: If we
> break API and release a major revision, how do we make sure it's worth it?
>
> -ck
>
> On Mon, Dec 16, 2019, at 13:13, 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 separately.
> >
> > The APIs b/w Log4j 2 and 3 are already not binary compatible WRT to
> > appenders at least, I know I've removed deprecated methods, not sure
> about
> > the log4j-api module.
> >
> > IMO: A major version let's us break things and provide a better API,
> > otherwise, we can keep on the 2.x branch.
> >
> > For example, this API and all like it should be gone from 3.0:
> >
> > org.apache.logging.log4j.Logger.debug(Marker,
> > org.apache.logging.log4j.util.Supplier<?>)
> >
> > and replaced with:
> >
> > org.apache.logging.log4j.Logger.debug(Marker,
> > java.util.function.Supplier<T><?>)
> >
> > Everywhere we have org.apache.logging.log4j.util.Supplier in 2.0, should
> be
> > replaced by java.util.function.Supplier in 3.0.
> >
> > In fact, we could (should IMO), now that we are on Java 8, in 2.14.0, add
> > java.util.function.Supplier version of all methods and _deprecate_ all
> > org.apache.logging.log4j.util.Supplier methods.
> >
> > We can also explore other kinds of logging APIs. One maybe goofy example
> > was my attempt a long time ago maybe even still in some branch of having
> > log methods on levels so you can say "Level.DEBUG.log(levellogger, ...)"
> > which I did to avoid the explosion of methods on Logger whenever you want
> > to add a new API (you need to duplicate it for debug, info, warn, and so
> > on.)
> >
> > Gary
> >
> > On Mon, Dec 16, 2019 at 12:03 PM Ralph Goers <ralph.goers@dslextreme.com
> >
> > wrote:
> >
> > >
> > >
> > > > On Dec 16, 2019, at 9:42 AM, Raman Gupta <ro...@gmail.com>
> 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/), I did
> > > > note some things that it would be nice to change in the API -- see
> > > >
> > >
> https://github.com/apache/logging-log4j-kotlin/blob/master/log4j-api-kotlin/src/main/kotlin/org/apache/logging/log4j/kotlin/KotlinLogger.kt#L51-L64
> > > .
> > > >
> > > > That being said, to make a wider point, if 3.0 is gonna by JDK11+, we
> > > > could consider promoting lambda-based logging, like the Kotlin logger
> > > > does, as a first-class log4j3 API. The advantage of a lambda-based
> > > > logger is no more need for callers to do if-logger-level-enabled
> > > > checks or to use the messy parameterized methods.
> > > >
> > > > Regards,
> > > > Raman
> > >
> > >
> > > Thanks for the input.
> > >
> > > The current log4j 2 API already supports lambdas. Are you proposing
> that
> > > we do something different? What would that look like?
> > >
> > > FWIW, the idea that we would have to bridge the Log4j 2 API to a Log4j
> 3
> > > implementation doesn’t make sense to me. I would think that would annoy
> > > users. The Log4j 3 implementation needs to work with the Log4j 2 API.
> The
> > > problem Gary is highlighting is that having both the jars for the
> Log4j 2
> > > API and Log4j 3 API would mean the package structure would need to be
> > > different between them.
> > >
> > > Instead, I would prefer that the Log4j 3 API be backward compatible
> with
> > > the Log4j 2 API.
> > >
> > > Ralph
> > >
> >
>
Re: Thoughts on Log4j 3.0
Posted by Javier Sanchez <jf...@gmail.com>.
UNSUSCRIBE
El lun., 16 dic. 2019 a las 14:47, Ralph Goers (<ra...@dslextreme.com>)
escribió:
>
>
> > On Dec 16, 2019, at 11:32 AM, Carter Kozak <ck...@ckozak.net> 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 that we cannot capture without breaking our API? Based on recent
> dev list traffic, we still have consumers on log4j 1.2, it would be great
> if we could avoid similar stratification as we move forward. The value
> proposition moving from log4j1.2 to log4j2 is substantial, we support
> orders of magnitude higher throughput and eliminated entire classes of bugs
> through the new architecture/threading model, and that hasn't been enough
> to push many consumers to upgrade from 1.2. I suppose my question is: If we
> break API and release a major revision, how do we make sure it's worth it?
> >
>
> I don’t believe you can. The stuff Gary is talking about is mostly
> cosmetic stuff that users really don’t care about. They want a working API
> that is flexible, easy to use, that they can count on. Sure adding stuff to
> it - like the log builders we just added - are great but we shouldn’t take
> away stuff that users already have in their application code.
>
> In the latest update from Hadoop they said that they can’t upgrade from
> Log4j 1.x to Log4j 2 because they have customers who have hundreds of
> log4j1 configuration files that is too much effort for them to change. I am
> sure there are many users who have lots of code using the log4j 1 Logger.
> We made that as easy to switch from as we could but it is still too much
> work for many people to bother with, so they use the bridge instead. But
> everyone hates using the logging bridges because of the complexity and
> overhead it adds.
>
> So while we do want to make significant changes in 3.0 we should not
> consider it to be an opportunity to make the stuff users do - such as use
> the API and write custom Plugins - incompatible.
>
> Ralph
>
>
>
Re: Thoughts on Log4j 3.0
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Dec 16, 2019, at 11:32 AM, Carter Kozak <ck...@ckozak.net> 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 that we cannot capture without breaking our API? Based on recent dev list traffic, we still have consumers on log4j 1.2, it would be great if we could avoid similar stratification as we move forward. The value proposition moving from log4j1.2 to log4j2 is substantial, we support orders of magnitude higher throughput and eliminated entire classes of bugs through the new architecture/threading model, and that hasn't been enough to push many consumers to upgrade from 1.2. I suppose my question is: If we break API and release a major revision, how do we make sure it's worth it?
>
I don’t believe you can. The stuff Gary is talking about is mostly cosmetic stuff that users really don’t care about. They want a working API that is flexible, easy to use, that they can count on. Sure adding stuff to it - like the log builders we just added - are great but we shouldn’t take away stuff that users already have in their application code.
In the latest update from Hadoop they said that they can’t upgrade from Log4j 1.x to Log4j 2 because they have customers who have hundreds of log4j1 configuration files that is too much effort for them to change. I am sure there are many users who have lots of code using the log4j 1 Logger. We made that as easy to switch from as we could but it is still too much work for many people to bother with, so they use the bridge instead. But everyone hates using the logging bridges because of the complexity and overhead it adds.
So while we do want to make significant changes in 3.0 we should not consider it to be an opportunity to make the stuff users do - such as use the API and write custom Plugins - incompatible.
Ralph
Re: Thoughts on Log4j 3.0
Posted by Carter Kozak <ck...@ckozak.net>.
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 dev list traffic, we still have consumers on log4j 1.2, it would be great if we could avoid similar stratification as we move forward. The value proposition moving from log4j1.2 to log4j2 is substantial, we support orders of magnitude higher throughput and eliminated entire classes of bugs through the new architecture/threading model, and that hasn't been enough to push many consumers to upgrade from 1.2. I suppose my question is: If we break API and release a major revision, how do we make sure it's worth it?
-ck
On Mon, Dec 16, 2019, at 13:13, 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 separately.
>
> The APIs b/w Log4j 2 and 3 are already not binary compatible WRT to
> appenders at least, I know I've removed deprecated methods, not sure about
> the log4j-api module.
>
> IMO: A major version let's us break things and provide a better API,
> otherwise, we can keep on the 2.x branch.
>
> For example, this API and all like it should be gone from 3.0:
>
> org.apache.logging.log4j.Logger.debug(Marker,
> org.apache.logging.log4j.util.Supplier<?>)
>
> and replaced with:
>
> org.apache.logging.log4j.Logger.debug(Marker,
> java.util.function.Supplier<T><?>)
>
> Everywhere we have org.apache.logging.log4j.util.Supplier in 2.0, should be
> replaced by java.util.function.Supplier in 3.0.
>
> In fact, we could (should IMO), now that we are on Java 8, in 2.14.0, add
> java.util.function.Supplier version of all methods and _deprecate_ all
> org.apache.logging.log4j.util.Supplier methods.
>
> We can also explore other kinds of logging APIs. One maybe goofy example
> was my attempt a long time ago maybe even still in some branch of having
> log methods on levels so you can say "Level.DEBUG.log(levellogger, ...)"
> which I did to avoid the explosion of methods on Logger whenever you want
> to add a new API (you need to duplicate it for debug, info, warn, and so
> on.)
>
> Gary
>
> On Mon, Dec 16, 2019 at 12:03 PM Ralph Goers <ra...@dslextreme.com>
> wrote:
>
> >
> >
> > > On Dec 16, 2019, at 9:42 AM, Raman Gupta <ro...@gmail.com> 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/), I did
> > > note some things that it would be nice to change in the API -- see
> > >
> > https://github.com/apache/logging-log4j-kotlin/blob/master/log4j-api-kotlin/src/main/kotlin/org/apache/logging/log4j/kotlin/KotlinLogger.kt#L51-L64
> > .
> > >
> > > That being said, to make a wider point, if 3.0 is gonna by JDK11+, we
> > > could consider promoting lambda-based logging, like the Kotlin logger
> > > does, as a first-class log4j3 API. The advantage of a lambda-based
> > > logger is no more need for callers to do if-logger-level-enabled
> > > checks or to use the messy parameterized methods.
> > >
> > > Regards,
> > > Raman
> >
> >
> > Thanks for the input.
> >
> > The current log4j 2 API already supports lambdas. Are you proposing that
> > we do something different? What would that look like?
> >
> > FWIW, the idea that we would have to bridge the Log4j 2 API to a Log4j 3
> > implementation doesn’t make sense to me. I would think that would annoy
> > users. The Log4j 3 implementation needs to work with the Log4j 2 API. The
> > problem Gary is highlighting is that having both the jars for the Log4j 2
> > API and Log4j 3 API would mean the package structure would need to be
> > different between them.
> >
> > Instead, I would prefer that the Log4j 3 API be backward compatible with
> > the Log4j 2 API.
> >
> > Ralph
> >
>
Re: Thoughts on Log4j 3.0
Posted by Gary Gregory <ga...@gmail.com>.
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 WRT to
appenders at least, I know I've removed deprecated methods, not sure about
the log4j-api module.
IMO: A major version let's us break things and provide a better API,
otherwise, we can keep on the 2.x branch.
For example, this API and all like it should be gone from 3.0:
org.apache.logging.log4j.Logger.debug(Marker,
org.apache.logging.log4j.util.Supplier<?>)
and replaced with:
org.apache.logging.log4j.Logger.debug(Marker,
java.util.function.Supplier<T><?>)
Everywhere we have org.apache.logging.log4j.util.Supplier in 2.0, should be
replaced by java.util.function.Supplier in 3.0.
In fact, we could (should IMO), now that we are on Java 8, in 2.14.0, add
java.util.function.Supplier version of all methods and _deprecate_ all
org.apache.logging.log4j.util.Supplier methods.
We can also explore other kinds of logging APIs. One maybe goofy example
was my attempt a long time ago maybe even still in some branch of having
log methods on levels so you can say "Level.DEBUG.log(levellogger, ...)"
which I did to avoid the explosion of methods on Logger whenever you want
to add a new API (you need to duplicate it for debug, info, warn, and so
on.)
Gary
On Mon, Dec 16, 2019 at 12:03 PM Ralph Goers <ra...@dslextreme.com>
wrote:
>
>
> > On Dec 16, 2019, at 9:42 AM, Raman Gupta <ro...@gmail.com> 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/), I did
> > note some things that it would be nice to change in the API -- see
> >
> https://github.com/apache/logging-log4j-kotlin/blob/master/log4j-api-kotlin/src/main/kotlin/org/apache/logging/log4j/kotlin/KotlinLogger.kt#L51-L64
> .
> >
> > That being said, to make a wider point, if 3.0 is gonna by JDK11+, we
> > could consider promoting lambda-based logging, like the Kotlin logger
> > does, as a first-class log4j3 API. The advantage of a lambda-based
> > logger is no more need for callers to do if-logger-level-enabled
> > checks or to use the messy parameterized methods.
> >
> > Regards,
> > Raman
>
>
> Thanks for the input.
>
> The current log4j 2 API already supports lambdas. Are you proposing that
> we do something different? What would that look like?
>
> FWIW, the idea that we would have to bridge the Log4j 2 API to a Log4j 3
> implementation doesn’t make sense to me. I would think that would annoy
> users. The Log4j 3 implementation needs to work with the Log4j 2 API. The
> problem Gary is highlighting is that having both the jars for the Log4j 2
> API and Log4j 3 API would mean the package structure would need to be
> different between them.
>
> Instead, I would prefer that the Log4j 3 API be backward compatible with
> the Log4j 2 API.
>
> Ralph
>
Re: Thoughts on Log4j 3.0
Posted by Matt Sicker <bo...@gmail.com>.
I’ve used AssertJ before and really liked it.
On Mon, Dec 16, 2019 at 12:10 Carter Kozak <ck...@ckozak.net> 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.
> Thisdecouples assertions from the framework, and takes advantage of tab
> completion for
> more specific tests with less code and complexity. Do others have
> experience with
> AssertJ and want to use it in log4j?
>
> We're working on splitting the automation into an isolated OSS project
> this week. A snippet
> from the readme:
>
> -assertTrue(continents.size() == 7);
> +assertThat(continents).hasSize(7);
>
> (Before) Test failures like the following can be quite frustrating to
> debug:
>
> `Expected :true
> Actual :false
>
> `(After) By tweaking the assertion code slightly, the failure message can
> be
> vastly improved, allowing an engineer to quickly diagnose what went
> wrong - perhaps they left a `foo` in recently:
>
> `java.lang.AssertionError:
> Expected size:<7> but was:<8> in:
> <["Africa", "Asia", "North America", "South America", "Antarctica",
> "Australia", "foo"]>`
>
> 1. https://joel-costigliola.github.io/assertj/
>
> -ck
>
> On Mon, Dec 16, 2019, at 12:58, Matt Sicker wrote:
> > 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 result will be useful (right now, it's effectively a
> > simplified version of CDI, though once I'm able to start refactoring
> > Configuration based on it, I'll be able to tell if this is worth
> > merging or not). I'll be working more on that again starting next week
> > (yes, programming is also a hobby of mine during PTO :D).
> >
> > As for the overall 3.0 story, what I'd love to see in general is the
> > proper modularization of things as we've done some work toward in
> > master already. Simplifying the build setup to require less versions
> > of Java to compile everything would be great. API cleanup for
> > everything marked deprecated for 3.0 (including some deprecated for
> > 2.0 APIs that were never removed; go see Marker).
> >
> > As for package names, if we actually do try to simplify the Logger API
> > or remove deprecated bits at least, then we'd likely need a separate
> > package name and bridge for 2.x.
> >
> > And for a bonus chore task: unit test cleanup! I have a task for
> > upgrading to JUnit 5 in our tests (while leaving a JUnit 4 logging
> > rule available for 4.x users), and that seems like a great opportunity
> > to rename test log4j config files to be more consistent with their
> > tests and seeing if there are any untested configuration scenarios.
> > I'd already be working on this if I weren't busy experimenting with
> > the CDI-light thing. Of course, this task is not specific to 3.0 but
> > generally more specific to when we changed our Java version baseline
> > to 1.8.
> >
> > On Mon, 16 Dec 2019 at 11:03, Ralph Goers <ra...@dslextreme.com>
> wrote:
> > >
> > >
> > >
> > > > On Dec 16, 2019, at 9:42 AM, Raman Gupta <ro...@gmail.com>
> 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/), I did
> > > > note some things that it would be nice to change in the API -- see
> > > >
> https://github.com/apache/logging-log4j-kotlin/blob/master/log4j-api-kotlin/src/main/kotlin/org/apache/logging/log4j/kotlin/KotlinLogger.kt#L51-L64
> .
> > > >
> > > > That being said, to make a wider point, if 3.0 is gonna by JDK11+, we
> > > > could consider promoting lambda-based logging, like the Kotlin logger
> > > > does, as a first-class log4j3 API. The advantage of a lambda-based
> > > > logger is no more need for callers to do if-logger-level-enabled
> > > > checks or to use the messy parameterized methods.
> > > >
> > > > Regards,
> > > > Raman
> > >
> > >
> > > Thanks for the input.
> > >
> > > The current log4j 2 API already supports lambdas. Are you proposing
> that we do something different? What would that look like?
> > >
> > > FWIW, the idea that we would have to bridge the Log4j 2 API to a Log4j
> 3 implementation doesn’t make sense to me. I would think that would annoy
> users. The Log4j 3 implementation needs to work with the Log4j 2 API. The
> problem Gary is highlighting is that having both the jars for the Log4j 2
> API and Log4j 3 API would mean the package structure would need to be
> different between them.
> > >
> > > Instead, I would prefer that the Log4j 3 API be backward compatible
> with the Log4j 2 API.
> > >
> > > Ralph
> >
> >
> >
> > --
> > Matt Sicker <bo...@gmail.com>
> >
>
--
Matt Sicker <bo...@gmail.com>
Re: Thoughts on Log4j 3.0
Posted by Carter Kozak <ck...@ckozak.net>.
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 less code and complexity. Do others have experience with
AssertJ and want to use it in log4j?
We're working on splitting the automation into an isolated OSS project this week. A snippet
from the readme:
-assertTrue(continents.size() == 7);
+assertThat(continents).hasSize(7);
(Before) Test failures like the following can be quite frustrating to debug:
`Expected :true
Actual :false
`(After) By tweaking the assertion code slightly, the failure message can be
vastly improved, allowing an engineer to quickly diagnose what went
wrong - perhaps they left a `foo` in recently:
`java.lang.AssertionError:
Expected size:<7> but was:<8> in:
<["Africa", "Asia", "North America", "South America", "Antarctica", "Australia", "foo"]>`
1. https://joel-costigliola.github.io/assertj/
-ck
On Mon, Dec 16, 2019, at 12:58, Matt Sicker wrote:
> 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 result will be useful (right now, it's effectively a
> simplified version of CDI, though once I'm able to start refactoring
> Configuration based on it, I'll be able to tell if this is worth
> merging or not). I'll be working more on that again starting next week
> (yes, programming is also a hobby of mine during PTO :D).
>
> As for the overall 3.0 story, what I'd love to see in general is the
> proper modularization of things as we've done some work toward in
> master already. Simplifying the build setup to require less versions
> of Java to compile everything would be great. API cleanup for
> everything marked deprecated for 3.0 (including some deprecated for
> 2.0 APIs that were never removed; go see Marker).
>
> As for package names, if we actually do try to simplify the Logger API
> or remove deprecated bits at least, then we'd likely need a separate
> package name and bridge for 2.x.
>
> And for a bonus chore task: unit test cleanup! I have a task for
> upgrading to JUnit 5 in our tests (while leaving a JUnit 4 logging
> rule available for 4.x users), and that seems like a great opportunity
> to rename test log4j config files to be more consistent with their
> tests and seeing if there are any untested configuration scenarios.
> I'd already be working on this if I weren't busy experimenting with
> the CDI-light thing. Of course, this task is not specific to 3.0 but
> generally more specific to when we changed our Java version baseline
> to 1.8.
>
> On Mon, 16 Dec 2019 at 11:03, Ralph Goers <ra...@dslextreme.com> wrote:
> >
> >
> >
> > > On Dec 16, 2019, at 9:42 AM, Raman Gupta <ro...@gmail.com> 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/), I did
> > > note some things that it would be nice to change in the API -- see
> > > https://github.com/apache/logging-log4j-kotlin/blob/master/log4j-api-kotlin/src/main/kotlin/org/apache/logging/log4j/kotlin/KotlinLogger.kt#L51-L64.
> > >
> > > That being said, to make a wider point, if 3.0 is gonna by JDK11+, we
> > > could consider promoting lambda-based logging, like the Kotlin logger
> > > does, as a first-class log4j3 API. The advantage of a lambda-based
> > > logger is no more need for callers to do if-logger-level-enabled
> > > checks or to use the messy parameterized methods.
> > >
> > > Regards,
> > > Raman
> >
> >
> > Thanks for the input.
> >
> > The current log4j 2 API already supports lambdas. Are you proposing that we do something different? What would that look like?
> >
> > FWIW, the idea that we would have to bridge the Log4j 2 API to a Log4j 3 implementation doesn’t make sense to me. I would think that would annoy users. The Log4j 3 implementation needs to work with the Log4j 2 API. The problem Gary is highlighting is that having both the jars for the Log4j 2 API and Log4j 3 API would mean the package structure would need to be different between them.
> >
> > Instead, I would prefer that the Log4j 3 API be backward compatible with the Log4j 2 API.
> >
> > Ralph
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
Re: Thoughts on Log4j 3.0
Posted by Matt Sicker <bo...@gmail.com>.
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 result will be useful (right now, it's effectively a
simplified version of CDI, though once I'm able to start refactoring
Configuration based on it, I'll be able to tell if this is worth
merging or not). I'll be working more on that again starting next week
(yes, programming is also a hobby of mine during PTO :D).
As for the overall 3.0 story, what I'd love to see in general is the
proper modularization of things as we've done some work toward in
master already. Simplifying the build setup to require less versions
of Java to compile everything would be great. API cleanup for
everything marked deprecated for 3.0 (including some deprecated for
2.0 APIs that were never removed; go see Marker).
As for package names, if we actually do try to simplify the Logger API
or remove deprecated bits at least, then we'd likely need a separate
package name and bridge for 2.x.
And for a bonus chore task: unit test cleanup! I have a task for
upgrading to JUnit 5 in our tests (while leaving a JUnit 4 logging
rule available for 4.x users), and that seems like a great opportunity
to rename test log4j config files to be more consistent with their
tests and seeing if there are any untested configuration scenarios.
I'd already be working on this if I weren't busy experimenting with
the CDI-light thing. Of course, this task is not specific to 3.0 but
generally more specific to when we changed our Java version baseline
to 1.8.
On Mon, 16 Dec 2019 at 11:03, Ralph Goers <ra...@dslextreme.com> wrote:
>
>
>
> > On Dec 16, 2019, at 9:42 AM, Raman Gupta <ro...@gmail.com> 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/), I did
> > note some things that it would be nice to change in the API -- see
> > https://github.com/apache/logging-log4j-kotlin/blob/master/log4j-api-kotlin/src/main/kotlin/org/apache/logging/log4j/kotlin/KotlinLogger.kt#L51-L64.
> >
> > That being said, to make a wider point, if 3.0 is gonna by JDK11+, we
> > could consider promoting lambda-based logging, like the Kotlin logger
> > does, as a first-class log4j3 API. The advantage of a lambda-based
> > logger is no more need for callers to do if-logger-level-enabled
> > checks or to use the messy parameterized methods.
> >
> > Regards,
> > Raman
>
>
> Thanks for the input.
>
> The current log4j 2 API already supports lambdas. Are you proposing that we do something different? What would that look like?
>
> FWIW, the idea that we would have to bridge the Log4j 2 API to a Log4j 3 implementation doesn’t make sense to me. I would think that would annoy users. The Log4j 3 implementation needs to work with the Log4j 2 API. The problem Gary is highlighting is that having both the jars for the Log4j 2 API and Log4j 3 API would mean the package structure would need to be different between them.
>
> Instead, I would prefer that the Log4j 3 API be backward compatible with the Log4j 2 API.
>
> Ralph
--
Matt Sicker <bo...@gmail.com>
Re: Thoughts on Log4j 3.0
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Dec 16, 2019, at 9:42 AM, Raman Gupta <ro...@gmail.com> 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/), I did
> note some things that it would be nice to change in the API -- see
> https://github.com/apache/logging-log4j-kotlin/blob/master/log4j-api-kotlin/src/main/kotlin/org/apache/logging/log4j/kotlin/KotlinLogger.kt#L51-L64.
>
> That being said, to make a wider point, if 3.0 is gonna by JDK11+, we
> could consider promoting lambda-based logging, like the Kotlin logger
> does, as a first-class log4j3 API. The advantage of a lambda-based
> logger is no more need for callers to do if-logger-level-enabled
> checks or to use the messy parameterized methods.
>
> Regards,
> Raman
Thanks for the input.
The current log4j 2 API already supports lambdas. Are you proposing that we do something different? What would that look like?
FWIW, the idea that we would have to bridge the Log4j 2 API to a Log4j 3 implementation doesn’t make sense to me. I would think that would annoy users. The Log4j 3 implementation needs to work with the Log4j 2 API. The problem Gary is highlighting is that having both the jars for the Log4j 2 API and Log4j 3 API would mean the package structure would need to be different between them.
Instead, I would prefer that the Log4j 3 API be backward compatible with the Log4j 2 API.
Ralph
Re: Thoughts on Log4j 3.0
Posted by Raman Gupta <ro...@gmail.com>.
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 API -- see
https://github.com/apache/logging-log4j-kotlin/blob/master/log4j-api-kotlin/src/main/kotlin/org/apache/logging/log4j/kotlin/KotlinLogger.kt#L51-L64.
That being said, to make a wider point, if 3.0 is gonna by JDK11+, we
could consider promoting lambda-based logging, like the Kotlin logger
does, as a first-class log4j3 API. The advantage of a lambda-based
logger is no more need for callers to do if-logger-level-enabled
checks or to use the messy parameterized methods.
Regards,
Raman
On Mon, Dec 16, 2019 at 10:17 AM Ralph Goers <ra...@dslextreme.com> wrote:
>
>
>
> > On Dec 16, 2019, at 7:01 AM, Gary Gregory <ga...@gmail.com> wrote:
> >
> > On Sun, Dec 15, 2019 at 5:56 PM Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>>
> > wrote:
> >
> >>
> >>
> >>> On Dec 15, 2019, at 2:44 PM, Gary Gregory <ga...@gmail.com>
> >> 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 can drop
> >> our
> >>> custom functional interfaces in the 3.0 branch (if that did not already
> >>> happen.)
> >>
> >> Although I am not opposed, is there any benefit to that? It just adds more
> >> binary incompatibilities. Although some are necessary I’d like to keep the
> >> upgrade from 2.x to 3.0 as easy as possible.
> >>
> >
> > By definition 3.0 is going to be binary incompatible with 2.x, so I am not
> > worried about how much different it will be. Log4j 3 will have to be
> > repackaged so that it can live in the same class loader as Log4j 2,
> > otherwise, it will be a giant headache for people (like me) that live in
> > large stacks with dependencies they cannot control that use all sorts of
> > stuff.
>
>
> Umm. What you are describing sounds like a nightmare. Having multiple incompatible Log4j versions would mean we would have to build a bridge between the two so that users of the 2.x API can route to the 3.x implementation. If the APIs are the same then that wouldn’t be necessary. It has been so long that I have forgotten if we have really made the API incompatible.
>
> Ralph
Re: Thoughts on Log4j 3.0
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Dec 16, 2019, at 7:01 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> On Sun, Dec 15, 2019 at 5:56 PM Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>>
> wrote:
>
>>
>>
>>> On Dec 15, 2019, at 2:44 PM, Gary Gregory <ga...@gmail.com>
>> 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 can drop
>> our
>>> custom functional interfaces in the 3.0 branch (if that did not already
>>> happen.)
>>
>> Although I am not opposed, is there any benefit to that? It just adds more
>> binary incompatibilities. Although some are necessary I’d like to keep the
>> upgrade from 2.x to 3.0 as easy as possible.
>>
>
> By definition 3.0 is going to be binary incompatible with 2.x, so I am not
> worried about how much different it will be. Log4j 3 will have to be
> repackaged so that it can live in the same class loader as Log4j 2,
> otherwise, it will be a giant headache for people (like me) that live in
> large stacks with dependencies they cannot control that use all sorts of
> stuff.
Umm. What you are describing sounds like a nightmare. Having multiple incompatible Log4j versions would mean we would have to build a bridge between the two so that users of the 2.x API can route to the 3.x implementation. If the APIs are the same then that wouldn’t be necessary. It has been so long that I have forgotten if we have really made the API incompatible.
Ralph
Re: Thoughts on Log4j 3.0
Posted by Gary Gregory <ga...@gmail.com>.
On Sun, Dec 15, 2019 at 5:56 PM Ralph Goers <ra...@dslextreme.com>
wrote:
>
>
> > On Dec 15, 2019, at 2:44 PM, Gary Gregory <ga...@gmail.com>
> 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 can drop
> our
> > custom functional interfaces in the 3.0 branch (if that did not already
> > happen.)
>
> Although I am not opposed, is there any benefit to that? It just adds more
> binary incompatibilities. Although some are necessary I’d like to keep the
> upgrade from 2.x to 3.0 as easy as possible.
>
By definition 3.0 is going to be binary incompatible with 2.x, so I am not
worried about how much different it will be. Log4j 3 will have to be
repackaged so that it can live in the same class loader as Log4j 2,
otherwise, it will be a giant headache for people (like me) that live in
large stacks with dependencies they cannot control that use all sorts of
stuff.
Gary
>
>
> >
> > At work, we are looking to move Java 11 as customers are uneasy running
> on
> > an EOL version like Java 8 (I know, I know, commercial support). As far
> as
> > making Java 11 the base requirement, we are somewhat waiting on IBM to
> make
> > Java 11 available on z/OS (
> https://developer.ibm.com/javasdk/support/zos/)
> >
> > So overall my thoughts are to make use of Java 8 in 2.x and seeing how
> that
> > allows 3.0 to be cleaned up.
>
> I don’t understand this statement. Are you agreeing that 3.0 should move
> to Java 11 or just stating that you want 3.0 to be cleaned up?
>
> Ralph
>
>
>
>
>
Re: Thoughts on Log4j 3.0
Posted by Gary Gregory <ga...@gmail.com>.
On Sun, Dec 15, 2019 at 5:56 PM Ralph Goers <ra...@dslextreme.com>
wrote:
>
>
> > On Dec 15, 2019, at 2:44 PM, Gary Gregory <ga...@gmail.com>
> 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 can drop
> our
> > custom functional interfaces in the 3.0 branch (if that did not already
> > happen.)
>
> Although I am not opposed, is there any benefit to that? It just adds more
> binary incompatibilities. Although some are necessary I’d like to keep the
> upgrade from 2.x to 3.0 as easy as possible.
>
>
> >
> > At work, we are looking to move Java 11 as customers are uneasy running
> on
> > an EOL version like Java 8 (I know, I know, commercial support). As far
> as
> > making Java 11 the base requirement, we are somewhat waiting on IBM to
> make
> > Java 11 available on z/OS (
> https://developer.ibm.com/javasdk/support/zos/)
> >
> > So overall my thoughts are to make use of Java 8 in 2.x and seeing how
> that
> > allows 3.0 to be cleaned up.
>
> I don’t understand this statement. Are you agreeing that 3.0 should move
> to Java 11 or just stating that you want 3.0 to be cleaned up?
>
I am not saying either way really ;-) If Log4j were on Java 11 today, I
could not use it at work. But that should not stop the project from moving
on.
Gary
>
> Ralph
>
>
>
>
>
Re: Thoughts on Log4j 3.0
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Dec 15, 2019, at 2:44 PM, Gary Gregory <ga...@gmail.com> 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 can drop our
> custom functional interfaces in the 3.0 branch (if that did not already
> happen.)
Although I am not opposed, is there any benefit to that? It just adds more binary incompatibilities. Although some are necessary I’d like to keep the upgrade from 2.x to 3.0 as easy as possible.
>
> At work, we are looking to move Java 11 as customers are uneasy running on
> an EOL version like Java 8 (I know, I know, commercial support). As far as
> making Java 11 the base requirement, we are somewhat waiting on IBM to make
> Java 11 available on z/OS (https://developer.ibm.com/javasdk/support/zos/)
>
> So overall my thoughts are to make use of Java 8 in 2.x and seeing how that
> allows 3.0 to be cleaned up.
I don’t understand this statement. Are you agreeing that 3.0 should move to Java 11 or just stating that you want 3.0 to be cleaned up?
Ralph
Re: Thoughts on Log4j 3.0
Posted by Gary Gregory <ga...@gmail.com>.
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 can drop our
custom functional interfaces in the 3.0 branch (if that did not already
happen.)
At work, we are looking to move Java 11 as customers are uneasy running on
an EOL version like Java 8 (I know, I know, commercial support). As far as
making Java 11 the base requirement, we are somewhat waiting on IBM to make
Java 11 available on z/OS (https://developer.ibm.com/javasdk/support/zos/)
So overall my thoughts are to make use of Java 8 in 2.x and seeing how that
allows 3.0 to be cleaned up.
Gary
On Sun, Dec 15, 2019 at 4:17 PM Ralph Goers <ra...@dslextreme.com>
wrote:
> 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
> is one of the main reasons I believe things have been moving slow.
>
> Now that we have moved the 2.x releases to Java 8 I am wondering if we
> shouldn’t make Java 11 the minimum for 3.0. It would simplify the build as
> we would no longer need multiple Java versions installed, we would no
> longer need toolchains, and we could simply move the code from the Java 9
> specific modules into their respective modules and clean up that code. It
> would also make it much easier to implement a few other features that
> require Java 9+.
>
> Obviously, if we have a minimum of Java 11 then we would need to continue
> to support both the main and release-2.x branches for some time to come as
> it is going to be quite a while before Java 8 falls out of favor.
>
> Thoughts?
>
> Ralph
>