I've noticed that one of the common complaints when migrating from log4j 1 to 2 (or similar) is the API to modify loggers/appenders/etc. at runtime. Despite efforts to fulfill the user needs without digging into internals, it seems like some frameworks or tools prefer convoluted access instead of managing config files.
As for an API trim or similar to make Android and future Java use easier, that would really require a v3 API at this point, and I'd imagine any v3 API we made would use Java 8 as a baseline which doesn't really solve the Android problem at all. In practical usage, all my applications have to mangle logging dependencies transitively regardless, so I've given up hope that there will ever be a simple solution. Sometimes I wonder if it would be more valuable to try and port more of log4j-api to slf4j-api, or potentially unify the two facades one day. On 8 January 2018 at 09:37, Gary Gregory <[email protected]> wrote: > Hi All: > > Over on the [email protected] list, we have a thread called "Using SLF4J > as > a logging facade; Re: Disagreement on Log4J2" where Oleg (our lead and main > author) has proposed moving from Log4j2 to SLF4J for the next HttpClient > Alpha. > > (I had initially switched HC from Commons Logging to Log4j 2) > > Android is the main contention. The size of the API is another but we > cannot do anything about that. > > Your comments to at least provide direction and expectations would be most > welcome. > > Thank you, > Gary > -- Matt Sicker <[email protected]>
