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
