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

See http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html . Perhaps we need to add this to one of our guide pages. Ralph > On Jan 16, 2018, at 8:43 PM, Gary Gregory wrote: > > Yeah, sorry about t

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

Yeah, 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: > > > > Repository: logging-log4j2 > > Updated Branches: > > refs/heads/master

Re: MongoDB, Cassandra, CouchDB, Liquibase, Flume

And there is no obvious way to tell what matches to what :-( Gary On Tue, Jan 16, 2018 at 4:34 PM, Ralph Goers wrote: > 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 wro

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: >> I don’t believe the componen

Re: MongoDB, Cassandra, CouchDB, Liquibase, Flume

I originally developed log4j-liquibase. I have not used it or Liquibase itself for quite some time now. It might be so that the next version of Liquibase will make that module obsolete. But maybe we should keep it around at least until such new version of Liquibase is released? On 2

Re: MongoDB, Cassandra, CouchDB, Liquibase, Flume

Why do we need to change the version number? On 2018-01-14 22:11, Ralph Goers wrote: 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

Re: [Log4j] Binary layout

I am experimenting with an Avro layout: https://github.com/apache/logging-log4j-plugins/tree/avro-layout It happens to be the case that the generated Avro value class implements Serializable, but is it appropriate to return that? Or should it return null? What if you want to make another binary

Re: [Log4j] Binary layout

Well, in looking at the various uses of that method I am a bit confused. 1. The JMSAppender will use Java serialization if it isn’t a MapMessage or a String. 2. CassandraManager uses some sort of TypeConverter to convert the Serializable - but it only seems to handle a limited set of types. For

Re: [Log4j] Binary layout

I think what Mikael meant is that Serializable is just a marker interface that does not provide any guidance on what methods to call on it to turn the result into bytes. Unless we want to use java serialization, and I presume one of the main reasons for creating a custom binary layout (other than p

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

Doesn't that depend on the generic type T of the Layout? For example, MessageLayout extends AbstractLayout returns a Message instance. You could return a ByteBuffer, but generally for an efficient binary layout I would look at the encode method instead. On Tue, Jan 16, 2018 at 11:45 PM, Mikael Stå

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

[Log4j] Binary layout

How is a binary layout (extending AbstractLayout) supposed to implement the toSerializable method in the Layout interface? Why is that method there?