You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Gary Gregory <ga...@gmail.com> on 2018/01/08 15:37:57 UTC
[log4j] and Apache HttpClient
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
Re: [log4j] and Apache HttpClient
Posted by Ralph Goers <ra...@dslextreme.com>.
Gary,
As far as I know the only outstanding issue is https://issues.apache.org/jira/browse/LOG4J2-2038 <https://issues.apache.org/jira/browse/LOG4J2-2038>. I would point them to https://issuetracker.google.com/issues/70118537 <https://issuetracker.google.com/issues/70118537> as well. Also, in https://issues.apache.org/jira/browse/LOG4J2-2133 <https://issues.apache.org/jira/browse/LOG4J2-2133> Oleg said he was going to follow-up and see if Google had fixed the issue with the module-info.class files. He never did that.
FWIW, I pinged again on the thread at http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-December/050382.html <http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-December/050382.html> to see if I can get an answer on whether Google has implemented a fix to ignore files in META-INF/versions.
When you converted HttpClient to use Log4j 2 did you happen to use any API methods that SLF4J doesn’t support (for example, custom Messages)? If so I would mention that reverting will cause a loss of functionality.
My response would be that the tooling for Android should be catching up shortly which will allow the existing Log4j 2 API to work properly.
Ralph
> On Jan 8, 2018, at 10:56 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> 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 <ra...@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 <bo...@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 <ga...@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 <bo...@gmail.com>
>>
>>
Re: [log4j] and Apache HttpClient
Posted by Gary Gregory <ga...@gmail.com>.
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 <ra...@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 <bo...@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 <ga...@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 <bo...@gmail.com>
>
>
Re: [log4j] and Apache HttpClient
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Jan 8, 2018 at 9:26 AM, Ralph Goers <ra...@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 <bo...@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 <ga...@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 <bo...@gmail.com>
>
>
Re: [log4j] and Apache HttpClient
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <bo...@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 <ga...@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 <bo...@gmail.com>
Re: [log4j] and Apache HttpClient
Posted by Matt Sicker <bo...@gmail.com>.
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 <ga...@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 <bo...@gmail.com>
Re: [log4j] and Apache HttpClient
Posted by Ralph Goers <ra...@dslextreme.com>.
I am on PTO this week. I might find time for this when I am not out having fun
Sent from my iPhone
> On Jan 8, 2018, at 11:24 AM, Mikael Ståldal <mi...@apache.org> wrote:
>
> I think that we should at least make a release with fix for https://issues.apache.org/jira/browse/LOG4J2-2126 before we try to convince anyone to use Log4j for something which might be used on Android.
>
>
>> On 2018-01-08 16:37, Gary Gregory 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
>
>
Re: [log4j] and Apache HttpClient
Posted by Mikael Ståldal <mi...@apache.org>.
I think that we should at least make a release with fix for
https://issues.apache.org/jira/browse/LOG4J2-2126 before we try to
convince anyone to use Log4j for something which might be used on Android.
On 2018-01-08 16:37, Gary Gregory 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
>