GC Free Layouts

Hello, I am working on the next release of log4j2-logstash-layout , which is an alternative to the default JsonLayout and allows custom JSON schemas. There I achieved to get up to 5x speed up compared to JsonLayout[1] and I want to

Re: GC Free Layouts

t; > Good luck, keep us posted! > > (Shameless plug) Every java main() method deserves http://picocli.info > > > On Oct 23, 2018, at 6:40, Volkan Yazıcı wrote: > > > > Hello, > > > > I am working on the next release of log4j2-logstash-layout > > <h

Re: GC Free Layouts

> > On Oct 25, 2018, at 15:50, Volkan Yazıcı > wrote: > > > > One thing I am still struggling is how to iterate over ContextData and > > ContextStack without any garbage. > > ContextData#forEach() necessitates instantiation of a new > > BiConsumer. > > An

Re: GC Free Layouts

I took a brief look at the BENCHMARK.txt file but didn’t have time to look > in detail. A graph comparison would be very cool! > > Good luck, keep us posted! > > (Shameless plug) Every java main() method deserves http://picocli.info > > > On Oct 23, 2018, at 6:40, Volkan Yazı

Re: [log4j] Toward 3.0

Hey Gary, *Package Name* Once every couple of months I found myself helping out people for JAR Hell problems since they included wrong Log4j artifact. The artifact and package names of Log4j 1 and Log4j 2 are pretty similar looking. Hence I really encourage you to explicitly state the version in

Re: [log4j] Toward 3.0

log4j2-logstash-layout was already using Apache License v2. I have switched log4j2-redis-appender to it as well. On Fri, Nov 16, 2018 at 9:15 PM Gary Gregory wrote: > On Fri, Nov 16, 2018 at 12:30 PM Volkan Yazıcı > wrote: > > > Hey Gary, > > > > *Package Name* &

Re: [log4j] Toward 3.0

, at 1:14 PM, Gary Gregory > wrote: > > > > On Fri, Nov 16, 2018 at 12:30 PM Volkan Yazıcı > > wrote: > > > >> Hey Gary, > >> > >> *Package Name* > >> > >> Once every couple of months I found myself helping out people > &

Re: [log4j] Toward 3.0

Volkan Yazıcı wrote: > Hey Gary, > > *Package Name* > > Once every couple of months I found myself helping out people > for JAR Hell problems since they included wrong Log4j artifact. > The artifact and package names of Log4j 1 and Log4j 2 are > pretty similar looking. Hence I

How to write to a ByteBufferDestination

Hello, In log4j2-logstash-layout , I am trying to fix a concurrency bug which led me investigate the way I write to a ByteBufferDestination. ByteBufferDestinationHelper.writeToUnsynchronized() provides a helper to serve this purpose, though I am a litt

[ApacheCon] How and why of the fastest Log4j JSON layout

Motivated by Matt's e-mail, I also would like to share my submission for the ApacheCon Europe 2019 . Fingers crossed... *How and why of the fastest Log4j JSON layout* Log4j is awesome. Love it or hate it, it is the de facto logger in the Java land. In the era of micr

Re: [ApacheCon] How and why of the fastest Log4j JSON layout

ed to the project? > > Ralph > > > On May 13, 2019, at 1:40 PM, Volkan Yazıcı > wrote: > > > > Motivated by Matt's e-mail, I also would like to share my submission for > > the ApacheCon Europe 2019 <https://aceu19.apachecon.com/>. Fingers > > crossed.

Re: [Log4j] Anyone know how to get this working in IntelliJ anymore?

For the records, the very same frustration was my initial driver to start working on log4j2-logstash-layout as a separate project. (That said, this path led other advantages for the plugin.) I think this awkwardly high entry barrier repels many potential contributors. Sometimes you just want to fix

Re: Should Log4j 2 2.x drop support for Java 7?

+1 for Java 8. On Wed, Jul 31, 2019 at 3:01 AM Gary Gregory wrote: > +1 for Java 8. > > Gary > > On Tue, Jul 30, 2019 at 7:49 PM Ralph Goers > wrote: > > > I implemented a logging builder pattern in the Log4j API on the master > > branch. I was able to do that in a backward compatible manner by

Re: Blog post

That was a pretty good read Ralph, please keep them coming. Further I will appreciate if you can share the upcoming (Log4j-related?) posts here too. On Tue, Dec 17, 2019 at 6:58 AM Apache wrote: > > I thought you all might be interested in this - > https://www.ralphgoers.com/home/why-was-log4j-2

Re: Feature request/possible contribution

Hello David, Truncating JSON field values (incl. the stack trace) longer than a certain threshold is supported by log4j2-logstash-layout[1] via maxStringLength configuration. Best. [1] https://github.com/vy/log4j2-logstash-layout On Sun, Dec 22, 2019 at 10:37 PM J. David Requejo wrote: > > Hel

Thoughts on XML/JSON/YAML layout in Log4j 3.0 (Was: Feature request/possible contribution)

Hello, As the author of log4j2-logstash-layout[1], I would like to share some thoughts on the plugin and its implications on Log4j 3.0 roadmap. - LogstashLayout is pretty stable in its feature set for the last year. That is, the advantages (customization, etc.) it offers over JsonLayout could

Re: Thoughts on XML/JSON/YAML layout in Log4j 3.0 (Was: Feature request/possible contribution)

This is easier said than done. Customizing the schema and injected content is the raison d'être of LogstashLayout. Would you people accept a PR re-branding LogstashLayout as the new JsonLayout where the default JSON schema conforms with the JsonLayout of Log4j 2.0? This would provide 100% backward-

Re: Thoughts on XML/JSON/YAML layout in Log4j 3.0 (Was: Feature request/possible contribution)

ot;: ["${json:mdc:user}", "${json:mdc:fallbackUser}"] On Tue, Dec 24, 2019 at 3:54 PM Matt Sicker wrote: > > Perhaps the ColumnMapping plugin from the database appenders could be > useful here? > > On Tue, Dec 24, 2019 at 03:09 Volkan Yazıcı wrote: > > >

Re: Thoughts on XML/JSON/YAML layout in Log4j 3.0 (Was: Feature request/possible contribution)

On Tue, Dec 24, 2019 at 4:38 PM Ralph Goers wrote: > Personally, I would have no problem accepting a contribution that is > backwards compatible and meets ASF requirements; it has to use the > Apache License and the contribution needs to be signed off by anyone > who has copyright claims. That can

Re: Thoughts on XML/JSON/YAML layout in Log4j 3.0 (Was: Feature request/possible contribution)

On Wed, Dec 25, 2019 at 7:38 AM Ralph Goers wrote: > FWIW, I am not necessarily proposing we implement that. I am > trying to point out that your templating approach doesn’t really > seem to be tied to JSON, [...] I could just as easily imagine an > XML template with xml resolvers. This is a stri

Re: Thoughts on XML/JSON/YAML layout in Log4j 3.0 (Was: Feature request/possible contribution)

17 PM Matt Sicker wrote: > > I’m not sure if any existing template libraries are garbage free, though I > like the idea in general at least. > > On Wed, Dec 25, 2019 at 14:42 Volkan Yazıcı wrote: > > > On Wed, Dec 25, 2019 at 7:38 AM Ralph Goers > > wrote: > >

The convention for thread-local allocations (TLAs)

Hello, I see that many Log4j components rely on TLA for efficiency reasons. There I have two main concerns: 1. TLAs, for obvious reasons, entail an extra memory cost on threads, particularly, even when they are not used. Consider a thread invoking a Log4j flow where various TLAs are perf

Re: The convention for thread-local allocations (TLAs)

Regarding log4j2.enableThreadlocals configuration knob, it feels more like a hint rather than a hard restriction. See how AbstractStringLayout#getStringBuilder() doesn't take that flag into account. On Sat, Dec 28, 2019 at 10:10 PM Volkan Yazıcı wrote: > > Hello, > > I se

Re: The convention for thread-local allocations (TLAs)

On Mon, Dec 30, 2019 at 10:15 PM Carter Kozak wrote: > Beyond StringBuilder instances, we attempt to clear references > from all thread local references to avoid substantial overhead. In > practice this works nicely because it reinforces java performance > characteristics. Java threads are fairly

Constants in 3.0

A majority of the Log4j 2.0 constants are structured by means of "public final" fields initialized via system properties. While this serves great for accessibility, IMHO, becomes an obstacle for tests. For instance, I have needed two maven-surefire-plugin executions for log4j2-logstash-layout: one

Re: Constants in 3.0

t demonstrates what you would like to do? It is > easier for me to evaluate the pros and cons of that then guessing what the > implementation would look like. > > Ralph > > > On Dec 31, 2019, at 2:43 PM, Volkan Yazıcı wrote: > > > > A majority of the Log4j 2.0

Re: Thoughts on XML/JSON/YAML layout in Log4j 3.0 (Was: Feature request/possible contribution)

On Tue, Dec 24, 2019 at 10:48 PM Volkan Yazıcı wrote: > In its current form, LogstashLayout can (almost) very well render the > GELF layout[1]. There are only two shortcomings: 1) epoch seconds with > fraction and 2) using PatternLayout while rendering messages. But no > worries, I

Re: The convention for thread-local allocations (TLAs)

On Mon, Jan 6, 2020 at 7:09 PM Matt Sicker wrote: > Would it be useful to implement some sort of buffer pool for > StringBuilders and ByteBuffers? Could likely copy code from netty's > util library (ByteBuf et al.) or reuse stuff from commons-pool if > needed. This would work properly in applicati

Re: The convention for thread-local allocations (TLAs)

On Tue, Jan 7, 2020 at 12:36 AM Ralph Goers wrote: > I am not against making a change but I would need to see performance results > before it gets merged. Unless my knowledge on the JVM is fundamentally wrong, no shared data structure can beat a TLA in terms of access costs. But at which point s

Re: The convention for thread-local allocations (TLAs)

On Thu, Jan 9, 2020 at 12:33 AM Gary Gregory wrote: > Can we please not invent yet another pooling mechanism at Apache? That definitely was not my intention. I was just suggesting borrowing code (not dependency!) from certain projects to get us going, since, to the best of my knowledge, log4j-cor

Re: Thoughts on XML/JSON/YAML layout in Log4j 3.0 (Was: Feature request/possible contribution)

integrating LogstashLayout into log4j-core. On Thu, Jan 9, 2020 at 1:19 AM Ralph Goers wrote: > > Are you still considering contributing this? > > Ralph > > > On Jan 8, 2020, at 2:42 PM, Volkan Yazıcı wrote: > > > > On Tue, Dec 24, 2019 at 10:48 PM Volkan Yazıcı &g

Re: Thoughts on XML/JSON/YAML layout in Log4j 3.0 (Was: Feature request/possible contribution)

On Wed, Dec 25, 2019 at 7:38 AM Ralph Goers wrote: > Also, I must admit I probably would have implemented the > resolvers differently. It seems to me that each “entity" is going > to return either a String, a number, a Map, or an array. So I > would have just had the resolver return its key and i

PluginAttributeBuilder-vs-PluginAttribute

Hello, Started working on replacing JsonLayout with LogstashLayout. I have noticed that @PluginAttributeBuilder is deprecated in favor of @PluginAttribute. I am not equipped with the sufficient background on this decision's justification, but what I can tell is I find @PluginAttribute unpleasant t

Re: PluginAttributeBuilder-vs-PluginAttribute

gt; > Perhaps we need to update our docs/javadoc. > > > > > > -ck > > > > > >> On Jan 16, 2020, at 10:54 AM, Ralph Goers > > >> wrote: > > >> > > >> Builders haven’t gone away, if that is what you are thinking.

final modifier in method args and local variables

Hello, I don't want to turn this into a religious war, but is having final modifier on both method arguments and local variables a convention that *must* be followed or some legacy followed blindly? Because if I can opt out, I would prefer so. Regards.

eol and null-delimiter in Jackson layouts

Jackson layouts accept the following two parameters: String eol boolean includeNullDelimiter Their purpose is simple: logEvent(event); writer.write(eol); if (includeNullDelimiter) { writer.write('\0'); } Isn't it possible to combine this into a single "String eol"

Re: eol and null-delimiter in Jackson layouts

> not using a compact format. > > Gary > > > > > Ralph > > > > > On Jan 17, 2020, at 6:11 AM, Volkan Yazıcı > > wrote: > > > > > > Jackson layouts accept the following two parameters: > > > > > >String eol > > &

Re: eol and null-delimiter in Jackson layouts

Let me add header/footer getters to the list of components whose interaction is still mysterious for me. On Fri, Jan 17, 2020 at 2:45 PM Volkan Yazıcı wrote: > > Gary, would you mind explaining the interaction between the following > fields, please? > > boolean eventEol

FOSDEM'20 attendance

Will any of you Log4j enthusiasts, developers plan to show up in FOSDEM'20[1]? If so, I will be more than happy to share a beer/coffee with you. [1] https://fosdem.org

Migrating from Travis CI to GitHub Actions

Given GitHub has introduced its own CI, i.e., GitHub Actions, would you consider migrating from Travis CI to that? In its current form, setup-java[1] doesn't support multiple JDKs, but I think it can be worked around. If the rest of the people would agree, I will create a ticket for that and work o

Re: Migrating from Travis CI to GitHub Actions

Given everybody is willing to give it a go, I've created LOG4J2-2764[1]. [1] https://issues.apache.org/jira/browse/LOG4J2-2764 On Mon, Jan 20, 2020 at 9:40 PM Volkan Yazıcı wrote: > > Given GitHub has introduced its own CI, i.e., GitHub Actions, would > you consider migrating fro

Preserving Backward-Compatibility While Replacing JsonLayout

While replacing JsonLayout, I am a little bit puzzled by a certain issue, which I will try to exemplify below: LogstashLayout.Builder contains - @PluginBuilderAttribute("prettyPrint") boolean prettyPrintEnabled; - void isPrettyPrintEnabled() - Builder setPrettyPrintEnabled(boolean prettyPrintEnabl

Contributing LogstashLayout to Log4j core

I've just created a PR[1] contributing LogstashLayout to Log4j core. Please see the GitHub link for the feedback/support requests. I will appreciate a quick review cycle, since I will try my best to invest quite some time into this during FOSDEM. [1] https://github.com/apache/logging-log4j2/pull/3

Re: Contributing LogstashLayout to Log4j core

ome of your wrappers if desired. > > On Tue, 28 Jan 2020 at 13:59, Volkan Yazıcı wrote: > > > > I've just created a PR[1] contributing LogstashLayout to Log4j core. > > Please see the GitHub link for the feedback/support requests. I will > > appreciate a quick rev

Re: The convention for thread-local allocations (TLAs)

t; On Dec 28, 2019, at 2:39 PM, Volkan Yazıcı wrote: > > > > Regarding log4j2.enableThreadlocals configuration knob, it feels more > > like a hint rather than a hard restriction. See how > > AbstractStringLayout#getStringBuilder() doesn't take that flag into > >

Necessity of multiple JDKs for build

Hello, Would somebody mind reminding me why do we need multiple JDKs for build rather than just sticking to 11 and tuning the target version whenever necessary? Kind regards.

Best practices for editing the manual

Hello, I have a couple of questions regarding working on the manual. I will appreciate if you can spare some time to help me out with them: 1. What is the easiest Maven command just to get `/target/site` generated? `./mvnw site` works, but is taking ages. 2. What is the recommended practice f

Re: Necessity of multiple JDKs for build

2:24 PM Matt Sicker wrote: > > There are some compile errors if you try to use 11 for everything. If those > are fixed, we can likely use 11 for the whole build with animal sniffer or > something configured to prevent using incorrect APIs. > > On Tue, Feb 4, 2020 at 03:

Re: Contributing LogstashLayout to Log4j core

d "nanos fraction of epoch millis" or "millis fraction of epoch seconds", etc.? I've actually directed this question to @Ralph in the PR review[1], but got no replies so far. Any comments? [1] https://github.com/apache/logging-log4j2/pull/335/files#r372016555 On Tue, Jan

Review request for PR#339 addressing LOG4J2-2703

Hello, I've created a PR[1] addressing the MapMessage JSON formatter bug reported in LOG4J2-2703[2]. Would somebody mind reviewing it, please? Cheers! [1] https://github.com/apache/logging-log4j2/pull/339 [2] https://issues.apache.org/jira/browse/LOG4J2-2703

Help with test-jar in json-template-layout branch

Hello, I am almost done with the new JsonTemplateLayout[1]. Though I am having a difficulty in producing a test-jar out of log4j-layout-json-template module and using it in log4j-perf module. Matt Sicker has also given it a try, but no luck so far[2]. I will really appreciate if somebody can point

Custom class reader for PluginBuilderAttribute

Hello, Given a builder's @PluginBuilderAttribute field of type T, how can I instruct the DI mechanism to employ a certain Function method for injection? Kind regards.

Re: Help with test-jar in json-template-layout branch

ble to look at it tonight or over the weekend. I need to > review the contribution anyway. > > Ralph > > > On Feb 14, 2020, at 6:21 AM, Volkan Yazıcı > wrote: > > > > Hello, > > > > I am almost done with the new JsonTemplateLayout[1]. Though I am > &

Re: Help with test-jar in json-template-layout branch

Hey Ralph! Did you have any time to take a look at the issue? On Fri, Feb 14, 2020 at 3:59 PM Ralph Goers wrote: > > I should be able to look at it tonight or over the weekend. I need to review > the contribution anyway. > > Ralph > > > On Feb 14, 2020, at 6:21

Review request for JsonTemplateLayout

Hello, I think I am done with the JsonTemplateLayout[1]. I will appreciate a thorough review. Kind regards. [1] https://github.com/apache/logging-log4j2/pull/335

Filtering out excessive log payloads

Hello, Given I am done with my JsonTemplateLayout PR and waiting for the review (I am looking at you Ralph), I have started working on removing Jackson dependency. This would allow the layout to be included in the core. A major obstacle I encounter is the implementation of the following two config

Re: Filtering out excessive log payloads

be in a separate > module, I do not know yet. > > Certainly each kind of layout should live in it's own module which is > already almost in place for 3,0. > > Gary > > On Tue, Mar 3, 2020 at 4:12 AM Volkan Yazıcı > wrote: > > > Hello, > > > >

shade+relocate policy & parsing JSON

Hello, I have managed to produce JSON in JsonTemplateLayout without using Jackson. I have successfully implemented all existing features with the exception of pretty printing, which I will leave out. There is a 2nd use case for Jackson in JsonTemplateLayout: reading the JSON schema. That is, JsonT

unstable master branch

Hello, While developing it is really difficult to keep up with the master branch, it continuously gets broken. master and release-2.x diverge a lot as well, hence I am sitting on the fence for whether I should base my changes on master or release-2.x. This is my current state: $ git remote -v ori

Re: unstable master branch

> > I can’t recall ever seeing the error below. It implies that the log4j-plugins > module is being built before the log4j-api module, which never happens for > me. I suppose it would happen if you try to build the log4j-plugin module > from its directory without having built the rest o

Re: unstable master branch

Nope, neither "install" works; fails with the same message. On Thu, Mar 5, 2020 at 4:25 PM Matt Sicker wrote: > > It could be an issue in the pom somewhere. Does "install" instead of > "package" work for you? > > On Thu, 5 Mar 2020 at 02:27, Vol

Re: unstable master branch

[1] https://gist.github.com/vy/a8018bbdf5442e998f95008f5959e775 On Thu, Mar 5, 2020 at 4:34 PM Volkan Yazıcı wrote: > > Nope, neither "install" works; fails with the same message. > > On Thu, Mar 5, 2020 at 4:25 PM Matt Sicker wrote: > > > > It could be an issue in the

Dependency-free JsonTemplateLayout

I have finally removed all dependencies of JsonTemplateLayout, except for optional JCTools dependency. I have a couple of questions to proceed further: 1. May I move the code in the module to core? 2. Shall I remove benchmark results in the manual since it is difficult to keep them up to date?

Re: Dependency-free JsonTemplateLayout

My comments are inline. On Wed, Mar 11, 2020 at 4:01 PM Ralph Goers wrote: > 1. Did you lose functionality by removing the dependencies? Except pretty printing, no. > 2. Did you have to add things like JSON parsing to > remove the dependencies? Yes, I have implemented simple JsonReader[1] and

Re: Dependency-free JsonTemplateLayout

e a while with 97 files being modified. > > Ralph > > > On Mar 11, 2020, at 8:01 AM, Ralph Goers wrote: > > > > > >> On Mar 11, 2020, at 7:09 AM, Volkan Yazıcı wrote: > >> > >> I have finally removed all dependencies of JsonTemplateLayout,

Re: Dependency-free JsonTemplateLayout

/RecyclerFactories.java https://github.com/vy/log4j2/blob/json-template-layout/src/site/asciidoc/manual/json-template-layout.adoc#recycling-strategy [6] https://github.com/JCTools/JCTools/issues/289 On Wed, Mar 11, 2020 at 4:19 PM Volkan Yazıcı wrote: > > My comments are inline. > > On Wed, Mar 11, 202

Property prefix convention

Hello, I see there are multiple property prefix conventions in the sources, e.g., `log4j2.enable.threadlocals` and `log4j.maxReusableMsgSize`. In JsonTemplateLayout, builder defaults are initialized via properties too[1]. There shall I stick to `log4j`, `log4j2`, or even `log4j3` property prefix?

LockingStringBuilderEncoder ByteBuffer

Hello, I want to take advantage of StringBuilder plumbing in the core module. There are two Encoder implementations: StringBuilderEncoder and LockingStringBuilderEncoder. Given JsonTemplateLayout has its own customizable recycling strategy, I can't use StringBuilderEncoder due to its TLAs. Locking

Re: LockingStringBuilderEncoder ByteBuffer

On Sun, Mar 15, 2020 at 6:03 PM Ralph Goers wrote: > After looking at the code I am sure there is something > wrong with the logic. While you can set property > log4j2.enable.direct.encoders to true or false it > uses the same Encoder in either case. I am a little bit puzzled here. Which particul

Re: unstable master branch

erate the test-jar. Speaking of subtle details ruining a developer's life... Renaming default-jar in maven-jar-plugin configuration to something else also breaks the compilation. Though I did not further dig this down. Just don't do it. On Wed, Mar 4, 2020 at 12:51 PM Volkan Yazıcı w

Re: [VOTE] Move Log4net to dormant state

+1 On Mon, Mar 30, 2020 at 12:23 AM Ralph Goers wrote: > Seeing as there have been no volunteers after my last message regarding > Log4Net, I propose that it be moved to a dormant status. This would simply > entail: > 1. Create a tag of the source. > 2. Create an archive of the source to be pla

Re: [VOTE] Log4Net dormant release

+1 On Sun, 5 Apr 2020, 00:25 Ralph Goers wrote: > I have modified the STATUS.txt and README.txt for Log4Net, tagged the > source, zipped it and then published it to > https://dist.apache.org/repos/dist/dev/logging/log4net/ < > https://dist.apache.org/repos/dist/dev/logging/log4net/>. > > This is

JSON quoting discrepancies

Hello, There are a couple of concerns I want to share regarding the available JSON quoting options in the core. I would appreciate your feedback on them. 1. My first concern is... There are 2 competing JSON quoting implementations in the core: - JsonUtils.quoteAsString(CharSequence, String

Magic char(s) breaking SocketAppender behavior

Hello, While trying to understand the behavior of SocketAppender against uncommon Unicode characters, I have come across to an interesting case: \uD800 gets transmitted as \u003F ('?'). One can easily verify this by appending \uD800 at the end of "This is a test message" literals in SocketAppender

Re: Json Template Layout

Hey Ralph, Thanks so much for taking time to review such a lengthy PR, much appreciated. Let me try to address your concerns and share some of mine: Does JTL (i.e., JsonTemplateLayout) support Logstash? I've tried it locally against an actually running Logstash instance and it has worked fine. Th

Re: Json Template Layout

o Kibana. It was pretty easy for me to set it all > > up in docker containers. I think the log4j-spring-cloud-sample project has > > reference to the docker setup I used. > > > > Ralph > > > > > > > >> On Apr 11, 2020, at 11:23 PM, Volkan Yazıcı

Re: Json Template Layout

erns regarding updating the logging in the cloud page. > > Ralph > > > > > > On Apr 19, 2020, at 2:30 PM, Volkan Yazıcı wrote: > > > > Hello Ralph, > > > > [Due to #COVID-19, day cares are closed. I can hardly spare time to > > work, including L

Garbage-generating PatternLayout#serialize(LogEvent,StringBuilder)

Hello, For the records, PatternLayout#serialize(LogEvent,StringBuilder) falls back to AbstractStringLayout#toSerializable(LogEvent,StringBuilder) which consequently passes the ball to toSerializable(LogEvent), which is not garbage-free. This is an obstacle for certain layouts (e.g., Gelf, JsonTemp

Re: [ANNOUNCEMENT] Welcome Volkan Yazici

I am speechless, thanks so much Ralph! That means a lot coming from you. I will do my best push the project forward. On Sun, May 17, 2020 at 12:19 AM Ralph Goers wrote: > > > > Hi, > > it is my pleasure to announce to the community that Volkan Yazici has joined > our ranks as a new Committer. >

Re: [Log4j] Potential simplification to java9 builds?

Maybe a naive question, but... Does anybody know how other Apache projects deal with this? Do they also require multiple JDKs to be present at compile time? Do they also employ `java9` directory work arounds as in log4j? On Sat, Apr 11, 2020 at 6:39 PM Matt Sicker wrote: > > I was playing around

Re: Json Template Layout

, I’d like > that option anyway. > > I would suggest you attempt to work to make a template that matches the > result of the GelfLayout I had previously documented. > > But now that I understand what is going on I am OK with this contribution > being merged. I would like to ge

Re: Json Template Layout

Unless there are objections, I want to merge the branch to master. There on I will share json-template-layout.md with the community to collect some feedback on the API. In particular, I have existing users of LogstashLayout in mind. Kind regards. On Mon, May 18, 2020 at 1:18 AM Ralph Goers w

Re: [log4j] Drop org.apache.logging.log4j.util.Supplier from master for 3.x

May I second that with {Bi,Tri}Consumer classes as well? On Sun, May 24, 2020 at 11:21 PM Gary Gregory wrote: > > Hi All, > > Can we drop org.apache.logging.log4j.util.Supplier from master for 3.x and > replace its usage with java.util.function.Supplier? > > Gary

Re: Json Template Layout

Somebody mind giving me write access to the GitHub repo, please? I am not able to merge the PR. On Fri, May 22, 2020 at 3:53 PM Apache wrote: > > Feel free to merge it. I will test it there when I can. > > Ralph > > > > On May 22, 2020, at 4:50 AM, Volkan Yazıcı w

Re: Json Template Layout

visual cue to proceed further. Maybe it is just me...) On Mon, May 25, 2020 at 12:02 AM Ralph Goers wrote: > > You should already have it. > > Ralph > > > On May 24, 2020, at 2:59 PM, Volkan Yazıcı wrote: > > > > Somebody mind giving me write access to the GitHub

JsonTemplateLayout template directives

Hello, In JTL, we employ two templating languages within each other. Consider the following GelfLayout.json: { "version": "1.1", "host": "${hostName}", "short_message": "${json:message}", "full_message": "${json:exception:stackTrace:text}", "timestamp": "${json:t

Re: Json Template Layout

t 8:49 AM, Matt Sicker wrote: > > > > Make sure your account is linked properly: > > https://gitbox.apache.org/setup/ > > > > On Mon, May 25, 2020 at 07:23 Volkan Yazıcı wrote: > > > >> Ralph, I can indeed see I am a member of the Apache organizatio

Re: Json Template Layout

BAM! JsonTemplateLayout is merged to master! 🎉🍾 (I needed to wait some for the GitHub write access to get sync'ed with Apache LDAP.) On Mon, May 25, 2020 at 9:46 PM Volkan Yazıcı wrote: > > I had missed the GitBox Account Linking Matt has mentioned. I have > just comple

Re: [apache/logging-log4j2] LOG4J2-2749 - fix JSON Layout output containing empty values while configured otherwise (#362)

While master builds are successful, release-2.x builds have been broken on Travis CI for quite a long time (more than 2 months?) that I have the impression that something else is going on there. This becomes a problem for approving PRs like the one in the attachment. Would anybody mind sharing what

Re: [log4j] Drop org.apache.logging.log4j.util.Supplier from master for 3.x

Can we also replace core.time.Instant with java.time.Instant? On Sun, May 24, 2020 at 11:57 PM Volkan Yazıcı wrote: > > May I second that with {Bi,Tri}Consumer classes as well? > > On Sun, May 24, 2020 at 11:21 PM Gary Gregory wrote: > > > > Hi

JsonTemplateLayout is ready for public review

Hello, Regarding JsonTemplateLayout, I've just pushed the following changes to the master: 1. Set the default template to ECS[1]. Picking a default is a delicate process and has quite some implications in the long term. After evaluating the existing options (incl. no default at all!), I

Broke master due to UriUtilTest failure on Windows

Sorry, I've just noticed that I broke the `master` builds due to a UriUtilTest failure[1] on Windows. I will fix it ASAP. [1] https://builds.apache.org/view/L/view/Logging/job/log4j/job/master/76/testReport/org.apache.logging.log4j.layout.json.template.util/UrisTest/Continuous_Integration___Windo

Re: Broke master due to UriUtilTest failure on Windows

Fixed: https://builds.apache.org/view/L/view/Logging/job/log4j/job/master/78/ On Sun, Jun 7, 2020 at 11:03 PM Volkan Yazıcı wrote: > > Sorry, I've just noticed that I broke the `master` builds due to a > UriUtilTest failure[1] on Windows. I will fix it ASAP. > > [1] > ht

Merging JsonTemplateLayout to release-2.x branch

Hello, May I cherry-pick the JsonTemplateLayout-related changes to release-2.x branch? Are there any objections regarding its current form and changes it incorporates? Kind regards.

Removal of log4j-layout-jackson-* modules

Hello, I want to go forward and delete log4j-layout-jackson-* modules from the master. This will effectively remove JsonLayout, XmlLayout, and YamlLayout. Given these changes break backward compatibility, shall I introduce these changes to a new release-3.x branch? Maybe this is a good moment to d

Review request for LOG4J2-2828

Hello, I've pushed a fix[1] for LOG4J2-2828[2]. Would somebody mind reviewing it, please? Cheers! [1] https://github.com/apache/logging-log4j2/pull/364 [2] https://issues.apache.org/jira/projects/LOG4J2/issues/LOG4J2-2828

Re: Merging JsonTemplateLayout to release-2.x branch

he way it was previously. > > Ralph > > > On Jun 15, 2020, at 11:26 AM, Volkan Yazıcı wrote: > > > > Hello, > > > > May I cherry-pick the JsonTemplateLayout-related changes to > > release-2.x branch? Are there any objections regarding its current > > form and changes it incorporates? > > > > Kind regards. > > > >

Re: Removal of log4j-layout-jackson-* modules

onal and I prefer not to implement this feature in JTL. On Mon, Jun 15, 2020 at 11:49 PM Ralph Goers wrote: > > Is it possible to modify those Layouts to use yours instead? I’d prefer not > to break existing applications. > > Ralph > > > On Jun 15, 2020, at 11:36 AM, V

Re: Review request for LOG4J2-2828

One more "blocker" is down. Changes are merged to master. Thanks to @Remko for the review. On Wed, Jun 17, 2020 at 10:29 AM Volkan Yazıcı wrote: > > Hello, > > I've pushed a fix[1] for LOG4J2-2828[2]. Would somebody mind reviewing > it, please? > > Cheer

How to handle stack trace serialization errors

Hello, Yesterday I've paged by a colleague for a really strange logging behaviour on production. The logging stops working after 15m-2h. Diving into Tomcat catalina logs pointed out that there is a particular exception whose Throwable#printStackTrace(PrintWriter) method is throwing an exception --

  1   2   3   4   5   6   7   8   9   10   >