logging-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [log4j] and Apache HttpClient
Date Mon, 08 Jan 2018 16:44:02 GMT
On Mon, Jan 8, 2018 at 9:26 AM, Ralph Goers <ralph.goers@dslextreme.com>
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 <boards@gmail.com> 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 <garydgregory@gmail.com> wrote:
> >
> >> Hi All:
> >>
> >> Over on the dev@hc.apache.org 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 <boards@gmail.com>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message