Oleg, thanks for the clarification. I originally thought you meant the JMX classes in log4j-core.
I think we may be able to come up with a different solution to (LOG4J2-1226 <https://issues.apache.org/jira/browse/LOG4J2-1226>) that does not involve MarshalledObject in log4j-api. I created https://issues.apache.org/jira/browse/LOG4J2-1926 for this (with you as the reporter). Please feel free to modify that ticket if it is incomplete or incorrect. Remko On Thu, Jun 1, 2017 at 1:57 AM, Oleg Kalnichevski <ol...@apache.org> wrote: > On Thu, 2017-06-01 at 01:18 +0900, Remko Popma wrote: > > Oleg, > > > > Elements in the Log4j configuration can be instrumented with MBeans > > to > > allow remote inspection and modification of an application's logging > > configuration. As Matt pointed out, this can be disabled. > > > > There is no dependency on RMI as far as I know. > > Remko, > > Lint code analyzer used by Android seems to suggest otherwise. > java.rmi.MarshalledObject imported by SortedArrayStringMap does look > like a direct dependency on RMI to me as well. > > > > Was the above a conscious design decision? I did most of the work in > > this > > area and as far as I remember, yes. ;-) > > > > Given we have established that I am not sure what your long term > strategy towards Android is going to be. At the moment adding > transitive dependency on log4j2-api causes any Android build to fail > with a scary invalid package error. Surely this error can be ignored > with a custom lint rule but it may present a certain reason for concert > to less experienced developers. > > > > Not sure what you mean by "heavy". From a user's point of view, more > > functionality is often desirable. From an implementor's point of > > view, care > > was taken to provide abstract implementations that should make it > > relatively easy to provide an alternative implementation of the > > Log4j2 API. > > There is some additional cognitive load because of the richer > > functionality > > but there is enough overlap with other logging frameworks that in > > practice > > I don't think this is a problem for users. > > > > The Message interface is a powerful abstraction that allows users to > > create > > I have nothing against the Message interface as such. I am not not sure > that all of its implementations belong to the facade APIs. That is all. > > Oleg > > > various enhancements without requiring API changes. It is one of the > > things > > that made it possible to make Log4j2 garbage-free in a backwards > > compatible > > manner. Compare for example with the SLF4J API which requires that > > the user > > logs String messages only. I personally think that was a design > > mistake, if > > only for the fact that a String-based API prevents garbage-free > > logging. > > The Message implementations simply cover a range of common use cases. > > > > Remko > > > > > > On Thu, Jun 1, 2017 at 12:10 AM, Oleg Kalnichevski <ol...@apache.org> > > wrote: > > > > > 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 > > > > > > > > > > > > > > > > > >
