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 17:56:03 GMT
Thank you both for replying. It sounds like for now we do not have clean
Android story. I will reply later today to the HC thread with something
like 'We plan on having an Android solution in the future" which means HC
will likely switch to Slf4j for the next alpha/beta. Feel free to comment
over at HC as well.

Gary

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 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 <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