Re: org.apache.logging.log4j.core.config.Configurator.initialize(String, String)

gt;> >> Thoughts? >> >> Gary >> >> >> >> On Tue, Apr 11, 2017 at 10:01 PM, Ralph Goers <ralph.go...@dslextreme.com> >> wrote: >> >>> That’s a good point. It is a programmatic interface so it should return >>> an

Re: Feedback request

uld easily be shaded > into log4j-core for the CLI classes. Very nice! > >> On 15 April 2017 at 09:25, Remko Popma <remko.po...@gmail.com> wrote: >> >> Everyone, I would love your feedback on this: >> >> https://remkop.github.io/picocli/ >> https:/

Re: Feedback request

nd_styles On Sun, Apr 16, 2017 at 8:15 Gary Gregory <garydgreg...@gmail.com> wrote: > I use JCommander a lot. Can you explain the difference? Most applications I > work on depend on other jars, so one more is no biggie. > > Thank you! > Gary > > On Apr 15, 2017 7:25

Re: [log4j] Performance comparsion

Moderated? I noticed that the author enjoys taking strong positions on things but at the same time finds it inconceivable that he could be wrong. On Sat, Apr 15, 2017 at 1:00 AM, Ralph Goers wrote: > I’m not sure why my comment has not appeared… > > Ralph > > > On

Re: Log4net website issue

Asciidoc can include code snippets or whole files: http://asciidoctor.org/docs/user-manual/#include-partial I'm not convinced that it's desirable to generate the user manual from javadoc though. They usually target different audiences so the content is different. Sent from my iPhone > On Apr

Re: [Log4j] Plans for modularization

y uber jars are not going > to work as you can’t have multiple modules that export the same package. > > Ralph > >> On Apr 24, 2017, at 10:43 AM, Remko Popma <remko.po...@gmail.com> wrote: >> >> How many new modules are we talking about, concretely? >&

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

Gary, the change you propose in the LOG4J2-1888 branch look good to me. Should be fine to merge. On Tue, Aug 15, 2017 at 7:20 AM, ASF subversion and git services (JIRA) < j...@apache.org> wrote: > > [ https://issues.apache.org/jira/browse/LOG4J2-1888?page= >

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

OK, I will move them to core.tools. On Wed, Aug 16, 2017 at 4:32 AM, Matt Sicker <boa...@gmail.com> wrote: > I kind of consider the tools package for command line tools, so it sorta > does make sense to include the command line parser in the same package. > > On 14 August 20

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

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

Re: picocli in log4j

I created https://issues.apache.org/jira/browse/LOG4J2-2011 for this. On Thu, Aug 10, 2017 at 8:29 Remko Popma <remko.po...@gmail.com> wrote: > Hi Gary, > > Love the add-ons. Definitely interested. > Let me ping you offlist to see how we can collaborate on this. > >

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

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

Re: [Log4j] 2.9 release and Java 9

* When I said "Java 9 has been on the roadmap" I meant the Log4j 2 roadmap. On Sun, Jul 9, 2017 at 9:15 PM, Remko Popma <remko.po...@gmail.com> wrote: > Not sure I agree. Our interest in Android is a very recent thing. We've > done some work with LOG4J2-1926 > <ht

Re: [Log4j] 2.9 release and Java 9

Not sure I agree. Our interest in Android is a very recent thing. We've done some work with LOG4J2-1926 , we are still discovering new work and I suspect we will keep discovering new issues as we start to take an in-depth look. If anything, let's

Re: [Log4j] 2.9 release and Java 9

I think both Gary and myself had the same misunderstanding about log4j-api-android. I didn't realize it contains a bridge/adapter to the Android logging implementation until you mentioned it. Would `log4j-api-android-impl` be a better name? (Shameless plug) Every java main() method deserves

Re: Releasing 2.9

Updating the performance page with the items you mentioned is on my todo list but I doubt I'll be able to get to it in July or even August. Performance testing, analyzing the results, redoing after finding I measured the wrong thing:-) and finally doing a write up of the results took me several

Re: [JIRA] Editing comments

Reopen the issue. Once the issue is closed, you can only add comments, not edit them. (Shameless plug) Every java main() method deserves http://picocli.info > On Jul 15, 2017, at 4:31, Gary Gregory wrote: > > Hi All, > > What do we have to do to allow us to EDIT

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

I think compilation fails because the class version is incompatible: we're using the 1.7 javac to compile but use the 1.8 jconsole jar as a compilation dependency. (Shameless plug) Every java main() method deserves http://picocli.info > On Jul 18, 2017, at 15:26, Gary Gregory

Re: [Log4j] 2.9 release and Java 9

One problem with the log4j-api-android idea is that it doesn't cover other libraries that bring in a dependency to log4j-api. However, I wouldn't mind saying Log4j 2.9 supports Java 9 but not Android; on Android use Log4j 2.8. (Shameless plug) Every java main() method deserves

Re: Release notes

Release Notes = changes.xml, no? (Shameless plug) Every java main() method deserves http://picocli.info > On Jun 29, 2017, at 19:48, Mikael Ståldal wrote: > > Do we have any place to prepare release notes for an upcoming release, before > actually making the release? > >

Re: [1/2] logging-log4j2 git commit: LOG4J2-1958 Deprecate SerializedLayout and remove it as default

In the manual pages, can we mention that in previous versions the default was SerializedLayout, but as of log4j-2.9 users need to explicitly specify a layout since there is no default? I think it is important to document the log4j version when this change took place. On Wed, Jun 28, 2017 at 9:52

Re: [Log4j] Plans for modularization

ra > - log4j-couchdb > - log4j-mongodb > - log4j-lucene (new, under development) > > > >> On Mon, Apr 24, 2017 at 7:43 PM, Remko Popma <remko.po...@gmail.com> wrote: >> >> How many new modules are we talking about, concretely? >> >> Mat

Re: [Log4j] Plans for modularization

Gregory <garydgreg...@gmail.com> > > wrote: > > > > > We should have consensus on the big picture here... are we all Ok with > > the > > > idea of all modules only having _required_ dependencies? > > > > > > Gary > > > > > > On A

picocli in log4j

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

Re: picocli in log4j

or you library, let me know... > > Gary > > On Aug 4, 2017 12:59, "Remko Popma" <remko.po...@gmail.com> wrote: > > > Thanks all for your positive feedback on picocli <http://picocli.info/> > > back > > in April. > > There have been multiple release

Re: picocli in log4j

ary, though I haven't used it > > for > > > any of my own projects yet (since most of what I've been working on for > > the > > > past several months have all been Mesos-managed containers, so startup > > has > > > been mostly delegated to environment variables for c

Re: SocketOptions builder

I like the idiom where setter methods return `this`, so users can chain methods; thanks for making that change. On Fri, Aug 18, 2017 at 5:41 AM, Gary Gregory wrote: > Hi All and FYI: > > I plan on redoing the SocketOptions class as a real builder by making all >

Re: SocketOptions builder

ces. We should do that for 3.0 I think. > > Gary > >> On Thu, Aug 17, 2017 at 4:10 PM, Remko Popma <remko.po...@gmail.com> wrote: >> >> I like the idiom where setter methods return `this`, so users can chain >> methods; thanks for making that change. >

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

I like the idea of having it as a parameter to ConsoleAppender, that would make it easy for users to find. No problem changing the default behaviour to not using Jansi. Do we still retain the current system property with its current semantics (so setting skipJansi=false would also enable

Re: Logger names for nested classes

No objection to creating logger names from Class.getCanonicalName() instead of Class.getName(). I assume that this means we don't need a custom toLoggerName(Class) method. Question for our Scala experts: does Class.getCanonicalName() preserve the trailing $ in Scala classes? At some point there

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

> On Aug 23, 2017, at 2:22, Gary Gregory <garydgreg...@gmail.com> wrote: > >> On Tue, Aug 22, 2017 at 10:27 AM, Remko Popma <remko.po...@gmail.com> wrote: >> >> What I don't like about this proposal is that LogManager.getLogger(Class) >

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

Yes, renamed in build 166 apparently. https://bugs.openjdk.java.net/browse/JDK-8178347 On Mon, Aug 21, 2017 at 13:40 Remko Popma <remko.po...@gmail.com> wrote: > Jenkins may be using an old Java 9: > > JDK[/home/jenkins/tools/java/jigsaw-jdk-9-ea-b156] > > Also,

Re: Logger names for nested classes

35 PM, Gary Gregory <garydgreg...@gmail.com> wrote: >> >> The only change I am now talking about is replacing getName() with >> getCannonicalName(). >> >> Gary >> >>> On Aug 19, 2017 18:00, "Remko Popma" <remko.po...@gmail.co

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

Jenkins may be using an old Java 9: JDK[/home/jenkins/tools/java/jigsaw-jdk-9-ea-b156] Also, it seems this method was previously called `getPid`. It must have been renamed recently. http://www.javaworld.com/article/3176874/java-language/java-9s-other-new-enhancements-part-3.html On Mon, Aug

Re: Java 9 modules

(Shameless plug) Every java main() method deserves http://picocli.info > On May 9, 2017, at 15:35, Gary Gregory wrote: > > Hi All, > > On Mon, May 8, 2017 at 10:46 PM, Ralph Goers > wrote: > >> So I keep reading up on Java modules and

Re: Java9

One idea: we could move (actually copy) the StackLocator interface to the Java 9 module. This allows us to build the Java 9 module first. Then, when building the log4j-api module, the Java 9 classes can be shaded into the log4j-api jar (excluding StackLocator since we want to compile that

Re: Chainsaw in git

Thanks for doing this work, Ralph! Remko (Shameless plug) Every java main() method deserves http://picocli.info > On May 31, 2017, at 8:54, Ralph Goers wrote: > > At the request of Scott Deboy I have migrated chainsaw to git. You can view > it at

Re: Log4j2 APIs on Android

Oleg, Elements in the Log4j configuration can be instrumented with MBeans to allow remote inspection and modification of an application's logging configuration. As Matt pointed out, this can be disabled. There is no dependency on RMI as far as I know. There is a log4j-jmx-gui client module that

Re: Log4j2 APIs on Android

finitely make sure that log4j-api works smoothly on Android. > > >> On 2017-05-31 19:57, Oleg Kalnichevski wrote: >>> On Thu, 2017-06-01 at 01:18 +0900, Remko Popma wrote: >>> Oleg, >>> >>> Elements in the Log4j configuration can be instrume

Re: Log4j - Java 9

Ralph, thank you!! I just tried it and it works great. All I needed to do was tell IntelliJ IDEA to use Java 9 for the log4j-api-java9 module and it all just works in the IDE again. Great, thanks again! Remko On Mon, Jun 19, 2017 at 4:39 AM, Ralph Goers wrote: > I

Re: [Log4j] log4j-server

ther tool gives a large advantage. I >> really >>>>> like Gradle's incremental build feature but I can live without it. >>>> However, >>>>> moving half the project into separate repos feels too much like working >>>>> a

Re: [Log4j] log4j-server

ikael.stal...@magine.com> > wrote: > >> I think we should continue to break up things into modules, but keep them >> in the same repo. >> >>> On Fri, May 5, 2017 at 2:16 AM, Remko Popma <remko.po...@gmail.com> wrote: >>> >>> Why don't we focu

Re: [Log4j] log4j-server

. I'm not sure if it's in release:prepare or > > >>> release:perform. > > >>> > > >>> On 5 May 2017 at 12:12, Gary Gregory <garydgreg...@gmail.com> wrote: > > >>> > > >>>> Are the tests run 3 times from within t

Re: [Log4j] log4j-server

Why don't we focus on making the build faster instead of this module & repo break-up? We know this breakup is adding all kinds of complexity but we are only *hoping* (not sure) that it will make the build faster. The way I've heard Ralph and Matt describe it, the build currently requires the

Re: Java9

> On May 22, 2017, at 5:30, Ralph Goers wrote: > > I’m not sure how to make it be any better than this. Although the Java 9 > classes could be removed we would just have to put them back in a couple of > months when Java 9 is released. Putting them in a separate

Re: Java9

ed log4j-api to something else and then disable > the deploy in the module. Then the new log4j-api could create the jar. But > this all seems messier than what is there now. If you ignore the Java 9 stuff > it should just work in the IDE. > > Ralph > >> On May 21, 2017,

Re: Random failure in AsyncLoggerAndAsyncAppenderTest

I've looked at this before but couldn't figure it out. I'll take another look. (Shameless plug) Every java main() method deserves http://picocli.info > On Sep 12, 2017, at 9:00, Matt Sicker wrote: > > I'm pretty sure I've seen that failure (or something similar at least) >

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

Ralph, Would it be possible to include the new wording in the 2.9.1 announcement email? Remko > On Sep 22, 2017, at 7:17, rpo...@apache.org wrote: > > Repository: logging-log4j2 > Updated Branches: > refs/heads/master 3f5d58cd3 -> 8b5d644d5 > > > Fix wording of 2.9.1 change item

Re: [VOTE] Release Log4j 2.9.1-rc1

never released)."? (Shameless plug) Every java main() method deserves http://picocli.info > On Sep 22, 2017, at 8:06, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > I changed it some, yes. > > Ralph > >> On Sep 21, 2017, at 2:55 PM, Remko Popma <rem

Re: [VOTE] Release Log4j 2.9.1-rc1

I started writing the blog post for 2.9.1. Quick question: no changes to the announcement text this time, is that correct? On Thu, Sep 21, 2017 at 1:12 PM, Ralph Goers wrote: > My +1 > > Ralph > > > On Sep 18, 2017, at 12:07 AM, Ralph Goers

Re: Log4J 2.9.1 release

I'll try to put in a fix for https://issues.apache.org/jira/browse/LOG4J2-1988?filter=-1 (java.util.ConcurrentModificationException with AsyncLogger?) today. Stretch goal: https://issues.apache.org/jira/browse/LOG4J2-2031 (Messages appear out of order in log file (was: Log4j2 log file not

Re: [ANNOUNCE] Apache Log4j 2.9.1 released

Blogged: https://blogs.apache.org/logging/entry/log4j-2-9-1-released (Shameless plug) Every java main() method deserves http://picocli.info > On Sep 22, 2017, at 9:32, Ralph Goers wrote: > > As of Log4j 2.9.0, the Log4j API was modified to use

Re: [VOTE] Release Log4j 2.9.1-rc1

+1 Builds fine, checksums good. On Mon, Sep 18, 2017 at 4:07 PM, Ralph Goers wrote: > This is a vote to release Log4j 2.9.1, the next version of the Log4j 2 > project. > > Please download, test, and cast your votes on the log4j developers list. > [] +1, release the

Re: Java Modules

You mean we may want to do something like this in the future? module org.apache.logging.log4j { exports org.apache.logging.log4j; exports org.apache.logging.log4j.message; exports org.apache.logging.log4j.simple; exports org.apache.logging.log4j.spi; exports

Re: [VOTE] Release Log4j 2.9.0-rc1

If anyone has a script for recursively checking the checksums of a directory tree I'd be much obliged. (Shameless plug) Every java main() method deserves http://picocli.info > On Aug 30, 2017, at 14:36, Ralph Goers wrote: > > Here is my +1 > > Ralph > >> On Aug

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

ased on release candidate 1 has passed with > +1 votes from Gary Gregory, Matt Sicker, Mikael Ståldal, Remko Popma, and > Ralph Goers. No other votes were cast. > > I will continue with the release process. > > Ralph

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

:39, Gary Gregory <garydgreg...@gmail.com> wrote: > > The word container is so vague... container of what? Files, Applications, > NoSQL things? How about app-container? > > Gary > >> On Wed, Sep 6, 2017 at 4:07 PM, Remko Popma <remko.po...@gmail.com> wrote:

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

log4j-container? (To be more generic than javaee) > On Sep 7, 2017, at 4:56, Ralph Goers wrote: > > Yes, the intent would be to allow containers to use Log4j as their logging > implementation. > > Ralph > >> On Sep 6, 2017, at 12:26 PM, Mikael Ståldal

Re: Automatic module names

Isn't it the opposite? Giving them the same module name will prevents them from being used together, which is what we want: http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html?m=1 "JPMS will simply refuse to start a modulepath where two modules have the same name, even if they

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

t;> A very restrictive mode of operation could enforce that all arguments >> passed into a log event must be limited to immutable primitive types. In >> this mode deadlocks could no longer occur because rogue recursions would >> actively prevented. >> >> On 10 Se

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

Thanks for reviewing. Good catch, a null check is needed to prevent NPEs. But null passwords are possible so perhaps make it like this: return password == null ? null : password.toCharArray(); > On Sep 26, 2017, at 1:08, Gary Gregory wrote: > >> On Mon, Sep 25, 2017

Re: log4j-to-slf4j

Logback 1.1.7. Logback > is now at 1.1.11 and 1.2.3. I am not really clear on what is different > between 1.1.x and 1.2.x. > > Ralph > >> On Sep 24, 2017, at 9:50 PM, Remko Popma <remko.po...@gmail.com> wrote: >> >> Ok I see now. >> It would certai

Re: log4j-to-slf4j

Sounds to me that Ralph's analysis shows that doing the binding ourselves may not be worth doing since we can't get an advantage by either improving people's perception nor improve performance. Unless I'm missing something. > On Sep 26, 2017, at 16:34, Mikael Ståldal

Re: log4j-to-slf4j

ementation would be shorter. > > To be honest, item 1 is the one I find more appealing. It reminds me of how > OS/2’s support for Windows was not what people really wanted vs the way > Windows NT handled it. > > Ralph > >> Begin forwarded message: >> >> From: R

Re: SocketOptions builder

ore BC and make > the change from "set" to "with" now? > > Gary > >> On Thu, Aug 17, 2017 at 4:21 PM, Remko Popma <remko.po...@gmail.com> wrote: >> >> That's fine I think. >> >> (Shameless plug) Every java main() method des

Re: [VOTE] Release Log4j 2.9.0-rc1

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

Re: Logging list for emails generated by tools

I think that's a good idea. (I really wish we could have fewer duplicate emails though.) Remko > On Oct 13, 2017, at 6:59, Dominik Psenner wrote: > > Stuff that requires human intervention should stay prominent. The rest can > go away. :-) > > 2017-10-12 23:06 GMT+02:00

Re: [Log4j] skipJansi by default

We don't have much choice I think. As Ralph pointed out, we have to change the default value as it can cause application startup to fail... > On Oct 13, 2017, at 4:25, Gary Gregory wrote: > > My preference is to leave it as. The 2nd option is to add jansi=true|false

Re: Test failures in log4j-taglib

The error went away on my machine and the Jenkins build started passing after reverting back to 3.2.18.RELEASE > On Oct 24, 2017, at 4:51, Ralph Goers wrote: > > OK. So I am guessing that the errors are happening on a unit test that uses > Spring’s mock classes

converting markdown links to html links

This took me a while to get right, so let me share it. Below unix command can be used to replace the markdown links to HTML links in a text file: sed -i -e 's/\[\([^\]*\)\](\([^)]*\))/\1<\/a>/g' RELEASE-NOTES.md Tricky points were that sed does not recognize the non-greedy qualifier, so you

Re: converting markdown links to html links

Really? Looking at announcement.vm they seem identical. > On Nov 23, 2017, at 16:59, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > Thanks, although the announcement is going to contain a bit more text than is > in the release notes. > > Ralph > >> On

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

I'll prepare the usual blog post. On Thu, Nov 23, 2017 at 11:57 AM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > This vote has passed with binding +1 votes from Mikael Ståldal, Matt > Sicker, Remko Popma, and Ralph Goers, a binding -1 from Gary Gregory, and > a non-bindi

Log4JNA

Interesting: https://github.com/dblock/log4jna/blob/master/README.md Maybe we should link to this from our site somewhere. Like a section on 3rd party appenders or so?

Re: [Log4j] Header/footer and thread context

Generally it doesn’t make sense to expect ThreadLocal lookups to work with async appender/loggers. Another lookup should be used. I haven’t looked at the code but I expect that the subject is cached somehow. Perhaps this should be changed (to no caching) so that the user experience is

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

Guys, if any of your findings should be reflected in the Log4j2 documentation for web applications, please let us know (I'm not following this discussion in enough detail to judge whether the Log4j2 docs need adjustment). Documentation patches are always welcome! On Thu, Nov 23, 2017 at 10:54

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

I’ll take a look tomorrow. > On Nov 10, 2017, at 22:47, Ralph Goers wrote: > > Please review this commit as I want to make sure I didn’t make any mistakes. > > Ralph > > >> On Nov 10, 2017, at 6:46 AM, rgo...@apache.org wrote: >> >> Repository: logging-log4j2 >>

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

I’ve built several Swing-based apps and know Swing fairly well. I’ve only got my feet wet with JavaFX. Both are big frameworks with a significant learning curve. Personally I’d use JavaFX, if only to make working on the project an interesting learning experience. > On Nov 12, 2017, at

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

ote: > > > >Ok. I’m waiting on feedback on this before I start a release. > > > > Ralph > > > > > > > > Senior Software Developer > > daan.hoogl...@shapeblue.com > > www.shapeblue.com > > > > > > > >> On Nov 11, 2017

Library versions

Gary, Just wondering: how do you keep track of library version updates? Is there a tool to get notified when there’s an update? Amazing job by the way! Remko (Shameless plug) Every java main() method deserves http://picocli.info

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

Aggreement-> Agreement (Away from pc) On Tue, Nov 14, 2017 at 0:50 wrote: > Repository: logging-log4j2 > Updated Branches: > refs/heads/master d85f39abc -> 8b71dbbf1 > > > Add PR notice to README > > > Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo >

Re: [VOTE] Release Log4j 2.10.0-rc1

use it works on my Windows and the tests use String.format with %n to avoid this exact issue. > > Ralph > > >> On Nov 19, 2017, at 11:12 PM, Remko Popma <remko.po...@gmail.com> wrote: >> >> Building current master (211326b) succeeds for me when runn

Re: [VOTE] Release Log4j 2.10.0-rc1

9:00 [INFO] Final Memory: 55M/451M [INFO] On Mon, Nov 20, 2017 at 5:06 PM, Remko Popma <remko.po...@gmail.com> wrote: > > > On Nov 20, 2017, at 15:21, Ralph Goers <ralph.go...@dslextreme.com> > wrote: > > > > Oh, and I wouldn

Re: [VOTE] Release Log4j 2.10.0-rc1

org.apache.log4j.config.Log4j1ConfigurationFactoryTest > > >>>>>> .testSystemProperties1(Log4j1ConfigurationFactoryTest.java:173) > > >>>>>> > > >>>>>> > > >>>>>> I think Remko fixed that in master.

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

The build now fails on windows. I always see this error: expected: C:\Users\remko\AppData\Local\Temp\/hadoop.log Actual: C:\Users\remko\AppData\Local\Temp\/hadoop.log java.nio.file.FileSystemException: C:\Users\remko\AppData\Local\Temp\hadoop.log: The process cannot access the file because it is

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

017, at 20:46, Mikael Ståldal <mi...@apache.org> wrote: > > Does it help if you add: > >appender.stop(10, TimeUnit.SECONDS); > > after line 171 in Log4j1ConfigurationFactoryTest.java (last in the try block)? > > >> On 2017-11-19 05:41, Remko Popma wrote:

Re: [VOTE] Release Log4j 2.10.0-rc1

time: 27:57 min [INFO] Finished at: 2017-11-20T14:56:18+09:00 [INFO] Final Memory: 56M/518M [INFO] ---- On Mon, Nov 20, 2017 at 2:10 PM, Remko Popma <remko.po...@gmail.com> wrote: > When I upgraded picocli to 2.0

Re: [VOTE] Release Log4j 2.10.0-rc1

When I upgraded picocli to 2.0.3 a few weeks ago I made sure all tests passed on Windows. CI builds are ok. I also did a successful Log4j2 build on Windows yesterday when looking at pull request #134. This is very odd. > On Nov 20, 2017, at 12:49, Ralph Goers

Re: Log4j 2.10

No objection, and thanks for RM-ing! Remko > On Nov 16, 2017, at 14:04, Gary Gregory wrote: > > Great! And thank you for RM'ing again. > > Gary > > On Wed, Nov 15, 2017 at 9:31 PM, Ralph Goers > wrote: > >> Unless someone objects I plan

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

lt;boa...@gmail.com> wrote: > > Considering it takes about 2-3 months of daily use of Scala to get > comfortable, perhaps Kotlin would be a better choice. It's a simpler > language and is supposed to be easy for Java developers to pick up. > >> On 10 November 2017 at 19:43, Remko Popma

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

I don’t know either language but I’d be more interested in learning Kotlin than learning Scala. OTOH I’m not sure how much time I’ll be able to contribute to Chainsaw so not sure how much that should count for. (Shameless plug) Every java main() method deserves http://picocli.info > On Nov

Re: logging-log4j2 git commit: Fix typo

Sorry, I still see one misspelled Aggreement (Away from pc) > On Nov 14, 2017, at 1:02, rgo...@apache.org wrote: > > Repository: logging-log4j2 > Updated Branches: > refs/heads/master ac82a0d78 -> 7ade3025b > > > Fix typo > > > Project:

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

Ok, you have some fair points there. Main take-away for me is that if we want Log4j2's API to become ubiquitous it needs to be at least painless for everyone. Don't known about the "too much stuff" in log4j-api - bit vague and not actionable. What can we do, concretely? log4j-api - 1)

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

y tooling won’t choke on the version 53 bytecode). We can extract those classes into a temp directly, rename them back to the canonical extension, and use the same class loader that loaded the other log4j-api classes to load the Java 9 classes from the temp directory. If this fails, we fall back

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

On second thought, without a custom class loader we’d first need to copy these classes into the classpath. This may not always be possible and sounds like a bad idea anyway. So please ignore my previous email. On Sun, Dec 3, 2017 at 8:38 Remko Popma <remko.po...@gmail.com> wrote: > &

Re: [log4j] providing sourcewith Message

Interesting! Can you point to an example of how this works? I’m trying to understand what changes would be required. Remko (Shameless plug) Every java main() method deserves http://picocli.info > On Dec 9, 2017, at 15:30, Jeffrey Shaw wrote: > > Hello, > I've found that

Re: SLF4J now requires Java 6

From Java 9, interfaces can have private methods that can be called from interface default methods. This is to reduce duplicate code in default method implementations. > On Dec 3, 2017, at 20:44, Mikael Ståldal wrote: > >> On 2017-12-03 00:24, Matt Sicker wrote: >> It's

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

You mean let’s replace all occurrences of `log4j.skipJansi` with `log4j2.skipJansi`, in both code and documentation? > On Oct 24, 2017, at 14:03, Matt Sicker wrote: > > Can you use the new system property naming scheme? This would be > log4j2.skipJansi. That property would

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

are confusing. > > >> On 2017-10-24 15:04, Remko Popma wrote: >> You mean let’s replace all occurrences of `log4j.skipJansi` with >> `log4j2.skipJansi`, in both code and documentation? >>> On Oct 24, 2017, at 14:03, Matt Sicker <boa...@gmail.com> wrote:

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

the plugin? It should ideally be filterable based on > at least the exception supertype, but any sort of filter like that could be > useful in power user scenarios as well. > >> On 24 October 2017 at 22:07, Gary Gregory <garydgreg...@gmail.com> wrote: >> >>

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

I just finished reading it. Looks great Matt! Enjoy giving the presentation! Remko (Shameless plug) Every java main() method deserves http://picocli.info > On Oct 31, 2017, at 6:26, Ole Ersoy wrote: > > That's the key - Gotta make it more fun! Keep it fresh - Ziplock

Re: Log4j-audit release

I’ll be flying back to Tokyo tomorrow but I can take another look when I’m back. Is there a recent snapshot of the site on your GitHub account? > On May 6, 2018, at 21:35, Ralph Goers wrote: > > I have finished everything I wanted to accomplish for the first

  1   2   3   4   5   6   7   8   9   10   >