Yes that’d be interesting.
I’d like to understand whether they could not use the ContextMap instead.
Remko.
(Shameless plug) Every java main() method deserves http://picocli.info
> On Nov 19, 2018, at 7:48, Ralph Goers wrote:
>
> I asked about that once and someone did come up with a reason a
I asked about that once and someone did come up with a reason as to why they
would use it. I’d have to hunt through the archives to find it though.
Ralph
> On Nov 18, 2018, at 9:17 AM, Matt Sicker wrote:
>
> Maybe we should deprecate it, but keep it in? The map version is still
> useful, but t
Maybe we should deprecate it, but keep it in? The map version is still
useful, but the stack form has always confused me as to why you’d use it
somewhere.
On Sat, Nov 17, 2018 at 15:26, Remko Popma wrote:
> Would it be an idea to drop support for ThreadContext.ContextStack
> altogether in log4j
Would it be an idea to drop support for ThreadContext.ContextStack altogether
in log4j 3?
Remko.
(Shameless plug) Every java main() method deserves http://picocli.info
> On Nov 18, 2018, at 4:25, Volkan Yazıcı wrote:
>
> ThreadContext.ContextStack
Patches are welcome! :-)
Gary
On Sat, Nov 17, 2018, 12:26 Volkan Yazıcı 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.ContextSta
The master branch is already on Java 8.
Gary
On Sat, Nov 17, 2018, 12:23 Volkan Yazıcı AsyncAppender can very well leverage this. Am I missing
> something? For the ones that do not implement these two
> methods, we can define a default interface method for
> them -- given log4j3 will target Java
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#getContextDat
AsyncAppender can very well leverage this. Am I missing
something? For the ones that do not implement these two
methods, we can define a default interface method for
them -- given log4j3 will target Java 8+.
On Sat, Nov 17, 2018 at 1:27 AM Ralph Goers
wrote:
>
>
> > On Nov 16, 2018, at 1:14 PM,
> On Nov 16, 2018, 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
>> for JAR Hell problems since they included wrong Log4j artifact.
>> The a
On Fri, Nov 16, 2018 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
>> for JAR Hell problems since they included wrong Log4j artifact.
>> The arti
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*
> >
> > Once every couple of mont
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
> for JAR Hell problems since they included wrong Log4j artifact.
> The artifact and package names of Log4j 1 and Log4j 2 are
> pretty similar loo
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
I’m not surprised. My plan for the socket appender is to look at leveraging
Netty. I believe it handles all of what I want to do really well.
Ralph
> On Nov 6, 2018, at 4:38 PM, Gary Gregory wrote:
>
> On Tue, Nov 6, 2018 at 4:10 PM Remko Popma wrote:
>
>> It may be wise to always include so
On Tue, Nov 6, 2018 at 4:10 PM Remko Popma wrote:
> It may be wise to always include some (configurable) backoff mechanism, to
> prevent our failover/reconnect logic from essentially initiating a denial
> of service attack when the service appears to be unavailable.
>
> Not sure if we currently h
It may be wise to always include some (configurable) backoff mechanism, to
prevent our failover/reconnect logic from essentially initiating a denial of
service attack when the service appears to be unavailable.
Not sure if we currently have this anywhere, but if we’re thinking to extract
some
It would be helpful if we could implement failover and retrial in a
way that is compatible with disabling immediate flush. The current
implementations may surface a failure to the attempt to log an end of
batch, but don't provide a mechanism to retry queued or buffered
events.
On Tue, Nov 6, 2018
On Tue, Nov 6, 2018 at 11:19 AM Ralph Goers
wrote:
> The socket appender already has the ability to reconnect. It just needs to
> ability to load balance or send to an alternate host if the connection
> fails.
>
Sure, I just would like reconnection and failover to be abstracted in our
core frame
The socket appender already has the ability to reconnect. It just needs to
ability to load balance or send to an alternate host if the connection fails.
Ralph
> On Nov 6, 2018, at 11:15 AM, Gary Gregory wrote:
>
> Speaking of failover kind of things, the JMS Appender has a reconnect
> feature
Speaking of failover kind of things, the JMS Appender has a reconnect
feature and I am wrapping up a similar feature for the JDBC Appender. This
kind of feature is a MUST for services that need to stay up and running for
longer periods of time.
It would be nice to have a reconnect feature abstract
Some other features I need/want to do:
1. LOG4J2-1137
2. Allow the SocketAppender to specify multiple IP addresses and allow either
round-robining through them or failing to the next if the first fails. This
will provide better high availability for applications.
3. Support a ContextSelector bas
How much are we impacting the API? I don’t know that package naming is required
if the API is compatible. I am hoping this doesn’t impact the API much.
I’d prefer this just be log4j 3.x. Log4j 2 3.x is just really weird.
I wouldn’t say a module shouldn’t have any optional dependencies but it s
Another API I've wanted to see is a proper async API. Since we're using
Java 8, this can be based on CompletableFuture. This would be mostly useful
for appenders that use networking (so mostly the database and message queue
appenders).
A nice to have would be a stable SPI for plugins with guarante
I'd like to consider potential API breaking refactors around
ThrowableProxy regarding LOG4J2-2391. The jar lookup is incredibly
expensive and creates a great deal of additional complexity.
On Mon, Nov 5, 2018 at 4:06 PM Matt Sicker wrote:
>
> One of my biggest bikeshedding questions I've been thin
One of my biggest bikeshedding questions I've been thinking about here is:
do we call it Log4j2 3.x or Log4j3?
On a more serious note, yes, I'd love to see the config parsing stuff
redone. I like using YAML over JSON or properties files, that's for sure,
though XML can be nicer when the XSD has en
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.loggi
26 matches
Mail list logo
