I noticed the following errors while testing: camunda-bpm-platform/engine-rest
see: MetricsRestServiceInteractionTest
Several errors (example):
Failed tests:
MetricsRestServiceInteractionTest.testGetIntervalWithStartDate:178
Argument(s) are different! Wanted:
metricsQuery.startDate(
Wed Dec 31 18:00:00 CST 1969
);
-> at org.camunda.bpm.engine.rest.MetricsRestServiceInteractionTest.testGetIntervalWithStartDate(MetricsRestServiceInteractionTest.java:178)
Actual invocation has different arguments:
metricsQuery.startDate(
Wed Dec 31 06:00:00 CST 1969
);
Is there a timezone issue in the test?
Looks like the actual error is an ‘INVALID-TIME-STAMP’ value being received rather a string representing a date value.
Maybe the test isn’t copacetic with the date format? Not sure
camunda BPM - engine - REST: Still failing -
Here are the details:
My target profile:
engine-integration,wildfly,wildfly10,h2
My host/workstation: mvn -version
[teamw@centosw02esx camunda-bpm-platform]$ mvn -version
Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T11:29:23-06:00)
Maven home: /opt/maven
Java version: 1.8.0_121, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-0.b13.el7_3.x86_64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: “linux”, version: “3.10.0-514.6.1.el7.x86_64”, arch: “amd64”, family: “unix”
Haven’t been able to run a complete test for a few days due to some failures in ReST tests. The “enforcer” is also squawking about java version (I use 1.8) - hence, here’s my current working mvn command:
NOTE: Tests turned off here - reason: can’t get past engine REST
mvn clean install -Dmaven.test.skip=true -Pengine-integration,wildfly,wildfly10,h2
If I do allow tests - I see this failure:
[INFO] camunda BPM - engine - REST … FAILURE [ 45.333 s]
Hi Gary,
I can reproduce the issue when I set CST or UTC as timezone, but not with CET. As a quick fix you could add -Duser.timezone=CET to the maven command line which should get you past this. I’ll investigate this further tomorrow.
Cheers,
Thorben
I noticed the actual error within the engine was that it couldn’t parse the date/time value “UNPARSIBLE DATE”. In-other-words, jayway ReST tester was submitting something that lead to the date-stamp turning into a value of “unparsible”. And, since the input no longer had a date-stamp, this lead to the failure. This then caused the earlier date… somehow.
It’s been a few days since looking at the error.
I was thinking about setting up a proxy between the Jayway test and Camunda to verify date values.
The test was actually good, though failing, in that it identified a bad fall-back recovery - this being my initial… analysis (meaning I need to take another look at it).