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
On Tue, Oct 30, 2018 at 7:08 PM Gary Gregory wrote:
> On Mon, Oct 22, 2018 at 5:40 PM Remko Popma wrote:
>
>> I’ll take a look.
>>
>
Ping :-)
>
> Ping ;-)
>
> Gary
>
>>
>>
>>
>> > On Oct 23, 2018, at 4:38, Gary Gregory wrote:
>> >
>> > In org.apache.logging.log4j.core.config.AbstractConfigura
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
Yeah, that format and library is designed around Java in mind and Scala as
a downstream user (unlike most Lightbend things which are Scala-first).
On Mon, 5 Nov 2018 at 15:03, Gary Gregory wrote:
> On Mon, Nov 5, 2018 at 2:02 PM Gary Gregory
> wrote:
>
> > On Mon, Nov 5, 2018 at 1:59 PM Matt Si
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
On Mon, Nov 5, 2018 at 2:02 PM Gary Gregory wrote:
> On Mon, Nov 5, 2018 at 1:59 PM Matt Sicker wrote:
>
>> I like the HOCON format for duration values:
>> https://github.com/lightbend/config/blob/master/HOCON.md#duration-format
>
>
> That looks easy to map to Java TimeUnit.
>
I could see augme
On Mon, Nov 5, 2018 at 1:59 PM Matt Sicker wrote:
> I like the HOCON format for duration values:
> https://github.com/lightbend/config/blob/master/HOCON.md#duration-format
That looks easy to map to Java TimeUnit.
Gary
>
>
> On Mon, 5 Nov 2018 at 14:53, Gary Gregory wrote:
>
> > On Mon, Nov
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
I like the HOCON format for duration values:
https://github.com/lightbend/config/blob/master/HOCON.md#duration-format
On Mon, 5 Nov 2018 at 14:53, Gary Gregory wrote:
> On Mon, Nov 5, 2018 at 1:50 PM Ralph Goers
> wrote:
>
> > I have no problem with this but would think it would be something we
On Mon, Nov 5, 2018 at 1:50 PM Ralph Goers
wrote:
> I have no problem with this but would think it would be something we would
> want to do in 3.0 and not 2.x. Rather than to keep introducing features to
> 2.x I’d like to concentrate a bit on figuring out what things really need
> to be changed f
On Mon, Nov 5, 2018 at 12:46 PM Matt Sicker wrote:
> The Duration format is just ISO-8601. Problem is that nobody uses that part
> of the spec. :)
>
We use ISO-8601 to configure some files at work and it works, but it's a
bit ugly. I'm OK supporting both formats even. I just want a better format
I have no problem with this but would think it would be something we would want
to do in 3.0 and not 2.x. Rather than to keep introducing features to 2.x I’d
like to concentrate a bit on figuring out what things really need to be changed
for a 3.0 release and adding new significant features ther
The Duration format is just ISO-8601. Problem is that nobody uses that part
of the spec. :)
On Mon, 5 Nov 2018 at 13:33, Gary Gregory wrote:
> On Mon, Nov 5, 2018 at 12:12 PM Carter Kozak wrote:
>
> > Big +1 for values with units.
> > Unless we need to support this on 2.x, should we take advant
I agree that we shouldn't use the Duration.parse functionality, but
perhaps we can define our own parser to convert strings into Duration
objects similar to the parse function in TimeValue. Thoughts?
On Mon, Nov 5, 2018 at 2:33 PM Gary Gregory wrote:
>
> On Mon, Nov 5, 2018 at 12:12 PM Carter Koza
On Mon, Nov 5, 2018 at 12:12 PM Carter Kozak wrote:
> Big +1 for values with units.
> Unless we need to support this on 2.x, should we take advantage of
> java 8 java.time.Duration as our value type, and only implement the
> parser ourselves?
>
I think that tracking as a Duration is OK. The only
Big +1 for values with units.
Unless we need to support this on 2.x, should we take advantage of
java 8 java.time.Duration as our value type, and only implement the
parser ourselves?
On Mon, Nov 5, 2018 at 1:54 PM Gary Gregory wrote:
>
> Hi All:
>
> Today in appenders like the JMS Appender you can
Hi All:
Today in appenders like the JMS Appender you can specify time values like
the setting reconnectIntervalMillis="5000"; same idea with the mysterious
Configuration monitorInterval which is specified in seconds (how would you
know that without digging in the docs? ;-)
What I'd like to see in
Thank you Carter! :-)
Gary
On Mon, Nov 5, 2018 at 9:26 AM Carter Kozak wrote:
> Should be resolved :-)
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/924a476c
> On Mon, Nov 5, 2018 at 11:22 AM Carter Kozak wrote:
> >
> > Looks like this commit broke the JUL WrappedLogger:
> > b
Should be resolved :-)
http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/924a476c
On Mon, Nov 5, 2018 at 11:22 AM Carter Kozak wrote:
>
> Looks like this commit broke the JUL WrappedLogger:
> bccb9a365a7de68431b7165a33d514f07e659528
>
> -ck
Looks like this commit broke the JUL WrappedLogger:
bccb9a365a7de68431b7165a33d514f07e659528
-ck
22 matches
Mail list logo
