You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2017/05/31 09:54:18 UTC
Log4j2 APIs on Android
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
Re: Log4j2 APIs on Android
Posted by Matt Sicker <bo...@gmail.com>.
Those Message implementations correspond to a lot of basic functionality
you'll find in other APIs like SLF4J, so I wouldn't consider it heavy.
Besides, that's also one of the key differentiating features between
log4j-api and slf4j-api, for example.
As for RMI, the only strange use I know of is in serializing a LogEvent via
the MarshalledObject class. Otherwise, the RMI/JMX stuff are all
administrative features that are optional.
On 31 May 2017 at 10:10, 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
> > >
> >
> >
> >
>
--
Matt Sicker <bo...@gmail.com>
Re: Log4j2 APIs on Android
Posted by Remko Popma <re...@gmail.com>.
...that said, there is an effort underway to break up log4j-core into
smaller modules with more explicit dependencies.
In light of what you are saying it may make sense to break out the `
org.apache.logging.log4j.core.jmx` package into a separate module.
User domain objects and exceptions are wrapped in MarshalledObject when
LogEvents are serialized. This allows applications like Lilith to
deserialize LogEvents even when not all domain classes are on the classpath
(LOG4J2-1226 <https://issues.apache.org/jira/browse/LOG4J2-1226>).
Is java.rmi.MarshalledObject a problem in Android?
On Thu, Jun 1, 2017 at 1:18 AM, Remko Popma <re...@gmail.com> 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. 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
>> > >
>> >
>> >
>> >
>>
>
>
Re: Log4j2 APIs on Android
Posted by Mikael Ståldal <mi...@apache.org>.
I am not sure I like Remko's solution to remove the dependency on RMI
MarshalledObject in SortedArrayStringMap. I am afraid that this
implementation:
private static Object unmarshall(byte[] data) throws IOException,
ClassNotFoundException {
ByteArrayInputStream bin = new ByteArrayInputStream(data);
try (ObjectInputStream ois = new ObjectInputStream(bin)) {
return ois.readObject();
}
}
might open the serialization security vulnerability CVE-2017-5645 we
fixed with FilteredObjectInputStream in LOG4J2-1863 since the nested
ObjectInputStream does not respect the filtering.
I would like to know why we used MarshalledObject in the first place,
and why we cannot simply serialize the objects directly in
SortedArrayStringMap.
(I do agree that we should not use MarshalledObject, or anything else
from RMI, in log4j-api.)
On 2017-06-01 05:44, Remko Popma wrote:
> 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
>>>>>>
>>>>>
>>>>>
>>>>>
>>
>
Re: Log4j2 APIs on Android
Posted by Remko Popma <re...@gmail.com>.
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
> > > > >
> > > >
> > > >
> > > >
>
Re: Log4j2 APIs on Android
Posted by Remko Popma <re...@gmail.com>.
I did some work to get closer to making Log4j2 API work on Android. What remains is the dependency on the java.lang.management package in ThreadDumpMessage and ExtendedThreadInformation.
(Shameless plug) Every java main() method deserves http://picocli.info
> On Jun 17, 2017, at 16:50, Mikael Ståldal <mi...@apache.org> wrote:
>
> I think Oleg have a point in that log4j-api is a bit too heavy currently. I was maybe a mistake to put concrete implementations of Message and StringMap there.
>
> The problem is not primarily the size, but that the implementation classes drag in unwanted dependencies (like this RMI dependency).
>
> We cannot change that now (maybe for Log4j 3.0), but I think we should keep that in mind and try to avoid adding more implementation stuff to log4j-api in the future.
>
> And we should definitely make sure that log4j-api works smoothly on Android.
>
>
>> On 2017-05-31 19:57, Oleg Kalnichevski 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
>>>>>>
>>>>>
>>>>>
>>>>>
Re: Log4j2 APIs on Android
Posted by Mikael Ståldal <mi...@apache.org>.
I think Oleg have a point in that log4j-api is a bit too heavy
currently. I was maybe a mistake to put concrete implementations of
Message and StringMap there.
The problem is not primarily the size, but that the implementation
classes drag in unwanted dependencies (like this RMI dependency).
We cannot change that now (maybe for Log4j 3.0), but I think we should
keep that in mind and try to avoid adding more implementation stuff to
log4j-api in the future.
And we should definitely make sure that log4j-api works smoothly on Android.
On 2017-05-31 19:57, Oleg Kalnichevski 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
>>>>>
>>>>
>>>>
>>>>
>
Re: Log4j2 APIs on Android
Posted by Oleg Kalnichevski <ol...@apache.org>.
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
> > > >
> > >
> > >
> > >
Re: Log4j2 APIs on Android
Posted by Remko Popma <re...@gmail.com>.
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
> > >
> >
> >
> >
>
Re: Log4j2 APIs on Android
Posted by Oleg Kalnichevski <ol...@apache.org>.
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
> >
>
>
>
Re: Log4j2 APIs on Android
Posted by Matt Sicker <bo...@gmail.com>.
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!
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
>
--
Matt Sicker <bo...@gmail.com>