[GitHub] logging-log4j2 pull request #107: Mark FileRenameAction as successful when u...

[benji]

Github user benji commented on a diff in the pull request:

https://github.com/apache/logging-log4j2/pull/107#discussion_r133093011
  
--- Diff: 
log4j-core/src/main/java/org/apache/logging/log4j/core/appender/rolling/action/FileRenameAction.java
 ---
@@ -124,11 +124,12 @@ public static boolean execute(final File source, 
final File destination, final b
 } catch (final IOException exMove) {
 LOGGER.error("Unable to move file {} to {}: {} {}", 
source.getAbsolutePath(),
 destination.getAbsolutePath(), 
exMove.getClass().getName(), exMove.getMessage());
-final boolean result = source.renameTo(destination);
+boolean result = source.renameTo(destination);
 if (!result) {
 try {
 
Files.copy(Paths.get(source.getAbsolutePath()), 
Paths.get(destination.getAbsolutePath()),
 StandardCopyOption.REPLACE_EXISTING);
+result = true;
--- End diff --

Maybe, I considered it but in my case I'd rather compress the destination 
file even if the source file has not been deleted successfully. I can change 
that if you want to only succeed when the delete has been successful has well.


---
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.
---

[GitHub] logging-log4j2 pull request #107: Mark FileRenameAction as successful when u...

[garydgregory]

Github user garydgregory commented on a diff in the pull request:

https://github.com/apache/logging-log4j2/pull/107#discussion_r133084320
  
--- Diff: 
log4j-core/src/main/java/org/apache/logging/log4j/core/appender/rolling/action/FileRenameAction.java
 ---
@@ -124,11 +124,12 @@ public static boolean execute(final File source, 
final File destination, final b
 } catch (final IOException exMove) {
 LOGGER.error("Unable to move file {} to {}: {} {}", 
source.getAbsolutePath(),
 destination.getAbsolutePath(), 
exMove.getClass().getName(), exMove.getMessage());
-final boolean result = source.renameTo(destination);
+boolean result = source.renameTo(destination);
 if (!result) {
 try {
 
Files.copy(Paths.get(source.getAbsolutePath()), 
Paths.get(destination.getAbsolutePath()),
 StandardCopyOption.REPLACE_EXISTING);
+result = true;
--- End diff --

Shouldn't this "result = true" be done _after_ this method successfully 
deletes the file?


---
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.
---

[jira] [Created] (LOG4J2-2012) No compression when using a separate drive in Linux

[Benjamin Jaton (JIRA)]

Benjamin Jaton created LOG4J2-2012:
--

 Summary: No compression when using a separate drive in Linux
 Key: LOG4J2-2012
 URL: https://issues.apache.org/jira/browse/LOG4J2-2012
 Project: Log4j 2
  Issue Type: Bug
  Components: Core
Affects Versions: 2.7
 Environment: Unix
Reporter: Benjamin Jaton


When setting up the filePattern of a RollingFileAppender pointing to a 
different FS than the fileName, the file gets moved but not compressed:

In this example, /usr/local and /archives are not on the same FS:
{code}2017-08-11 14:34:33,632 pool-8-thread-1 TRACE 
DefaultRolloverStrategy.purge() took 15.0 milliseconds 
2017-08-11 14:34:33,643 pool-8-thread-1 DEBUG RollingFileManager executing 
synchronous FileRenameAction[/usr/local/app/logs/app.log to 
/archives/logs/app-2017-08-11_14-34-33.log, renameEmptyFiles=false] 
2017-08-11 14:34:33,646 pool-8-thread-1 ERROR Unable to move file 
/usr/local/app/logs/app.log to /archives/logs/app-2017-08-11_14-34-33.log: 
java.nio.file.AtomicMoveNotSupportedException /usr/local/app/logs/app.log -> 
/archives/logs/app-2017-08-11_14-34-33.log: Invalid cross-device link 
2017-08-11 14:34:33,736 pool-8-thread-1 TRACE Renamed file 
/usr/local/app/logs/app.log to /archives/logs/app-2017-08-11_14-34-33.log using 
copy and delete{code}

Also reported here:
https://stackoverflow.com/questions/43179979/log4j2-rollingfileappender-invalid-cross-device-link



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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.
> 

[GitHub] logging-log4j2 pull request #107: Mark FileRenameAction as successful when u...

[benji]

GitHub user benji opened a pull request:

https://github.com/apache/logging-log4j2/pull/107

Mark FileRenameAction as successful when using alternative ways to mo…

If the primary strategy for moving a file (Files.move) fails, then the code 
tries other strategies but never returned successfully.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/benji/logging-log4j2 master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/logging-log4j2/pull/107.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #107


commit 931383fb0a6bfa8be19e27c688953adaf446b95c
Author: benjamin.ja...@gmail.com 
Date:   2017-08-14T22:21:26Z

Mark FileRenameAction as successful when using alternative ways to move a 
file.




---
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.
---

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

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

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

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16126500#comment-16126500
 ] 

Gary Gregory commented on LOG4J2-1888:
--

I am looking for a community review for my proposal in branch {{LOG4J-1888}}

> 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: Logger names for nested classes

[Gary Gregory]

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 
>> > 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 
>> > >> 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 
>>
>
>

Re: Logger names for nested classes

[Gary Gregory]

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 
> > 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 
> > >> 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 
>

Re: Jenkins build became unstable: Log4j 2.x #2980

[Matt Sicker]

It's from an async test. Could be a timing issue. I'd wait to see if it
pops up again.

On 14 August 2017 at 15:58, Ralph Goers  wrote:

>
> I don’t recall having seen this error before. Did the latest commit break
> something?
>
> Ralph
>
> > On Aug 14, 2017, at 1:12 PM, Apache Jenkins Server <
> jenk...@builds.apache.org> wrote:
> >
> > See  redirect?page=changes>
> >
> >
>
>
>


-- 
Matt Sicker 

Re: Logger names for nested classes

[Ralph Goers]

> On Aug 14, 2017, at 1:38 PM, Gary Gregory  wrote:
> 
> On Mon, Aug 14, 2017 at 2:08 PM, Ralph Goers  >
> wrote:
> 
>> 
>>> On Aug 14, 2017, at 11:49 AM, Gary Gregory 
>> wrote:
>>> 
>>> On Mon, Aug 14, 2017 at 12:35 PM, Gary Gregory 
>>> 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

Re: Logger names for nested classes

[Gary Gregory]

On Mon, Aug 14, 2017 at 2:08 PM, Ralph Goers 
wrote:

>
> > On Aug 14, 2017, at 11:49 AM, Gary Gregory 
> wrote:
> >
> > On Mon, Aug 14, 2017 at 12:35 PM, Gary Gregory 
> > 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.

Gary


> Ralph
>
>
>

Jenkins build became unstable: Log4j 2.x #2980

[Apache Jenkins Server]

See 

Re: Logger names for nested classes

[Ralph Goers]

> On Aug 14, 2017, at 11:49 AM, Gary Gregory  wrote:
> 
> On Mon, Aug 14, 2017 at 12:35 PM, Gary Gregory 
> 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?

Ralph

Re: Logger names for nested classes

[Dominik Psenner]

Thanks Gary!

I've been struggling with this since half a year now. Unfortunately I even
wasn't able to go to work since two months and it looks like this is not
something that simply goes away over time. At this very moment I'm happy to
be able to stand up straight, walk or even just sit and play games with the
kids for an hour with the pain coming back only very slowly. Rest assured
that I'm going to stick around, even though other things are more important
right now.

Cheers and hoping to read you soon!

2017-08-14 20:05 GMT+02:00 Gary Gregory :

> Dominik,
>
> I am so sorry to read that you are struggling with health issue.
>
> Thank you so much for taking the time to create the JIRA.
>
> We will take it from here and feel free to chime in or contribute at any
> time :-)
>
> I wish you a speedy recovery.
>
> Gary
>
> On Mon, Aug 14, 2017 at 2:14 AM, Dominik Psenner 
> wrote:
>
> > I wrote this up in a jira issue at [1]. Unfortunately I'm struggling with
> > my health and I can't give an estimate of when I can work on this. If you
> > want it for the next release, please take over the work right away as I
> > won't be able to contribute further.
> >
> > [1] https://issues.apache.org/jira/browse/LOG4J2-2010
> >
> > 2017-08-14 1:14 GMT+02:00 Gary Gregory :
> >
> > > Recapping:
> > >
> > > Using it:
> > >
> > >  > >
> > > Default:
> > >
> > >  > >
> > > Dominik: Do you want to take a shot at it?
> > >
> > > Gary
> > >
> > >
> > >
> > > On Sun, Aug 13, 2017 at 2:58 PM, Ralph Goers <
> ralph.go...@dslextreme.com
> > >
> > > wrote:
> > >
> > > > Yes, that is the way I would envision it. The default would be how it
> > > > works now.
> > > >
> > > > Ralph
> > > >
> > > > > On Aug 13, 2017, at 12:37 PM, Gary Gregory  >
> > > > wrote:
> > > > >
> > > > > Well we can make an exception for trailing $?
> > > > >
> > > > > Do we want to add an attribute in the Configuration XML element?
> For
> > > > > example hierarchySeparators=".$/"
> > > > >
> > > > > What should the default be?
> > > > >
> > > > > Gary
> > > > >
> > > > > On Aug 13, 2017 12:17, "Matt Sicker"  wrote:
> > > > >
> > > > >> Having the dollar sign interpreted differently also makes a
> > difference
> > > > in
> > > > >> Scala classes and potentially other languages. For example, in
> > Scala,
> > > an
> > > > >> "object" class is a singleton instance of the class (vaguely
> similar
> > > to
> > > > a
> > > > >> class with all static methods and fields), and it's translated to
> a
> > > Java
> > > > >> class name with a dollar sign appended. The Scala code "object
> Foo {
> > > > ... }"
> > > > >> translates to the equivalent of "public class Foo$ { public static
> > > Foo$
> > > > >> MODULE$ = new Foo$(); ... }" or something like that.
> > > > >>
> > > > >> On 13 August 2017 at 11:08, Apache 
> > > wrote:
> > > > >>
> > > > >>> You cannot replace. We always must support dots. But some people
> > have
> > > > >>> asked for '/' as well.
> > > > >>>
> > > > >>> Sent from my iPad
> > > > >>>
> > > >  On Aug 13, 2017, at 8:38 AM, Dominik Psenner <
> dpsen...@gmail.com>
> > > > >> wrote:
> > > > 
> > > >  Yes
> > > > 
> > > > > On 13 Aug 2017 5:13 p.m., "Gary Gregory" <
> garydgreg...@gmail.com
> > >
> > > > >>> wrote:
> > > > >
> > > > > You are talking about replacing $ with dot in the
> > getLogger(Class)
> > > > >> API?
> > > > >
> > > > > Gary
> > > > >
> > > > >> On Aug 13, 2017 01:57, "Dominik Psenner" 
> > > > wrote:
> > > > >>
> > > > >> Could the $ be replaced by a dot when the logger is
> > instantiated?
> > > > >>> Log4net
> > > > >> picks the class name as logger name but also allows custom
> > logger
> > > > >>> names.
> > > > >>
> > > > >> On 13 Aug 2017 8:30 a.m., "Ralph Goers" <
> > > ralph.go...@dslextreme.com
> > > > >
> > > > >> wrote:
> > > > >>
> > > > >>> Rather than implementing this I would rather have the
> separator
> > > > >> chars
> > > > > be
> > > > >>> specifiable in the configuration. Blatantly making this
> change
> > > > might
> > > > >> cause
> > > > >>> compatibility problems, although I am not really sure how it
> > > could.
> > > > >>>
> > > > >>> Ralph
> > > > >>>
> > > >  On Aug 12, 2017, at 11:29 AM, Gary Gregory <
> > > > garydgreg...@gmail.com
> > > > >>>
> > > > >>> wrote:
> > > > 
> > > >  Hi All,
> > > > 
> > > >  I you use nested classes to build loggers, you end up with
> > > logger
> > > > > names
> > > >  like A$N1, A$N2 and so on.
> > > > 
> > > >  If you then set a logger level in a config using "A", it
> does
> > > not
> > > > >> affect
> > > >  A$N1 and A$N2 as you might expect, since "$" is not a ".".
> > > > 
> > > >  What about treating "$" 

Re: Logger names for nested classes

[Gary Gregory]

It turns out that I have some use cases for the Core LoggerContext to
support getLogger(Class), which is really a convenience to avoid calling
Class.getName() but then I am in the same pickle.

That tells me that:
- either Core needs to parse logger names and do char subst.
- or Core LoggerContext should support getLogger(Class)

Gary

On Mon, Aug 14, 2017 at 12:49 PM, Gary Gregory 
wrote:

> On Mon, Aug 14, 2017 at 12:35 PM, Gary Gregory 
> 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?
>
> Gary
>
>
>
>> Gary
>>
>>
>> On Mon, Aug 14, 2017 at 2:14 AM, Dominik Psenner 
>> wrote:
>>
>>> I wrote this up in a jira issue at [1]. Unfortunately I'm struggling with
>>> my health and I can't give an estimate of when I can work on this. If you
>>> want it for the next release, please take over the work right away as I
>>> won't be able to contribute further.
>>>
>>> [1] https://issues.apache.org/jira/browse/LOG4J2-2010
>>>
>>> 2017-08-14 1:14 GMT+02:00 Gary Gregory :
>>>
>>> > Recapping:
>>> >
>>> > Using it:
>>> >
>>> > >> >
>>> > Default:
>>> >
>>> > >> >
>>> > Dominik: Do you want to take a shot at it?
>>> >
>>> > Gary
>>> >
>>> >
>>> >
>>> > On Sun, Aug 13, 2017 at 2:58 PM, Ralph Goers <
>>> ralph.go...@dslextreme.com>
>>> > wrote:
>>> >
>>> > > Yes, that is the way I would envision it. The default would be how it
>>> > > works now.
>>> > >
>>> > > Ralph
>>> > >
>>> > > > On Aug 13, 2017, at 12:37 PM, Gary Gregory >> >
>>> > > wrote:
>>> > > >
>>> > > > Well we can make an exception for trailing $?
>>> > > >
>>> > > > Do we want to add an attribute in the Configuration XML element?
>>> For
>>> > > > example hierarchySeparators=".$/"
>>> > > >
>>> > > > What should the default be?
>>> > > >
>>> > > > Gary
>>> > > >
>>> > > > On Aug 13, 2017 12:17, "Matt Sicker"  wrote:
>>> > > >
>>> > > >> Having the dollar sign interpreted differently also makes a
>>> difference
>>> > > in
>>> > > >> Scala classes and potentially other languages. For example, in
>>> Scala,
>>> > an
>>> > > >> "object" class is a singleton instance of the class (vaguely
>>> similar
>>> > to
>>> > > a
>>> > > >> class with all static methods and fields), and it's translated to
>>> a
>>> > Java
>>> > > >> class name with a dollar sign appended. The Scala code "object
>>> Foo {
>>> > > ... }"
>>> > > >> translates to the equivalent of "public class Foo$ { public static
>>> > Foo$
>>> > > >> MODULE$ = new Foo$(); ... }" or something like that.
>>> > > >>
>>> > > >> On 13 August 2017 at 11:08, Apache 
>>> > wrote:
>>> > > >>
>>> > > >>> You cannot replace. We always must support dots. But some people
>>> have
>>> > > >>> asked for '/' as well.
>>> > > >>>
>>> > > >>> Sent from my iPad
>>> > > >>>
>>> > >  On Aug 13, 2017, at 8:38 AM, Dominik Psenner <
>>> dpsen...@gmail.com>
>>> > > >> wrote:
>>> > > 
>>> > >  Yes
>>> > > 
>>> > > > On 13 Aug 2017 5:13 p.m., "Gary Gregory" <
>>> garydgreg...@gmail.com>
>>> > > >>> wrote:
>>> > > >
>>> > > > You are talking about replacing $ with dot in the
>>> getLogger(Class)
>>> > > >> API?
>>> > > >
>>> > > > Gary
>>> > > >
>>> > > >> On Aug 13, 2017 01:57, "Dominik Psenner" 
>>> > > wrote:
>>> > > >>
>>> > > >> Could the $ be replaced by a dot when the logger is
>>> instantiated?
>>> > > >>> Log4net
>>> > > >> picks the class name as logger name but also allows custom
>>> logger
>>> > > >>> names.
>>> > > >>
>>> > > >> On 13 Aug 2017 8:30 a.m., "Ralph Goers" <
>>> > ralph.go...@dslextreme.com
>>> > > >
>>> > > >> wrote:
>>> > > >>
>>> > > >>> Rather than implementing this I would rather have the
>>> separator
>>> > > >> chars
>>> > > > be
>>> > > >>> specifiable in the configuration. Blatantly making this
>>> change
>>> > > might
>>> > > >> cause
>>> > > >>> compatibility problems, although I am not really sure how it
>>> > could.
>>> > > >>>
>>> > > >>> Ralph
>>> > > >>>
>>> > >  On Aug 12, 2017, at 11:29 AM, Gary Gregory <
>>> > > garydgreg...@gmail.com
>>> > > >>>
>>> > > >>> wrote:
>>> > > 
>>> > >  Hi All,
>>> > > 
>>> > >  I you use nested classes to build 

Re: Logger names for nested classes

[Gary Gregory]

On Mon, Aug 14, 2017 at 12:35 PM, Gary Gregory 
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?

Gary



> Gary
>
>
> On Mon, Aug 14, 2017 at 2:14 AM, Dominik Psenner 
> wrote:
>
>> I wrote this up in a jira issue at [1]. Unfortunately I'm struggling with
>> my health and I can't give an estimate of when I can work on this. If you
>> want it for the next release, please take over the work right away as I
>> won't be able to contribute further.
>>
>> [1] https://issues.apache.org/jira/browse/LOG4J2-2010
>>
>> 2017-08-14 1:14 GMT+02:00 Gary Gregory :
>>
>> > Recapping:
>> >
>> > Using it:
>> >
>> > > >
>> > Default:
>> >
>> > > >
>> > Dominik: Do you want to take a shot at it?
>> >
>> > Gary
>> >
>> >
>> >
>> > On Sun, Aug 13, 2017 at 2:58 PM, Ralph Goers <
>> ralph.go...@dslextreme.com>
>> > wrote:
>> >
>> > > Yes, that is the way I would envision it. The default would be how it
>> > > works now.
>> > >
>> > > Ralph
>> > >
>> > > > On Aug 13, 2017, at 12:37 PM, Gary Gregory 
>> > > wrote:
>> > > >
>> > > > Well we can make an exception for trailing $?
>> > > >
>> > > > Do we want to add an attribute in the Configuration XML element? For
>> > > > example hierarchySeparators=".$/"
>> > > >
>> > > > What should the default be?
>> > > >
>> > > > Gary
>> > > >
>> > > > On Aug 13, 2017 12:17, "Matt Sicker"  wrote:
>> > > >
>> > > >> Having the dollar sign interpreted differently also makes a
>> difference
>> > > in
>> > > >> Scala classes and potentially other languages. For example, in
>> Scala,
>> > an
>> > > >> "object" class is a singleton instance of the class (vaguely
>> similar
>> > to
>> > > a
>> > > >> class with all static methods and fields), and it's translated to a
>> > Java
>> > > >> class name with a dollar sign appended. The Scala code "object Foo
>> {
>> > > ... }"
>> > > >> translates to the equivalent of "public class Foo$ { public static
>> > Foo$
>> > > >> MODULE$ = new Foo$(); ... }" or something like that.
>> > > >>
>> > > >> On 13 August 2017 at 11:08, Apache 
>> > wrote:
>> > > >>
>> > > >>> You cannot replace. We always must support dots. But some people
>> have
>> > > >>> asked for '/' as well.
>> > > >>>
>> > > >>> Sent from my iPad
>> > > >>>
>> > >  On Aug 13, 2017, at 8:38 AM, Dominik Psenner > >
>> > > >> wrote:
>> > > 
>> > >  Yes
>> > > 
>> > > > On 13 Aug 2017 5:13 p.m., "Gary Gregory" <
>> garydgreg...@gmail.com>
>> > > >>> wrote:
>> > > >
>> > > > You are talking about replacing $ with dot in the
>> getLogger(Class)
>> > > >> API?
>> > > >
>> > > > Gary
>> > > >
>> > > >> On Aug 13, 2017 01:57, "Dominik Psenner" 
>> > > wrote:
>> > > >>
>> > > >> Could the $ be replaced by a dot when the logger is
>> instantiated?
>> > > >>> Log4net
>> > > >> picks the class name as logger name but also allows custom
>> logger
>> > > >>> names.
>> > > >>
>> > > >> On 13 Aug 2017 8:30 a.m., "Ralph Goers" <
>> > ralph.go...@dslextreme.com
>> > > >
>> > > >> wrote:
>> > > >>
>> > > >>> Rather than implementing this I would rather have the
>> separator
>> > > >> chars
>> > > > be
>> > > >>> specifiable in the configuration. Blatantly making this change
>> > > might
>> > > >> cause
>> > > >>> compatibility problems, although I am not really sure how it
>> > could.
>> > > >>>
>> > > >>> Ralph
>> > > >>>
>> > >  On Aug 12, 2017, at 11:29 AM, Gary Gregory <
>> > > garydgreg...@gmail.com
>> > > >>>
>> > > >>> wrote:
>> > > 
>> > >  Hi All,
>> > > 
>> > >  I you use nested classes to build loggers, you end up with
>> > logger
>> > > > names
>> > >  like A$N1, A$N2 and so on.
>> > > 
>> > >  If you then set a logger level in a config using "A", it does
>> > not
>> > > >> affect
>> > >  A$N1 and A$N2 as you might expect, since "$" is not a ".".
>> > > 
>> > >  What about treating "$" like a "."?
>> > > 
>> > >  Thoughts?
>> > > 
>> > >  Gary
>> > > >>>
>> > > >>>
>> > > >>>
>> > > >>
>> > > >
>> > > >>>
>> > > >>>
>> > > >>>
>> > > >>
>> > > >>
>> > > >> --
>> > > >> Matt Sicker 

Re: Logger names for nested classes

[Gary Gregory]

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.

Gary


On Mon, Aug 14, 2017 at 2:14 AM, Dominik Psenner  wrote:

> I wrote this up in a jira issue at [1]. Unfortunately I'm struggling with
> my health and I can't give an estimate of when I can work on this. If you
> want it for the next release, please take over the work right away as I
> won't be able to contribute further.
>
> [1] https://issues.apache.org/jira/browse/LOG4J2-2010
>
> 2017-08-14 1:14 GMT+02:00 Gary Gregory :
>
> > Recapping:
> >
> > Using it:
> >
> >  >
> > Default:
> >
> >  >
> > Dominik: Do you want to take a shot at it?
> >
> > Gary
> >
> >
> >
> > On Sun, Aug 13, 2017 at 2:58 PM, Ralph Goers  >
> > wrote:
> >
> > > Yes, that is the way I would envision it. The default would be how it
> > > works now.
> > >
> > > Ralph
> > >
> > > > On Aug 13, 2017, at 12:37 PM, Gary Gregory 
> > > wrote:
> > > >
> > > > Well we can make an exception for trailing $?
> > > >
> > > > Do we want to add an attribute in the Configuration XML element? For
> > > > example hierarchySeparators=".$/"
> > > >
> > > > What should the default be?
> > > >
> > > > Gary
> > > >
> > > > On Aug 13, 2017 12:17, "Matt Sicker"  wrote:
> > > >
> > > >> Having the dollar sign interpreted differently also makes a
> difference
> > > in
> > > >> Scala classes and potentially other languages. For example, in
> Scala,
> > an
> > > >> "object" class is a singleton instance of the class (vaguely similar
> > to
> > > a
> > > >> class with all static methods and fields), and it's translated to a
> > Java
> > > >> class name with a dollar sign appended. The Scala code "object Foo {
> > > ... }"
> > > >> translates to the equivalent of "public class Foo$ { public static
> > Foo$
> > > >> MODULE$ = new Foo$(); ... }" or something like that.
> > > >>
> > > >> On 13 August 2017 at 11:08, Apache 
> > wrote:
> > > >>
> > > >>> You cannot replace. We always must support dots. But some people
> have
> > > >>> asked for '/' as well.
> > > >>>
> > > >>> Sent from my iPad
> > > >>>
> > >  On Aug 13, 2017, at 8:38 AM, Dominik Psenner 
> > > >> wrote:
> > > 
> > >  Yes
> > > 
> > > > On 13 Aug 2017 5:13 p.m., "Gary Gregory"  >
> > > >>> wrote:
> > > >
> > > > You are talking about replacing $ with dot in the
> getLogger(Class)
> > > >> API?
> > > >
> > > > Gary
> > > >
> > > >> On Aug 13, 2017 01:57, "Dominik Psenner" 
> > > wrote:
> > > >>
> > > >> Could the $ be replaced by a dot when the logger is
> instantiated?
> > > >>> Log4net
> > > >> picks the class name as logger name but also allows custom
> logger
> > > >>> names.
> > > >>
> > > >> On 13 Aug 2017 8:30 a.m., "Ralph Goers" <
> > ralph.go...@dslextreme.com
> > > >
> > > >> wrote:
> > > >>
> > > >>> Rather than implementing this I would rather have the separator
> > > >> chars
> > > > be
> > > >>> specifiable in the configuration. Blatantly making this change
> > > might
> > > >> cause
> > > >>> compatibility problems, although I am not really sure how it
> > could.
> > > >>>
> > > >>> Ralph
> > > >>>
> > >  On Aug 12, 2017, at 11:29 AM, Gary Gregory <
> > > garydgreg...@gmail.com
> > > >>>
> > > >>> wrote:
> > > 
> > >  Hi All,
> > > 
> > >  I you use nested classes to build loggers, you end up with
> > logger
> > > > names
> > >  like A$N1, A$N2 and so on.
> > > 
> > >  If you then set a logger level in a config using "A", it does
> > not
> > > >> affect
> > >  A$N1 and A$N2 as you might expect, since "$" is not a ".".
> > > 
> > >  What about treating "$" like a "."?
> > > 
> > >  Thoughts?
> > > 
> > >  Gary
> > > >>>
> > > >>>
> > > >>>
> > > >>
> > > >
> > > >>>
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >> --
> > > >> Matt Sicker 
> > > >>
> > >
> > >
> > >
> >
>
>
>
> --
> Dominik Psenner
>

Re: Logger names for nested classes

[Gary Gregory]

Dominik,

I am so sorry to read that you are struggling with health issue.

Thank you so much for taking the time to create the JIRA.

We will take it from here and feel free to chime in or contribute at any
time :-)

I wish you a speedy recovery.

Gary

On Mon, Aug 14, 2017 at 2:14 AM, Dominik Psenner  wrote:

> I wrote this up in a jira issue at [1]. Unfortunately I'm struggling with
> my health and I can't give an estimate of when I can work on this. If you
> want it for the next release, please take over the work right away as I
> won't be able to contribute further.
>
> [1] https://issues.apache.org/jira/browse/LOG4J2-2010
>
> 2017-08-14 1:14 GMT+02:00 Gary Gregory :
>
> > Recapping:
> >
> > Using it:
> >
> >  >
> > Default:
> >
> >  >
> > Dominik: Do you want to take a shot at it?
> >
> > Gary
> >
> >
> >
> > On Sun, Aug 13, 2017 at 2:58 PM, Ralph Goers  >
> > wrote:
> >
> > > Yes, that is the way I would envision it. The default would be how it
> > > works now.
> > >
> > > Ralph
> > >
> > > > On Aug 13, 2017, at 12:37 PM, Gary Gregory 
> > > wrote:
> > > >
> > > > Well we can make an exception for trailing $?
> > > >
> > > > Do we want to add an attribute in the Configuration XML element? For
> > > > example hierarchySeparators=".$/"
> > > >
> > > > What should the default be?
> > > >
> > > > Gary
> > > >
> > > > On Aug 13, 2017 12:17, "Matt Sicker"  wrote:
> > > >
> > > >> Having the dollar sign interpreted differently also makes a
> difference
> > > in
> > > >> Scala classes and potentially other languages. For example, in
> Scala,
> > an
> > > >> "object" class is a singleton instance of the class (vaguely similar
> > to
> > > a
> > > >> class with all static methods and fields), and it's translated to a
> > Java
> > > >> class name with a dollar sign appended. The Scala code "object Foo {
> > > ... }"
> > > >> translates to the equivalent of "public class Foo$ { public static
> > Foo$
> > > >> MODULE$ = new Foo$(); ... }" or something like that.
> > > >>
> > > >> On 13 August 2017 at 11:08, Apache 
> > wrote:
> > > >>
> > > >>> You cannot replace. We always must support dots. But some people
> have
> > > >>> asked for '/' as well.
> > > >>>
> > > >>> Sent from my iPad
> > > >>>
> > >  On Aug 13, 2017, at 8:38 AM, Dominik Psenner 
> > > >> wrote:
> > > 
> > >  Yes
> > > 
> > > > On 13 Aug 2017 5:13 p.m., "Gary Gregory"  >
> > > >>> wrote:
> > > >
> > > > You are talking about replacing $ with dot in the
> getLogger(Class)
> > > >> API?
> > > >
> > > > Gary
> > > >
> > > >> On Aug 13, 2017 01:57, "Dominik Psenner" 
> > > wrote:
> > > >>
> > > >> Could the $ be replaced by a dot when the logger is
> instantiated?
> > > >>> Log4net
> > > >> picks the class name as logger name but also allows custom
> logger
> > > >>> names.
> > > >>
> > > >> On 13 Aug 2017 8:30 a.m., "Ralph Goers" <
> > ralph.go...@dslextreme.com
> > > >
> > > >> wrote:
> > > >>
> > > >>> Rather than implementing this I would rather have the separator
> > > >> chars
> > > > be
> > > >>> specifiable in the configuration. Blatantly making this change
> > > might
> > > >> cause
> > > >>> compatibility problems, although I am not really sure how it
> > could.
> > > >>>
> > > >>> Ralph
> > > >>>
> > >  On Aug 12, 2017, at 11:29 AM, Gary Gregory <
> > > garydgreg...@gmail.com
> > > >>>
> > > >>> wrote:
> > > 
> > >  Hi All,
> > > 
> > >  I you use nested classes to build loggers, you end up with
> > logger
> > > > names
> > >  like A$N1, A$N2 and so on.
> > > 
> > >  If you then set a logger level in a config using "A", it does
> > not
> > > >> affect
> > >  A$N1 and A$N2 as you might expect, since "$" is not a ".".
> > > 
> > >  What about treating "$" like a "."?
> > > 
> > >  Thoughts?
> > > 
> > >  Gary
> > > >>>
> > > >>>
> > > >>>
> > > >>
> > > >
> > > >>>
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >> --
> > > >> Matt Sicker 
> > > >>
> > >
> > >
> > >
> >
>
>
>
> --
> Dominik Psenner
>

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

[Gary Gregory]

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 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;
>> > > +
>> > > +/**
>> > > + * 
>> > > + * 

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 

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

[Matt Sicker]

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 ListFile files = new ArrayListFile();
> > + *
> > + * Option(names = { "-o", "--out" }, description = "Output
> file
> > (default: print to console)")
> > + * private File outputFile;
> > + *
> > + * Option(names = { "-v", "--verbose"}, description =
> > "Verbosely list files 

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

[Gary Gregory]

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 ListFile files = new ArrayListFile();
> + *
> + * Option(names = { "-o", "--out" }, description = "Output file
> (default: print to console)")
> + * private File outputFile;
> + *
> + * Option(names = { "-v", "--verbose"}, description =
> "Verbosely list files processed")
> + * private boolean verbose;
> + *
> + * Option(names = { "-h", "--help", "-?", "-help"}, help =
> true, description = "Display this help and exit")
> + * private boolean help;
> + * }
> + * 
> + * 
> + * Use {@code CommandLine} to initialize a domain object as follows:
> + * 
> + * public static void main(String... args) {
> + * try {
> + * Encrypt encrypt = 

Re: Log4j 2.9

[Matt Sicker]

Alright, I'll try to get that committed early this week. I've been finally
(for real this time) wrapping up work stuff that was taking too much of my
time and energy, so I should be able to get back on this.

On 14 August 2017 at 10:56, Ralph Goers  wrote:

> If you can get the scala site checked in I can figure out how to do link
> them.
>
> Ralph
>
> > On Aug 14, 2017, at 7:00 AM, Matt Sicker  wrote:
> >
> > The Scala site hasn't been committed to SVN as I wasn't exactly sure how
> to
> > go about integrating it properly. I do think we should get that
> integrated
> > first. I'm not exactly sure where the links should go in the 2.9 version
> of
> > the site as they're no longer components of the release.
> >
> > On 14 August 2017 at 00:39, Ralph Goers 
> wrote:
> >
> >> I’d like to start the release process next weekend for Log4j 2.9. I
> >> believe there is some web site work that has to take place for that to
> >> happen to integrate with the new Scala release. Has Scala been
> published to
> >> the web site? I can’t find it in SVN.
> >>
> >> Ralph
> >>
> >
> >
> >
> > --
> > Matt Sicker 
>
>
>


-- 
Matt Sicker 

[jira] [Updated] (LOG4J2-2011) replace JCommander with picocli

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma updated LOG4J2-2011:

Description: 
As discussed in the mailing list, replace uses of JCommander with 
[picocli|https://github.com/remkop/picocli] to get

* customizable usage help
* usage help with ANSI colors
* better support for positional parameters (so we can use positional parameters 
for mandatory arguments and options for optional arguments)
* include picocli as source so users can run these applications without 
requiring an external dependency

Candidates for usage are:

*log4j-core*

* CustomLoggerGenerator
* ExtendedLoggerGenerator
* Generate
* PluginManager

*log4j-jmx-gui*
* ClientGui

*log4j-1.2-api*
* (/) Log4j1ConfigurationConverter

*logging-log4j-tools/log4j-server*
* (/) AbstractSocketServer
* (/) TcpSocketServer
* (/)  UdpSocketServer

  was:
As discussed in the mailing list, replace uses of JCommander with 
[picocli|https://github.com/remkop/picocli] to get

* customizable usage help
* usage help with ANSI colors
* better support for positional parameters (so we can use positional parameters 
for mandatory arguments and options for optional arguments)
* include picocli as source so users can run these applications without 
requiring an external dependency

Candidates for usage are:

*log4j-core*

* CustomLoggerGenerator
* ExtendedLoggerGenerator
* Generate
* PluginManager

*log4j-jmx-gui*
* ClientGui

*log4j-1.2-api*
* Log4j1ConfigurationConverter

*logging-log4j-tools/log4j-server*
* AbstractSocketServer
* TcpSocketServer


> replace JCommander with picocli
> ---
>
> Key: LOG4J2-2011
> URL: https://issues.apache.org/jira/browse/LOG4J2-2011
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core, Servers
>Affects Versions: 2.8.2
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.9
>
>
> As discussed in the mailing list, replace uses of JCommander with 
> [picocli|https://github.com/remkop/picocli] to get
> * customizable usage help
> * usage help with ANSI colors
> * better support for positional parameters (so we can use positional 
> parameters for mandatory arguments and options for optional arguments)
> * include picocli as source so users can run these applications without 
> requiring an external dependency
> Candidates for usage are:
> *log4j-core*
> * CustomLoggerGenerator
> * ExtendedLoggerGenerator
> * Generate
> * PluginManager
> *log4j-jmx-gui*
> * ClientGui
> *log4j-1.2-api*
> * (/) Log4j1ConfigurationConverter
> *logging-log4j-tools/log4j-server*
> * (/) AbstractSocketServer
> * (/) TcpSocketServer
> * (/)  UdpSocketServer



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (LOG4J2-2011) replace JCommander with picocli

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma resolved LOG4J2-2011.
-
Resolution: Fixed

Migrated to picocli, and users no longer need an external dependency to run 
Log4j2 utility applications like TcpSocketServer or 
Log4j1ConfigurationConverter.

There is still some remaining work to add {{description}} annotations on these 
commands to generate nicer usage help messages, and migrate some other utility 
applications that did not use JCommander to use picocli.

> replace JCommander with picocli
> ---
>
> Key: LOG4J2-2011
> URL: https://issues.apache.org/jira/browse/LOG4J2-2011
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core, Servers
>Affects Versions: 2.8.2
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.9
>
>
> As discussed in the mailing list, replace uses of JCommander with 
> [picocli|https://github.com/remkop/picocli] to get
> * customizable usage help
> * usage help with ANSI colors
> * better support for positional parameters (so we can use positional 
> parameters for mandatory arguments and options for optional arguments)
> * include picocli as source so users can run these applications without 
> requiring an external dependency
> Candidates for usage are:
> *log4j-core*
> * CustomLoggerGenerator
> * ExtendedLoggerGenerator
> * Generate
> * PluginManager
> *log4j-jmx-gui*
> * ClientGui
> *log4j-1.2-api*
> * Log4j1ConfigurationConverter
> *logging-log4j-tools/log4j-server*
> * AbstractSocketServer
> * TcpSocketServer



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LOG4J2-2011) replace JCommander with picocli

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125917#comment-16125917
 ] 

ASF subversion and git services commented on LOG4J2-2011:
-

Commit 0007b107b94f5b5024ea4aaa189bb8e0b7bf1c5c in logging-log4j-tools's branch 
refs/heads/master from rpopma
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j-tools.git;h=0007b10 ]

LOG4J2-2011 replace JCommander command line parser with picocli to let users 
run Log4j2 utility applications without requiring an external dependency


> replace JCommander with picocli
> ---
>
> Key: LOG4J2-2011
> URL: https://issues.apache.org/jira/browse/LOG4J2-2011
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core, Servers
>Affects Versions: 2.8.2
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.9
>
>
> As discussed in the mailing list, replace uses of JCommander with 
> [picocli|https://github.com/remkop/picocli] to get
> * customizable usage help
> * usage help with ANSI colors
> * better support for positional parameters (so we can use positional 
> parameters for mandatory arguments and options for optional arguments)
> * include picocli as source so users can run these applications without 
> requiring an external dependency
> Candidates for usage are:
> *log4j-core*
> * CustomLoggerGenerator
> * ExtendedLoggerGenerator
> * Generate
> * PluginManager
> *log4j-jmx-gui*
> * ClientGui
> *log4j-1.2-api*
> * Log4j1ConfigurationConverter
> *logging-log4j-tools/log4j-server*
> * AbstractSocketServer
> * TcpSocketServer



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LOG4J2-2011) replace JCommander with picocli

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125909#comment-16125909
 ] 

ASF subversion and git services commented on LOG4J2-2011:
-

Commit c2818beca59e948c205c359f714f24eff7340477 in logging-log4j2's branch 
refs/heads/master from rpopma
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=c2818be ]

LOG4J2-2011 replace JCommander command line parser with picocli to let users 
run Log4j2 utility applications without requiring an external dependency


> replace JCommander with picocli
> ---
>
> Key: LOG4J2-2011
> URL: https://issues.apache.org/jira/browse/LOG4J2-2011
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core, Servers
>Affects Versions: 2.8.2
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.9
>
>
> As discussed in the mailing list, replace uses of JCommander with 
> [picocli|https://github.com/remkop/picocli] to get
> * customizable usage help
> * usage help with ANSI colors
> * better support for positional parameters (so we can use positional 
> parameters for mandatory arguments and options for optional arguments)
> * include picocli as source so users can run these applications without 
> requiring an external dependency
> Candidates for usage are:
> *log4j-core*
> * CustomLoggerGenerator
> * ExtendedLoggerGenerator
> * Generate
> * PluginManager
> *log4j-jmx-gui*
> * ClientGui
> *log4j-1.2-api*
> * Log4j1ConfigurationConverter
> *logging-log4j-tools/log4j-server*
> * AbstractSocketServer
> * TcpSocketServer



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Log4j 2.9

[Ralph Goers]

If you can get the scala site checked in I can figure out how to do link them.

Ralph

> On Aug 14, 2017, at 7:00 AM, Matt Sicker  wrote:
> 
> The Scala site hasn't been committed to SVN as I wasn't exactly sure how to
> go about integrating it properly. I do think we should get that integrated
> first. I'm not exactly sure where the links should go in the 2.9 version of
> the site as they're no longer components of the release.
> 
> On 14 August 2017 at 00:39, Ralph Goers  wrote:
> 
>> I’d like to start the release process next weekend for Log4j 2.9. I
>> believe there is some web site work that has to take place for that to
>> happen to integrate with the new Scala release. Has Scala been published to
>> the web site? I can’t find it in SVN.
>> 
>> Ralph
>> 
> 
> 
> 
> -- 
> Matt Sicker 

Re: Log4j 2.9

[Matt Sicker]

The Scala site hasn't been committed to SVN as I wasn't exactly sure how to
go about integrating it properly. I do think we should get that integrated
first. I'm not exactly sure where the links should go in the 2.9 version of
the site as they're no longer components of the release.

On 14 August 2017 at 00:39, Ralph Goers  wrote:

> I’d like to start the release process next weekend for Log4j 2.9. I
> believe there is some web site work that has to take place for that to
> happen to integrate with the new Scala release. Has Scala been published to
> the web site? I can’t find it in SVN.
>
> Ralph
>



-- 
Matt Sicker 

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 
>> > 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
>> >  with picocli?
>> >
>> > Main benefits:
>> >
>> >- Customizable usage help
>> >- Usage help with ANSI colors
>> >
>> >- 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)>
>> >
>>
>

[jira] [Created] (LOG4J2-2011) replace JCommander with picocli

[Remko Popma (JIRA)]

Remko Popma created LOG4J2-2011:
---

 Summary: replace JCommander with picocli
 Key: LOG4J2-2011
 URL: https://issues.apache.org/jira/browse/LOG4J2-2011
 Project: Log4j 2
  Issue Type: Improvement
  Components: Core, Servers
Affects Versions: 2.8.2
Reporter: Remko Popma
Assignee: Remko Popma
 Fix For: 2.9


As discussed in the mailing list, replace uses of JCommander with 
[picocli|https://github.com/remkop/picocli] to get

* customizable usage help
* usage help with ANSI colors
* better support for positional parameters (so we can use positional parameters 
for mandatory arguments and options for optional arguments)
* include picocli as source so users can run these applications without 
requiring an external dependency

Candidates for usage are:

*log4j-core*

* CustomLoggerGenerator
* ExtendedLoggerGenerator
* Generate
* PluginManager

*log4j-jmx-gui*
* ClientGui

*log4j-1.2-api*
* Log4j1ConfigurationConverter

*logging-log4j-tools/log4j-server*
* AbstractSocketServer
* TcpSocketServer



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LOG4NET-567) Use new csproj format to target multiple frameworks

[Dominik Psenner (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4NET-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125429#comment-16125429
 ] 

Dominik Psenner commented on LOG4NET-567:
-

The diff looks good so far except that there are no traces of the mono 
frameworks. Anyway, would you like to rebase or merge your changes onto develop 
and file a pull request to see what jenkins thinks about this? I expect that 
you'll have to tweak the nant files a little but since that relates to my 
ongoing work I wouldn't mind your help. :-)

> Use new csproj format to target multiple frameworks
> ---
>
> Key: LOG4NET-567
> URL: https://issues.apache.org/jira/browse/LOG4NET-567
> Project: Log4net
>  Issue Type: Improvement
>Reporter: Peter Jas
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> I have noticed that recently all the csprojs are converged to one monolithic 
> "old-style" csproj. It is an improvement but what about xproj and .NET Core?
> Instead of having xproj+project.json and csproj with two solution files and 
> multiple packages.config files in the repo, use modern csproj format, which 
> is compact, clear, able to target multiple platforms at once, does not 
> require any additional packages.config etc. file.
> bq. The idea is to remove netstandard directory from the root and maintain 
> only new-format csproj file.
> Additional advantange include easy to package for _all supported platforms_ 
> with ONE command: [{{dotnet 
> pack}}|https://docs.microsoft.com/en-us/dotnet/articles/core/tools/dotnet-pack].
> Example: 
> https://github.com/JamesNK/Newtonsoft.Json/blob/b311d91/Src/Newtonsoft.Json/Newtonsoft.Json.csproj.
>  James is supporting the whole JSON.NET for .NET Framework 2.0 to .NET 
> Standard 1.3 with a single new-csproj file.
> Sometimes we want to explicitly target mono, other times the neutral grouds 
> like PCL or NetStandard1.0 do the job. An example of explict targeting:
> {code:xml}
> net45;netstandard1.1;netstandard1.3;win81;MonoAndroid7;Xamarin.iOS10
> {code}
> see this example in action: 
> https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/blob/0ae178520/src/Microsoft.Identity.Client/Microsoft.Identity.Client.csproj
> Also See: 
> https://docs.microsoft.com/en-us/dotnet/core/tools/project-json-to-csproj
> and http://www.natemcmaster.com/blog/2017/03/09/vs2015-to-vs2017-upgrade/
> ---
> You can also try creating a new solution in VS2017 with dotnet core project 
> to get familiar with new csproj format. If you are not using VS2017 or VS 
> Code, then dotnet-cli can give a quick sneak peak:
> {code}
> mkdir test && cd $_
> dotnet new classlib -n mylib
> dotnet new console -n myapp
> dotnet add myapp.csproj reference mylib.csproj
> # dotnet restore && dotnet run
> {code}
> Then see the structure of mylib.csproj and myapp.csproj.
> ---
> Issues with new project system (which supports the new-csproj structure) can 
> be reported at https://github.com/dotnet/project-system. Note that in that 
> repo 15.3 milestone is next in line which will bring new features and fix 
> some existing complains: 
> https://github.com/dotnet/project-system/milestone/7. However the current 
> 15.2 version is working out fine for us in production.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125417#comment-16125417
 ] 

ASF GitHub Bot commented on LOG4J2-928:
---

Github user remkop commented on the issue:

https://github.com/apache/logging-log4j2/pull/87
  
@leventov We may have a Log4j 2.9 release starting as soon as this weekend. 
Let me know if you want to make the remaining changes to complete this PR for 
merging into master before that release.


> Lock-free synchronous sub-microsecond appender
> --
>
> Key: LOG4J2-928
> URL: https://issues.apache.org/jira/browse/LOG4J2-928
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Appenders
>Reporter: Remko Popma
>
> _(This is a work in progress.)_
> *Goal*
> It should be possible to create synchronous file appenders with (nearly) the 
> same performance as async loggers.
> *Background*
> The key to the async loggers performance is the lock-free queue provided by 
> the LMAX Disruptor. Multiple threads can add events to this queue without 
> contending on a lock. This means throughput scales linearly with the number 
> of threads: more threads = more throughput.
> With a lock-based design, on the other hand, performance maxes out with a 
> single thread logging. Adding more threads does not help. In fact, total 
> logging throughput goes down slightly when multiple threads are logging (see 
> the Async Appenders in the [async performance 
> comparison|http://logging.apache.org/log4j/2.x/manual/async.html#Asynchronous_Throughput_Comparison_with_Other_Logging_Packages]).
>  Lock contention means that multiple threads together end up logging slower 
> than a single thread.
> *Currently only async loggers are lock-free*
> Log4j2 provides good performance with async loggers, but this approach has 
> several drawbacks:
> * dependency on external LMAX disruptor library
> * possibility of data loss: log events that have been put on the queue but 
> not flushed to disk yet may be lost in the event of an application crash
> This ticket proposes a new feature to address these issues.
> *Proposal: a lock-free synchronous appender*
> For a single-threaded application the current MemoryMappedFileAppender has 
> performance comparable to Async Loggers (TODO: perf test).
> However, the current implementation uses locks to control concurrency, and 
> suffers from lock contention in multi-threaded scenarios.
> For inspiration for a lock-free solution, we can look at 
> [Aeron|https://github.com/real-logic/Aeron], specifically Aeron's design for 
> Log Buffers. Martin Thompson's September 2014 Strangeloop 
> [presentation|https://www.youtube.com/watch?v=tM4YskS94b0] gives details on 
> the design (especially the section 16:45-23:30 is relevant).
> The way this works, is that instead of using locks, concurrency is handled 
> with a protocol where threads "reserve" blocks of memory atomically. Each 
> thread (having serialized the log event) knows how many bytes it wants to 
> write. It then atomically moves the buffer tail pointer by that many bytes 
> using a CAS operation. After the tail has been moved, the thread is free to 
> write the message payload bytes to the area of the buffer that it just 
> reserved, without needing to worry about other threads. Between threads, the 
> only point of contention is the tail pointer, which is similar to the 
> disruptor. We can reasonably expect performance to scale linearly with the 
> number threads, like async loggers.
> *Still needs work*
> This looks promising, but there are a few snags. 
> # Needs the Unsafe. {{java.nio.ByteBuffer}} only provides relative, not 
> absolute bulk put operations. That is, it only allows appending byte arrays 
> at the current cursor location, not at some user-specified absolute location. 
> The above design requires random access to be thread-safe. Aeron works around 
> this by using {{sun.misc.Unsafe}}. Users should be aware of this so they can 
> decide on whether the performance gain is worth the risk. Also, this may make 
> the OSGi folks unhappy (see LOG4J2-238 discussion)... Not sure how serious we 
> are about making Log4j2 work on OSGi, but perhaps it is possible to mark the 
> package for this feature as optional in the OSGi manifest. An alternative may 
> be to put this appender in a separate module.
> # TBD: How many files/buffers to use? In his presentation Martin mentions 
> that using a single large memory mapped file will cause a lot of page faults, 
> page cache churn, and unspecified VM issues. He recommends cycling between 
> three smaller buffers, one active (currently written to), one dirty (full, 
> now being processed by a background thread) and one clean (to swap in when 
> the active buffer becomes full). I am not sure if the page fault problem will 
> occur for our 

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

[remkop]

Github user remkop commented on the issue:

https://github.com/apache/logging-log4j2/pull/87
  
@leventov We may have a Log4j 2.9 release starting as soon as this weekend. 
Let me know if you want to make the remaining changes to complete this PR for 
merging into master before that release.


---
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: [jira] [Updated] (LOG4J2-2010) Allow customization of the conversion from logger names to logger hierarchy

[Dominik Psenner]

I've just investigated whether this would be something that log4net could
need too, but it looks like C# (dot net) always uses a dot to split
namespaces:

https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/namespaces/using-namespaces

Maybe there are other usecases (like generic classes), therefore I would
like to know what the community thinks. Do you think this feature makes
sense for log4net?

2017-08-14 10:29 GMT+02:00 Dominik Psenner (JIRA) :

>
>  [ https://issues.apache.org/jira/browse/LOG4J2-2010?page=
> com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Dominik Psenner updated LOG4J2-2010:
> 
> Description:
> Class paths are currently split into a hierarchy of loggers. Private
> classes however are not put as a child of their containing class logger
> because their classpath contains a dollar sign ($). To allow this usecase
> it has been discussed to add a logger hierarchy calculation strategy that
> determines how the logger hierarchy is built from a classpath.
>
> By default the default implementation of the hierarchy calculations
> strategy should split a class path by a dot (.). It should further allow
> splitting by other common separators like a dollar and a slash ($ and /) to
> accomodate more use cases. It should also be possible to split by multiple
> separator characters at the same time, meaning that the logger hierarchy
> could be split by either a dot, a dollar or a slash or arbitrary other
> characters as well.
>
> It is yet to be discussed whether we the user should be able to provide a
> custom implementation of the hierarchy calculation strategy. If so, the
> configuration of that strategy must allow the class notation. If the user
> cannot provide a custom implementation, the following configuration syntax
> should suffice as suggested by Gary:
>
> {code}
>  {code}
>
> while the default configuration would be:
>
> {code}
>  {code}
>
>   was:
> Class paths are currently split into a hierarchy of loggers. Private
> classes however are subclassed into their containing class with a dollar
> sign ($) which is currently not reflected as an entry in the logger
> hierarchy. It has been discussed to allow the customization of the logger
> hierarchy calculation strategy.
>
> By default the default implementation of the hierarchy calculations
> strategy should split a class path by a dot (.). It should further allow
> splitting by other common separators like a dollar and a slash ($ and /) to
> accomodate more use cases. It should also be possible to split by multiple
> separator characters at the same time, meaning that the logger hierarchy
> could be split by either a dot, a dollar or a slash or arbitrary other
> characters as well.
>
> It is yet to be discussed whether we the user should be able to provide a
> custom implementation of the hierarchy calculation strategy. If so, the
> configuration of that strategy must allow the class notation. If the user
> cannot provide a custom implementation, the following configuration syntax
> should suffice as suggested by Gary:
>
> {code}
>  {code}
>
> while the default configuration would be:
>
> {code}
>  {code}
>
>
> > Allow customization of the conversion from logger names to logger
> hierarchy
> > 
> ---
> >
> > Key: LOG4J2-2010
> > URL: https://issues.apache.org/jira/browse/LOG4J2-2010
> > Project: Log4j 2
> >  Issue Type: Improvement
> >  Components: Core
> >Reporter: Dominik Psenner
> >Priority: Minor
> >
> > Class paths are currently split into a hierarchy of loggers. Private
> classes however are not put as a child of their containing class logger
> because their classpath contains a dollar sign ($). To allow this usecase
> it has been discussed to add a logger hierarchy calculation strategy that
> determines how the logger hierarchy is built from a classpath.
> > By default the default implementation of the hierarchy calculations
> strategy should split a class path by a dot (.). It should further allow
> splitting by other common separators like a dollar and a slash ($ and /) to
> accomodate more use cases. It should also be possible to split by multiple
> separator characters at the same time, meaning that the logger hierarchy
> could be split by either a dot, a dollar or a slash or arbitrary other
> characters as well.
> > It is yet to be discussed whether we the user should be able to provide
> a custom implementation of the hierarchy calculation strategy. If so, the
> configuration of that strategy must allow the class notation. If the user
> cannot provide a custom implementation, the following configuration syntax
> should suffice as suggested by Gary:
> > {code}
> >  > {code}
> > while the default configuration would be:
> > {code}
> >  > {code}
>
>
>
> --
> This message was sent by 

[jira] [Updated] (LOG4J2-2010) Allow customization of the conversion from logger names to logger hierarchy

[Dominik Psenner (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dominik Psenner updated LOG4J2-2010:

Description: 
Class paths are currently split into a hierarchy of loggers. Private classes 
however are not put as a child of their containing class logger because their 
classpath contains a dollar sign ($). To allow this usecase it has been 
discussed to add a logger hierarchy calculation strategy that determines how 
the logger hierarchy is built from a classpath.

By default the default implementation of the hierarchy calculations strategy 
should split a class path by a dot (.). It should further allow splitting by 
other common separators like a dollar and a slash ($ and /) to accomodate more 
use cases. It should also be possible to split by multiple separator characters 
at the same time, meaning that the logger hierarchy could be split by either a 
dot, a dollar or a slash or arbitrary other characters as well.

It is yet to be discussed whether we the user should be able to provide a 
custom implementation of the hierarchy calculation strategy. If so, the 
configuration of that strategy must allow the class notation. If the user 
cannot provide a custom implementation, the following configuration syntax 
should suffice as suggested by Gary:

{code}
 Allow customization of the conversion from logger names to logger hierarchy
> ---
>
> Key: LOG4J2-2010
> URL: https://issues.apache.org/jira/browse/LOG4J2-2010
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Dominik Psenner
>Priority: Minor
>
> Class paths are currently split into a hierarchy of loggers. Private classes 
> however are not put as a child of their containing class logger because their 
> classpath contains a dollar sign ($). To allow this usecase it has been 
> discussed to add a logger hierarchy calculation strategy that determines how 
> the logger hierarchy is built from a classpath.
> By default the default implementation of the hierarchy calculations strategy 
> should split a class path by a dot (.). It should further allow splitting by 
> other common separators like a dollar and a slash ($ and /) to accomodate 
> more use cases. It should also be possible to split by multiple separator 
> characters at the same time, meaning that the logger hierarchy could be split 
> by either a dot, a dollar or a slash or arbitrary other characters as well.
> It is yet to be discussed whether we the user should be able to provide a 
> custom implementation of the hierarchy calculation strategy. If so, the 
> configuration of that strategy must allow the class notation. If the user 
> cannot provide a custom implementation, the following configuration syntax 
> should suffice as suggested by Gary:
> {code}
>  {code}
> while the default configuration would be:
> {code}
>  {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [jira] [Updated] (LOG4J2-2010) Allow customization of the conversion from logger names to logger hierarchy

[Dominik Psenner]

Please discuss whether we want to give the user the possibility to inject a
custom implementation of a logger hierarchy calculation strategy.

2017-08-14 10:24 GMT+02:00 Dominik Psenner (JIRA) :

>
>  [ https://issues.apache.org/jira/browse/LOG4J2-2010?page=
> com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Dominik Psenner updated LOG4J2-2010:
> 
> Description:
> Class paths are currently split into a hierarchy of loggers. Private
> classes however are subclassed into their containing class with a dollar
> sign ($) which is currently not reflected as an entry in the logger
> hierarchy. It has been discussed to allow the customization of the logger
> hierarchy calculation strategy.
>
> By default the default implementation of the hierarchy calculations
> strategy should split a class path by a dot (.). It should further allow
> splitting by other common separators like a dollar and a slash ($ and /) to
> accomodate more use cases. It should also be possible to split by multiple
> separator characters at the same time, meaning that the logger hierarchy
> could be split by either a dot, a dollar or a slash or arbitrary other
> characters as well.
>
> It is yet to be discussed whether we the user should be able to provide a
> custom implementation of the hierarchy calculation strategy. If so, the
> configuration of that strategy must allow the class notation. If the user
> cannot provide a custom implementation, the following configuration syntax
> should suffice as suggested by Gary:
>
> {code}
>  {code}
>
> while the default configuration would be:
>
> {code}
>  {code}
>
>   was:
> Class paths are currently split into a hierarchy of loggers. Private
> classes however are subclassed into their containing class with a dollar
> sign ($) which is currently not reflected as an entry in the logger
> hierarchy. It has been discussed to allow the customization of the logger
> hierarchy calculation strategy.
>
> By default the default implementation of the hierarchy calculations
> strategy should split a class path by a dot (.). It should further allow
> splitting by other common separators like a dollar and a slash ($ and /) to
> accomodate more use cases. It should also be possible to split by multiple
> separator characters at the same time, meaning that the logger hierarchy
> could be split by either a dot, a dollar or a slash or arbitrary other
> characters as well.
>
> It is yet to be discussed whether we the user should be able to provide a
> custom implementatino of the hierarchy calculation strategy.
>
>
> > Allow customization of the conversion from logger names to logger
> hierarchy
> > 
> ---
> >
> > Key: LOG4J2-2010
> > URL: https://issues.apache.org/jira/browse/LOG4J2-2010
> > Project: Log4j 2
> >  Issue Type: Improvement
> >  Components: Core
> >Reporter: Dominik Psenner
> >Priority: Minor
> >
> > Class paths are currently split into a hierarchy of loggers. Private
> classes however are subclassed into their containing class with a dollar
> sign ($) which is currently not reflected as an entry in the logger
> hierarchy. It has been discussed to allow the customization of the logger
> hierarchy calculation strategy.
> > By default the default implementation of the hierarchy calculations
> strategy should split a class path by a dot (.). It should further allow
> splitting by other common separators like a dollar and a slash ($ and /) to
> accomodate more use cases. It should also be possible to split by multiple
> separator characters at the same time, meaning that the logger hierarchy
> could be split by either a dot, a dollar or a slash or arbitrary other
> characters as well.
> > It is yet to be discussed whether we the user should be able to provide
> a custom implementation of the hierarchy calculation strategy. If so, the
> configuration of that strategy must allow the class notation. If the user
> cannot provide a custom implementation, the following configuration syntax
> should suffice as suggested by Gary:
> > {code}
> >  > {code}
> > while the default configuration would be:
> > {code}
> >  > {code}
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.14#64029)
>



-- 
Dominik Psenner

[jira] [Updated] (LOG4J2-2010) Allow customization of the conversion from logger names to logger hierarchy

[Dominik Psenner (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dominik Psenner updated LOG4J2-2010:

Description: 
Class paths are currently split into a hierarchy of loggers. Private classes 
however are subclassed into their containing class with a dollar sign ($) which 
is currently not reflected as an entry in the logger hierarchy. It has been 
discussed to allow the customization of the logger hierarchy calculation 
strategy.

By default the default implementation of the hierarchy calculations strategy 
should split a class path by a dot (.). It should further allow splitting by 
other common separators like a dollar and a slash ($ and /) to accomodate more 
use cases. It should also be possible to split by multiple separator characters 
at the same time, meaning that the logger hierarchy could be split by either a 
dot, a dollar or a slash or arbitrary other characters as well.

It is yet to be discussed whether we the user should be able to provide a 
custom implementation of the hierarchy calculation strategy. If so, the 
configuration of that strategy must allow the class notation. If the user 
cannot provide a custom implementation, the following configuration syntax 
should suffice as suggested by Gary:

{code}
 Allow customization of the conversion from logger names to logger hierarchy
> ---
>
> Key: LOG4J2-2010
> URL: https://issues.apache.org/jira/browse/LOG4J2-2010
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Dominik Psenner
>Priority: Minor
>
> Class paths are currently split into a hierarchy of loggers. Private classes 
> however are subclassed into their containing class with a dollar sign ($) 
> which is currently not reflected as an entry in the logger hierarchy. It has 
> been discussed to allow the customization of the logger hierarchy calculation 
> strategy.
> By default the default implementation of the hierarchy calculations strategy 
> should split a class path by a dot (.). It should further allow splitting by 
> other common separators like a dollar and a slash ($ and /) to accomodate 
> more use cases. It should also be possible to split by multiple separator 
> characters at the same time, meaning that the logger hierarchy could be split 
> by either a dot, a dollar or a slash or arbitrary other characters as well.
> It is yet to be discussed whether we the user should be able to provide a 
> custom implementation of the hierarchy calculation strategy. If so, the 
> configuration of that strategy must allow the class notation. If the user 
> cannot provide a custom implementation, the following configuration syntax 
> should suffice as suggested by Gary:
> {code}
>  {code}
> while the default configuration would be:
> {code}
>  {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (LOG4J2-2010) Allow customization of the conversion from logger names to logger hierarchy

[Dominik Psenner (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dominik Psenner updated LOG4J2-2010:

Description: 
Class paths are currently split into a hierarchy of loggers. Private classes 
however are subclassed into their containing class with a dollar sign ($) which 
is currently not reflected as an entry in the logger hierarchy. It has been 
discussed to allow the customization of the logger hierarchy calculation 
strategy.

By default the default implementation of the hierarchy calculations strategy 
should split a class path by a dot (.). It should further allow splitting by 
other common separators like a dollar and a slash ($ and /) to accomodate more 
use cases. It should also be possible to split by multiple separator characters 
at the same time, meaning that the logger hierarchy could be split by either a 
dot, a dollar or a slash or arbitrary other characters as well.

It is yet to be discussed whether we the user should be able to provide a 
custom implementatino of the hierarchy calculation strategy.

  was:
Class paths are currently split into a hierarchy of loggers. Private classes 
however are subclassed into their containing class with a dollar sign ($) which 
is currently not reflected as an entry in the logger hierarchy. It has been 
discussed to allow the customization of the logger hierarchy calculation 
strategy.

By default the default implementation of the hierarchy calculations strategy 
should split a class path by a dot (.). It should further allow splitting by 
other common separators like a dot and a slash (. and /) to accomodate more use 
cases.

It is yet to be discussed whether we the user should be able to provide a 
custom implementatino of the hierarchy calculation strategy.


> Allow customization of the conversion from logger names to logger hierarchy
> ---
>
> Key: LOG4J2-2010
> URL: https://issues.apache.org/jira/browse/LOG4J2-2010
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Dominik Psenner
>Priority: Minor
>
> Class paths are currently split into a hierarchy of loggers. Private classes 
> however are subclassed into their containing class with a dollar sign ($) 
> which is currently not reflected as an entry in the logger hierarchy. It has 
> been discussed to allow the customization of the logger hierarchy calculation 
> strategy.
> By default the default implementation of the hierarchy calculations strategy 
> should split a class path by a dot (.). It should further allow splitting by 
> other common separators like a dollar and a slash ($ and /) to accomodate 
> more use cases. It should also be possible to split by multiple separator 
> characters at the same time, meaning that the logger hierarchy could be split 
> by either a dot, a dollar or a slash or arbitrary other characters as well.
> It is yet to be discussed whether we the user should be able to provide a 
> custom implementatino of the hierarchy calculation strategy.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (LOG4J2-2010) Allow customization of the conversion from logger names to logger hierarchy

[Dominik Psenner (JIRA)]

Dominik Psenner created LOG4J2-2010:
---

 Summary: Allow customization of the conversion from logger names 
to logger hierarchy
 Key: LOG4J2-2010
 URL: https://issues.apache.org/jira/browse/LOG4J2-2010
 Project: Log4j 2
  Issue Type: Improvement
  Components: Core
Reporter: Dominik Psenner
Priority: Minor


Class paths are currently split into a hierarchy of loggers. Private classes 
however are subclassed into their containing class with a dollar sign ($) which 
is currently not reflected as an entry in the logger hierarchy. It has been 
discussed to allow the customization of the logger hierarchy calculation 
strategy.

By default the default implementation of the hierarchy calculations strategy 
should split a class path by a dot (.). It should further allow splitting by 
other common separators like a dot and a slash (. and /) to accomodate more use 
cases.

It is yet to be discussed whether we the user should be able to provide a 
custom implementatino of the hierarchy calculation strategy.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)