Re: [log4j] org.apache.logging.log4j.message.MapMessage.put(String, String)

s now, which is nice. > > Gary > > On Thu, Jan 11, 2018 at 9:24 PM, Ralph Goers > wrote: > >> In looking at the history MapMessage only supported Strings until you >> modified it last June. It appears to me you did it incorrectly. You made >> MapMessage gene

Re: [log4j] org.apache.logging.log4j.message.MapMessage.put(String, String)

gt; > On Fri, Jan 12, 2018 at 10:47 AM, Gary Gregory <mailto:garydgreg...@gmail.com>> > wrote: > >> On Fri, Jan 12, 2018 at 12:33 AM, Ralph Goers >> wrote: >> >>> Then I don’t understand why you modified MapMessage to be >>> >>>

Re: [log4j] Move JDBC appender to own module?

My main complaint with core is the amount of time it takes to run unit tests. I don’t think the JDBC tests are a big contributor to that. Ralph > On Jan 13, 2018, at 6:34 PM, Gary Gregory wrote: > > On Jan 13, 2018 16:11, "Remko Popma" wrote: > > JDCB doesn’t require an external dependency s

Re: logging-log4j2 git commit: [LOG4J2-2185] Add a simple JDBC DriverManager-based ConnectionSource that uses JDBC's DriverManager#getConnection(String, String, String). Use @PluginBuilderFactory.

Why are there 5 commits in a row for the same Jira issue? Is there are reason you don’t test it all before committing? If you need to commit piecemeal then please squash the commits. Ralph > On Jan 12, 2018, at 10:15 PM, ggreg...@apache.org wrote: > > Repository: logging-log4j2 > Updated Branc

Re: logging-log4j2 git commit: [LOG4J2-2179] The MongoDB Appender should use keys and values from a Log4j MapMessage. Fix compile. Doc it!

7 commits for the same Jira? Ralph > On Jan 11, 2018, at 10:48 AM, ggreg...@apache.org wrote: > > Repository: logging-log4j2 > Updated Branches: > refs/heads/master e78d205cc -> 672832929 > > > [LOG4J2-2179] > The MongoDB Appender should use keys and values from a Log4j MapMessage. > Fix comp

Re: logging-log4j2 git commit: [LOG4J2-2181] The JDBC Appender should use keys and values from a Log4j MapMessage. Implementation and documentation.

Again 6 commits for the same Jira? Ralph > On Jan 11, 2018, at 5:52 PM, ggreg...@apache.org wrote: > > Repository: logging-log4j2 > Updated Branches: > refs/heads/master f530d4c8c -> 187e236ff > > > [LOG4J2-2181] The JDBC Appender should use keys and values from a Log4j > MapMessage. Implemen

MongoDB, Cassandra, CouchDB, Liquibase, Flume

I don’t believe the components listed in the subject line should be part of the main flume build and would like to see them moved to the logging-log4j-plugins project. The only problem is that the modules and maven coordinates need to change since the version numbers will be going backwards. I w

Re: MongoDB, Cassandra, CouchDB, Liquibase, Flume

uld start > by creating a JIRA epic (it’s in maintenance now but when it’s back up). > > (Shameless plug) Every java main() method deserves http://picocli.info > >> On Jan 15, 2018, at 6:11, Ralph Goers wrote: >> >> I don’t believe the components listed in the subj

Re: MongoDB, Cassandra, CouchDB, Liquibase, Flume

gt; On 14 January 2018 at 17:14, Ralph Goers wrote: > >> Ok. >> >> If we do this we should release that before we remove them from a Log4J >> release to minimize confusion. >> >> Sent from my iPhone >> >>> On Jan 14, 2018, at 3:47 PM, Remko Po

Re: MongoDB, Cassandra, CouchDB, Liquibase, Flume

e past, it doesn't log _to_ >>> liquibase; instead, it offers an implementation of its internal logger >>> logic which doesn't use any existing facade by default. >>> >>> On 14 January 2018 at 17:14, Ralph Goers >> wrote: >>> >>>>

Re: [Log4j] Binary layout

> On Jan 16, 2018, at 7:45 AM, Mikael Ståldal wrote: > > How is a binary layout (extending AbstractLayout) supposed to implement the > toSerializable method in the Layout interface? > > Why is that method there? > > You would implement it the same way all the other layouts do. All that met

Re: [Log4j] Binary layout

I think MessageLayout is a special case as it only returns the message portion of the LogEvent. Most Layouts return all of the LogEvent attributes. Even so, you could have AbstractLayout if you wanted the serialized version of the LogEvent. It can also be anything else that implements Serializa

Re: [Log4j] Binary layout

d just return the bytes it produced > itself. Either as a byte array or as a ByteBuffer. > > > On Wed, Jan 17, 2018 at 12:23 AM, Ralph Goers > wrote: > >> I think MessageLayout is a special case as it only returns the message >> portion of the LogEvent. Most

Re: MongoDB, Cassandra, CouchDB, Liquibase, Flume

Because logging-log4j-plugins is released separately from logging-log4j2 and the versions would not line up. Ralph > On Jan 16, 2018, at 2:31 PM, Mikael Ståldal wrote: > > Why do we need to change the version number? > > On 2018-01-14 22:11, Ralph Goers wrote: >>

Re: logging-log4j2 git commit: [LOG4J2-2179] The MongoDB Appender should use keys and values from a Log4j MapMessage. Fix compile. Doc it!

ah, sorry about that. I"ll be mindful in the future. > > Gary > > On Sat, Jan 13, 2018 at 7:18 PM, Ralph Goers > wrote: > >> 7 commits for the same Jira? >> >> Ralph >> >>> On Jan 11, 2018, at 10:48 AM, ggreg...@apache.org wrote: >>

Re: [log4j] changes.xml states 2.11.0 but POMs state 2.10.1

Doesn’t matter. When the release is performed the release plugin modifies all the poms. The release manager only needs to know what the version should be. Having the changes.xml reflect that is a good way to do it. Ralph > On Jan 18, 2018, at 9:23 AM, Gary Gregory wrote: > > Hi All: > > Just

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

-1 Please revert and move this to the log4j plugins project. Ralph > On Jan 18, 2018, at 8:54 PM, ggreg...@apache.org wrote: > > Repository: logging-log4j2 > Updated Branches: > refs/heads/master bb6fcd09e -> 639f093b8 > > > [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling th

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

In addition, the build is now failing to compile on Jenkins. Ralph > On Jan 18, 2018, at 9:28 PM, Ralph Goers wrote: > > -1 > > Please revert and move this to the log4j plugins project. > > Ralph > >> On Jan 18, 2018, at 8:54 PM, ggreg...@apache.org wrote: >

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

OK, but that doesn’t resolve the initial problem. The log4j 2 project is too large. Ralph > On Jan 18, 2018, at 10:15 PM, Gary Gregory wrote: > > On Thu, Jan 18, 2018 at 9:43 PM, Ralph Goers > wrote: > >> In addition, the build is now failing to compile on Jenkins.

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

ote: > > On Thu, Jan 18, 2018 at 10:20 PM, Ralph Goers > wrote: > >> OK, but that doesn’t resolve the initial problem. The log4j 2 project is >> too large. >> > > From what I've experienced, folks complain about the size of the api and > core jars, not

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

t > too big. > > It's better to create a new repository for each new module (or possibly for a > couple of related modules, but they should be more related than just being > Log4j plugins). > > > On 2018-01-19 06:31, Ralph Goers wrote: >> Gary, I am complaining b

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: logging-log4j2 git commit: [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling through Apache Commons DBCP 2.

ut of the main repo we need a > plan for the new repo(s). There is a one-time work of setting up web sites > and integrating them with the main site, but on an ongoing basis we need > some way to verify that a change in log4j-core did not break any plugins, > and agree to do a plugins

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

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

best to allow both to coexist. Ralph > On Jan 21, 2018, at 5:13 PM, Gary Gregory wrote: > > 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

Re: [log4j] The shape of Log4j

t those two changes be much more impactful in reducing the release time > than any amount of module or repo reshuffling? > > Remko > > (Shameless plug) Every java main() method deserves http://picocli.info > >> On Jan 22, 2018, at 8:14, Ralph Goers wrote: >> >

Re: [log4j] The shape of Log4j

s 1000 times smaller than log4j-core. Ralph > On Jan 21, 2018, at 9:35 PM, Ralph Goers wrote: > > 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 lo

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

y Gregory <mailto:garydgreg...@gmail.com>> > 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

Re: [log4j] The shape of Log4j

ntegration thing sounds neat, particularly for code > review, though that's a separate topic entirely. > > On 22 January 2018 at 00:37, Gary Gregory wrote: > >> On Sun, Jan 21, 2018 at 4:14 PM, Ralph Goers >> wrote: >> >>> I am very much against the i

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

o the point where folks would not need > to go to the site; having examples in the Javadoc you can cut and paste for > example. > > Gary > > >> >> And yes, the GitBox integration thing sounds neat, particularly for code >> review, though that's a separ

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: logging-log4j2 git commit: [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling through Apache Commons DBCP 2.

t;>>> make it our first priority. >>>> If you want to add anything to the main project, *first reduce the >> build >>>> duration*. First find an existing test and speed it up. Only then add >> new >>>> stuff, keeping the total build time to the

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

introduced by this solution (keeping the new repo(s) in >> sync, >>>>> building new web sites and linking them into the main site, release >>>> timing >>>>> etc). >>>>> >>>>> PROPOSAL: >>>>> I t

Re: [log4j] The shape of Log4j

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

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 o

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

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 woul

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

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 <mailto:ralph.go...@dslextreme.com>> > wrote: >> >> That process would be guaranteed to have things messed up and would make >> users wonder why version

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: > >> >> >>> On Jan 22, 2018, at 4:26 PM, Gary Gregory >> wrote: >>> >>> On Mon, Jan 22, 2018 at 4:22 PM, Ralph Goers > <mail

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 mak

Re: [log4j] The shape of Log4j

> On Jan 23, 2018, at 6:51 AM, Gary Gregory wrote: > > On Jan 23, 2018 5:09 AM, "Mikael Ståldal" wrote: > > There is no NoSQL appender. There are Cassandra, CouchDB and MongoDB > appenders. I don't think we should bundle them together. > > > Note that these are already separate modules/jar

Re: logging-log4j2 git commit: [LOG4J2-2212]Unnecessary contention in CopyOnWriteSortedArrayThreadContextMap. [LOG4J2-2213] Unnecessary contention in GarbageFreeSortedArrayThreadContextMap.

Static vars are camelCase. Only class names are CamelCase. Isn’t that documented in our conventions? Ralph > On Jan 23, 2018, at 3:32 PM, Gary Gregory wrote: > > On Tue, Jan 23, 2018 at 3:01 PM, Remko Popma wrote: > >> This solution should work. Thanks for taking care of this, Gary! >> >> O

Re: [log4j] The shape of Log4j

k/dumping-grounds log4j-plugins is not acceptable to > me. > > Ralph does not want it in the main repo. I say it's fine. > > Now what? > > Should I call a VOTE? > > Gary > > > On Tue, Jan 23, 2018 at 7:40 AM, Ralph Goers > wrote: > >> >

Re: [log4j] The shape of Log4j

want it in the main repo. I say it's fine. > > Now what? > > Should I call a VOTE? > > Gary > > > On Tue, Jan 23, 2018 at 7:40 AM, Ralph Goers > wrote: > >> >> >>> On Jan 23, 2018, at 6:51 AM, Gary Gregory >> wrote: >>

Re: [log4j] The shape of Log4j

> On Jan 24, 2018, at 1:56 PM, Gary Gregory wrote: > > On Wed, Jan 24, 2018 at 1:18 PM, Ralph Goers > wrote: > >> A vote can’t override a veto of a code commit. >> > > I'm trying to get things to move along toward some kind of workable > solution

Re: [log4j] The shape of Log4j

They are not really orthogonal. 1. Log4j core contains some stuff that isn’t really “core” functionality., such as Kafka or JMS. These cause the core tests to take longer than necessary. 2. The size of the repo directly effects how long a build takes to run, as does the number of components in c

Re: [log4j] The shape of Log4j

> On Jan 24, 2018, at 3:02 PM, Gary Gregory wrote: > > On Wed, Jan 24, 2018 at 2:33 PM, Ralph Goers <mailto:ralph.go...@dslextreme.com>> > wrote: > >> >> >>> On Jan 24, 2018, at 1:56 PM, Gary Gregory >> wrote: >>> &g

Re: [log4j] The shape of Log4j

Thanks for that Remko. We are about due for another Log4j 2 release. I won’t be able to get a release of log4j-server and then move the plugins to the plugins project in a short enough time to warrant holding off a Log4j 2 release. So I am going to say Gary should go ahead and add the mongo3 mo

Re: [log4j][LOG4J2-2195] PatternLayout, %exception, separator, and suffix

> On Jan 25, 2018, at 11:11 AM, Gary Gregory wrote: > > Hi All: > > I am looking at https://issues.apache.org/jira/browse/LOG4J2-2195 > > Looking at our documentation for PatternLayout, the way I interpret > "suffix" is that it is a string printed _after_ the stack trace is printed > out. Make

Re: logging-log4j2 git commit: LOG4J2-1883 moved SystemMillisClock out of the java9 module into core so it can be used with any supported Java version

I’m not crazy about adding date related stuff directly to the util package. I am not thrilled that we have date/time related stuff there when we have a datetime package they could have been placed in. Since we already have a datetime package there and if those classes could be moved to core.time

Re: logging-log4j2 git commit: LOG4J2-1883 moved SystemMillisClock out of the java9 module into core so it can be used with any supported Java version

> On Jan 26, 2018, at 8:54 PM, Remko Popma wrote: > > I guess the classes in util/datetime can be moved to the new time package. > Note that these are public classes so there is a probability that a user is > using these classes directly and this move will break their code, but if we > judge thi

Re: [log4j] The shape of Log4j

> On Jan 27, 2018, at 9:39 AM, Gary Gregory wrote: > > Should a goal be that log4j-core have no external dependencies? The requirement is that log4j-core have no required dependencies. I should have as few optional dependencies as possible. Ralph

Re: [log4j] The shape of Log4j

Also, in Java 9 it must only require the java.base module. Ralph > On Jan 27, 2018, at 6:49 PM, Matt Sicker wrote: > > On 27 January 2018 at 16:18, Ralph Goers wrote: > >> The requirement is that log4j-core have no required dependencies. I should >> have as few

Re: [log4j] org.apache.logging.log4j.core.appender.mom.jeromq move?

Any component that is not in the core module MUST NOT use the core package. That would make it impossible to package them as Java 9 modules. Ralph > On Jan 28, 2018, at 11:31 AM, Gary Gregory wrote: > > Hi All, > > Now that the ZeroMQ via JeroMQ support is in its own module log4j-jeromq, I >

Re: [log4j] org.apache.logging.log4j.core.appender.mom.jeromq move?

PM, Ralph Goers wrote: > > Any component that is not in the core module MUST NOT use the core package. > That would make it impossible to package them as Java 9 modules. > > Ralph > >> On Jan 28, 2018, at 11:31 AM, Gary Gregory wrote: >> >> Hi All, >>

Re: [log4j] org.apache.logging.log4j.core.appender.mom.jeromq move?

> On Jan 28, 2018, at 9:22 PM, Matt Sicker wrote: > > XML configuration requires the java.xml module which is a dependency to > consider now. Really? That sucks. Ralph

Re: [log4j] The shape of Log4j

e simpler ones, we'll end up with > several additional modules to detangle that. > > If we could include multiple logical modules in a single physical module, > then this wouldn't be as tedious. > > On 27 January 2018 at 20:01, Ralph Goers wrote: > >> Also, in J

Re: [log4j] org.apache.logging.log4j.core.appender.mom.jeromq move?

quot;org.apache.logging.log4j.cassandra"? > > Gary > > > On Sun, Jan 28, 2018 at 2:25 PM, Ralph Goers > wrote: > >> I should add that each module must have a unique package hierarchy so, in >> general, the package names should be org.apache.logging.log4j.m

Re: [log4j] org.apache.logging.log4j.core.appender.mom.jeromq move?

rag in JSON configuration code if all I > want is a JSON layout. > > Thoughts? > > Gary > > > On Sun, Jan 28, 2018 at 7:38 PM, Gary Gregory > wrote: > >> >> >> On Sun, Jan 28, 2018 at 2:25 PM, Ralph Goers >&g

Java 8

Ceki has started a poll to upgrade Logback to Java 8 - https://doodle.com/poll/s7n3wk59694pmnbs . The last poll I saw was in May of last year that had Java 7 at about 30%. https://plumbr.io/blog/java/java-version-and-vendor-data-analyzed-2017-edition

Re: [log4j] clarify "internal" vs exported packages in core - plugin API

If are going to call it 3.0 I would have liked to cut a release before all this modularization work and then created a branch so we could maintain it if necessary. Ralph > On Jan 29, 2018, at 10:04 AM, Gary Gregory wrote: > > On Mon, Jan 29, 2018 at 8:17 AM, Remko Popma wrote: > >> If we ar

Re: [log4j] clarify "internal" vs exported packages in core - plugin API

h from an earlier commit, from before we >> started to rename packages, and cut a 2.11 release from that branch? >> >> On Tue, Jan 30, 2018 at 2:08 AM, Ralph Goers >> wrote: >> >>> If are going to call it 3.0 I would have liked to cut a release before &

Re: [log4j] clarify "internal" vs exported packages in core - plugin API

> here >>> is a github link: >>>>> https://github.com/apache/logging-log4j2/commit/ >>> 21bc3aa3bf8d8a043459c6a58e774b82a617a058 >>>>> >>>>> LOG4J2-2225 provide alias for SystemMillisClock so the fully qualifie… >>>>>

Re: [log4j] clarify "internal" vs exported packages in core - plugin API

rk on master should be targeted at that as well as incorporating anything added to the release-2.x branch. My goal would be to get 2.11.0 out as quickly as possible. Ralph > On Jan 30, 2018, at 9:21 AM, Gary Gregory wrote: > > On Tue, Jan 30, 2018 at 9:15 AM, Ralph Goers >

Re: [log4j] clarify "internal" vs exported packages in core - plugin API

Barring something I am unaware of I should be able to do it this weekend. Ralph > On Jan 31, 2018, at 12:44 PM, Gary Gregory wrote: > > On Tue, Jan 30, 2018 at 11:14 AM, Gary Gregory > wrote: > >> >> >> On Jan 30, 2018 11:11, "Ralph Goers" wrote

Re: [log4j] which branches can be deleted?

Obviously release-2.x needs to stay as you just created it. Master of course has to stay. I’d like to keep android around until we solve that problem. I would have to look at each of the specified Jira issues to know which can be deleted. Ralph > On Feb 2, 2018, at 1:39 AM, Remko Popma wrote:

Log4j Audit

Well I have good news and bad news. The bad news is that I forgot my wife and I were having people over for the super bowl so I didn’t have as much time as I had hoped and I wasn’t able to run the Log4j 2.11.0 release build. The good news is that I think Log4j Audit V1.0 is about ready for a rel

Re: Log4j Audit

called a Catalog? Perhaps explaining why this term is a good >> name would help set the readers frame of thinking to understand the rest of >> the page. >> Also, do users need to create a catalog? Or is it something that emerges >> automatically when one uses audit logging?

Re: Log4j Audit

> Also, is a container (tomcat or others ) a requirement? if it is I do not see > it in the requirements section. I assumed it was an api either using or built > on top of log4j2 > > > Best, > Chandra > > On 5 Feb 2018, 8:44 PM +0530, Ralph Goers , wrote: >>

Re: [log4j] NUL in log event message

Maybe this is a silly question, but in what world is it rational to have NULL chars in the middle of a String? Ralph > On Feb 8, 2018, at 10:24 AM, Gary Gregory wrote: > > In some cases I get: > > 2018-02-08 10:14:49,488 main WARN Unable to instantiate > org.fusesource.jansi.WindowsAnsiOutput

Re: Log4j Audit

ng "but >> Log4j doesn't do anything with that". Why not just leave it out altogether >> and not mention these? >> Why is it called a Catalog? Perhaps explaining why this term is a good >> name would help set the readers frame of thinking to understand the res

Re: Log4j Audit

gt; to me whether these annotations would be useful (or generally how > RequestContext could be used) outside the Spring world, or even outside of > web applications. > > I like the diagram under Transporting the RequestContext though. Diagrams > are good! I like diagrams! &g

Re: Java 8

; >>>>>>> wrote: >>>>>>> >>>>>>>> On Mon, Jan 29, 2018 at 10:24 AM, Matt Sicker >>>> wrote: >>>>>>>> >>>>>>>>> I'd be +1 for Java 8, but making a 3.0 release is a dif

Re: Java 8

; This is not a precondition for the releases Ralph mentioned, but we should > test this idea with log4j-server before proceeding with the modularization. > > (Shameless plug) Every java main() method deserves http://picocli.info > >> On Feb 13, 2018, at 6:46, Ralph Goers wrote: &g

Java 7 as well as future JDK support strategy.

There is an article at InfoQ that discusses Oracle’s support strategy [1]. It contains a chart that shows the support lifetime for all Oracle releases. [2] It references a blog post from Azul discussing Oracle’s support strategy. [3] These charts are confirmed by Oracle’s roadmap. [4]. The end

Re: Java 7 as well as future JDK support strategy.

I found this update that says Oracle has extended the public support of Java 8 about 4 months past the release of Java 11. https://www.infoq.com/news/2018/02/Java8SupportJan18 <https://www.infoq.com/news/2018/02/Java8SupportJan18> Ralph > On Feb 12, 2018, at 5:28 PM, Ralph Goe

Re: Java 7 as well as future JDK support strategy.

018, at 3:26 PM, Gary Gregory wrote: > > On Mon, Feb 12, 2018 at 9:44 PM, Ralph Goers > wrote: > >> I found this update that says Oracle has extended the public support of >> Java 8 about 4 months past the release of Java 11. >> https://www.infoq.com/news/201

Re: Java 7 as well as future JDK support strategy.

, although I agree it is unfortunate that it was done in a way that causes so much grief. Ralph > On Feb 13, 2018, at 5:10 PM, Gary Gregory wrote: > > On Tue, Feb 13, 2018 at 5:04 PM, Ralph Goers > wrote: > >> While I agree with your statements regarding Java 7 and 8 I can

Re: Java 7 as well as future JDK support strategy.

ignore non-LTS releases. Ralph > On Feb 13, 2018, at 5:50 PM, Gary Gregory wrote: > > On Tue, Feb 13, 2018 at 5:17 PM, Ralph Goers > wrote: > >> Did you look at any of the links in my email? Java 10 will be released in >> March. When that happens Java 9 will be un

Re: Java 7 as well as future JDK support strategy.

> On Feb 13, 2018, at 9:26 PM, Gary Gregory wrote: > > On Tue, Feb 13, 2018 at 6:22 PM, Ralph Goers <mailto:ralph.go...@dslextreme.com>> > wrote: > >> Well, here are some things to think about. >> 1. When Oracle drops support for Java 9 next month does tha

Re: [1/2] logging-log4j2 git commit: LOG4J2-2250 The internal status logger timestamp format is now configurable with system property `log4j2.StatusLogger.dateformat`.

> On Feb 16, 2018, at 8:34 AM, Gary Gregory wrote: > > On Fri, Feb 16, 2018 at 8:32 AM, Jochen Wiedmann > > wrote: > >> On Fri, Feb 16, 2018 at 4:03 PM, Gary Gregory >> wrote: >>> On Fri, Feb 16, 2018 at 7:03 AM, Matt Sicker wrote: >>> Is this propert

Re: Jenkins build is unstable: Log4j 2 3.x #1

The mongo db test failed. Ralph > On Feb 18, 2018, at 12:35 AM, Apache Jenkins Server > wrote: > > See > >

Log4j Jenkins builds

While splitting out components into modules should have had the desired effect of reducing the dependencies in log4j-core, it didn’t help making the builds take less time. The Jenkins build for 3.x took about 43 minutes while the 2.x build took 38 minutes. Ralph

Re: Log4j Jenkins builds

12:44 AM, Ralph Goers > wrote: > >> While splitting out components into modules should have had the desired >> effect of reducing the dependencies in log4j-core, it didn’t help making >> the builds take less time. The Jenkins build for 3.x took about 43 minutes >&

Re: [proposal] Should we drop Java 9 "features" like module-info and multi-release jars or provide it differently.

I am not in favor of this. I was told that moving module-info.java into the META-INF/versions/9 directory is valid and will remedy some of these problems. I intend to do that prior to the next release. Although I agree what Oracle did is a mess there are people who want this stuff. In fact, so

Re: JDK 10: Release Candidate & JDK 11 Early Access builds available

If somebody sees something in Java 10 or 11 that we should support please speak up. So far, I don’t. Ralph > On Mar 2, 2018, at 4:03 AM, Rory O'Donnell wrote: > > Hi Ralph, > > *JDK 10 build 45 is our JDK 10 Release Candidate and now available at > http://jdk.java.net/10/* > > * Schedule,

Re: JDK 10: Release Candidate & JDK 11 Early Access builds available

s that seemed >>> relevant for Log4j... >>> >>> On Sat, Mar 3, 2018 at 12:05 AM, Ralph Goers >>> wrote: >>> >>>> If somebody sees something in Java 10 or 11 that we should support >>> please >>>> speak up. So far, I

OSGi and multi-release jars

The issue with OSGi not supporting Java 9 has finally seen some movement. See the update at https://github.com/bndtools/bnd/issues/2227#issuecomment-370600204 . It seems support for multi-release jars has finally been added to

release 2.11.0 site

I am afraid I am unable to build the site for release 2.11.0 and I don’t know why. It fails with the stack trace below, but as far as I know nothing significant has changed in this area since the last release. Any ideas? Ralph [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site

Re: release 2.11.0 site

e current version of maven-site-plugin (3.7) has >>> updated its dependency on BCEL to the latest where I updated the code to >>> avoid this exception. >>> >>> Gary >>> >>> On Mon, Mar 5, 2018 at 9:06 PM, Ralph Goers >>> wrote: >>

2.11.0 status

I have created the release notes for 2.11.0. Please review them. I have built the 2.11.0 web site locally and am noticing the following problems: The javadoc page does not list jdbc-dbc2, jpa, or liquibase. The link on the javadco page for MongoDB results in a 404. I suspect because there should

Re: 2.11.0 status

Failures: [ERROR] CommandLineTest.testInetAddressConvertersInvalidError:480->parseInvalidValue:496 Invalid format %$::a?*!a was accepted for -InetAddress [INFO] [ERROR] Tests run: 199, Failures: 1, Errors: 0, Skipped: 4 Ralph > On Mar 9, 2018, at 12:23 PM, Gary Gregory wrote: > > On Thu, Mar 8, 2018 at 9:48 PM, Ralp

Re: 2.11.0 status

hought it > was "picoli") > > Gary > > > On Sun, Mar 11, 2018, 12:06 Ralph Goers wrote: > >> I do not know why but now on one of my MacBooks the 2.x build is failing >> with >> >> [INFO] Running org.apache.logging.log4j.core.tools.picocli.C

Re: 2.11.0 status

8 on the laptop where it fails and Java 7 on the laptop where it works. Ralph > On Mar 11, 2018, at 11:57 AM, Ralph Goers wrote: > > I can’t answer that except to say that I don’t think that will change for > 2.11.0. I have no idea why we have anything to do with the command line

Re: 2.11.0 status

I’m not sure what you are thinking. Ralph > On Mar 11, 2018, at 12:10 PM, Gary Gregory wrote: > > Could it be a Maven toolchain that is misconfigured? > > Gary > > On Sun, Mar 11, 2018, 13:01 Ralph Goers wrote: > >> I should also add that this test is not fai

<    1   2   3   4   5   6   7   8   9   10   >