Another API I've wanted to see is a proper async API. Since we're using Java 8, this can be based on CompletableFuture. This would be mostly useful for appenders that use networking (so mostly the database and message queue appenders).
A nice to have would be a stable SPI for plugins with guarantees like the API has for backwards compatibility and the like. Java 8 helps with this once again with default methods on interfaces. On Mon, 5 Nov 2018 at 15:12, Carter Kozak <[email protected]> wrote: > I'd like to consider potential API breaking refactors around > ThrowableProxy regarding LOG4J2-2391. The jar lookup is incredibly > expensive and creates a great deal of additional complexity. > On Mon, Nov 5, 2018 at 4:06 PM Matt Sicker <[email protected]> wrote: > > > > One of my biggest bikeshedding questions I've been thinking about here > is: > > do we call it Log4j2 3.x or Log4j3? > > > > On a more serious note, yes, I'd love to see the config parsing stuff > > redone. I like using YAML over JSON or properties files, that's for sure, > > though XML can be nicer when the XSD has enough information for editors > to > > discover everything. Whether we rely on dependencies, > shading/repackaging, > > or a custom API, however, is an interesting discussion. > > > > Perhaps if we also tackle autoformatting everything and enforcing a > > checkstyle config or similar, that would make it easier to maintain > > multiple branches in the future for backporting bugfixes or security > fixes. > > > > On Mon, 5 Nov 2018 at 15:01, Gary Gregory <[email protected]> > wrote: > > > > > Considerations for 3.0: > > > > > > - Currently targeting Java 8, seems OK to keep this for now. > > > - Remove deprecated code > > > - Make BC-breaking changes as we see fit to improve impl. > > > - ? Update root package to include "3" to allow Log4j 1, 2, and 3 to > > > co-exist peacefully on the claspath. Perhaps org.apache.logging.log4j3. > > > - Do we need a compatibility layer for 1.2 to 3.0 and 2.x to 3.0? > > > - Where can we use java.time? > > > - Is it a goal to have Maven modules with NO optional dependencies? I > think > > > so. > > > - Play nice in the Java 9 module system > > > - Continue to break up current Maven modules > > > - How can we make Core smaller? > > > - Should we redo our config code to use something like Jackson or > Commons > > > Configuration? We have a lot of config code... Not sure if everything > you > > > can do in XML is doable in JSON and YAML. YAML is gross IMO but some > people > > > like it. > > > > > > What else? > > > > > > Gary > > > > > > > > > -- > > Matt Sicker <[email protected]> > -- Matt Sicker <[email protected]>
