Patches are welcome! :-) Gary
On Sat, Nov 17, 2018, 12:26 Volkan Yazıcı <[email protected] wrote: > One more feature request: > > *Garbage-free ThreadContext Map and Stack Accessors* > > I do not have the complete view of what it looks like under > the hood, but to the best of my knowledge > > - ThreadContext.ContextStack does not provide any > garbage-free iteration methods. > - LogEvent#getContextData() returns a value of type > ReadOnlyStringMap. This interface has implementations > that do not provide garbage-free iteration methods > as well. > > I would really appreciate if ThreadContext data and stack > interfaces would enforce garbage-free accessors. > > > > On Fri, Nov 16, 2018 at 8:29 PM Volkan Yazıcı <[email protected]> > 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 really encourage you to explicitly > > state the version in artifact and package names. For instance, > > log4j3-core and org.apache.logging.log4j3, etc. It goes without > > saying, this will also aid SEO too, which is a pain right now. > > > > *Allowing Batches in Appender Interface* > > > > Is it also possible to extend the Appender interface such that in > > addition to append(LogEvent), batched append(LogEvent[]), > > append(LogEvent[], int offset, int length) are allowed as well? > > > > For instance, in log4j2-redis-appender I needed to implement > > my own AsyncAppender logic to push the serialized LogEvent's > > to Redis in batches. > > > > *Merging log4j2-redis-appender to master* > > > > Would you consider merging log4j2-redis-appender > > <https://github.com/vy/log4j2-redis-appender> to master? > > > > *Merging log4j2-logstash-layout to master* > > > > Given its garbage-free superior performance and schema > > customization support, would you consider merging > > log4j2-logstash-layout > > <https://github.com/vy/log4j2-logstash-layout/tree/json-generator> to > > master? We can rebrand it as the > > next JSONLayout and provide pre-cooked schemas for common > > use cases, for instance, a schema of the old JSONLayout, a > > schema for the pretty common Logstash event layout v1 > > <https://github.com/logstash/log4j-jsonevent-layout>, etc. > > > > Best. > > > > > > On Mon, Nov 5, 2018 at 10:01 PM Gary Gregory <[email protected]> > > wrote: > > > >> Considerations for 3.0: > >> > >> - Currently targeting Java 8, seems OK to keep this for now. > >> - Remove deprecated code > >> - Make BC-breaking changes as we see fit to improve impl. > >> - ? Update root package to include "3" to allow Log4j 1, 2, and 3 to > >> co-exist peacefully on the claspath. Perhaps org.apache.logging.log4j3. > >> - Do we need a compatibility layer for 1.2 to 3.0 and 2.x to 3.0? > >> - Where can we use java.time? > >> - Is it a goal to have Maven modules with NO optional dependencies? I > >> think > >> so. > >> - Play nice in the Java 9 module system > >> - Continue to break up current Maven modules > >> - How can we make Core smaller? > >> - Should we redo our config code to use something like Jackson or > Commons > >> Configuration? We have a lot of config code... Not sure if everything > you > >> can do in XML is doable in JSON and YAML. YAML is gross IMO but some > >> people > >> like it. > >> > >> What else? > >> > >> Gary > >> > > >
