For receiving log messages, though that's a separate feature.
On 4 May 2017 at 02:57, Mikael Ståldal wrote:
> We are talking about layouts now, why would we need JSON deserialization?
>
> On Wed, May 3, 2017 at 9:49 PM, Matt Sicker wrote:
>
> > I'll make a ticket for adding dependency-free JSON
We are talking about layouts now, why would we need JSON deserialization?
On Wed, May 3, 2017 at 9:49 PM, Matt Sicker wrote:
> I'll make a ticket for adding dependency-free JSON serialization and
> deserialization (probably separate tickets).
>
> On 3 May 2017 at 12:57, Remko Popma wrote:
>
> >
FWIW, if we want to do dependency- and garbage-free JSON serialization (not
parsing), we have org.apache.logging.log4j.core.util.JsonUtils in
log4j-core (used by GelfLayout).
On Wed, May 3, 2017 at 10:43 PM, Matt Sicker wrote:
> Remko has a ticket with a proposed binary logging format. Does tha
Remko has a ticket with a proposed binary logging format. Does that include
all the relevant data to reconstruct LogEvents by reading the file(s)?
On 3 May 2017 at 15:36, Ralph Goers wrote:
> While I agree with Gary, my recommendation would be to either come up with
> a custom serialization/dese
While I agree with Gary, my recommendation would be to either come up with a
custom serialization/deserialization format, use one where we can just copy a
class or two, or customize the SerializedLayout to not include arbitrary
classes.
Ralph
> On May 3, 2017, at 1:29 PM, Matt Sicker wrote:
>
I suppose serialization would be more important for dependency-free. I
don't believe there's any way to make Jackson GC-free, for example, as a
use case here.
On 3 May 2017 at 15:14, Gary Gregory wrote:
> This really feels silly to me. Doing JSON and XML IO is not 100% trivial
> and removing the
This really feels silly to me. Doing JSON and XML IO is not 100% trivial
and removing the dep is not a driver for me and not a "feature". Well, the
parsing is not trivial, generation is simple even with escaping. But why? I
really don't see the point for the apps I write at least. I mean, I have my
I'll make a ticket for adding dependency-free JSON serialization and
deserialization (probably separate tickets).
On 3 May 2017 at 12:57, Remko Popma wrote:
> Thank you for the clarification, Mikael!
> We may have to live with an external dependency initially until the JSON
> serializer that Mat
Thank you for the clarification, Mikael!
We may have to live with an external dependency initially until the JSON
serializer that Matt mentioned is ready.
On Wed, May 3, 2017 at 5:22 PM, Mikael Ståldal
wrote:
> GelfLayout currently lacks markers, context stack and detailed structured
> stacktr
GelfLayout currently lacks markers, context stack and detailed structured
stacktrace (it has a string formatted stacktrace), thread id, location, etc.
The GELF standard i extensible, but only with key-value pairs with string
or numeric values, it cannot be extended with an arbitrary JSON structure
GelfLayout follows the standard from Graylog, similar in idea to the syslog
standard.
On 2 May 2017 at 19:34, Remko Popma wrote:
> That sounds good!
> Essentially we want a layout that allows the receiver to reconstruct the
> LogEvent (assuming the receiver has all required classes for custom
>
That sounds good!
Essentially we want a layout that allows the receiver to reconstruct the
LogEvent (assuming the receiver has all required classes for custom messages
etc).
Isn't GelfLayout quite close? What info does it leave out?
(Shameless plug) Every java main() method deserves http://
I added some minimal code in the escape pattern converter for handling JSON
string encoding. We can probably include a minimal JSON serialization
"library" inside log4j-core which could also be included in the general
GC-free ecosystem we have going on.
On 2 May 2017 at 10:14, Mikael Ståldal wrot
Oh, I did not think about that aspect. Both JsonLayout and a potential new
AvroLayout (will) have external dependency.
Without external dependency, we currently have GelfLayout, PatternLayout
and RFC5424Layout.
GelfLayout and RFC5424Layout would be useful in some cases, but they do not
have all i
What layout do we have available that does not require an external
dependency?
On Tue, May 2, 2017 at 8:38 PM, Mikael Ståldal
wrote:
> Given the inherent security problems with Java object serialization
> (highlighted by CVE-2017-5645), I do suggest that we deprecate
> SerializedLayout and remov
Given the inherent security problems with Java object serialization
(highlighted by CVE-2017-5645), I do suggest that we deprecate
SerializedLayout and remove it as default for SocketAppender, and all other
appenders which currently have it as default. (We can still keep
SerializedLayout, with a wa
16 matches
Mail list logo
