Re: [log4j] log4j-core test speed breakdown

Nice!! (Shameless plug) Every java main() method deserves http://picocli.info > On Jan 23, 2018, at 14:25, Gary Gregory wrote: > > On Mon, Jan 22, 2018 at 9:45 PM, Gary Gregory > wrote: > >> Hm, it already uses the mock stuff! >> >> I reduced test delays in the MockProducer introduced in com

Re: [log4j] log4j-core test speed breakdown

On Mon, Jan 22, 2018 at 9:45 PM, Gary Gregory wrote: > Hm, it already uses the mock stuff! > > I reduced test delays in the MockProducer introduced in commit > 96436fb958ce1f1a3d4f0c951f556f0709c91b15 (by Mike) from 3 seconds to 50 > milliseconds. This reduces running this test case from 43 to 3

Re: [log4j] log4j-core test speed breakdown

Hm, it already uses the mock stuff! I reduced test delays in the MockProducer introduced in commit 96436fb958ce1f1a3d4f0c951f556f0709c91b15 (by Mike) from 3 seconds to 50 milliseconds. This reduces running this test case from 43 to 3 seconds. Let's watch this test in Jenkins to make sure it still

Re: [log4j] The shape of Log4j

> On Jan 22, 2018, at 5:10 PM, Gary Gregory wrote: > > On Mon, Jan 22, 2018 at 4:45 PM, Ralph Goers > wrote: >> > "When you have a chart like Maven does users can easily deal with figuring > out what versions they want to use." > > That makes no sense to me either: The page https://maven.apa

Re: [log4j] The shape of Log4j

You are making a mountain out of a mole hill. If a plugin released for 2.8.2 doesn’t work with 2.11.0 we are doing something wrong. Users shouldn’t need to inspect anything. The problem with your premise is assuming these components require some specific version of log4j-core. Ralph > On Jan

Re: [log4j] The shape of Log4j

On Mon, Jan 22, 2018 at 4:45 PM, Ralph Goers wrote: > > > > On Jan 22, 2018, at 4:26 PM, Gary Gregory > wrote: > > > > On Mon, Jan 22, 2018 at 4:22 PM, Ralph Goers > > > wrote: > >> > >> That process would be guaranteed to have things messed up and would make

Re: [log4j] The shape of Log4j

> On Jan 22, 2018, at 4:26 PM, Gary Gregory wrote: > > On Mon, Jan 22, 2018 at 4:22 PM, Ralph Goers > > wrote: >> >> That process would be guaranteed to have things messed up and would make >> users wonder why versions of jars were skipped. >> > > How is t

Re: [log4j] The shape of Log4j

My recollection is vague, tied to pom machinations supporting a similar separation for the 'log4j companions': outside of core log4j - chainsaw, component, extras, receivers and zeroconf' Some of the issues I recall having to deal with when we had the generic 'component' module: - Some classes s

Re: [log4j] The shape of Log4j

On Mon, Jan 22, 2018 at 4:22 PM, Ralph Goers wrote: > > > > On Jan 22, 2018, at 4:02 PM, Gary Gregory > wrote: > > > > On Mon, Jan 22, 2018 at 3:54 PM, Ralph Goers > > > wrote: > > > >> > >> > >>> On Jan 22, 2018, at 3:44 PM, Gary Gregory > >> wrote: > >>> > >>> On Mon, Jan 22, 2018 at 3:25 PM

Re: [log4j] The shape of Log4j

> On Jan 22, 2018, at 4:02 PM, Gary Gregory wrote: > > On Mon, Jan 22, 2018 at 3:54 PM, Ralph Goers > wrote: > >> >> >>> On Jan 22, 2018, at 3:44 PM, Gary Gregory >> wrote: >>> >>> On Mon, Jan 22, 2018 at 3:25 PM, Matt Sicker wrote: >>> The profiles idea would help a lot for local

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc2

+1 (Shameless plug) Every java main() method deserves http://picocli.info > On Jan 23, 2018, at 7:29, Matt Sicker wrote: > > I'll add my +1 from earlier. We still need another +1, though it's only > been two days so far, so we still have time. > >> On 20 January 2018 at 16:54, Matt Sicker wro

Re: [log4j] The shape of Log4j

On Mon, Jan 22, 2018 at 3:54 PM, Ralph Goers wrote: > > > > On Jan 22, 2018, at 3:44 PM, Gary Gregory > wrote: > > > > On Mon, Jan 22, 2018 at 3:25 PM, Matt Sicker wrote: > > > >> The profiles idea would help a lot for local development and making it > >> easier to run the relevant unit tests w

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

On Mon, Jan 22, 2018 at 3:26 PM, Mikael Ståldal wrote: > I actually prefer to keep everything related to Log4j 2 (maybe except > Chainsaw) in the same repository, if we can find a way to manage that > properly. > A big +1 from me on that one. The question is how to "manage that properly" as you

Re: [log4j] The shape of Log4j

> On Jan 22, 2018, at 3:44 PM, Gary Gregory wrote: > > On Mon, Jan 22, 2018 at 3:25 PM, Matt Sicker wrote: > >> The profiles idea would help a lot for local development and making it >> easier to run the relevant unit tests when modifying code. This wouldn't >> really help the release process

Re: [log4j] Building and releasing

Committing the site to SVN certainly takes a lot longer than committing it to Git when publishing the staging version. Perhaps we can try out GitPubSub for the CMS functionality instead of the traditional SvnPubSub? On 22 January 2018 at 16:49, Ralph Goers wrote: > https://wiki.apache.org/loggin

Re: [log4j] Building and releasing

https://wiki.apache.org/logging/Log4j2ReleaseGuide is fairly close to being up to date. I try to update it whenever I change the process. Some of the steps are one time only - like getting the signing key or setting up Maven. I should add on

Re: [log4j] The shape of Log4j

On 22 January 2018 at 16:44, Gary Gregory wrote: > Ah... but you COULD make it help in the release just as well but putting > what you are releasing into the main profile! That's the beauty of it. > Sure, you'd tag the whole thing as one. Presumably, you'd think the RM > would make sure at least

Re: [log4j] The shape of Log4j

On Mon, Jan 22, 2018 at 3:25 PM, Matt Sicker wrote: > The profiles idea would help a lot for local development and making it > easier to run the relevant unit tests when modifying code. This wouldn't > really help the release process, though, as we'd either need to release > everything in the rep

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

> On Jan 22, 2018, at 3:20 PM, Gary Gregory wrote: > > On Mon, Jan 22, 2018 at 3:14 PM, Ralph Goers > wrote: > >> I started to read it but it is too long. To be honest I would love it if >> I could just run the release from Jenkins. Unfortunately, that would >> require someone’s code signing

Re: [log4j] Building and releasing

We're migrating to Confluence over time: https://cwiki.apache.org/confluence/display/LOGGING/Home Should be copied over. I already have the Chainsaw release guide there. On 22 January 2018 at 16:34, Gary Gregory wrote: > Hi All but mostly Ralph: > > Are all the instructions to release all of Lo

Re: [log4j] The shape of Log4j

On 22 January 2018 at 16:29, Ralph Goers wrote: > IMO the main repo should contain the stuff 80% (or more) of our user’s use > and the stuff that is common across all plugins. So the file appenders and > console appenders all belong, probably most of the existing lookups and > filters. Since the

Re: [log4j] The shape of Log4j

> On Jan 22, 2018, at 3:23 PM, Gary Gregory wrote: > > On Mon, Jan 22, 2018 at 2:58 PM, Matt Sicker wrote: > >> Using Maven profiles could help, though when tagging a release, if we >> didn't release every module within, then it'd get out of sync anyways. Then >> it would still require buildi

[log4j] Building and releasing

Hi All but mostly Ralph: Are all the instructions to release all of Log4j up to date on the wiki https://wiki.apache.org/logging ? Gary

Re: [log4j] The shape of Log4j

> On Jan 22, 2018, at 2:21 PM, Gary Gregory wrote: > > On Mon, Jan 22, 2018 at 12:58 PM, Matt Sicker wrote: > >> On 22 January 2018 at 13:48, Ralph Goers >> wrote: >> >>> I don’t see why this work would require 3.0 as we aren’t planning on >>> breaking any contracts to do this. >>> >> >>

Re: [log4j] The shape of Log4j

IMO the main repo should contain the stuff 80% (or more) of our user’s use and the stuff that is common across all plugins. So the file appenders and console appenders all belong, probably most of the existing lookups and filters. Since the Syslog Appender probably fits in I would also keep the

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc2

I'll add my +1 from earlier. We still need another +1, though it's only been two days so far, so we still have time. On 20 January 2018 at 16:54, Matt Sicker wrote: > I've committed the updated .asc files in revision 24339. MD5 and SHA-512 > hashes are still the same. > > Do note that you can al

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

I actually prefer to keep everything related to Log4j 2 (maybe except Chainsaw) in the same repository, if we can find a way to manage that properly. But if we have to split it up as Ralph wants, we should do it properly and have one repository and release train per module (or closely related

Re: [log4j] The shape of Log4j

The profiles idea would help a lot for local development and making it easier to run the relevant unit tests when modifying code. This wouldn't really help the release process, though, as we'd either need to release everything in the repo at once, or we'd end up with unreleased modules being tagged

Re: [log4j] The shape of Log4j

On Mon, Jan 22, 2018 at 2:58 PM, Matt Sicker wrote: > Using Maven profiles could help, though when tagging a release, if we > didn't release every module within, then it'd get out of sync anyways. Then > it would still require building every single component in each release, > even when said comp

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

On Mon, Jan 22, 2018 at 3:14 PM, Ralph Goers wrote: > I started to read it but it is too long. To be honest I would love it if > I could just run the release from Jenkins. Unfortunately, that would > require someone’s code signing key which would be a bit problematic to > install on a shared ser

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

I started to read it but it is too long. To be honest I would love it if I could just run the release from Jenkins. Unfortunately, that would require someone’s code signing key which would be a bit problematic to install on a shared server. In addition, I am a bit paranoid about making sure the

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

When performing a release I always run the build a few times. Because it takes so long and because fixing a release that fails halfway through is such a pain I always run the build to make sure it will work before I start the release build, so I could certainly skip the tests when actually perfo

Re: [log4j] The shape of Log4j

On Mon, Jan 22, 2018 at 2:58 PM, Matt Sicker wrote: > Using Maven profiles could help, though when tagging a release, if we > didn't release every module within, then it'd get out of sync anyways. Then > it would still require building every single component in each release, > even when said comp

Re: [log4j] The shape of Log4j

On Mon, Jan 22, 2018 at 3:03 PM, Scott Deboy wrote: > Correcting my prior comment: the nightmare I was referring to was the > ugliness we did and un-did related to the never-released receivers and > 'component' companions. Definitely feels like deja vu. > > https://github.com/apache/log4j-compon

Re: [log4j] The shape of Log4j

Correcting my prior comment: the nightmare I was referring to was the ugliness we did and un-did related to the never-released receivers and 'component' companions. Definitely feels like deja vu. https://github.com/apache/log4j-component/blob/trunk/pom.xml apache-log4j-companions-parent etc etc

Re: [log4j] The shape of Log4j

Using Maven profiles could help, though when tagging a release, if we didn't release every module within, then it'd get out of sync anyways. Then it would still require building every single component in each release, even when said components haven't changed at all. On 22 January 2018 at 15:50, G

Re: [log4j] The shape of Log4j

Coming back around to the idea of One Repo to Rule Them All*TM* ... what if we used Maven profiles to separate out the "main" build from "other" builds? All that is needed to move modules from one build to another is just to edit the profile! Gary On Mon, Jan 22, 2018 at 12:48 PM, Ralph Goers w

Re: [log4j] The shape of Log4j

On Mon, Jan 22, 2018 at 2:25 PM, Gary Gregory wrote: > > > On Mon, Jan 22, 2018 at 2:21 PM, Gary Gregory > wrote: > >> >> >> On Mon, Jan 22, 2018 at 12:58 PM, Matt Sicker wrote: >> >>> On 22 January 2018 at 13:48, Ralph Goers >>> wrote: >>> >>> > I don’t see why this work would require 3.0 as

Re: [log4j] The shape of Log4j

On Mon, Jan 22, 2018 at 2:21 PM, Gary Gregory wrote: > > > On Mon, Jan 22, 2018 at 12:58 PM, Matt Sicker wrote: > >> On 22 January 2018 at 13:48, Ralph Goers >> wrote: >> >> > I don’t see why this work would require 3.0 as we aren’t planning on >> > breaking any contracts to do this. >> > >> >>

Re: [log4j] The shape of Log4j

On Mon, Jan 22, 2018 at 12:58 PM, Matt Sicker wrote: > On 22 January 2018 at 13:48, Ralph Goers > wrote: > > > I don’t see why this work would require 3.0 as we aren’t planning on > > breaking any contracts to do this. > > > > I'm referring to something more in line with past proposals of having

Re: [log4j] The shape of Log4j

I'm curious: What is threshold where it would be OK to add stuff to the main repo? Gary On Mon, Jan 22, 2018 at 12:48 PM, Ralph Goers wrote: > I don’t see why this work would require 3.0 as we aren’t planning on > breaking any contracts to do this. > > As I’ve said, I am not tied to each plugin

Re: [log4j] A better log4j2.debug

Gary, If you’re looking for a “to accomplish X, do Y”, see the FAQ. https://logging.apache.org/log4j/2.x/faq.html#troubleshooting (Shameless plug) Every java main() method deserves http://picocli.info > On Jan 23, 2018, at 5:46, Gary Gregory wrote: > > On Mon, Jan 22, 2018 at 12:49 PM, Ralph

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

I read this blog post recently about build tools and found it interesting: < http://www.lihaoyi.com/post/BuildToolsasPureFunctionalPrograms.html>. Perhaps we can lift some ideas from here to find some build optimizations we may have missed (e.g., caching settings). On 22 January 2018 at 14:40, Gar

Re: [log4j] log4j-core test speed breakdown

On Mon, Jan 22, 2018 at 1:11 PM, Matt Sicker wrote: > The Kafka test could probably be rewritten to use the > MockProducer/MockConsumer classes instead of presumably embedding Kafka. > For my money, using mocks here does not guarantee anything :-( Gary > > On 22 January 2018 at 14:08, Gary Gr

Re: [log4j] A better log4j2.debug

On Mon, Jan 22, 2018 at 12:49 PM, Ralph Goers wrote: > Properties on the command line should override configurations in files. > +1 Gary > Ralph > > > On Jan 22, 2018, at 12:38 PM, Matt Sicker wrote: > > > > On 22 January 2018 at 13:22, Gary Gregory > wrote: > >> > >> Yikes. What I want to

Re: [log4j] Adding methods to org.apache.logging.log4j.core.appender.nosql.NoSqlObject

On Mon, Jan 22, 2018 at 12:30 PM, Matt Sicker wrote: > Back when I wrote the initial CassandraAppender implementation, I found the > existing NoSQL interfaces to be too restrictive. I found a similar problem > long ago when I was experimenting with a DynamoDB appender. Most NoSQL APIs > I've used

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

On Mon, Jan 22, 2018 at 12:26 PM, Matt Sicker wrote: > I still haven't seen a nice way to integrate multiple Maven-generated > websites as it is. If we broke into multiple repositories, we'd have to > basically rewrite the website infrastructure as well (which I've been > thinking about for a whi

Re: [log4j] log4j-core test speed breakdown

Maybe, but is that as reliable as what is currently done. FWIW, Kafka is another one that should be moved. The issue with a lot of these tests is that the smallest granularity that can be counted on for a file last modified time is 1 second. That means the unit test often has to wait for longer

Re: [log4j] log4j-core test speed breakdown

Lame formatting, I put these results here as well: https://pastebin.com/grKtxPTq Gary On Mon, Jan 22, 2018 at 1:08 PM, Gary Gregory wrote: > Hi All: > > Here are some number based on https://builds.apache.org/ > user/ggregory/my-views/view/Logging/job/Log4j 2.x/3315. There are some > obvious lo

Re: [log4j] log4j-core test speed breakdown

The Kafka test could probably be rewritten to use the MockProducer/MockConsumer classes instead of presumably embedding Kafka. On 22 January 2018 at 14:08, Gary Gregory wrote: > Hi All: > > Here are some number based on > https://builds.apache.org/user/ggregory/my-views/view/Logging/job/Log4j >

[log4j] log4j-core test speed breakdown

Hi All: Here are some number based on https://builds.apache.org/user/ggregory/my-views/view/Logging/job/Log4j 2.x/3315. There are some obvious low-hanging fruits. 43.078 org.apache.logging.log4j.core.appender.mom.kafka.KafkaAppenderTest 33.799 org.apache.logging.log4j.core.appender.routing.Rout

Re: [log4j] The shape of Log4j

On 22 January 2018 at 13:48, Ralph Goers wrote: > I don’t see why this work would require 3.0 as we aren’t planning on > breaking any contracts to do this. > I'm referring to something more in line with past proposals of having a sort of log4j-core-api or similar which is essentially just the di

Re: [log4j] The shape of Log4j

I am always in favor of improving the documentation. The general rule is you never have enough and what you have is never good enough. Ralph > On Jan 22, 2018, at 12:49 PM, Gary Gregory wrote: > > On Mon, Jan 22, 2018 at 12:36 PM, Matt Sicker wrote: > >> This whole conversation just reminds

Re: [log4j] A better log4j2.debug

Properties on the command line should override configurations in files. Ralph > On Jan 22, 2018, at 12:38 PM, Matt Sicker wrote: > > On 22 January 2018 at 13:22, Gary Gregory wrote: >> >> Yikes. What I want to do is use a -D on the command line instead of editing >> the status attribute in an

Re: [log4j] The shape of Log4j

On Mon, Jan 22, 2018 at 12:36 PM, Matt Sicker wrote: > This whole conversation just reminds me of all the times in the past I > suggested full modularization of the core API/SPI. I think such an effort > would make sense in a 3.0 release. > > In 2.x, perhaps what we can do is define a stable plug

Re: [log4j] The shape of Log4j

I don’t see why this work would require 3.0 as we aren’t planning on breaking any contracts to do this. As I’ve said, I am not tied to each plugin having its own repo. I am OK with these options; a) each plugin has its own repo and site and is released independently, b) we use the plugins repo

Re: [log4cxx] Current State

On 22 January 2018 at 03:25, Thorsten Schöning wrote: > Should I send you/to the list a changed KEYS file with my added > PGP-key and you commit that? > Yes, you can send us your key and any PMC member can commit it to the KEYS file. > What about publishing a release after a successfully vote

Re: [log4j] The shape of Log4j

On Sun, Jan 21, 2018 at 5:51 PM, Remko Popma wrote: > Log4j2 is not like Maven. Maven (I assume) has a plugin API. Log4j2 > modules depend on the internals of log4j-core. > > I agree with Gary that not being able to verify that a core change doesn’t > break any modules when they live outside the

Re: [log4j] MongoDB driver 2.x vs. 3.x

Please don’t commit the mongo 3 stuff until we decide what to do. I really, really want Cassandra, Flume, Mongo and other lightly used components out of the main build. Ralph > On Jan 22, 2018, at 12:12 PM, Gary Gregory wrote: > > On Sun, Jan 21, 2018 at 11:43 PM, Gary Gregory

Re: [log4j] A better log4j2.debug

On 22 January 2018 at 13:22, Gary Gregory wrote: > > Yikes. What I want to do is use a -D on the command line instead of editing > the status attribute in an XML configuration file. > Right, that makes sense. Would this property override the config file or the other way around? > The docs for l

Re: [log4j] The shape of Log4j

This whole conversation just reminds me of all the times in the past I suggested full modularization of the core API/SPI. I think such an effort would make sense in a 3.0 release. In 2.x, perhaps what we can do is define a stable plugin API based on what we already have. Since we're still supporti

Re: [log4j] Adding methods to org.apache.logging.log4j.core.appender.nosql.NoSqlObject

Back when I wrote the initial CassandraAppender implementation, I found the existing NoSQL interfaces to be too restrictive. I found a similar problem long ago when I was experimenting with a DynamoDB appender. Most NoSQL APIs I've used tend to accept a generic Map for documents/records, and it was

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

I still haven't seen a nice way to integrate multiple Maven-generated websites as it is. If we broke into multiple repositories, we'd have to basically rewrite the website infrastructure as well (which I've been thinking about for a while anyways). As a result, either direction we take (monorepo or

Re: [log4j] A better log4j2.debug

On Mon, Jan 22, 2018 at 12:15 PM, Matt Sicker wrote: > There are some related properties to what you're proposing already: > > log4j2.simplelogStatusLoggerLevel > log4j2.defaultStatusLevel > log4j2.statusLoggerLevel > > Though it's a bit confusing setting them here since some of these > propertie

Re: [log4j] A better log4j2.debug

There are some related properties to what you're proposing already: log4j2.simplelogStatusLoggerLevel log4j2.defaultStatusLevel log4j2.statusLoggerLevel Though it's a bit confusing setting them here since some of these properties get overridden by the configuration file or only apply in certain l

Re: [log4j] MongoDB driver 2.x vs. 3.x

On Sun, Jan 21, 2018 at 11:43 PM, Gary Gregory wrote: > On Sun, Jan 21, 2018 at 5:22 PM, Ralph Goers > wrote: > >> If the mongo 2 and mongo 3 Java 9 module names are going to be different >> then their package names must unique. JPMS requires that a Java package >> reside in only one module. >>

Re: svn commit: r1821805 - /logging/site/cms/trunk/content/security.twig

Thanks for taking care of this! We have a CVE in Log4j 2 we can link to on this page as well. On 21 January 2018 at 10:26, wrote: > Author: bodewig > Date: Sun Jan 21 16:26:21 2018 > New Revision: 1821805 > > URL: http://svn.apache.org/viewvc?rev=1821805&view=rev > Log: > first cut at a top leve

JDK 10 Early Access b40 & JDK 8u172 Early Access b02 are available on jdk.java.net

 Hi Ralph, Happy New Year! *OpenJDK builds - *JDK 10 Early Access build 40 is available at http://jdk.java.net/10/ * These early-access, open-source builds are provided under the GNU General Public License, version 2, with the Classpath Exception

Re: [log4cxx] Current State

Guten Tag Matt Sicker, am Samstag, 20. Januar 2018 um 18:56 schrieben Sie: > I'd be available to help with the release process along with any karma > mangling needed. Should I send you/to the list a changed KEYS file with my added PGP-key and you commit that? What about publishing a release afte