Re: picocli in log4j

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 J

Logger names for nested classes

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

Re: Logger names for nested classes

Hi, Why does that matter? Gary On Aug 12, 2017 12:34, "Dominik Psenner" wrote: > Are the nested classes private or public? > > 2017-08-12 20:29 GMT+02:00 Gary Gregory : > > > Hi All, > > > > I you use nested classes to build loggers, you end up with lo

Re: Logger names for nested classes

. It is often a bash variable > and thus bound to be typo prone when used for greps, configurations, .. > > Could a logger name attribute be an option? > What do you mean? Gary > > 2017-08-12 20:44 GMT+02:00 Gary Gregory : > > > Hi, > > > > Why does that m

Re: Logger names for nested classes

ot really sure how it could. > > > > Ralph > > > > > On Aug 12, 2017, at 11:29 AM, Gary Gregory > > wrote: > > > > > > Hi All, > > > > > > I you use nested classes to build loggers, you end up with logger names > > > lik

Re: Logger names for nested classes

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 Au

Re: Logger names for nested classes

Sure why not. I just want to nail down the spec before we get caught up in implementation details. Gary On Aug 13, 2017 13:53, "Dominik Psenner" wrote: > What about a LoggerHierarchySeparationStrategy interface along with a > default impl? > > On 13 Aug 2017 9:37 p.m.,

Re: Logger names for nested classes

Recapping: Using it: 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 $? > >

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

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

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

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 Au

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

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

Re: Logger names for nested classes

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

Re: Logger names for nested classes

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

Re: Logger names for nested classes

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 dow

Re: Logger names for nested classes

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

Re: Logger names for nested classes

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

Re: Logger names for nested classes

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: > &g

Re: Logger names for nested classes

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

Re: logging-log4j2 git commit: [LOG4J2-2015] Allow KeyStoreConfiguration and TrustStoreConfiguration to find files as resources.

-log4j2/tree/ > 741be7fc > > Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/ > 741be7fc > > > > Branch: refs/heads/master > > Commit: 741be7fc61529147969afa4bd05cebc6cdac9c91 > > Parents: e2f9d5e > > Author

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

JAnsi uses the same trick JNA uses: The native libraries it needs for each OS is embedded inside the JAR itself. At runtime, the library detects the OS and extracts the right native library from itself. Gary On Wed, Aug 16, 2017 at 1:52 PM, mikaelstaldal wrote: > Github user mikaelstaldal comme

SocketOptions builder

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

Re: SocketOptions builder

nks for making that change. > > > On Fri, Aug 18, 2017 at 5:41 AM, Gary Gregory > wrote: > > > Hi All and FYI: > > > > I plan on redoing the SocketOptions class as a real builder by making all > > accessors return this. > > > > Any objections? > > > > Gary > > >

Re: Logger names for nested classes

Any opposition to using the canonical name? Gary On Aug 14, 2017 15:28, "Gary Gregory" wrote: > In LogManager, if we call getCanonicalName() instead of getName(), we only > get "."s, no "$"s... > > How about that? > > Gary > >

Re: Logger names for nested classes

t; > >> build logger hierarchies from class names, but it is also something > that > > >> only a very small subset of users would use. We can keep that as a > wish > > for > > >> later. > > >> > > >> 2017-08-19 20:13 GMT+02:0

Re: Logger names for nested classes

. > > > > Also: does Class.getCanonicalName() preserve the trailing $ in Scala > > classes? > > > > (Shameless plug) Every java main() method deserves http://picocli.info > > > > > On Aug 20, 2017, at 15:43, Ralph Goers > > wrote: > > >

Re: SocketOptions builder

i.info > > > On Aug 18, 2017, at 7:18, Gary Gregory wrote: > > > > What I did not do is change the "set" methods to "with" to avoid breaking > > user sources. We should do that for 3.0 I think. > > > > Gary > > > >> On Thu,

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

Hi All: I have a need for the shortcut method org.apache.logging.log4j.core.LoggerContext getLogger(Class) which would use getCannonicalName(). Any objection to adding that? Gary

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

, Ralph Goers wrote: > Did you ask this question last week? Why is it needed? Why can’t this be > handled in LogManager? > > Ralph > > > On Aug 21, 2017, at 2:10 PM, Gary Gregory > wrote: > > > > Hi All: > > > > I have a need for the shortcut method

Re: [log4j2] sys props driving me nuts

On Thu, Jul 20, 2017 at 9:05 PM, Gary Gregory wrote: > On Thu, Jul 20, 2017 at 7:19 PM, Matt Sicker wrote: > >> I haven't been able to get to this so far this week. Been finishing up a >> project for work. I should hopefully have enough time to merge this >> tomo

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

odify Log4j’s LoggerContext simply so you can modify yours? > > Ralph > > > On Aug 21, 2017, at 3:01 PM, Gary Gregory > wrote: > > > > My use case is that deep in the guts and call stack of my server/app, I > > have a specific Core LoggerContext that I should/mus

Re: [log4j2] sys props driving me nuts

2017, at 3:25 PM, Gary Gregory > wrote: > > > > On Thu, Jul 20, 2017 at 9:05 PM, Gary Gregory > > wrote: > > > >> On Thu, Jul 20, 2017 at 7:19 PM, Matt Sicker wrote: > >> > >>> I haven't been able to get to this so far this week. Been finis

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

'm all about humoring the ML :-) Any further thoughts on adding these APIs? For or against? Gary > > Ralph > > > On Aug 21, 2017, at 3:42 PM, Gary Gregory > wrote: > > > > Hi, > > > > When someone calls any of the init methods like > > or

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

That is a much bigger topic than the one core API I am talking about. Gary On Aug 21, 2017 18:35, "Matt Sicker" wrote: > I'd rather we had a log4j-api way to initialise configuration outside the > default class initialisation path. > > On 21 August 2017 at 19:24, Ga

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

; On Aug 21, 2017, at 5:24 PM, Gary Gregory > wrote: > > > > On Mon, Aug 21, 2017 at 6:01 PM, Ralph Goers > > > wrote: > > > >> It is actually funny that you say that. The API we provide for > performing > >> logging is log4j-api, not log4j-core

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

tice if I found it in > someone’s code for “normal” logging and I would strongly recommend they > change it. > Thanks for the details. I'll read up on the links and sleep on it. Gary > > Ralph > > > On Aug 21, 2017, at 6:45 PM, Gary Gregory > wrote: > >

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

. Regardless of the above, would you say that the interface org.apache.logging.log4j.spi.LoggerContext is also "out of bounds" for normal/non-advanced use cases of "get me a logger" even though it is in the log4j-api module? Thank you again! Gary On Mon, Aug 21, 2017 at 10:34 PM,

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

Because that leave open the original problem, it's too easy to mess up and call getName(). This is a shorthand API just like LogManager.getLogger(Class). I always want to call an API that takes a Class where I can to avoid the mix up. Gary > > On Wed, Aug 23, 2017 at 12:32 AM, Gary Gr

Help with LOG4J2-2009

Hi All, Looking for help to fix this or document a workaround: https://issues.apache.org/jira/browse/LOG4J2-2009 Gary

Re: [log4j2] sys props driving me nuts

e free until Wednesday night at the earliest. If Ralph wants to > > start the release before that, I'm alright with that. > > > > On 21 August 2017 at 17:43, Gary Gregory wrote: > > > >> Sweet. I've been going through the back log and picking some low-

Re: [log4j2] sys props driving me nuts

t this point. I'll be handling > >> documentation updates along with trying to copy over all the old > property > >> names into a full unit test to verify the old names always work in the > >> future for BC. > >> > >> On 23 August 2017 at 14:59, Ga

Re: Release build failed

How about trying with Java 8? G On Aug 26, 2017 14:00, "Matt Sicker" wrote: > I don't see anything wrong with that test. Strange. > > On 26 August 2017 at 14:45, Ralph Goers > wrote: > > > The release build failed with something I have never seen before. I am > > going to try a normal build a

Re: [VOTE] Release Log4j 2.9.0-rc1

cumentation for LoggerNameLevelRewritePolicy. > LOG4J2-922 <https://issues.apache.org/jira/browse/LOG4J2-922>: Parameter > of mdcId in SyslogAppender has no default value. Thanks to angus.aqlu, Paul > Burrowes. > LOG4J2-2001 <https://issues.apache.org/jira/browse/LOG4J2-2001&

Re: [VOTE] Release Log4j 2.9.0-rc1

d in SyslogAppender has no default value. Thanks to angus.aqlu, Paul > Burrowes. > LOG4J2-2001 <https://issues.apache.org/jira/browse/LOG4J2-2001>: > StyleConverter.newInstance argument validation is incorrect. Thanks to Paul > Burrowes. > LOG4J2-1999 <https://issues.a

Re: [VOTE] Release Log4j 2.9.0-rc1

1 <https://issues.apache.org/jira/browse/LOG4J2-2001>: > StyleConverter.newInstance argument validation is incorrect. Thanks to Paul > Burrowes. > LOG4J2-1999 <https://issues.apache.org/jira/browse/LOG4J2-1999>: > HighlightConverter converts all unrecognized level

Re: [VOTE] Release Log4j 2.9.0-rc1

On Sun, Aug 27, 2017 at 8:12 AM, Gary Gregory wrote: > From src zip file and using guidance from BUILDING.md > > ASC, MD5, SHA1, OK. > FYI: I was able to validate against a KEYS file I imported previously. Gary > > RAT check OK > > mvn clean install OK > > C

Re: [VOTE] Release Log4j 2.9.0-rc1

On Sun, Aug 27, 2017 at 8:12 AM, Gary Gregory wrote: > From src zip file and using guidance from BUILDING.md > > ASC, MD5, SHA1, OK. > > RAT check OK > > mvn clean install OK > > CLIRR check OK but MUST be done AFTER the above and I get: > > [INFO] --- clirr-ma

Re: [VOTE] Release Log4j 2.9.0-rc1

gt; same date for LOG4J2-1935. I believe you moved the method into MapMessage > so this shouldn’t be a problem. > 3. ReflectionUtil was eliminated as part of implementing the support for > StackWalker. The class was documented as private so it should not be a > problem to remo

Re: [VOTE] Release Log4j 2.9.0-rc1

ed until after 2.8 according to the tags: > > > > https://github.com/apache/logging-log4j2/commit/ > > 33f97a804b6f44364b5913cd5a893c1b55a6 > > > > > >> > >> Ralph > >> > >> > On Aug 27, 2017, at 7:50 AM, Gary Gregory > >> wrote: > >

Re: [VOTE] Release Log4j 2.9.0-rc1

ust 2017 at 10:18, Matt Sicker wrote: > > > I do like the full version number, but I'm just comparing to historical > > releases: > > > > https://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org. > > apache.logging.log4j%22%20AND%20a%3A%22log4j-api%22 > > >

Re: [VOTE] Release Log4j 2.9.0-rc1

.0 releases. > > > > On 28 August 2017 at 10:18, Matt Sicker wrote: > > > >> I do like the full version number, but I'm just comparing to historical > >> releases: > >> > >> https://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.

Re: [VOTE] Release Log4j 2.9.0-rc1

I'm just comparing to historical > > releases: > > > > https://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org. > > apache.logging.log4j%22%20AND%20a%3A%22log4j-api%22 > > > > On 28 August 2017 at 10:17, Gary Gregory wrote: > > > >> It sor

Module log4j-core-its not in MC

Hi All, My build is going fine with 2.9.0 from MC but I do not see the log4j-core-its in MC: https://search.maven.org/#search%7Cga%7C1%7Ca%3A%22log4j-core-its%22 Shouldn't it be there? Gary

Re: Module log4j-core-its not in MC

But I think that is a _good_ thing to have all modules published. Gary On Wed, Aug 30, 2017 at 9:20 AM, Matt Sicker wrote: > I was the one who published 2.8.2, and I think I simply forgot to delete > that from the staging repo before releasing. > > On 30 August 2017 at 09:46,

Re: [Log4j] Public beta release

That might help but some folks will only use releases... Gary On Thu, Aug 31, 2017 at 1:51 PM, Mikael Ståldal wrote: > Yet again some users find bugs right after release of a minor version, so > far LOG4J2-2023 and LOG4J2-2026. > > Maybe we should do a public beta before next minor release (2.1

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

Maybe we should force use of Maven 3.5.0 to allow newer plugins to be used. Gary On Sep 2, 2017 17:39, "Apache Jenkins Server" wrote: > See redirect?page=changes> > > Changes: > > [garydgregory] [LOG4J2-2029] Marker examples should not

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

The word container is so vague... container of what? Files, Applications, NoSQL things? How about app-container? Gary On Wed, Sep 6, 2017 at 4:07 PM, Remko Popma wrote: > log4j-container? > (To be more generic than javaee) > > > > On Sep 7, 2017, at 4:56, Ralph Goers wrote: > > > > Yes, the in

Re: Log4J 2.9.1 release

Hi All, It seems to me that the recent addition of the log4j-appserver module requires a version bump to 2.10.0, not 2.9.1. Gary On Mon, Sep 11, 2017 at 8:25 AM, Matt Sicker wrote: > I still have my outstanding branch that didn't make it into 2.9.0 that's > ready to merge, though if you're rea

Re: Log4J 2.9.1 release

lass. That said, if others feel that 2.10.0 is better I am happy to > accommodate. > > Ralph > > > On Sep 11, 2017, at 8:31 AM, Gary Gregory > wrote: > > > > Hi All, > > > > It seems to me that the recent addition of the log4j-appserver module > > r

Re: Automatic module names

On Mon, Sep 11, 2017 at 11:27 AM, Ralph Goers wrote: > I know we discussed module names in the past and decided not to go the > route of modularizing now - in fact, we can’t until all of our dependencies > are modularized. However, we can (and probably should) add the automatic > module name as a

Fwd: Build failed in Jenkins: Log4j 2.x #3051

A local build worked for me (mvn clean install), this looks a Nexus issue maybe. Gary -- Forwarded message -- From: Apache Jenkins Server Date: Mon, Sep 11, 2017 at 12:36 PM Subject: Build failed in Jenkins: Log4j 2.x #3051 To: dev@logging.apache.org See

Random failure in AsyncLoggerAndAsyncAppenderTest

Just FYI: I am seeing this random but infrequent failure: [ERROR] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.62 s <<< FAILURE! - in org.apache.logging.log4j.core.async.AsyncLoggerThreadContextGarbageFreeTest [ERROR] testAsyncLogWritesToLog[GARBAGE_FREE BOTH_ALL_ASYNC_AND_MI

Fwd: Build failed in Jenkins: Log4j 2.x #3052

Frak! What could cause the JConsolePlugin class to not be found? Gary -- Forwarded message -- From: Apache Jenkins Server Date: Mon, Sep 11, 2017 at 2:17 PM Subject: Build failed in Jenkins: Log4j 2.x #3052 To: dev@logging.apache.org See

Re: Log4J 2.9.1 release

.9.1 > without it. I think that would be good given that we had quite some > regressions in 2.9.0. > > > > > > On 2017-09-11 17:34, Ralph Goers wrote: > >> I thought about that, but it really is a pretty minor addition - it is > one class. That said, if others feel

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

I fixed something I broke... Gary On Sep 11, 2017 18:08, "Matt Sicker" wrote: > I wonder if the jenkins java config changed at all. That class is in > tools.jar I believe. > > On 11 September 2017 at 16:02, Gary Gregory > wrote: > > > Frak! What could cause

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

On Sep 11, 2017 21:43, "Matt Sicker" wrote: Looking closer, it says it cannot find the symbol, not the class. Missing import statement. Yep, already fixed a while back. :-) Gary On 11 September 2017 at 21:36, Gary Gregory wrote: > I fixed something I broke... > > Gary

[log4j] Cassandra driver

Hi Matt (I think, since you may have the best knowledge on this one), Did you know that trying the latest Cassandra jars cause the tests to fail? It seems there is some mismatch with Netty versions and APIs coming and going. Let me know if you can take a look. Gary

Re: Log4j-core and Android?

I would like to see support for Android, all in our one code base, for now. Gary On Sep 13, 2017 08:02, "Ralph Goers" wrote: > We are getting Jira issues about getting log4j to work in Android. At > first, all I thought was required was getting the API to function on top of > Android’s logging

Re: Log4J 2.9.1 release

That all sounds great! Gary On Thu, Sep 14, 2017 at 1:33 PM, Matt Sicker wrote: > I think we should release 2.9.1. If Ralph doesn't have time this weekend, I > can RM. > > I have a feature (system properties/environment variables normalization) > I'd like to add to 2.10 and am waiting for our b

Re: [VOTE] Release Log4j 2.9.1-rc1

>From src zip: ASC OK, MD5 OK, SHA1 OK. I have seen an Apache Commons release use SHA-512 recently, which is nice. In the future it would be nice if we could use SHA-512 instead of MD5 and SHA1. Apache RAT check OK Must install _before_ running _all_ CLIRR checks. CLIRR checks OK on API and 1.2

Re: [VOTE] Release Log4j 2.9.1-rc1

+1 BTW ;-) Gary On Mon, Sep 18, 2017 at 9:28 AM, Gary Gregory wrote: > From src zip: ASC OK, MD5 OK, SHA1 OK. > > I have seen an Apache Commons release use SHA-512 recently, which is nice. > In the future it would be nice if we could use SHA-512 instead of MD5 and > SHA1. >

Re: [VOTE] Release Log4j 2.9.1-rc1

On Mon, Sep 18, 2017 at 9:28 AM, Gary Gregory wrote: > From src zip: ASC OK, MD5 OK, SHA1 OK. > > I have seen an Apache Commons release use SHA-512 recently, which is nice. > In the future it would be nice if we could use SHA-512 instead of MD5 and > SHA1. > > Apache

[log4j] Scala 2.12.3

Hi All, Scala 2.12.3 has been out for a little while. Do we need a new module to match? Gary

[log4j] "JDK 9 Ready"

Hi, Oracle has asked me if we have an official announcement that we are "JDK 9 ready". Do we? We are listed here: https://wiki.openjdk.java.net/display/quality/Quality+Outreach Gary

Re: [log4j] "JDK 9 Ready"

On Thu, Sep 21, 2017 at 9:39 AM, Ralph Goers wrote: > > > On Sep 21, 2017, at 7:35 AM, Gary Gregory > wrote: > > > > Hi, > > > > Oracle has asked me if we have an official announcement that we are "JDK > 9 > > ready". Do we? > > >

Re: logging-log4j2 git commit: LOG4J2-1896 Update classes in org.apache.logging.log4j.core.net.ssl in APIs from String to a PasswordProvider producing char[] for passwords.

I wonder if this should be called SecretProvider because I am thinking that optionally (or not) the user name can also be a secret. Also there is such a thing as other login info like the "realm" in Windows IIRC. Gary On Sep 23, 2017 11:36, wrote: > Repository: logging-log4j2 > Updated Branches

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

On Mon, Sep 25, 2017 at 10:00 AM, wrote: > Repository: logging-log4j2 > Updated Branches: > refs/heads/master a73fce2e7 -> 08077cba3 > > > LOG4J2-2054 Provide ways to configure SSL that avoid plain-text passwords > in the log4j configuration. The configuration may now specify a system > environ

Re: logging-log4j2 git commit: Update dev mailing list address.

og4j2/tree/ > f1b26358 > > Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/ > f1b26358 > > > > Branch: refs/heads/master > > Commit: f1b2635861e5a3fe6d862b0405a66d8ed24c1f17 > > Parents: b9297a6 > > Author

Re: Binary compatibility for managers in log4j-core

"Within reason" should be the operative term here... IOW, let's not handcuff ourselves unless necessary. Gary On Thu, Oct 5, 2017 at 11:02 AM, Matt Sicker wrote: > Since appenders are usually final classes, I think the only compatibility > there is calling compatibility. For managers, users can

Re: Binary compatibility for managers in log4j-core

How about switching to a Builder like we have been doing for Appenders? Gary On Thu, Oct 5, 2017 at 11:38 AM, Mikael Ståldal wrote: > The specific case is KafkaManager constructor. Can we just add a new > parameter, or should we overload? > > > On 2017-10-05 19:02, Matt Sicker wrote: > >> Since

Re: MapMessage conversion layout %K not working

Also, cross-posting between the dev and user ML is bad form ;-) Gary On Fri, Oct 6, 2017 at 8:49 AM, gaurav9...@gmail.com wrote: > Hi log4j2 users, > > I have created a MapMessage with a key-value pair > > e.g. userName="log4j" > > I have configured JDBCAppender with > > > > But, it gives null

Re: [Log4j] Next release?

as soon as you can RM ;-) :-) Gary On Oct 12, 2017 13:12, "Mikael Ståldal" wrote: Some users are eager to get access to some newly added features: https://github.com/apache/logging-log4j2/pull/110 When do we plan to do a 2.10.0 release?

Re: [Log4j] skipJansi by default

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

Re: Logging list for emails generated by tools

I do not care either way. Gary On Thu, Oct 12, 2017 at 2:34 PM, Ralph Goers wrote: > What do others think about the idea of creating a separate mailing list > for emails generated by tools? This list gets a bit noisy from all the > extra emails and I have a hard time filtering this list because

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

Sigh, but how? G On Thu, Oct 12, 2017 at 5:11 PM, Ralph Goers wrote: > One of the Jenkins servers must be misconfigured. > > Ralph > > > On Oct 12, 2017, at 3:37 PM, Apache Jenkins Server < > jenk...@builds.apache.org> wrote: > > > > See

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

Hi Matt, It seems to me that to get out of the mess we are currently in, we need to publish something official ASAP, even it is just an alpha or beta. Toward this goal, we should make the least amount of changes as possible. Changing the source to 1.6 seems like a requirement to use modern toolin

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

I would really stay away from Java 9 at this point. There is too much incompatible tooling out there at this point. I can't even run most apps out of the box I have laying around on Java 9 without breakage. Gary On Sat, Oct 14, 2017 at 12:09 PM, Matt Sicker wrote: > I forgot to mention my curre

Re: Logging list for emails generated by tools

So mailto:notifications-subscr...@logging.apache.org to subscribe... Gary On Mon, Oct 16, 2017 at 7:53 AM, Ralph Goers wrote: > The mailing list notificati...@logging.apache.org notificati...@logging.apache.org> has been created. All committers should > subscribe. > > Ralph > > > On Oct 15, 20

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

ip-us.apache.org/repos/asf/logging-log4j2/diff/ > ecc2d35a > > > > Branch: refs/heads/master > > Commit: ecc2d35a4d3a90327d8a490edbd00ec8bfaeaea3 > > Parents: ff5e664 > > Author: Gary Gregory > > Authored: Tue Oct 17 08:43:25 2017 -0600 > >

Re: logging-log4j2 git commit: Update Mockito from 2.10.0 to 2.11.0. Build passes with 'mvn clean install'.

ttp://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/ > 2313b947 > > Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/ > 2313b947 > > > > Branch: refs/heads/master > > Commit: 2313b947835126044458c2d14c06268edd1cf9a1 > > Parents:

Java 8 Epic in JIRA.

Hi All, FYI, I created a Java 8 epic in JIRA: https://issues.apache.org/jira/browse/LOG4J2-2080 Gary

Re: Revisiting the binary logging format idea

What about BSON? Gary On Oct 19, 2017 08:41, "Matt Sicker" wrote: > I don't have the ticket on hand, but a few months ago, Remko suggested a > binary logging format that would allow for super fast appends of > log-specific information along with companion files for additional metadata > not com

Re: Revisiting the binary logging format idea

o with Avro or Thrift > since > > > LogEvents have a lot of standard fields with only a few optional > map-like > > > structures. For optimized log appending, the binary format was proposed > > as > > > a way to append quickly and without garbage IIRC. > >

Re: Revisiting the binary logging format idea

ary: this is just another Layout. Should not need another > repo... > Prototyping on another branch makes sense. > > On Fri, Oct 20, 2017 at 1:23 AM, Gary Gregory > wrote: > > > Bleh, ANOTHER repo? We have so many already... but I see what the big > > picture is. Wo

Testing log4j-mongodb

Hi All: In order to do integration tests with MongoDB, we should depend on and use: de.flapdoodle.embed de.flapdoodle.embed.mongo 2.0.0 test This is what I did at work and it works like a charm. Gary

Re: No more log4j-nosql

WRT MongoDB, please see my other email "Testing log4j-mongodb". Thank you, Gary On Thu, Oct 19, 2017 at 2:02 PM, Mikael Ståldal wrote: > If someone has a running MongoDB, CouchDB or Cassandra handy, some manual > testing would be good. > > Especially for MongoDB and CouchDB since we don't have

Re: Test failures in log4j-taglib

Weird. I have been running so manyv local builds for changes I check in. I must have missed that one! Feel free to revert or investigate unless I get to it first. Gary On Oct 21, 2017 08:11, "Mikael Ståldal" wrote: > The problem started here: > https://builds.apache.org/job/Log4j%202.x/3135/ >

Re: Test failures in log4j-taglib

On Thu, Oct 19, 2017 at 2:14 PM, Ralph Goers wrote: > I am wondering why this is suddenly failing. Was it changed recently? > > Ralph > > > On Oct 19, 2017, at 1:00 PM, Mikael Ståldal wrote: > > > > The missing class, javax.servlet.SessionCookieConfig is new in Servlet > API 3.x. In log4j-taglib

Re: Test failures in log4j-taglib

from 2005 (12 years old!) and 3.0 from 2009. Gary [1] https://en.wikipedia.org/wiki/Java_servlet > > Ralph > > > On Oct 23, 2017, at 8:21 AM, Gary Gregory > wrote: > > > > On Thu, Oct 19, 2017 at 2:14 PM, Ralph Goers <mailto:ralph.go...@dslextreme.com>>

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

Wait a sec: How do I enable Jansi in my app _without_ fiddling with system properties? System properties should be considered a hack for things that can't be done in the configuration file. Gary On Tue, Oct 24, 2017 at 8:04 AM, Matt Sicker wrote: > Yes. New property names should all start with

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

On Tue, Oct 24, 2017 at 5:47 PM, Remko Popma wrote: > Mikael, I also don’t like the negative properties. > > Gary, we could remove the `log4j.skipJansi` system property altogether and > instead have an explicit ConsoleAppender config attribute like `loadJansi` > (or something). > This still feel

  1   2   3   4   5   6   7   8   9   10   >