Metrics ReST Tests and SimpleDateFormat


#1

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?


#2

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


#3

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]


#4

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


#5

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).