Re: picocli in log4j

[Remko Popma]

Great, thanks for the positive feedback!

For whoever is interested, picocli autocomplete
<http://picocli.info/1.0.0-SNAPSHOT/autocomplete.html> is now in public
beta. Spread the word! :-) Feedback welcome!

On Tue, Aug 8, 2017 at 3:06 AM, Matt Sicker  wrote:

> JCommander is in use mainly for the log4j-server stuff.
>
> On 7 August 2017 at 10:21, Chandra 
> wrote:
>
> > +1 for picocli, I looked into it some time ago and looked pretty good.
> > In-fact, I wanted to use it for my own project for `JvmTop`.
> >
> > btw, where are we using `Jcommander` in log4j2?
> >
> >
> > thanks,
> > Chandra
> >
> > On 7 Aug 2017, 8:32 PM +0530, Matt Sicker , wrote:
> > > I have no objections. I do like your library, though I haven't used it
> > for
> > > any of my own projects yet (since most of what I've been working on for
> > the
> > > past several months have all been Mesos-managed containers, so startup
> > has
> > > been mostly delegated to environment variables for configuration).
> > >
> > > The autocomplete feature sounds pretty sweet.
> > >
> > > On 4 August 2017 at 13:59, Remko Popma  wrote:
> > >
> > > > Thanks all for your positive feedback on picocli <
> http://picocli.info/
> > > > back
> > > > in April.
> > > > There have been multiple releases since then and I am confident about
> > its
> > > > stability now.
> > > >
> > > > Any objections if I replace our current usage of JCommander
> > > > <http://jcommander.org/> with picocli?
> > > >
> > > > Main benefits:
> > > >
> > > > - Customizable usage help
> > > > - Usage help with ANSI colors
> > > > <https://github.com/remkop/picocli#picocli_demo
> > > > - Better support for positional parameters
> > > > - POSIX short options (like -xvrf)
> > > > - Can be included as source to reduce external dependencies
> > > > - Coming soon: autocomplete
> > > > <https://github.com/remkop/picocli/wiki/Notes-on-
> > autocomplete-(work-in-
> > > > progress)
> > > >
> > >
> > >
> > >
> > > --
> > > Matt Sicker  >
>
>
>
> --
> Matt Sicker 
>

Re: picocli in log4j

[Remko Popma]

Hi Gary,

Love the add-ons. Definitely interested.
Let me ping you offlist to see how we can collaborate on this.

Remko

On Wed, Aug 9, 2017 at 1:02 Gary Gregory  wrote:

> Hi,
>
> Congrats on your library!
>
> What I look for in these CLI frameworks is a rich library of bindings. None
> of them have it which is why I ended up creating
> https://github.com/garydgregory/jcommander-addons/blob/master/README.md
>
> This is a pain because I should not need two libraries to cover the JRE.
>
> If you want this kind of stuff for you library, let me know...
>
> Gary
>
> On Aug 4, 2017 12:59, "Remko Popma"  wrote:
>
> > Thanks all for your positive feedback on picocli <http://picocli.info/>
> > back
> > in April.
> > There have been multiple releases since then and I am confident about its
> > stability now.
> >
> > Any objections if I replace our current usage of JCommander
> > <http://jcommander.org/> with picocli?
> >
> > Main benefits:
> >
> >- Customizable usage help
> >- Usage help with ANSI colors
> ><https://github.com/remkop/picocli#picocli_demo>
> >- Better support for positional parameters
> >- POSIX short options (like -xvrf)
> >- Can be included as source to reduce external dependencies
> >- Coming soon: autocomplete
> ><
> https://github.com/remkop/picocli/wiki/Notes-on-autocomplete-(work-in-
> > progress)>
> >
>

Re: picocli in log4j

[Remko Popma]

I created https://issues.apache.org/jira/browse/LOG4J2-2011 for this.


On Thu, Aug 10, 2017 at 8:29 Remko Popma  wrote:

> Hi Gary,
>
> Love the add-ons. Definitely interested.
> Let me ping you offlist to see how we can collaborate on this.
>
> Remko
>
> On Wed, Aug 9, 2017 at 1:02 Gary Gregory  wrote:
>
>> Hi,
>>
>> Congrats on your library!
>>
>> What I look for in these CLI frameworks is a rich library of bindings.
>> None
>> of them have it which is why I ended up creating
>> https://github.com/garydgregory/jcommander-addons/blob/master/README.md
>>
>> This is a pain because I should not need two libraries to cover the JRE.
>>
>> If you want this kind of stuff for you library, let me know...
>>
>> Gary
>>
>> On Aug 4, 2017 12:59, "Remko Popma"  wrote:
>>
>> > Thanks all for your positive feedback on picocli <http://picocli.info/>
>> > back
>> > in April.
>> > There have been multiple releases since then and I am confident about
>> its
>> > stability now.
>> >
>> > Any objections if I replace our current usage of JCommander
>> > <http://jcommander.org/> with picocli?
>> >
>> > Main benefits:
>> >
>> >- Customizable usage help
>> >- Usage help with ANSI colors
>> ><https://github.com/remkop/picocli#picocli_demo>
>> >- Better support for positional parameters
>> >- POSIX short options (like -xvrf)
>> >- Can be included as source to reduce external dependencies
>> >- Coming soon: autocomplete
>> ><
>> https://github.com/remkop/picocli/wiki/Notes-on-autocomplete-(work-in-
>> > progress)>
>> >
>>
>

Re: [4/5] logging-log4j2 git commit: LOG4J2-2011 replace JCommander command line parser with picocli to let users run Log4j2 utility applications without requiring an external dependency

[Remko Popma]

Picocli is designed to be included as source with minimal impact. That's why 
it's a single source file. 

Users should not have to specify a command line parser library jar just to run 
our Log4j2 utility applications. 


> On Aug 15, 2017, at 2:06, Matt Sicker  wrote:
> 
> Embedding a single class? I don't see the problem with that. We do it with
> several Commons classes.
> 
>> On 14 August 2017 at 11:59, Gary Gregory  wrote:
>> 
>> Wait a minute? We are embedding a third party jar? Yuk! -1, sorry that is
>> not what I thought was happening.
>> 
>> Gary
>> 
>>> On Aug 14, 2017 10:18,  wrote:
>>> 
>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/
>>> c2818bec/log4j-core/src/main/java/org/apache/logging/log4j/
>>> core/util/picocli/CommandLine.java
>>> --
>>> diff --git a/log4j-core/src/main/java/org/apache/logging/log4j/core/
>> util/picocli/CommandLine.java
>>> b/log4j-core/src/main/java/org/apache/logging/log4j/core/
>>> util/picocli/CommandLine.java
>>> new file mode 100644
>>> index 000..5c4e9cc
>>> --- /dev/null
>>> +++ b/log4j-core/src/main/java/org/apache/logging/log4j/core/
>>> util/picocli/CommandLine.java
>>> @@ -0,0 +1,3900 @@
>>> +/*
>>> + * Licensed to the Apache Software Foundation (ASF) under one or more
>>> + * contributor license agreements. See the NOTICE file distributed with
>>> + * this work for additional information regarding copyright ownership.
>>> + * The ASF licenses this file to You under the Apache license, Version
>> 2.0
>>> + * (the "License"); you may not use this file except in compliance with
>>> + * the License. You may obtain a copy of the License at
>>> + *
>>> + *  http://www.apache.org/licenses/LICENSE-2.0
>>> + *
>>> + * Unless required by applicable law or agreed to in writing, software
>>> + * distributed under the License is distributed on an "AS IS" BASIS,
>>> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
>>> implied.
>>> + * See the license for the specific language governing permissions and
>>> + * limitations under the license.
>>> + */
>>> +package org.apache.logging.log4j.core.util.picocli;
>>> +
>>> +import java.awt.Point;
>>> +import java.io.File;
>>> +import java.io.PrintStream;
>>> +import java.lang.annotation.ElementType;
>>> +import java.lang.annotation.Retention;
>>> +import java.lang.annotation.RetentionPolicy;
>>> +import java.lang.annotation.Target;
>>> +import java.lang.reflect.Array;
>>> +import java.lang.reflect.Constructor;
>>> +import java.lang.reflect.Field;
>>> +import java.math.BigDecimal;
>>> +import java.math.BigInteger;
>>> +import java.net.InetAddress;
>>> +import java.net.MalformedURLException;
>>> +import java.net.URI;
>>> +import java.net.URISyntaxException;
>>> +import java.net.URL;
>>> +import java.nio.charset.Charset;
>>> +import java.nio.file.Path;
>>> +import java.nio.file.Paths;
>>> +import java.sql.Time;
>>> +import java.text.BreakIterator;
>>> +import java.text.ParseException;
>>> +import java.text.SimpleDateFormat;
>>> +import java.util.ArrayList;
>>> +import java.util.Arrays;
>>> +import java.util.Collection;
>>> +import java.util.Collections;
>>> +import java.util.Comparator;
>>> +import java.util.Date;
>>> +import java.util.HashMap;
>>> +import java.util.HashSet;
>>> +import java.util.LinkedHashMap;
>>> +import java.util.LinkedList;
>>> +import java.util.List;
>>> +import java.util.Map;
>>> +import java.util.Queue;
>>> +import java.util.Set;
>>> +import java.util.SortedMap;
>>> +import java.util.SortedSet;
>>> +import java.util.Stack;
>>> +import java.util.TreeMap;
>>> +import java.util.TreeSet;
>>> +import java.util.UUID;
>>> +import java.util.regex.Pattern;
>>> +
>>> +import org.apache.logging.log4j.core.util.picocli.CommandLine.Help.
>> Ansi;
>>> +import org.apache.logging.log4j.core.util.picocli.CommandLine.Help.
>>> Ansi.IStyle;
>>> +import org.apache.logging.log4j.core.util.picocli.CommandLine.Help.
>>> Ansi.Style;
>>> +import org.apache.logging.log4j.core.util.picocli.CommandLine.Help.
>>> Ansi.Text;
>>> +
>>> +import static java.util.Locale.ENGLISH;
>>> +import static org.apache.logging.log4j.core.
>>> util.picocli.CommandLine.Help.Column.Overflow.SPAN;
>>> +import static org.apache.logging.log4j.core.
>>> util.picocli.CommandLine.Help.Column.Overflow.TRUNCATE;
>>> +import static org.apache.logging.log4j.core.
>>> util.picocli.CommandLine.Help.Column.Overflow.WRAP;
>>> +
>>> +/**
>>> + * 
>>> + * CommandLine interpreter that uses reflection to initialize an
>>> annotated domain object with values obtained from the
>>> + * command line arguments.
>>> + * Example
>>> + * import static picocli.CommandLine.*;
>>> + *
>>> + * @Command(header = "Encrypt FILE(s), or standard input, to
>>> standard output or to the output file.")
>>> + * public class Encrypt {
>>> + *
>>> + * @Parameters(type = File.class, description = "Any number of
>>> input files")
>>> + * private List files = new ArrayList

Re: [4/5] logging-log4j2 git commit: LOG4J2-2011 replace JCommander command line parser with picocli to let users run Log4j2 utility applications without requiring an external dependency

[Remko Popma]

Thank you for retracting your -1, Gary.

All,
Would core.tools be a better place for this package, just core, or is
core.util okay?

On Tue, Aug 15, 2017 at 3:03 AM, Gary Gregory 
wrote:

> Can we please avoid "util" packages, that just tells me "I can't be
> bothered to think of a good name". Just remove the "util" level IMO.
>
> Gary
>
> On Mon, Aug 14, 2017 at 12:02 PM, Gary Gregory 
> wrote:
>
> > Ugh, not a fan, but I'll retract my -1.
> >
> > "a single class", yes, but a 4000 line class.
> >
> > Gary
> >
> > On Mon, Aug 14, 2017 at 11:06 AM, Matt Sicker  wrote:
> >
> >> Embedding a single class? I don't see the problem with that. We do it
> with
> >> several Commons classes.
> >>
> >> On 14 August 2017 at 11:59, Gary Gregory 
> wrote:
> >>
> >> > Wait a minute? We are embedding a third party jar? Yuk! -1, sorry that
> >> is
> >> > not what I thought was happening.
> >> >
> >> > Gary
> >> >
> >> > On Aug 14, 2017 10:18,  wrote:
> >> >
> >> > > http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/
> >> > > c2818bec/log4j-core/src/main/java/org/apache/logging/log4j/
> >> > > core/util/picocli/CommandLine.java
> >> > > 
> >> --
> >> > > diff --git a/log4j-core/src/main/java/
> org/apache/logging/log4j/core/
> >> > util/picocli/CommandLine.java
> >> > > b/log4j-core/src/main/java/org/apache/logging/log4j/core/
> >> > > util/picocli/CommandLine.java
> >> > > new file mode 100644
> >> > > index 000..5c4e9cc
> >> > > --- /dev/null
> >> > > +++ b/log4j-core/src/main/java/org/apache/logging/log4j/core/
> >> > > util/picocli/CommandLine.java
> >> > > @@ -0,0 +1,3900 @@
> >> > > +/*
> >> > > + * Licensed to the Apache Software Foundation (ASF) under one or
> more
> >> > > + * contributor license agreements. See the NOTICE file distributed
> >> with
> >> > > + * this work for additional information regarding copyright
> >> ownership.
> >> > > + * The ASF licenses this file to You under the Apache license,
> >> Version
> >> > 2.0
> >> > > + * (the "License"); you may not use this file except in compliance
> >> with
> >> > > + * the License. You may obtain a copy of the License at
> >> > > + *
> >> > > + *  http://www.apache.org/licenses/LICENSE-2.0
> >> > > + *
> >> > > + * Unless required by applicable law or agreed to in writing,
> >> software
> >> > > + * distributed under the License is distributed on an "AS IS"
> BASIS,
> >> > > + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> >> > > implied.
> >> > > + * See the license for the specific language governing permissions
> >> and
> >> > > + * limitations under the license.
> >> > > + */
> >> > > +package org.apache.logging.log4j.core.util.picocli;
> >> > > +
> >> > > +import java.awt.Point;
> >> > > +import java.io.File;
> >> > > +import java.io.PrintStream;
> >> > > +import java.lang.annotation.ElementType;
> >> > > +import java.lang.annotation.Retention;
> >> > > +import java.lang.annotation.RetentionPolicy;
> >> > > +import java.lang.annotation.Target;
> >> > > +import java.lang.reflect.Array;
> >> > > +import java.lang.reflect.Constructor;
> >> > > +import java.lang.reflect.Field;
> >> > > +import java.math.BigDecimal;
> >> > > +import java.math.BigInteger;
> >> > > +import java.net.InetAddress;
> >> > > +import java.net.MalformedURLException;
> >> > > +import java.net.URI;
> >> > > +import java.net.URISyntaxException;
> >> > > +import java.net.URL;
> >> > > +import java.nio.charset.Charset;
> >> > > +import java.nio.file.Path;
> >> > > +import java.nio.file.Paths;
> >> > > +import java.sql.Time;
> >> > > +import java.text.BreakIterator;
> >> > > +import java.text.ParseException;
> >> > > +import java.text.SimpleDateFormat;
> >> > > +import java.util.ArrayList;
> >> > > +import java.util.Arrays;
> >> > > +import java.util.Collection;
> >> > > +import java.util.Collections;
> >> > > +import java.util.Comparator;
> >> > > +import java.util.Date;
> >> > > +import java.util.HashMap;
> >> > > +import java.util.HashSet;
> >> > > +import java.util.LinkedHashMap;
> >> > > +import java.util.LinkedList;
> >> > > +import java.util.List;
> >> > > +import java.util.Map;
> >> > > +import java.util.Queue;
> >> > > +import java.util.Set;
> >> > > +import java.util.SortedMap;
> >> > > +import java.util.SortedSet;
> >> > > +import java.util.Stack;
> >> > > +import java.util.TreeMap;
> >> > > +import java.util.TreeSet;
> >> > > +import java.util.UUID;
> >> > > +import java.util.regex.Pattern;
> >> > > +
> >> > > +import org.apache.logging.log4j.core.
> util.picocli.CommandLine.Help.
> >> > Ansi;
> >> > > +import org.apache.logging.log4j.core.
> util.picocli.CommandLine.Help.
> >> > > Ansi.IStyle;
> >> > > +import org.apache.logging.log4j.core.
> util.picocli.CommandLine.Help.
> >> > > Ansi.Style;
> >> > > +import org.apache.logging.log4j.core.
> util.picocli.CommandLine.Help.
> >> > > Ansi.Text;
> >> > > +
> >> > > +import static java.util.Locale.ENGLISH;
> >> > > +import sta

Re: [4/5] logging-log4j2 git commit: LOG4J2-2011 replace JCommander command line parser with picocli to let users run Log4j2 utility applications without requiring an external dependency

[Remko Popma]

OK, I will move them to core.tools.

On Wed, Aug 16, 2017 at 4:32 AM, Matt Sicker  wrote:

> I kind of consider the tools package for command line tools, so it sorta
> does make sense to include the command line parser in the same package.
>
> On 14 August 2017 at 17:36, Remko Popma  wrote:
>
> > Thank you for retracting your -1, Gary.
> >
> > All,
> > Would core.tools be a better place for this package, just core, or is
> > core.util okay?
> >
> > On Tue, Aug 15, 2017 at 3:03 AM, Gary Gregory 
> > wrote:
> >
> > > Can we please avoid "util" packages, that just tells me "I can't be
> > > bothered to think of a good name". Just remove the "util" level IMO.
> > >
> > > Gary
> > >
> > > On Mon, Aug 14, 2017 at 12:02 PM, Gary Gregory  >
> > > wrote:
> > >
> > > > Ugh, not a fan, but I'll retract my -1.
> > > >
> > > > "a single class", yes, but a 4000 line class.
> > > >
> > > > Gary
> > > >
> > > > On Mon, Aug 14, 2017 at 11:06 AM, Matt Sicker 
> > wrote:
> > > >
> > > >> Embedding a single class? I don't see the problem with that. We do
> it
> > > with
> > > >> several Commons classes.
> > > >>
> > > >> On 14 August 2017 at 11:59, Gary Gregory 
> > > wrote:
> > > >>
> > > >> > Wait a minute? We are embedding a third party jar? Yuk! -1, sorry
> > that
> > > >> is
> > > >> > not what I thought was happening.
> > > >> >
> > > >> > Gary
> > > >> >
> > > >> > On Aug 14, 2017 10:18,  wrote:
> > > >> >
> > > >> > > http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/
> > > >> > > c2818bec/log4j-core/src/main/java/org/apache/logging/log4j/
> > > >> > > core/util/picocli/CommandLine.java
> > > >> > > 
> > > >> --
> > > >> > > diff --git a/log4j-core/src/main/java/
> > > org/apache/logging/log4j/core/
> > > >> > util/picocli/CommandLine.java
> > > >> > > b/log4j-core/src/main/java/org/apache/logging/log4j/core/
> > > >> > > util/picocli/CommandLine.java
> > > >> > > new file mode 100644
> > > >> > > index 000..5c4e9cc
>

Re: [jira] [Commented] (LOG4J2-1888) Log4j throws a java.nio.charset.UnsupportedCharsetException: cp65001

[Remko Popma]

Gary, the change you propose in the LOG4J2-1888 branch look good to me.
Should be fine to merge.

On Tue, Aug 15, 2017 at 7:20 AM, ASF subversion and git services (JIRA) <
j...@apache.org> wrote:

>
> [ https://issues.apache.org/jira/browse/LOG4J2-1888?page=
> com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel&focusedCommentId=16126501#comment-16126501 ]
>
> ASF subversion and git services commented on LOG4J2-1888:
> -
>
> Commit 4ca638067516f6d488e910a9ff8e0f348d1d5d9f in logging-log4j2's
> branch refs/heads/LOG4J2-1888 from [~garydgregory]
> [ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=4ca6380 ]
>
> [LOG4J2-1888] Log4j throws a
> java.nio.charset.UnsupportedCharsetException: cp65001. Fix proposal.
>
> > Log4j throws a java.nio.charset.UnsupportedCharsetException: cp65001
> > 
> >
> > Key: LOG4J2-1888
> > URL: https://issues.apache.org/jira/browse/LOG4J2-1888
> > Project: Log4j 2
> >  Issue Type: Bug
> >  Components: Core
> >Affects Versions: 2.8.2
> >Reporter: Misagh Moayyed
> >
> > Running a Java spring boot web application using a "java -jar" type of
> command with a pretty vanilla log4j2.xml file in it, I see the following
> error.
> > {code}
> > 2017-04-24 11:47:45,338 main ERROR Unable to inject fields into builder
> class for plugin type class 
> org.apache.logging.log4j.core.appender.ConsoleAppender,
> element Console. java.nio.charset.UnsupportedCharsetException: cp65001
> > at java.nio.charset.Charset.forName(Charset.java:531)
> > at org.apache.logging.log4j.util.PropertiesUtil.
> getCharsetProperty(PropertiesUtil.java:146)
> > at org.apache.logging.log4j.util.PropertiesUtil.
> getCharsetProperty(PropertiesUtil.java:134)
> > at org.apache.logging.log4j.core.appender.ConsoleAppender$
> Target.getCharset(ConsoleAppender.java:85)
> > at org.apache.logging.log4j.core.appender.ConsoleAppender$
> Target$1.getDefaultCharset(ConsoleAppender.java:71)
> > at org.apache.logging.log4j.core.appender.ConsoleAppender$
> Builder.build(ConsoleAppender.java:218)
> > at org.apache.logging.log4j.core.appender.ConsoleAppender$
> Builder.build(ConsoleAppender.java:185)
> > at org.apache.logging.log4j.core.config.plugins.util.
> PluginBuilder.build(PluginBuilder.java:122)
> > at org.apache.logging.log4j.core.config.AbstractConfiguration.
> createPluginObject(AbstractConfiguration.java:952)
> > at org.apache.logging.log4j.core.config.AbstractConfiguration.
> createConfiguration(AbstractConfiguration.java:892)
> > at org.apache.logging.log4j.core.config.AbstractConfiguration.
> createConfiguration(AbstractConfiguration.java:884)
> > at org.apache.logging.log4j.core.config.AbstractConfiguration.
> doConfigure(AbstractConfiguration.java:508)
> > at org.apache.logging.log4j.core.config.AbstractConfiguration.
> initialize(AbstractConfiguration.java:232)
> > at org.apache.logging.log4j.core.config.AbstractConfiguration.
> start(AbstractConfiguration.java:244)
> > {code}
> > I am running the "run" command on Windows 10 64x inside a ConEmu
> console. If I switch to Babun, then I don't see the error.
> > This may not exactly be a "bug", but it would be great to not crash the
> app and fallback to a more accepting encoding perhaps.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.14#64029)
>

Re: [GitHub] logging-log4j2 issue #29: Property log4j.skipJansi should have a default of ...

[Remko Popma]

I like the idea of having it as a parameter to ConsoleAppender, that would
make it easy for users to find.

No problem changing the default behaviour to not using Jansi.

Do we still retain the current system property with its current semantics
(so setting skipJansi=false would also enable colorized output)? That would
allow existing setups to continue functioning. In the documentation we can
replace mentions of this system property with a link to the upcoming
ConsoleAppender attribute.

On Thu, Aug 17, 2017 at 6:02 AM, garydgregory  wrote:

> Github user garydgregory commented on the issue:
>
> https://github.com/apache/logging-log4j2/pull/29
>
> Sure, I was just looking ahead... ;-)
>
>
> ---
> 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 feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
>

Re: SocketOptions builder

[Remko Popma]

I like the idiom where setter methods return `this`, so users can chain
methods; thanks for making that change.


On Fri, Aug 18, 2017 at 5:41 AM, Gary Gregory 
wrote:

> Hi All and FYI:
>
> I plan on redoing the SocketOptions class as a real builder by making all
> accessors return this.
>
> Any objections?
>
> Gary
>

Re: SocketOptions builder

[Remko Popma]

That's fine I think. 

(Shameless plug) Every java main() method deserves http://picocli.info

> On Aug 18, 2017, at 7:18, Gary Gregory  wrote:
> 
> What I did not do is change the "set" methods to "with" to avoid breaking
> user sources. We should do that for 3.0 I think.
> 
> Gary
> 
>> On Thu, Aug 17, 2017 at 4:10 PM, Remko Popma  wrote:
>> 
>> I like the idiom where setter methods return `this`, so users can chain
>> methods; thanks for making that change.
>> 
>> 
>> On Fri, Aug 18, 2017 at 5:41 AM, Gary Gregory 
>> wrote:
>> 
>>> Hi All and FYI:
>>> 
>>> I plan on redoing the SocketOptions class as a real builder by making all
>>> accessors return this.
>>> 
>>> Any objections?
>>> 
>>> Gary
>>> 
>> 

Re: Logger names for nested classes

[Remko Popma]

No objection to creating logger names from Class.getCanonicalName() instead
of Class.getName(). I assume that this means we don't need a custom
toLoggerName(Class)
method.

Question for our Scala experts: does Class.getCanonicalName() preserve the
trailing $ in Scala classes?

At some point there was talk of API changes. Is that still needed?
Finally, I guess in order to keep supporting the current behaviour as well,
we still need to build configuration support for this 
wrote:

> I agree.
>
> Ralph
>
> > On Aug 19, 2017, at 11:43 AM, Matt Sicker  wrote:
> >
> > Canonical name sounds like it makes sense. I wonder what that evaluates
> to
> > in other JVM languages like Scala, Kotlin, Clojure, etc., but it seems to
> > make sense.
> >
> > On 19 August 2017 at 13:23, Dominik Psenner  wrote:
> >
> >> To me it is a simple and good solution to the problem. The first
> outlined
> >> solution has the pro that it would give a user more sophisticated ways
> to
> >> build logger hierarchies from class names, but it is also something that
> >> only a very small subset of users would use. We can keep that as a wish
> for
> >> later.
> >>
> >> 2017-08-19 20:13 GMT+02:00 Gary Gregory :
> >>
> >>> Any opposition to using the canonical name?
> >>>
> >>> Gary
> >>>
> >>> On Aug 14, 2017 15:28, "Gary Gregory"  wrote:
> >>>
>  In LogManager, if we call getCanonicalName() instead of getName(), we
> >>> only
>  get "."s, no "$"s...
> 
>  How about that?
> 
>  Gary
> 
>  On Mon, Aug 14, 2017 at 3:24 PM, Gary Gregory  >
>  wrote:
> 
> > Another way to look at this is that instead of calling
> class.getName()
> >>> we
> > would call our own toLoggerName(Class) which would NOT use $ but only
> >>> use
> > "."s.
> >
> > Gary
> >
> > On Mon, Aug 14, 2017 at 3:07 PM, Matt Sicker 
> >> wrote:
> >
> >> The logger name hierarchy interpretation is handled at the string
> >>> level,
> >> not the class level. I don't think the class needs to be passed
> along
> >>> as
> >> there isn't much useful info we can get from the Class instance that
> >> we
> >> can't already figure out from its FQCN.
> >>
> >> On 14 August 2017 at 15:56, Ralph Goers  >
> >> wrote:
> >>
> >>>
>  On Aug 14, 2017, at 1:38 PM, Gary Gregory <
> >> garydgreg...@gmail.com>
> >>> wrote:
> 
>  On Mon, Aug 14, 2017 at 2:08 PM, Ralph Goers <
> >> ralph.go...@dslextreme.com
> >>> >
>  wrote:
> 
> >
> >> On Aug 14, 2017, at 11:49 AM, Gary Gregory <
> >>> garydgreg...@gmail.com
> >>>
> > wrote:
> >>
> >> On Mon, Aug 14, 2017 at 12:35 PM, Gary Gregory <
> >> garydgreg...@gmail.com
> 
> >> wrote:
> >>
> >>> Probably for Ralph:
> >>>
> >>> Right now, it's the LogManager in log4j-api that converts
> >> Class
> >> names
> > into
> >>> Logger names.
> >>>
> >>> There is no getLogger(Class) API in the Core LoggerContext.
> >>>
> >>> Should we push down this conversion into Core's LoggerContext?
> >>>
> >>> It seems the sane thing to do to:
> >>> - Avoid making something pluggable in log4j-api
> >>> - Avoid making Core parse logger names looking for separators.
> >>>
> >>
> >> But that would mean adding two methods to:
> >>
> >> org.apache.logging.log4j.spi.LoggerContext:
> >>
> >> org.apache.logging.log4j.spi.LoggerContext.getLogger(Class)
> >> org.apache.logging.log4j.spi.LoggerContext.getLogger(Class,
> >> MessageFactory)
> >>
> >> Thoughts?
> >>
> >
> > Why does it mean that?
> >
> 
>  If we want the core to implement converting Class names to Logger
> >> names,
>  the Class must be passed down to the Core. Right now the
> >> LogManager
> >> does
>  that by calling org.apache.logging.log4j.spi.LoggerContext
> >>> methods.
> >>> These
>  methods take only String for the logger name.
> >>>
> >>> And that is a problem because….?  I am trying to understand why
> >>> LoggerContext will be required to accept a class name.
> >>>
> >>> Ralph
> >>>
> >>>
> >>
> >>
> >> --
> >> Matt Sicker 
> >>
> >
> >
> 
> >>>
> >>
> >>
> >>
> >> --
> >> Dominik Psenner
> >>
> >
> >
> >
> > --
> > Matt Sicker 
>
>
>

Re: Build failed in Jenkins: Log4j 2.x #3005

[Remko Popma]

Jenkins may be using an old Java 9:

JDK[/home/jenkins/tools/java/jigsaw-jdk-9-ea-b156]

Also, it seems this method was previously called `getPid`. It must have
been renamed recently.
http://www.javaworld.com/article/3176874/java-language/java-9s-other-new-enhancements-part-3.html


On Mon, Aug 21, 2017 at 13:17 Ralph Goers 
wrote:

> I don’t understand why this is failing. My local machine is running build
> 174. Was ProcessHandle.pid() really added that late?
>
> Ralph
>
> > On Aug 20, 2017, at 7:51 PM, Apache Jenkins Server <
> jenk...@builds.apache.org> wrote:
> >
> > See <
> https://builds.apache.org/job/Log4j%202.x/3005/display/redirect?page=changes
> >
> >
> > Changes:
> >
> > [rgoers] Add missing license header. Message should implement
> >
> > --
> > Started by an SCM change
> > Started by an SCM change
> > [EnvInject] - Loading node environment variables.
> > Building remotely on ubuntu-4 (ubuntu trusty) in workspace <
> https://builds.apache.org/job/Log4j%202.x/ws/>
> >> git rev-parse --is-inside-work-tree # timeout=10
> > Fetching changes from the remote Git repository
> >> git config remote.origin.url
> https://git-wip-us.apache.org/repos/asf/logging-log4j2.git # timeout=10
> > Fetching upstream changes from
> https://git-wip-us.apache.org/repos/asf/logging-log4j2.git
> >> git --version # timeout=10
> >> git fetch --tags --progress
> https://git-wip-us.apache.org/repos/asf/logging-log4j2.git
> +refs/heads/*:refs/remotes/origin/*
> >> git rev-parse refs/remotes/origin/master^{commit} # timeout=10
> >> git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
> > Checking out Revision c9a92d9de75f73390b3afa2ca9ade3097e478281
> (refs/remotes/origin/master)
> > Commit message: "Add missing license header. Message should implement
> StringBuilderFormattable"
> >> git config core.sparsecheckout # timeout=10
> >> git checkout -f c9a92d9de75f73390b3afa2ca9ade3097e478281
> >> git rev-list 39114a7af34a01312bcbefadf3e905dcb6fde75b # timeout=10
> > [EnvInject] - Executing scripts and injecting environment variables
> after the SCM step.
> > [EnvInject] - Injecting as environment variables the properties content
> > LANG=en_US.UTF-8
> >
> > [EnvInject] - Variables injected successfully.
> > Parsing POMs
> > Modules changed, recalculating dependency graph
> > Established TCP socket on 49485
> > maven33-agent.jar already up to date
> > maven33-interceptor.jar already up to date
> > maven3-interceptor-commons.jar already up to date
> > [Log4j 2.x] $ /home/jenkins/tools/java/latest1.8/bin/java -Xmx2g
> -Xms256m -XX:MaxPermSize=256m -cp
> /home/jenkins/jenkins-slave/maven33-agent.jar:/home/jenkins/tools/maven/apache-maven-3.3.9/boot/plexus-classworlds-2.5.2.jar:/home/jenkins/tools/maven/apache-maven-3.3.9/conf/logging
> jenkins.maven3.agent.Maven33Main
> /home/jenkins/tools/maven/apache-maven-3.3.9
> /home/jenkins/jenkins-slave/slave.jar
> /home/jenkins/jenkins-slave/maven33-interceptor.jar
> /home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 49485
> > Java HotSpot(TM) 64-Bit Server VM warning: ignoring option
> MaxPermSize=256m; support was removed in 8.0
> > <===[JENKINS REMOTING CAPACITY]===>   channel started
> > Executing Maven:  -B -f <
> https://builds.apache.org/job/Log4j%202.x/ws/pom.xml>
> -Dmaven.repo.local=/home/jenkins/jenkins-slave/maven-repositories/1 -t
> jenkins-toolchains.xml -DuseJava7 -Djenkins clean install
> > [INFO] Scanning for projects...
> > [WARNING]
> > [WARNING] Some problems were encountered while building the effective
> model for
> org.apache.logging.log4j.samples:log4j-samples-flume-remote:war:2.9-SNAPSHOT
> > [WARNING] 'build.plugins.plugin.(groupId:artifactId)' must be unique but
> found duplicate declaration of plugin
> org.apache.maven.plugins:maven-deploy-plugin @
> org.apache.logging.log4j.samples:log4j-samples-flume-remote:[unknown-version],
> <
> https://builds.apache.org/job/Log4j%202.x/ws/log4j-samples/flume-remote/pom.xml,>
> line 129, column 15
> > [WARNING]
> > [WARNING] Some problems were encountered while building the effective
> model for
> org.apache.logging.log4j.samples:log4j-samples-flume-embedded:war:2.9-SNAPSHOT
> > [WARNING] 'build.plugins.plugin.(groupId:artifactId)' must be unique but
> found duplicate declaration of plugin
> org.apache.maven.plugins:maven-deploy-plugin @
> org.apache.logging.log4j.samples:log4j-samples-flume-embedded:[unknown-version],
> <
> https://builds.apache.org/job/Log4j%202.x/ws/log4j-samples/flume-embedded/pom.xml,>
> line 141, column 15
> > [WARNING]
> > [WARNING] Some problems were encountered while building the effective
> model for org.apache.logging.log4j:log4j-bom:pom:2.9-SNAPSHOT
> > [WARNING] 'parent.relativePath' of POM
> org.apache.logging.log4j:log4j-bom:2.9-SNAPSHOT (<
> https://builds.apache.org/job/Log4j%202.x/ws/log4j-bom/pom.xml)> points
> at org.apache.logging.log4j:log4j instead of
> org.apache.logging:logging-parent, please verify your project structu

Re: Build failed in Jenkins: Log4j 2.x #3005

[Remko Popma]

Yes, renamed in build 166 apparently.
https://bugs.openjdk.java.net/browse/JDK-8178347


On Mon, Aug 21, 2017 at 13:40 Remko Popma  wrote:

> Jenkins may be using an old Java 9:
>
> JDK[/home/jenkins/tools/java/jigsaw-jdk-9-ea-b156]
>
> Also, it seems this method was previously called `getPid`. It must have
> been renamed recently.
> http://www.javaworld.com/article/3176874/java-language/java-9s-other-new-enhancements-part-3.html
>
>
> On Mon, Aug 21, 2017 at 13:17 Ralph Goers 
> wrote:
>
>> I don’t understand why this is failing. My local machine is running build
>> 174. Was ProcessHandle.pid() really added that late?
>>
>> Ralph
>>
>> > On Aug 20, 2017, at 7:51 PM, Apache Jenkins Server <
>> jenk...@builds.apache.org> wrote:
>> >
>> > See <
>> https://builds.apache.org/job/Log4j%202.x/3005/display/redirect?page=changes
>> >
>> >
>> > Changes:
>> >
>> > [rgoers] Add missing license header. Message should implement
>> >
>> > --
>> > Started by an SCM change
>> > Started by an SCM change
>> > [EnvInject] - Loading node environment variables.
>> > Building remotely on ubuntu-4 (ubuntu trusty) in workspace <
>> https://builds.apache.org/job/Log4j%202.x/ws/>
>> >> git rev-parse --is-inside-work-tree # timeout=10
>> > Fetching changes from the remote Git repository
>> >> git config remote.origin.url
>> https://git-wip-us.apache.org/repos/asf/logging-log4j2.git # timeout=10
>> > Fetching upstream changes from
>> https://git-wip-us.apache.org/repos/asf/logging-log4j2.git
>> >> git --version # timeout=10
>> >> git fetch --tags --progress
>> https://git-wip-us.apache.org/repos/asf/logging-log4j2.git
>> +refs/heads/*:refs/remotes/origin/*
>> >> git rev-parse refs/remotes/origin/master^{commit} # timeout=10
>> >> git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
>> > Checking out Revision c9a92d9de75f73390b3afa2ca9ade3097e478281
>> (refs/remotes/origin/master)
>> > Commit message: "Add missing license header. Message should implement
>> StringBuilderFormattable"
>> >> git config core.sparsecheckout # timeout=10
>> >> git checkout -f c9a92d9de75f73390b3afa2ca9ade3097e478281
>> >> git rev-list 39114a7af34a01312bcbefadf3e905dcb6fde75b # timeout=10
>> > [EnvInject] - Executing scripts and injecting environment variables
>> after the SCM step.
>> > [EnvInject] - Injecting as environment variables the properties content
>> > LANG=en_US.UTF-8
>> >
>> > [EnvInject] - Variables injected successfully.
>> > Parsing POMs
>> > Modules changed, recalculating dependency graph
>> > Established TCP socket on 49485
>> > maven33-agent.jar already up to date
>> > maven33-interceptor.jar already up to date
>> > maven3-interceptor-commons.jar already up to date
>> > [Log4j 2.x] $ /home/jenkins/tools/java/latest1.8/bin/java -Xmx2g
>> -Xms256m -XX:MaxPermSize=256m -cp
>> /home/jenkins/jenkins-slave/maven33-agent.jar:/home/jenkins/tools/maven/apache-maven-3.3.9/boot/plexus-classworlds-2.5.2.jar:/home/jenkins/tools/maven/apache-maven-3.3.9/conf/logging
>> jenkins.maven3.agent.Maven33Main
>> /home/jenkins/tools/maven/apache-maven-3.3.9
>> /home/jenkins/jenkins-slave/slave.jar
>> /home/jenkins/jenkins-slave/maven33-interceptor.jar
>> /home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 49485
>> > Java HotSpot(TM) 64-Bit Server VM warning: ignoring option
>> MaxPermSize=256m; support was removed in 8.0
>> > <===[JENKINS REMOTING CAPACITY]===>   channel started
>> > Executing Maven:  -B -f <
>> https://builds.apache.org/job/Log4j%202.x/ws/pom.xml>
>> -Dmaven.repo.local=/home/jenkins/jenkins-slave/maven-repositories/1 -t
>> jenkins-toolchains.xml -DuseJava7 -Djenkins clean install
>> > [INFO] Scanning for projects...
>> > [WARNING]
>> > [WARNING] Some problems were encountered while building the effective
>> model for
>> org.apache.logging.log4j.samples:log4j-samples-flume-remote:war:2.9-SNAPSHOT
>> > [WARNING] 'build.plugins.plugin.(groupId:artifactId)' must be unique
>> but found duplicate declaration of plugin
>> org.apache.maven.plugins:maven-deploy-plugin @
>> org.apache.logging.log4j.samples:log4j-samples-flume-remote:[unknown-version],
>> <
>> https://builds.apache.org/job/Log4j%202.x/ws/log4j-samples/flume-remote/pom.xml,>
>> line 12

Re: Logger names for nested classes

[Remko Popma]

Ok, let's document this clearly though. 

There may be users that have configuration to route logging from an inner class 
to a separate appender. If I'm not mistaken our change will break such 
configurations. 

Also: does Class.getCanonicalName() preserve the trailing $ in Scala classes?

(Shameless plug) Every java main() method deserves http://picocli.info

> On Aug 20, 2017, at 15:43, Ralph Goers  wrote:
> 
> And I doubt there are many use cases where doing that will be an issue.
> 
> Ralph
> 
>> On Aug 19, 2017, at 5:35 PM, Gary Gregory  wrote:
>> 
>> The only change I am now talking about is replacing getName() with
>> getCannonicalName().
>> 
>> Gary
>> 
>>> On Aug 19, 2017 18:00, "Remko Popma"  wrote:
>>> 
>>> No objection to creating logger names from Class.getCanonicalName() instead
>>> of Class.getName(). I assume that this means we don't need a custom
>>> toLoggerName(Class)
>>> method.
>>> 
>>> Question for our Scala experts: does Class.getCanonicalName() preserve the
>>> trailing $ in Scala classes?
>>> 
>>> At some point there was talk of API changes. Is that still needed?
>>> Finally, I guess in order to keep supporting the current behaviour as well,
>>> we still need to build configuration support for this >> hierarchySeparators="./$" ... Is my understanding correct?
>>> 
>>> 
>>> On Sun, Aug 20, 2017 at 3:47 AM, Ralph Goers 
>>> wrote:
>>> 
>>>> I agree.
>>>> 
>>>> Ralph
>>>> 
>>>>> On Aug 19, 2017, at 11:43 AM, Matt Sicker  wrote:
>>>>> 
>>>>> Canonical name sounds like it makes sense. I wonder what that evaluates
>>>> to
>>>>> in other JVM languages like Scala, Kotlin, Clojure, etc., but it seems
>>> to
>>>>> make sense.
>>>>> 
>>>>> On 19 August 2017 at 13:23, Dominik Psenner 
>>> wrote:
>>>>> 
>>>>>> To me it is a simple and good solution to the problem. The first
>>>> outlined
>>>>>> solution has the pro that it would give a user more sophisticated ways
>>>> to
>>>>>> build logger hierarchies from class names, but it is also something
>>> that
>>>>>> only a very small subset of users would use. We can keep that as a
>>> wish
>>>> for
>>>>>> later.
>>>>>> 
>>>>>> 2017-08-19 20:13 GMT+02:00 Gary Gregory :
>>>>>> 
>>>>>>> Any opposition to using the canonical name?
>>>>>>> 
>>>>>>> Gary
>>>>>>> 
>>>>>>> On Aug 14, 2017 15:28, "Gary Gregory" 
>>> wrote:
>>>>>>> 
>>>>>>>> In LogManager, if we call getCanonicalName() instead of getName(),
>>> we
>>>>>>> only
>>>>>>>> get "."s, no "$"s...
>>>>>>>> 
>>>>>>>> How about that?
>>>>>>>> 
>>>>>>>> Gary
>>>>>>>> 
>>>>>>>> On Mon, Aug 14, 2017 at 3:24 PM, Gary Gregory <
>>> garydgreg...@gmail.com
>>>>> 
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Another way to look at this is that instead of calling
>>>> class.getName()
>>>>>>> we
>>>>>>>>> would call our own toLoggerName(Class) which would NOT use $ but
>>> only
>>>>>>> use
>>>>>>>>> "."s.
>>>>>>>>> 
>>>>>>>>> Gary
>>>>>>>>> 
>>>>>>>>> On Mon, Aug 14, 2017 at 3:07 PM, Matt Sicker 
>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> The logger name hierarchy interpretation is handled at the string
>>>>>>> level,
>>>>>>>>>> not the class level. I don't think the class needs to be passed
>>>> along
>>>>>>> as
>>>>>>>>>> there isn't much useful info we can get from the Class instance
>>> that
>>>>>> we
>>>>>>>>>> can't already figure out from its FQCN.
>>>>>>>>>> 
>>>&

Re: SocketOptions builder

[Remko Popma]

Not breaking binary comparability (so leaving it as it is) is fine. 

(Shameless plug) Every java main() method deserves http://picocli.info

> On Aug 22, 2017, at 0:32, Gary Gregory  wrote:
> 
> To be clear, what is fine? Leaving it as is, or breaking Core BC and make
> the change from "set" to "with" now?
> 
> Gary
> 
>> On Thu, Aug 17, 2017 at 4:21 PM, Remko Popma  wrote:
>> 
>> That's fine I think.
>> 
>> (Shameless plug) Every java main() method deserves http://picocli.info
>> 
>>> On Aug 18, 2017, at 7:18, Gary Gregory  wrote:
>>> 
>>> What I did not do is change the "set" methods to "with" to avoid breaking
>>> user sources. We should do that for 3.0 I think.
>>> 
>>> Gary
>>> 
>>>> On Thu, Aug 17, 2017 at 4:10 PM, Remko Popma 
>> wrote:
>>>> 
>>>> I like the idiom where setter methods return `this`, so users can chain
>>>> methods; thanks for making that change.
>>>> 
>>>> 
>>>> On Fri, Aug 18, 2017 at 5:41 AM, Gary Gregory 
>>>> wrote:
>>>> 
>>>>> Hi All and FYI:
>>>>> 
>>>>> I plan on redoing the SocketOptions class as a real builder by making
>> all
>>>>> accessors return this.
>>>>> 
>>>>> Any objections?
>>>>> 
>>>>> Gary
>>>>> 
>>>> 
>> 

Re: org.apache.logging.log4j.core.LoggerContext getLogger(Class)

[Remko Popma]

What I don't like about this proposal is that LogManager.getLogger(Class)
would end up working differently than
o.a.l.l.core.LoggerContext.getLogger(Class). (One uses Class.getName, the
other Class.getCanonicalName.)

Why not just use org.apache.logging.log4j.core.
LoggerContext.getLogger(clazz.getCanonicalName()) in your application?

On Wed, Aug 23, 2017 at 12:32 AM, Gary Gregory 
wrote:

> Hi Ralph,
>
> I looked over the links and I (still) do understand the separation and I
> have a follow up question below.
>
> First, to be precise, I am proposing to add this shorthand method (note
> there is no @Override to ease compatibility, so no change to
> org.apache.logging.log4j.spi.LoggerContext):
>
> diff --git
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/
> LoggerContext.java
> b/log4j-core/src/main/java/org/apache/logging/log4j/core/
> LoggerContext.java
> index cd15dce..8002853 100644
> ---
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/
> LoggerContext.java
> +++
> b/log4j-core/src/main/java/org/apache/logging/log4j/core/
> LoggerContext.java
> @@ -410,6 +410,17 @@
>  }
>
>  /**
> + * Returns a Logger using the fully qualified name of the Class as the
> Logger name.
> + *
> + * @param clazz The Class whose name should be used as the Logger
> name. If null it will default to the calling
> + *class.
> + * @return The Logger.
> + */
> +public Logger getLogger(final Class clazz) {
> +return getLogger(clazz.getCanonicalName(), null);
> +}
> +
> +/**
>   * Gets a Logger from the Context.
>   *
>   * @param name The name of the Logger to return.
>
> Regardless of the above, would you say that the interface
> org.apache.logging.log4j.spi.LoggerContext is also "out of bounds" for
> normal/non-advanced use cases of "get me a logger" even though it is in the
> log4j-api module?
>
> Thank you again!
> Gary
>
>
> On Mon, Aug 21, 2017 at 10:34 PM, Gary Gregory 
> wrote:
>
> > On Mon, Aug 21, 2017 at 10:27 PM, Ralph Goers <
> ralph.go...@dslextreme.com>
> > wrote:
> >
> >> I would say look at http://logging.apache.org/log4j/2.x/ <
> >> http://logging.apache.org/log4j/2.x/> and that paragraph entitled “API
> >> Separation”. Then look at http://logging.apache.org/log4
> >> j/2.x/manual/api.html  >> 4j/2.x/manual/api.html>. The first paragraph makes it clear what our
> >> intent is. It should be telling that nowhere on that page is the
> >> LoggerContext mentioned. It isn’t until you get to the Configuration
> >> section that LoggerContext APIs are discussed.
> >>
> >> So the intent of the design is that code that is performing logging
> >> sticks to the Log4j API - providing it with a guarantee of backward
> >> compatibility. In a lot of cases no custom configuration is needed and
> so
> >> the whole application will be compatible no matter what we change
> >> internally.  That doesn’t mean that getLogger() cannot be called - but
> IMO
> >> applications should never be calling it for “normal" logging operations.
> >>
> >> All of that said, I wouldn’t veto a code commit to do what you want. It
> >> is just not something I’d consider as a worst practice if I found it in
> >> someone’s code for “normal” logging and I would strongly recommend they
> >> change it.
> >>
> >
> > Thanks for the details. I'll read up on the links and sleep on it.
> >
> > Gary
> >
> >
> >>
> >> Ralph
> >>
> >> > On Aug 21, 2017, at 6:45 PM, Gary Gregory 
> >> wrote:
> >> >
> >> > Hi Ralph,
> >> >
> >> > Would you say that is your opinion or the intent of the design? And if
> >> the
> >> > latter, should we adjust the Javadoc accordingly.
> >> >
> >> > Gary
> >> >
> >> > On Mon, Aug 21, 2017 at 7:31 PM, Ralph Goers <
> >> ralph.go...@dslextreme.com>
> >> > wrote:
> >> >
> >> >> I am against encouraging users to directly acquire a Logger.
> >> >>
> >> >> Ralph
> >> >>
> >> >>
> >> >>> On Aug 21, 2017, at 5:24 PM, Gary Gregory 
> >> >> wrote:
> >> >>>
> >> >>> On Mon, Aug 21, 2017 at 6:01 PM, Ralph Goers <
> >> ralph.go...@dslextreme.com
> >> >>>
> >> >>> wrote:
> >> >>>
> >>  It is actually funny that you say that. The API we provide for
> >> >> performing
> >>  logging is log4j-api, not log4j-core. We provide access in
> log4j-core
> >> >> for
> >>  users to customize how they configure their logging - not perform
> it.
> >> 
> >> >>>
> >> >>> I'm all about humoring the ML :-)
> >> >>>
> >> >>> Any further thoughts on adding these APIs? For or against?
> >> >>>
> >> >>> Gary
> >> >>>
> >> 
> >>  Ralph
> >> 
> >> > On Aug 21, 2017, at 3:42 PM, Gary Gregory  >
> >>  wrote:
> >> >
> >> > Hi,
> >> >
> >> > When someone calls any of the init methods like
> >> > org.apache.logging.log4j.core.config.Configurator.initialize
> >> (String,
> >> > ClassLoader, String), you get a Core LoggerContext, and that's
> what
> >>  you've
> >> > got to work with... Why i

Re: org.apache.logging.log4j.core.LoggerContext getLogger(Class)

[Remko Popma]

> On Aug 23, 2017, at 2:22, Gary Gregory  wrote:
> 
>> On Tue, Aug 22, 2017 at 10:27 AM, Remko Popma  wrote:
>> 
>> What I don't like about this proposal is that LogManager.getLogger(Class)
>> would end up working differently than
>> o.a.l.l.core.LoggerContext.getLogger(Class). (One uses Class.getName, the
>> other Class.getCanonicalName.)
>> 
> 
> No it would not, LogManager now uses getCanonicalName() based on last
> week's discussion. The shorthand APIs should all use getCanonicalName() now.
> 
I stand corrected. 

> 
>> 
>> Why not just use org.apache.logging.log4j.core.
>> LoggerContext.getLogger(clazz.getCanonicalName()) in your application?
>> 
> 
> Because that leave open the original problem, it's too easy to mess up and
> call getName().  This is a shorthand API just like
> LogManager.getLogger(Class). I always want to call an API that takes a
> Class where I can to avoid the mix up.
> 
> Gary
> 
>> 
>> On Wed, Aug 23, 2017 at 12:32 AM, Gary Gregory 
>> wrote:
>> 
>>> Hi Ralph,
>>> 
>>> I looked over the links and I (still) do understand the separation and I
>>> have a follow up question below.
>>> 
>>> First, to be precise, I am proposing to add this shorthand method (note
>>> there is no @Override to ease compatibility, so no change to
>>> org.apache.logging.log4j.spi.LoggerContext):
>>> 
>>> diff --git
>>> a/log4j-core/src/main/java/org/apache/logging/log4j/core/
>>> LoggerContext.java
>>> b/log4j-core/src/main/java/org/apache/logging/log4j/core/
>>> LoggerContext.java
>>> index cd15dce..8002853 100644
>>> ---
>>> a/log4j-core/src/main/java/org/apache/logging/log4j/core/
>>> LoggerContext.java
>>> +++
>>> b/log4j-core/src/main/java/org/apache/logging/log4j/core/
>>> LoggerContext.java
>>> @@ -410,6 +410,17 @@
>>> }
>>> 
>>> /**
>>> + * Returns a Logger using the fully qualified name of the Class as
>> the
>>> Logger name.
>>> + *
>>> + * @param clazz The Class whose name should be used as the Logger
>>> name. If null it will default to the calling
>>> + *class.
>>> + * @return The Logger.
>>> + */
>>> +public Logger getLogger(final Class clazz) {
>>> +return getLogger(clazz.getCanonicalName(), null);
>>> +}
>>> +
>>> +/**
>>>  * Gets a Logger from the Context.
>>>  *
>>>  * @param name The name of the Logger to return.
>>> 
>>> Regardless of the above, would you say that the interface
>>> org.apache.logging.log4j.spi.LoggerContext is also "out of bounds" for
>>> normal/non-advanced use cases of "get me a logger" even though it is in
>> the
>>> log4j-api module?
>>> 
>>> Thank you again!
>>> Gary
>>> 
>>> 
>>> On Mon, Aug 21, 2017 at 10:34 PM, Gary Gregory 
>>> wrote:
>>> 
>>>> On Mon, Aug 21, 2017 at 10:27 PM, Ralph Goers <
>>> ralph.go...@dslextreme.com>
>>>> wrote:
>>>> 
>>>>> I would say look at http://logging.apache.org/log4j/2.x/ <
>>>>> http://logging.apache.org/log4j/2.x/> and that paragraph entitled
>> “API
>>>>> Separation”. Then look at http://logging.apache.org/log4
>>>>> j/2.x/manual/api.html <http://logging.apache.org/log
>>>>> 4j/2.x/manual/api.html>. The first paragraph makes it clear what our
>>>>> intent is. It should be telling that nowhere on that page is the
>>>>> LoggerContext mentioned. It isn’t until you get to the Configuration
>>>>> section that LoggerContext APIs are discussed.
>>>>> 
>>>>> So the intent of the design is that code that is performing logging
>>>>> sticks to the Log4j API - providing it with a guarantee of backward
>>>>> compatibility. In a lot of cases no custom configuration is needed and
>>> so
>>>>> the whole application will be compatible no matter what we change
>>>>> internally.  That doesn’t mean that getLogger() cannot be called - but
>>> IMO
>>>>> applications should never be calling it for “normal" logging
>> operations.
>>>>> 
>>>>> All of that said, I wouldn’t veto a code commit to do what you want.
>> It
>>>>> is just not something I’d c

Re: [VOTE] Release Log4j 2.9.0-rc1

[Remko Popma]

+1

Tested with
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-11T01:41:47+09:00)
Maven home: C:\apps\apache-maven-3.3.9\bin\..
Java version: 1.8.0_131, vendor: Oracle Corporation
Java home: C:\apps\jdk1.8.0_131\jre
Default locale: en_US, platform encoding: MS932
OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos"

mvn clean install - OK

website - OK, except for some stylesheet problem for everything under
http://logging.apache.org/log4j/scala/index.html
   not a showstopper, can fix later

checksums - Could not find my script to recursively check the tree - no
time to write a new one. Not a showstopper since other people checked.




On Sun, Aug 27, 2017 at 11:45 AM, Ralph Goers 
wrote:

> This is a vote to release Log4j 2.9.0 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 welcome and we encourage everyone to test the release, but only Logging
> PMC votes are “officially” counted. As always, at least 3 +1 votes and more
> positive than negative votes are required.
> Changes in this version include:
>
>   SE-NOTES.md#new-features>New Features
>
> LOG4J2-2008 : Support
> printing multiple StructuredData elements in RFC5424Layout.
> LOG4J2-1986 : Public
> API for parsing the output from JsonLayout/XmlLayout/YamlLayout into a
> LogEvent.
> LOG4J2-1981 :
> JsonLayout, XmlLayout and YamlLayout support 0-byte termination of log
> events.
> LOG4J2-1864 : Support
> capped collections for MongoDb appender. Thanks to Matthias Kappeller.
> LOG4J2-1813 : Log4j2
> will now print all internal logging to the console if system property
> log4j2.debug is defined with any value (or no value).
> LOG4J2-1766 :
> Temporary compress directory during rollover (#88). Thanks to Pierrick
> HYMBERT.
> LOG4J2-1814 : Added
> wrapper classes CustomLoggerGenerator and ExtendedLoggerGenerator to avoid
> class name with a dollar ($) character which has special meaning in many
> *nix command line environments.
> LOG4J2-1884 : Added
> process ID (pid) pattern converter.
> LOG4J2-1699 :
> Configurable Log File Permissions with PosixFilePermission. Thanks to
> Demetrios Dimatos, Pierrick HYMBERT.
> LOG4J2-1945 : Generate
> source jas for all test jars.
> LOG4J2-1934 : JMS
> Appender does not know how to recover from a broken connection.
> LOG4J2-1955 : JMS
> Appender should be able connect to a broker (later) even it is not present
> at configuration time.
> LOG4J2-1874 : Added
> methods ::writeBytes(ByteBuffer) and ::writeBytes(byte[], int, int) to
> ByteBufferDestination interface and use these methods in TextEncoderHelper
> where possible to prepare for future enhancements to reduce lock
> contention. Thanks to Roman Leventov.
> LOG4J2-1442 : Generic
> HTTP appender.
> LOG4J2-1935 : Add
> with(String, primitive) methods to org.apache.logging.log4j.messa
> ge.MapMessage.
> LOG4J2-1930 : Add
> forEach() methods to org.apache.logging.log4j.message.MapMessage.
> LOG4J2-1932 : Add
> containsKey() methods to org.apache.logging.log4j.message.MapMessage.
> LOG4J2-1854 : Support
> null byte delimiter in GelfLayout. Thanks to Xavier Jodoin.
> LOG4J2-1359 : Add
> support for Java 9 StackWalker.
> LOG4J2-1880 : Warn
> when a configuration file for an inactive ConfigurationFactory is found.
> LOG4J2-1855 : Add an
> optional random delay in TimeBasedTriggeringPolicy Thanks to Anthony Maire.
> LOG4J2-1860 : Shortcut
> to add Property and KeyValuePair component in ConfigurationBuilder.
> LOG4J2-1294 : The JMS
> Appender should use a JMS MapMessage for a Log4j MapMessage.
>  

Re: [VOTE] Release Log4j 2.9.0-rc1

[Remko Popma]

If anyone has a script for recursively checking the checksums of a directory 
tree I'd be much obliged. 

(Shameless plug) Every java main() method deserves http://picocli.info

> On Aug 30, 2017, at 14:36, Ralph Goers  wrote:
> 
> Here is my +1
> 
> Ralph
> 
>> On Aug 26, 2017, at 7:45 PM, Ralph Goers  wrote:
>> 
>> This is a vote to release Log4j 2.9.0 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 
>> welcome and we encourage everyone to test the release, but only Logging PMC 
>> votes are “officially” counted. As always, at least 3 +1 votes and more 
>> positive than negative votes are required.
>> Changes in this version include:
>> 
>> New
>>  Features
>> 
>> LOG4J2-2008 : Support 
>> printing multiple StructuredData elements in RFC5424Layout.
>> LOG4J2-1986 : Public API 
>> for parsing the output from JsonLayout/XmlLayout/YamlLayout into a LogEvent.
>> LOG4J2-1981 : JsonLayout, 
>> XmlLayout and YamlLayout support 0-byte termination of log events.
>> LOG4J2-1864 : Support 
>> capped collections for MongoDb appender. Thanks to Matthias Kappeller.
>> LOG4J2-1813 : Log4j2 will 
>> now print all internal logging to the console if system property 
>> log4j2.debug is defined with any value (or no value).
>> LOG4J2-1766 : Temporary 
>> compress directory during rollover (#88). Thanks to Pierrick HYMBERT.
>> LOG4J2-1814 : Added 
>> wrapper classes CustomLoggerGenerator and ExtendedLoggerGenerator to avoid 
>> class name with a dollar ($) character which has special meaning in many 
>> *nix command line environments.
>> LOG4J2-1884 : Added 
>> process ID (pid) pattern converter.
>> LOG4J2-1699 : 
>> Configurable Log File Permissions with PosixFilePermission. Thanks to 
>> Demetrios Dimatos, Pierrick HYMBERT.
>> LOG4J2-1945 : Generate 
>> source jas for all test jars.
>> LOG4J2-1934 : JMS 
>> Appender does not know how to recover from a broken connection.
>> LOG4J2-1955 : JMS 
>> Appender should be able connect to a broker (later) even it is not present 
>> at configuration time.
>> LOG4J2-1874 : Added 
>> methods ::writeBytes(ByteBuffer) and ::writeBytes(byte[], int, int) to 
>> ByteBufferDestination interface and use these methods in TextEncoderHelper 
>> where possible to prepare for future enhancements to reduce lock contention. 
>> Thanks to Roman Leventov.
>> LOG4J2-1442 : Generic 
>> HTTP appender.
>> LOG4J2-1935 : Add 
>> with(String, primitive) methods to 
>> org.apache.logging.log4j.message.MapMessage.
>> LOG4J2-1930 : Add 
>> forEach() methods to org.apache.logging.log4j.message.MapMessage.
>> LOG4J2-1932 : Add 
>> containsKey() methods to org.apache.logging.log4j.message.MapMessage.
>> LOG4J2-1854 : Support 
>> null byte delimiter in GelfLayout. Thanks to Xavier Jodoin.
>> LOG4J2-1359 : Add support 
>> for Java 9 StackWalker.
>> LOG4J2-1880 : Warn when a 
>> configuration file for an inactive ConfigurationFactory is found.
>> LOG4J2-1855 : Add an 
>> optional random delay in TimeBasedTriggeringPolicy Thanks to Anthony Maire.
>> LOG4J2-1860 : Shortcut to 
>> add Property and KeyValuePair component in ConfigurationBuilder.
>> LOG4J2-1294 : The JMS 
>> Appender should use a JMS MapMessage for a Log4j MapMessage.
>> Fixed
>>  Bugs
>> 
>> LOG4J2-1833 : Prevent 
>> NullPointerException when a file name is specified with the 
>> DirectWriteRolloverStrategy.
>> LOG4J2-2018 

Re: [VOTE][RESULT] Log4j 2.9.0-rc1

[Remko Popma]

I drafted a Log4j 2.9 release blog post. 
I'll hold off on publishing until the announcement email. Roughly what time do 
you think you'll send it, Ralph?

Remko 

> On Aug 30, 2017, at 14:43, Ralph Goers  wrote:
> 
> The vote to release Log4j 2.9.0 based on release candidate 1 has passed with 
> +1 votes from Gary Gregory, Matt Sicker, Mikael Ståldal, Remko Popma, and 
> Ralph Goers. No other votes were cast.
> 
> I will continue with the release process.
> 
> Ralph

Re: [ANNOUNCE] Apache Log4j 2.9.0 released

[Remko Popma]

Blogged: https://blogs.apache.org/logging/entry/log4j-2-9-released

(Shameless plug) Every java main() method deserves http://picocli.info

> On Aug 31, 2017, at 9:26, Ralph Goers  wrote:
> 
> The Apache Log4j 2 team is pleased to announce the Log4j 2.9.0 release!
> 
> Apache Log4j is a well known framework for logging application behavior. 
> Log4j 2 is an upgrade to Log4j that provides significant improvements over 
> its predecessor, Log4j 1.x, and provides many other modern features such as 
> support for Markers, lambda expressions for lazy logging, property 
> substitution using Lookups, multiple patterns on a PatternLayout and 
> asynchronous Loggers. Another notable Log4j 2 feature is the ability to be 
> "garbage-free" (avoid allocating temporary objects) while logging. In 
> addition, Log4j 2 will not lose events while reconfiguring.
> 
> This release contains the first support of Java 9 as well as bugfixes and 
> minor enhancements. The Log4j API was modified to use java.util.ServiceLoader 
> to locate Log4j implementations, although the former binding mechanism is 
> still supported. The Log4j jar is now a multi-release jar to provide 
> implementations of the Java 9 specific classes. Multi-release jars are not 
> supported by the OSGi specification so OSGi modules will not be able to take 
> advantage of these implementations but will not lose functionality as they 
> will fall back to the implementations used in Java 7 and 8. More details on 
> the new features and fixes are itemized below.
> 
> Note that subsequent to the 2.9 release, for security reasons, 
> SerializedLayout is deprecated and no longer used as default in the Socket 
> and JMS appenders. SerializedLayout can still be used as before, but has to 
> be specified explicitly. To retain old behaviour, you have to change 
> configuration like:
> 
> 
>  
> 
> into:
> 
> 
>  
>
>  
> 
> We do, however, discourage the use of SerializedLayout and recommend 
> JsonLayout as a replacement:
> 
> 
>  
>
>  
> 
> Note that subsequent to the 2.9 release, for security reasons, Log4j does not 
> process DTD in XML files. If you used DTD for including snippets, you have to 
> use XInclude or Composite Configuration instead.
> 
> The Log4j 2.9.0 API, as well as many core components, maintains binary 
> compatibility with previous releases.
> 
> GA
>  Release 2.9.0
> 
> Changes in this version include:
> 
> New
>  Features
> 
> LOG4J2-2008 : Support 
> printing multiple StructuredData elements in RFC5424Layout.
> LOG4J2-1986 : Public API 
> for parsing the output from JsonLayout/XmlLayout/YamlLayout into a LogEvent.
> LOG4J2-1981 : JsonLayout, 
> XmlLayout and YamlLayout support 0-byte termination of log events.
> LOG4J2-1864 : Support 
> capped collections for MongoDb appender. Thanks to Matthias Kappeller.
> LOG4J2-1813 : Log4j2 will 
> now print all internal logging to the console if system property log4j2.debug 
> is defined with any value (or no value).
> LOG4J2-1766 : Temporary 
> compress directory during rollover (#88). Thanks to Pierrick HYMBERT.
> LOG4J2-1814 : Added 
> wrapper classes CustomLoggerGenerator and ExtendedLoggerGenerator to avoid 
> class name with a dollar ($) character which has special meaning in many *nix 
> command line environments.
> LOG4J2-1884 : Added 
> process ID (pid) pattern converter.
> LOG4J2-1699 : Configurable 
> Log File Permissions with PosixFilePermission. Thanks to Demetrios Dimatos, 
> Pierrick HYMBERT.
> LOG4J2-1945 : Generate 
> source jas for all test jars.
> LOG4J2-1934 : JMS Appender 
> does not know how to recover from a broken connection.
> LOG4J2-1955 : JMS Appender 
> should be able connect to a broker (later) even it is not present at 
> configuration time.
> LOG4J2-1874 : Added 
> methods ::writeBytes(ByteBuffer) and ::writeBytes(byte[], int, int) to 
> ByteBufferDestination interface and use these methods in TextEncoderHelper 
> where possible to prepare for future enhancements to reduce lock contention. 
> Thanks to Roman Leventov.
> LOG4J2-1442 : Generic HTTP 
> appender.
> LOG4J2-1935 

Re: Log4j support for Tomcat, TomEE, JBoss, etc.

[Remko Popma]

log4j-container?
(To be more generic than javaee)


> On Sep 7, 2017, at 4:56, Ralph Goers  wrote:
> 
> Yes, the intent would be to allow containers to use Log4j as their logging 
> implementation.
> 
> Ralph
> 
>> On Sep 6, 2017, at 12:26 PM, Mikael Ståldal  wrote:
>> 
>> Is the point to integrate with JavaEE containers, not necessarily from a web 
>> app?
>> 
>> Then I would suggest a new module log4j-javaee, and to put it in the main 
>> repo.
>> 
>> 
>>> On 2017-09-06 20:49, Ralph Goers wrote:
>>> On the commons list I got some pointers on how to integrate with Tomcat 
>>> 8.5+ and TomEE. I’ve written the class that is required but am wondering 
>>> where to put it. It could go in log4j-core, but that isn’t where we have 
>>> been putting these things. It really shouldn’t go in log4j-web as users may 
>>> not want that jar just to get the integration with log4j.
>>> I am thinking a new module should be created for this - something like 
>>> log4j-containers. If I do that does it belong in log4j2 or in log4j-tools, 
>>> log4j-boot or some other repo?
>> 
> 
> 

Re: Log4j support for Tomcat, TomEE, JBoss, etc.

[Remko Popma]

I guess it depends on what dependencies this module requires. 

If this module requires Tomcat dependencies then perhaps  log4j-tomcat is 
better because another container wouldn't want to drag in the Tomcat 
dependencies. 

If there's no dependency on any specific container or on any javaEE jars I'd 
keep it to generic container and split further when appropriate...

About the repo, this may be a good candidate for moving outside the main repo 
to speed up the build. Update/release frequency may differ from the main 
releases.  
Maybe log4j-tools?

One thing about the separate repos is that integration is still incomplete. Is 
the log4j-tools site published? It's not referenced from the Log4j2 site. Also 
we should link to the log4j-tools artifacts from the main Download page. 

Remko 

(Shameless plug) Every java main() method deserves http://picocli.info

> On Sep 7, 2017, at 7:39, Gary Gregory  wrote:
> 
> The word container is so vague... container of what? Files, Applications,
> NoSQL things? How about app-container?
> 
> Gary
> 
>> On Wed, Sep 6, 2017 at 4:07 PM, Remko Popma  wrote:
>> 
>> log4j-container?
>> (To be more generic than javaee)
>> 
>> 
>>> On Sep 7, 2017, at 4:56, Ralph Goers  wrote:
>>> 
>>> Yes, the intent would be to allow containers to use Log4j as their
>> logging implementation.
>>> 
>>> Ralph
>>> 
>>>> On Sep 6, 2017, at 12:26 PM, Mikael Ståldal  wrote:
>>>> 
>>>> Is the point to integrate with JavaEE containers, not necessarily from
>> a web app?
>>>> 
>>>> Then I would suggest a new module log4j-javaee, and to put it in the
>> main repo.
>>>> 
>>>> 
>>>>> On 2017-09-06 20:49, Ralph Goers wrote:
>>>>> On the commons list I got some pointers on how to integrate with
>> Tomcat 8.5+ and TomEE. I’ve written the class that is required but am
>> wondering where to put it. It could go in log4j-core, but that isn’t where
>> we have been putting these things. It really shouldn’t go in log4j-web as
>> users may not want that jar just to get the integration with log4j.
>>>>> I am thinking a new module should be created for this - something like
>> log4j-containers. If I do that does it belong in log4j2 or in log4j-tools,
>> log4j-boot or some other repo?
>> 

Re: [jira] [Commented] (LOG4J2-2031) Messages appear out of order in log file (was: Log4j2 log file not reflecting application log function calls)

[Remko Popma]

I don't think that this should be the responsibility of the users. The library 
needs to be safe to use even when used "wrongly". 

Cases in point:
* we prevent infinite recursion when a collection is logged that contains 
itself 
* we agreed to catch and suppress exceptions thrown from domain objects' 
{{toString}} method 

Preventing deadlock when application objects log from their {{toString}} method 
is also the job of the library. 

Our current solution results in messages appearing out of sequence in the log 
file. This is better than deadlocking the application. It is also better than 
throwing an exception or reducing the service level to allow only primitive 
values to be logged. 

But the current solution is still surprising and inconvenient for users. We can 
do better, which is what the ticket aims to achieve. 

I hope this clarifies things. 

PS.
Your comments are not visible on the JIRA ticket. (Just letting you know in 
case you want to add something there.)

(Shameless plug) Every java main() method deserves http://picocli.info

> On Sep 10, 2017, at 23:15, Dominik Psenner  wrote:
> 
> In addition to that a less aggressive (or lazy) mode of operation could
> detect rogue recursions and throw in such a situation to prevent deadlocks.
> 
> The last mode of operation could do no checks at all, but that mode would
> not prevent from deadlocks or infinite recursions at all.
> 
>> On 10 Sep 2017 4:06 p.m., "Dominik Psenner"  wrote:
>> 
>> I opt that everyone should use the library in a way that makes sure
>> deadlocks cannot happen. Trying to solve this by fancy "deadlock could
>> occur" mechanisms feels wrong.
>> 
>> A very restrictive mode of operation could enforce that all arguments
>> passed into a log event must be limited to immutable primitive types. In
>> this mode deadlocks could no longer occur because rogue recursions would
>> actively prevented.
>> 
>> On 10 Sep 2017 3:43 p.m., "Remko Popma (JIRA)"  wrote:
>> 
>> 
>>[ https://issues.apache.org/jira/browse/LOG4J2-2031?page=com.
>> atlassian.jira.plugin.system.issuetabpanels:comment-tabpane
>> l&focusedCommentId=16160342#comment-16160342 ]
>> 
>> Remko Popma commented on LOG4J2-2031:
>> -
>> 
>> After thinking about this some more, I think it should be possible to
>> prevent messages from appearing out of order in most cases.
>> 
>> The reason Log4j2 logs directly to the appender, bypassing the async queue
>> when the queue is full, is to prevent deadlock.
>> 
>> However, when exactly is deadlock possible? Only when an application
>> object is logged that itself invokes a logging call in its {{toString}}
>> method. If the logging call from the {{toString}} method would block until
>> it was able to add a new LogEvent to the queue, then the object that is
>> being logged could never return from its {{toString}} method, resulting in
>> deadlock.
>> 
>> For "normal" logging calls (not from a {{toString}}) it is fine to block
>> when the queue is full, because the background thread will eventually make
>> a slot available.
>> 
>> Currently the [DefaultAsyncQueueFullPolicy|https://logging.apache.org/log4
>> j/2.0/log4j-core/apidocs/org/apache/logging/log4j/core/asyn
>> c/DefaultAsyncQueueFullPolicy.html] is very conservative and logs
>> directly to the underlying appender for _all_ events when the queue is
>> full. This can be improved by trying to rule out cases where deadlock could
>> not occur, and in such cases, block until space in the queue becomes
>> available.
>> 
>> Ways to detect potential deadlock situations when the queue is full:
>> * the logging thread is a background thread (of any of the Async
>> Appenders, or a Disruptor) - this is the original solution for LOG4J2-471
>> * set a thread-local flag when logging is invoked (specifically, before
>> calling {{Disruptor.tryPublish}}). If the flag has already been set then
>> deadlock is possible - this should cover LOG4J2-1518
>> 
>> If deadlock is possible, the current behaviour (log directly to the
>> underlying appender) is the safe thing to do. Perhaps a suffix should be
>> appended to such log events to the effect that "(Log4j2) This message
>> appears out of order to prevent deadlock: logging inside the toString()
>> method is not recommended."
>> 
>> Thoughts?
>> 
>>> Messages appear out of order in log file (was: Log4j2 log file not
>> reflecting application log function calls)
>>> ---

Re: Random failure in AsyncLoggerAndAsyncAppenderTest

[Remko Popma]

I've looked at this before but couldn't figure it out. I'll take another look. 

(Shameless plug) Every java main() method deserves http://picocli.info

> On Sep 12, 2017, at 9:00, Matt Sicker  wrote:
> 
> I'm pretty sure I've seen that failure (or something similar at least)
> several times before. I believe the issue is essentially due to
> asynchronicity compared to JUnit. I wonder if JUnit 5 has async test
> support, though if we upgrade to that, then the tests will require Java 8.
> 
>> On 11 September 2017 at 14:16, Gary Gregory  wrote:
>> 
>> Just FYI:
>> 
>> I am seeing this random but infrequent failure:
>> 
>> [ERROR] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
>> 1.62 s <<< FAILURE! - in
>> org.apache.logging.log4j.core.async.AsyncLoggerThreadContextGarbag
>> eFreeTest
>> [ERROR] testAsyncLogWritesToLog[GARBAGE_FREE
>> BOTH_ALL_ASYNC_AND_MIXED](org.apache.logging.log4j.core.async.
>> AsyncLoggerThreadContextGarbageFreeTest)
>> Time elapsed: 0.284 s  <<< FAILURE!
>> org.junit.ComparisonFailure: AsyncLoggerAndAsyncAppenderTest.log: line 0
>> expected:<...syncLoggerContext i=[0]> but was:<...syncLoggerContext
>> i=[128]>
>> 
>> Gary
>> 
> 
> 
> 
> -- 
> Matt Sicker 

Re: Automatic module names

[Remko Popma]

Isn't it the opposite? Giving them the same module name will prevents them from 
being used together, which is what we want:

http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html?m=1
"JPMS will simply refuse to start a modulepath where two modules have the same 
name, even if they contain different packages."

(Shameless plug) Every java main() method deserves http://picocli.info

> On Sep 12, 2017, at 13:29, Ralph Goers  wrote:
> 
> Actually, re-reading this again makes it clear to me that log4j-slf4j-impl 
> and log4j-to-slf4j SHOULD use the same package name as it prevents them from 
> both being present at the same time. Obviously, their module names still have 
> to be different but this could mean the code doesn’t really need to be 
> modified.
> 
> Ralph
> 
>> On Sep 11, 2017, at 6:26 PM, Matt Sicker  wrote:
>> 
>> Is it possible to make the JPMS module names the same as the OSGi ones? The
>> default OSGi naming scheme is basically:
>> 
>> groupId: org.apache.logging.log4j, artifactId: log4j-foo becomes bundleId:
>> org.apache.logging.log4j.foo
>> 
>>> On 11 September 2017 at 13:01, Gary Gregory  wrote:
>>> 
>>> On Mon, Sep 11, 2017 at 11:27 AM, Ralph Goers 
>>> wrote:
>>> 
 I know we discussed module names in the past and decided not to go the
 route of modularizing now - in fact, we can’t until all of our
>>> dependencies
 are modularized. However, we can (and probably should) add the automatic
 module name as a manifest entry to each of our jars. My understanding is
 that these would be the package name of the individual modules. For the
 most part this should be trivial given the structure of our code base.
 However I have two concerns:
 
 The package name used in log4j-api is org.apache.logging.log4j. My
 understanding is that the module name should match the package name, but
>>> I
 suspect most people would expect the module name to be
 org.apache.logging.log4j.api.
 
>>> 
>>> I think we can leave that one as is. The package is
>>> org.apache.logging.log4j and that seems reasonable. It's the module
>>> name/artifact ID that we chose that is "different". If anything, I would
>>> change that.
>>> 
>>> 
 Both log4j-slf4j-impl and log4j-to-slf4j use org.apache.loggingj.slf4j.
 Notice that neither has log4j in the package name. These need to be
 separate packages to be able to define module names to them.
 
 Thoughts?
 
>>> 
>>> I think we should just bite the bullet and repackage these two under
>>> org.apache.logging.log4j. That means changing the module name and artifact
>>> ID though to avoid jar hell. log4j-slf4j-to-log4j and log4j-log4j-to-slf4j?
>>> A bit wordy... proposals?
>>> 
>>> Gary
>>> 
>>> 
 Ralph
>>> 
>> 
>> 
>> 
>> -- 
>> Matt Sicker 
> 
> 

Re: Log4J 2.9.1 release

[Remko Popma]

I'll try to put in a fix for 
https://issues.apache.org/jira/browse/LOG4J2-1988?filter=-1 
(java.util.ConcurrentModificationException with AsyncLogger?) today. 

Stretch goal: https://issues.apache.org/jira/browse/LOG4J2-2031 (Messages 
appear out of order in log file (was: Log4j2 log file not reflecting 
application log function calls))

Remko 

> On Sep 15, 2017, at 6:19, Gary Gregory  wrote:
> 
> That all sounds great!
> 
> Gary
> 
>> On Thu, Sep 14, 2017 at 1:33 PM, Matt Sicker  wrote:
>> 
>> I think we should release 2.9.1. If Ralph doesn't have time this weekend, I
>> can RM.
>> 
>> I have a feature (system properties/environment variables normalization)
>> I'd like to add to 2.10 and am waiting for our bugfixes first.
>> 
>>> On 14 September 2017 at 14:09, Mikael Ståldal  wrote:
>>> 
>>> So do we plan to release 2.9.1 soon? Should we wait with merging new
>>> features into master?
>>> 
>>> I think it would be good to release 2.9.1 before the Java 9 release on
>>> September 21th, since we have fixed a few Java 9 related issues.
>>> 
>>> Then we should wait for the Java 9 release, and test Log4j 2.9.1 with
>> Java
>>> 9 GA to verify that everything works fine. If not, we can do a 2.9.2 to
>> fix
>>> any issues found.
>>> 
>>> Then we add new features for 2.10.0.
>>> 
>>> 
>>> 
 On 2017-09-12 06:18, Ralph Goers wrote:
 
 OK. The module is commented out along with the update to changes.xml.
 
 Ralph
 
>>> 
>> 
>> 
>> --
>> Matt Sicker 
>> 

Re: [VOTE] Release Log4j 2.9.1-rc1

[Remko Popma]

+1

Builds fine, checksums good.

On Mon, Sep 18, 2017 at 4:07 PM, Ralph Goers 
wrote:

> This is a vote to release Log4j 2.9.1, 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 welcome and we encourage everyone to test the release, but only Logging
> PMC votes are “officially” counted. As always, at least 3 +1 votes and more
> positive than negative votes are required.
>
> Changes in this version include:
>
> Fixed Bugs
>
> • LOG4J2-1988: Prevent ConcurrentModificationException with
> AsyncLoggerConfig.
> • LOG4J2-1914: Prevent ConcurrentModificationException with
> AsyncLoggerConfig.
> • LOG4J2-2048: Increase default queue size for AsyncAppender from
> 128 to 1024.
> • LOG4J2-2035: Fix documentation to clarify disruptor-3.3.4 is now
> required for async loggers: disruptor-3.3.3 was never released.
> • LOG4J2-2030: Inspect all known ClassLoaders to locate the
> service provider.
> • LOG4J2-2028: Java 9 StackLocator was not properly skipping the
> initial stack frames. Thanks to Jason Tedor.
> • LOG4J2-2026: java.lang.AbstractMethodError: javax.xml.parsers.
> DocumentBuilderFactory.setFeature(). Thanks to Leon Finker.
> • LOG4J2-2029: Marker examples should not use deprecated flow
> APIs. Thanks to Fabrizio Cucci.
> • LOG4J2-1936: ClassNotFoundException when making all loggers
> asynchronous under OSGi environment. Thanks to Helber Belmiro.
>
> Changes
>
> • LOG4J2-2023: Use a class' canonical name instead of name to
> create its logger name.
> • LOG4J2-2043: Update Jackson from 2.9.0 to 2.9.1 (fix for Java 9.)
> • LOG4J2-2044: Update Apache Commons CSV from 1.4 to 1.5.
> • LOG4J2-2045: Update javax.mail from 1.5.6 to 1.6.0.
> • LOG4J2-2046: Update Apache Commons Compress from 1.13 to 1.14.
> • LOG4J2-2047: Update Cassandra driver from 3.1.0 to 3.1.4.
> • LOG4J2-2049: Update Apache Kafka Client from 0.11.0.0 to
> 0.11.0.1.
>
> Tag:
> a)  for a new copy do "git clone https://git-wip-us.apache.org/
> repos/asf/logging-log4j2.git" and then "git checkout tags/log4j-2.9.1-rc1”
> b) for an existing working copy to “git pull” and then “git checkout
> tags/log4j-2.9.1-rc1”
>
> Web Site:  http://rgoers.github.io/log4j2-site/index.html
>
> Maven Artifacts: https://repository.apache.org/content/repositories/
> orgapachelogging-1030
>
> Distribution archives: https://dist.apache.org/repos/
> dist/dev/logging/log4j/
>
> You may download all the Maven artifacts by executing:
> wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
> https://repository.apache.org/content/repositories/
> orgapachelogging-1030/org/apache/logging/log4j/
>
> Ralph
>

Re: [VOTE] Release Log4j 2.9.1-rc1

[Remko Popma]

I started writing the blog post for 2.9.1.
Quick question: no changes to the announcement text this time, is that
correct?

On Thu, Sep 21, 2017 at 1:12 PM, Ralph Goers 
wrote:

> My +1
>
> Ralph
>
> > On Sep 18, 2017, at 12:07 AM, Ralph Goers 
> wrote:
> >
> > This is a vote to release Log4j 2.9.1, 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 welcome and we encourage everyone to test the release, but only Logging
> PMC votes are “officially” counted. As always, at least 3 +1 votes and more
> positive than negative votes are required.
> >
> > Changes in this version include:
> >
> > Fixed Bugs
> >
> >   • LOG4J2-1988: Prevent ConcurrentModificationException with
> AsyncLoggerConfig.
> >   • LOG4J2-1914: Prevent ConcurrentModificationException with
> AsyncLoggerConfig.
> >   • LOG4J2-2048: Increase default queue size for AsyncAppender from
> 128 to 1024.
> >   • LOG4J2-2035: Fix documentation to clarify disruptor-3.3.4 is now
> required for async loggers: disruptor-3.3.3 was never released.
> >   • LOG4J2-2030: Inspect all known ClassLoaders to locate the
> service provider.
> >   • LOG4J2-2028: Java 9 StackLocator was not properly skipping the
> initial stack frames. Thanks to Jason Tedor.
> >   • LOG4J2-2026: java.lang.AbstractMethodError: javax.xml.parsers.
> DocumentBuilderFactory.setFeature(). Thanks to Leon Finker.
> >   • LOG4J2-2029: Marker examples should not use deprecated flow
> APIs. Thanks to Fabrizio Cucci.
> >   • LOG4J2-1936: ClassNotFoundException when making all loggers
> asynchronous under OSGi environment. Thanks to Helber Belmiro.
> >
> > Changes
> >
> >   • LOG4J2-2023: Use a class' canonical name instead of name to
> create its logger name.
> >   • LOG4J2-2043: Update Jackson from 2.9.0 to 2.9.1 (fix for Java 9.)
> >   • LOG4J2-2044: Update Apache Commons CSV from 1.4 to 1.5.
> >   • LOG4J2-2045: Update javax.mail from 1.5.6 to 1.6.0.
> >   • LOG4J2-2046: Update Apache Commons Compress from 1.13 to 1.14.
> >   • LOG4J2-2047: Update Cassandra driver from 3.1.0 to 3.1.4.
> >   • LOG4J2-2049: Update Apache Kafka Client from 0.11.0.0 to
> 0.11.0.1.
> >
> > Tag:
> > a)  for a new copy do "git clone https://git-wip-us.apache.org/
> repos/asf/logging-log4j2.git" and then "git checkout tags/log4j-2.9.1-rc1”
> > b) for an existing working copy to “git pull” and then “git checkout
> tags/log4j-2.9.1-rc1”
> >
> > Web Site:  http://rgoers.github.io/log4j2-site/index.html
> >
> > Maven Artifacts: https://repository.apache.org/content/repositories/
> orgapachelogging-1030
> >
> > Distribution archives: https://dist.apache.org/repos/
> dist/dev/logging/log4j/
> >
> > You may download all the Maven artifacts by executing:
> > wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
> https://repository.apache.org/content/repositories/
> orgapachelogging-1030/org/apache/logging/log4j/
> >
> > Ralph
> >
>
>
>

Re: logging-log4j2 git commit: Fix wording of 2.9.1 change item (LOG4J2-2035)

[Remko Popma]

Ralph,

Would it be possible to include the new wording in the 2.9.1 announcement email?

Remko 


> On Sep 22, 2017, at 7:17, rpo...@apache.org wrote:
> 
> Repository: logging-log4j2
> Updated Branches:
>  refs/heads/master 3f5d58cd3 -> 8b5d644d5
> 
> 
> Fix wording of 2.9.1 change item (LOG4J2-2035)
> 
> 
> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/8b5d644d
> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/8b5d644d
> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/8b5d644d
> 
> Branch: refs/heads/master
> Commit: 8b5d644d5716e47db2497ddd571a4b2f763861ec
> Parents: 3f5d58c
> Author: rpopma 
> Authored: Fri Sep 22 07:17:11 2017 +0900
> Committer: rpopma 
> Committed: Fri Sep 22 07:17:11 2017 +0900
> 
> --
> src/changes/changes.xml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/8b5d644d/src/changes/changes.xml
> --
> diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> index 6a63210..300b443 100644
> --- a/src/changes/changes.xml
> +++ b/src/changes/changes.xml
> @@ -46,7 +46,7 @@
> Increase default queue size for AsyncAppender from 128 to 1024.
>   
>   
> -Fix documentation to clarify disruptor-3.3.4 is now required for 
> async loggers: disruptor-3.3.3 was never released.
> +Fix documentation to clarify disruptor-3.3.4 is now required for 
> async loggers (previously the docs referred to disruptor-3.3.3 which was 
> never released).
>   
>   
> Inspect all known ClassLoaders to locate the service provider.
> 

Re: [VOTE] Release Log4j 2.9.1-rc1

[Remko Popma]

Okay. I'll update the draft blog post when I see your email. 

By the way, would it be possible to modify the announcement text for 
LOG4J2-2035 to "Fix documentation to clarify disruptor-3.3.4 is now required 
for async loggers (previously the docs referred to disruptor-3.3.3 which was 
never released)."?

(Shameless plug) Every java main() method deserves http://picocli.info

> On Sep 22, 2017, at 8:06, Ralph Goers  wrote:
> 
> I changed it some, yes.
> 
> Ralph
> 
>> On Sep 21, 2017, at 2:55 PM, Remko Popma  wrote:
>> 
>> I started writing the blog post for 2.9.1.
>> Quick question: no changes to the announcement text this time, is that
>> correct?
>> 
>> On Thu, Sep 21, 2017 at 1:12 PM, Ralph Goers 
>> wrote:
>> 
>>> My +1
>>> 
>>> Ralph
>>> 
>>>> On Sep 18, 2017, at 12:07 AM, Ralph Goers 
>>> wrote:
>>>> 
>>>> This is a vote to release Log4j 2.9.1, 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 welcome and we encourage everyone to test the release, but only Logging
>>> PMC votes are “officially” counted. As always, at least 3 +1 votes and more
>>> positive than negative votes are required.
>>>> 
>>>> Changes in this version include:
>>>> 
>>>> Fixed Bugs
>>>> 
>>>> • LOG4J2-1988: Prevent ConcurrentModificationException with
>>> AsyncLoggerConfig.
>>>> • LOG4J2-1914: Prevent ConcurrentModificationException with
>>> AsyncLoggerConfig.
>>>> • LOG4J2-2048: Increase default queue size for AsyncAppender from
>>> 128 to 1024.
>>>> • LOG4J2-2035: Fix documentation to clarify disruptor-3.3.4 is now
>>> required for async loggers: disruptor-3.3.3 was never released.
>>>> • LOG4J2-2030: Inspect all known ClassLoaders to locate the
>>> service provider.
>>>> • LOG4J2-2028: Java 9 StackLocator was not properly skipping the
>>> initial stack frames. Thanks to Jason Tedor.
>>>> • LOG4J2-2026: java.lang.AbstractMethodError: javax.xml.parsers.
>>> DocumentBuilderFactory.setFeature(). Thanks to Leon Finker.
>>>> • LOG4J2-2029: Marker examples should not use deprecated flow
>>> APIs. Thanks to Fabrizio Cucci.
>>>> • LOG4J2-1936: ClassNotFoundException when making all loggers
>>> asynchronous under OSGi environment. Thanks to Helber Belmiro.
>>>> 
>>>> Changes
>>>> 
>>>> • LOG4J2-2023: Use a class' canonical name instead of name to
>>> create its logger name.
>>>> • LOG4J2-2043: Update Jackson from 2.9.0 to 2.9.1 (fix for Java 9.)
>>>> • LOG4J2-2044: Update Apache Commons CSV from 1.4 to 1.5.
>>>> • LOG4J2-2045: Update javax.mail from 1.5.6 to 1.6.0.
>>>> • LOG4J2-2046: Update Apache Commons Compress from 1.13 to 1.14.
>>>> • LOG4J2-2047: Update Cassandra driver from 3.1.0 to 3.1.4.
>>>> • LOG4J2-2049: Update Apache Kafka Client from 0.11.0.0 to
>>> 0.11.0.1.
>>>> 
>>>> Tag:
>>>> a)  for a new copy do "git clone https://git-wip-us.apache.org/
>>> repos/asf/logging-log4j2.git" and then "git checkout tags/log4j-2.9.1-rc1”
>>>> b) for an existing working copy to “git pull” and then “git checkout
>>> tags/log4j-2.9.1-rc1”
>>>> 
>>>> Web Site:  http://rgoers.github.io/log4j2-site/index.html
>>>> 
>>>> Maven Artifacts: https://repository.apache.org/content/repositories/
>>> orgapachelogging-1030
>>>> 
>>>> Distribution archives: https://dist.apache.org/repos/
>>> dist/dev/logging/log4j/
>>>> 
>>>> You may download all the Maven artifacts by executing:
>>>> wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
>>> https://repository.apache.org/content/repositories/
>>> orgapachelogging-1030/org/apache/logging/log4j/
>>>> 
>>>> Ralph
>>>> 
>>> 
>>> 
>>> 
> 
> 

Re: [ANNOUNCE] Apache Log4j 2.9.1 released

[Remko Popma]

Blogged:

https://blogs.apache.org/logging/entry/log4j-2-9-1-released

(Shameless plug) Every java main() method deserves http://picocli.info

> On Sep 22, 2017, at 9:32, Ralph Goers  wrote:
> 
> As of Log4j 2.9.0, the Log4j API was modified to use java.util.ServiceLoader 
> to locate Log4j implementations

Re: log4j-to-slf4j

[Remko Popma]

That's certainly possible. 
The trade off is that we'd need to track the SLF4J binding mechanism and update 
our implementation when this binding mechanism changes. 

What problem are we trying to solve?

Remko 

> On Sep 25, 2017, at 7:16, Ralph Goers  wrote:
> 
> In looking at the implementations of log4j-slf4j-impl and log4j-to-slf4j is 
> strikes me that log4j-to-slf4j is binding to the SLF4J API while 
> log4j-slf4j-impl is binding the SFL4J API to the log4j implementation using 
> SLF4J’s binding mechanism. So it seems to me that instead of having 
> log4j-to-slf4j call the SLF4J API we ought to be able to have it call the 
> SLF4J bindings and completely bypass SLF4J itself. Some user’s might find 
> this more palatable as it would remove one layer between the Log4j API and 
> whatever logging implementation the user chose.
> 
> Thoughts?
> 
> Ralph

Re: log4j-to-slf4j

[Remko Popma]

Ok I see now. 
It would certainly be good to have more ammunition to argue for using the 
Log4j2 API directly. 

Comments on StackOverflow
https://stackoverflow.com/a/41500347/1446916 show some people perceive the 
log4j-to-slf4j module as a facade for a facade. 

If we bind directly, perhaps I should update this diagram to have a direct 
arrow from log4j-to-slf4j to SLF4J implementation?


Remko 

(Shameless plug) Every java main() method deserves http://picocli.info

> On Sep 25, 2017, at 8:57, Ralph Goers  wrote:
> 
> Well, SLF4J recently changed the binding mechanism with 1.8 in order to 
> comply with Java 9. It isn’t likely to do it again any time soon. 
> 
> What we would “solve” is that now it is log4j-api -> log4j-to-slf4j -> 
> slf4j-api -> logging implementation.  With this change it would be log4j-api 
> -> log4j-slf4j-binding -> logging implementation.  I see 2 advantages to this:
> 1. It would be harder to say that the log4j-api isn’t appropriate to be the 
> logging API since the binding to SLF4J implementations would be very light. 
> 2. The code path to get to an SLF4J implementation would be shorter.
> 
> To be honest, item 1 is the one I find more appealing. It reminds me of how 
> OS/2’s support for Windows was not what people really wanted vs the way 
> Windows NT handled it.
> 
> Ralph
> 
>> Begin forwarded message:
>> 
>> From: Remko Popma 
>> Subject: Re: log4j-to-slf4j
>> Date: September 24, 2017 at 4:27:59 PM MST
>> To: dev@logging.apache.org
>> Reply-To: dev@logging.apache.org
>> 
>> That's certainly possible. 
>> The trade off is that we'd need to track the SLF4J binding mechanism and 
>> update our implementation when this binding mechanism changes. 
>> 
>> What problem are we trying to solve?
>> 
>> Remko 
>> 
>>> On Sep 25, 2017, at 7:16, Ralph Goers  wrote:
>>> 
>>> In looking at the implementations of log4j-slf4j-impl and log4j-to-slf4j is 
>>> strikes me that log4j-to-slf4j is binding to the SLF4J API while 
>>> log4j-slf4j-impl is binding the SFL4J API to the log4j implementation using 
>>> SLF4J’s binding mechanism. So it seems to me that instead of having 
>>> log4j-to-slf4j call the SLF4J API we ought to be able to have it call the 
>>> SLF4J bindings and completely bypass SLF4J itself. Some user’s might find 
>>> this more palatable as it would remove one layer between the Log4j API and 
>>> whatever logging implementation the user chose.
>>> 
>>> Thoughts?
>>> 
>>> Ralph
>> 
> 

Re: log4j-to-slf4j

[Remko Popma]

Understood about the log4j-to-slf4j diagram. 

About updating the performance page, I haven't been able to spend much time on 
Log4j2 recently. When I did have time it has gone mostly into bug fixes. 

If you have done this before you probably know this, but doing these 
performance investigations easily take weeks of work. Every time I do this I 
have multiple cycles of test design, set up, execution, gathering results, 
analyzing the results, discovering a problem and starting again from scratch. 
:-) 

With that in mind I hope you understand that competitors like Logback improving 
their product is not a great motivator for me to undertake this work. 

I'm not averse to doing this work, I like it, but it should be driven by 
advances in Log4j2 in my opinion. 

The Java 9 stackwalker performance would be interesting to document though, so 
I am sure I will get around to it at some point. 

Remko 


> On Sep 25, 2017, at 14:33, Ralph Goers  wrote:
> 
> Yes, that is what we would want to do.
> 
> BTW - I mentioned it a while ago but is there any chance we can get updated 
> performance charts? The charts are for Log4j 2.6 vs Logback 1.1.7.  Logback 
> is now at 1.1.11 and 1.2.3. I am not really clear on what is different 
> between 1.1.x and 1.2.x.
> 
> Ralph
> 
>> On Sep 24, 2017, at 9:50 PM, Remko Popma  wrote:
>> 
>> Ok I see now. 
>> It would certainly be good to have more ammunition to argue for using the 
>> Log4j2 API directly. 
>> 
>> Comments on StackOverflow
>> https://stackoverflow.com/a/41500347/1446916 
>> <https://stackoverflow.com/a/41500347/1446916> show some people perceive the 
>> log4j-to-slf4j module as a facade for a facade. 
>> 
>> If we bind directly, perhaps I should update this diagram to have a direct 
>> arrow from log4j-to-slf4j to SLF4J implementation?
>> 
>> 
>> Remko 
>> 
>> (Shameless plug) Every java main() method deserves http://picocli.info 
>> <http://picocli.info/>
>> 
>>> On Sep 25, 2017, at 8:57, Ralph Goers >> <mailto:ralph.go...@dslextreme.com>> wrote:
>>> 
>>> Well, SLF4J recently changed the binding mechanism with 1.8 in order to 
>>> comply with Java 9. It isn’t likely to do it again any time soon. 
>>> 
>>> What we would “solve” is that now it is log4j-api -> log4j-to-slf4j -> 
>>> slf4j-api -> logging implementation.  With this change it would be 
>>> log4j-api -> log4j-slf4j-binding -> logging implementation.  I see 2 
>>> advantages to this:
>>> 1. It would be harder to say that the log4j-api isn’t appropriate to be the 
>>> logging API since the binding to SLF4J implementations would be very light. 
>>> 2. The code path to get to an SLF4J implementation would be shorter.
>>> 
>>> To be honest, item 1 is the one I find more appealing. It reminds me of how 
>>> OS/2’s support for Windows was not what people really wanted vs the way 
>>> Windows NT handled it.
>>> 
>>> Ralph
>>> 
>>>> Begin forwarded message:
>>>> 
>>>> From: Remko Popma mailto:remko.po...@gmail.com>>
>>>> Subject: Re: log4j-to-slf4j
>>>> Date: September 24, 2017 at 4:27:59 PM MST
>>>> To: dev@logging.apache.org <mailto:dev@logging.apache.org>
>>>> Reply-To: dev@logging.apache.org <mailto:dev@logging.apache.org>
>>>> 
>>>> That's certainly possible. 
>>>> The trade off is that we'd need to track the SLF4J binding mechanism and 
>>>> update our implementation when this binding mechanism changes. 
>>>> 
>>>> What problem are we trying to solve?
>>>> 
>>>> Remko 
>>>> 
>>>>> On Sep 25, 2017, at 7:16, Ralph Goers >>>> <mailto:ralph.go...@dslextreme.com>> wrote:
>>>>> 
>>>>> In looking at the implementations of log4j-slf4j-impl and log4j-to-slf4j 
>>>>> is strikes me that log4j-to-slf4j is binding to the SLF4J API while 
>>>>> log4j-slf4j-impl is binding the SFL4J API to the log4j implementation 
>>>>> using SLF4J’s binding mechanism. So it seems to me that instead of having 
>>>>> log4j-to-slf4j call the SLF4J API we ought to be able to have it call the 
>>>>> SLF4J bindings and completely bypass SLF4J itself. Some user’s might find 
>>>>> this more palatable as it would remove one layer between the Log4j API 
>>>>> and whatever logging implementation the user chose.
>>>>> 
>>>>> Thoughts?
>>>>> 
>>>>> Ralph
>>>> 
>>> 
> 

Re: logging-log4j2 git commit: LOG4J2-2054 Provide ways to configure SSL that avoid plain-text passwords in the log4j configuration. The configuration may now specify a system environment variable tha

[Remko Popma]

Thanks for reviewing. 
Good catch, a null check is needed to prevent NPEs. 
But null passwords are possible so perhaps make it like this:

return password == null ? null : password.toCharArray();


> On Sep 26, 2017, at 1:08, Gary Gregory  wrote:
> 
>> On Mon, Sep 25, 2017 at 10:00 AM,  wrote:
>> 
>> Repository: logging-log4j2
>> Updated Branches:
>>  refs/heads/master a73fce2e7 -> 08077cba3
>> 
>> 
>> LOG4J2-2054 Provide ways to configure SSL that avoid plain-text passwords
>> in the log4j configuration. The configuration may now specify a system
>> environment variable that holds the password, or the path to a file that
>> holds the password.
>> 
>> 
>> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/
>> commit/08077cba
>> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/08077cba
>> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/08077cba
>> 
>> Branch: refs/heads/master
>> Commit: 08077cba385ee376aa44ae33c66833421e9d19bc
>> Parents: a73fce2
>> Author: rpopma 
>> Authored: Tue Sep 26 01:00:15 2017 +0900
>> Committer: rpopma 
>> Committed: Tue Sep 26 01:00:15 2017 +0900
>> 
>> --
>> .../net/ssl/EnvironmentPasswordProvider.java|  54 ++
>> .../core/net/ssl/FilePasswordProvider.java  |  83 +
>> .../core/net/ssl/KeyStoreConfiguration.java |  58 +--
>> .../core/net/ssl/MemoryPasswordProvider.java|  20 ++-
>> .../core/net/ssl/TrustStoreConfiguration.java   |  57 --
>> .../log4j/core/appender/HttpAppenderTest.java   |   6 +-
>> .../SecureSocketAppenderSocketOptionsTest.java  |   8 +-
>> .../core/appender/TlsSyslogAppenderTest.java|   4 +-
>> .../ssl/EnvironmentPasswordProviderTest.java|  38 
>> .../core/net/ssl/FilePasswordProviderTest.java  |  50 ++
>> .../core/net/ssl/KeyStoreConfigurationTest.java |   8 +-
>> .../net/ssl/MemoryPasswordProviderTest.java |  49 ++
>> .../core/net/ssl/SslConfigurationTest.java  |  16 +-
>> .../log4j/core/net/ssl/TestConstants.java   |  10 +-
>> .../net/ssl/TrustStoreConfigurationTest.java |   8 +-
>> src/changes/changes.xml |   3 +
>> src/site/site.xml   |   1 +
>> src/site/xdoc/manual/appenders.xml  | 172 +--
>> 18 files changed, 580 insertions(+), 65 deletions(-)
>> --
>> 
>> 
>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/
>> 08077cba/log4j-core/src/main/java/org/apache/logging/log4j/core/net/ssl/
>> EnvironmentPasswordProvider.java
>> --
>> diff --git a/log4j-core/src/main/java/org/apache/logging/log4j/core/
>> net/ssl/EnvironmentPasswordProvider.java b/log4j-core/src/main/java/
>> org/apache/logging/log4j/core/net/ssl/EnvironmentPasswordProvider.java
>> new file mode 100644
>> index 000..e501c15
>> --- /dev/null
>> +++ b/log4j-core/src/main/java/org/apache/logging/log4j/core/net/ssl/
>> EnvironmentPasswordProvider.java
>> @@ -0,0 +1,54 @@
>> +/*
>> + * Licensed to the Apache Software Foundation (ASF) under one or more
>> + * contributor license agreements. See the NOTICE file distributed with
>> + * this work for additional information regarding copyright ownership.
>> + * The ASF licenses this file to You under the Apache license, Version 2.0
>> + * (the "License"); you may not use this file except in compliance with
>> + * the License. You may obtain a copy of the License at
>> + *
>> + *  http://www.apache.org/licenses/LICENSE-2.0
>> + *
>> + * Unless required by applicable law or agreed to in writing, software
>> + * distributed under the License is distributed on an "AS IS" BASIS,
>> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
>> implied.
>> + * See the license for the specific language governing permissions and
>> + * limitations under the license.
>> + */
>> +package org.apache.logging.log4j.core.net.ssl;
>> +
>> +import java.util.Objects;
>> +
>> +/**
>> + * PasswordProvider implementation that obtains the password value from a
>> system environment variable.
>> + * 
>> + * This implementation is not very secure because the Java interface to
>> obtain system environment variable values
>> + * requires us to use String objects. String objects are immutable and
>> Java does not provide a way to erase this
>> + * sensitive data from the application memory. The password data will
>> stay resident in memory until the String object
>> + * and its associated char[] array object are garbage collected and the
>> memory is overwritten by another object.
>> + * 
>> + * This is slightly more secure than {@link MemoryPasswordProvider}
>> because the actual password string is not pulled
>> + * into memory until it is needed (so the password string does not need
>> to be pas

Re: log4j-to-slf4j

[Remko Popma]

Sounds to me that Ralph's analysis shows that doing the binding ourselves may 
not be worth doing since we can't get an advantage by either improving people's 
perception nor improve performance. Unless I'm missing something. 



> On Sep 26, 2017, at 16:34, Mikael Ståldal  wrote:
> 
> I don't think we should support binding to Logback specifically. We should 
> support binding to any SLF4J implementation (including Logback). We should 
> probably test this with Logback though, since it's one of the most popular 
> SLF4J implementations.
> 
> 
>> On 2017-09-26 03:58, Matt Sicker wrote:
>> Would it be possible to make a log4j-api provider that binds directly to
>> logback instead?

Re: Logging list for emails generated by tools

[Remko Popma]

I think that's a good idea. (I really wish we could have fewer duplicate emails 
though.)

Remko


> On Oct 13, 2017, at 6:59, Dominik Psenner  wrote:
> 
> Stuff that requires human intervention should stay prominent. The rest can
> go away. :-)
> 
> 2017-10-12 23:06 GMT+02:00 Ralph Goers :
> 
>> It will also make the quarterly board reports more accurate.
>> reporter.apache.org provides the number of emails received on the list
>> during the quarter. In my view, having the GitHub, Jira, Jenkins, etc
>> emails on the dev list skews things as they dominate they number of “real”
>> discussion emails that happen on the list, which is what I think is the
>> important part of what the board wants to know.
>> 
>> Ralph
>> 
>>> On Oct 12, 2017, at 1:58 PM, Matt Sicker  wrote:
>>> 
>>> If it makes email filter rules easier to configure, I'd say go for it.
>> It'd
>>> be just like the commits@ list though with floods of emails coming in
>> every
>>> so often that I just have to skip over (e.g., rebasing a long lived
>> branch).
>>> 
>>> On 12 October 2017 at 15:45, Gary Gregory 
>> wrote:
>>> 
 I do not care either way.
 
 Gary
 
 On Thu, Oct 12, 2017 at 2:34 PM, Ralph Goers <
>> ralph.go...@dslextreme.com>
 wrote:
 
> What do others think about the idea of creating a separate mailing list
> for emails generated by tools? This list gets a bit noisy from all the
> extra emails and I have a hard time filtering this list because of how
 some
> of the emails are generated.
> 
> I would also say that we expect every committer to be subscribed to
>> that
> list.
> 
> Ralph
> 
 
>>> 
>>> 
>>> 
>>> --
>>> Matt Sicker 
>> 
>> 
>> 
> 
> 
> -- 
> Dominik Psenner

Re: [Log4j] skipJansi by default

[Remko Popma]

We don't have much choice I think. 

As Ralph pointed out, we have to change the default value as it can cause 
application startup to fail...



> On Oct 13, 2017, at 4:25, Gary Gregory  wrote:
> 
> My preference is to leave it as. The 2nd option is to add jansi=true|false
> to the ConsoleAppender.
> 
> Gary
> 
>> On Oct 12, 2017 13:17, "Mikael Ståldal"  wrote:
>> 
>> Do we want to do this?
>> 
>> https://github.com/apache/logging-log4j2/pull/29
>> 
>> (I rather not do this, since I do not use Windows.)
>> 

Re: Java Modules

[Remko Popma]

You mean we may want to do something like this in the future?

module org.apache.logging.log4j {
exports org.apache.logging.log4j;
exports org.apache.logging.log4j.message;
exports org.apache.logging.log4j.simple;
exports org.apache.logging.log4j.spi;
exports org.apache.logging.log4j.status;
exports org.apache.logging.log4j.util to
org.apache.logging.log4j.impl; // only impl can see util
uses org.apache.logging.log4j.spi.Provider;
}

The util package in log4j-api is actually a mixture of "consider private"
implementation classes and interfaces that are actually public API.
So some refactoring will be needed as you say.

Question: does it matter what the log4j-core module name is for the above?
Either impl or core would work, no?
If more modules need access, we can expand the list:

exports org.apache.logging.log4j.util to
org.apache.logging.log4j.core, some.external.impl, yet.another.impl;


I notice that the JDK module docs I've seen so far don't suggest the use of
an identical module name to prevent multiple implementations for a service
on the module path. The emphasis is more on detecting dependencies and
encapsulation, rather than preventing misconfiguration.

I wonder if there are other projects that use identical module names to
prevent misconfiguration. Is this a "best practice"?

Remko


On Sun, Oct 15, 2017 at 4:05 PM, Ralph Goers 
wrote:

> FWIW, I am still torn on whether log4j-core should have a module name of
> org.apache.logging.log4j.core or org.apache.logging.log4j.impl. If it is
> the second then log4j-api could restrict exporting packages only meant for
> the implementation to that module. That would require some refactoring of
> the API classes but that shouldn’t be too big of a deal. Is the benefit of
> doing that greater than the (hypothetical) benefit of supporting multiple
> log4j implementations at the same time?  Should log4j-to-slf4j also then
> use the same module name since it replaces log4j-core?
>
> Ralph
>
> > On Oct 14, 2017, at 10:40 PM, Ralph Goers 
> wrote:
> >
> > I have committed the code for LOG4J2-2056. Log4j-api is a “real” module
> and has a module-info.java while all the rest that can be modularized are
> automatic modules.  Please review and test.
> >
> > In order to create the module-info.java I had to do a few strange things:
> > Module-info.java is in the log4j-api-java9 project since log4j-api isn’t
> compiled with Java 9.
> > Compiling module-info.java requires that the packages being exported
> exist and have at least one class in them, so I had to create the
> directories and place a dummy java class in them.
> > The assembly that creates the log4j-api-java9 zip ignores all the dummy
> files and directories and only copies module-info.java and the two utility
> classes into the zip.
> >
> > I have tested this with a simple program that only uses a module path
> but I would appreciate more extensive tests before it is released.
> >
> > Ralph
>
>
>

Re: [1/2] logging-log4j2 git commit: Revert "LOG4J2-2060 AbstractDatabaseManager should make a copy of LogEvents before holding references to them: AsyncLogger log events are mutable"

[Remko Popma]

My bad.

On Wed, Oct 18, 2017 at 12:22 AM,  wrote:

> Repository: logging-log4j2
> Updated Branches:
>   refs/heads/master ff5e664cd -> 247c91d01
>
>
> Revert "LOG4J2-2060 AbstractDatabaseManager should make a copy of
> LogEvents before holding references to them: AsyncLogger log events are
> mutable"
>
> This reverts commit 334667c7acc2955e157572bfa3b8d0272a8f1495.
>
>
> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/
> commit/ecc2d35a
> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/ecc2d35a
> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/ecc2d35a
>
> Branch: refs/heads/master
> Commit: ecc2d35a4d3a90327d8a490edbd00ec8bfaeaea3
> Parents: ff5e664
> Author: Gary Gregory 
> Authored: Tue Oct 17 08:43:25 2017 -0600
> Committer: Gary Gregory 
> Committed: Tue Oct 17 08:43:25 2017 -0600
>
> --
>  .../logging/log4j/core/appender/db/AbstractDatabaseManager.java   | 2 +-
>  src/changes/changes.xml   | 3 ---
>  2 files changed, 1 insertion(+), 4 deletions(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/
> ecc2d35a/log4j-core/src/main/java/org/apache/logging/log4j/
> core/appender/db/AbstractDatabaseManager.java
> --
> diff --git a/log4j-core/src/main/java/org/apache/logging/log4j/core/
> appender/db/AbstractDatabaseManager.java b/log4j-core/src/main/java/
> org/apache/logging/log4j/core/appender/db/AbstractDatabaseManager.java
> index b8b9899..c36c4d8 100644
> --- a/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/db/
> AbstractDatabaseManager.java
> +++ b/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/db/
> AbstractDatabaseManager.java
> @@ -162,7 +162,7 @@ public abstract class AbstractDatabaseManager extends
> AbstractManager implements
>   */
>  public final synchronized void write(final LogEvent event) {
>  if (this.bufferSize > 0) {
> -this.buffer.add(event.toImmutable());
> +this.buffer.add(event);
>  if (this.buffer.size() >= this.bufferSize ||
> event.isEndOfBatch()) {
>  this.flush();
>  }
>
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/
> ecc2d35a/src/changes/changes.xml
> --
> diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> index 73d42ea..6dcb09e 100644
> --- a/src/changes/changes.xml
> +++ b/src/changes/changes.xml
> @@ -59,9 +59,6 @@
>
>  Disable thread name caching by default when running on Java 8u102
> or later.
>
> -  
> -AbstractDatabaseManager should make a copy of LogEvents before
> holding references to them: AsyncLogger log events are mutable.
> -  
>
>  If Log4j is used as the Tomcat logging implementation startup
> might fail if an application also uses Log4j.
>
>
>

Re: Revisiting the binary logging format idea

[Remko Popma]

I agree with Gary: this is just another Layout. Should not need another
repo...
Prototyping on another branch makes sense.

On Fri, Oct 20, 2017 at 1:23 AM, Gary Gregory 
wrote:

> Bleh, ANOTHER repo? We have so many already... but I see what the big
> picture is. Would this add a new layout in Core? Maybe we should just start
> with that... then grow...
>
> Gary
>
> On Thu, Oct 19, 2017 at 9:57 AM, Matt Sicker  wrote:
>
> > I mean in the logging services project. So it'd be a new repo.
> >
> > On 19 October 2017 at 10:48, Ralph Goers 
> > wrote:
> >
> > > When you say “another component in the project” do you mean logging
> > > services project or log4j? I’d prefer to see you do this in a separate
> > repo
> > > or at least a branch until we understand what it looks like. If it is
> > going
> > > to apply to many things it probably makes sense to be a separate repo.
> > >
> > > Ralph
> > >
> > > > On Oct 19, 2017, at 8:26 AM, Matt Sicker  wrote:
> > > >
> > > > For generic structured records, I'd probably go with Avro or Thrift
> > since
> > > > LogEvents have a lot of standard fields with only a few optional
> > map-like
> > > > structures. For optimized log appending, the binary format was
> proposed
> > > as
> > > > a way to append quickly and without garbage IIRC.
> > > >
> > > > On 19 October 2017 at 10:21, Gary Gregory 
> > > wrote:
> > > >
> > > >> What about BSON?
> > > >>
> > > >> Gary
> > > >>
> > > >> On Oct 19, 2017 08:41, "Matt Sicker"  wrote:
> > > >>
> > > >>> I don't have the ticket on hand, but a few months ago, Remko
> > suggested
> > > a
> > > >>> binary logging format that would allow for super fast appends of
> > > >>> log-specific information along with companion files for additional
> > > >> metadata
> > > >>> not commonly used in log messages. I've been thinking about this
> > idea a
> > > >> bit
> > > >>> in relation to existing structured layouts (both textual and
> binary),
> > > >> and I
> > > >>> was thinking that it might be a useful format to standardize on for
> > all
> > > >> the
> > > >>> logging projects.
> > > >>>
> > > >>> What I'd like to propose is making another component in the project
> > > that
> > > >>> would contain a reference implementation of encoding and decoding
> the
> > > >>> format in Java, C++, .NET, and PHP (or as a C binding for PHP).
> > > >>> Potentially, this format could be inclusive with other logging
> > projects
> > > >>> like Logstash, Logback, Splunk, etc.
> > > >>>
> > > >>> What do you all think? Is this a good idea? Or would this be
> > > duplicating
> > > >>> effort from other standards already?
> > > >>>
> > > >>> --
> > > >>> Matt Sicker 
> > > >>>
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Matt Sicker 
> > >
> > >
> > >
> >
> >
> > --
> > Matt Sicker 
> >
>

Re: Test failures in log4j-taglib

[Remko Popma]

The error went away on my machine and the Jenkins build started passing after 
reverting back to  3.2.18.RELEASE



> On Oct 24, 2017, at 4:51, Ralph Goers  wrote:
> 
> OK. So I am guessing that the errors are happening on a unit test that uses 
> Spring’s mock classes and those were upgraded in 4.x to support Servlet 3.0.
> 
> Ralph
> 
>> On Oct 23, 2017, at 11:46 AM, Mikael Ståldal  wrote:
>> 
>> It happened when Spring Framework was upgraded to 4.x.
>> 
>> 
>>> On 2017-10-23 20:14, Ralph Goers wrote:
>>> So does this mean that log4j-taglib no longer supports servlet 2.5?  How 
>>> did this happen with no changes?
>>> Ralph
 On Oct 23, 2017, at 8:21 AM, Gary Gregory  wrote:
 
 On Thu, Oct 19, 2017 at 2:14 PM, Ralph Goers >>> >
 wrote:
 
> I am wondering why this is suddenly failing. Was it changed recently?
> 
> Ralph
> 
>> On Oct 19, 2017, at 1:00 PM, Mikael Ståldal  wrote:
>> 
>> The missing class, javax.servlet.SessionCookieConfig is new in Servlet
> API 3.x. In log4j-taglib pom, we have this dependency:
>> 
>>
>>  javax.servlet
>>  servlet-api
>>  2.5
>>  provided
>>
>> 
>> That's causing the issue, when I changed it to 3.0.1 the test pass. Is
> there any particular reason for keeping this at version 2.5?
> 
 
 I updated to 3.0.1 with [LOG4J2-2089][TagLib] Update servlet-api provided
 dependency from 2.5 to 3.0.1.
 
 Gary
 
> 
>> 
>>> On 2017-10-19 21:27, Ralph Goers wrote:
>>> I’m not sure why that would be. AFAIK that hasn’t been modified in a
> long time.
>>> Ralph
 On Oct 19, 2017, at 12:15 PM, Mikael Ståldal  wrote:
 
 I get a bunch of these errors in log4j-taglib when trying to build
> current master branch locally:
 
 [ERROR] Errors:
 [ERROR]   CatchingTagTest.setUp:48 » NoClassDefFound javax/servlet/
> SessionCookieConfig
 [ERROR]   CatchingTagTest.setUp:48 » NoClassDefFound javax/servlet/
> SessionCookieConfig
 [ERROR]   CatchingTagTest.setUp:48 » NoClassDefFound javax/servlet/
> SessionCookieConfig
 [ERROR]   DumpTagTest.setUp:51 » NoClassDefFound javax/servlet/
> SessionCookieConfig
 [ERROR]   DumpTagTest.setUp:51 » NoClassDefFound javax/servlet/
> SessionCookieConfig
>> 
>> 
> 
> 

Re: logging-log4j2 git commit: LOG4J2-2087 Jansi now needs to be enabled explicitly (by setting system property `log4j.skipJansi` to `false`). To avoid causing problems for web applications, Log4j wil

[Remko Popma]

You mean let’s replace all occurrences of `log4j.skipJansi` with 
`log4j2.skipJansi`, in both code and documentation?



> On Oct 24, 2017, at 14:03, Matt Sicker  wrote:
> 
> Can you use the new system property naming scheme? This would be
> log4j2.skipJansi. That property would work regardless with the new system
> properties parser thing, though the documentation should be more consistent
> now.
> 
>> On 23 October 2017 at 22:14,  wrote:
>> 
>> Repository: logging-log4j2
>> Updated Branches:
>>  refs/heads/master 00823bd95 -> 73efe3dcf
>> 
>> 
>> LOG4J2-2087 Jansi now needs to be enabled explicitly (by setting system
>> property `log4j.skipJansi` to `false`). To avoid causing problems for web
>> applications, Log4j will no longer automatically try to load Jansi without
>> explicit configuration.
>> 
>> 
>> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/
>> commit/73efe3dc
>> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/73efe3dc
>> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/73efe3dc
>> 
>> Branch: refs/heads/master
>> Commit: 73efe3dcf6787e66177a6485271362c5f989e014
>> Parents: 00823bd
>> Author: rpopma 
>> Authored: Tue Oct 24 12:13:56 2017 +0900
>> Committer: rpopma 
>> Committed: Tue Oct 24 12:13:56 2017 +0900
>> 
>> --
>> .../log4j/core/appender/ConsoleAppender.java| 10 ++--
>> .../log4j/core/layout/PatternLayout.java| 16 +--
>> .../ConsoleAppenderAnsiMessagesMain.java|  3 +-
>> .../ConsoleAppenderAnsiStyleJira180Main.java|  3 +-
>> .../ConsoleAppenderAnsiStyleJira272Main.java|  1 +
>> .../ConsoleAppenderAnsiStyleJira319Main.java|  3 +-
>> .../ConsoleAppenderAnsiStyleLayoutMain.java |  3 +-
>> .../ConsoleAppenderAnsiStyleNameLayoutMain.java |  1 +
>> ...nsoleAppenderHighlightLayoutDefaultMain.java |  1 +
>> .../ConsoleAppenderHighlightLayoutMain.java |  1 +
>> .../ConsoleAppenderJAnsiMessageMain.java|  7 +--
>> .../ConsoleAppenderJAnsiXExceptionMain.java |  7 +--
>> .../ConsoleAppenderNoAnsiStyleLayoutMain.java   |  2 +-
>> .../log4j/core/pattern/StyleConverterTest.java  |  6 +++
>> src/changes/changes.xml |  3 ++
>> src/site/xdoc/manual/layouts.xml.vm | 48 
>> 16 files changed, 76 insertions(+), 39 deletions(-)
>> --
>> 
>> 
>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/
>> 73efe3dc/log4j-core/src/main/java/org/apache/logging/log4j/
>> core/appender/ConsoleAppender.java
>> --
>> diff --git 
>> a/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/ConsoleAppender.java
>> b/log4j-core/src/main/java/org/apache/logging/log4j/core/
>> appender/ConsoleAppender.java
>> index bd2dc16..90d16e6 100644
>> --- a/log4j-core/src/main/java/org/apache/logging/log4j/core/
>> appender/ConsoleAppender.java
>> +++ b/log4j-core/src/main/java/org/apache/logging/log4j/core/
>> appender/ConsoleAppender.java
>> @@ -67,7 +67,7 @@ public final class ConsoleAppender extends
>> AbstractOutputStreamAppender>  * Enumeration of console destinations.
>>  */
>> public enum Target {
>> -
>> +
>> /** Standard output. */
>> SYSTEM_OUT {
>> @Override
>> @@ -76,7 +76,7 @@ public final class ConsoleAppender extends
>> AbstractOutputStreamAppender> return getCharset("sun.stdout.encoding",
>> Charset.defaultCharset());
>> }
>> },
>> -
>> +
>> /** Standard error output. */
>> SYSTEM_ERR {
>> @Override
>> @@ -85,9 +85,9 @@ public final class ConsoleAppender extends
>> AbstractOutputStreamAppender> return getCharset("sun.stderr.encoding",
>> Charset.defaultCharset());
>> }
>> };
>> -
>> +
>> public abstract Charset getDefaultCharset();
>> -
>> +
>> protected Charset getCharset(final String property, Charset
>> defaultCharset) {
>> return new PropertiesUtil(PropertiesUtil.
>> getSystemProperties()).getCharsetProperty(property, defaultCharset);
>> }
>> @@ -260,7 +260,7 @@ public final class ConsoleAppender extends
>> AbstractOutputStreamAppender> throw new IllegalStateException("Unsupported default
>> encoding " + enc, ex);
>> }
>> final PropertiesUtil propsUtil = PropertiesUtil.getProperties();
>> -if (!propsUtil.isOsWindows() || 
>> propsUtil.getBooleanProperty("log4j.skipJansi")
>> || direct) {
>> +if (!propsUtil.isOsWindows() || 
>> propsUtil.getBooleanProperty("log4j.skipJansi",
>> true) || direct) {
>> return outputStream;
>> }
>> try {
>> 
>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/
>> 73efe3dc/log4j-core/src/main/

Re: logging-log4j2 git commit: LOG4J2-2087 Jansi now needs to be enabled explicitly (by setting system property `log4j.skipJansi` to `false`). To avoid causing problems for web applications, Log4j wil

[Remko Popma]

Mikael, I also don’t like the negative properties. 

Gary, we could remove the `log4j.skipJansi` system property altogether and 
instead have an explicit ConsoleAppender config attribute like `loadJansi` (or 
something). 


Note by the way that `disableAnsi` is for all ANSI escape codes and is not 
directly related to the Jansi library. 



> On Oct 25, 2017, at 4:40, Mikael Ståldal  wrote:
> 
> If we are going to rename it, I would like to invert it to 
> "log4j2.enableJansi" (default false). I think negative properties with true 
> default are confusing.
> 
> 
>> On 2017-10-24 15:04, Remko Popma wrote:
>> You mean let’s replace all occurrences of `log4j.skipJansi` with 
>> `log4j2.skipJansi`, in both code and documentation?
>>> On Oct 24, 2017, at 14:03, Matt Sicker  wrote:
>>> 
>>> Can you use the new system property naming scheme? This would be
>>> log4j2.skipJansi. That property would work regardless with the new system
>>> properties parser thing, though the documentation should be more consistent
>>> now.
>>> 
>>>> On 23 October 2017 at 22:14,  wrote:
>>>> 
>>>> Repository: logging-log4j2
>>>> Updated Branches:
>>>>  refs/heads/master 00823bd95 -> 73efe3dcf
>>>> 
>>>> 
>>>> LOG4J2-2087 Jansi now needs to be enabled explicitly (by setting system
>>>> property `log4j.skipJansi` to `false`). To avoid causing problems for web
>>>> applications, Log4j will no longer automatically try to load Jansi without
>>>> explicit configuration.
>>>> 
>>>> 
>>>> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
>>>> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/
>>>> commit/73efe3dc
>>>> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/73efe3dc
>>>> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/73efe3dc
>>>> 
>>>> Branch: refs/heads/master
>>>> Commit: 73efe3dcf6787e66177a6485271362c5f989e014
>>>> Parents: 00823bd
>>>> Author: rpopma 
>>>> Authored: Tue Oct 24 12:13:56 2017 +0900
>>>> Committer: rpopma 
>>>> Committed: Tue Oct 24 12:13:56 2017 +0900
>>>> 
>>>> --
>>>> .../log4j/core/appender/ConsoleAppender.java| 10 ++--
>>>> .../log4j/core/layout/PatternLayout.java| 16 +--
>>>> .../ConsoleAppenderAnsiMessagesMain.java|  3 +-
>>>> .../ConsoleAppenderAnsiStyleJira180Main.java|  3 +-
>>>> .../ConsoleAppenderAnsiStyleJira272Main.java|  1 +
>>>> .../ConsoleAppenderAnsiStyleJira319Main.java|  3 +-
>>>> .../ConsoleAppenderAnsiStyleLayoutMain.java |  3 +-
>>>> .../ConsoleAppenderAnsiStyleNameLayoutMain.java |  1 +
>>>> ...nsoleAppenderHighlightLayoutDefaultMain.java |  1 +
>>>> .../ConsoleAppenderHighlightLayoutMain.java |  1 +
>>>> .../ConsoleAppenderJAnsiMessageMain.java|  7 +--
>>>> .../ConsoleAppenderJAnsiXExceptionMain.java |  7 +--
>>>> .../ConsoleAppenderNoAnsiStyleLayoutMain.java   |  2 +-
>>>> .../log4j/core/pattern/StyleConverterTest.java  |  6 +++
>>>> src/changes/changes.xml |  3 ++
>>>> src/site/xdoc/manual/layouts.xml.vm | 48 
>>>> 16 files changed, 76 insertions(+), 39 deletions(-)
>>>> --
>>>> 
>>>> 
>>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/
>>>> 73efe3dc/log4j-core/src/main/java/org/apache/logging/log4j/
>>>> core/appender/ConsoleAppender.java
>>>> --
>>>> diff --git 
>>>> a/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/ConsoleAppender.java
>>>> b/log4j-core/src/main/java/org/apache/logging/log4j/core/
>>>> appender/ConsoleAppender.java
>>>> index bd2dc16..90d16e6 100644
>>>> --- a/log4j-core/src/main/java/org/apache/logging/log4j/core/
>>>> appender/ConsoleAppender.java
>>>> +++ b/log4j-core/src/main/java/org/apache/logging/log4j/core/
>>>> appender/ConsoleAppender.java
>>>> @@ -67,7 +67,7 @@ public final class ConsoleAppender extends
>>>> AbstractOutputStreamAppender>>>  * Enumeration of console destinations.
>>&

Re: logging-log4j2 git commit: LOG4J2-2087 Jansi now needs to be enabled explicitly (by setting system property `log4j.skipJansi` to `false`). To avoid causing problems for web applications, Log4j wil

[Remko Popma]

IgnoreException doesn’t fit: We’re not going to use Jansi by default, so the 
user needs a way to explicitly request Jansi somehow. 

Gary expressed a preference for configuration over system properties hence the 
idea of `loadJansi` or `enableJansi` as a ConsoleAppender attribute. But we can 
keep it a system property. 

 

> On Oct 25, 2017, at 12:22, Matt Sicker  wrote:
> 
> We have an ignoreExceptions option for when exceptions are thrown while
> appending a log event. Why not add another for ignoring exceptions thrown
> during construction of the plugin? It should ideally be filterable based on
> at least the exception supertype, but any sort of filter like that could be
> useful in power user scenarios as well.
> 
>> On 24 October 2017 at 22:07, Gary Gregory  wrote:
>> 
>> On Tue, Oct 24, 2017 at 5:47 PM, Remko Popma 
>> wrote:
>> 
>>> Mikael, I also don’t like the negative properties.
>>> 
>>> Gary, we could remove the `log4j.skipJansi` system property altogether
>> and
>>> instead have an explicit ConsoleAppender config attribute like
>> `loadJansi`
>>> (or something).
>>> 
>> 
>> This still feels weird. Are we going to end up with loadJacksonJson,
>> loadJacksonYaml, loadThis, and loadThat?
>> 
>> Would be possible to instead say something like ignoreDependencyExceptions?
>> 
>> Gary
>> 
>>> 
>>> 
>>> Note by the way that `disableAnsi` is for all ANSI escape codes and is
>> not
>>> directly related to the Jansi library.
>>> 
>>> 
>>> 
>>>> On Oct 25, 2017, at 4:40, Mikael Ståldal  wrote:
>>>> 
>>>> If we are going to rename it, I would like to invert it to
>>> "log4j2.enableJansi" (default false). I think negative properties with
>> true
>>> default are confusing.
>>>> 
>>>> 
>>>>> On 2017-10-24 15:04, Remko Popma wrote:
>>>>> You mean let’s replace all occurrences of `log4j.skipJansi` with
>>> `log4j2.skipJansi`, in both code and documentation?
>>>>>> On Oct 24, 2017, at 14:03, Matt Sicker  wrote:
>>>>>> 
>>>>>> Can you use the new system property naming scheme? This would be
>>>>>> log4j2.skipJansi. That property would work regardless with the new
>>> system
>>>>>> properties parser thing, though the documentation should be more
>>> consistent
>>>>>> now.
>>>>>> 
>>>>>>> On 23 October 2017 at 22:14,  wrote:
>>>>>>> 
>>>>>>> Repository: logging-log4j2
>>>>>>> Updated Branches:
>>>>>>> refs/heads/master 00823bd95 -> 73efe3dcf
>>>>>>> 
>>>>>>> 
>>>>>>> LOG4J2-2087 Jansi now needs to be enabled explicitly (by setting
>>> system
>>>>>>> property `log4j.skipJansi` to `false`). To avoid causing problems
>> for
>>> web
>>>>>>> applications, Log4j will no longer automatically try to load Jansi
>>> without
>>>>>>> explicit configuration.
>>>>>>> 
>>>>>>> 
>>>>>>> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
>>>>>>> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/
>>>>>>> commit/73efe3dc
>>>>>>> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/
>>> 73efe3dc
>>>>>>> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/
>>> 73efe3dc
>>>>>>> 
>>>>>>> Branch: refs/heads/master
>>>>>>> Commit: 73efe3dcf6787e66177a6485271362c5f989e014
>>>>>>> Parents: 00823bd
>>>>>>> Author: rpopma 
>>>>>>> Authored: Tue Oct 24 12:13:56 2017 +0900
>>>>>>> Committer: rpopma 
>>>>>>> Committed: Tue Oct 24 12:13:56 2017 +0900
>>>>>>> 
>>>>>>> 
>>> --
>>>>>>> .../log4j/core/appender/ConsoleAppender.java| 10 ++--
>>>>>>> .../log4j/core/layout/PatternLayout.java| 16 +--
>>>>>>> .../ConsoleAppenderAnsiMessagesMain.java|  3 +-
>>>>>>> .../ConsoleAppenderAnsiStyleJira180Main.java|  3 +-
>>>>>>> .../ConsoleAppenderAnsiStyleJ

Re: [meta] Draft blog post about logging in general

[Remko Popma]

I just finished reading it. 
Looks great Matt!
Enjoy giving the presentation!

Remko 

(Shameless plug) Every java main() method deserves http://picocli.info

> On Oct 31, 2017, at 6:26, Ole Ersoy  wrote:
> 
> That's the key - Gotta make it more fun!  Keep it fresh - Ziplock fresh!  
> Freshaliciouss!!
> 
> 
>> On 10/30/2017 04:14 PM, Matt Sicker wrote:
>> Zipkin is a fun topic I wrote a small internal blog post at my client
>> about. The general topic I'm doing a talk on is "The How and Why of
>> Logging" which is generally aimed at providing an overview of logging
>> concepts, common libraries, tools, patterns, etc. Distributed log tracing
>> is certainly a topic I was considering talking about in the talk provided
>> it doesn't go too long.
>> 
>>> On 30 October 2017 at 15:52, Ole Ersoy  wrote:
>>> 
>>> Probably a series of blog posts :).  Another thing that would be great is
>>> pumping up some of the new features that log4j2 has that developers will
>>> love.  It reads a little bit like a theoretical intro to logging in general
>>> (Although you did say clearly that that is what it is) and we have a lot of
>>> material like that, so what is it about the presentation that should make
>>> your peers want to pay attention?  I'm sure you'll find that even if the
>>> audience have heard of some of the new log4j2 features, they'll appreciate
>>> a recap.  For example here's a pretty good article on Kotlin that I
>>> recently read:
>>> 
>>> http://petersommerhoff.com/dev/kotlin/kotlin-for-java-devs/
>>> 
>>> A specific example of how to log from both a project dependency, as well
>>> as the core project code, would be great as well.  The FAQ is good, but it
>>> feels a little bit like reading your Denon Receiver's manual ...
>>> 
>>> Could be that throwing in Zipkin (http://zipkin.io/) with the rest of the
>>> reference material (Flume, etc.) would be a valued addition.
>>> 
>>> 
 On 10/30/2017 02:20 PM, Matt Sicker wrote:
 
 I could spend an entire blog post about Logstash and ELK in general, so I
 feel it's out of scope here.
 
 As for the other questions, I think that's covered by the FAQ <
 https://logging.apache.org/log4j/2.x/faq.html>, but if it's not, that
 would
 be useful here.
 
 On 30 October 2017 at 13:52, Ole Ersoy  wrote:
 
 I thought it was very good.  I'm a big fan of articles that come with and
> reference simple examples from a github repository.  One of the most
> confusing aspects of Java logging is configuring it to use one provider
> when multiple dependencies use different APIs ... SLF4J ... Log4J ... so
> if
> that were included / referenced I think it would be a plus.  In case you
> feel like expanding on the integration with Logstash that would be
> awesome
> too.  The ELK stack seems to be getting pretty popular.
> 
> Cheers,
> 
> Ole
> 
> 
> 
> 
> On 10/30/2017 01:09 PM, Matt Sicker wrote:
> 
> In preparation for an upcoming talk I'll be doing for CJUG, I'm writing a
>> blog post about introductory concepts to logging from both a developer
>> and
>> operator point of view. My current draft is available here: <
>> https://github.com/jvz/jvz.github.io/blob/logging/_posts/201
>> 7-10-30-logging.md>.
>> Let me know what you think!
>> 
>> 
>> 
>> 
> 

Re: Planning out what we can do to get Chainsaw back in the game

[Remko Popma]

I don’t know either language but I’d be more interested in learning Kotlin than 
learning Scala. 

OTOH I’m not sure how much time I’ll be able to contribute to Chainsaw so not 
sure how much that should count for. 

(Shameless plug) Every java main() method deserves http://picocli.info

> On Nov 11, 2017, at 10:16, Matt Sicker  wrote:
> 
> That's what I hear. I don't know Kotlin, but I'd certainly be interested in
> learning! (particularly so I can write Gradle builds in a statically typed
> language)
> 
>> On 10 November 2017 at 19:10, Gary Gregory  wrote:
>> 
>> I think Kotlin would be more approachable than Scala... thoughts?
>> 
>> Gary
>> 
>>> On Fri, Nov 10, 2017 at 3:26 PM, Matt Sicker  wrote:
>>> 
>>> On 10 November 2017 at 16:17, Robert Middleton 
>>> wrote:
>>> 
 What would the advantage be of using Scala vs just normal Java?
 Mostly from a curiosity standpoint; I've never done Scala so I don't
 know it works.
 
>>> 
>>> The main advantage I can see is that most of the developers interested in
>>> working on v3 all prefer to work in Scala. I could go on and on about
>> Scala
>>> over Java, but really, my comparison would all come down to functional
>>> programming over object oriented programming. When it comes to shared
>>> libraries like Log4j, I find Java far more appropriate and work in that
>>> space. In a GUI application where there is no real public API? I'd rather
>>> work in Scala. Kotlin was another option, but it seems like none of us
>>> really have experience there.
>>> 
>>> 
 Did you actually have trouble building?  I'm pretty sure that when I
 built it a few months ago I simply opened up the project in Netbeans
 and it built immediately as a maven project(although looking at the
 POM it does look like it uses ant on the backend for some reason).
 
>>> 
>>> Building the project is simple enough. I had issues with:
>>> 
>>> 1. Running mvn clean install does not work by default unless you run "mvn
>>> site:site" before running "mvn install".
>>> 2. Doesn't build in Java 9.
>>> 3. The maven-release-plugin is not configured at all, so I had to do all
>>> release steps by hand instead.
>>> 
>>> --
>>> Matt Sicker 
>>> 
>> 
> 
> 
> 
> -- 
> Matt Sicker 

Re: Planning out what we can do to get Chainsaw back in the game

[Remko Popma]

Now that I think of it, all else being equal, the combination of Kotlin and 
JavaFX may be attractive to get other new developers interested and grow the 
community...

(Shameless plug) Every java main() method deserves http://picocli.info

> On Nov 11, 2017, at 10:58, Matt Sicker  wrote:
> 
> Considering it takes about 2-3 months of daily use of Scala to get
> comfortable, perhaps Kotlin would be a better choice. It's a simpler
> language and is supposed to be easy for Java developers to pick up.
> 
>> On 10 November 2017 at 19:43, Remko Popma  wrote:
>> 
>> I don’t know either language but I’d be more interested in learning Kotlin
>> than learning Scala.
>> 
>> OTOH I’m not sure how much time I’ll be able to contribute to Chainsaw so
>> not sure how much that should count for.
>> 
>> (Shameless plug) Every java main() method deserves http://picocli.info
>> 
>>> On Nov 11, 2017, at 10:16, Matt Sicker  wrote:
>>> 
>>> That's what I hear. I don't know Kotlin, but I'd certainly be interested
>> in
>>> learning! (particularly so I can write Gradle builds in a statically
>> typed
>>> language)
>>> 
>>>> On 10 November 2017 at 19:10, Gary Gregory 
>> wrote:
>>>> 
>>>> I think Kotlin would be more approachable than Scala... thoughts?
>>>> 
>>>> Gary
>>>> 
>>>>> On Fri, Nov 10, 2017 at 3:26 PM, Matt Sicker  wrote:
>>>>> 
>>>>> On 10 November 2017 at 16:17, Robert Middleton 
>>>>> wrote:
>>>>> 
>>>>>> What would the advantage be of using Scala vs just normal Java?
>>>>>> Mostly from a curiosity standpoint; I've never done Scala so I don't
>>>>>> know it works.
>>>>>> 
>>>>> 
>>>>> The main advantage I can see is that most of the developers interested
>> in
>>>>> working on v3 all prefer to work in Scala. I could go on and on about
>>>> Scala
>>>>> over Java, but really, my comparison would all come down to functional
>>>>> programming over object oriented programming. When it comes to shared
>>>>> libraries like Log4j, I find Java far more appropriate and work in that
>>>>> space. In a GUI application where there is no real public API? I'd
>> rather
>>>>> work in Scala. Kotlin was another option, but it seems like none of us
>>>>> really have experience there.
>>>>> 
>>>>> 
>>>>>> Did you actually have trouble building?  I'm pretty sure that when I
>>>>>> built it a few months ago I simply opened up the project in Netbeans
>>>>>> and it built immediately as a maven project(although looking at the
>>>>>> POM it does look like it uses ant on the backend for some reason).
>>>>>> 
>>>>> 
>>>>> Building the project is simple enough. I had issues with:
>>>>> 
>>>>> 1. Running mvn clean install does not work by default unless you run
>> "mvn
>>>>> site:site" before running "mvn install".
>>>>> 2. Doesn't build in Java 9.
>>>>> 3. The maven-release-plugin is not configured at all, so I had to do
>> all
>>>>> release steps by hand instead.
>>>>> 
>>>>> --
>>>>> Matt Sicker 
>>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Matt Sicker 
>> 
> 
> 
> 
> -- 
> Matt Sicker 

Re: Planning out what we can do to get Chainsaw back in the game

[Remko Popma]

TornadoFX looks very interesting! Thanks for the link!

(Shameless plug) Every java main() method deserves http://picocli.info

> On Nov 11, 2017, at 13:24, Matt Sicker  wrote:
> 
> Using Kotlin could also attract Android developers who were otherwise stuck
> using Java 6 for years.
> 
> As mentioned in an earlier reply, this framework could be useful for
> Kotlin/JavaFX: <https://github.com/edvin/tornadofx>
> 
>> On 10 November 2017 at 22:12, Remko Popma  wrote:
>> 
>> Now that I think of it, all else being equal, the combination of Kotlin
>> and JavaFX may be attractive to get other new developers interested and
>> grow the community...
>> 
>> (Shameless plug) Every java main() method deserves http://picocli.info
>> 
>>> On Nov 11, 2017, at 10:58, Matt Sicker  wrote:
>>> 
>>> Considering it takes about 2-3 months of daily use of Scala to get
>>> comfortable, perhaps Kotlin would be a better choice. It's a simpler
>>> language and is supposed to be easy for Java developers to pick up.
>>> 
>>>> On 10 November 2017 at 19:43, Remko Popma 
>> wrote:
>>>> 
>>>> I don’t know either language but I’d be more interested in learning
>> Kotlin
>>>> than learning Scala.
>>>> 
>>>> OTOH I’m not sure how much time I’ll be able to contribute to Chainsaw
>> so
>>>> not sure how much that should count for.
>>>> 
>>>> (Shameless plug) Every java main() method deserves http://picocli.info
>>>> 
>>>>> On Nov 11, 2017, at 10:16, Matt Sicker  wrote:
>>>>> 
>>>>> That's what I hear. I don't know Kotlin, but I'd certainly be
>> interested
>>>> in
>>>>> learning! (particularly so I can write Gradle builds in a statically
>>>> typed
>>>>> language)
>>>>> 
>>>>>> On 10 November 2017 at 19:10, Gary Gregory 
>>>> wrote:
>>>>>> 
>>>>>> I think Kotlin would be more approachable than Scala... thoughts?
>>>>>> 
>>>>>> Gary
>>>>>> 
>>>>>>> On Fri, Nov 10, 2017 at 3:26 PM, Matt Sicker 
>> wrote:
>>>>>>> 
>>>>>>> On 10 November 2017 at 16:17, Robert Middleton 
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> What would the advantage be of using Scala vs just normal Java?
>>>>>>>> Mostly from a curiosity standpoint; I've never done Scala so I don't
>>>>>>>> know it works.
>>>>>>>> 
>>>>>>> 
>>>>>>> The main advantage I can see is that most of the developers
>> interested
>>>> in
>>>>>>> working on v3 all prefer to work in Scala. I could go on and on about
>>>>>> Scala
>>>>>>> over Java, but really, my comparison would all come down to
>> functional
>>>>>>> programming over object oriented programming. When it comes to shared
>>>>>>> libraries like Log4j, I find Java far more appropriate and work in
>> that
>>>>>>> space. In a GUI application where there is no real public API? I'd
>>>> rather
>>>>>>> work in Scala. Kotlin was another option, but it seems like none of
>> us
>>>>>>> really have experience there.
>>>>>>> 
>>>>>>> 
>>>>>>>> Did you actually have trouble building?  I'm pretty sure that when I
>>>>>>>> built it a few months ago I simply opened up the project in Netbeans
>>>>>>>> and it built immediately as a maven project(although looking at the
>>>>>>>> POM it does look like it uses ant on the backend for some reason).
>>>>>>>> 
>>>>>>> 
>>>>>>> Building the project is simple enough. I had issues with:
>>>>>>> 
>>>>>>> 1. Running mvn clean install does not work by default unless you run
>>>> "mvn
>>>>>>> site:site" before running "mvn install".
>>>>>>> 2. Doesn't build in Java 9.
>>>>>>> 3. The maven-release-plugin is not configured at all, so I had to do
>>>> all
>>>>>>> release steps by hand instead.
>>>>>>> 
>>>>>>> --
>>>>>>> Matt Sicker 
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Matt Sicker 
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Matt Sicker 
>> 
> 
> 
> 
> -- 
> Matt Sicker 

Re: logging-log4j2 git commit: LOG4J2-2106 Reduce locking when checking for rollover

[Remko Popma]

I’ll take a look tomorrow. 



> On Nov 10, 2017, at 22:47, Ralph Goers  wrote:
> 
> Please review this commit as I want to make sure I didn’t make any mistakes.
> 
> Ralph
> 
> 
>> On Nov 10, 2017, at 6:46 AM, rgo...@apache.org wrote:
>> 
>> Repository: logging-log4j2
>> Updated Branches:
>> refs/heads/master 0dca987fc -> aad2f132b
>> 
>> 
>> LOG4J2-2106 Reduce locking when checking for rollover
>> 
>> 
>> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/aad2f132
>> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/aad2f132
>> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/aad2f132
>> 
>> Branch: refs/heads/master
>> Commit: aad2f132b27f9e2667c2b43fb58ce59e3914edb3
>> Parents: 0dca987
>> Author: Ralph Goers 
>> Authored: Fri Nov 10 06:46:11 2017 -0700
>> Committer: Ralph Goers 
>> Committed: Fri Nov 10 06:46:11 2017 -0700
>> 
>> --
>> .../appender/rolling/RollingFileManager.java | 57 +---
>> .../rolling/SizeBasedTriggeringPolicy.java  |  2 +-
>> .../rolling/TimeBasedTriggeringPolicy.java  |  2 +-
>> src/changes/changes.xml |  3 ++
>> 4 files changed, 42 insertions(+), 22 deletions(-)
>> --
>> 
>> 
>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/aad2f132/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/rolling/RollingFileManager.java
>> --
>> diff --git 
>> a/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/rolling/RollingFileManager.java
>>  
>> b/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/rolling/RollingFileManager.java
>> index 6ccfe7b..ff7bf6d 100644
>> --- 
>> a/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/rolling/RollingFileManager.java
>> +++ 
>> b/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/rolling/RollingFileManager.java
>> @@ -29,6 +29,9 @@ import java.util.concurrent.Semaphore;
>> import java.util.concurrent.ThreadPoolExecutor;
>> import java.util.concurrent.TimeUnit;
>> import java.util.concurrent.atomic.AtomicReferenceFieldUpdater;
>> +import java.util.concurrent.locks.Lock;
>> +import java.util.concurrent.locks.ReadWriteLock;
>> +import java.util.concurrent.locks.ReentrantReadWriteLock;
>> 
>> import org.apache.logging.log4j.core.Layout;
>> import org.apache.logging.log4j.core.LifeCycle;
>> @@ -65,6 +68,9 @@ public class RollingFileManager extends FileManager {
>>private volatile boolean initialized = false;
>>private volatile String fileName;
>>private final FileExtension fileExtension;
>> +private final ReadWriteLock updateLock = new ReentrantReadWriteLock();
>> +private final Lock readLock = updateLock.readLock();
>> +private final Lock writeLock = updateLock.writeLock();
>> 
>>/* This executor pool will create a new Thread for every work async 
>> action to be performed. Using it allows
>>   us to make sure all the Threads are completed when the Manager is 
>> stopped. */
>> @@ -247,9 +253,14 @@ public class RollingFileManager extends FileManager {
>> * Determines if a rollover should occur.
>> * @param event The LogEvent.
>> */
>> -public synchronized void checkRollover(final LogEvent event) {
>> -if (triggeringPolicy.isTriggeringEvent(event)) {
>> -rollover();
>> +public void checkRollover(final LogEvent event) {
>> +readLock.lock();
>> +try {
>> +if (triggeringPolicy.isTriggeringEvent(event)) {
>> +rollover();
>> +}
>> +} finally {
>> +readLock.unlock();
>>}
>>}
>> 
>> @@ -333,25 +344,31 @@ public class RollingFileManager extends FileManager {
>>}
>> 
>>public void setTriggeringPolicy(final TriggeringPolicy triggeringPolicy) {
>> -triggeringPolicy.initialize(this);
>> -final TriggeringPolicy policy = this.triggeringPolicy;
>> -int count = 0;
>> -boolean policyUpdated = false;
>> -do {
>> -++count;
>> -} while (!(policyUpdated = 
>> triggeringPolicyUpdater.compareAndSet(this, this.triggeringPolicy, 
>> triggeringPolicy))
>> -&& count < MAX_TRIES);
>> -if (policyUpdated) {
>> -if (triggeringPolicy instanceof LifeCycle) {
>> -((LifeCycle) triggeringPolicy).start();
>> -}
>> -if (policy instanceof LifeCycle) {
>> -((LifeCycle) policy).stop();
>> +writeLock.lock();
>> +try {
>> +triggeringPolicy.initialize(this);
>> +final TriggeringPolicy policy = this.triggeringPolicy;
>> +int count = 0;
>> +boolean policyUpdated = false;
>> +do 

Re: Planning out what we can do to get Chainsaw back in the game

[Remko Popma]

I’ve built several Swing-based apps and know Swing fairly well. I’ve only got 
my feet wet with JavaFX. 

Both are big frameworks with a significant learning curve. 

Personally I’d use JavaFX, if only to make working on the project an 
interesting learning experience. 

> On Nov 12, 2017, at 9:13, Matt Sicker  wrote:
> 
> I'll certainly be playing around with 2.0 for a bit before I can even
> determine what needs attention first anyways. I'm not super experienced
> with either Swing or JavaFX, so if it turns out that Swing is the more
> natural API to use based on your experiences, then it'd make sense to stick
> with that.
> 
>> On 11 November 2017 at 18:09, Scott Deboy  wrote:
>> 
>> I'd love to hear what folks think of the user experience with the
>> 'latest Chainsaw' and its feature set.
>> 
>> There are a ton of features.  It will be interesting to get a sense of
>> how many of those features we get 'for free' in any of these other UI
>> toolkits.  It was a lot of heavy lifting to get Swing to do what we
>> wanted.
>> 
>> Scott
>> 
>> 
>>> On 11/11/17, Ole Ersoy  wrote:
>>> Kotlin is almost a duplicate of Typescript, so Javascript devs should be
>>> able to pickup on it fast.  There's a Typescript to Kotlin converter
>> here:
>>> 
>>> https://github.com/Kotlin/ts2kt
>>> 
>>> Typescript is also supported in Electron:
>>> 
>>> https://electron.atom.io/blog/2017/06/01/typescript
>>> 
>>> So Kotlin should be a pretty good bridge between these worlds and opens
>> up a
>>> lot of possibilities ... Suggested Kotlin to the Hipparchus group as
>> well:
>>> 
>>> https://github.com/Hipparchus-Math/hipparchus/issues/26
>>> 
>>> A chainsaw implementation in Electron would provide a better developer
>> and
>>> user experience I would think though ... as you can now use the latest
>>> Javascript frameworks (Angular / React) and all the packages that come
>> with
>>> that ecosystem (Graphing, Widgets, etc.)
>>> 
>>> https://scotch.io/tutorials/creating-desktop-applications-
>> with-angularjs-and-github-electron
>>> 
>>> 
 On 11/11/2017 04:42 PM, Matt Sicker wrote:
 I've been using Java for years, Scala for several months (all of OOP,
 hybrid, and pure FP styles in different projects), and other languages
>> in
 the past. I've certainly found Scala to be useful in the Big Data space,
 especially when using Spark, though I've also found it useful in
>> projects
 that consume Java APIs.
 
 As for Kotlin fitting well to a GUI app, based on its traction in the
 Android GUI space, I had the same thought. Plus, this may attract more
 contributors outside ASF who are interested in using Kotlin or working
>> on
 a
 GUI app instead of low level Java bits.
 
 Also, I'd imagine Kotlin is easier for a C# or JavaScript developer to
 pick
 up on than Scala, so that also helps with adoption in theory.
 
> On 11 November 2017 at 10:23, Mikael Ståldal  wrote:
> 
> I have used both Java and Scala for several years, and I have been
> trying
> out Kotlin the latest months (for Android only).
> 
> I would say it is definitely easier for a developer with primarily Java
> experience to pick up Kotlin than Scala, especially if that Java
> experience
> is predominately pre-Java8. If your primary experience is functional
> programming like Haskell, O'Caml or F#; then Scala is probably easier
>> to
> pick up.
> 
> Kotlin is gaining traction in Android, since it works well there. Scala
> is
> big in Big Data (Apache Spark etc) and to some extent in
>> server/backend.
> 
> Kotlin might be a better fit for a desktop UI Java app like Chainsaw.
> 
> 
> 
>> On 2017-11-11 02:10, Gary Gregory wrote:
>> 
>> I think Kotlin would be more approachable than Scala... thoughts?
>> 
>> Gary
>> 
>> On Fri, Nov 10, 2017 at 3:26 PM, Matt Sicker 
>> wrote:
>> 
>> On 10 November 2017 at 16:17, Robert Middleton 
>>> wrote:
>>> 
>>> What would the advantage be of using Scala vs just normal Java?
 Mostly from a curiosity standpoint; I've never done Scala so I don't
 know it works.
 
 
>>> The main advantage I can see is that most of the developers
>> interested
>>> in
>>> working on v3 all prefer to work in Scala. I could go on and on about
>>> Scala
>>> over Java, but really, my comparison would all come down to
>> functional
>>> programming over object oriented programming. When it comes to shared
>>> libraries like Log4j, I find Java far more appropriate and work in
>>> that
>>> space. In a GUI application where there is no real public API? I'd
>>> rather
>>> work in Scala. Kotlin was another option, but it seems like none of
>> us
>>> really have experience there.
>>> 
>>> 
>>> Did you actually have trouble building?  I'm pretty sure that when I
 built it a few months 

Re: logging-log4j2 git commit: LOG4J2-2106 Reduce locking when checking for rollover

[Remko Popma]

I reviewed the changes and found some potential issues.
Please see my comment on https://issues.apache.org/jira/browse/LOG4J2-2106

On Sun, Nov 12, 2017 at 6:17 AM, Daan Hoogland 
wrote:

> Thanks, I'm trying the commitish build install use.
>
> Sent from Nine <http://www.9folders.com/>
> --
> *From:* Ralph Goers 
> *Sent:* 11 Nov 2017 8:45 pm
> *To:* dev@logging.apache.org
> *Subject:* Re: logging-log4j2 git commit: LOG4J2-2106 Reduce locking when
> checking for rollover
>
> Release candidates are only available on the Apache staging repository.
> The download information will be in the email for the release candidate.
>
> Ralph
>
>
> > On Nov 11, 2017, at 10:59 AM, Daan Hoogland 
> wrote:
> >
> > As a matter of interest, can we test release candidates from maven
> central at apache or do I need to build and install locally to test?
> >
> > thanks
> >
> > On 11/11/2017, 18:32, "Ralph Goers"  wrote:
> >
> >Ok. I’m waiting on feedback on this before I start a release.
> >
> >Ralph
> >
> >
> >
> > Senior Software Developer
> > daan.hoogl...@shapeblue.com
> > www.shapeblue.com
> >
> >
> >
> >> On Nov 11, 2017, at 7:14 AM, Remko Popma  wrote:
> >>
> >> I’ll take a look tomorrow.
> >>
> >>
> >>
> >>> On Nov 10, 2017, at 22:47, Ralph Goers  wrote:
> >>>
> >>> Please review this commit as I want to make sure I didn’t make any
> mistakes.
> >>>
> >>> Ralph
> >>>
> >>>
> >>>> On Nov 10, 2017, at 6:46 AM, rgo...@apache.org wrote:
> >>>>
> >>>> Repository: logging-log4j2
> >>>> Updated Branches:
> >>>> refs/heads/master 0dca987fc -> aad2f132b
> >>>>
> >>>>
> >>>> LOG4J2-2106 Reduce locking when checking for rollover
> >>>>
> >>>>
> >>>> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
> >>>> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/
> commit/aad2f132
> >>>> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/
> aad2f132
> >>>> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/
> aad2f132
> >>>>
> >>>> Branch: refs/heads/master
> >>>> Commit: aad2f132b27f9e2667c2b43fb58ce59e3914edb3
> >>>> Parents: 0dca987
> >>>> Author: Ralph Goers 
> >>>> Authored: Fri Nov 10 06:46:11 2017 -0700
> >>>> Committer: Ralph Goers 
> >>>> Committed: Fri Nov 10 06:46:11 2017 -0700
> >>>>
> >>>> 
> --
> >>>> .../appender/rolling/RollingFileManager.java | 57
> +---
> >>>> .../rolling/SizeBasedTriggeringPolicy.java  |  2 +-
> >>>> .../rolling/TimeBasedTriggeringPolicy.java  |  2 +-
> >>>> src/changes/changes.xml |  3 ++
> >>>> 4 files changed, 42 insertions(+), 22 deletions(-)
> >>>> 
> --
> >>>>
> >>>>
> >>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/
> aad2f132/log4j-core/src/main/java/org/apache/logging/log4j/
> core/appender/rolling/RollingFileManager.java
> >>>> 
> --
> >>>> diff --git a/log4j-core/src/main/java/org/apache/logging/log4j/core/
> appender/rolling/RollingFileManager.java b/log4j-core/src/main/java/
> org/apache/logging/log4j/core/appender/rolling/RollingFileManager.java
> >>>> index 6ccfe7b..ff7bf6d 100644
> >>>> --- a/log4j-core/src/main/java/org/apache/logging/log4j/core/
> appender/rolling/RollingFileManager.java
> >>>> +++ b/log4j-core/src/main/java/org/apache/logging/log4j/core/
> appender/rolling/RollingFileManager.java
> >>>> @@ -29,6 +29,9 @@ import java.util.concurrent.Semaphore;
> >>>> import java.util.concurrent.ThreadPoolExecutor;
> >>>> import java.util.concurrent.TimeUnit;
> >>>> import java.util.concurrent.atomic.AtomicReferenceFieldUpdater;
> >>>> +import java.util.concurrent.locks.Lock;
> >>>> +import java.util.concurrent.locks.ReadWriteLock;
> >>>> +import java.util.concurrent.locks.ReentrantReadWriteLock;

Re: logging-log4j2 git commit: Add PR notice to README

[Remko Popma]

Aggreement-> Agreement
(Away from pc)

On Tue, Nov 14, 2017 at 0:50  wrote:

> Repository: logging-log4j2
> Updated Branches:
>   refs/heads/master d85f39abc -> 8b71dbbf1
>
>
> Add PR notice to README
>
>
> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
> Commit:
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/8b71dbbf
> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/8b71dbbf
> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/8b71dbbf
>
> Branch: refs/heads/master
> Commit: 8b71dbbf1038952af4ae23f82817eb875c582ab6
> Parents: d85f39a
> Author: Ralph Goers 
> Authored: Mon Nov 13 08:50:13 2017 -0700
> Committer: Ralph Goers 
> Committed: Mon Nov 13 08:50:27 2017 -0700
>
> --
>  README.md | 8 
>  1 file changed, 8 insertions(+)
> --
>
>
>
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/8b71dbbf/README.md
> --
> diff --git a/README.md b/README.md
> index 98d95cf..36c7f9d 100644
> --- a/README.md
> +++ b/README.md
> @@ -7,6 +7,14 @@ and provides many of the improvements available in
> Logback while fixing some inh
>  [![Travis Status](
> https://travis-ci.org/apache/logging-log4j2.svg?branch=master)](https://travis-ci.org/apache/logging-log4j2
> )
>  [![Maven Central](
> https://img.shields.io/maven-central/v/org.apache.logging.log4j/log4j-api.svg)](http://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-api
> )
>
> +
> +## Pull Requests on Github
> +
> +By sending a pull request you grant the Apache Software Foundation
> sufficient rights to use and release the submitted
> +work under the Apache license. You grant the same rights (copyright
> license, patent license, etc.) to the
> +Apache Software Foundation as if you have signed a Contributor License
> Aggreement. For contributions that are
> +judged to be non-trivial, you will be asked to actually signing a
> Contributor License Aggreement.
> +
>  ## Usage
>
>  Users should refer to [Maven, Ivy, Gradle, and SBT Artifacts](
> http://logging.apache.org/log4j/2.x/maven-artifacts.html)
>
>

Re: logging-log4j2 git commit: Fix typo

[Remko Popma]

Sorry, I still see one misspelled Aggreement 

(Away from pc)

> On Nov 14, 2017, at 1:02, rgo...@apache.org wrote:
> 
> Repository: logging-log4j2
> Updated Branches:
>  refs/heads/master ac82a0d78 -> 7ade3025b
> 
> 
> Fix typo
> 
> 
> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/7ade3025
> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/7ade3025
> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/7ade3025
> 
> Branch: refs/heads/master
> Commit: 7ade3025b8de4176a2149a7aec00362b2380fe61
> Parents: ac82a0d
> Author: Ralph Goers 
> Authored: Mon Nov 13 09:02:30 2017 -0700
> Committer: Ralph Goers 
> Committed: Mon Nov 13 09:02:38 2017 -0700
> 
> --
> README.md | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/7ade3025/README.md
> --
> diff --git a/README.md b/README.md
> index 36c7f9d..b35cd0e 100644
> --- a/README.md
> +++ b/README.md
> @@ -13,7 +13,7 @@ and provides many of the improvements available in Logback 
> while fixing some inh
> By sending a pull request you grant the Apache Software Foundation sufficient 
> rights to use and release the submitted 
> work under the Apache license. You grant the same rights (copyright license, 
> patent license, etc.) to the 
> Apache Software Foundation as if you have signed a Contributor License 
> Aggreement. For contributions that are 
> -judged to be non-trivial, you will be asked to actually signing a 
> Contributor License Aggreement.
> +judged to be non-trivial, you will be asked to actually signing a 
> Contributor License Agreement.
> 
> ## Usage
> 
> 

Library versions

[Remko Popma]

Gary,

Just wondering: how do you keep track of library version updates? Is there
a tool to get notified when there’s an update?

Amazing job by the way!

Remko
(Shameless plug) Every java main() method deserves http://picocli.info

Re: Log4j 2.10

[Remko Popma]

No objection, and thanks for RM-ing!

Remko



> On Nov 16, 2017, at 14:04, Gary Gregory  wrote:
> 
> Great! And thank you for RM'ing again.
> 
> Gary
> 
> On Wed, Nov 15, 2017 at 9:31 PM, Ralph Goers 
> wrote:
> 
>> Unless someone objects I plan to start the release process for Log4j 2.10
>> tomorrow. I had wanted to include a fix for LOG4J2-2106 but the problem
>> only occurs in rare situations and I am not sure how to fix it yet. There
>> are a lot of other issues that deserve looking at but nothing I can see
>> that warrants waiting on.
>> 
>> Ralph
>> 

Re: logging-log4j2 git commit: Always delete temporary file created in test

[Remko Popma]

The build now fails on windows.
I always see this error:

expected: C:\Users\remko\AppData\Local\Temp\/hadoop.log Actual:
C:\Users\remko\AppData\Local\Temp\/hadoop.log

java.nio.file.FileSystemException:
C:\Users\remko\AppData\Local\Temp\hadoop.log: The process cannot access the
file because it is being used by another process.


at
sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
at
sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
at
sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
at
sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:269)
at
sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:108)
at java.nio.file.Files.deleteIfExists(Files.java:1116)
at
org.apache.log4j.config.Log4j1ConfigurationFactoryTest.testSystemProperties1(Log4j1ConfigurationFactoryTest.java:173)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)


On Sat, Nov 18, 2017 at 8:59 PM,  wrote:

> Repository: logging-log4j2
> Updated Branches:
>   refs/heads/master e962f82cf -> 5d7f784b4
>
>
> Always delete temporary file created in test
>
>
> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/
> commit/5d7f784b
> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/5d7f784b
> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/5d7f784b
>
> Branch: refs/heads/master
> Commit: 5d7f784b4fecf086b545c2143a054c9ce5c9c301
> Parents: e962f82
> Author: Mikael Ståldal 
> Authored: Sat Nov 18 12:59:08 2017 +0100
> Committer: Mikael Ståldal 
> Committed: Sat Nov 18 12:59:08 2017 +0100
>
> --
>  .../log4j/config/Log4j1ConfigurationFactoryTest.java   | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/
> 5d7f784b/log4j-1.2-api/src/test/java/org/apache/log4j/config/
> Log4j1ConfigurationFactoryTest.java
> --
> diff --git a/log4j-1.2-api/src/test/java/org/apache/log4j/config/
> Log4j1ConfigurationFactoryTest.java b/log4j-1.2-api/src/test/java/
> org/apache/log4j/config/Log4j1ConfigurationFactoryTest.java
> index ff1fa12..a5a8e67 100644
> --- a/log4j-1.2-api/src/test/java/org/apache/log4j/config/
> Log4j1ConfigurationFactoryTest.java
> +++ b/log4j-1.2-api/src/test/java/org/apache/log4j/config/
> Log4j1ConfigurationFactoryTest.java
> @@ -161,12 +161,15 @@ public class Log4j1ConfigurationFactoryTest {
>
> @Test
> public void testSystemProperties1() throws Exception {
> -   final Configuration configuration =
> getConfiguration("config-1.2/log4j-system-properties-1.properties");
> -   final RollingFileAppender appender =
> configuration.getAppender("RFA");
>  final String tempFileName = System.getProperty("java.io.tmpdir")
> + "/hadoop.log";
> -System.out.println("expected: " + tempFileName + " Actual: " +
> appender.getFileName());
> -   assertEquals(tempFileName, appender.getFileName());
> -   Files.deleteIfExists(new File(tempFileName).toPath());

Re: logging-log4j2 git commit: Always delete temporary file created in test

[Remko Popma]

I have a fix, but I’ll hold off pushing it until Ralph is done with the release 
that’s in progress. 

(It’s just a try/catch FileSystemException around the deleteIfExists in the 
finally block on line 174)

(Shameless plug) Every java main() method deserves http://picocli.info

> On Nov 19, 2017, at 20:46, Mikael Ståldal  wrote:
> 
> Does it help if you add:
> 
>appender.stop(10, TimeUnit.SECONDS);
> 
> after line 171 in Log4j1ConfigurationFactoryTest.java (last in the try block)?
> 
> 
>> On 2017-11-19 05:41, Remko Popma wrote:
>> The build now fails on windows.
>> I always see this error:
>> expected: C:\Users\remko\AppData\Local\Temp\/hadoop.log Actual:
>> C:\Users\remko\AppData\Local\Temp\/hadoop.log
>> java.nio.file.FileSystemException:
>> C:\Users\remko\AppData\Local\Temp\hadoop.log: The process cannot access the
>> file because it is being used by another process.
>> at
>> sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
>> at
>> sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
>> at
>> sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
>> at
>> sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:269)
>> at
>> sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:108)
>> at java.nio.file.Files.deleteIfExists(Files.java:1116)
>> at
>> org.apache.log4j.config.Log4j1ConfigurationFactoryTest.testSystemProperties1(Log4j1ConfigurationFactoryTest.java:173)

Re: [VOTE] Release Log4j 2.10.0-rc1

[Remko Popma]

When I upgraded picocli to 2.0.3 a few weeks ago I made sure all tests passed 
on Windows. CI builds are ok. 

I also did a successful Log4j2 build on Windows yesterday when looking at pull 
request #134. 

This is very odd. 


> On Nov 20, 2017, at 12:49, Ralph Goers  wrote:
> 
> All of these errors seem to be against a single test class which tests the 
> help text of the command line tool. Frankly, I don’t even know what that tool 
> does. Second, I’ve not had any problems on MacOS nor seem complaints on 
> Linux. Have you run a full build on Windows since JCommander replaced 
> Piccoli? Does the command line tool still work or is this just a problem with 
> the tests not behaving correctly on Windows (which is what I suspect)?
> 
> Ralph
> 
>> On Nov 19, 2017, at 6:32 PM, Gary Gregory  wrote:
>> 
>> -1
>> 
>> From src zip: ASC OK, MD5 OK, SHA1 OK.
>> 
>> Building with 'mvn clean verify' using:
>> 
>> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
>> 2017-10-18T03:58:13-04:00)
>> Maven home: C:\Java\apache-maven-3.5.2
>> Java version: *1.7.0_80*, vendor: *Oracle* Corporation
>> Java home: C:\Program Files\Java\jdk1.7.0_80\jre
>> Default locale: en_US, platform encoding: Cp1252
>> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"
>> 
>> I get the following ERRORs:
>> 
>> [ERROR] Tests run: 136, Failures: 17, Errors: 0, Skipped: 1, Time elapsed:
>> 0.6 s <<< FAILURE! - in
>> org.apache.logging.log4j.core.tools.picocli.CommandLineHelpTest
>> [ERROR]
>> testSynopsisOrderCorrectWhenParametersDeclaredOutOfOrder(org.apache.logging.log4j.core.tools.picocli.CommandLineHelpTest)
>> Time elapsed: 0 s  <<< FAILURE!
>> org.junit.ComparisonFailure:
>> expected:<[  ]
>>> but was:<[  ]
>>> 
>>   at
>> org.apache.logging.log4j.core.tools.picocli.CommandLineHelpTest.testSynopsisOrderCorrectWhenParametersDeclaredOutOfOrder(CommandLineHelpTest.java:2014)
>> 
>> [ERROR]
>> testDefaultParameterRenderer_rendersSpecifiedMarkerForParametersWithPositiveArity(org.apache.logging.log4j.core.tools.picocli.CommandLineHelpTest)
>> Time elapsed: 0 s  <<< FAILURE!
>> org.junit.internal.ArrayComparisonFailure: [*, , , , required]:
>> arrays first differed at element [0]; expected:<*> but was:<*>
>>   at
>> org.apache.logging.log4j.core.tools.picocli.CommandLineHelpTest.testDefaultParameterRenderer_rendersSpecifiedMarkerForParametersWithPositiveArity(CommandLineHelpTest.java:1020)
>> Caused by: java.lang.AssertionError: expected:<*> but was:<*>
>>   at
>> org.apache.logging.log4j.core.tools.picocli.CommandLineHelpTest.testDefaultParameterRenderer_rendersSpecifiedMarkerForParametersWithPositiveArity(CommandLineHelpTest.java:1020)
>> 
>> [ERROR]
>> testDefaultOptionRenderer_rendersSpacePrefixByDefaultForRequiredOptionsWithDefaultValue(org.apache.logging.log4j.core.tools.picocli.CommandLineHelpTest)
>> Time elapsed: 0.017 s  <<< FAILURE!
>> org.junit.internal.ArrayComparisonFailure: [ , -b, ,, -a,
>> --alpha=, other]: arrays first differed at element [0];
>> expected:< > but was:< >
>>   at
>> org.apache.logging.log4j.core.tools.picocli.CommandLineHelpTest.testDefaultOptionRenderer_rendersSpacePrefixByDefaultForRequiredOptionsWithDefaultValue(CommandLineHelpTest.java:990)
>> Caused by: java.lang.AssertionError: expected:< > but was:< >
>>   at
>> org.apache.logging.log4j.core.tools.picocli.CommandLineHelpTest.testDefaultOptionRenderer_rendersSpacePrefixByDefaultForRequiredOptionsWithDefaultValue(CommandLineHelpTest.java:990)
>> 
>> [ERROR]
>> testDefaultParameterRenderer_rendersSpacePrefixForParametersWithZeroArity(org.apache.logging.log4j.core.tools.picocli.CommandLineHelpTest)
>> Time elapsed: 0 s  <<< FAILURE!
>> org.junit.internal.ArrayComparisonFailure: [, , , , optional]:
>> arrays first differed at element [3]; expected:<> but
>> was:<>
>>   at
>> org.apache.logging.log4j.core.tools.picocli.CommandLineHelpTest.testDefaultParameterRenderer_rendersSpacePrefixForParametersWithZeroArity(CommandLineHelpTest.java:1035)
>> Caused by: java.lang.AssertionError: expected:<> but
>> was:<>
>>   at
>> org.apache.logging.log4j.core.tools.picocli.CommandLineHelpTest.testDefaultParameterRenderer_rendersSpacePrefixForParametersWithZeroArity(CommandLineHelpTest.java:1035)
>> 
>> [ERROR]
>> testDefaultOptionRenderer_rendersSpecifiedMarkerForRequiredOptionsWithDefault(org.apache.logging.log4j.core.tools.picocli.CommandLineHelpTest)
>> Time elapsed: 0 s  <<< FAILURE!
>> org.junit.internal.ArrayComparisonFailure: [*, -b, ,, -a,
>> --alpha=, other]: arrays first differed at element [0];
>> expected:<*> but was:<*>
>>   at
>> org.apache.logging.log4j.core.tools.picocli.CommandLineHelpTest.testDefaultOptionRenderer_rendersSpecifiedMarkerForRequiredOptionsWithDefault(CommandLineHelpTest.java:944)
>> Caused by: java.lang.AssertionError: expected:<*> but was:<*>
>>   at
>> org.apache.logging.log4j.core.tools.picocli.CommandLineHelpTest.testDefaultOptionRenderer_rendersSpecifiedMarkerForReq

Re: [VOTE] Release Log4j 2.10.0-rc1

[Remko Popma]

Building current master (211326b) succeeds for me when running `mvn clean
verify` on

Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-11T01:41:47+09:00)
Maven home: C:\apps\apache-maven-3.3.9\bin\..
Java version: 1.8.0_131, vendor: Oracle Corporation
Java home: C:\apps\jdk1.8.0_131\jre
Default locale: en_US, platform encoding: MS932
OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos"

[INFO] Reactor Summary:
[INFO]
[INFO] Apache Log4j 2 . SUCCESS [
7.669 s]
[INFO] Apache Log4j API Java 9 support  SUCCESS [
15.544 s]
[INFO] Apache Log4j API ... SUCCESS [
39.700 s]
[INFO] Apache Log4j Core .. SUCCESS [20:39
min]
[INFO] Apache Log4j Core Integration Tests  SUCCESS [01:11
min]
[INFO] Apache Log4j 1.x Compatibility API . SUCCESS [
20.190 s]
[INFO] Apache Log4j SLF4J Binding . SUCCESS [
12.041 s]
[INFO] Apache Log4j to SLF4J Adapter .. SUCCESS [
7.408 s]
[INFO] Apache Log4j Commons Logging Bridge  SUCCESS [
6.109 s]
[INFO] Apache Log4j Flume Bridge .. SUCCESS [
35.029 s]
[INFO] Apache Log4j Web ... SUCCESS [
14.350 s]
[INFO] Apache Log4j Tag Library ... SUCCESS [
23.264 s]
[INFO] Apache Log4j JMX GUI ... SUCCESS [
2.881 s]
[INFO] Apache Log4j Samples ... SUCCESS [
0.649 s]
[INFO] Apache Log4j Samples: Flume - Common ... SUCCESS [
3.368 s]
[INFO] Apache Log4j Samples: Flume - Remote ... SUCCESS [
3.873 s]
[INFO] Apache Log4j Samples: Flume - Embedded . SUCCESS [
8.254 s]
[INFO] Apache Log4j Samples: Configuration  SUCCESS [
5.707 s]
[INFO] Apache Log4j Samples: LoggerProperties . SUCCESS [
5.481 s]
[INFO] Apache Log4j OSGi .. SUCCESS [
10.065 s]
[INFO] Apache Log4j BOM ... SUCCESS [
1.030 s]
[INFO] Apache Log4j CouchDB ... SUCCESS [
2.694 s]
[INFO] Apache Log4j MongoDB ... SUCCESS [
5.229 s]
[INFO] Apache Log4j Cassandra . SUCCESS [
26.357 s]
[INFO] Apache Log4J Performance Tests . SUCCESS [01:01
min]
[INFO] Apache Log4j Streaming Interface ... SUCCESS [
19.790 s]
[INFO] Apache Log4j JUL Adapter ... SUCCESS [
17.716 s]
[INFO] Apache Log4j Liquibase Binding . SUCCESS [
4.818 s]
[INFO] Apache Log4j App Server Support  SUCCESS [
2.434 s]
[INFO]

[INFO] BUILD SUCCESS
[INFO]

[INFO] Total time: 27:57 min
[INFO] Finished at: 2017-11-20T14:56:18+09:00
[INFO] Final Memory: 56M/518M
[INFO]
----



On Mon, Nov 20, 2017 at 2:10 PM, Remko Popma  wrote:

> When I upgraded picocli to 2.0.3 a few weeks ago I made sure all tests
> passed on Windows. CI builds are ok.
>
> I also did a successful Log4j2 build on Windows yesterday when looking at
> pull request #134.
>
> This is very odd.
>
>
> > On Nov 20, 2017, at 12:49, Ralph Goers 
> wrote:
> >
> > All of these errors seem to be against a single test class which tests
> the help text of the command line tool. Frankly, I don’t even know what
> that tool does. Second, I’ve not had any problems on MacOS nor seem
> complaints on Linux. Have you run a full build on Windows since JCommander
> replaced Piccoli? Does the command line tool still work or is this just a
> problem with the tests not behaving correctly on Windows (which is what I
> suspect)?
> >
> > Ralph
> >
> >> On Nov 19, 2017, at 6:32 PM, Gary Gregory 
> wrote:
> >>
> >> -1
> >>
> >> From src zip: ASC OK, MD5 OK, SHA1 OK.
> >>
> >> Building with 'mvn clean verify' using:
> >>
> >> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> >> 2017-10-18T03:58:13-04:00)
> >> Maven home: C:\Java\apache-maven-3.5.2
> >> Java version: *1.7.0_80*, vendor: *Oracle* Corporation
> >> Java home: C:\Program Files\Java\jdk1.7.0_80\jre
> >> Default locale: en_US, platform encoding: Cp1252
> >> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"
> >>
> >> I get the following ERRORs:
> >>
> >> [ERROR] Tests run: 136, Failures: 17, Errors: 0, Skipped: 1, Time
> ela

Re: [VOTE] Release Log4j 2.10.0-rc1

[Remko Popma]

> On Nov 20, 2017, at 15:21, Ralph Goers  wrote:
> 
> Oh, and I wouldn’t be surprised if the problem is caused by you using MS932 
> and Greg using cp1252.

From Gary’s error messages  it seems more like a white space/newline issue 
which is odd  because it works on my Windows and the tests use String.format 
with %n to avoid this exact issue. 


> 
> Ralph
> 
> 
>> On Nov 19, 2017, at 11:12 PM, Remko Popma  wrote:
>> 
>> Building current master (211326b) succeeds for me when running `mvn clean
>> verify` on
>> 
>> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
>> 2015-11-11T01:41:47+09:00)
>> Maven home: C:\apps\apache-maven-3.3.9\bin\..
>> Java version: 1.8.0_131, vendor: Oracle Corporation
>> Java home: C:\apps\jdk1.8.0_131\jre
>> Default locale: en_US, platform encoding: MS932
>> OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos"
>> 
>> [INFO] Reactor Summary:
>> [INFO]
>> [INFO] Apache Log4j 2 . SUCCESS [
>> 7.669 s]
>> [INFO] Apache Log4j API Java 9 support  SUCCESS [
>> 15.544 s]
>> [INFO] Apache Log4j API ... SUCCESS [
>> 39.700 s]
>> [INFO] Apache Log4j Core .. SUCCESS [20:39
>> min]
>> [INFO] Apache Log4j Core Integration Tests  SUCCESS [01:11
>> min]
>> [INFO] Apache Log4j 1.x Compatibility API . SUCCESS [
>> 20.190 s]
>> [INFO] Apache Log4j SLF4J Binding . SUCCESS [
>> 12.041 s]
>> [INFO] Apache Log4j to SLF4J Adapter .. SUCCESS [
>> 7.408 s]
>> [INFO] Apache Log4j Commons Logging Bridge  SUCCESS [
>> 6.109 s]
>> [INFO] Apache Log4j Flume Bridge .. SUCCESS [
>> 35.029 s]
>> [INFO] Apache Log4j Web ... SUCCESS [
>> 14.350 s]
>> [INFO] Apache Log4j Tag Library ... SUCCESS [
>> 23.264 s]
>> [INFO] Apache Log4j JMX GUI ... SUCCESS [
>> 2.881 s]
>> [INFO] Apache Log4j Samples ... SUCCESS [
>> 0.649 s]
>> [INFO] Apache Log4j Samples: Flume - Common ... SUCCESS [
>> 3.368 s]
>> [INFO] Apache Log4j Samples: Flume - Remote ... SUCCESS [
>> 3.873 s]
>> [INFO] Apache Log4j Samples: Flume - Embedded . SUCCESS [
>> 8.254 s]
>> [INFO] Apache Log4j Samples: Configuration  SUCCESS [
>> 5.707 s]
>> [INFO] Apache Log4j Samples: LoggerProperties . SUCCESS [
>> 5.481 s]
>> [INFO] Apache Log4j OSGi .. SUCCESS [
>> 10.065 s]
>> [INFO] Apache Log4j BOM ... SUCCESS [
>> 1.030 s]
>> [INFO] Apache Log4j CouchDB ... SUCCESS [
>> 2.694 s]
>> [INFO] Apache Log4j MongoDB ... SUCCESS [
>> 5.229 s]
>> [INFO] Apache Log4j Cassandra . SUCCESS [
>> 26.357 s]
>> [INFO] Apache Log4J Performance Tests . SUCCESS [01:01
>> min]
>> [INFO] Apache Log4j Streaming Interface ... SUCCESS [
>> 19.790 s]
>> [INFO] Apache Log4j JUL Adapter ... SUCCESS [
>> 17.716 s]
>> [INFO] Apache Log4j Liquibase Binding . SUCCESS [
>> 4.818 s]
>> [INFO] Apache Log4j App Server Support .... SUCCESS [
>> 2.434 s]
>> [INFO]
>> 
>> [INFO] BUILD SUCCESS
>> [INFO]
>> 
>> [INFO] Total time: 27:57 min
>> [INFO] Finished at: 2017-11-20T14:56:18+09:00
>> [INFO] Final Memory: 56M/518M
>> [INFO]
>> 
>> 
>> 
>> 
>>> On Mon, Nov 20, 2017 at 2:10 PM, Remko Popma  wrote:
>>> 
>>> When I upgraded picocli to 2.0.3 a few weeks ago I made sure all tests
>>> passed on Windows. CI builds are ok.
>>> 
>>> I also did a successful Log4j2 build on Windows yesterday when looking at
>>> pull request #134.
>>> 
>>> This is very odd.
>>> 
>>> 
>>>> On Nov 20, 2017, at 12:49, Ralph Goers 
>>> wrote:
>>>> 
>>>> All of these errors seem to be against a single test class which tests
>

Re: [VOTE] Release Log4j 2.10.0-rc1

[Remko Popma]

Ran another build from the release tag, with Java 7. Build succeeds.

I'll look at the checksums and the site next.

Gary, could you run another clean build?
The error messages look strange: I cannot see any difference between the
expected and the actual result in the error output...



Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-11T01:41:47+09:00)
Maven home: C:\apps\apache-maven-3.3.9\bin\..
Java version: 1.7.0_55, vendor: Oracle Corporation
Java home: C:\apps\jdk1.7.0_55\jre
Default locale: en_US, platform encoding: MS932
OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"

[INFO] Reactor Summary:
[INFO]
[INFO] Apache Log4j 2 . SUCCESS [
3.940 s]
[INFO] Apache Log4j API Java 9 support  SUCCESS [
12.324 s]
[INFO] Apache Log4j API ... SUCCESS [
36.662 s]
[INFO] Apache Log4j Core .. SUCCESS [22:30
min]
[INFO] Apache Log4j Core Integration Tests  SUCCESS [01:26
min]
[INFO] Apache Log4j 1.x Compatibility API . SUCCESS [
19.337 s]
[INFO] Apache Log4j SLF4J Binding . SUCCESS [
10.867 s]
[INFO] Apache Log4j to SLF4J Adapter .. SUCCESS [
5.751 s]
[INFO] Apache Log4j Commons Logging Bridge  SUCCESS [
5.527 s]
[INFO] Apache Log4j Flume Bridge .. SUCCESS [
35.251 s]
[INFO] Apache Log4j Web ... SUCCESS [
13.574 s]
[INFO] Apache Log4j Tag Library ... SUCCESS [
24.771 s]
[INFO] Apache Log4j JMX GUI ... SUCCESS [
2.966 s]
[INFO] Apache Log4j Samples ... SUCCESS [
0.846 s]
[INFO] Apache Log4j Samples: Flume - Common ... SUCCESS [
4.211 s]
[INFO] Apache Log4j Samples: Flume - Remote ... SUCCESS [
3.523 s]
[INFO] Apache Log4j Samples: Flume - Embedded . SUCCESS [
9.808 s]
[INFO] Apache Log4j Samples: Configuration  SUCCESS [
4.508 s]
[INFO] Apache Log4j Samples: LoggerProperties . SUCCESS [
4.883 s]
[INFO] Apache Log4j OSGi .. SUCCESS [
9.422 s]
[INFO] Apache Log4j BOM ... SUCCESS [
1.082 s]
[INFO] Apache Log4j CouchDB ... SUCCESS [
2.306 s]
[INFO] Apache Log4j MongoDB ... SUCCESS [
4.873 s]
[INFO] Apache Log4j Cassandra . SUCCESS [
27.022 s]
[INFO] Apache Log4J Performance Tests . SUCCESS [
58.354 s]
[INFO] Apache Log4j Streaming Interface ... SUCCESS [
15.511 s]
[INFO] Apache Log4j JUL Adapter ... SUCCESS [
15.085 s]
[INFO] Apache Log4j Liquibase Binding . SUCCESS [
4.396 s]
[INFO] Apache Log4j App Server Support  SUCCESS [
1.993 s]
[INFO]

[INFO] BUILD SUCCESS
[INFO]

[INFO] Total time: 29:39 min
[INFO] Finished at: 2017-11-20T20:25:57+09:00
[INFO] Final Memory: 55M/451M
[INFO]
--------


On Mon, Nov 20, 2017 at 5:06 PM, Remko Popma  wrote:

>
> > On Nov 20, 2017, at 15:21, Ralph Goers 
> wrote:
> >
> > Oh, and I wouldn’t be surprised if the problem is caused by you using
> MS932 and Greg using cp1252.
>
> From Gary’s error messages  it seems more like a white space/newline issue
> which is odd  because it works on my Windows and the tests use
> String.format with %n to avoid this exact issue.
>
>
> >
> > Ralph
> >
> >
> >> On Nov 19, 2017, at 11:12 PM, Remko Popma 
> wrote:
> >>
> >> Building current master (211326b) succeeds for me when running `mvn
> clean
> >> verify` on
> >>
> >> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> >> 2015-11-11T01:41:47+09:00)
> >> Maven home: C:\apps\apache-maven-3.3.9\bin\..
> >> Java version: 1.8.0_131, vendor: Oracle Corporation
> >> Java home: C:\apps\jdk1.8.0_131\jre
> >> Default locale: en_US, platform encoding: MS932
> >> OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos"
> >>
> >> [INFO] Reactor Summary:
> >> [INFO]
> >> [INFO] Apache Log4j 2 . SUCCESS [
> >> 7.669 s]
> >> [INFO] Apache Log4j API Java 9 support  SUCCESS [
> >> 15.544 s]
> >> [INFO] Apache Log4j API ... SUCCESS [
> >> 39.700 s]
> >>

Re: [VOTE] Release Log4j 2.10.0-rc1

[Remko Popma]

+1
checksums good, build good, site good other than H3 on top page.

On Tue, Nov 21, 2017 at 5:41 AM, Matt Sicker  wrote:

> FWIW, if I have to download and compile the source code for Java libraries,
> I usually just skip tests.
>
> On 20 November 2017 at 13:50, Ralph Goers 
> wrote:
>
> > More like 4 hors
> >
> > Sent from my iPhone
> >
> > > On Nov 20, 2017, at 12:43 PM, Mikael Ståldal  wrote:
> > >
> > > It is. But how common is it that people download the source of a
> > particular release? I think that most people either download the binary
> > artifacts, or build the source from latest master branch (and there it is
> > already fixed).
> > >
> > > Maybe we can include something about this in the release notes, that
> > this unit test might fail in Windows.
> > >
> > > It is unfourtante that our release process is so heavy that it takes ~1
> > hour to make another RC, but that's the way it (currently) is.
> > >
> > >
> > >> On 2017-11-20 20:33, Gary Gregory wrote:
> > >> It's just lame that if someone downloads the source they cannot even
> > build
> > >> it :-(
> > >> Gayr
> > >>> On Mon, Nov 20, 2017 at 2:28 PM, Mikael Ståldal 
> > wrote:
> > >>> I agree with Ralph.
> > >>>
> > >>>> On 2017-11-20 20:03, Ralph Goers wrote:
> > >>>>
> > >>>> Unless you find something else I am not inclined to rerun the
> release
> > >>>> just to fix a unit test where we know what the problem is and that
> > has no
> > >>>> impact on the code customers use.
> > >>>>
> > >>>> Ralph
> > >>>>
> > >>>> On Nov 20, 2017, at 11:56 AM, Gary Gregory 
> > >>>>> wrote:
> > >>>>>
> > >>>>> On Mon, Nov 20, 2017 at 10:43 AM, Gary Gregory <
> > garydgreg...@gmail.com>
> > >>>>> wrote:
> > >>>>>
> > >>>>> Here it is:
> > >>>>>>
> > >>>>>> [ERROR] Tests run: 13, Failures: 0, Errors: 1, Skipped: 0, Time
> > elapsed:
> > >>>>>> 1.469 s <<< FAILURE! - in org.apache.log4j.config.
> > >>>>>> Log4j1ConfigurationFactoryTest
> > >>>>>> [ERROR] testSystemProperties1(org.apache.log4j.config.
> > >>>>>> Log4j1ConfigurationFactoryTest)  Time elapsed: 0.027 s  <<<
> ERROR!
> > >>>>>> java.nio.file.FileSystemException:
> > >>>>>> C:\Users\ggregory\AppData\Local\Temp\hadoop.log: The process
> cannot
> > >>>>>> access the file because it is being used by another process.
> > >>>>>>
> > >>>>>> at org.apache.log4j.config.Log4j1ConfigurationFactoryTest
> > >>>>>> .testSystemProperties1(Log4j1ConfigurationFactoryTest.java:173)
> > >>>>>>
> > >>>>>>
> > >>>>>> I think Remko fixed that in master.
> > >>>>>>
> > >>>>>>
> > >>>>> Building master with 'mvn clean install' passes so I would prefer
> > another
> > >>>>> RC that picks up Remko's fix.
> > >>>>>
> > >>>>> Gary
> > >>>>>
> > >>>>>
> > >>>>>> Gary
> > >>>>>>
> > >>>>>> On Mon, Nov 20, 2017 at 9:41 AM, Gary Gregory <
> > garydgreg...@gmail.com>
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>> Wow,
> > >>>>>>>
> > >>>>>>> Now I get a different failure. I had run the build in Windows but
> > from
> > >>>>>>> the git command line (MINGW64). That that I run from a "real"
> > Windows
> > >>>>>>> command line I get:
> > >>>>>>>
> > >>>>>>> [ERROR] Errors:
> > >>>>>>> [ERROR]   Log4j1ConfigurationFactoryTest
> .testSystemProperties1:173
> > »
> > >>>>>>> FileSystem C:\Users...
> > >>>>>>> [INFO]
> > >>>>>>> [ERROR] Tests run: 145, Failures: 0, Errors: 1, Skipped: 0
> > >>>>>>> [INF

Re: [VOTE][RESULT] Release Log4j 2.10.0-rc1

[Remko Popma]

I'll prepare the usual blog post.


On Thu, Nov 23, 2017 at 11:57 AM, Ralph Goers 
wrote:

> This vote has passed with binding +1 votes from Mikael Ståldal, Matt
> Sicker, Remko Popma, and Ralph Goers,  a binding -1 from Gary Gregory, and
> a non-binding +1 from Daan Hoogland.
>
> I will continue with the release process.
>
> Ralph
>

converting markdown links to html links

[Remko Popma]

This took me a while to get right, so let me share it.

Below unix command can be used to replace the markdown links to HTML links
in a text file:

sed -i -e 's/\[\([^\]*\)\](\([^)]*\))/\1<\/a>/g'
RELEASE-NOTES.md

Tricky points were that sed does not recognize the non-greedy qualifier, so
you need to do [^x]* to match _up to_ the next `x`.
Also round brackets are taken literally and capturing group brackets need
to be escaped (the opposite from what I expected).

Re: converting markdown links to html links

[Remko Popma]

Really?
Looking at announcement.vm they seem identical. 



> On Nov 23, 2017, at 16:59, Ralph Goers  wrote:
> 
> Thanks, although the announcement is going to contain a bit more text than is 
> in the release notes.
> 
> Ralph
> 
>> On Nov 23, 2017, at 12:06 AM, Remko Popma  wrote:
>> 
>> This took me a while to get right, so let me share it.
>> 
>> Below unix command can be used to replace the markdown links to HTML links
>> in a text file:
>> 
>> sed -i -e 's/\[\([^\]*\)\](\([^)]*\))/\1<\/a>/g'
>> RELEASE-NOTES.md
>> 
>> Tricky points were that sed does not recognize the non-greedy qualifier, so
>> you need to do [^x]* to match _up to_ the next `x`.
>> Also round brackets are taken literally and capturing group brackets need
>> to be escaped (the opposite from what I expected).
> 
> 

Log4JNA

[Remko Popma]

Interesting:
https://github.com/dblock/log4jna/blob/master/README.md

Maybe we should link to this from our site somewhere. Like a section on 3rd 
party appenders or so?

Re: [jira] [Commented] (LOG4J2-1606) log4j-web deinitalizes the Logger too early if listeners defined in web.xml use it

[Remko Popma]

Guys, if any of your findings should be reflected in the Log4j2
documentation for web applications, please let us know (I'm not following
this discussion in enough detail to judge whether the Log4j2 docs need
adjustment).

Documentation patches are always welcome!

On Thu, Nov 23, 2017 at 10:54 PM, Pavel Erofeev (JIRA) 
wrote:

>
> [ https://issues.apache.org/jira/browse/LOG4J2-1606?page=
> com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel&focusedCommentId=16264359#comment-16264359 ]
>
> Pavel Erofeev commented on LOG4J2-1606:
> ---
>
> Thanks a lot [~lukedirtwalker] and [~rtur...@e-djuster.com]
> After trying different workarounds I found the one which works fine for us:
> * I keep log4j-web on the classpath
> * In web.xml I disable auto initialization with context param {{
> isLog4jAutoInitializationDisabled}}
> * I include {{Log4jServletContextListener}} as the first listener in
> web.xml - it guarantees the right order of initialization / shutdown
> * Inside all other context listeners, I don't create loggers before
> contextInitialized is called
>
> > log4j-web deinitalizes the Logger too early if listeners defined in
> web.xml use it
> > 
> ---
> >
> > Key: LOG4J2-1606
> > URL: https://issues.apache.org/jira/browse/LOG4J2-1606
> > Project: Log4j 2
> >  Issue Type: Bug
> >  Components: Web/Servlet
> >Affects Versions: 2.6.2
> > Environment: Java8, Linux/Mac, Tomcat
> >Reporter: Lukas Vogel
> >
> > We use log4j in a Apache Tomcat environment.
> > In the web.xml file we define a custom ServerStartup listener that
> initializes the DB etc and logs both in contextInitialized and
> contextDestroyed.
> > If we use the log4j-web package the class Log4jServletContainerInitializer
> initializes the logger and adds a Log4jServletContextListener to the
> ServletContext. Since this listener is added after our listener the method
> Log4jServletContextListener#contextDestroyed is called before our
> listener's contextDestroyed method. Thus the Logger is de-initialized too
> early.
> > We could disable auto initialization and initialize the logger ourselves
> but then doing it in the listener is too late since the
> WebService-framework (Metro glassfish) initializes the webservice endpoints
> before the listener. Since we use static logger variables in those
> webservice classes this would trigger the message "StatusLogger no log4j
> configuration found..."  because the logger was not yet initialized.
> > One possible patch we see is that we make an option to manually add the
> Log4jServletContextListener:
> > In Log4jServletContainerInitializer we would put an "if (! Manually
> added)" around the  call "servletContext.addListener(new
> Log4jServletContextListener());" and then we could manually add it to the
> listeners in web.xml
> > If you have any other suggestions I would be glad to hear them.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.14#64029)
>

Re: [Log4j] Header/footer and thread context

[Remko Popma]

Generally it doesn’t make sense to expect ThreadLocal lookups to work with 
async appender/loggers. Another lookup should be used. 

I haven’t looked at the code but I expect that the subject is cached somehow. 
Perhaps this should be changed (to no caching) so that the user experience is 
consistent. 

(Shameless plug) Every java main() method deserves http://picocli.info

> On Dec 1, 2017, at 6:05, Matt Sicker  wrote:
> 
> I'm not sure if this use case makes much sense. Dynamic data like that
> makes more sense in the message itself, though I'm sure there are several
> ways to do this.
> 
>> On 30 November 2017 at 15:02, Mikael Ståldal  wrote:
>> 
>> I am looking at https://issues.apache.org/jira/browse/LOG4J2-2007
>> 
>> What is the expected behavior here? Should there be any thread context for
>> header/footer?
>> 
>> I guess it should be consistent for sync and async logging, which it isn't
>> right now. But maybe the async case is correct in not includin any thread
>> context in header/footer, and the sync case incorrect?
>> 
> 
> 
> 
> -- 
> Matt Sicker 

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

[Remko Popma]

Ok, you have some fair points there.

Main take-away for me is that if we want Log4j2's API to become ubiquitous
it needs to be at least painless for everyone.
Don't known about the "too much stuff" in log4j-api - bit vague and not
actionable.

What can we do, concretely?

log4j-api
-
1) I've already replaced the explicit references to JMX classes in
log4j-api with reflection for Android compatibility. (LOG4J2-2126
 was a regression, fixed
now)
2) The tricky bit is StackLocator. Options I can think of:
   a) reflection;
   b) separate log4j-api-java9 jar;
   c) rename java 9 class files to other extension than .class and load at
runtime when running in Java 9
   d) other?
3) The PID stuff can be moved to core (would still need some solution like
for above (2) to allow use in Android).


log4j-core
--
We don't really have a good Android story for core.

One option we can offer is log4j-api-android, which is a drop-in
replacement for log4j-core that logs to Android's adb, similar to what
"android.util.Log.d" does. However, we've had feedback from users who want
to use normal log4j-core file logging facilities on Android (LOG4J2-1921
).

Maybe we can do the same for log4j-core as for log4j-api: use reflection or
even separate jars :-( to make log4j-core work in Android.



On Sat, Dec 2, 2017 at 8:09 PM, Mikael Ståldal  wrote:

> I fully understand Oleg's point of view.
>
> If we aim for Log4j 2's API to be the standard logging API/facade for
> Java/JVM (eventually replacing SLF4J), then we have painted ourselves into
> a corner by allowing log4j-api to grow out of bounds, and not paying enough
> attention to the compatibility problems with Android (and possibly fringe
> platforms) it causes.
>
> It is quite pointless to blame this on Android and its tooling. We can,
> and should raise issues we find on Android tooling, and hope for them to
> eventually get fixed. But that can take time, and at the end of the day
> Android is what it is, and that's what users are going to use. If log4j-api
> does not work on Android, most users will blame Log4j and not Android.
>
> And if a library with use cases both on standard Java and on Android, like
> Apache HttpClient, have a required dependency on log4j-api and that causes
> it to fail on Android, most users will blame HttpClient and not Android
> (nor Log4j since they may be unaware of it).
>
> If I were maintainer of Apache HttpClient, I would also be very hesitant
> to make it depend on log4j-api at this point. I don't think it is
> constructive to just try to convince them given the current state of Log4j
> and the Android tooling, we need to do some work on our end first (or
> possibly volunteer to spend some effort on fixing the Android tooling).
>
> I think that the root cause is not Java 9 support, it is that we have
> allowed too much stuff to go into log4j-api (instead of log4j-core), and
> that started long before the Java 9 work. JMX is also incompatible with
> Android, regardless of Java 9.
>
> With a thinner log4j-api, we could have added Java 9 support to log4j-core
> only, and avoided this problem.
>
>
>
> On 2017-12-01 15:53, Gary Gregory wrote:
>
>> I had migrated HttpClient 5 to Log4j 2 but now there is push back due to
>> the mess Java 9 has made of the META-INF folder and our adding support for
>> Java 9 modules perhaps too soon.
>>
>> Please see http://markmail.org/message/yyoj4zs3ieyaept5 and comment on
>> that
>> thread please.
>>
>

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

[Remko Popma]

> On Dec 3, 2017, at 1:38, Ralph Goers  wrote:
> 
> I see several issues:
> 
> StackLocator:
>This cannot be removed from the API is the API as LogManager.getLogger() 
> calls it. Converting the Java 9 version to use Reflection would add enough 
> overhead that it probably wouldn’t be worth it to use it. Also, you would 
> have to figure out how to code the lambda expressions without using Lambdas. 
> Adding a log4j-java9 jar for api and/or core would probably make us as 
> unpopular with folks migrating to Java 9 as the current situation is for 
> Android users, but it may be the only viable solution. Figuring out how to 
> have the class files be ignored by Android seems reasonable but nothing 
> immediately comes to mind as to how to do it.
> 
> I made a log4j-android branch a while back that operates pretty much as Remko 
> describes below. It does not include the Java 9 support and includes a 
> binding to the android logger. However, I got an immediate complaint from an 
> Android user that they were not happy with that as they wanted access to 
> core. It is also a problem to have lots of pom files refer to log4j-api and 
> to have to exclude that and replace it with log4j-android instead.
> 
> I do not want to drop support for Java 9 but we do need to find a creative 
> solution for StackLocator. The limitations I am aware of with this are that 
> having multi-release jars and/or Java 9 classes in the jar cause problems 
> with tools. Also, having Java 9 source directly in log4j-api or log4j-core 
> does not play nice with IDEs. 
> 
> The only thing that comes to mind with regarding having classes with a 
> different file extension would be to have a custom class loader that wraps 
> whatever the class loader is. Going down that road seems like it could be 
> full of problems.

We may not need a custom class loader. Idea:

The Java 9 classes would be in the log4j-api jar, just with a different 
extension (so the legacy tooling won’t choke on the version 53 bytecode). 

We can extract those classes into a temp directly, rename them back to the 
canonical extension, and use the same class loader that loaded the other 
log4j-api classes to load the Java 9 classes from the temp directory. 

If this fails, we fall back to the Java 7-compatible implementation. 

> 
> Ralph
> 
> 
> 
> 
>> On Dec 2, 2017, at 7:34 AM, Remko Popma  wrote:
>> 
>> Ok, you have some fair points there.
>> 
>> Main take-away for me is that if we want Log4j2's API to become ubiquitous
>> it needs to be at least painless for everyone.
>> Don't known about the "too much stuff" in log4j-api - bit vague and not
>> actionable.
>> 
>> What can we do, concretely?
>> 
>> log4j-api
>> -
>> 1) I've already replaced the explicit references to JMX classes in
>> log4j-api with reflection for Android compatibility. (LOG4J2-2126
>> <https://issues.apache.org/jira/browse/LOG4J2-2126> was a regression, fixed
>> now)
>> 2) The tricky bit is StackLocator. Options I can think of:
>>  a) reflection;
>>  b) separate log4j-api-java9 jar;
>>  c) rename java 9 class files to other extension than .class and load at
>> runtime when running in Java 9
>>  d) other?
>> 3) The PID stuff can be moved to core (would still need some solution like
>> for above (2) to allow use in Android).
>> 
>> 
>> log4j-core
>> --
>> We don't really have a good Android story for core.
>> 
>> One option we can offer is log4j-api-android, which is a drop-in
>> replacement for log4j-core that logs to Android's adb, similar to what
>> "android.util.Log.d" does. However, we've had feedback from users who want
>> to use normal log4j-core file logging facilities on Android (LOG4J2-1921
>> <https://issues.apache.org/jira/browse/LOG4J2-1921>).
>> 
>> Maybe we can do the same for log4j-core as for log4j-api: use reflection or
>> even separate jars :-( to make log4j-core work in Android.
>> 
>> 
>> 
>>> On Sat, Dec 2, 2017 at 8:09 PM, Mikael Ståldal  wrote:
>>> 
>>> I fully understand Oleg's point of view.
>>> 
>>> If we aim for Log4j 2's API to be the standard logging API/facade for
>>> Java/JVM (eventually replacing SLF4J), then we have painted ourselves into
>>> a corner by allowing log4j-api to grow out of bounds, and not paying enough
>>> attention to the compatibility problems with Android (and possibly fringe
>>> platforms) it causes.
>>> 
>>> It is quite pointless to blame this on Android and its tooling. We can,
>>> and s

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

[Remko Popma]

On second thought, without a custom class loader we’d first need to copy
these classes into the classpath.

This may not always be possible and sounds like a bad idea anyway.

So please ignore my previous email.

On Sun, Dec 3, 2017 at 8:38 Remko Popma  wrote:

>
> > On Dec 3, 2017, at 1:38, Ralph Goers  wrote:
> >
> > I see several issues:
> >
> > StackLocator:
> >This cannot be removed from the API is the API as
> LogManager.getLogger() calls it. Converting the Java 9 version to use
> Reflection would add enough overhead that it probably wouldn’t be worth it
> to use it. Also, you would have to figure out how to code the lambda
> expressions without using Lambdas. Adding a log4j-java9 jar for api and/or
> core would probably make us as unpopular with folks migrating to Java 9 as
> the current situation is for Android users, but it may be the only viable
> solution. Figuring out how to have the class files be ignored by Android
> seems reasonable but nothing immediately comes to mind as to how to do it.
> >
> > I made a log4j-android branch a while back that operates pretty much as
> Remko describes below. It does not include the Java 9 support and includes
> a binding to the android logger. However, I got an immediate complaint from
> an Android user that they were not happy with that as they wanted access to
> core. It is also a problem to have lots of pom files refer to log4j-api and
> to have to exclude that and replace it with log4j-android instead.
> >
> > I do not want to drop support for Java 9 but we do need to find a
> creative solution for StackLocator. The limitations I am aware of with this
> are that having multi-release jars and/or Java 9 classes in the jar cause
> problems with tools. Also, having Java 9 source directly in log4j-api or
> log4j-core does not play nice with IDEs.
> >
> > The only thing that comes to mind with regarding having classes with a
> different file extension would be to have a custom class loader that wraps
> whatever the class loader is. Going down that road seems like it could be
> full of problems.
>
> We may not need a custom class loader. Idea:
>
> The Java 9 classes would be in the log4j-api jar, just with a different
> extension (so the legacy tooling won’t choke on the version 53 bytecode).
>
> We can extract those classes into a temp directly, rename them back to the
> canonical extension, and use the same class loader that loaded the other
> log4j-api classes to load the Java 9 classes from the temp directory.
>
> If this fails, we fall back to the Java 7-compatible implementation.
>
> >
> > Ralph
> >
> >
> >
> >
> >> On Dec 2, 2017, at 7:34 AM, Remko Popma  wrote:
> >>
> >> Ok, you have some fair points there.
> >>
> >> Main take-away for me is that if we want Log4j2's API to become
> ubiquitous
> >> it needs to be at least painless for everyone.
> >> Don't known about the "too much stuff" in log4j-api - bit vague and not
> >> actionable.
> >>
> >> What can we do, concretely?
> >>
> >> log4j-api
> >> -
> >> 1) I've already replaced the explicit references to JMX classes in
> >> log4j-api with reflection for Android compatibility. (LOG4J2-2126
> >> <https://issues.apache.org/jira/browse/LOG4J2-2126> was a regression,
> fixed
> >> now)
> >> 2) The tricky bit is StackLocator. Options I can think of:
> >>  a) reflection;
> >>  b) separate log4j-api-java9 jar;
> >>  c) rename java 9 class files to other extension than .class and load at
> >> runtime when running in Java 9
> >>  d) other?
> >> 3) The PID stuff can be moved to core (would still need some solution
> like
> >> for above (2) to allow use in Android).
> >>
> >>
> >> log4j-core
> >> --
> >> We don't really have a good Android story for core.
> >>
> >> One option we can offer is log4j-api-android, which is a drop-in
> >> replacement for log4j-core that logs to Android's adb, similar to what
> >> "android.util.Log.d" does. However, we've had feedback from users who
> want
> >> to use normal log4j-core file logging facilities on Android (LOG4J2-1921
> >> <https://issues.apache.org/jira/browse/LOG4J2-1921>).
> >>
> >> Maybe we can do the same for log4j-core as for log4j-api: use
> reflection or
> >> even separate jars :-( to make log4j-core work in Android.
> >>
> >>
> >>
> >>> On Sat, Dec 2, 2017 at 8:09 PM, Mikae

Re: SLF4J now requires Java 6

[Remko Popma]

From Java 9, interfaces can have private methods that can be called from 
interface default methods. This is to reduce duplicate code in default method 
implementations. 



> On Dec 3, 2017, at 20:44, Mikael Ståldal  wrote:
> 
>> On 2017-12-03 00:24, Matt Sicker wrote:
>> It's too bad that Java 8 and 9 added language features
>> that would have been immensely useful for maintaining a backwards
>> compatible API (default and private methods on interfaces), 
> 
> Did Java 9 add anything more than Java 8 for this?

Re: [log4j] providing sourcewith Message

[Remko Popma]

Interesting!
Can you point to an example of how this works? I’m trying to understand what 
changes would be required. 

Remko 

(Shameless plug) Every java main() method deserves http://picocli.info

> On Dec 9, 2017, at 15:30, Jeffrey Shaw  wrote:
> 
> Hello,
> I've found that I am able to use Scala macros to provide compile-time
> source information for log messages. However, I don't see a way to inject
> this into log4j's logging mechanism.
> 
> I'm wondering if there is something I'm missing, or if LogEvent's getSource
> method could be duplicated in Message.
> 
> We could then have zero-overhead location information in logs. I'm thinking
> that tools other than Scala could also take advantage of this.
> 
> Thanks,
> Jeff

Re: [jira] [Commented] (LOG4J2-1944) Should suppress message "ERROR No log4j2 configuration file found..." when programmatic API is used to config log4j.

[Remko Popma]

But how would this filter be installed given that there is no configuration
file? Aren't we back to a system property to install this filter?

On Tue, Jan 2, 2018 at 12:27 PM, Ralph Goers (JIRA)  wrote:

>
> [ https://issues.apache.org/jira/browse/LOG4J2-1944?page=
> com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel&focusedCommentId=16307645#comment-16307645 ]
>
> Ralph Goers commented on LOG4J2-1944:
> -
>
> Rather than adding yet another system property to deal with this single
> case it seems to me that allowing some sort of filtering on the message
> text or log level in StatusLogger would be a more flexible solution to
> this. This way the user could configure a filter that suppresses any status
> logger message they don't want to see.
>
> > Should suppress message "ERROR No log4j2 configuration file found..."
> when programmatic API is used to config log4j.
> > 
> 
> >
> > Key: LOG4J2-1944
> > URL: https://issues.apache.org/jira/browse/LOG4J2-1944
> > Project: Log4j 2
> >  Issue Type: Bug
> >  Components: Configurators
> >Affects Versions: 2.6.2
> >Reporter: Weian Deng
> >Priority: Minor
> > Attachments: LOG4J2-1944.patch, LOG4J2_1944.zip
> >
> >
> > Log4j can be configured through log4j's configuration API.  There are
> cases that an organization want to control the log4j configuration through
> the configuration API and discourage the use of config file.  The error
> message
> > {code}
> > ERROR No log4j2 configuration file found. Using default configuration:
> logging only errors to the console.
> > {code}
> > is misleading.
> > Can this be downgraded to WARN message, or provide a way to suppress it?
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.14#64029)
>

log4j2 build fails in OSGi

[Remko Popma]

The build repeatedly gets stuck at the OSGi module...

[ERROR]
testMissingImportOfCoreOsgiPackage(org.apache.logging.log4j.osgi.tests.equinox.EquinoxLoadApiBundleTest)
Time elapsed: 0.58 s  <<< ERROR!
org.osgi.framework.BundleException: Error reading bundle content.
Caused by: java.io.FileNotFoundException:
C:\Users\remko\IdeaProjects\logging-log4j2\log4j-samples\configuration\target\log4j-samples-configuration-2.10.1-SNAPSHOT.jar
(The system cannot find the path specified)

Anyone else also seeing this?

Re: logging-log4j2 git commit: [LOG4J2-2177] Replace use of deprecated Core API org.apache.logging.log4j.core.impl.Log4jLogEvent.Builder.setContextMap(Map). Add non-JRE-Map ctors for o

[Remko Popma]

> On Jan 9, 2018, at 4:49, ggreg...@apache.org wrote:
> 
> Repository: logging-log4j2
> Updated Branches:
>  refs/heads/master 2352052d0 -> 9637dc558
> 
> 
> [LOG4J2-2177] Replace use of deprecated Core API
> org.apache.logging.log4j.core.impl.Log4jLogEvent.Builder.setContextMap(Map String>). Add non-JRE-Map ctors for our not-real-Maps: StringMap and
> IndexedStringMap.
> 
> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/9637dc55
> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/9637dc55
> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/9637dc55
> 
> Branch: refs/heads/master
> Commit: 9637dc558e338cf3db368dc0fc6bd2a76d09e2cf
> Parents: 2352052
> Author: Gary Gregory 
> Authored: Mon Jan 8 12:49:03 2018 -0700
> Committer: Gary Gregory 
> Committed: Mon Jan 8 12:49:03 2018 -0700
> 
> --
> .../logging/log4j/message/MapMessage.java | 21 +++-
> 1 file changed, 20 insertions(+), 1 deletion(-)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/9637dc55/log4j-api/src/main/java/org/apache/logging/log4j/message/MapMessage.java
> --
> diff --git 
> a/log4j-api/src/main/java/org/apache/logging/log4j/message/MapMessage.java 
> b/log4j-api/src/main/java/org/apache/logging/log4j/message/MapMessage.java
> index 9f2aeeb..b48e825 100644
> --- a/log4j-api/src/main/java/org/apache/logging/log4j/message/MapMessage.java
> +++ b/log4j-api/src/main/java/org/apache/logging/log4j/message/MapMessage.java
> @@ -30,6 +30,7 @@ import org.apache.logging.log4j.util.PerformanceSensitive;
> import org.apache.logging.log4j.util.ReadOnlyStringMap;
> import org.apache.logging.log4j.util.SortedArrayStringMap;
> import org.apache.logging.log4j.util.StringBuilders;
> +import org.apache.logging.log4j.util.StringMap;
> import org.apache.logging.log4j.util.Strings;
> import org.apache.logging.log4j.util.TriConsumer;
> 
> @@ -100,6 +101,15 @@ public class MapMessage, V> 
> implements MultiFormatStr
> }
> 
> /**
> + * Constructs a new instance based on an existing {@link 
> IndexedStringMap}.
> + * @param map The IndexedStringMap.
> + * @since 2.10.1
> + */
> +public MapMessage(final IndexedStringMap map) {
> +this.data = map;
> +}
> +
> +/**
>  * Constructs a new instance.
>  * 
>  * @param  initialCapacity the initial capacity.
> @@ -109,13 +119,22 @@ public class MapMessage, V> 
> implements MultiFormatStr
> }
> 
> /**
> - * Constructs a new instance based on an existing Map.
> + * Constructs a new instance based on an existing {@link Map}.
>  * @param map The Map.
>  */
> public MapMessage(final Map map) {
> this.data = new SortedArrayStringMap(map);
> }
> 
> +/**
> + * Constructs a new instance based on an existing {@link StringMap}.
> + * @param map The StringMap.
> + * @since 2.10.1
> + */
> +public MapMessage(final StringMap map) {
> +this.data = map instanceof IndexedStringMap ? (IndexedStringMap) map 
> : new SortedArrayStringMap(map);
> +}
> +

The constructor should make a defensive copy of the constructor parameter 
regardless of whether it implements IndexedStringMap or not. 


> @Override
> public String[] getFormats() {
> return MapFormat.names();
> 

Re: Event batch

[Remko Popma]

I don’t think that creating a AbstractBatchedAppender/Manager would help with 
batching. 

Log4j2 currently already provides core batching support for appender 
implementors with the `LogEvent.endOfBatch` attribute. 

LogEvent producers, if they know that more events will follow, should set this 
attribute to `false` in the produced events. Conversely, when they know they 
have reached the end of a sequence of events they should set this attribute to 
`true`. 

LogEvent consumers should monitor this attribute and postpone expensive 
operations like flushing a buffer to disk or committing a database transaction 
until they see an event with `endOfBatch=true`, or until they run out of buffer 
space, whichever comes first. 

This results in a very efficient style of batching known as “smart batching” 
(Google it for more details). 

Log4j2 internally uses this with async logging: with async logging, the 
“producer” is the async logging queue. The queue “knows“ whether it’s empty or 
whether more events will follow immediately and it will set the `endOfBatch` 
attribute accordingly. Appenders downstream from the async logging queue will 
flush their buffer when they see the end of a batch. 

Jochen, you can achieve your objective of efficiently logging a sequence or 
array of log events by setting the `endOfBatch` attribute to false on all but 
the last event. On the consumer side, you may buffer all incoming events until 
you see one with `endOfBatch=true`. 

I hope this helps. 

Remko 

(Shameless plug) Every java main() method deserves http://picocli.info

> On Jan 10, 2018, at 6:14, Matt Sicker  wrote:
> 
> AbstractBatchedAppender/Manager

Re: Event batch

[Remko Popma]

Here is the smart batching link:
https://mechanical-sympathy.blogspot.jp/2011/10/smart-batching.html?m=1

Remko

(Shameless plug) Every java main() method deserves http://picocli.info

On Wed, Jan 10, 2018 at 8:14 Remko Popma  wrote:

> I don’t think that creating a AbstractBatchedAppender/Manager would help
> with batching.
>
> Log4j2 currently already provides core batching support for appender
> implementors with the `LogEvent.endOfBatch` attribute.
>
> LogEvent producers, if they know that more events will follow, should set
> this attribute to `false` in the produced events. Conversely, when they
> know they have reached the end of a sequence of events they should set this
> attribute to `true`.
>
> LogEvent consumers should monitor this attribute and postpone expensive
> operations like flushing a buffer to disk or committing a database
> transaction until they see an event with `endOfBatch=true`, or until they
> run out of buffer space, whichever comes first.
>
> This results in a very efficient style of batching known as “smart
> batching” (Google it for more details).
>
> Log4j2 internally uses this with async logging: with async logging, the
> “producer” is the async logging queue. The queue “knows“ whether it’s empty
> or whether more events will follow immediately and it will set the
> `endOfBatch` attribute accordingly. Appenders downstream from the async
> logging queue will flush their buffer when they see the end of a batch.
>
> Jochen, you can achieve your objective of efficiently logging a sequence
> or array of log events by setting the `endOfBatch` attribute to false on
> all but the last event. On the consumer side, you may buffer all incoming
> events until you see one with `endOfBatch=true`.
>
> I hope this helps.
>
> Remko
>
> (Shameless plug) Every java main() method deserves http://picocli.info
>
> > On Jan 10, 2018, at 6:14, Matt Sicker  wrote:
> >
> > AbstractBatchedAppender/Manager
>

Re: Event batch

[Remko Popma]

Yes, all async logging, either with AsyncAppender or with Async Loggers will 
set `endOfBatch` to true on all events where the queue becomes empty. 

(Shameless plug) Every java main() method deserves http://picocli.info

> On Jan 10, 2018, at 19:17, Mikael Ståldal  wrote:
> 
> And the same applies to AsyncAppender, right?
> 
>> On 2018-01-10 00:14, Remko Popma wrote:
>> Log4j2 internally uses this with async logging: with async logging, the 
>> “producer” is the async logging queue. The queue “knows“ whether it’s empty 
>> or whether more events will follow immediately and it will set the 
>> `endOfBatch` attribute accordingly. Appenders downstream from the async 
>> logging queue will flush their buffer when they see the end of a batch.

Re: [log4j] MongoDB Appender changes heads up.

[Remko Popma]

No objection, but please do this in a way that existing users of this appender 
are not affected. 

So if the new behavior is incompatible with the current behavior, then the new 
behavior should be switched on explicitly in configuration. 

Remko 

(Shameless plug) Every java main() method deserves http://picocli.info

> On Jan 11, 2018, at 7:49, Gary Gregory  wrote:
> 
> Hi All:
> 
> I need for the MongoDB Appender to behave similarly to the JMS Appender
> regarding MapMessages.
> 
> What I plan on doing:
> 
> Like with the JMS Appender, if the MongoDB element contains a child
> MessageLayout element, the MongoDB appender will apply this layout.
> 
> Like with the JMS Appender, my goal is to let a MapMessage be converted to
> a MongbDB object with key and values from the MapMessage, not from the
> LogEvent.
> 
> I will create a Jira.
> 
> Gary

Re: [log4j] Move JDBC appender to own module?

[Remko Popma]

How about moving all of these (generic database support, jdbc and jpa) together 
into a single separate module? 

Something like:

log4j-db 

I don’t see much value into splitting them up further, but perhaps that’s just 
me.

Remko

(Shameless plug) Every java main() method deserves http://picocli.info

> On Jan 13, 2018, at 13:16, Gary Gregory  wrote:
> 
> Hi All:
> 
> I wonder if we should move the JDBC Appender to its own module.
> 
> Also wondering how we would then slice and dice the generic database
> support and the JPA Appender:
> 
> - log4j-db
> - log4j-jdbc
> - log4j-jpa
> 
> Those would all be small modules...
> 
> ?
> 
> Thank you,
> Gary

Re: [log4j] Move JDBC appender to own module?

[Remko Popma]

Okay perhaps just two modules then?

By the way, I have work in progress on the high-precision time stamps that 
would be impacted by this. I would like to avoid the merge conflict by 
postponing this module breakdown until that is merged. Is that possible?

(Shameless plug) Every java main() method deserves http://picocli.info

> On Jan 13, 2018, at 14:33, Gary Gregory  wrote:
> 
> The reason to split out JPA would be to avoid bringing in the dependency to
> javax.persistenance which is not in the JRE. The JDBC API OTOH is in the
> JRE.
> 
> Gary
> 
>> On Fri, Jan 12, 2018 at 10:14 PM, Remko Popma  wrote:
>> 
>> How about moving all of these (generic database support, jdbc and jpa)
>> together into a single separate module?
>> 
>> Something like:
>> 
>> log4j-db
>> 
>> I don’t see much value into splitting them up further, but perhaps that’s
>> just me.
>> 
>> Remko
>> 
>> (Shameless plug) Every java main() method deserves http://picocli.info
>> 
>>> On Jan 13, 2018, at 13:16, Gary Gregory  wrote:
>>> 
>>> Hi All:
>>> 
>>> I wonder if we should move the JDBC Appender to its own module.
>>> 
>>> Also wondering how we would then slice and dice the generic database
>>> support and the JPA Appender:
>>> 
>>> - log4j-db
>>> - log4j-jdbc
>>> - log4j-jpa
>>> 
>>> Those would all be small modules...
>>> 
>>> ?
>>> 
>>> Thank you,
>>> Gary
>> 

Re: [log4j] Move JDBC appender to own module?

[Remko Popma]

I meant to keep the jdbc and the generic db package together.

log4j-db:  generic db + jdbc
log4j-jpa: requires javax.persistance

We can also keep all of these in a single module `log4j-db` with an
optional dependency on javax.persistance.

More modules gives more flexibility but also more complexity, so I lean
towards keeping things together where possible until the flexibility is
really needed.



On Sat, Jan 13, 2018 at 4:38 PM, Gary Gregory 
wrote:

> I won't touch the modules. I think we need hash it out a little more and
> get a consensus.
>
> If there are 2 modules: JPA and JDBC, then the generic .db package needs to
> stay in log4j-core. Which would be OK for now.
>
> Gary
>
> On Fri, Jan 12, 2018 at 11:16 PM, Remko Popma 
> wrote:
>
> > Okay perhaps just two modules then?
> >
> > By the way, I have work in progress on the high-precision time stamps
> that
> > would be impacted by this. I would like to avoid the merge conflict by
> > postponing this module breakdown until that is merged. Is that possible?
> >
> > (Shameless plug) Every java main() method deserves http://picocli.info
> >
> > > On Jan 13, 2018, at 14:33, Gary Gregory 
> wrote:
> > >
> > > The reason to split out JPA would be to avoid bringing in the
> dependency
> > to
> > > javax.persistenance which is not in the JRE. The JDBC API OTOH is in
> the
> > > JRE.
> > >
> > > Gary
> > >
> > >> On Fri, Jan 12, 2018 at 10:14 PM, Remko Popma 
> > wrote:
> > >>
> > >> How about moving all of these (generic database support, jdbc and jpa)
> > >> together into a single separate module?
> > >>
> > >> Something like:
> > >>
> > >> log4j-db
> > >>
> > >> I don’t see much value into splitting them up further, but perhaps
> > that’s
> > >> just me.
> > >>
> > >> Remko
> > >>
> > >> (Shameless plug) Every java main() method deserves
> http://picocli.info
> > >>
> > >>> On Jan 13, 2018, at 13:16, Gary Gregory 
> > wrote:
> > >>>
> > >>> Hi All:
> > >>>
> > >>> I wonder if we should move the JDBC Appender to its own module.
> > >>>
> > >>> Also wondering how we would then slice and dice the generic database
> > >>> support and the JPA Appender:
> > >>>
> > >>> - log4j-db
> > >>> - log4j-jdbc
> > >>> - log4j-jpa
> > >>>
> > >>> Those would all be small modules...
> > >>>
> > >>> ?
> > >>>
> > >>> Thank you,
> > >>> Gary
> > >>
> >
>

Re: [log4j] Move JDBC appender to own module?

[Remko Popma]

JDCB doesn’t require an external dependency so why split it off into a separate 
module?

This page is outdated now:
https://logging.apache.org/log4j/2.x/runtime-dependencies.html



(Shameless plug) Every java main() method deserves http://picocli.info

> On Jan 14, 2018, at 3:43, Gary Gregory  wrote:
> 
> I created:
> 
> LOG4J2-2188 <https://issues.apache.org/jira/browse/LOG4J2-2188>
> 
> Split off JPA support into a new module log4j-jpa
> <https://issues.apache.org/jira/browse/LOG4J2-2188>
> 
> LOG4J2-2187 <https://issues.apache.org/jira/browse/LOG4J2-2187>
> 
> Split off JDBC support into a new module log4j-jdbc
> <https://issues.apache.org/jira/browse/LOG4J2-2187>
> Gary
> 
> On Sat, Jan 13, 2018 at 10:54 AM, Gary Gregory 
> wrote:
> 
>> 
>> 
>> On Jan 13, 2018 09:54, "Mikael Ståldal"  wrote:
>> 
>> As usual, I think we should avoid optional dependencies.
>> 
>> 
>> That means more modules.
>> 
>> Maybe we can start small here with a log4j-jpa module.
>> 
>> Gary
>> 
>> 
>> 
>> 
>>>> On 2018-01-13 10:16, Remko Popma wrote:
>>> 
>>> I meant to keep the jdbc and the generic db package together.
>>> 
>>> log4j-db:  generic db + jdbc
>>> log4j-jpa: requires javax.persistance
>>> 
>>> We can also keep all of these in a single module `log4j-db` with an
>>> optional dependency on javax.persistance.
>>> 
>>> More modules gives more flexibility but also more complexity, so I lean
>>> towards keeping things together where possible until the flexibility is
>>> really needed.
>> 
>> 

Re: [Log4j] Release plan?

[Remko Popma]

I’m hoping to complete https://issues.apache.org/jira/browse/LOG4J2-1883 in a 
week or two. 

That would bring a new log4j-core-java9 module and should probably be called 
2.11 if that can be included. 

Remko 

(Shameless plug) Every java main() method deserves http://picocli.info

> On Jan 14, 2018, at 20:25, Mikael Ståldal  wrote:
> 
> Will the next release be 2.10.1 or 2.11.0?
> 
> If 2.10.1, I start seeing a few new features in master branch that might not 
> be appropriate for a patch release.

Re: MongoDB, Cassandra, CouchDB, Liquibase, Flume

[Remko Popma]

No objection from me. 

Let’s make it a community goal to speed up the Log4j2 build. We should start by 
creating  a JIRA epic (it’s in maintenance now but when it’s back up).

(Shameless plug) Every java main() method deserves http://picocli.info

> On Jan 15, 2018, at 6:11, Ralph Goers  wrote:
> 
> I don’t believe the components listed in the subject line should be part of 
> the main flume build and would like to see them moved to the 
> logging-log4j-plugins project. The only problem is that the modules and maven 
> coordinates need to change since the version numbers will be going backwards. 
> I would propose we solve that by adding “plugin” to the jar names.
> 
> Ralph

Re: [Log4j] Binary layout

[Remko Popma]

Doesn't that depend on the generic type T of the Layout?
For example, MessageLayout extends AbstractLayout returns a
Message instance.
You could return a ByteBuffer, but generally for an efficient binary layout
I would look at the encode method instead.

On Tue, Jan 16, 2018 at 11:45 PM, Mikael Ståldal  wrote:

> How is a binary layout (extending AbstractLayout) supposed to implement
> the toSerializable method in the Layout interface?
>
> Why is that method there?
>
>

Re: [Log4j] Binary layout

[Remko Popma]

I think what Mikael meant is that Serializable is just a marker interface
that does not provide any guidance on what methods to call on it to turn
the result into bytes.
Unless we want to use java serialization, and I presume one of the main
reasons for creating a custom binary layout (other than performance) is to
avoid java serialization and the associated security risks.

How should a custom binary layout turn the result of `toSerializable` into
bytes without using java serialization? - may be the question that Mikael
is trying to answer. Correct me if I'm wrong,  Mikael.
I think a custom binary layout should just return the bytes it produced
itself. Either as a byte array or as a ByteBuffer.


On Wed, Jan 17, 2018 at 12:23 AM, Ralph Goers 
wrote:

> I think MessageLayout is a special case as it only returns the message
> portion of the LogEvent. Most Layouts return all of the LogEvent
> attributes. Even so, you could have AbstractLayout if you
> wanted the serialized version of the LogEvent. It can also be anything else
> that implements Serializable.
>
> Ralph
>
> > On Jan 16, 2018, at 8:06 AM, Remko Popma  wrote:
> >
> > Doesn't that depend on the generic type T of the Layout?
> > For example, MessageLayout extends AbstractLayout returns a
> > Message instance.
> > You could return a ByteBuffer, but generally for an efficient binary
> layout
> > I would look at the encode method instead.
> >
> > On Tue, Jan 16, 2018 at 11:45 PM, Mikael Ståldal 
> wrote:
> >
> >> How is a binary layout (extending AbstractLayout) supposed to implement
> >> the toSerializable method in the Layout interface?
> >>
> >> Why is that method there?
> >>
> >>
>
>
>

Re: logging-log4j2 git commit: [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling through Apache Commons DBCP 2.

[Remko Popma]

Reducing the time it takes to run the core tests is key. 

It would be great if we could specify which tests should be forked, and run the 
rest non-forked. Perhaps we need to enhance Surefire. Or can JUnit 5 help 
somehow (haven’t looked at it yet)? 

Remko 

(Shameless plug) Every java main() method deserves http://picocli.info

> On Jan 20, 2018, at 8:21, Matt Sicker  wrote:
> 
> I'd much prefer if we had a leaner core repo for more frequent releases
> (RERO after all). I've only done the release process a couple times, but
> Ralph is right: more modules means a larger pain in the ass. The other
> thing we could really benefit from would be speeding up unit tests. If we
> can run them without forking, I think that would help a lot in execution
> speedups. I'm not sure if using Gradle or something else instead of Maven
> would speed things up there, but I believe there are more low hanging fruit
> we could handle before something that drastic.
> 
>> On 18 January 2018 at 23:31, Ralph Goers  wrote:
>> 
>> Gary, I am complaining because I perform the releases. You never have. We
>> keep adding more and more crap to the build and it keeps taking longer and
>> longer. Af far as I am concerned that is a valid technical reason.
>> 
>> My -1 stands.
>> 
>> Ralph
>> 
>> 
>>> On Jan 18, 2018, at 10:24 PM, Gary Gregory 
>> wrote:
>>> 
>>> On Thu, Jan 18, 2018 at 10:20 PM, Ralph Goers <
>> ralph.go...@dslextreme.com>
>>> wrote:
>>> 
 OK, but that doesn’t resolve the initial problem. The log4j 2 project is
 too large.
 
>>> 
>>> From what I've experienced, folks complain about the size of the api and
>>> core jars, not the Maven project.
>>> 
>>> What is the target size/metric if it is currently "too large"? ;-)
>>> 
>>> Gary
>>> 
>>> 
 Ralph
 
> On Jan 18, 2018, at 10:15 PM, Gary Gregory 
 wrote:
> 
> On Thu, Jan 18, 2018 at 9:43 PM, Ralph Goers <
>> ralph.go...@dslextreme.com
> 
> wrote:
> 
>> In addition, the build is now failing to compile on Jenkins.
>> 
> 
> Oops, please accept my apologies. I got caught by the Eclipse compiler
> being more forgiving (or more powerful) than the Oracle compiler in the
> generics department. All of that despite the Maven partial builds I
>> ran.
 I
> must have not run the clean goal or some-such.
> 
> Gary
> 
> 
>> Ralph
>> 
>>> On Jan 18, 2018, at 9:28 PM, Ralph Goers >> 
>> wrote:
>>> 
>>> -1
>>> 
>>> Please revert and move this to the log4j plugins project.
>>> 
>>> Ralph
>>> 
 On Jan 18, 2018, at 8:54 PM, ggreg...@apache.org wrote:
 
 Repository: logging-log4j2
 Updated Branches:
 refs/heads/master bb6fcd09e -> 639f093b8
 
 
 [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling
 through
 Apache Commons DBCP 2.
 
 Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
 Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/
>> commit/639f093b
 Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/
>> 639f093b
 Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/
>> 639f093b
 
 Branch: refs/heads/master
 Commit: 639f093b8103df2c2eda8d62fd12d7619d98ac04
 Parents: bb6fcd0
 Author: Gary Gregory 
 Authored: Thu Jan 18 20:54:47 2018 -0700
 Committer: Gary Gregory 
 Committed: Thu Jan 18 20:54:47 2018 -0700
 
 
 --
 log4j-jdbc-dbcp2/pom.xml| 170
>> +++
 .../db/jdbc/PoolingDriverConnectionSource.java  | 155
 +
 log4j-jdbc-dbcp2/src/site/manual/index.md   |  35 
 log4j-jdbc-dbcp2/src/site/site.xml  |  52 ++
 .../jdbc/PoolingDriverConnectionSourceTest.java |  96 +++
 pom.xml |   1 +
 src/changes/changes.xml |   3 +
 src/site/xdoc/manual/appenders.xml  |  28 ++-
 8 files changed, 537 insertions(+), 3 deletions(-)
 
 --
 
 
 http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/
>> 639f093b/log4j-jdbc-dbcp2/pom.xml
 
 --
 diff --git a/log4j-jdbc-dbcp2/pom.xml b/log4j-jdbc-dbcp2/pom.xml
 new file mode 100644
 index 000..18e0e86
 --- /dev/null
 +++ b/log4j-jdbc-dbcp2/pom.xml
 @@ -0,0 +1,170 @@
 +
 +
 +
 +http://maven.apache.org/POM/4.0.0"; xmlns:xsi="
>> http://www.w3.org/2001/XMLSchema-instance";
 + 

Re: logging-log4j2 git commit: [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling through Apache Commons DBCP 2.

[Remko Popma]

Mikael, Ralph,

Have you really thought through the implications of having a separate
repository for each module? The overhead is very large!

It would mean:
* a separate website for each repo (our current Log4j2 website only knows
about the modules in the logging-log4j project).
* a separate release and release vote would need to be performed *for each
repo*. This process is so heavy that we only do it once a month for Log4j2.
Imagine doing this 10 times when we have 10 modules each in separate repos.
* synchronizing with the main Log4j project becomes checking and updating
10 projects instead of one.

All of these concerns already hold for a single log4j-plugins project, they
just multiply for each additional repo.

All,

Gary does have a point when he says we don’t have a clear plan for managing
the log4j-plugins repo. Who is going to check that the plugins still
compile after a Log4j2 release? Are we going to release a new plugins
version for each Log4j2 release? If not, when _will_ we release new
log4j-plugins versions?

Given our terrible track record for the log4j-tools project since we moved
TcpServer etc. into that repo (nobody showing interest to do the work to
release it), I agree these are valid concerns.

On the other hand, I also completely agree with Ralph that the build takes
much too long. Something needs to be done and Ralph is clearly signalling
he won't have this problem ignored any longer.

I'm not sure that moving things out of the main repo is the only solution
to make the build faster. If it really is the *only* solution, then fine.
But be mindful we are trading one problem for a set of new ones, and, just
like we can't ignore the slow build problem, we also cannot ignore the new
problems introduced by this solution (keeping the new repo(s) in sync,
building new web sites and linking them into the main site, release timing
etc).

PROPOSAL:
I think all of us should take responsibility for speeding up the build and
make it our first priority.
If you want to add anything to the main project, *first reduce the build
duration*. First find an existing test and speed it up. Only then add new
stuff, keeping the total build time to the same or less than it was
before.  Building core and running its tests used to take 8 minutes. Now it
takes 19:10 (`mvn clean package` on the whole project takes 24:22).

The core tests clearly are a major bottleneck.

Speeding up the core tests is something we can all work on. Can we split
the tests into a set that can be run multi-threaded in parallel (fastest),
a different set that does not require forking (fast) and a third set that
requires forking for every test (slowest)?

On the other hand, if we want to move things out of the main repo we need a
plan for the new repo(s). There is a one-time work of setting up web sites
and integrating them with the main site, but on an ongoing basis we need
some way to verify that a change in log4j-core did not break any plugins,
and agree to do a plugins release if it did break something.

Remko


On Sun, Jan 21, 2018 at 2:27 Ralph Goers  wrote:

> I am fine with doing that but we would still want a way to get to all the
> plugin sites from the log4j web site. Maven does that and maintains a list
> at https://maven.apache.org/plugins/ .
> I think the easiest way to manage a page like that would to have it be a
> separate page in the CMS that the log4j site links to.
>
> Ralph
>
> > On Jan 20, 2018, at 8:29 AM, Mikael Ståldal  wrote:
> >
> > As I wrote recently, I don't think that having a kitchen-sink plugins
> repository is a good way to solve this. Eventually that repository will get
> too big.
> >
> > It's better to create a new repository for each new module (or possibly
> for a couple of related modules, but they should be more related than just
> being Log4j plugins).
> >
> >
> > On 2018-01-19 06:31, Ralph Goers wrote:
> >> Gary, I am complaining because I perform the releases. You never have.
> We keep adding more and more crap to the build and it keeps taking longer
> and longer. Af far as I am concerned that is a valid technical reason.
> >> My -1 stands.
> >> Ralph
> >>> On Jan 18, 2018, at 10:24 PM, Gary Gregory 
> wrote:
> >>>
> >>> On Thu, Jan 18, 2018 at 10:20 PM, Ralph Goers <
> ralph.go...@dslextreme.com>
> >>> wrote:
> >>>
>  OK, but that doesn’t resolve the initial problem. The log4j 2 project
> is
>  too large.
> 
> >>>
> >>> From what I've experienced, folks complain about the size of the api
> and
> >>> core jars, not the Maven project.
> >>>
> >>> What is the target size/metric if it is currently "too large"? ;-)
> >>>
> >>> Gary
> >>>
> >>>
>  Ralph
> 
> > On Jan 18, 2018, at 10:15 PM, Gary Gregory 
>  wrote:
> >
> > On Thu, Jan 18, 2018 at 9:43 PM, Ralph Goers <
> ralph.go...@dslextreme.com
> >
> > wrote:
> >
> >> In addition, the build is now failing to compile on Jenkins.
> >>
> >
> > Oops, plea

Re: logging-log4j2 git commit: [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling through Apache Commons DBCP 2.

[Remko Popma]

This looks promising:
http://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html
(especially the @NotThreadSafe annotation, potentially in combination with
JUnit Suits)


On Sun, Jan 21, 2018 at 13:12 Remko Popma  wrote:

> Mikael, Ralph,
>
> Have you really thought through the implications of having a separate
> repository for each module? The overhead is very large!
>
> It would mean:
> * a separate website for each repo (our current Log4j2 website only knows
> about the modules in the logging-log4j project).
> * a separate release and release vote would need to be performed *for each
> repo*. This process is so heavy that we only do it once a month for Log4j2.
> Imagine doing this 10 times when we have 10 modules each in separate repos.
> * synchronizing with the main Log4j project becomes checking and updating
> 10 projects instead of one.
>
> All of these concerns already hold for a single log4j-plugins project,
> they just multiply for each additional repo.
>
> All,
>
> Gary does have a point when he says we don’t have a clear plan for
> managing the log4j-plugins repo. Who is going to check that the plugins
> still compile after a Log4j2 release? Are we going to release a new plugins
> version for each Log4j2 release? If not, when _will_ we release new
> log4j-plugins versions?
>
> Given our terrible track record for the log4j-tools project since we
> moved TcpServer etc. into that repo (nobody showing interest to do the
> work to release it), I agree these are valid concerns.
>
> On the other hand, I also completely agree with Ralph that the build takes
> much too long. Something needs to be done and Ralph is clearly signalling
> he won't have this problem ignored any longer.
>
> I'm not sure that moving things out of the main repo is the only solution
> to make the build faster. If it really is the *only* solution, then fine.
> But be mindful we are trading one problem for a set of new ones, and, just
> like we can't ignore the slow build problem, we also cannot ignore the new
> problems introduced by this solution (keeping the new repo(s) in sync,
> building new web sites and linking them into the main site, release timing
> etc).
>
> PROPOSAL:
> I think all of us should take responsibility for speeding up the build and
> make it our first priority.
> If you want to add anything to the main project, *first reduce the build
> duration*. First find an existing test and speed it up. Only then add new
> stuff, keeping the total build time to the same or less than it was
> before.  Building core and running its tests used to take 8 minutes. Now it
> takes 19:10 (`mvn clean package` on the whole project takes 24:22).
>
> The core tests clearly are a major bottleneck.
>
> Speeding up the core tests is something we can all work on. Can we split
> the tests into a set that can be run multi-threaded in parallel (fastest),
> a different set that does not require forking (fast) and a third set that
> requires forking for every test (slowest)?
>
> On the other hand, if we want to move things out of the main repo we need
> a plan for the new repo(s). There is a one-time work of setting up web
> sites and integrating them with the main site, but on an ongoing basis we
> need some way to verify that a change in log4j-core did not break any
> plugins, and agree to do a plugins release if it did break something.
>
> Remko
>
>
> On Sun, Jan 21, 2018 at 2:27 Ralph Goers 
> wrote:
>
>> I am fine with doing that but we would still want a way to get to all the
>> plugin sites from the log4j web site. Maven does that and maintains a list
>> at https://maven.apache.org/plugins/ <https://maven.apache.org/plugins/>.
>> I think the easiest way to manage a page like that would to have it be a
>> separate page in the CMS that the log4j site links to.
>>
>> Ralph
>>
>> > On Jan 20, 2018, at 8:29 AM, Mikael Ståldal  wrote:
>> >
>> > As I wrote recently, I don't think that having a kitchen-sink plugins
>> repository is a good way to solve this. Eventually that repository will get
>> too big.
>> >
>> > It's better to create a new repository for each new module (or possibly
>> for a couple of related modules, but they should be more related than just
>> being Log4j plugins).
>> >
>> >
>> > On 2018-01-19 06:31, Ralph Goers wrote:
>> >> Gary, I am complaining because I perform the releases. You never have.
>> We keep adding more and more crap to the build and it keeps taking longer
>> and longer. Af far as I am concerned that is a valid technical reason.
>> >> My -1 stands.
&

Re: [log4j] The shape of Log4j

[Remko Popma]

Log4j2 is not like Maven. Maven (I assume) has a plugin API. Log4j2 modules 
depend on the internals of log4j-core. 

I agree with Gary that not being able to verify that a core change doesn’t 
break any modules when they live outside the main project is a valid concern. 

Why are we talking about modules and repos when the issue is that it takes too 
long to do a release? Maven reports most modules as taking a handful of seconds 
to build. 

I keep thinking:

1. We’re running the tests twice during a release. Let’s change this. 
Logically, once should be enough. What prevents us from doing this?

2. Core tests take unnecessarily long. By running some tests in parallel and 
some other tests without forking I have hope we can run all core tests in ~15 
minutes. 

Won’t those two changes be much more impactful in reducing the release time 
than any amount of module or repo reshuffling?

Remko 

(Shameless plug) Every java main() method deserves http://picocli.info

> On Jan 22, 2018, at 8:14, Ralph Goers  wrote:
> 
> I am very much against the idea of a single repo. Yes, you can have multiple 
> projects in the repo but I am not sure how that can be sanely released. I 
> much prefer the model that Maven has taken. They are now using gitbox [1] 
> which seems to allow GitHub to be the primary repo. Every Maven plugin is 
> individually released. Scroll down the link below to the Maven section and 
> you can see all the plugin repos.
> 
> The upside to this is that it are: 
>1. It is far easier to perform releases of the individual components. 
>2. It is much easier to accept plugin contributions.
> The downsides are:
>1. A page like https://maven.apache.org/plugins/ 
>  is needed to keep track of the plugin 
> versions.
>2. It could make sense to have log4j-parent and log4j-bom projects. The 
> first to help keep the builds similar and the second to help customers pick 
> up the latest versions. 
> 
> Ralph
> 
> [1] https://gitbox.apache.org/repos/asf 
> 
>> On Jan 21, 2018, at 8:55 AM, Gary Gregory  wrote:
>> 
>> Hi All,
>> 
>> I am writing this to in an effort to understand how we can manage and grow
>> Log4j. I use the term 'grow' not in the 'bigger is better' sense but more
>> in the maturing sense.
>> 
>> I am prompted to write this by Ralph's comment that log4j-core and the main
>> repo is too big and that releases take too long make, partially prompted by
>> my addition of a new module called log4j-jdbc-dbcp2 which currently
>> contains one small class with a dependency on Apache Commons DBCP 2.
>> 
>> I would like to express my gratitude at Ralph's efforts to revitalized
>> Log4j and performing most release management duties. Thank you Ralph!
>> 
>> I can see two main orthogonal issues:
>> - The size of the git repo.
>> - The size of the log4j-core module.
>> 
>> Ralph has proposed that new modules like log4j-jdbc-dbcp2 be moved to
>> another 'plugin' repo.
>> 
>> I really dislike this idea:
>> - The plugin repo has never been released. Not that one releases a repo but
>> you get the point.
>> - How do you keep things in sync between repos and code when we have no
>> official 'core' SPI.
>> 
>> For my money, we should keep _everything_ in one repo. Good enough for
>> Google, so good enough for me. What we release out of that repo is a
>> different story and what I would like to discuss next.
>> 
>> This is not the same as Maven plugins IMO but the case could be made for it
>> I suppose where a lot/most plugins live in their own repos. It is not the
>> same as with Maven IMO because our plugins rely on log4j-core and it's
>> guts, for which we only make loose compatibility guarantees -- as opposed
>> to log4j-core where we are strict(er). Maven OTOH, has a API for plugin
>> auteurs.
>> 
>> For example, log4j-jdbc-dbcp2 replies on the guts of log4j-core and we have
>> no 'official' core SPI, so splitting it off into a separate repo would
>> greatly increase the risk of it falling out of sync. It is just so much
>> more easier to maintain when it is all in one repo.
>> 
>> My proposal is to:
>> 
>> - Put everything back into one repo (Chainsaw too?)
>> - Define a core SPI for plugin writers where we make some statement about
>> BC, more than the casual 'we try not break stuff.'
>> - Defining what Log4j project 'components' we have and release based on
>> that. For example, today, all of the main Log4j repo is one component with
>> many modules. Chainsaw would be another component of the Log4j project.
>> Maybe we need to redefine components: API, File, JDBC and so on. A
>> component can have one of more module
>> - Got for there.
>> 
>> Thoughts? Help me flush this out?
>> 
>> Thank you for reading!
>> Gary
> 

Re: [log4j] A better log4j2.debug

[Remko Popma]

Gary,

If you’re looking for a “to accomplish X, do Y”, see the FAQ. 
https://logging.apache.org/log4j/2.x/faq.html#troubleshooting

(Shameless plug) Every java main() method deserves http://picocli.info

> On Jan 23, 2018, at 5:46, Gary Gregory  wrote:
> 
> On Mon, Jan 22, 2018 at 12:49 PM, Ralph Goers 
> wrote:
> 
>> Properties on the command line should override configurations in files.
>> 
> 
> +1
> 
> Gary
> 
> 
>> Ralph
>> 
>>> On Jan 22, 2018, at 12:38 PM, Matt Sicker  wrote:
>>> 
>>> On 22 January 2018 at 13:22, Gary Gregory 
>> wrote:
 
 Yikes. What I want to do is use a -D on the command line instead of
>> editing
 the status attribute in an XML configuration file.
 
>>> 
>>> Right, that makes sense. Would this property override the config file or
>>> the other way around?
>>> 
>>> 
 The docs for log4j2.defaultStatusLevel and log4j2.statusLoggerLevel are
 very confusing IMO. I suppose I'll have to try both. Can these docs be
 improved with an intro sentence for each saying "To do X, use Y"?
 
>>> 
>>> Agreed. I'm not entirely sure what combo would make sense, so I'd
>> probably
>>> just set all three properties to be safe.
>>> 
>>> 
>>> --
>>> Matt Sicker 
>> 
>> 
>> 

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc2

[Remko Popma]

+1

(Shameless plug) Every java main() method deserves http://picocli.info

> On Jan 23, 2018, at 7:29, Matt Sicker  wrote:
> 
> I'll add my +1 from earlier. We still need another +1, though it's only
> been two days so far, so we still have time.
> 
>> On 20 January 2018 at 16:54, Matt Sicker  wrote:
>> 
>> I've committed the updated .asc files in revision 24339. MD5 and SHA-512
>> hashes are still the same.
>> 
>> Do note that you can also verify the git tag using the same gpg key via
>> this command:
>> 
>> git tag --verify chainsaw-2.0.0-rc2
>> 
>>> On 20 January 2018 at 16:47, Matt Sicker  wrote:
>>> 
>>> I didn't change my key (last 8 characters are the same as the short id).
>>> Looks like I might have signed it wrong.
>>> 
>>> On 20 January 2018 at 15:01, ralph.goers dslextreme.com <
>>> ralph.go...@dslextreme.com> wrote:
>>> 
 Did you use a new signing key? When I try to verify I get
 
 gpg --verify apache-chainsaw-2.0.0-bin.tar.gz.asc
 apache-chainsaw-2.0.0-bin.tar.gz
 gpg: Signature made Fri Nov 10 11:41:12 2017 MST
 gpg:using RSA key 9D0A56AAA0D60E0C0C7DCCC0B4C708
 93B62BABE8
 gpg: BAD signature from "Matthew Sicker (Signing Key) <
 mattsic...@apache.org>" [undefined]
 
 Ralph
 
 
 - Original Message -
 From: "Matt Sicker" 
 To: "Apache Logging Developers List" 
 Sent: Saturday, January 20, 2018 10:42:21 AM
 Subject: [VOTE] Release Apache Chainsaw 2.0.0-rc2
 
 This is a vote to release Apache Chainsaw 2.0.0-rc2
 
 Source and binary artifacts:
 
 https://dist.apache.org/repos/dist/dev/logging/chainsaw/
 
 Committed under SVN revision 24337.
 
 Site:
 
 http://musigma.org/chainsaw-site/
 https://github.com/jvz/chainsaw-site
 
 Git:
 
 https://git-wip-us.apache.org/repos/asf/logging-chainsaw.git
 tag: chainsaw-2.0.0-rc2 <
 https://git-wip-us.apache.org/repos/asf?p=logging-chainsaw.g
 it;a=tag;h=a9633a9bc4e7d635b893f7697e4a3dbae596795d
> 
 
 Artifacts signed by my key id 748F15B2CF9BA8F024155E6ED7C92B70FA1C814D.
 
 This vote will be open for at least 72 hours and requires at least 3 +1
 votes and no more -1 votes than +1 votes.
 
 --
 Matt Sicker 
 
 
>>> 
>>> 
>>> --
>>> Matt Sicker 
>>> 
>> 
>> 
>> 
>> --
>> Matt Sicker 
>> 
> 
> 
> 
> -- 
> Matt Sicker 

Re: [log4j] log4j-core test speed breakdown

[Remko Popma]

Nice!!

(Shameless plug) Every java main() method deserves http://picocli.info

> On Jan 23, 2018, at 14:25, Gary Gregory  wrote:
> 
> On Mon, Jan 22, 2018 at 9:45 PM, Gary Gregory 
> wrote:
> 
>> Hm, it already uses the mock stuff!
>> 
>> I reduced test delays in the MockProducer introduced in commit
>> 96436fb958ce1f1a3d4f0c951f556f0709c91b15 (by Mike) from 3 seconds to 50
>> milliseconds. This reduces running this test case from 43 to 3 seconds.
>> Let's watch this test in Jenkins to make sure it still passes. It runs fine
>> over and over in Eclipse and with 'mvn test -pl log4j-core
>> -Dtest=KafkaAppenderTest'.
>> 
>> If Jenkins is happy that's 40 seconds * test_runs shaved off the build.
>> 
> 
> It worked and did not break anything:
> https://builds.apache.org/user/ggregory/my-views/view/Logging/job/Log4j%202.x/3317/
> 
> Gary
> 
> 
>> 
>> Gary
>> 
>>> On Mon, Jan 22, 2018 at 1:11 PM, Matt Sicker  wrote:
>>> 
>>> The Kafka test could probably be rewritten to use the
>>> MockProducer/MockConsumer classes instead of presumably embedding Kafka.
>>> 
 On 22 January 2018 at 14:08, Gary Gregory  wrote:
 
 Hi All:
 
 Here are some number based on
 https://builds.apache.org/user/ggregory/my-views/view/Logging/job/Log4j
 2.x/3315. There are some obvious low-hanging fruits.
 
 43.078  org.apache.logging.log4j.core.appender.mom.kafka.KafkaAppend
>>> erTest
 33.799
 org.apache.logging.log4j.core.appender.routing.
 RoutingAppenderWithPurgingTest
 20.638  org.apache.logging.log4j.core.appender.FileAppenderPermissio
>>> nsTest
 15.375
 org.apache.logging.log4j.core.appender.rolling.RollingAppenderSizeTest
 14.752
 org.apache.logging.log4j.core.appender.rolling.
 RollingAppenderCronOnceADayTest
 12.075  org.apache.logging.log4j.core.GcFreeMixedSyncAyncLoggingTest
 10.031  org.apache.logging.log4j.core.async.AsyncRootReloadTest
 9.835  org.apache.logging.log4j.core.GcFreeAsynchronousLoggingTest
 9.295
 org.apache.logging.log4j.core.appender.rolling.RollingAppenderCronTest
 9.142  org.apache.logging.log4j.core.GcFreeSynchronousLoggingTest
 8.777  org.apache.logging.log4j.core.LoggerTest
 8.347  org.apache.logging.log4j.core.config.TestConfigurator
 8.186  org.apache.logging.log4j.core.config.ReconfigurationDeadlockTest
 8.085  org.apache.logging.log4j.core.util.WatchManagerTest
 6.915  org.apache.logging.log4j.core.filter.BurstFilterTest
 6.517
 org.apache.logging.log4j.core.appender.rolling.
 RollingAppenderCronEvery2DirectTest
 6.421
 org.apache.logging.log4j.core.appender.rolling.
 RollingAppenderCronEvery2Test
 6.11  org.apache.logging.log4j.core.PropertiesFileConfigTest
 6.026  org.apache.logging.log4j.core.layout.CsvParameterLayoutTest
 5.922
 org.apache.logging.log4j.core.appender.rolling.
 RollingAppenderSizeNoCompressTest
 5.742
 org.apache.logging.log4j.core.util.datetime.FastDateParser_
 TimeZoneStrategyTest
 5.534  org.apache.logging.log4j.core.appender.db.jpa.JpaH2AppenderTest
 5.456  org.apache.logging.log4j.core.appender.db.jpa.JpaHsqldbAppen
>>> derTest
 4.315  org.apache.logging.log4j.core.appender.TlsSyslogAppenderTest
 3.536
 org.apache.logging.log4j.core.appender.rolling.
 RollingAppenderTempCompressedFilePatternTest
 3.475
 org.apache.logging.log4j.core.appender.rolling.
 RollingAppenderSizeCompressPermissionsTest
 3.331  org.apache.logging.log4j.core.appender.HttpAppenderTest
 3.256
 org.apache.logging.log4j.core.appender.routing.
 DefaultRouteScriptAppenderTest
 2.993  org.apache.logging.log4j.core.util.datetime.FixedDateFormatTest
 2.982
 org.apache.logging.log4j.core.appender.routing.RoutesScriptA
>>> ppenderTest
 2.96  org.apache.logging.log4j.core.util.datetime.FastDateParserTest
 2.562  org.apache.logging.log4j.core.tools.GenerateExtendedLoggerTest
 2.547  org.apache.logging.log4j.core.appender.XmlCompleteFileAppend
>>> erTest
 2.398
 org.apache.logging.log4j.core.appender.rolling.
 RollingAppenderDeleteScriptFri13thTest
 2.394
 org.apache.logging.log4j.core.appender.rolling.RollingAppenderTimeTest
 2.381
 org.apache.logging.log4j.core.appender.rolling.
 RollingAppenderDeleteScriptTest
 2.378  org.apache.logging.log4j.core.appender.SocketAppenderBufferS
>>> izeTest
 2.26  org.apache.logging.log4j.core.tools.GenerateCustomLoggerTest
 2.19  org.apache.logging.log4j.core.appender.ScriptAppenderSelectorTest
 2.061  org.apache.logging.log4j.core.appender.AsyncAppenderTest
 1.996  org.apache.logging.log4j.core.config.ConfigurationTest
 1.993
 org.apache.logging.log4j.core.appender.rolling.
 RollingAppenderTimeAndSizeDirectTest
 1.823
 org.apache.logging.log4j.core.config.plugins.util.
 PluginManagerPackagesTest
 1.778  org.apache.logging.log4j.core.impl.ThrowableProxyTest
>

Re: [log4j] The shape of Log4j

[Remko Popma]

> On Jan 23, 2018, at 7:29, Ralph Goers  wrote:
> 
> IMO the main repo should contain the stuff 80% (or more) of our user’s use 
> and the stuff that is common across all plugins.  So the file appenders and 
> console appenders all belong, probably most of the existing lookups and 
> filters. Since the Syslog Appender probably fits in I would also keep the 
> socket appenders as well.  
> 
> If it was up to me I would move the following Appenders: Cassandra, Flume, 
> JDBC, JMS, JPA, HTTP, Kafka, NoSQL, SMTP, ZeroMQ/JeroMQ, CouchDB, MongoDB.
> In addition to those I would move the taglib, imx-gui and samples modules and 
> possibly the perf module.

Two questions:
1. How much faster do you estimate this will make the build?
2. How do we verify that changes in log4j-core didn’t break any of the plugins?


About the perf module:
If you take perf out of the main repo we will only be able to create 
performance tests against pre-built binaries. This is impractical and the added 
overhead likely means performance testing becomes too cumbersome for anyone to 
do it any more. I think that’s a bad idea. 


> Although it is probably lightly used I would consider keeping the iostreams 
> module, although to be honest I am not sure why it isn’t part of the api 
> module.
> 
> Ralph
> 
>> On Jan 22, 2018, at 2:19 PM, Gary Gregory  wrote:
>> 
>> I'm curious: What is threshold where it would be OK to add stuff to the
>> main repo?
>> 
>> Gary
>> 
>> On Mon, Jan 22, 2018 at 12:48 PM, Ralph Goers 
>> wrote:
>> 
>>> I don’t see why this work would require 3.0 as we aren’t planning on
>>> breaking any contracts to do this.
>>> 
>>> As I’ve said, I am not tied to each plugin having its own repo. I am OK
>>> with these options; a) each plugin has its own repo and site and is
>>> released independently, b) we use the plugins repo and move all the more
>>> lightly used components there. It would have its own site, or c) we group
>>> plugins by how they are related (RDBMS, NoSQL, “Transport” (Flume or
>>> similar) with each having its own site.
>>> 
>>> Obviously I do not consider continuing to add new plugins to the main
>>> build as one of the options.
>>> 
>>> Ralph
>>> 
 On Jan 22, 2018, at 12:36 PM, Matt Sicker  wrote:
 
 This whole conversation just reminds me of all the times in the past I
 suggested full modularization of the core API/SPI. I think such an effort
 would make sense in a 3.0 release.
 
 In 2.x, perhaps what we can do is define a stable plugin API based on
>>> what
 we already have. Since we're still supporting Java 7, I'd suggest we make
 abstract classes be the stable part of the API since we don't have
>>> default
 methods on interfaces here.
 
 And yes, the GitBox integration thing sounds neat, particularly for code
 review, though that's a separate topic entirely.
 
 On 22 January 2018 at 00:37, Gary Gregory 
>>> wrote:
 
> On Sun, Jan 21, 2018 at 4:14 PM, Ralph Goers <
>>> ralph.go...@dslextreme.com>
> wrote:
> 
>> I am very much against the idea of a single repo. Yes, you can have
>> multiple projects in the repo but I am not sure how that can be sanely
>> released. I much prefer the model that Maven has taken. They are now
> using
>> gitbox [1] which seems to allow GitHub to be the primary repo.
> 
> 
> GitHub is a distracting tangent here IMO. I really like GitHub's code
> commenting feature, but it should not matter if we use Apache's Git
>>> hosted
> repos or GitHub's. So I'm not sure why we are mixing GitHub in the
> conversation... ;-)
> 
> Gary
> 
> 
>> Every Maven plugin is individually released. Scroll down the link below
> to
>> the Maven section and you can see all the plugin repos.
>> 
>> The upside to this is that it are:
>>  1. It is far easier to perform releases of the individual
>> components.
>>  2. It is much easier to accept plugin contributions.
>> The downsides are:
>>  1. A page like https://maven.apache.org/plugins/ <
>> https://maven.apache.org/plugins/> is needed to keep track of the
>>> plugin
>> versions.
>>  2. It could make sense to have log4j-parent and log4j-bom
>> projects. The first to help keep the builds similar and the second to
> help
>> customers pick up the latest versions.
>> 
>> Ralph
>> 
>> [1] https://gitbox.apache.org/repos/asf > repos/asf>
>> 
>>> On Jan 21, 2018, at 8:55 AM, Gary Gregory 
>> wrote:
>>> 
>>> Hi All,
>>> 
>>> I am writing this to in an effort to understand how we can manage and
>> grow
>>> Log4j. I use the term 'grow' not in the 'bigger is better' sense but
> more
>>> in the maturing sense.
>>> 
>>> I am prompted to write this by Ralph's comment that log4j-core and the
>> main
>>> repo is too big and that releases take t

Re: logging-log4j2 git commit: [LOG4J2-2212]Unnecessary contention in CopyOnWriteSortedArrayThreadContextMap. [LOG4J2-2213] Unnecessary contention in GarbageFreeSortedArrayThreadContextMap.

[Remko Popma]

This solution should work. Thanks for taking care of this, Gary!

One thing, why are the new fields capitalized? It makes the field names look 
like class names in the code. I’ve never seen that convention. Should they not 
be simply lower case?

(Shameless plug) Every java main() method deserves http://picocli.info

> On Jan 24, 2018, at 6:20, ggreg...@apache.org wrote:
> 
> Repository: logging-log4j2
> Updated Branches:
>  refs/heads/master 81d12ad14 -> 93e97932c
> 
> 
> [LOG4J2-2212]Unnecessary contention in
> CopyOnWriteSortedArrayThreadContextMap.
> [LOG4J2-2213] Unnecessary contention in
> GarbageFreeSortedArrayThreadContextMap.
> 
> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/93e97932
> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/93e97932
> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/93e97932
> 
> Branch: refs/heads/master
> Commit: 93e97932c871a94486b8dc1c16f6ae3a77184871
> Parents: 81d12ad
> Author: Gary Gregory 
> Authored: Tue Jan 23 14:20:14 2018 -0700
> Committer: Gary Gregory 
> Committed: Tue Jan 23 14:20:14 2018 -0700
> 
> --
> .../org/apache/logging/log4j/ThreadContext.java |  1 +
> .../CopyOnWriteSortedArrayThreadContextMap.java | 21 ---
> .../GarbageFreeSortedArrayThreadContextMap.java | 23 ++--
> .../log4j/spi/ThreadContextMapFactory.java  | 39 
> .../log4j/ThreadContextInheritanceTest.java |  8 +++-
> .../logging/log4j/core/LoggerContext.java   |  7 
> src/changes/changes.xml | 11 ++
> 7 files changed, 92 insertions(+), 18 deletions(-)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/93e97932/log4j-api/src/main/java/org/apache/logging/log4j/ThreadContext.java
> --
> diff --git 
> a/log4j-api/src/main/java/org/apache/logging/log4j/ThreadContext.java 
> b/log4j-api/src/main/java/org/apache/logging/log4j/ThreadContext.java
> index fc018b9..c4ae445 100644
> --- a/log4j-api/src/main/java/org/apache/logging/log4j/ThreadContext.java
> +++ b/log4j-api/src/main/java/org/apache/logging/log4j/ThreadContext.java
> @@ -211,6 +211,7 @@ public final class ThreadContext {
>  * Consider private, used for testing.
>  */
> static void init() {
> +ThreadContextMapFactory.init();
> contextMap = null;
> final PropertiesUtil managerProps = PropertiesUtil.getProperties();
> disableAll = managerProps.getBooleanProperty(DISABLE_ALL);
> 
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/93e97932/log4j-api/src/main/java/org/apache/logging/log4j/spi/CopyOnWriteSortedArrayThreadContextMap.java
> --
> diff --git 
> a/log4j-api/src/main/java/org/apache/logging/log4j/spi/CopyOnWriteSortedArrayThreadContextMap.java
>  
> b/log4j-api/src/main/java/org/apache/logging/log4j/spi/CopyOnWriteSortedArrayThreadContextMap.java
> index d5e466f..fd94566 100644
> --- 
> a/log4j-api/src/main/java/org/apache/logging/log4j/spi/CopyOnWriteSortedArrayThreadContextMap.java
> +++ 
> b/log4j-api/src/main/java/org/apache/logging/log4j/spi/CopyOnWriteSortedArrayThreadContextMap.java
> @@ -53,9 +53,23 @@ class CopyOnWriteSortedArrayThreadContextMap implements 
> ReadOnlyThreadContextMap
> protected static final String PROPERTY_NAME_INITIAL_CAPACITY = 
> "log4j2.ThreadContext.initial.capacity";
> 
> private static final StringMap EMPTY_CONTEXT_DATA = new 
> SortedArrayStringMap(1);
> +
> +private static volatile int InitialCapacity;
> +private static volatile boolean InheritableMap;
> 
> +/**
> + * Initializes static variables based on system properties. Normally 
> called when this class is initialized by the VM
> + * and when Log4j is reconfigured.
> + */
> +static void init() {
> +final PropertiesUtil properties = PropertiesUtil.getProperties();
> +InitialCapacity = 
> properties.getIntegerProperty(PROPERTY_NAME_INITIAL_CAPACITY, 
> DEFAULT_INITIAL_CAPACITY);
> +InheritableMap = properties.getBooleanProperty(INHERITABLE_MAP);
> +}
> +
> static {
> EMPTY_CONTEXT_DATA.freeze();
> +init();
> }
> 
> private final ThreadLocal localMap;
> @@ -67,9 +81,7 @@ class CopyOnWriteSortedArrayThreadContextMap implements 
> ReadOnlyThreadContextMap
> // LOG4J2-479: by default, use a plain ThreadLocal, only use 
> InheritableThreadLocal if configured.
> // (This method is package protected for JUnit tests.)
> private ThreadLocal createThreadLocalMap() {
> -final PropertiesUtil managerProps = PropertiesUtil.getProperties();
> -final boolean inheritable = 
> managerProps.getBo

Re: logging-log4j2 git commit: LOG4J2-1883 moved SystemMillisClock out of the java9 module into core so it can be used with any supported Java version

[Remko Popma]

I see what you mean. Hmm...

FYI, this feature (LOG4J2-1883) adds the following classes. I added them to
core.util, but they could still be moved to another package:
* Instant 
* PreciseClock 
* MutableInstant
* DummyPreciseClock
* SystemMillisClock

I would not consider moving the existing time-related classes, because that
would break client code. These should stay as is:
* Clock 
* NanoClock 
* ClockFactory
* SystemNanoClock, DummyNanoClock
* CachedClock, CoarseCachedClock, SystemClock

I also would not want to rename core.util.datetime; that would just break
client code without any tangible benefit.

So, we can add the new 5 classes to core.util.datetime, or create a new
package core.util.time and add them there, or leave them in core.util.  Not
sure which I prefer actually, need to think about it a bit...



On Wed, Jan 24, 2018 at 11:54 PM, Gary Gregory 
wrote:

> Hi,
>
> The package core.time is starting to look like a kitchen sink. Why not put
> this new class into the existing core.util.datetime or into a new core.time
> package. IMO core.util.datetime, should be core.datetime or simply
> core.util.time.
>
> Gary
>
> On Wed, Jan 24, 2018 at 4:22 AM,  wrote:
>
> > Repository: logging-log4j2
> > Updated Branches:
> >   refs/heads/LOG4J2-1883-instant-field 3c22d3d83 -> b8b519e5b
> >
> >
> > LOG4J2-1883 moved SystemMillisClock out of the java9 module into core so
> > it can be used with any supported Java version
> >
> >
> > Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
> > Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/
> > commit/b8b519e5
> > Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/
> b8b519e5
> > Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/
> b8b519e5
> >
> > Branch: refs/heads/LOG4J2-1883-instant-field
> > Commit: b8b519e5b6125ca08545691a631e8b3e0a0e4cd0
> > Parents: 3c22d3d
> > Author: rpopma 
> > Authored: Wed Jan 24 20:22:41 2018 +0900
> > Committer: rpopma 
> > Committed: Wed Jan 24 20:22:41 2018 +0900
> >
> > --
> >  .../log4j/core/util/SystemMillisClock.java  | 34
> 
> >  .../log4j/core/util/SystemMillisClock.java  | 34
> 
> >  2 files changed, 34 insertions(+), 34 deletions(-)
> > --
> >
> >
> > http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/
> > b8b519e5/log4j-core-java9/src/main/java/org/apache/logging/
> > log4j/core/util/SystemMillisClock.java
> > --
> > diff --git a/log4j-core-java9/src/main/java/org/apache/logging/log4j/
> > core/util/SystemMillisClock.java b/log4j-core-java9/src/main/
> > java/org/apache/logging/log4j/core/util/SystemMillisClock.java
> > deleted file mode 100644
> > index f267320..000
> > --- a/log4j-core-java9/src/main/java/org/apache/logging/log4j/
> > core/util/SystemMillisClock.java
> > +++ /dev/null
> > @@ -1,34 +0,0 @@
> > -/*
> > - * Licensed to the Apache Software Foundation (ASF) under one or more
> > - * contributor license agreements. See the NOTICE file distributed with
> > - * this work for additional information regarding copyright ownership.
> > - * The ASF licenses this file to You under the Apache license, Version
> 2.0
> > - * (the "License"); you may not use this file except in compliance with
> > - * the License. You may obtain a copy of the License at
> > - *
> > - *  http://www.apache.org/licenses/LICENSE-2.0
> > - *
> > - * Unless required by applicable law or agreed to in writing, software
> > - * distributed under the License is distributed on an "AS IS" BASIS,
> > - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> > implied.
> > - * See the license for the specific language governing permissions and
> > - * limitations under the license.
> > - */
> > -package org.apache.logging.log4j.core.util;
> > -
> > -/**
> > - * Implementation of the {@code Clock} interface that returns the system
> > time in millisecond granularity.
> > - * @since 2.11
> > - */
> > -public final class SystemMillisClock implements Clock {
> > -
> > -/**
> > - * Returns the system time.
> > - * @return the result of calling {@code System.currentTimeMillis()}
> > - */
> > -@Override
> > -public long currentTimeMillis() {
> > -return System.currentTimeMillis();
> > -}
> > -
> > -}
> >
> > http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/
> > b8b519e5/log4j-core/src/main/java/org/apache/logging/log4j/
> > core/util/SystemMillisClock.java
> > --
> > diff --git a/log4j-core/src/main/java/org/apache/logging/log4j/core/
> util/SystemMillisClock.java
> > b/log4j-core/src/main/java/org/apache/logging/log4j/core/
> > util/SystemMillisClock.java
> > new file mode 100644
> > index 000..f267320
> > --