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

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. > > As a general rule, if you change

Re: [log4j] The shape of Log4j

On Sun, Jan 21, 2018 at 4:14 PM, Ralph Goers wrote: > I am very much against the idea of a single repo. Yes, you can have > multiple projects in the repo but I am not sure how that can be sanely > released. I much prefer the model that Maven has taken. They are now

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

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

Hi All, The interface org.apache.logging.log4j.core.appender.nosql.NoSqlObject requires arrays in two methods: set(String, NoSqlObject[]) set(String, Object[]) For some providers like the new MongoDB driver 3.x provider I am working on this causes double work. First the log4j NoSQL guts

Re: [log4j] The shape of Log4j

FWIW, Some of this is borne out by looking at the stats at https://repository.apache.org/#central-stat . The good news is that the downloads are 3 times what they were a year ago. But you can see that the usage of these extra components is 1000

Re: [log4j] The shape of Log4j

Remko, I am all for speeding up the build. I have been complaining about this for well over a year and it keeps getting worse with every release. The compile of log4j-core takes less than 20 seconds on the machine provided by my employer. On the same machine the tests take 11 minutes. On this

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

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. As a general rule, if you change the artifactId the package name should be changed as well. I agree that it is probably

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

On Sun, Jan 21, 2018 at 4:20 PM, Ralph Goers wrote: > What do you mean by “renaming”? Hello, What I mean is that the Maven module's artifact ID 'log4j-mongodb' would be renamed to 'log4j-mongodb2' in the pom.xml file. The Java 9 module name in pom.xml would be

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

This looks promising: http://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html (especially the @NotThreadSafe annotation, potentially in combination with JUnit Suits) On Sun, Jan 21, 2018 at 13:12 Remko Popma wrote: >

Re: [log4cxx] Are these project notification settings in JIRA correct?

Jira, GitHub and Jenkins notifications for all projects under the Apache Logging umbrella should be going to notificati...@logging.apache.org . The reply-to field should be set to dev@logging.apache.org so replies go to

[log4cxx] Are these project notification settings in JIRA correct?

Hi all, two issues have been created in log4cxx[1][2] recently I wasn't aware of, so I checked the project notification settings and found that most of them go to notificati...@logging.apache.org now. I wasn't subscribed on that list and did that now. The one thing I don't understand is that I

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

What do you mean by “renaming”? I don’t know that it would be a good idea for both the Mongo 2 & 3 plugins to have the same plugin name. Although it is not likely they would ever be used together if they do it would be impossible to ever have both at the same time. Ralph > On Jan 21, 2018, at

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

Yes, I have thought about this. Maven has had separate repos for plugins for years. In every quarterly they have at least a dozen releases. They create the draft quarterly report right after the previous one is submitted and the release manager for each plugin updates the draft as part of the

[log4j] A better log4j2.debug

Hi All, I want to toggle between different status levels on the command line and log4j2.debug can't do that. How about adding log4j2.status=level ? Gary

Re: [log4j] The shape of Log4j

I am very much against the idea of a single repo. Yes, you can have multiple projects in the repo but I am not sure how that can be sanely released. I much prefer the model that Maven has taken. They are now using gitbox [1] which seems to allow GitHub to be the primary repo. Every Maven plugin

Re: [log4net] release 2.0.9

On 21 Jan 2018 11:28 a.m., "Stefan Bodewig" wrote: On 2018-01-20, Dominik Psenner wrote: > I have looked at the assert that fails. For one there's a comment on it > saying that "on linux locking seems to not behave as one would expect". > Second the assert is wrapped in an

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

On 01/21/2018 07:58 AM, Mikael Ståldal wrote: Nothing stops you from starting your own log viewer project based on whatever technology you want. If it turns out useful, we might even consider adopting it as an Apache Logging subproject. Indeed I'm right in the middle of starting a CSS

Re: [log4net] exclusive lock on .NET Core 1.x and Linux

Sometimes it is possible to configure the test runner so that it runs in process instead of spawning a new process. Would you like to investigate on this? I had contact to Rob Prouse of the nunit developers. It might be a good idea to crosspost to nunit-discuss. On 21 Jan 2018 11:21 a.m., "Stefan

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

Mikael, Ralph, Have you really thought through the implications of having a separate repository for each module? The overhead is very large! It would mean: * a separate website for each repo (our current Log4j2 website only knows about the modules in the logging-log4j project). * a separate

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

Hi All: As I am working through https://issues.apache.org/jira/browse/LOG4J2-2205 to migrate from 2.x to 3.x APIs in the module log4j-mongodb, I am concerned that the changes are large enough as to break some older apps. I am sure I wouldn't hear about it until my customers complain. Therefore,

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

Nothing stops you from starting your own log viewer project based on whatever technology you want. If it turns out useful, we might even consider adopting it as an Apache Logging subproject. I think it's better if you and we try out what we believe in independently, and then we will see what

Re: [log4net] release 2.0.9

On 2018-01-20, Dominik Psenner wrote: > I have looked at the assert that fails. For one there's a comment on it > saying that "on linux locking seems to not behave as one would expect". > Second the assert is wrapped in an #if !MONO || MONO_3_5 || MONO_4_0. Note > that this all comes from my

Re: [log4net] exclusive lock on .NET Core 1.x and Linux

On 2018-01-20, Stefan Bodewig wrote: > I have disabled the test conditionallly on Linux and the Jenkins build > now finishes the tests on Linux. But not reliably, there seems to be another test that crashes the test runner from time to time.