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 <[email protected]> > wrote: > > > > > > > > On Dec 16, 2019, at 9:42 AM, Raman Gupta <[email protected]> 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 > > >
