On Mon, Jan 8, 2018 at 9:26 AM, Ralph Goers <[email protected]> wrote:
> 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 seen the same kinds of thing from Slf4j, so I too would not be keen to get under the Slf4j umbrella. 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. > That sounds reasonable to be and an accurate picture. Gary > > 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]> > >
