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 <[email protected]> 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 <[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 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]> >> >>
