On Fri, Nov 16, 2018 at 1:14 PM Gary Gregory <[email protected]> wrote:

>
>
> On Fri, Nov 16, 2018 at 12:30 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.
>>
>
> IMO, we should change the package names and artifact IDs to contains a "3"
> postfix, like we did in HttpComponents for version 5, so probably
> "log4j-core3", "log4j-api3" and so on. To be discussed...
>

I take it back "log4j3-..." is better, unless we go with something like
"log4j-r3-..." or "log4j-v3-..."

Gary

>
>
>>
>> *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?
>>
>
> Sounds OK, PRs welcome. Ralph, any thoughts?
>
> Gary
>
>
>> 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?
>>
>
> The first step would be to change the license to the Apache License v2.
>
> Gary
>
>
>>
>> *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