I certainly would hope that collapsing Foo2, Foo3 into their parent is up for consideration for 3.0. Memories of Microsoft COM and DCOM...
Gary On Fri, May 13, 2022, 13:36 Matt Sicker <[email protected]> wrote: > The only realistic way to break compatibility in the API is to > introduce a v3 API and make the v3 Core implement both the v2 and v3 > APIs (or breaking that into two modules, but that introduces more log > bridge confusion which is already a huge mess thanks to people > continually reinventing logging APIs instead of using log4j-api (or > slf4j-api even; seen plenty of projects that introduce their own log > adaptor to further fragment things). > > If the v3 API was introduced purely to remove MessageSupplier (which > can be replaced with Supplier<Message> or Supplier<? extends Message> > as we already support) and our custom Supplier<T> interface, then I > don't think that's enough changes to warrant the introduction of a > brand new API. On the other hand, if we could aggregate enough changes > that break compatibility to warrant a v3 API, then I could support > that idea more. However, I'd hope that such a breakage would be more > than removing deprecated things or merging extension classes (such as > flattening the Foo2 classes into Foo). > > It could potentially be interesting to consider offering multiple APIs > for different use cases (e.g., having a minimal API that has a small > jar size that can use lambdas rather than parameter arguments), but > that's somewhat orthogonal here. > > On Thu, May 12, 2022 at 3:31 PM Ralph Goers <[email protected]> > wrote: > > > > > > > > > On May 12, 2022, at 10:15 AM, Chris Hegarty <[email protected]> > wrote: > > > > > > > > > My motivation for bringing this up now is just to explicitly highlight > the consequences and potential wide impact of such a change, not to make > any concrete suggestions. It's a difficult balancing act to weigh > compatibility against making progress, but ultimately j.u.f.Supplier is the > right choice (there are just different ways to get there). > > > > Any ideas on how to get there? The one proposal Gary made was to require > log4j3 artifacts and renaming all packages to org.apache.logging.log4j3. > The consequences of this would be: > > a. Both are on the classpath - unless we change log4j2.xml to log4j3.xml > and change all our property names then both will try to load the same > logging configuration, which is bound to be problematic. > > b. We create a bridge in log4j3 for the log4j 2 api. I just see this as > a mess and confusing to users. > > > > FWIW, the impact of us using our own Supplier seems non-existent since > anyone using those methods would be providing a lambda expression. > > > > Ralph >
