I have a couple of comments here. One of the reasons I created Log4j using its own API was due to the introduction of Messages. I had discussions on the SLF4J list that made it clear that Ceki wasn’t interested in modifying the API to support anything more than Strings. In fact, as a whole SLF4J is not very responsive to people proposing changes. Just last week there were emails to the SLF4J from someone begging that their PRs be committed, or at the very least be reviewed. Although it would be great to only have a single Logging API I hold out little hope that SLF4J will ever incorporate what we would need. I have noticed that when people migrate from Log4j 1 to Log4j 2 they are trying to figure out how to simply migrate their code from Log4j 1 syntax to Log4j 2. They are not investigating how Log4j 2 works and trying how to best implement the functionality they require. Android is a problem. I think that is primarily because none of us develop for it. The main reason we have support for OSGi, low GC overhead, asynchronous loggers, etc. is because we have or had committers with a need for those features. Although SLF4J seems to support Android my understanding is that there is an SLF4J Android project that provides more support. I think we just need to determine what the best way to support Android is and implement it.
Ralph > On Jan 8, 2018, at 9:01 AM, Matt Sicker <[email protected]> wrote: > > 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]>
