java.lang.AssertionError

QOS.ch JIRA | Joern Huxhorn | 6 months ago
  1. 0

    Trying to perform a {{mvn clean install}} on revision {{03e26684d43066d53dbf926e060a73d43bee77fd}} causes the following tests to fail: {noformat} Failed tests: TimeBasedRollingWithArchiveRemoval_Test.checkThatSmallTotalSizeCapLeavesAtLeastOneArhcive:191->checkFileCount:484 expected:<1> but was:<0> RollingCalendarTest.testCollisionFreenes:148->checkCollisionFreeness:158 RollingCalendarTest.testPeriodicity:63 expected:<TOP_OF_WEEK> but was:<TOP_OF_MONTH> Tests run: 532, Failures: 3, Errors: 0, Skipped: 7 {noformat} The {{System.out.println}} in {{computePeriodicityType}} of {{RollingCalendar}} is printing the following things: *RollingCalendarTest.testPeriodicity* {noformat} Type = TOP_OF_WEEK, r0 = 1970-01, r1 = 1970-01 Type = TOP_OF_MONTH, r0 = 1970-01, r1 = 1970-05 java.lang.AssertionError: Expected :TOP_OF_WEEK Actual :TOP_OF_MONTH {noformat} The failing code looks like this: {noformat} { RollingCalendar rc = new RollingCalendar("yyyy-ww"); assertEquals(PeriodicityType.TOP_OF_WEEK, rc.getPeriodicityType()); } {noformat} *RollingCalendarTest.testCollisionFreenes* {noformat} java.lang.AssertionError at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertFalse(Assert.java:68) at org.junit.Assert.assertFalse(Assert.java:79) at ch.qos.logback.core.rolling.helper.RollingCalendarTest.checkCollisionFreeness(RollingCalendarTest.java:158) at ch.qos.logback.core.rolling.helper.RollingCalendarTest.testCollisionFreenes(RollingCalendarTest.java:148) {noformat} The line in question is this: {noformat} checkCollisionFreeness("yyyy-WW", false); {noformat} *TimeBasedRollingWithArchiveRemoval_Test.checkThatSmallTotalSizeCapLeavesAtLeastOneArhcive* {noformat} Type = TOP_OF_MILLISECOND, r0 = 1970-01-01, r1 = 1970-01-01 Type = TOP_OF_SECOND, r0 = 1970-01-01, r1 = 1970-01-01 Type = TOP_OF_MINUTE, r0 = 1970-01-01, r1 = 1970-01-01 Type = TOP_OF_HOUR, r0 = 1970-01-01, r1 = 1970-01-01 Type = TOP_OF_DAY, r0 = 1970-01-01, r1 = 1970-01-02 cp.periodDurationInMillis=86400000, tickDuration=:400000, runLength=648 Sat Mar 26 13:13:45 CET 2016 13:18:47,353 |-INFO in c.q.l.core.rolling.TimeBasedRollingPolicy@1159114532 - No compression will be used 13:18:47,353 |-INFO in c.q.l.core.rolling.TimeBasedRollingPolicy@1159114532 - Will use the pattern target/test-output/1647000378/clean-%d{yyyy-MM-dd}.txt for the active file 13:18:47,353 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - The date pattern is 'yyyy-MM-dd' from file name pattern 'target/test-output/1647000378/clean-%d{yyyy-MM-dd}.txt'. 13:18:47,353 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Roll-over at midnight. 13:18:47,354 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Setting initial period to Wed Mar 23 13:07:05 CET 2016 13:18:47,354 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[null] - Active log file name: target/test-output/1647000378/clean-2016-03-23.txt 13:18:47,354 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[null] - File property is set to [null] 13:18:47,354 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Elapsed period: Wed Mar 23 13:07:05 CET 2016 13:18:47,355 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - first clean up after appender initialization 13:18:47,355 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Multiple periods, i.e. 31 periods, seem to have elapsed. This is expected at application start. 13:18:47,356 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Deleting [target/test-output/1647000378/clean-2016-03-24.txt] of size 76 Bytes 13:18:47,356 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Deleting [target/test-output/1647000378/clean-2016-03-23.txt] of size 7 KB 13:18:47,356 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Removed 7 KB of files 13:18:47,358 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Elapsed period: Thu Mar 24 00:00:25 CET 2016 13:18:47,359 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Removed 0 Bytes of files 13:18:47,361 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Elapsed period: Fri Mar 25 00:00:25 CET 2016 13:18:47,362 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Deleting [target/test-output/1647000378/clean-2016-03-26.txt] of size 75 Bytes 13:18:47,362 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Deleting [target/test-output/1647000378/clean-2016-03-25.txt] of size 15 KB 13:18:47,362 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Removed 15 KB of files java.lang.AssertionError: Expected :1 Actual :0 at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at ch.qos.logback.core.rolling.TimeBasedRollingWithArchiveRemoval_Test.checkFileCount(TimeBasedRollingWithArchiveRemoval_Test.java:484) at ch.qos.logback.core.rolling.TimeBasedRollingWithArchiveRemoval_Test.checkThatSmallTotalSizeCapLeavesAtLeastOneArhcive(TimeBasedRollingWithArchiveRemoval_Test.java:191) {noformat} *Stuff I already tried:* - changed {{TimeZone}} in {{RollingCalendar}} from {{GMT}} to {{UTC}} - changed {{Locale}} of {{GregorianCalendar}} in {{computePeriodicityType}} from {{Locale.getDefault()}} to {{Locale.ENGLISH}} and {{Locale.US}}. No change in behavior. Given that [Logback Travis CI|https://travis-ci.org/qos-ch/logback] is building fine with Java {{1.7.0_80}} but I'm using Java {{1.8.0_92}}, I strongly suspect that the failures are actually caused by an incompatibility introduced in Java 8. I can't personally check against Java 7 anymore because Oracle. You could try this out by adding the following to your {{.travis.yml}} file: {noformat} jdk: - oraclejdk8 - oraclejdk7 - openjdk7 - openjdk6 {noformat} (The above worked about a year ago. It's possible that something changed at Travis in the meantime.) Hope this helps.

    QOS.ch JIRA | 6 months ago | Joern Huxhorn
    java.lang.AssertionError
  2. 0

    Trying to perform a {{mvn clean install}} on revision {{03e26684d43066d53dbf926e060a73d43bee77fd}} causes the following tests to fail: {noformat} Failed tests: TimeBasedRollingWithArchiveRemoval_Test.checkThatSmallTotalSizeCapLeavesAtLeastOneArhcive:191->checkFileCount:484 expected:<1> but was:<0> RollingCalendarTest.testCollisionFreenes:148->checkCollisionFreeness:158 RollingCalendarTest.testPeriodicity:63 expected:<TOP_OF_WEEK> but was:<TOP_OF_MONTH> Tests run: 532, Failures: 3, Errors: 0, Skipped: 7 {noformat} The {{System.out.println}} in {{computePeriodicityType}} of {{RollingCalendar}} is printing the following things: *RollingCalendarTest.testPeriodicity* {noformat} Type = TOP_OF_WEEK, r0 = 1970-01, r1 = 1970-01 Type = TOP_OF_MONTH, r0 = 1970-01, r1 = 1970-05 java.lang.AssertionError: Expected :TOP_OF_WEEK Actual :TOP_OF_MONTH {noformat} The failing code looks like this: {noformat} { RollingCalendar rc = new RollingCalendar("yyyy-ww"); assertEquals(PeriodicityType.TOP_OF_WEEK, rc.getPeriodicityType()); } {noformat} *RollingCalendarTest.testCollisionFreenes* {noformat} java.lang.AssertionError at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertFalse(Assert.java:68) at org.junit.Assert.assertFalse(Assert.java:79) at ch.qos.logback.core.rolling.helper.RollingCalendarTest.checkCollisionFreeness(RollingCalendarTest.java:158) at ch.qos.logback.core.rolling.helper.RollingCalendarTest.testCollisionFreenes(RollingCalendarTest.java:148) {noformat} The line in question is this: {noformat} checkCollisionFreeness("yyyy-WW", false); {noformat} *TimeBasedRollingWithArchiveRemoval_Test.checkThatSmallTotalSizeCapLeavesAtLeastOneArhcive* {noformat} Type = TOP_OF_MILLISECOND, r0 = 1970-01-01, r1 = 1970-01-01 Type = TOP_OF_SECOND, r0 = 1970-01-01, r1 = 1970-01-01 Type = TOP_OF_MINUTE, r0 = 1970-01-01, r1 = 1970-01-01 Type = TOP_OF_HOUR, r0 = 1970-01-01, r1 = 1970-01-01 Type = TOP_OF_DAY, r0 = 1970-01-01, r1 = 1970-01-02 cp.periodDurationInMillis=86400000, tickDuration=:400000, runLength=648 Sat Mar 26 13:13:45 CET 2016 13:18:47,353 |-INFO in c.q.l.core.rolling.TimeBasedRollingPolicy@1159114532 - No compression will be used 13:18:47,353 |-INFO in c.q.l.core.rolling.TimeBasedRollingPolicy@1159114532 - Will use the pattern target/test-output/1647000378/clean-%d{yyyy-MM-dd}.txt for the active file 13:18:47,353 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - The date pattern is 'yyyy-MM-dd' from file name pattern 'target/test-output/1647000378/clean-%d{yyyy-MM-dd}.txt'. 13:18:47,353 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Roll-over at midnight. 13:18:47,354 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Setting initial period to Wed Mar 23 13:07:05 CET 2016 13:18:47,354 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[null] - Active log file name: target/test-output/1647000378/clean-2016-03-23.txt 13:18:47,354 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[null] - File property is set to [null] 13:18:47,354 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Elapsed period: Wed Mar 23 13:07:05 CET 2016 13:18:47,355 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - first clean up after appender initialization 13:18:47,355 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Multiple periods, i.e. 31 periods, seem to have elapsed. This is expected at application start. 13:18:47,356 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Deleting [target/test-output/1647000378/clean-2016-03-24.txt] of size 76 Bytes 13:18:47,356 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Deleting [target/test-output/1647000378/clean-2016-03-23.txt] of size 7 KB 13:18:47,356 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Removed 7 KB of files 13:18:47,358 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Elapsed period: Thu Mar 24 00:00:25 CET 2016 13:18:47,359 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Removed 0 Bytes of files 13:18:47,361 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Elapsed period: Fri Mar 25 00:00:25 CET 2016 13:18:47,362 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Deleting [target/test-output/1647000378/clean-2016-03-26.txt] of size 75 Bytes 13:18:47,362 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Deleting [target/test-output/1647000378/clean-2016-03-25.txt] of size 15 KB 13:18:47,362 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Removed 15 KB of files java.lang.AssertionError: Expected :1 Actual :0 at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at ch.qos.logback.core.rolling.TimeBasedRollingWithArchiveRemoval_Test.checkFileCount(TimeBasedRollingWithArchiveRemoval_Test.java:484) at ch.qos.logback.core.rolling.TimeBasedRollingWithArchiveRemoval_Test.checkThatSmallTotalSizeCapLeavesAtLeastOneArhcive(TimeBasedRollingWithArchiveRemoval_Test.java:191) {noformat} *Stuff I already tried:* - changed {{TimeZone}} in {{RollingCalendar}} from {{GMT}} to {{UTC}} - changed {{Locale}} of {{GregorianCalendar}} in {{computePeriodicityType}} from {{Locale.getDefault()}} to {{Locale.ENGLISH}} and {{Locale.US}}. No change in behavior. Given that [Logback Travis CI|https://travis-ci.org/qos-ch/logback] is building fine with Java {{1.7.0_80}} but I'm using Java {{1.8.0_92}}, I strongly suspect that the failures are actually caused by an incompatibility introduced in Java 8. I can't personally check against Java 7 anymore because Oracle. You could try this out by adding the following to your {{.travis.yml}} file: {noformat} jdk: - oraclejdk8 - oraclejdk7 - openjdk7 - openjdk6 {noformat} (The above worked about a year ago. It's possible that something changed at Travis in the meantime.) Hope this helps.

    QOS.ch JIRA | 6 months ago | Joern Huxhorn
    java.lang.AssertionError
  3. 0

    SocketSuspendTest fails on Linux/jdk7

    GitHub | 4 years ago | ryanobjc
    java.lang.AssertionError
  4. Speed up your debug routine!

    Automated exception search integrated into your IDE

  5. 0

    GitHub comment 780#2986135

    GitHub | 5 years ago | bstansberry
    java.lang.AssertionError
  6. 0

    GitHub comment 3567#163210204

    GitHub | 12 months ago | akarnokd
    java.lang.AssertionError

  1. andyglick 4 times, last 9 months ago
1 unregistered visitors
Not finding the right solution?
Take a tour to get the most out of Samebug.

Tired of useless tips?

Automated exception search integrated into your IDE

Root Cause Analysis

  1. java.lang.AssertionError

    No message provided

    at org.junit.Assert.fail()
  2. JUnit
    Assert.assertFalse
    1. org.junit.Assert.fail(Assert.java:92)
    2. org.junit.Assert.assertTrue(Assert.java:43)
    3. org.junit.Assert.assertFalse(Assert.java:68)
    4. org.junit.Assert.assertFalse(Assert.java:79)
    4 frames
  3. Logback Core Module
    RollingCalendarTest.testCollisionFreenes
    1. ch.qos.logback.core.rolling.helper.RollingCalendarTest.checkCollisionFreeness(RollingCalendarTest.java:158)
    2. ch.qos.logback.core.rolling.helper.RollingCalendarTest.testCollisionFreenes(RollingCalendarTest.java:148)
    2 frames