On Wed, 2017-05-31 at 09:30 -0500, Matt Sicker wrote: > The JMX stuff can be disabled, and there are some other similar > optional > dependencies we've had to create due to some previously reported > issues > with missing classes on Android. As for full compatibility, I don't > think > any of the main developers here have worked on that, but patches and > other > contributions are welcome! >
Matt I am perfectly fine with doing all the necessary leg work but first I need to understand if dependency on RMI and Management APIs was a conscious design decision or it simply happened. After having taken a cursory look at Log4j2 APIs I must admit I am bit unpleasantly surprised at how heavy they feel. For instance, was it really necessary to put all sort of concrete Message implementations into what is meant to be an abstract logging API? Oleg > On 31 May 2017 at 04:54, Oleg Kalnichevski <ol...@apache.org> wrote: > > > Folks, > > > > I did try to do a reasonable research on the matter prior to > > posting my > > question here, nevertheless, please do excuse me if I am asking > > something obvious or well documented somewhere (in a place I was > > unable > > to find). > > > > I read that people had been more or less successfully using Log4j2 > > 2.3 > > on Android. > > > > In our case (Apache HttpClient 5.0) when the library gets pulled > > into > > an Android project, the Lint static code analyzer reports two > > severe > > violations due to transitive dependency through Log4j APIs 2.8 on > > Java > > RMI and Java Management APIs. > > > > My first question is whether or not Log4j2 has been built and > > tested > > for compatibility with Android of any version? > > > > Another question whether or not Logging APIs dependency on on Java > > RMI > > and Java Management APIs intentional? > > > > Oleg > > > > >
