Re: Release process

The idea of release branches is to only include relevant fixes on the branches. It's usually easy to "git cherry-pick" the respective commit into the master or from master to the release branch - depending on where it got fixed first. For a public project like Log4j2 there probably would be a m

Re: Release process

I am not concerned with running the release plugin. I am concerned when we have patches for the release branch that we make sure that they are also pushed to master. Where I work the release branch is always merged back to master, but that means any patches should really only be applied to the

Re: @Required on layout on AbstractAppender

I have to take a look at the respective code (I did not write it), but it seems I can already give the all-clear: The latest master does not break any of our logging-specific test cases any more (except within Eclipse, but that's probably related to a very specific requirement of ours in those tes

Re: OS-based dynamic configuration file

Yes, it returns the key. Remember, a Route can dynamically create an Appender so it isn’t required to be a reference. At the same time we can (and probably should) pass variables and/or a Map to the script that it can update in any way it wants for later usage by the Routing script. As is shown

Re: Release process

This is how we do it at our company: - start a new artifact on branch master, setting the version number in pom.xml to 0.1.0-SNAPSHOT - create CHANGELOG.md, add a headline "## Last Changes", and during development, add an entry with a link to the respective JIRA issue for each solved ticket,

Jenkins build is back to stable : Log4j 2.x #2300

See - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: OS-based dynamic configuration file

Wait a sec, the DefaultRouteScript should return the Route key, not the Route ref. Right? Gary On Mon, Sep 12, 2016 at 9:53 PM, Gary Gregory wrote: > "First, the init script changes the default route based on the OS." > > Maybe the tag should be called "DefaultRouteScript" since it's job is to

Jenkins build is still unstable: Log4j 2.x #2299

See - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: OS-based dynamic configuration file

"First, the init script changes the default route based on the OS." Maybe the tag should be called "DefaultRouteScript" since it's job is to return the default route name? Gary On Mon, Sep 12, 2016 at 8:05 PM, Ralph Goers wrote: > After reviewing what I wrote below and looking at the Routing A

[jira] [Closed] (LOG4J2-1577) Add a Builder to the RoutingAppender and deprecate factory method

[ https://issues.apache.org/jira/browse/LOG4J2-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed LOG4J2-1577. Resolution: Fixed Fix Version/s: 2.7 Commit 4591f3fce2d5c65d7446ba8cfca20da5421165a2 > Add

[jira] [Created] (LOG4J2-1578) RoutingAppender can be configured with scripts

Gary Gregory created LOG4J2-1578: Summary: RoutingAppender can be configured with scripts Key: LOG4J2-1578 URL: https://issues.apache.org/jira/browse/LOG4J2-1578 Project: Log4j 2 Issue Type:

Re: OS-based dynamic configuration file

Tracking here: https://issues.apache.org/jira/browse/LOG4J2-1578 Gary On Mon, Sep 12, 2016 at 8:37 PM, Gary Gregory wrote: > Thanks Ralph. I'll start with > > LOG4J2-1577 Add a Builder to the RoutingAppender and deprecate factory > method > > and create another Jira after that. > > Gary > > On

Re: OS-based dynamic configuration file

Thanks Ralph. I'll start with LOG4J2-1577 Add a Builder to the RoutingAppender and deprecate factory method and create another Jira after that. Gary On Mon, Sep 12, 2016 at 8:05 PM, Ralph Goers wrote: > After reviewing what I wrote below and looking at the Routing Appender I > think the best

[jira] [Created] (LOG4J2-1577) Add a Builder to the RoutingAppender and deprecate factory method

Gary Gregory created LOG4J2-1577: Summary: Add a Builder to the RoutingAppender and deprecate factory method Key: LOG4J2-1577 URL: https://issues.apache.org/jira/browse/LOG4J2-1577 Project: Log4j 2

Re: OS-based dynamic configuration file

Replace the “?” characters with double quotes. Ralph > On Sep 12, 2016, at 8:05 PM, Ralph Goers wrote: > > After reviewing what I wrote below and looking at the Routing Appender I > think the best thing to do is just to add script support to it. It already > has support for a default Route.

Jenkins build became unstable: Log4j 2.x #2298

See - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1576) Better automated backwards compatibility checking

[ https://issues.apache.org/jira/browse/LOG4J2-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15486077#comment-15486077 ] Ralph Goers commented on LOG4J2-1576: - I'd be interested to know what the mechanism i

Re: OS-based dynamic configuration file

After reviewing what I wrote below and looking at the Routing Appender I think the best thing to do is just to add script support to it. It already has support for a default Route. The init script, if present, could override which Route to use as I described below. Then we could add a script at

[jira] [Created] (LOG4J2-1576) Better automated backwards compatibility checking

Remko Popma created LOG4J2-1576: --- Summary: Better automated backwards compatibility checking Key: LOG4J2-1576 URL: https://issues.apache.org/jira/browse/LOG4J2-1576 Project: Log4j 2 Issue Type:

Re: OS-based dynamic configuration file

I’ll try to describe it better but I’m not sure how good a job I’ll do if the dots aren’t clicking yet. Also, even though I might say to do it one way if I was coding I could very well change my mind as I implement it. That said: Create an Appender plugin named ScriptSelector or ScriptAppenderSel

Re: StatusConfiguration.initialize ()

Agreed on all that. On 12 September 2016 at 19:03, Remko Popma wrote: > I'm actually not that happy with status logging as it works now. The > status attribute in the configuration file is not helpful in common trouble > scenarios like the configuration file not being found. Also, status logging

Re: StatusConfiguration.initialize ()

I'm actually not that happy with status logging as it works now. The status attribute in the configuration file is not helpful in common trouble scenarios like the configuration file not being found. Also, status logging that happens during the LoggerContext initialization is not displayed. (For

Re: Release process

It sounds like the idea is to open up a branch for each 2.x release so we can backport specific bugfixes to the previous release branch to make minor version releases. We could either fork from the last 2.6.x release to maintain a 2.6 branch, or we could start with 2.7. If there's an easy way to m

Re: Deprecated factory methods replaced by builders.

mvn clirr:check Please see http://www.mojohaus.org/clirr-maven-plugin/ Gary On Mon, Sep 12, 2016 at 4:01 PM, Remko Popma wrote: > How do I run clirr? I would like to ensure the breaking changes are > reverted. If we have to redo a release because of this it would be wasting > the release manag

Re: Deprecated factory methods replaced by builders.

How do I run clirr? I would like to ensure the breaking changes are reverted. If we have to redo a release because of this it would be wasting the release manager's time. On Thu, Sep 8, 2016 at 1:32 PM, Gary Gregory wrote: > FWIW, here is what Clirr finds for removed code: > > [ERROR] 7002: org.

JIRA permissions (was Re: "sys" properties lookup regression)

Leon mentioned he was unable to reopen the issue. Looking at the permission scheme, it looks like Reporters can resolve and reopen, but not Jira-users. Just wondering if this is correct... Remko On Fri, Sep 9, 2016 at 11:19 PM, Remko Popma wrote: > Would you mind reopening 1313 and pasting you

Re: Release process

Back to the discussion about the release process, concretely what are we going to do differently from what we do now? On Sat, Sep 10, 2016 at 3:26 AM, Gary Gregory wrote: > Remko has a branch to merge. > > I'd like to hear from Steffen Offermann >

Re: StatusConfiguration.initialize ()

I don’t think moving it is a good idea. The Status Logger is initialized as soon as it possibly can be, which is after we have read the attributes for the Configuration element. If the call is moved to the initialize method then no status logging will occur while the configuration is processed.

Re: OS-based dynamic configuration file

On Sun, Sep 11, 2016 at 12:47 PM, Ralph Goers wrote: > Yes. The Appenders tag inside the ScriptSelector are the Appenders that > are to be created. But now that I think about it, we can’t use “Appenders” > for this. If you look at the RoutingAppender you will notice that Appenders > there are dec

Re: StatusConfiguration.initialize ()

Anything to reduce duplication of code is great! The Configuration classes have quite a bit of duplication right now and are prime candidates for some refactoring love. On 28 August 2016 at 07:38, Mikael Ståldal wrote: > The method StatusConfiguration.initialize() is invoked from > Configuration

Re: @Required on layout on AbstractAppender

On Sun, Sep 11, 2016 at 10:55 PM, Gary Gregory wrote: > I understand now, thank you. All build methods do not use the same > default. I'll remove the @Required tomorrow. > Done. Gary > Gary > > On Sep 11, 2016 9:11 PM, "Matt Sicker" wrote: > >> I mean if you do something like this: >> >> @Plu

Re: @Required on layout on AbstractAppender

Steffen, is the code you're looking at using the factory methods? Or are you using the builder class? On 12 September 2016 at 02:33, Steffen Offermann < steffen.offerm...@aixigo.de> wrote: > > Nope, this does not work. The test case mentioned in LOG4J2-1573 works if > I remove the @Required annot

[jira] [Resolved] (LOG4J2-1313) not working

[ https://issues.apache.org/jira/browse/LOG4J2-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma resolved LOG4J2-1313. - Resolution: Fixed Fixed in master in commit 7994789. Please verify and close. > not working > -

[jira] [Commented] (LOG4J2-1447) Garbage-free data structure for LogEvent's context map data

[ https://issues.apache.org/jira/browse/LOG4J2-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15484317#comment-15484317 ] Remko Popma commented on LOG4J2-1447: - Final polishing: * ArrayContextData no longer

[jira] [Commented] (LOG4J2-1313) not working

[ https://issues.apache.org/jira/browse/LOG4J2-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15484058#comment-15484058 ] Remko Popma commented on LOG4J2-1313: - (Debugging out loud) What is currently happeni

Re: [jira] [Commented] (LOG4J2-1573) Layout is no longer optional

Actually the latest master branch now breaks many more of our test cases, i.e. the situation has gotten even worse. On 09/12/2016 09:35 AM, Steffen Offermann (JIRA) wrote: [ https://issues.apache.org/jira/browse/LOG4J2-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabp

[jira] [Commented] (LOG4J2-1573) Layout is no longer optional

[ https://issues.apache.org/jira/browse/LOG4J2-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15483370#comment-15483370 ] Steffen Offermann commented on LOG4J2-1573: --- The problem still exists with the

Re: @Required on layout on AbstractAppender

Nope, this does not work. The test case mentioned in LOG4J2-1573 works if I remove the @Required annotation, like Gary suggested, but then most of the other tests break. Regards, Steffen On 09/12/2016 09:17 AM, Steffen Offermann wrote: Hmmm, would that still guarantee the correct defaults

[jira] [Commented] (LOG4J2-1447) Garbage-free data structure for LogEvent's context map data

[ https://issues.apache.org/jira/browse/LOG4J2-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15483347#comment-15483347 ] Remko Popma commented on LOG4J2-1447: - In addition to the {{toMap}} name change (and

Re: @Required on layout on AbstractAppender

Hmmm, would that still guarantee the correct defaults (as mentioned in the documentation) though? On 09/12/2016 09:16 AM, Steffen Offermann wrote: Looks like this would also fix https://issues.apache.org/jira/browse/LOG4J2-1573. I'll try that shortly. On 09/12/2016 07:55 AM, Gary Gregory wro

Re: @Required on layout on AbstractAppender

Looks like this would also fix https://issues.apache.org/jira/browse/LOG4J2-1573. I'll try that shortly. On 09/12/2016 07:55 AM, Gary Gregory wrote: I understand now, thank you. All build methods do not use the same default. I'll remove the @Required tomorrow. Gary On Sep 11, 2016 9:11 PM,

[jira] [Commented] (LOG4J2-1573) Layout is no longer optional

[ https://issues.apache.org/jira/browse/LOG4J2-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15483321#comment-15483321 ] Steffen Offermann commented on LOG4J2-1573: --- This _was_ the latest build at the

[jira] [Commented] (LOG4J2-1573) Layout is no longer optional

[ https://issues.apache.org/jira/browse/LOG4J2-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15483317#comment-15483317 ] Steffen Offermann commented on LOG4J2-1573: --- This is the stack trace from the d