Re: [VOTE] Release Log4j 2.7-rc1

I was able to build the site on Linux with: MAVEN_OPTS="-Xmx2000m -XX:MaxPermSize=384m" mvn site Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00) Java version: 1.7.0_80, vendor: Oracle Corporation Default locale: en_US, platform encoding: UTF-8 OS name:

Re: [VOTE] Release Log4j 2.7-rc1

Since it seems all issues have been resolved I am going to start the release build. Please do not commit as it causes the release to fail. Ralph > On Oct 1, 2016, at 4:32 AM, Remko Popma wrote: > > LOG4J2-1618 is now also fixed. > > On Sat, Oct 1, 2016 at 3:20 AM, Gary

Re: [VOTE] Release Log4j 2.7-rc1

On Thu, Sep 29, 2016 at 10:05 AM, Gary Gregory wrote: > Please wait to cut rc2, I am fixing a regression: > https://issues.apache.org/jira/browse/LOG4J2-1620 > Fixed. This looks like it needs addressing: https://issues.apache.org/jira/browse/LOG4J2-1618 Gary > > Gary

Re: [VOTE] Release Log4j 2.7-rc1

Please wait to cut rc2, I am fixing a regression: https://issues.apache.org/jira/browse/LOG4J2-1620 Gary On Thu, Sep 29, 2016 at 9:31 AM, Mikael Ståldal wrote: > I created JIRA issues for the Kafka and Flume appender timeout issues, and > I have fixed both of them in

Re: [VOTE] Release Log4j 2.7-rc1

I created JIRA issues for the Kafka and Flume appender timeout issues, and I have fixed both of them in master branch. https://issues.apache.org/jira/browse/LOG4J2-1624 https://issues.apache.org/jira/browse/LOG4J2-1625 I also created a JIRA issue for the JVM shutdown hook, but that not as easy to

Re: [VOTE] Release Log4j 2.7-rc1

Yes please, only fix the blockers for rc2. We can make a 2.7.1 soon after with more fixes if needed. As Gary always says, RERO! On 29 September 2016 at 08:45, Ralph Goers wrote: > The release is already delayed. So far we have two compatibility issues > that need to

Re: [VOTE] Release Log4j 2.7-rc1

The release is already delayed. So far we have two compatibility issues that need to be fixed. Please create a Jira issue for the Flume Appender and the JVM shutdown hook. Lets gets those fixed. And perhaps we should stop doing things that aren’t directly focused on getting the release out as

Re: [VOTE] Release Log4j 2.7-rc1

I think that it is unfortunate that the close timeout is always zero within the standard JVM shutdown hook (LoggerContext.java:275). I think that should be configurable. However, I don't want to delay the release for that, so let's fix that after the 2.7 release.

Re: [VOTE] Release Log4j 2.7-rc1

On Wed, Sep 28, 2016 at 8:51 AM, Mikael Ståldal wrote: > Was this timeout thing implemented as part of any JIRA issue? > The high level ticket is: https://issues.apache.org/jira/browse/LOG4J2-1539 Gary > > On Wed, Sep 28, 2016 at 5:49 PM, Mikael Ståldal

Re: [VOTE] Release Log4j 2.7-rc1

I also did not see Mikael's -1 email... Strange. I agree we should not break compatibility like this. On Thu, Sep 29, 2016 at 12:55 AM, Ralph Goers wrote: > I don’t know what is going on with my email but I never saw your -1 email. > Obviously, I see it now. > > I

Re: [VOTE] Release Log4j 2.7-rc1

I don’t recall but he did mention it on the dev list. As I recall he decided we needed to add timeouts to all the stop calls to make sure shutdown doesn’t hang. Ralph > On Sep 28, 2016, at 8:51 AM, Mikael Ståldal wrote: > > Was this timeout thing implemented as part

Re: [VOTE] Release Log4j 2.7-rc1

I don’t know what is going on with my email but I never saw your -1 email. Obviously, I see it now. I agree that we should not be breaking compatibility like this. Ralph > On Sep 28, 2016, at 7:42 AM, Mikael Ståldal wrote: > > I fixed the Kafka issue and pushed it

Re: [VOTE] Release Log4j 2.7-rc1

Was this timeout thing implemented as part of any JIRA issue? On Wed, Sep 28, 2016 at 5:49 PM, Mikael Ståldal wrote: > To track this, I temporary added this to KafkaManager.releaseSub(): > LOGGER.info("releaseSub: timeout=" + timeout + " " + timeUnit.toString(), new >

Re: [VOTE] Release Log4j 2.7-rc1

To track this, I temporary added this to KafkaManager.releaseSub(): LOGGER.info("releaseSub: timeout=" + timeout + " " + timeUnit.toString(), new Throwable()); and I get: 2016-09-28 17:43:14,382 pool-1-thread-1 INFO releaseSub: timeout=0 MILLISECONDS java.lang.Throwable at

Re: [VOTE] Release Log4j 2.7-rc1

It is used when you call LifeCycle2.stop(long, TimeUnit), like stopping a LoggerContext or all of Log4j through the shutdown() method. Gary On Wed, Sep 28, 2016 at 8:35 AM, Mikael Ståldal wrote: > I see that KafkaManager.releaseSub() is passed a timeout of 0 at

Re: [VOTE] Release Log4j 2.7-rc1

I see that KafkaManager.releaseSub() is passed a timeout of 0 at runtime, which is not very useful. How is this actually supposed to be used? How can you make it get something else than 0? On Wed, Sep 28, 2016 at 5:33 PM, Mikael Ståldal wrote: > We have already

Re: [VOTE] Release Log4j 2.7-rc1

We have already discussed this here: https://issues.apache.org/jira/browse/LOG4J2-1390 I don't think the release process is the right occasion to reopen this discussion. Can we please keep the Kafka 0.8 compatibility for this release, and then possibly reopen this discussion after the release

Re: [VOTE] Release Log4j 2.7-rc1

I am in favour of having these few lines of extra code if it enables people who for some reason cannot upgrade their Kafka server to use Log4j 2. There is no drawback for us, and it can be a huge help to users. On Thu, Sep 29, 2016 at 12:24 AM, Gary Gregory wrote: > On

Re: [VOTE] Release Log4j 2.7-rc1

On Wed, Sep 28, 2016 at 8:13 AM, Mikael Ståldal wrote: > Kafka server 0.8 is still in use, and newer Kafka clients cannot connect > to older Kafka servers. > There will always be users of old software. That does not mean that new versions of Log4j must support old

Re: [VOTE] Release Log4j 2.7-rc1

On Wed, Sep 28, 2016 at 7:42 AM, Mikael Ståldal wrote: > I fixed the Kafka issue and pushed it to master branch. > > However, I have another concern, what timeout value is actually passed in > to AbstractManager.releaseSub ? > releaseSub() is called by

Re: [VOTE] Release Log4j 2.7-rc1

Kafka server 0.8 is still in use, and newer Kafka clients cannot connect to older Kafka servers. On Wed, Sep 28, 2016 at 5:10 PM, Gary Gregory wrote: > I do not think it makes sense to support old versions that are not even > 1.0. > > Gary > > On Wed, Sep 28, 2016 at

Re: [VOTE] Release Log4j 2.7-rc1

I do not think it makes sense to support old versions that are not even 1.0. Gary On Wed, Sep 28, 2016 at 7:42 AM, Mikael Ståldal wrote: > I fixed the Kafka issue and pushed it to master branch. > > However, I have another concern, what timeout value is actually

Re: [VOTE] Release Log4j 2.7-rc1

I fixed the Kafka issue and pushed it to master branch. However, I have another concern, what timeout value is actually passed in to AbstractManager.releaseSub ? On Wed, Sep 28, 2016 at 3:51 PM, Mikael Ståldal wrote: > -1 since the Kafka appender now only works with

Re: [VOTE] Release Log4j 2.7-rc1

+1 Works with my application, compiles and tests fine from git (Java 1.8), gpg sigs are all good, log4j-bom looks good, manifest looks good. Note that there are no links to the Scala components on the left sidebar, but that can be updated directly on svn. Same goes on the javadocs page. There is

Re: [VOTE] Release Log4j 2.7-rc1

Johannes, We are currently reviewing whether the artifacts or the web site for this release candidate has any showstoppers. If showstoppers are found and we need to rebuild and repackage anyway we can consider merging other patches. Otherwise it will be the next release. Generally I try to

Re: [VOTE] Release Log4j 2.7-rc1

May it be possible to integrate the third patch from Log4j2-1506? Then I would be happy too with the release. Johannes

Re: [VOTE] Release Log4j 2.7-rc1

You probably do not want to depend directly on classes in org.apache.logging.log4j.core.util. Gary On Tue, Sep 27, 2016 at 8:25 PM, Leon Finker wrote: > FYI, probably not important, but noticed that this was removed: >

Re: [VOTE] Release Log4j 2.7-rc1

FYI, probably not important, but noticed that this was removed: org.apache.logging.log4j.core.util.Constant.LINE_SEPARATOR. For some reason we used it in one of custom plugins (probably copied from log4j2 existing classes as a starting point). So it threw class not found exception in 2.7. It

Re: [VOTE] Release Log4j 2.7-rc1

I'm going to go to +1 since the software can be built soup to nuts with 'mvn clean install'. Gary On Mon, Sep 26, 2016 at 11:06 PM, Ralph Goers wrote: > Matt, note that it didn’t fail when Gary ran mvn clean install. If you > run mvn install -DskipTests followed by

Re: [VOTE] Release Log4j 2.7-rc1

+1 No issues found On Wed, Sep 28, 2016 at 1:39 AM, Leon Finker wrote: > +1 > Tested with various services and use cases (only async logging). No issues > observed. > > On Sep 26, 2016 11:50 AM, "Ralph Goers" > wrote: > > This is a vote to release

Re: [VOTE] Release Log4j 2.7-rc1

+1 Tested with various services and use cases (only async logging). No issues observed. On Sep 26, 2016 11:50 AM, "Ralph Goers" wrote: This is a vote to release Log4j 2.6.2, the next version of the Log4j 2 project. Please download, test, and cast your votes on the

Re: [VOTE] Release Log4j 2.7-rc1

Oh, got it. I have a backlog item in Commons to make a generic pax-exam test for testing OSGi integration of various projects. Such a test would be great for here, too. On 27 September 2016 at 01:06, Ralph Goers wrote: > Matt, note that it didn’t fail when Gary ran

Re: [VOTE] Release Log4j 2.7-rc1

Matt, note that it didn’t fail when Gary ran mvn clean install. If you run mvn install -DskipTests followed by mvn test it fails. This tells me there is something funny going on in the tests that requires the tests to be run as part of the full lifecycle. Ralph > On Sep 26, 2016, at 9:51

Re: [VOTE] Release Log4j 2.7-rc1

That OSGi test failure could be related to the fix for LOG4J2-351, though I'm surprised it hasn't caused a test failure until now. On 26 September 2016 at 23:42, Ralph Goers wrote: > When I looked at it the Log4j1Configuration stuff said it was experimental > so if

Re: [VOTE] Release Log4j 2.7-rc1

When I looked at it the Log4j1Configuration stuff said it was experimental so if it has issues I don’t think it matters. Believe it or not I have never run mvn test all by itself. I pretty much only do mvn clean install. So I have no idea if this is new or has always been this way. Ralph >

Re: [VOTE] Release Log4j 2.7-rc1

Based in the src distribution: MD5, SHA1, ASC OK. mvn clean install OK. BUT I had to hack the tset org.apache.log4j.config. Log4j1ConfigurationFactoryTest.testSystemProperties2() and add a "appender.stop(10, TimeUnit.SECONDS);" to get the test to pass; this is pushed to Git master. RAT check

Re: [VOTE] Release Log4j 2.7-rc1

Yes. That is what cut & paste does to you… :-) Ralph > On Sep 26, 2016, at 10:27 AM, Gary Gregory wrote: > > > > On Mon, Sep 26, 2016 at 8:50 AM, Ralph Goers > wrote: > This is a vote to release Log4j

Re: [VOTE] Release Log4j 2.7-rc1

On Mon, Sep 26, 2016 at 8:50 AM, Ralph Goers wrote: > This is a vote to release Log4j 2.6.2, the next version of the Log4j 2 > project. > You mean 2.7... ;-) Gary > > Please download, test, and cast your votes on the log4j developers list. > [] +1, release the

Re: [VOTE] Release Log4j 2.7-rc1

I blogged "A sneak peak into Log4j 2.7 " with a link to the JAX Innovation Awards voting page since the vote closes in a few days. Please share. Remko On Tue, Sep 27, 2016 at 12:50 AM, Ralph Goers

[VOTE] Release Log4j 2.7-rc1

This is a vote to release Log4j 2.6.2, the next version of the Log4j 2 project. Please download, test, and cast your votes on the log4j developers list. [] +1, release the artifacts [] -1, don't release because... The vote will remain open for 72 hours (or more if required). All votes are