[
https://issues.apache.org/jira/browse/LOG4J2-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-985:
---
Description:
For the same reasons as LOG4J2-891 was raised, {{equals()}} and {{hashCode()}}
should be
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
[
https://issues.apache.org/jira/browse/LOG4J2-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma reassigned LOG4J2-985:
--
Assignee: Remko Popma
> AbstractFilter should not implement equals() and hashCode()
> -
[
https://issues.apache.org/jira/browse/LOG4J2-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma resolved LOG4J2-985.
Resolution: Fixed
Fixed in master in commit 13d1d78.
> AbstractFilter should not implement equals()
[
https://issues.apache.org/jira/browse/LOG4J2-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma closed LOG4J2-985.
--
> AbstractFilter should not implement equals() and hashCode()
>
I am seeing this test for log4j-jul fail:
java.lang.UnsupportedOperationException: Cannot set level through log4j-api
at
org.apache.logging.log4j.jul.ApiLogger.setLevel(ApiLogger.java:82)
at
org.apache.logging.log4j.jul.CoreLoggerTest.testSetLevel(CoreLoggerTest.java:67)
Did we do
The Buildbot has detected a new failure on builder log4j2-nightly while
building ASF Buildbot. Full details are available at:
http://ci.apache.org/builders/log4j2-nightly/builds/279
Buildbot URL: http://ci.apache.org/
Buildslave for this Build: lares_ubuntu
Build Reason: The Nightly schedul
[
https://issues.apache.org/jira/browse/LOG4J2-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14396247#comment-14396247
]
chidveer commented on LOG4J2-411:
-
Can you rename the xsd to Log4j2-config.xsd in the log4
[
https://issues.apache.org/jira/browse/LOG4J2-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14396255#comment-14396255
]
Robin Pradel commented on LOG4J2-411:
-
Sehr geehrte Damen und Herren,
ich bin bis ein
I think it has something to do with the fact that you cannot uninstall our JUL
layer or other layer so the wrong code is installed at some point in the whole
test suite. I am guessing it runs fine on its own.
Gary
Original message
From: Remko Popma
Date: 04/05/2015 00:42 (
Oops. I just saw this thread. I am getting the same error and won’t be able to
perform a release until this is fixed. Anyone no what commit broke it?
Ralph
> On Apr 5, 2015, at 8:27 AM, Gary Gregory wrote:
>
> I think it has something to do with the fact that you cannot uninstall our
> JUL la
Hm, I think I might have done that, sorry. I wonder how long we want to
keep Java 6 as the base platform...
Gary
-- Forwarded message --
From:
Date: Sun, Apr 5, 2015 at 12:00 AM
Subject: logging-log4j2 git commit: LOG4J2-980 Replaced Long.compare(long,
0) with Long.signum(long) in
I wonder if this has to do with tests being forked vs. not. When _not_
forked, then this would happen I am guessing. I am also guessing that
something has changed in JUnit or Surefire. Perhaps all this needs is
setting fork to true for tests that create the issue in the 1st place?
Gary
On Sun, Ap
I’ve changed forkCount and reuseForks and it isn’t making a difference.
Interestingly, when I run with -X the tests pass with forkCount=1 and
reuseForks= false.
Ralph
> On Apr 5, 2015, at 2:07 PM, Gary Gregory wrote:
>
> I wonder if this has to do with tests being forked vs. not. When _not_
If you look at the release notes for the last release I added “Future releases
may require a minimum of Java 7”.
Ralph
> On Apr 5, 2015, at 2:01 PM, Gary Gregory wrote:
>
> Hm, I think I might have done that, sorry. I wonder how long we want to keep
> Java 6 as the base platform...
>
> Gary
Arg, I cannot ever run org.apache.logging.log4j.jul tests from Eclipse
without getting errors. It looks like tests cannot find the List appender,
weird, and unrelated I am sure.
Gary
On Sun, Apr 5, 2015 at 2:32 PM, Ralph Goers
wrote:
> I’ve changed forkCount and reuseForks and it isn’t making a
In this case signum() is actually the correct method to use: it was designed
for this purpose, and (for the performance freaks) the JDK provides a
branch-free implementation so the CPU pipeline is never stalled because of a
branch misprediction here.
Sent from my iPhone
> On 2015/04/06, at 6:
It's gotta be some side effect because this passes: mvn test
-Dtest=org.apache.logging.log4j.jul.CoreLoggerTest
Gary
On Sun, Apr 5, 2015 at 3:32 PM, Gary Gregory wrote:
> Arg, I cannot ever run org.apache.logging.log4j.jul tests from Eclipse
> without getting errors. It looks like tests cannot
and this fails (from the JUL folder):
mvn test
-Dtest=org.apache.logging.log4j.jul.ApiLoggerTest,org.apache.logging.log4j.jul.CoreLoggerTest
G
On Sun, Apr 5, 2015 at 3:37 PM, Gary Gregory wrote:
> It's gotta be some side effect because this passes: mvn test
> -Dtest=org.apache.logging.log4j.ju
In Eclipse, before building jars, the binary data file with plugin-to-class
mappings may not have been created yet. You could try putting the package
containing the list appender in the On 2015/04/06, at 7:32, Gary Gregory wrote:
>
> Arg, I cannot ever run org.apache.logging.log4j.jul tests fr
I did a diff of log4j-jul in 2.2 against master and they are virtually the
same. I didn’t see this error when I built 2.2. I am rerunning it again now
just to be doubly sure.
Ralph
> On Apr 5, 2015, at 3:44 PM, Remko Popma wrote:
>
> In Eclipse, before building jars, the binary data file wi
Roger that!
G
On Sun, Apr 5, 2015 at 2:34 PM, Ralph Goers
wrote:
> If you look at the release notes for the last release I added “Future
> releases may require a minimum of Java 7”.
>
> Ralph
>
>
> On Apr 5, 2015, at 2:01 PM, Gary Gregory wrote:
>
> Hm, I think I might have done that, sorry. I
Is there a way to de-register Log4J from JUL to undo what happens in
org.apache.logging.log4j.jul.LogManager.LogManager()?
Gary
On Sun, Apr 5, 2015 at 3:48 PM, Ralph Goers
wrote:
> I did a diff of log4j-jul in 2.2 against master and they are virtually the
> same. I didn’t see this error when I
In the parent POM, if I set reuseForks to false, then the JUL module tests
pass. So maybe we need to override the Surefire settings just for the JUL
module...
Gary
On Sun, Apr 5, 2015 at 4:13 PM, Gary Gregory wrote:
> Is there a way to de-register Log4J from JUL to undo what happens in
> org.ap
I was configuring the surefire plugin incorrectly. Once I did it right the
tests pass. I will commit the fix shortly.
Ralph
> On Apr 5, 2015, at 4:35 PM, Gary Gregory wrote:
>
> In the parent POM, if I set reuseForks to false, then the JUL module tests
> pass. So maybe we need to override th
25 matches
Mail list logo
