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]>
