Re: [proposal] Should we drop Java 9 "features" like module-info and multi-release jars or provide it differently.

2018-02-20 Thread Jochen Wiedmann
On Wed, Feb 21, 2018 at 3:48 AM, Gary Gregory wrote: > How about dropping the MR jaring (a horrible design with this META_INF > business IMO)? Having to admit, that I haven't got the slightest idea about feasibility, and amount of work, but: IMO, the best solution would be to release, say, a log

Re: [proposal] Should we drop Java 9 "features" like module-info and multi-release jars or provide it differently.

2018-02-20 Thread Ralph Goers
I am not in favor of this. I was told that moving module-info.java into the META-INF/versions/9 directory is valid and will remedy some of these problems. I intend to do that prior to the next release. Although I agree what Oracle did is a mess there are people who want this stuff. In fact, so

Re: [proposal] Should we drop Java 9 "features" like module-info and multi-release jars or provide it differently.

2018-02-20 Thread Matt Sicker
Perhaps we should revert Java 9 features and defer them to 3.0.0 where we require Java 8 minimum as it is. It leaves a distinct legacy splitting point. On Tue, Feb 20, 2018 at 20:48, Gary Gregory wrote: > Hi All: > > https://issues.apache.org/jira/browse/LOG4J2-2173 is yet another example > of >

[proposal] Should we drop Java 9 "features" like module-info and multi-release jars or provide it differently.

2018-02-20 Thread Gary Gregory
Hi All: https://issues.apache.org/jira/browse/LOG4J2-2173 is yet another example of a jar (ours) breaking an application as it attempts to support Java 9. It really does not matter that code is not supposed to look at class files in a jar here or there (I'm looking at you META-INF); or that they c

Re: Best practices for unit testing that logging is correct done

2018-02-20 Thread Matt Sicker
As for a random example: Config file: https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/test/resources/log4j-customLevel.xml Test class: https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/test/java/org/apache/logging/log4j/core/CustomLevelsTest.java JUnit rule:

Re: Best practices for unit testing that logging is correct done

2018-02-20 Thread Matt Sicker
If you add log4j-core:test (the test jar), there's a ListAppender built in that we use extensively to verify logging messages in various scenarios. If you add the list appender to your log4j2-test.xml file, then it'll take precedence over a normal log4j2.xml file. You can probably take a look at a

Best practices for unit testing that logging is correct done

2018-02-20 Thread Atle Tokle
I would like to know suggestions for best practices for unit-testing that logging is correctly performed in the code. I use Mockito, and have tried a few aproaches which I'm not pleased with. 1. I have tried static mock with Powermockito, but PowerMockito have several bad effects and screws up cod