Log4J2-API-Java9 Build Failure

I am running Ubuntu 16.04.2 LTS AMD 64 The sole purpose of my laptop is to get this build to work. I've literally reformatted my machine just for this project and I'm at my wits end trying to figure this out after googling for 2 days. I've made sure the POM reflects the correct path to my jdk,

[jira] [Commented] (LOG4J2-1973) FailoverAppenders fail to start

[ https://issues.apache.org/jira/browse/LOG4J2-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16081581#comment-16081581 ] Remko Popma commented on LOG4J2-1973: - The configuration looks correct but initialization fails

[jira] [Commented] (LOG4J2-1971) ClassCastException: org.eclipse.osgi.internal.loader.SystemBundleLoader$1 cannot be cast to java.lang.ClassLoader

[ https://issues.apache.org/jira/browse/LOG4J2-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16081177#comment-16081177 ] Gary Gregory commented on LOG4J2-1971: -- I refactored the code to make the check on both cases.

Re: [Log4j] 2.9 release and Java 9

> On Jul 10, 2017, at 3:12 PM, Matt Sicker wrote: > > Does the log4j-android module shade in log4j-api or something? If not, we > still have the same exact initial problem of Java 9 classes being in the > jar. It specifically excludes the Java 9 class(es) under META-INF.

Re: [Log4j] 2.9 release and Java 9

Does the log4j-android module shade in log4j-api or something? If not, we still have the same exact initial problem of Java 9 classes being in the jar. On 10 July 2017 at 17:08, Remko Popma wrote: > I think both Gary and myself had the same misunderstanding about >

Re: [Log4j] 2.9 release and Java 9

Forgot to add the link: . Lots of people involved. On 10 July 2017 at 17:19, Matt Sicker wrote: > OSGi's biggest contributors are Adobe, Bosch, Deutsche Telekom, Huawei, > IBM, Liferay, NTT, Oracle (surprisingly), Paremus, and Software

Re: logging-log4j2 git commit: [LOG4J2-1976] Update org.osgi.core from 4.3.1 to 6.0.0.

I don't think we have any tests for that. Karaf uses pax-logging-log4j2 which shades in log4j-api and log4j-core together for some reason. I've made some commits on that project before, though I'm not sure why everything is shaded. On 10 July 2017 at 16:53, Gary Gregory

Re: logging-log4j2 git commit: [LOG4J2-1976] Update org.osgi.core from 4.3.1 to 6.0.0.

Even version 6 is three years old... the one we had in there was over 10 IIRC G On Jul 10, 2017 14:42, "Matt Sicker" wrote: > Now I'll admit that I'm not using OSGi anymore nowadays (different client, > different requirements, right?), so I'm not sure on what a reasonable >

Re: [Log4j] 2.9 release and Java 9

> On Jul 10, 2017, at 2:58 PM, Gary Gregory wrote: > > On Mon, Jul 10, 2017 at 2:52 PM, Gary Gregory > wrote: > >> >> >> On Jul 10, 2017 14:40, "Matt Sicker" wrote: >> >> 1. The stack is walked every time the LoggerContext

Re: logging-log4j2 git commit: [LOG4J2-1976] Update org.osgi.core from 4.3.1 to 6.0.0.

WRT Karaf, do we even have tests for that? G On Jul 10, 2017 14:42, "Matt Sicker" wrote: > Now I'll admit that I'm not using OSGi anymore nowadays (different client, > different requirements, right?), so I'm not sure on what a reasonable > baseline requirement is for the OSGi

Re: [Log4j] 2.9 release and Java 9

I think both Gary and myself had the same misunderstanding about log4j-api-android. I didn't realize it contains a bridge/adapter to the Android logging implementation until you mentioned it. Would `log4j-api-android-impl` be a better name? (Shameless plug) Every java main() method deserves

Re: [Log4j] 2.9 release and Java 9

That was just a random example. I can't imagine most of the core appenders are useful in Android, and that includes the ones that use Java SE classes only. On 10 July 2017 at 16:52, Gary Gregory wrote: > On Jul 10, 2017 14:40, "Matt Sicker" wrote: > >

Re: [Log4j] 2.9 release and Java 9

The META-INF directory is the only standardized directory in a jar file that's not supposed to be interpreted as containing code. Sure, there are other -INF directories that other tools make like OSGI-INF, BOOT-INF, WEB-INF, etc. It seems like a logical place. I don't know why the Android plugin

Re: [Log4j] 2.9 release and Java 9

On Mon, Jul 10, 2017 at 2:52 PM, Gary Gregory wrote: > > > On Jul 10, 2017 14:40, "Matt Sicker" wrote: > > 1. The stack is walked every time the LoggerContext has to be determined > dynamically. This would be a really shitty tradeoff to remove. > 2. I

Re: [Log4j] 2.9 release and Java 9

On Jul 10, 2017 14:40, "Matt Sicker" wrote: 1. The stack is walked every time the LoggerContext has to be determined dynamically. This would be a really shitty tradeoff to remove. 2. I personally care more about supporting standard Java than Google's bastardization, so I'm more

Re: logging-log4j2 git commit: [LOG4J2-1976] Update org.osgi.core from 4.3.1 to 6.0.0.

Now I'll admit that I'm not using OSGi anymore nowadays (different client, different requirements, right?), so I'm not sure on what a reasonable baseline requirement is for the OSGi API. This should be fine, though at worst we might want to drop it down to 5.0.0. I'm thinking it would be

[jira] [Comment Edited] (LOG4J2-1971) ClassCastException: org.eclipse.osgi.internal.loader.SystemBundleLoader$1 cannot be cast to java.lang.ClassLoader

[ https://issues.apache.org/jira/browse/LOG4J2-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16081177#comment-16081177 ] Gary Gregory edited comment on LOG4J2-1971 at 7/10/17 9:25 PM: --- Hello, I

[jira] [Resolved] (LOG4J2-1971) ClassCastException: org.eclipse.osgi.internal.loader.SystemBundleLoader$1 cannot be cast to java.lang.ClassLoader

[ https://issues.apache.org/jira/browse/LOG4J2-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved LOG4J2-1971. -- Resolution: Fixed Fix Version/s: 2.9 > ClassCastException:

Re: [Log4j] 2.9 release and Java 9

1. The stack is walked every time the LoggerContext has to be determined dynamically. This would be a really shitty tradeoff to remove. 2. I personally care more about supporting standard Java than Google's bastardization, so I'm more in support of the replaceable jar. It also provides a way to

[jira] [Created] (LOG4J2-1976) Update org.osgi.core from 4.3.1 to 6.0.0

Gary Gregory created LOG4J2-1976: Summary: Update org.osgi.core from 4.3.1 to 6.0.0 Key: LOG4J2-1976 URL: https://issues.apache.org/jira/browse/LOG4J2-1976 Project: Log4j 2 Issue Type: Task

[jira] [Commented] (LOG4J2-1976) Update org.osgi.core from 4.3.1 to 6.0.0

[ https://issues.apache.org/jira/browse/LOG4J2-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16081188#comment-16081188 ] ASF subversion and git services commented on LOG4J2-1976: - Commit

Re: [Log4j] 2.9 release and Java 9

I would also like to reiterate that StackWalker has to stay for Java 9. The last time I benchmarked walking the stack in Java 9 was slower than in Java 8 when not using StackWalker. See https://github.com/rgoers/stack-walker-benchmark . Ralph

[jira] [Commented] (LOG4J2-1967) Unable to invoke factory method in class class org.apache.logging.log4j.core.appender.RollingFileAppender for element RollingFile

[ https://issues.apache.org/jira/browse/LOG4J2-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080988#comment-16080988 ] Gary Gregory commented on LOG4J2-1967: -- In Git master, in log4j-core, test sources. > Unable to

Re: Starting and restarting managers

I know I know, just brainfarting aloud... No water cooler ;-) On Jul 10, 2017 11:50, "Ralph Goers" wrote: > How is that any different than creating a new manager as your recovery > logic? Remember, the reason for doing this is a) the managers live across >

Re: [Log4j] 2.9 release and Java 9

> On Jul 10, 2017, at 1:48 PM, Ralph Goers wrote: > > >> On Jul 10, 2017, at 1:25 PM, Mikael Ståldal wrote: >> >> Exactly. It would be better with a log4j-api that works on Android and then >> a log4j-android module as an alternative to

Re: [Log4j] 2.9 release and Java 9

A log4j-api-android jar is a terrible idea and confusing: Wouldn't the only difference with log4j-api be that the Java 9 optimization be absent? If so, that's a LOT of code duplication for no gain IMO. The KISS solution is a log4j-api-java9 jar with the Java 9-specific code, right now, just the

[jira] [Commented] (LOG4J2-1864) Support capped collection for MongoDB Log-Provider

[ https://issues.apache.org/jira/browse/LOG4J2-1864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080972#comment-16080972 ] ASF GitHub Bot commented on LOG4J2-1864: Github user garydgregory commented on the issue:

Re: [Log4j] 2.9 release and Java 9

We cannot say "on Android use Log4j 2.8" due to the problems you fixed in https://issues.apache.org/jira/browse/LOG4J2-1926 On 2017-07-10 14:33, Remko Popma wrote: However, I wouldn't mind saying Log4j 2.9 supports Java 9 but not Android; on Android use Log4j 2.8.

Re: [Log4j] 2.9 release and Java 9

Exactly. It would be better with a log4j-api that works on Android and then a log4j-android module as an alternative to log4j-core. On 2017-07-10 14:33, Remko Popma wrote: One problem with the log4j-api-android idea is that it doesn't cover other libraries that bring in a dependency to

[GitHub] logging-log4j2 issue #62: (LOG4J2-1864) Support capped collection for MongoD...

Github user garydgregory commented on the issue: https://github.com/apache/logging-log4j2/pull/62 Don't forget to update the docs please. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this

[jira] [Commented] (LOG4J2-1967) Unable to invoke factory method in class class org.apache.logging.log4j.core.appender.RollingFileAppender for element RollingFile

[ https://issues.apache.org/jira/browse/LOG4J2-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080959#comment-16080959 ] Paul K commented on LOG4J2-1967: Gary, where can I find your test java classes?

Re: Starting and restarting managers

How is that any different than creating a new manager as your recovery logic? Remember, the reason for doing this is a) the managers live across reconfigurations while appenders don’t and b) the appenders should be fairly simple - the managers deal with all these kinds of complexities. For

[GitHub] logging-log4j2 issue #62: (LOG4J2-1864) Support capped collection for MongoD...

Github user jvz commented on the issue: https://github.com/apache/logging-log4j2/pull/62 Alright, everything looks fine to merge then. @mikaelstaldal you can merge this if you have time. --- If your project is set up for it, you can reply to this email and have your reply appear on

[jira] [Commented] (LOG4J2-1864) Support capped collection for MongoDB Log-Provider

[ https://issues.apache.org/jira/browse/LOG4J2-1864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080862#comment-16080862 ] ASF GitHub Bot commented on LOG4J2-1864: Github user jvz commented on a diff in the pull request:

[GitHub] logging-log4j2 pull request #62: (LOG4J2-1864) Support capped collection for...

Github user jvz commented on a diff in the pull request: https://github.com/apache/logging-log4j2/pull/62#discussion_r126505047 --- Diff: log4j-nosql/src/main/java/org/apache/logging/log4j/nosql/appender/mongodb/MongoDbProvider.java --- @@ -21,50 +21,60 @@ import

[jira] [Commented] (LOG4J2-1864) Support capped collection for MongoDB Log-Provider

[ https://issues.apache.org/jira/browse/LOG4J2-1864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080847#comment-16080847 ] ASF GitHub Bot commented on LOG4J2-1864: Github user codescale commented on a diff in the pull

[jira] [Commented] (LOG4J2-1864) Support capped collection for MongoDB Log-Provider

[ https://issues.apache.org/jira/browse/LOG4J2-1864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080848#comment-16080848 ] ASF GitHub Bot commented on LOG4J2-1864: Github user codescale commented on a diff in the pull

[jira] [Commented] (LOG4J2-1864) Support capped collection for MongoDB Log-Provider

[ https://issues.apache.org/jira/browse/LOG4J2-1864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080849#comment-16080849 ] ASF GitHub Bot commented on LOG4J2-1864: Github user codescale commented on a diff in the pull

[jira] [Commented] (LOG4J2-1864) Support capped collection for MongoDB Log-Provider

[ https://issues.apache.org/jira/browse/LOG4J2-1864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080850#comment-16080850 ] ASF GitHub Bot commented on LOG4J2-1864: Github user codescale commented on a diff in the pull

[GitHub] logging-log4j2 pull request #62: (LOG4J2-1864) Support capped collection for...

Github user codescale commented on a diff in the pull request: https://github.com/apache/logging-log4j2/pull/62#discussion_r126504007 --- Diff: log4j-nosql/src/main/java/org/apache/logging/log4j/nosql/appender/mongodb/MongoDbProvider.java --- @@ -93,130 +103,249 @@ public String

[jira] [Closed] (LOG4J2-1974) Update ZeroMQ's JeroMQ from 0.4.1 to 0.4.2.

[ https://issues.apache.org/jira/browse/LOG4J2-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed LOG4J2-1974. Resolution: Fixed Fix Version/s: 2.9 In Git master. > Update ZeroMQ's JeroMQ from 0.4.1 to

[jira] [Created] (LOG4J2-1974) Update ZeroMQ's JeroMQ from 0.4.1 to 0.4.2.

Gary Gregory created LOG4J2-1974: Summary: Update ZeroMQ's JeroMQ from 0.4.1 to 0.4.2. Key: LOG4J2-1974 URL: https://issues.apache.org/jira/browse/LOG4J2-1974 Project: Log4j 2 Issue Type:

Re: Starting and restarting managers

Another idea, possibly whacky, is for an Appender to have two managers. When one goes bad, you initialize the 2nd based on the same factory data, then close the 1st one. The 2nd becomes current, rinse, repeat. Not sure how this fits in w manager cacheing. Gary On Jun 28, 2017 13:37, "Matt

[jira] [Commented] (LOG4J2-928) Lock-free synchronous sub-microsecond appender

[ https://issues.apache.org/jira/browse/LOG4J2-928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080779#comment-16080779 ] Gary Gregory commented on LOG4J2-928: - We really need a "Choosing a file Appender" section in our

[jira] [Commented] (LOG4J2-1864) Support capped collection for MongoDB Log-Provider

[ https://issues.apache.org/jira/browse/LOG4J2-1864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080636#comment-16080636 ] ASF GitHub Bot commented on LOG4J2-1864: Github user jvz commented on a diff in the pull request:

[GitHub] logging-log4j2 pull request #62: (LOG4J2-1864) Support capped collection for...

Github user jvz commented on a diff in the pull request: https://github.com/apache/logging-log4j2/pull/62#discussion_r126478075 --- Diff: log4j-nosql/src/main/java/org/apache/logging/log4j/nosql/appender/mongodb/MongoDbProvider.java --- @@ -93,130 +103,249 @@ public String

[jira] [Commented] (LOG4J2-1864) Support capped collection for MongoDB Log-Provider

[ https://issues.apache.org/jira/browse/LOG4J2-1864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080635#comment-16080635 ] ASF GitHub Bot commented on LOG4J2-1864: Github user jvz commented on a diff in the pull request:

[jira] [Commented] (LOG4J2-1864) Support capped collection for MongoDB Log-Provider

[ https://issues.apache.org/jira/browse/LOG4J2-1864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080638#comment-16080638 ] ASF GitHub Bot commented on LOG4J2-1864: Github user jvz commented on a diff in the pull request:

[GitHub] logging-log4j2 pull request #62: (LOG4J2-1864) Support capped collection for...

Github user jvz commented on a diff in the pull request: https://github.com/apache/logging-log4j2/pull/62#discussion_r126477831 --- Diff: log4j-nosql/src/main/java/org/apache/logging/log4j/nosql/appender/mongodb/MongoDbProvider.java --- @@ -93,130 +103,249 @@ public String

[jira] [Commented] (LOG4J2-928) Lock-free synchronous sub-microsecond appender

[ https://issues.apache.org/jira/browse/LOG4J2-928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080598#comment-16080598 ] ASF GitHub Bot commented on LOG4J2-928: --- Github user leventov commented on the issue:

[jira] [Created] (LOG4J2-1973) FailoverAppenders fail to start

Vina Martin created LOG4J2-1973: --- Summary: FailoverAppenders fail to start Key: LOG4J2-1973 URL: https://issues.apache.org/jira/browse/LOG4J2-1973 Project: Log4j 2 Issue Type: Bug

[jira] [Commented] (LOG4J2-928) Lock-free synchronous sub-microsecond appender

[ https://issues.apache.org/jira/browse/LOG4J2-928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080621#comment-16080621 ] ASF GitHub Bot commented on LOG4J2-928: --- Github user jvz commented on the issue:

[GitHub] logging-log4j2 issue #87: [LOG4J2-928] Mostly wait-free MemoryMappedFileMana...

Github user jvz commented on the issue: https://github.com/apache/logging-log4j2/pull/87 The Java 9 stuff sounds interesting. We may need to add a multi-version JAR build for log4j-core as well (we have one for log4j-api so far) if it can't reasonably done via reflection. --- If

[jira] [Commented] (LOG4J2-928) Lock-free synchronous sub-microsecond appender

[ https://issues.apache.org/jira/browse/LOG4J2-928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080607#comment-16080607 ] ASF GitHub Bot commented on LOG4J2-928: --- Github user leventov commented on the issue:

[GitHub] logging-log4j2 issue #87: [LOG4J2-928] Mostly wait-free MemoryMappedFileMana...

Github user leventov commented on the issue: https://github.com/apache/logging-log4j2/pull/87 Also recent addition of "write touch" seems to improve throughput considerably, so the numbers posted above are irrelevant now. --- If your project is set up for it, you can reply to this

[GitHub] logging-log4j2 issue #87: [LOG4J2-928] Mostly wait-free MemoryMappedFileMana...

Github user leventov commented on the issue: https://github.com/apache/logging-log4j2/pull/87 Things still TODO / TBD in this PR: - **Why on extreme loads the new version has significantly worse tail latency?** - StringBuilderEncoder.DEFAULT_BYTE_BUFFER_SIZE (8k) effectively

[jira] [Commented] (LOG4J2-928) Lock-free synchronous sub-microsecond appender

[ https://issues.apache.org/jira/browse/LOG4J2-928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080582#comment-16080582 ] ASF GitHub Bot commented on LOG4J2-928: --- Github user leventov commented on the issue:

Re: [Log4j] 2.9 release and Java 9

As I said before, that can be handled by a dependency swap. Ralph > On Jul 10, 2017, at 5:33 AM, Remko Popma wrote: > > One problem with the log4j-api-android idea is that it doesn't cover other > libraries that bring in a dependency to log4j-api. > > However, I

Re: [Log4j] 2.9 release and Java 9

One problem with the log4j-api-android idea is that it doesn't cover other libraries that bring in a dependency to log4j-api. However, I wouldn't mind saying Log4j 2.9 supports Java 9 but not Android; on Android use Log4j 2.8. (Shameless plug) Every java main() method deserves

[jira] [Closed] (LOG4J2-1912) CompositeConfiguration logs warning "Unable to determine URI for configuration." However, the reconfiguration is completed.

[ https://issues.apache.org/jira/browse/LOG4J2-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] R Ri closed LOG4J2-1912. > CompositeConfiguration logs warning "Unable to determine URI for > configuration." However, the reconfiguration is

Re: [log4net] ci pipeline status update

If this was not about hacking it would be a lot easier to accomplish.  I found also out that it is good practice to add arguments to the dockerfile. This would then be the interface to pass in environment variables of jenkins. A good candidate could be WORKSPACE and extract uid and gid

Re: [log4net] ci pipeline status update

Alternatives that may allow us to do the same are gosu and su-exec. Note that sudo won't work. On 10 Jul 2017 10:25 a.m., "Dominik Psenner" wrote: > I just stumbled upon this which may allows us to detect the expected uid > that a docker container is run in when the docker

Re: [log4net] ci pipeline status update

On 2017-07-10, Dominik Psenner wrote: > I just stumbled upon this which may allows us to detect the expected uid > that a docker container is run in when the docker container is built. We > can use that information to prepare the docker container user so that its > uid and gid match the one we

Re: [log4net] ci pipeline status update

I just stumbled upon this which may allows us to detect the expected uid that a docker container is run in when the docker container is built. We can use that information to prepare the docker container user so that its uid and gid match the one we need later when the docker container is run:

[jira] [Commented] (LOG4J2-1921) Getting ClassCastException while getting LoggerContext

[ https://issues.apache.org/jira/browse/LOG4J2-1921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16079948#comment-16079948 ] Ajitha commented on LOG4J2-1921: Thanks for the interim update. > Getting ClassCastException while

[jira] [Created] (LOG4J2-1971) ClassCastException: org.eclipse.osgi.internal.loader.SystemBundleLoader$1 cannot be cast to java.lang.ClassLoader

liwenxian2017 created LOG4J2-1971: - Summary: ClassCastException: org.eclipse.osgi.internal.loader.SystemBundleLoader$1 cannot be cast to java.lang.ClassLoader Key: LOG4J2-1971 URL: