Some other features I need/want to do: 1. LOG4J2-1137 2. Allow the SocketAppender to specify multiple IP addresses and allow either round-robining through them or failing to the next if the first fails. This will provide better high availability for applications. 3. Support a ContextSelector based on Module Layers. 4. LOG4J2-2170
Ralph > On Nov 5, 2018, at 9:22 PM, Ralph Goers <[email protected]> wrote: > > How much are we impacting the API? I don’t know that package naming is > required if the API is compatible. I am hoping this doesn’t impact the API > much. > > I’d prefer this just be log4j 3.x. Log4j 2 3.x is just really weird. > > I wouldn’t say a module shouldn’t have any optional dependencies but it > should be as few as possible. That said, because java is now modularized and > you only get java.base by default I think log4j-core should only require > that. This would mean probably only the Properties configuration can remain > in core. > > I’m not completely sold on replacing the configuration with Jackson or > Commons Configuration. First, I really like that we convert the configuration > to a node tree and then process the node tree the same way regardless of the > configuration syntax used to construct it. Since we already use Jackson for > JSON and YAML I am not sure what it means to redo the configuration to use > something we are already using. > > I would like to have every Maven module be a JPMS module, but this may still > be impossible to do as not all of our dependencies have declared module names > yet. For example, https://github.com/LMAX-Exchange/disruptor/issues/234 > <https://github.com/LMAX-Exchange/disruptor/issues/234> shows the disruptor > still hasn’t done anything. > > For me, the main goal would be just “cleaning up” so the modules have fewer > dependencies. This also should align nicely with generating JPMS modules. > > I do have new features I want to add and they don’t really require 3.0 to do > them, but I would really like to provide good reasons to upgrade to log4j 3.x > besides internal cleanup. > > One new feature that is a high priority for me is to make Log4j more “cloud > friendly”. This means being able to read and dynamically update the logging > configuration from something like Spring Cloud Configuration. Essentially > this just means being able to read and monitor a file via HTTP instead of > using only the File API. > > Also, I’d like to make another pass at performance testing to see where we > still have room for improvement. > > I would really, like to figure out a way to include location information in > the log events without the overhead we have now. The only sane way to do it > is to somehow get the information at compile time, but I just haven’t been > able to figure out a clever hack to make it work. > > Ralph > >> On Nov 5, 2018, at 2:01 PM, 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 >
