[jira] [Commented] (LOG4J2-1294) Update Kafka client from 0.9.0.0 to 0.9.0.1

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16032377#comment-16032377
 ] 

ASF subversion and git services commented on LOG4J2-1294:
-

Commit 0e2b89ee145e5f005bbe7699344e34453dac224e in logging-log4j2's branch 
refs/heads/master from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=0e2b89e ]

[LOG4J2-1294] The JMS Appender should use a JMS MapMessage for a Log4j
MapMessage.

> Update Kafka client from 0.9.0.0 to 0.9.0.1
> ---
>
> Key: LOG4J2-1294
> URL: https://issues.apache.org/jira/browse/LOG4J2-1294
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.5
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.6
>
>
> Update Kafka client from 0.9.0.0 to 0.9.0.1.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (LOG4J2-1924) The JMS Appender should use a JMS MapMessage for a Log4j MapMessage

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory closed LOG4J2-1924.

   Resolution: Fixed
Fix Version/s: 2.9

In Git master.

> The JMS Appender should use a JMS MapMessage for a Log4j MapMessage
> ---
>
> Key: LOG4J2-1924
> URL: https://issues.apache.org/jira/browse/LOG4J2-1924
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Appenders
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.9
>
>
> The JMS Appender should use a JMS {{javax.jms.MapMessage}} for a Log4j 
> {{org.apache.logging.log4j.message.MapMessage}}.
> To use this feature, set the layout of a JMS Appender to the new 
> {{MessageLayout}} which is included in this new feature like {{ />}}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Chainsaw in git

[Ralph Goers]

The old git repo on Github is the mirror of the subversion repo.  That repo 
should go away when the svn repo is deleted.

Ralph

> On May 31, 2017, at 6:54 PM, Robert Middleton  wrote:
> 
> I just noticed that there's already a chainsaw git repo on Github and
> ASF git, I assume that anything done to it would be against the
> logging-chainsaw.git and not chainsaw.git.  Is that correct?
> 
> -Robert Middleton
> 
> On Wed, May 31, 2017 at 3:14 AM, Gary Gregory  wrote:
>> A new Jira project or a component of LOG4J2?
>> 
>> Gary
>> 
>> On May 30, 2017 9:04 PM, "Ralph Goers"  wrote:
>> 
>>> The question was where does he file the bug?
>>> 
>>> Ralph
>>> 
 On May 30, 2017, at 6:55 PM, Scott Deboy  wrote:
 
 File a bug and it would get attention.
 
 Also: contributions welcome!
 
 Scott
 
 On May 30, 2017 6:48 PM, "Robert Middleton"  wrote:
 
> Is chainsaw used/maintained regularly?  There haven't been commits in
> a few years it looks like(also it's not in JIRA for bug tracking, the
> POM indicates that it should be in bugzilla but it doesn't look like
> it's there).
> 
> -Robert Middleton
> 
> On Tue, May 30, 2017 at 8:27 PM, Remko Popma 
> wrote:
>> Thanks for doing this work, Ralph!
>> Remko
>> 
>> (Shameless plug) Every java main() method deserves http://picocli.info
>> 
>>> On May 31, 2017, at 8:54, Ralph Goers 
> wrote:
>>> 
>>> At the request of Scott Deboy I have migrated chainsaw to git. You can
> view it at https://github.com/apache/logging-chainsaw <
> https://github.com/apache/logging-chainsaw> and check it out from
> https://git-wip-us.apache.org/repos/asf/logging-chainsaw.git <
> https://git-wip-us.apache.org/repos/asf/logging-chainsaw.git>. Please
> review it and let me know of any problems. If there aren’t any I will
> request infra close down the chainsaw svn repo.
>>> 
>>> Ralph
> 
>>> 
>>> 
>>> 
> 

[jira] [Updated] (LOG4J2-1924) The JMS Appender should use a JMS MapMessage for a Log4j MapMessage

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated LOG4J2-1924:
-
Description: 
The JMS Appender should use a JMS {{javax.jms.MapMessage}} for a Log4j 
{{org.apache.logging.log4j.message.MapMessage}}.

To use this feature, set the layout of a JMS Appender to the new 
{{MessageLayout}} which is included in this new feature.

  was:The JMS Appender should use a JMS {{javax.jms.MapMessage}} for a Log4j 
{{org.apache.logging.log4j.message.MapMessage}}.


> The JMS Appender should use a JMS MapMessage for a Log4j MapMessage
> ---
>
> Key: LOG4J2-1924
> URL: https://issues.apache.org/jira/browse/LOG4J2-1924
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Appenders
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> The JMS Appender should use a JMS {{javax.jms.MapMessage}} for a Log4j 
> {{org.apache.logging.log4j.message.MapMessage}}.
> To use this feature, set the layout of a JMS Appender to the new 
> {{MessageLayout}} which is included in this new feature.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (LOG4J2-1926) Remove dependency on MarshalledObject from log4j-api

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma updated LOG4J2-1926:

Description: 
(Remko: Paraphrasing discussion on the log4j dev mailing list. Please feel free 
to update/modify):

When the Apache HttpClient 5.0 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.

At the moment adding a 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.

This is caused by Log4j's use of MarshalledObject: 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).

Consider finding a different way to solve this problem that does not require 
MarshalledObject.

  was:
Paraphrasing discussion on the log4j dev mailing list (feel free to 
update/modify):

When the Apache HttpClient 5.0 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.

At the moment adding a 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.

This is caused by Log4j's use of MarshalledObject: 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).

Consider finding a different way to solve this problem that does not require 
MarshalledObject.


> Remove dependency on MarshalledObject from log4j-api
> 
>
> Key: LOG4J2-1926
> URL: https://issues.apache.org/jira/browse/LOG4J2-1926
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>Affects Versions: 2.8
> Environment: Android
>Reporter: Oleg Kalnichevski
>Assignee: Remko Popma
>
> (Remko: Paraphrasing discussion on the log4j dev mailing list. Please feel 
> free to update/modify):
> When the Apache HttpClient 5.0 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.
> At the moment adding a 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.
> This is caused by Log4j's use of MarshalledObject: 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).
> Consider finding a different way to solve this problem that does not require 
> MarshalledObject.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (LOG4J2-1925) Having log4j-core on the compile classpath somehow breaks compilation even if I'm not calling it

[Trejkaz (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16032288#comment-16032288
 ] 

Trejkaz commented on LOG4J2-1925:
-

I created an annotation processor which does nothing and put that on the 
classpath instead, with everything else in the command the same, and the 
resulting command runs successfully. So I guess it really is a problem in 
log4j's own annotation processor.


> Having log4j-core on the compile classpath somehow breaks compilation even if 
> I'm not calling it
> 
>
> Key: LOG4J2-1925
> URL: https://issues.apache.org/jira/browse/LOG4J2-1925
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.7, 2.8.2
> Environment: Oracle JDK 8
>Reporter: Trejkaz
>Priority: Blocker
>
> Background: Almost a week ago, our build started breaking with weird errors 
> on Javadoc. Initially only one user and the build machine were seeing it, but 
> it gradually spread and now happens for everyone on the team.
> Yesterday I spent most of the day investigating it and have cut it down to a 
> fairly minimal project, which I uploaded here: 
> https://github.com/trejkaz/gradle_wtf_compile
> The project name does contain "gradle" because at the time we had assumed 
> Gradle was to blame. However, this has since been removed from the list of 
> potential culprits, and all that's left now is log4j and javac itself. Given 
> that Oracle are near to useless at fixing even critical bugs, I figured 
> reporting it here would be a good next step in case it turns out to be 
> log4j's fault.
> Basically, if I have code like this:
> {code:java}
> /**
>  * Example utility class.
>  */
> public class Utils
> {
> /**
>  * Does stuff
>  *
>  * @throws Exception if an error occurs.
>  */
> public static void checkProject1() throws Exception
> {
> // empty
> }
> // ...
> }
> {code}
> And I try to build the code:
> {code:sh}
> mkdir -p build/classes/main
> javac -source 1.8 -target 1.8 -d build/classes/main \
>   -classpath 
> $HOME/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-core/2.8.2/979fc0cf8460302e4ffbfe38c1b66a99450b0bb7/log4j-core-2.8.2.jar:$HOME/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-api/2.8.2/e590eeb783348ce8ddef205b82127f9084d82bf3/log4j-api-2.8.2.jar
>  \
>   -Xlint:all,-serial -Xdoclint:all,-missing \
>   src/main/java/com/acme/Utils.java
> {code}
> I get an error:
> {noformat}
> src/main/java/com/acme/Utils.java:13: error: invalid use of @throws
>  * @throws Exception if an error occurs.
>^
> src/main/java/com/acme/Utils.java:23: error: invalid use of @throws
>  * @throws RuntimeException if an error occurs.
>^
> src/main/java/com/acme/Utils.java:33: error: invalid use of @throws
>  * @throws IOException if an error occurs.
>^
> 3 errors
> {noformat}
> The error message supposedly occurs when the thing you provided is not an 
> exception, but that is not the case at all.
> If I remove log4j-core from the classpath, compilation succeeds. If I remove 
> -Xdoclint from the command-line, that dodges the problem during javac, but 
> then javadoc fails later in the build, so it isn't a solution.
> I have many questions...
> 1. How does just having this one jar on the classpath somehow break 
> compilation when I'm not even calling it?
> 2. How is it that we are the first ones to encounter this? I'm seeing it on 
> literally every platform, and have tested multiple versions of Java 8 that I 
> had on hand, and all of them behaved the same way. Maybe nobody is using Java 
> 8 and log4j in the same project yet, but it seems a bit unlikely.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (LOG4J2-1925) Having log4j-core on the compile classpath somehow breaks compilation even if I'm not calling it

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16032252#comment-16032252
 ] 

Ralph Goers edited comment on LOG4J2-1925 at 6/1/17 12:34 AM:
--

No, javadoc doesn't parse English. But it does require a full sentence in the 
method description so it will look for a period. For some reason it allows 
other words after that first sentence and they don't have to end with a period.

My suggestion would be to create an annotation processor that does nothing and 
include that on the classpath. If that fails then it is not a problem with 
Log4j.


was (Author: ralph.go...@dslextreme.com):
No, javadoc doesn't parse English. But it does require a full sentence in the 
module description so it will look for a period. For some reason it allows 
other words after that first sentence and they don't have to end with a period.

My suggestion would be to create an annotation processor that does nothing and 
include that on the classpath. If that fails then it is not a problem with 
Log4j.

> Having log4j-core on the compile classpath somehow breaks compilation even if 
> I'm not calling it
> 
>
> Key: LOG4J2-1925
> URL: https://issues.apache.org/jira/browse/LOG4J2-1925
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.7, 2.8.2
> Environment: Oracle JDK 8
>Reporter: Trejkaz
>Priority: Blocker
>
> Background: Almost a week ago, our build started breaking with weird errors 
> on Javadoc. Initially only one user and the build machine were seeing it, but 
> it gradually spread and now happens for everyone on the team.
> Yesterday I spent most of the day investigating it and have cut it down to a 
> fairly minimal project, which I uploaded here: 
> https://github.com/trejkaz/gradle_wtf_compile
> The project name does contain "gradle" because at the time we had assumed 
> Gradle was to blame. However, this has since been removed from the list of 
> potential culprits, and all that's left now is log4j and javac itself. Given 
> that Oracle are near to useless at fixing even critical bugs, I figured 
> reporting it here would be a good next step in case it turns out to be 
> log4j's fault.
> Basically, if I have code like this:
> {code:java}
> /**
>  * Example utility class.
>  */
> public class Utils
> {
> /**
>  * Does stuff
>  *
>  * @throws Exception if an error occurs.
>  */
> public static void checkProject1() throws Exception
> {
> // empty
> }
> // ...
> }
> {code}
> And I try to build the code:
> {code:sh}
> mkdir -p build/classes/main
> javac -source 1.8 -target 1.8 -d build/classes/main \
>   -classpath 
> $HOME/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-core/2.8.2/979fc0cf8460302e4ffbfe38c1b66a99450b0bb7/log4j-core-2.8.2.jar:$HOME/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-api/2.8.2/e590eeb783348ce8ddef205b82127f9084d82bf3/log4j-api-2.8.2.jar
>  \
>   -Xlint:all,-serial -Xdoclint:all,-missing \
>   src/main/java/com/acme/Utils.java
> {code}
> I get an error:
> {noformat}
> src/main/java/com/acme/Utils.java:13: error: invalid use of @throws
>  * @throws Exception if an error occurs.
>^
> src/main/java/com/acme/Utils.java:23: error: invalid use of @throws
>  * @throws RuntimeException if an error occurs.
>^
> src/main/java/com/acme/Utils.java:33: error: invalid use of @throws
>  * @throws IOException if an error occurs.
>^
> 3 errors
> {noformat}
> The error message supposedly occurs when the thing you provided is not an 
> exception, but that is not the case at all.
> If I remove log4j-core from the classpath, compilation succeeds. If I remove 
> -Xdoclint from the command-line, that dodges the problem during javac, but 
> then javadoc fails later in the build, so it isn't a solution.
> I have many questions...
> 1. How does just having this one jar on the classpath somehow break 
> compilation when I'm not even calling it?
> 2. How is it that we are the first ones to encounter this? I'm seeing it on 
> literally every platform, and have tested multiple versions of Java 8 that I 
> had on hand, and all of them behaved the same way. Maybe nobody is using Java 
> 8 and log4j in the same project yet, but it seems a bit unlikely.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (LOG4J2-1925) Having log4j-core on the compile classpath somehow breaks compilation even if I'm not calling it

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16032252#comment-16032252
 ] 

Ralph Goers edited comment on LOG4J2-1925 at 6/1/17 12:34 AM:
--

No, javadoc doesn't parse English. But it does require a full sentence in the 
module description so it will look for a period. For some reason it allows 
other words after that first sentence and they don't have to end with a period.

My suggestion would be to create an annotation processor that does nothing and 
include that on the classpath. If that fails then it is not a problem with 
Log4j.


was (Author: ralph.go...@dslextreme.com):
My suggestion would be to create an annotation processor that does nothing and 
include that on the classpath. If that fails then it is not a problem with 
Log4j.

> Having log4j-core on the compile classpath somehow breaks compilation even if 
> I'm not calling it
> 
>
> Key: LOG4J2-1925
> URL: https://issues.apache.org/jira/browse/LOG4J2-1925
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.7, 2.8.2
> Environment: Oracle JDK 8
>Reporter: Trejkaz
>Priority: Blocker
>
> Background: Almost a week ago, our build started breaking with weird errors 
> on Javadoc. Initially only one user and the build machine were seeing it, but 
> it gradually spread and now happens for everyone on the team.
> Yesterday I spent most of the day investigating it and have cut it down to a 
> fairly minimal project, which I uploaded here: 
> https://github.com/trejkaz/gradle_wtf_compile
> The project name does contain "gradle" because at the time we had assumed 
> Gradle was to blame. However, this has since been removed from the list of 
> potential culprits, and all that's left now is log4j and javac itself. Given 
> that Oracle are near to useless at fixing even critical bugs, I figured 
> reporting it here would be a good next step in case it turns out to be 
> log4j's fault.
> Basically, if I have code like this:
> {code:java}
> /**
>  * Example utility class.
>  */
> public class Utils
> {
> /**
>  * Does stuff
>  *
>  * @throws Exception if an error occurs.
>  */
> public static void checkProject1() throws Exception
> {
> // empty
> }
> // ...
> }
> {code}
> And I try to build the code:
> {code:sh}
> mkdir -p build/classes/main
> javac -source 1.8 -target 1.8 -d build/classes/main \
>   -classpath 
> $HOME/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-core/2.8.2/979fc0cf8460302e4ffbfe38c1b66a99450b0bb7/log4j-core-2.8.2.jar:$HOME/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-api/2.8.2/e590eeb783348ce8ddef205b82127f9084d82bf3/log4j-api-2.8.2.jar
>  \
>   -Xlint:all,-serial -Xdoclint:all,-missing \
>   src/main/java/com/acme/Utils.java
> {code}
> I get an error:
> {noformat}
> src/main/java/com/acme/Utils.java:13: error: invalid use of @throws
>  * @throws Exception if an error occurs.
>^
> src/main/java/com/acme/Utils.java:23: error: invalid use of @throws
>  * @throws RuntimeException if an error occurs.
>^
> src/main/java/com/acme/Utils.java:33: error: invalid use of @throws
>  * @throws IOException if an error occurs.
>^
> 3 errors
> {noformat}
> The error message supposedly occurs when the thing you provided is not an 
> exception, but that is not the case at all.
> If I remove log4j-core from the classpath, compilation succeeds. If I remove 
> -Xdoclint from the command-line, that dodges the problem during javac, but 
> then javadoc fails later in the build, so it isn't a solution.
> I have many questions...
> 1. How does just having this one jar on the classpath somehow break 
> compilation when I'm not even calling it?
> 2. How is it that we are the first ones to encounter this? I'm seeing it on 
> literally every platform, and have tested multiple versions of Java 8 that I 
> had on hand, and all of them behaved the same way. Maybe nobody is using Java 
> 8 and log4j in the same project yet, but it seems a bit unlikely.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (LOG4J2-1925) Having log4j-core on the compile classpath somehow breaks compilation even if I'm not calling it

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16032252#comment-16032252
 ] 

Ralph Goers commented on LOG4J2-1925:
-

My suggestion would be to create an annotation processor that does nothing and 
include that on the classpath. If that fails then it is not a problem with 
Log4j.

> Having log4j-core on the compile classpath somehow breaks compilation even if 
> I'm not calling it
> 
>
> Key: LOG4J2-1925
> URL: https://issues.apache.org/jira/browse/LOG4J2-1925
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.7, 2.8.2
> Environment: Oracle JDK 8
>Reporter: Trejkaz
>Priority: Blocker
>
> Background: Almost a week ago, our build started breaking with weird errors 
> on Javadoc. Initially only one user and the build machine were seeing it, but 
> it gradually spread and now happens for everyone on the team.
> Yesterday I spent most of the day investigating it and have cut it down to a 
> fairly minimal project, which I uploaded here: 
> https://github.com/trejkaz/gradle_wtf_compile
> The project name does contain "gradle" because at the time we had assumed 
> Gradle was to blame. However, this has since been removed from the list of 
> potential culprits, and all that's left now is log4j and javac itself. Given 
> that Oracle are near to useless at fixing even critical bugs, I figured 
> reporting it here would be a good next step in case it turns out to be 
> log4j's fault.
> Basically, if I have code like this:
> {code:java}
> /**
>  * Example utility class.
>  */
> public class Utils
> {
> /**
>  * Does stuff
>  *
>  * @throws Exception if an error occurs.
>  */
> public static void checkProject1() throws Exception
> {
> // empty
> }
> // ...
> }
> {code}
> And I try to build the code:
> {code:sh}
> mkdir -p build/classes/main
> javac -source 1.8 -target 1.8 -d build/classes/main \
>   -classpath 
> $HOME/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-core/2.8.2/979fc0cf8460302e4ffbfe38c1b66a99450b0bb7/log4j-core-2.8.2.jar:$HOME/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-api/2.8.2/e590eeb783348ce8ddef205b82127f9084d82bf3/log4j-api-2.8.2.jar
>  \
>   -Xlint:all,-serial -Xdoclint:all,-missing \
>   src/main/java/com/acme/Utils.java
> {code}
> I get an error:
> {noformat}
> src/main/java/com/acme/Utils.java:13: error: invalid use of @throws
>  * @throws Exception if an error occurs.
>^
> src/main/java/com/acme/Utils.java:23: error: invalid use of @throws
>  * @throws RuntimeException if an error occurs.
>^
> src/main/java/com/acme/Utils.java:33: error: invalid use of @throws
>  * @throws IOException if an error occurs.
>^
> 3 errors
> {noformat}
> The error message supposedly occurs when the thing you provided is not an 
> exception, but that is not the case at all.
> If I remove log4j-core from the classpath, compilation succeeds. If I remove 
> -Xdoclint from the command-line, that dodges the problem during javac, but 
> then javadoc fails later in the build, so it isn't a solution.
> I have many questions...
> 1. How does just having this one jar on the classpath somehow break 
> compilation when I'm not even calling it?
> 2. How is it that we are the first ones to encounter this? I'm seeing it on 
> literally every platform, and have tested multiple versions of Java 8 that I 
> had on hand, and all of them behaved the same way. Maybe nobody is using Java 
> 8 and log4j in the same project yet, but it seems a bit unlikely.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (LOG4J2-1925) Having log4j-core on the compile classpath somehow breaks compilation even if I'm not calling it

[Trejkaz (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16032248#comment-16032248
 ] 

Trejkaz commented on LOG4J2-1925:
-

I'm pretty sure javadoc doesn't support parsing English to check the grammar.

But -proc:none somehow fixes it.

Turning off doclint is not a good idea because then you get invalid javadoc 
references, invalid HTML and other issues that you find out about through user 
bug reports down the track.


> Having log4j-core on the compile classpath somehow breaks compilation even if 
> I'm not calling it
> 
>
> Key: LOG4J2-1925
> URL: https://issues.apache.org/jira/browse/LOG4J2-1925
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.7, 2.8.2
> Environment: Oracle JDK 8
>Reporter: Trejkaz
>Priority: Blocker
>
> Background: Almost a week ago, our build started breaking with weird errors 
> on Javadoc. Initially only one user and the build machine were seeing it, but 
> it gradually spread and now happens for everyone on the team.
> Yesterday I spent most of the day investigating it and have cut it down to a 
> fairly minimal project, which I uploaded here: 
> https://github.com/trejkaz/gradle_wtf_compile
> The project name does contain "gradle" because at the time we had assumed 
> Gradle was to blame. However, this has since been removed from the list of 
> potential culprits, and all that's left now is log4j and javac itself. Given 
> that Oracle are near to useless at fixing even critical bugs, I figured 
> reporting it here would be a good next step in case it turns out to be 
> log4j's fault.
> Basically, if I have code like this:
> {code:java}
> /**
>  * Example utility class.
>  */
> public class Utils
> {
> /**
>  * Does stuff
>  *
>  * @throws Exception if an error occurs.
>  */
> public static void checkProject1() throws Exception
> {
> // empty
> }
> // ...
> }
> {code}
> And I try to build the code:
> {code:sh}
> mkdir -p build/classes/main
> javac -source 1.8 -target 1.8 -d build/classes/main \
>   -classpath 
> $HOME/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-core/2.8.2/979fc0cf8460302e4ffbfe38c1b66a99450b0bb7/log4j-core-2.8.2.jar:$HOME/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-api/2.8.2/e590eeb783348ce8ddef205b82127f9084d82bf3/log4j-api-2.8.2.jar
>  \
>   -Xlint:all,-serial -Xdoclint:all,-missing \
>   src/main/java/com/acme/Utils.java
> {code}
> I get an error:
> {noformat}
> src/main/java/com/acme/Utils.java:13: error: invalid use of @throws
>  * @throws Exception if an error occurs.
>^
> src/main/java/com/acme/Utils.java:23: error: invalid use of @throws
>  * @throws RuntimeException if an error occurs.
>^
> src/main/java/com/acme/Utils.java:33: error: invalid use of @throws
>  * @throws IOException if an error occurs.
>^
> 3 errors
> {noformat}
> The error message supposedly occurs when the thing you provided is not an 
> exception, but that is not the case at all.
> If I remove log4j-core from the classpath, compilation succeeds. If I remove 
> -Xdoclint from the command-line, that dodges the problem during javac, but 
> then javadoc fails later in the build, so it isn't a solution.
> I have many questions...
> 1. How does just having this one jar on the classpath somehow break 
> compilation when I'm not even calling it?
> 2. How is it that we are the first ones to encounter this? I'm seeing it on 
> literally every platform, and have tested multiple versions of Java 8 that I 
> had on hand, and all of them behaved the same way. Maybe nobody is using Java 
> 8 and log4j in the same project yet, but it seems a bit unlikely.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (LOG4J2-1925) Having log4j-core on the compile classpath somehow breaks compilation even if I'm not calling it

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16032233#comment-16032233
 ] 

Ralph Goers edited comment on LOG4J2-1925 at 6/1/17 12:16 AM:
--

Log4j-core has an annotation processor that will run by default when it is on 
the classpath. You could verify that it is causing the problem by compiling 
with -proc: none when you invoke javac. That said, I have no idea why it would 
be causing failures in javadoc. This makes me wonder if any annotation 
processor would cause the problem.

I suspect many people follow the suggestion at 
http://blog.joda.org/2014/02/turning-off-doclint-in-jdk-8-javadoc.html to 
disable doclint. Log4j does.

BTW - "Does stuff" should cause at least a warning since it doesn't end with a 
period.


was (Author: ralph.go...@dslextreme.com):
Log4j-core has an annotation processor that will run by default when it is on 
the classpath. You could verify that it is causing the problem by compiling 
with -proc: none when you invoke javac. That said, I have no idea why it would 
be causing failures in javadoc.

I suspect many people follow the suggestion at 
http://blog.joda.org/2014/02/turning-off-doclint-in-jdk-8-javadoc.html to 
disable doclint. Log4j does.

BTW - "Does stuff" should cause at least a warning since it doesn't end with a 
period.

> Having log4j-core on the compile classpath somehow breaks compilation even if 
> I'm not calling it
> 
>
> Key: LOG4J2-1925
> URL: https://issues.apache.org/jira/browse/LOG4J2-1925
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.7, 2.8.2
> Environment: Oracle JDK 8
>Reporter: Trejkaz
>Priority: Blocker
>
> Background: Almost a week ago, our build started breaking with weird errors 
> on Javadoc. Initially only one user and the build machine were seeing it, but 
> it gradually spread and now happens for everyone on the team.
> Yesterday I spent most of the day investigating it and have cut it down to a 
> fairly minimal project, which I uploaded here: 
> https://github.com/trejkaz/gradle_wtf_compile
> The project name does contain "gradle" because at the time we had assumed 
> Gradle was to blame. However, this has since been removed from the list of 
> potential culprits, and all that's left now is log4j and javac itself. Given 
> that Oracle are near to useless at fixing even critical bugs, I figured 
> reporting it here would be a good next step in case it turns out to be 
> log4j's fault.
> Basically, if I have code like this:
> {code:java}
> /**
>  * Example utility class.
>  */
> public class Utils
> {
> /**
>  * Does stuff
>  *
>  * @throws Exception if an error occurs.
>  */
> public static void checkProject1() throws Exception
> {
> // empty
> }
> // ...
> }
> {code}
> And I try to build the code:
> {code:sh}
> mkdir -p build/classes/main
> javac -source 1.8 -target 1.8 -d build/classes/main \
>   -classpath 
> $HOME/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-core/2.8.2/979fc0cf8460302e4ffbfe38c1b66a99450b0bb7/log4j-core-2.8.2.jar:$HOME/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-api/2.8.2/e590eeb783348ce8ddef205b82127f9084d82bf3/log4j-api-2.8.2.jar
>  \
>   -Xlint:all,-serial -Xdoclint:all,-missing \
>   src/main/java/com/acme/Utils.java
> {code}
> I get an error:
> {noformat}
> src/main/java/com/acme/Utils.java:13: error: invalid use of @throws
>  * @throws Exception if an error occurs.
>^
> src/main/java/com/acme/Utils.java:23: error: invalid use of @throws
>  * @throws RuntimeException if an error occurs.
>^
> src/main/java/com/acme/Utils.java:33: error: invalid use of @throws
>  * @throws IOException if an error occurs.
>^
> 3 errors
> {noformat}
> The error message supposedly occurs when the thing you provided is not an 
> exception, but that is not the case at all.
> If I remove log4j-core from the classpath, compilation succeeds. If I remove 
> -Xdoclint from the command-line, that dodges the problem during javac, but 
> then javadoc fails later in the build, so it isn't a solution.
> I have many questions...
> 1. How does just having this one jar on the classpath somehow break 
> compilation when I'm not even calling it?
> 2. How is it that we are the first ones to encounter this? I'm seeing it on 
> literally every platform, and have tested multiple versions of Java 8 that I 
> had on hand, and all of them behaved the same way. Maybe nobody is using Java 
> 8 and log4j in the same project yet, but it seems a bit unlikely.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (LOG4J2-1925) Having log4j-core on the compile classpath somehow breaks compilation even if I'm not calling it

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16032233#comment-16032233
 ] 

Ralph Goers edited comment on LOG4J2-1925 at 6/1/17 12:03 AM:
--

Log4j-core has an annotation processor that will run by default when it is on 
the classpath. You could verify that it is causing the problem by compiling 
with -proc: none when you invoke javac. That said, I have no idea why it would 
be causing failures in javadoc.

BTW - "Does stuff" should cause at least a warning since it doesn't end with a 
period.


was (Author: ralph.go...@dslextreme.com):
Log4j-core has an annotation processor that will run by default when it is on 
the classpath. You could verify that it is causing the problem by compiling 
with -proc: none when you invoke javac. That said, I have no idea why it would 
be causing failures in javadoc.

> Having log4j-core on the compile classpath somehow breaks compilation even if 
> I'm not calling it
> 
>
> Key: LOG4J2-1925
> URL: https://issues.apache.org/jira/browse/LOG4J2-1925
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.7, 2.8.2
> Environment: Oracle JDK 8
>Reporter: Trejkaz
>Priority: Blocker
>
> Background: Almost a week ago, our build started breaking with weird errors 
> on Javadoc. Initially only one user and the build machine were seeing it, but 
> it gradually spread and now happens for everyone on the team.
> Yesterday I spent most of the day investigating it and have cut it down to a 
> fairly minimal project, which I uploaded here: 
> https://github.com/trejkaz/gradle_wtf_compile
> The project name does contain "gradle" because at the time we had assumed 
> Gradle was to blame. However, this has since been removed from the list of 
> potential culprits, and all that's left now is log4j and javac itself. Given 
> that Oracle are near to useless at fixing even critical bugs, I figured 
> reporting it here would be a good next step in case it turns out to be 
> log4j's fault.
> Basically, if I have code like this:
> {code:java}
> /**
>  * Example utility class.
>  */
> public class Utils
> {
> /**
>  * Does stuff
>  *
>  * @throws Exception if an error occurs.
>  */
> public static void checkProject1() throws Exception
> {
> // empty
> }
> // ...
> }
> {code}
> And I try to build the code:
> {code:sh}
> mkdir -p build/classes/main
> javac -source 1.8 -target 1.8 -d build/classes/main \
>   -classpath 
> $HOME/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-core/2.8.2/979fc0cf8460302e4ffbfe38c1b66a99450b0bb7/log4j-core-2.8.2.jar:$HOME/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-api/2.8.2/e590eeb783348ce8ddef205b82127f9084d82bf3/log4j-api-2.8.2.jar
>  \
>   -Xlint:all,-serial -Xdoclint:all,-missing \
>   src/main/java/com/acme/Utils.java
> {code}
> I get an error:
> {noformat}
> src/main/java/com/acme/Utils.java:13: error: invalid use of @throws
>  * @throws Exception if an error occurs.
>^
> src/main/java/com/acme/Utils.java:23: error: invalid use of @throws
>  * @throws RuntimeException if an error occurs.
>^
> src/main/java/com/acme/Utils.java:33: error: invalid use of @throws
>  * @throws IOException if an error occurs.
>^
> 3 errors
> {noformat}
> The error message supposedly occurs when the thing you provided is not an 
> exception, but that is not the case at all.
> If I remove log4j-core from the classpath, compilation succeeds. If I remove 
> -Xdoclint from the command-line, that dodges the problem during javac, but 
> then javadoc fails later in the build, so it isn't a solution.
> I have many questions...
> 1. How does just having this one jar on the classpath somehow break 
> compilation when I'm not even calling it?
> 2. How is it that we are the first ones to encounter this? I'm seeing it on 
> literally every platform, and have tested multiple versions of Java 8 that I 
> had on hand, and all of them behaved the same way. Maybe nobody is using Java 
> 8 and log4j in the same project yet, but it seems a bit unlikely.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (LOG4J2-1925) Having log4j-core on the compile classpath somehow breaks compilation even if I'm not calling it

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16032233#comment-16032233
 ] 

Ralph Goers commented on LOG4J2-1925:
-

Log4j-core has an annotation processor that will run by default when it is on 
the classpath. You could verify that it is causing the problem by compiling 
with -proc: none when you invoke javac. That said, I have no idea why it would 
be causing failures in javadoc.

> Having log4j-core on the compile classpath somehow breaks compilation even if 
> I'm not calling it
> 
>
> Key: LOG4J2-1925
> URL: https://issues.apache.org/jira/browse/LOG4J2-1925
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.7, 2.8.2
> Environment: Oracle JDK 8
>Reporter: Trejkaz
>Priority: Blocker
>
> Background: Almost a week ago, our build started breaking with weird errors 
> on Javadoc. Initially only one user and the build machine were seeing it, but 
> it gradually spread and now happens for everyone on the team.
> Yesterday I spent most of the day investigating it and have cut it down to a 
> fairly minimal project, which I uploaded here: 
> https://github.com/trejkaz/gradle_wtf_compile
> The project name does contain "gradle" because at the time we had assumed 
> Gradle was to blame. However, this has since been removed from the list of 
> potential culprits, and all that's left now is log4j and javac itself. Given 
> that Oracle are near to useless at fixing even critical bugs, I figured 
> reporting it here would be a good next step in case it turns out to be 
> log4j's fault.
> Basically, if I have code like this:
> {code:java}
> /**
>  * Example utility class.
>  */
> public class Utils
> {
> /**
>  * Does stuff
>  *
>  * @throws Exception if an error occurs.
>  */
> public static void checkProject1() throws Exception
> {
> // empty
> }
> // ...
> }
> {code}
> And I try to build the code:
> {code:sh}
> mkdir -p build/classes/main
> javac -source 1.8 -target 1.8 -d build/classes/main \
>   -classpath 
> $HOME/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-core/2.8.2/979fc0cf8460302e4ffbfe38c1b66a99450b0bb7/log4j-core-2.8.2.jar:$HOME/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-api/2.8.2/e590eeb783348ce8ddef205b82127f9084d82bf3/log4j-api-2.8.2.jar
>  \
>   -Xlint:all,-serial -Xdoclint:all,-missing \
>   src/main/java/com/acme/Utils.java
> {code}
> I get an error:
> {noformat}
> src/main/java/com/acme/Utils.java:13: error: invalid use of @throws
>  * @throws Exception if an error occurs.
>^
> src/main/java/com/acme/Utils.java:23: error: invalid use of @throws
>  * @throws RuntimeException if an error occurs.
>^
> src/main/java/com/acme/Utils.java:33: error: invalid use of @throws
>  * @throws IOException if an error occurs.
>^
> 3 errors
> {noformat}
> The error message supposedly occurs when the thing you provided is not an 
> exception, but that is not the case at all.
> If I remove log4j-core from the classpath, compilation succeeds. If I remove 
> -Xdoclint from the command-line, that dodges the problem during javac, but 
> then javadoc fails later in the build, so it isn't a solution.
> I have many questions...
> 1. How does just having this one jar on the classpath somehow break 
> compilation when I'm not even calling it?
> 2. How is it that we are the first ones to encounter this? I'm seeing it on 
> literally every platform, and have tested multiple versions of Java 8 that I 
> had on hand, and all of them behaved the same way. Maybe nobody is using Java 
> 8 and log4j in the same project yet, but it seems a bit unlikely.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (LOG4J2-1925) Having log4j-core on the compile classpath somehow breaks compilation even if I'm not calling it

[Trejkaz (JIRA)]

Trejkaz created LOG4J2-1925:
---

 Summary: Having log4j-core on the compile classpath somehow breaks 
compilation even if I'm not calling it
 Key: LOG4J2-1925
 URL: https://issues.apache.org/jira/browse/LOG4J2-1925
 Project: Log4j 2
  Issue Type: Bug
  Components: Core
Affects Versions: 2.8.2, 2.7
 Environment: Oracle JDK 8
Reporter: Trejkaz
Priority: Blocker


Background: Almost a week ago, our build started breaking with weird errors on 
Javadoc. Initially only one user and the build machine were seeing it, but it 
gradually spread and now happens for everyone on the team.

Yesterday I spent most of the day investigating it and have cut it down to a 
fairly minimal project, which I uploaded here: 
https://github.com/trejkaz/gradle_wtf_compile

The project name does contain "gradle" because at the time we had assumed 
Gradle was to blame. However, this has since been removed from the list of 
potential culprits, and all that's left now is log4j and javac itself. Given 
that Oracle are near to useless at fixing even critical bugs, I figured 
reporting it here would be a good next step in case it turns out to be log4j's 
fault.

Basically, if I have code like this:

{code:java}
/**
 * Example utility class.
 */
public class Utils
{
/**
 * Does stuff
 *
 * @throws Exception if an error occurs.
 */
public static void checkProject1() throws Exception
{
// empty
}

// ...
}
{code}

And I try to build the code:

{code:sh}
mkdir -p build/classes/main

javac -source 1.8 -target 1.8 -d build/classes/main \
  -classpath 
$HOME/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-core/2.8.2/979fc0cf8460302e4ffbfe38c1b66a99450b0bb7/log4j-core-2.8.2.jar:$HOME/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-api/2.8.2/e590eeb783348ce8ddef205b82127f9084d82bf3/log4j-api-2.8.2.jar
 \
  -Xlint:all,-serial -Xdoclint:all,-missing \
  src/main/java/com/acme/Utils.java
{code}

I get an error:

{noformat}
src/main/java/com/acme/Utils.java:13: error: invalid use of @throws
 * @throws Exception if an error occurs.
   ^
src/main/java/com/acme/Utils.java:23: error: invalid use of @throws
 * @throws RuntimeException if an error occurs.
   ^
src/main/java/com/acme/Utils.java:33: error: invalid use of @throws
 * @throws IOException if an error occurs.
   ^
3 errors
{noformat}

The error message supposedly occurs when the thing you provided is not an 
exception, but that is not the case at all.

If I remove log4j-core from the classpath, compilation succeeds. If I remove 
-Xdoclint from the command-line, that dodges the problem during javac, but then 
javadoc fails later in the build, so it isn't a solution.

I have many questions...

1. How does just having this one jar on the classpath somehow break compilation 
when I'm not even calling it?
2. How is it that we are the first ones to encounter this? I'm seeing it on 
literally every platform, and have tested multiple versions of Java 8 that I 
had on hand, and all of them behaved the same way. Maybe nobody is using Java 8 
and log4j in the same project yet, but it seems a bit unlikely.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (LOG4J2-1924) The JMS Appender should use a JMS MapMessage for a Log4j MapMessage

[Gary Gregory (JIRA)]

Gary Gregory created LOG4J2-1924:


 Summary: The JMS Appender should use a JMS MapMessage for a Log4j 
MapMessage
 Key: LOG4J2-1924
 URL: https://issues.apache.org/jira/browse/LOG4J2-1924
 Project: Log4j 2
  Issue Type: New Feature
  Components: Appenders
Reporter: Gary Gregory
Assignee: Gary Gregory


The JMS Appender should use a JMS {{javax.jms.MapMessage}} for a Log4j 
{{org.apache.logging.log4j.message.MapMessage}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Log4j2 APIs on Android

[Oleg Kalnichevski]

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 
> 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 
> > > 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

[Remko Popma]

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  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  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

[Matt Sicker]

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  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  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 

Re: Log4j2 APIs on Android

[Oleg Kalnichevski]

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  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

[Matt Sicker]

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  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 

Log4j2 APIs on Android

[Oleg Kalnichevski]

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