Speaking of failover kind of things, the JMS Appender has a reconnect feature and I am wrapping up a similar feature for the JDBC Appender. This kind of feature is a MUST for services that need to stay up and running for longer periods of time.
It would be nice to have a reconnect feature abstracted out so that all appenders/managers that depend on external resources can survive these resources going up and down as well as internet connections going up and down. That would make it much easier to implement this in all appenders that need it. A start would be to abstract JMS and JDBC reconnect code. Testing this is quite tricky of course. Gary On Mon, Nov 5, 2018 at 9:33 PM Ralph Goers <[email protected]> wrote: > 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 > > > > >
