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
