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
>

Reply via email to