Github user rgoers commented on the issue:
https://github.com/apache/logging-log4j2/pull/221
Seems reasonable to me.
---
Github user rgoers commented on the issue:
https://github.com/apache/logging-log4j-audit/pull/12
I'm sorry, I just haven't had a chance to look at this yet.
---
Github user rgoers commented on the issue:
https://github.com/apache/logging-log4j-audit/pull/4
This PR has merge conflicts.
---
Github user rgoers commented on the issue:
https://github.com/apache/logging-log4j-audit/pull/8
See above. This PR has merge conflicts.
---
Github user rgoers commented on the issue:
https://github.com/apache/logging-log4j2/pull/213
I just looked at the statistics and 13% of last month's downloads were for
2.3 so I guess a fair number of people are still stuck at Java 6. Although I
have no problem providing suppor
Github user rgoers commented on the issue:
https://github.com/apache/logging-log4j-audit/pull/3
Thanks, I'll review this as soon as I can.
---
Github user rgoers commented on the issue:
https://github.com/apache/logging-log4j2/pull/212
I don't think a note is needed for the refactoring unless it is going to
close the Jira issue. I'd like to look at the new code and the performance
tests before doing that. Hopefull
Github user rgoers commented on a diff in the pull request:
https://github.com/apache/logging-log4j2/pull/213#discussion_r212697572
--- Diff:
log4j-jul/src/main/java/org/apache/logging/log4j/jul/Log4jBridgeHandler.java ---
@@ -0,0 +1,198 @@
+/*
+ * Licensed to the Apache
Github user rgoers commented on the issue:
https://github.com/apache/logging-log4j2/pull/212
ThrowableProxyRenderer was the same name I was going to use so I think we
are good on that one. As for the other I would be ok with ThrowableProxyHelper,
ThrowableProxyUtil. I am not as
Github user rgoers commented on a diff in the pull request:
https://github.com/apache/logging-log4j2/pull/213#discussion_r212672416
--- Diff: log4j-jul/src/site/markdown/index.md ---
@@ -74,3 +74,29 @@ Java Level | Log4j Level
[`FINER`](http://docs.oracle.com/javase/6/docs
Github user rgoers commented on a diff in the pull request:
https://github.com/apache/logging-log4j2/pull/213#discussion_r212672750
--- Diff:
log4j-jul/src/main/java/org/apache/logging/log4j/jul/Log4jBridgeHandler.java ---
@@ -0,0 +1,198 @@
+/*
+ * Licensed to the Apache
Github user rgoers commented on the issue:
https://github.com/apache/logging-log4j2/pull/212
I like it.
---
Github user rgoers commented on the issue:
https://github.com/apache/logging-log4j2/pull/206
I am not exactly sure when log4j 2 3.0 will be released. I think we have a
bit more work we want to do before we do that.
---
Github user rgoers commented on the issue:
https://github.com/apache/logging-log4j2/pull/206
I am probably fine with that.
---
Github user rgoers commented on the issue:
https://github.com/apache/logging-log4j2/pull/206
@jvz Exactly. But I am fine if refactoring to support that is done later
should anyone want to do it.
---
Github user rgoers commented on the issue:
https://github.com/apache/logging-log4j2/pull/206
I'm sorry, but I have to disagree. log4j-redis-jedis is just laughable. I
can't imagine anyone will care that Jedis is used to connect to Redis. If there
is a reason to switch to
Github user rgoers commented on a diff in the pull request:
https://github.com/apache/logging-log4j2/pull/206#discussion_r210158675
--- Diff:
log4j-redis/src/main/java/org/apache/logging/log4j/redis/appender/RedisAppender.java
---
@@ -0,0 +1,243 @@
+/*
+ * Licensed to the
Github user rgoers commented on a diff in the pull request:
https://github.com/apache/logging-log4j2/pull/206#discussion_r210157854
--- Diff:
log4j-redis/src/main/java/org/apache/logging/log4j/redis/appender/LoggingJedisPoolConfiguration.java
---
@@ -0,0 +1,127 @@
+package
Github user rgoers commented on a diff in the pull request:
https://github.com/apache/logging-log4j2/pull/206#discussion_r210161590
--- Diff:
log4j-redis/src/test/java/org/apache/logging/log4j/redis/appender/RedisManagerTest.java
---
@@ -0,0 +1,97 @@
+package
Github user rgoers commented on a diff in the pull request:
https://github.com/apache/logging-log4j2/pull/206#discussion_r210161631
--- Diff:
log4j-redis/src/test/java/org/apache/logging/log4j/redis/appender/RedisAppenderTest.java
---
@@ -0,0 +1,159 @@
+/*
--- End diff
Github user rgoers commented on a diff in the pull request:
https://github.com/apache/logging-log4j2/pull/206#discussion_r210161652
--- Diff:
log4j-redis/src/main/java/org/apache/logging/log4j/redis/appender/RedisManager.java
---
@@ -0,0 +1,104 @@
+package
Github user rgoers commented on the issue:
https://github.com/apache/logging-log4j2/pull/210
Yes, the performance is important when it clearing is underperforming.
---
Github user rgoers commented on the issue:
https://github.com/apache/logging-log4j2/pull/210
As I said on the mailing list, I would like to simplify ThrowableProxy by
moving all the rendering logic to a new Class, ThrowableProxyRenderer. I don't
know how it got this wa
Github user rgoers commented on the issue:
https://github.com/apache/logging-log4j2/pull/195
For the sake of argument lets say I agree that optimizing performance here
would be good. That still doesn't solve the second issue that it is likely to
cause problems in applications
Github user rgoers commented on the issue:
https://github.com/apache/logging-log4j2/pull/195
This makes no sense to me.
1. The cache is meant to keep a record of the cache entries in a single set
of chained exceptions.
1. This logic attempts to optimize the performance of
Github user rgoers commented on the issue:
https://github.com/apache/logging-log4j2/pull/167
Log4j-2390 created to track this.
---
Github user rgoers commented on the issue:
https://github.com/apache/logging-log4j2/pull/172
This PR was merged in May but apparently neglected to use the format to
trigger github to close it.
---
Github user rgoers commented on the issue:
https://github.com/apache/logging-log4j2/pull/173
@garydgregory Agreed. That was what I was questioning in my first comment.
---
Github user rgoers commented on the issue:
https://github.com/apache/logging-log4j2/pull/173
This shouldn't need to be a system property. it can be an attribute of the
configuration element.
---
Github user rgoers commented on the issue:
https://github.com/apache/logging-log4j2/pull/173
Why not just an attribute of the existing plugin?
---
Github user rgoers commented on the issue:
https://github.com/apache/logging-log4j2/pull/163
Is there a Jira issue for this?
---
Github user rgoers commented on the issue:
https://github.com/apache/logging-log4j2/pull/148
I don't understand why any of these changes are required. If you want
access to those in your Layout just call getFormat() and getParameters()
instead of getFormattedMessage().
---
Github user rgoers commented on the issue:
https://github.com/apache/logging-log4j2/pull/144
4. Run all the unit tests to make sure your fix didn't break something else.
---
Github user rgoers commented on the issue:
https://github.com/apache/logging-log4j2/pull/138
To be 100% certain that we didn't reference anything from Java 8 by
accident.
---
Github user rgoers commented on the issue:
https://github.com/apache/logging-log4j2/pull/138
All release builds are done with the Java 7 compiler.
---
Github user rgoers commented on the issue:
https://github.com/apache/logging-log4j2/pull/128
I'd be hesitant to apply this without understanding why contextInitialized
isn't being called.
---
Github user rgoers commented on the issue:
https://github.com/apache/logging-log4j2/pull/121
I'm not sure that this is really a problem. The Log4j-1.2-api provides a
Log4j1XmlLayout to be compatible with Log4j 1.x.
---
37 matches
Mail list logo
