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. There is a log4j-jmx-gui client module that can be used as a standalone application to perform this remote inspection and modification, and this client module uses RMI, but in the log4j-core components only use the platform javax.management API so in principle you can connect with other protocols. Was the above a conscious design decision? I did most of the work in this area and as far as I remember, yes. ;-) 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 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 > > > > > > > > > >
