OK, cool.
Then there are unused local variables, which you then wonder which calls
still need to be made.
DescriptionResourcePathLocationType
The value of the local variable receiver is not used
JMSTopicFailoverTest.java
/log4j-core/src/test/java/org/apache/logging/log4j/core/net
Hmm. The tests can certainly be cleaned up. I'm surprised at some of the other
ones but they may be the result of refactoring. Give me a day or two to look
at them.
On Jan 10, 2013, at 10:33 PM, Gary Gregory wrote:
> Should these unused fields be removed?
>
> DescriptionResourcePath
[
https://issues.apache.org/jira/browse/LOG4J2-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LOG4J2-145:
Summary: Add missing serial version IDs (was: Add missing serial version
IDs.)
> Add missing
Gary Gregory created LOG4J2-145:
---
Summary: Add missing serial version IDs.
Key: LOG4J2-145
URL: https://issues.apache.org/jira/browse/LOG4J2-145
Project: Log4j 2
Issue Type: Bug
Affects Ver
[
https://issues.apache.org/jira/browse/LOG4J2-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved LOG4J2-145.
-
Resolution: Fixed
commit -m "[LOG4J2-145] Add missing serial version IDs." (12 paths specified)
Should these unused fields be removed?
DescriptionResourcePathLocationType
The value of the field XMLConfiguration.Status.element is not used
XMLConfiguration.java
/log4j-core/src/main/java/org/apache/logging/log4j/core/configline
324Java Problem
The value of the field Flum
[
https://issues.apache.org/jira/browse/LOG4J2-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved LOG4J2-144.
-
Resolution: Fixed
commit -m "[LOG4J2-144] NullPointerException in RFC5424Layout."
C:/svn/org/apa
[
https://issues.apache.org/jira/browse/LOG4J2-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13550872#comment-13550872
]
Ralph Goers commented on LOG4J2-109:
This seems like it is almost the same as the comb
Gary Gregory created LOG4J2-144:
---
Summary: NullPointerException in RFC5424Layout
Key: LOG4J2-144
URL: https://issues.apache.org/jira/browse/LOG4J2-144
Project: Log4j 2
Issue Type: Bug
Thank you for fixing this again and exercising kindness! :)
Gary
On Thu, Jan 10, 2013 at 1:23 PM, Gary Gregory wrote:
> Crud
>
> Gary
>
> On Jan 10, 2013, at 12:33, Ralph Goers wrote:
>
> > I believe you made this first change before and it had to be reverted as
> it fails when compiling w
[
https://issues.apache.org/jira/browse/LOG4J2-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13550823#comment-13550823
]
Gary Gregory commented on LOG4J2-109:
-
Then I suppose the all-in-one jar isn't "all" a
[
https://issues.apache.org/jira/browse/LOG4J2-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joern Huxhorn closed LOG4J2-139.
Confirmed.
> NPE while using SocketAppender
> --
>
>
[
https://issues.apache.org/jira/browse/LOG4J2-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joern Huxhorn closed LOG4J2-142.
Works, thanks!
> Exception while deserializing event from SocketAppender
> ---
[
https://issues.apache.org/jira/browse/LOG4J2-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13550684#comment-13550684
]
Ralph Goers edited comment on LOG4J2-109 at 1/11/13 1:43 AM:
-
On Jan 10, 2013, at 19:55, Ralph Goers wrote:
On Jan 10, 2013, at 4:23 PM, Gary Gregory wrote:
It all depends on what "..." contains doesn't it? If it's a simple
one-liner-single-method-call-with-no-args, the "final" may seem overkill,
but it is more complex it is not IMO. This is all about co
[
https://issues.apache.org/jira/browse/LOG4J2-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13550684#comment-13550684
]
Ralph Goers commented on LOG4J2-109:
Gary, what are you going to do with this issue?
[
https://issues.apache.org/jira/browse/LOG4J2-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers closed LOG4J2-143.
--
Resolution: Fixed
Assignee: Ralph Goers
MessagePatternConverter now returns "null".
Ralph Goers created LOG4J2-143:
--
Summary: MessagePatternConverter throws a NullPointerException if
the log message is null
Key: LOG4J2-143
URL: https://issues.apache.org/jira/browse/LOG4J2-143
Project: L
On Jan 10, 2013, at 4:23 PM, Gary Gregory wrote:
>
> It all depends on what "..." contains doesn't it? If it's a simple
> one-liner-single-method-call-with-no-args, the "final" may seem overkill, but
> it is more complex it is not IMO. This is all about communicating intent. I
> prefer to use
Really? Final variables don't provide any compiler optimization in a loop?
Anyway, I'd have changed it to...
for (final Provider provider : ProviderUtil.getProviders()) {
//do some stuff...
}
Not all method blocks are only 3 lines long, and it's not always just one or
two people working
On Thu, Jan 10, 2013 at 6:53 PM, Ralph Goers wrote:
> I agree, with the exception of local variables. If you look at the last
> commits he made they were primarily to mark variables defined within a
> method as final. From a compiler/performance point of view these don't
> provide any real value
I don't think we need final or any local variables unless the language
mandates it. I think it just adds noise.
Paul
On Thu, Jan 10, 2013 at 5:53 PM, Ralph Goers wrote:
> I agree, with the exception of local variables. If you look at the last
> commits he made they were primarily to mark varia
I agree, with the exception of local variables. If you look at the last
commits he made they were primarily to mark variables defined within a method
as final. From a compiler/performance point of view these don't provide any
real value. For example, one of the changes Gary made was similar t
+1
I couldn't agree with Gary more. The "final" keyword is an essential element
to bug free programs for all the reasons he provides.
Jake
On Thu, 10 Jan 2013 16:59:08 -0500
Gary Gregory wrote:
Hi,
On Thu, Jan 10, 2013 at 4:39 PM, Ralph Goers
wrote:
I guess I should have replied.
M
Hi,
On Thu, Jan 10, 2013 at 4:39 PM, Ralph Goers wrote:
> I guess I should have replied.
>
> My attitude is "I don't care but don't expect me to always do it".
>
Sure, to each his own :)
> Mainly, this is because I have no idea what, if any, benefit there is to
> declaring a variable that is
That is a good question. Most of the converters simply don't add anything to
the buffer if they have no content, but "null" isn't necessarily the same
thing as no content.
Ralph
On Jan 10, 2013, at 12:33 PM, Gary Gregory wrote:
> What should be the expected output? "null" or a no-op?
>
> Ga
I'll give it a try. I am planning on upgrading to Flume 1.3.1 and making it so
the Appender won't fail to start if it can't establish a connection. I may also
convert it to use Flume's built in support for multiple agents.
Ralph
On Jan 10, 2013, at 12:28 PM, Gary Gregory wrote:
> Since we ju
What should be the expected output? "null" or a no-op?
Gary
On Thu, Jan 10, 2013 at 6:42 AM, Christian Grobmeier wrote:
> Folks,
>
> i am doing this:
>
> logger.debug(line)
>
> where line is null. Please not, if I do sysout(line) before the error
> does not happen.
>
> The exception is below. I
Since we just talked about compiling with Java 7...
I see test failures on Java 7 on Win 7:
---
T E S T S
---
Running org.apache.logging.log4j.flume.appender.FlumeAppenderTest
Tests run: 6, Fa
[
https://issues.apache.org/jira/browse/LOG4J2-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13549943#comment-13549943
]
Ralph Goers commented on LOG4J2-96:
---
I suspect this issue might be related to LOG4J2-142
[
https://issues.apache.org/jira/browse/LOG4J2-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers resolved LOG4J2-142.
Resolution: Fixed
Fix Version/s: 2.0-beta4
Assignee: Ralph Goers
I was able to dupl
Crud
Gary
On Jan 10, 2013, at 12:33, Ralph Goers wrote:
> I believe you made this first change before and it had to be reverted as it
> fails when compiling with Java 7.
>
> Ralph
>
>
> On Jan 10, 2013, at 7:34 AM, ggreg...@apache.org wrote:
>
>> Author: ggregory
>> Date: Thu Jan 10 15:34:
I took care of this. I put a comment in to remind you the next time you want
to "fix" this ;-)
Ralph
On Jan 10, 2013, at 9:32 AM, Ralph Goers wrote:
> I believe you made this first change before and it had to be reverted as it
> fails when compiling with Java 7.
>
> Ralph
>
>
> On Jan 10,
I believe you made this first change before and it had to be reverted as it
fails when compiling with Java 7.
Ralph
On Jan 10, 2013, at 7:34 AM, ggreg...@apache.org wrote:
> Author: ggregory
> Date: Thu Jan 10 15:34:39 2013
> New Revision: 1431434
>
> URL: http://svn.apache.org/viewvc?rev=143
LOG4J2-18 and LOG4J2-42 have been sitting for quite some time waiting for
someone like yourself to come along and help come up with good approaches.
I think most of the tools are there but I'm not sure what the best way(s)
is/are to finish it off.
First, hopefully you are aware that the default
All,
We'd like to replace Tomcat's built-in logging with Log4J2, and are able
to do so based on Tomcat's docs for using Log4J 1.x, and deploying the
log4j-1.2-api-2.0-beta4.jar shim.
However, we're running into an issue with external configuration...
Our webapps are always deployed with exte
Folks,
i am doing this:
logger.debug(line)
where line is null. Please not, if I do sysout(line) before the error
does not happen.
The exception is below. I believe it is because:
toAppendTo.append(config != null && result.contains("${") ?
config.getSubst().replace(event, result
37 matches
Mail list logo
