Hi Jeffery,

I rechecked this and I think, this is a test configuration issue and 
resolvable.

The point is we have at least two configurations for the connection url.
1) pom.xml: in profile <database> property torque.database.url is set, 
which is used in sql-maven and antrun plugins. This is, where you made the 
changes..
2) pom.xml: surefire plugin sets property torque.configuration.file to 
src/test/profile/${torque.test.profileDirectory}/Torque.properties. 
In mysql/Torque.properties the jdbc url is set for the JUnit tests with:
torque.dsfactory.bookstore.connection.url = 
jdbc:mysql://localhost:3306/bookstore?serverTimezone=Europe/Berlin&useSSL=false&allowPublicKeyRetrieval=true
Exact Details: This is used in the host based (non docker) test 
environment here: 
org.apache.torque.junit5.extension.HostCallbackExtension.setUp(ExtensionContext).
 
There this configuration is checked before evaluating the default (which 
is the same by the way: "src/test/profile/%s/Torque.properties").
If you change this and set the serverTimezone appropriately, e.g. to 
serverTimezone=America/New_York the test is passing (your failing test) !

Your first test fails, as the JUnit test sets the time field (using 
HostCallbackExtensions jdbc connection with serverTimezone=Europe/Berlin) 
and retrieves it from the database, which has timezone default to system, 
which is America/New_York. Actually setting the serverTimezone in the 
mysql pom profile does not affect anything, as all the initialization SQL 
is hard coded, and the serverTimezone is set there only to avoid a warning 
from the mysql jdbc driver (I think the warning is "The server timezone 
value XXX is unrecognized or represents more than one timezone). Voila!

Testing a different timezone than Europe/Berlin requires to set first of 
all setting the jdbc url in src/test/profile/%s/Torque.properties (or any 
other configured file). We should point out this somewhere in the 
developer's readme and explain this behaviour!

As a result, this is a test configuration issue.

What do you think? Is this stopping the release? 

Of course, we should update the README.md in torque-test, as the test 
expects, that the timezone in mysql is set implicitely (if it is system) 
or explicitely to Europe/Berlin, and this might be of course not the case 
... This is a IMO a non-functional requirement for running the tests, and 
we could only explain or declare it as such.

Best regards, Georg 




Von:    "Georg Kallidis" <[email protected]>
An:     "Apache Torque Developers List" <[email protected]>
Datum:  24.08.2020 12:42
Betreff:        Re: Re: [VOTE] RC Torque 5.0 based on staged repository



Hi Jeffery,

thanks for testing this! 

The use case we want to test is IMO just the system time zone, i.e. mysql 
uses the local system settings. 

1) I would expect, if system timezone is America/NY, then, if using this 
same timezone in the application jdbc driver, setting or getting the time 
(date) should work and retrieve the same time. As it fails the question is 

why.. If I have to explain the result (of the failure), I would say, the 
time was set in another time zone, e.g UTC and we retrieve the time 
converting it to America/US timezone, that is a different time zone, but 
how could that happen, if the system timezone is the same? As the second 
test setting with Europe/Berlin does not fail, it may be, that some hard 
coded time zone setting is somewhere in the code (?). We have to check ... 

could you check in mysql, if this results in "system":  SELECT 
@@global.time_zone, @@session.time_zone;

2) The  same tests (DefaultValuesFromDatabaseContainerTest)pass here, if I 

use the docker test environment, having changed the system time zone or 
setting e.g. ENV TZ America/New_York in DockerFile. If you have a running 
docker environment , you may want to check this with 

mvn clean test -Pdocker-testcontainer,mysql,managers,beans

(You may have to stop mysql server, as the docker mysql by default does 
use the same port 3306 As in DockerCallbackMySQLExtension in the jdbc call 

the serverTimezone is set to ZoneId.systemDefault())

This might by the last resort, and probably is not the reason: Mysql 
driver version has in an upcoming release some bug fixes regarding date 
time conversions: 
https://dev.mysql.com/doc/relnotes/connector-j/8.0/en/news-8-0-20.html (we 

use 8.0.18). What happens, if you you update the driver to the newest 
version - 8.0.22 in torque-test/pom.xml, 
<torque.test.mysql.version>8.0.21</torque.test.mysql.version> ?

I'll keep you updated, when more reliable results appear ;-)

Best regards,  Georg

P.S: By default named time zones are not settable on mysql server (at 
least in windows, in unix you have to trigger the setting), see 
https://dev.mysql.com/doc/refman/8.0/en/time-zone-support.html.



Von:    Jeffery Painter <[email protected]>
An:     [email protected]
Datum:  23.08.2020 23:17
Betreff:        Re: [VOTE] RC Torque 5.0 based on staged repository



Hi Georg,

I checked out the source from tag and was able to build and compile with 
no issues on my Linux machine (Ubuntu 20.04 fresh install):

Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /usr/java/maven
Java version: 1.8.0_261, vendor: Oracle Corporation, runtime: 
/usr/java/jdk1.8.0_261/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.4.0-42-generic", arch: "amd64", family: 
"unix"

I then went to torque-test/

I was able to run:

mvn clean test -Phsqldb,managers,beans

This completed with all tests passing.


MySQL Issues:

First test updating my pom.xml to use my local timezone:

-------------------------------------------------------------

I updated the torque-test/pom.xml to use my timezone "America/New_York"

painter@merlin:~/apache/torque-5.0/torque-test$ grep New_York pom.xml
<torque.database.url>jdbc:mysql://localhost:3306/bookstore?serverTimezone=America/New_York&amp;useSSL=false&amp;allowPublicKeyRetrieval=true</torque.database.url>

root@merlin:~# timedatectl
                Local time: Sun 2020-08-23 17:11:19 EDT
            Universal time: Sun 2020-08-23 21:11:19 UTC
                  RTC time: Sun 2020-08-23 21:11:19
                 Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes
               NTP service: active
           RTC in local TZ: no


MySQL Server version: 8.0.21-0ubuntu0.20.04.4 (Ubuntu)
mvn clean test -Pmysql,managers,beans

[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] DefaultValuesFromDatabaseTest.testNewObjectChangedValue:214 
expected: <1970-01-01 11:21:31> but was: <1970-01-01 05:21:31>
[INFO]
[ERROR] Tests run: 287, Failures: 1, Errors: 0, Skipped: 0
[INFO]

-------------------------------------------------------------

Second, I try to reset my local timezone to Europe/Berlin

painter@merlin:~/apache/torque-5.0/torque-test$ grep Berlin pom.xml
<torque.database.url>jdbc:mysql://localhost:3306/bookstore?serverTimezone=Europe/Berlin&amp;useSSL=false&amp;allowPublicKeyRetrieval=true</torque.database.url>


painter@merlin:~/apache/torque-5.0/torque-test$ timedatectl
                Local time: Sun 2020-08-23 23:15:06 CEST
            Universal time: Sun 2020-08-23 21:15:06 UTC
                  RTC time: Sun 2020-08-23 21:15:07
                 Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
               NTP service: active
           RTC in local TZ: no


mvn clean test -Pmysql,managers,beans

[INFO] Results:
[INFO]
[INFO] Tests run: 287, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] 
------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] 
------------------------------------------------------------------------
[INFO] Total time:  02:27 min
[INFO] Finished at: 2020-08-23T23:15:33+02:00
[INFO] 
------------------------------------------------------------------------


So unfortunately, I would still say there is a bug in this test case, 
but it is very close! I do not know how to resolve this or I would :-)

[ ] +1 release it
[ ] +0 go ahead I don't care
[x] -1 no, do not release it because


--

Jeffery Painter










On 8/14/20 8:17 AM, Georg Kallidis wrote:
> Hi Torque community,
>
>
> another release candidate for Torque version 5.0 has been prepared and 
is
> again open for voting!
>
>
> Artifacts:
>
> 
https://repository.apache.org/content/repositories/orgapachetorque-1002/org/apache/torque/


>
>
> Tag:
>
> https://svn.apache.org/repos/asf/db/torque/torque4/tags/torque-5.0
>
>
> This release contains the following updates:
>
> - fixes from last vote relplies, updated resources, improved build
> workflow.
>
> - 81 resolved JIRA issues:
> 
https://issues.apache.org/jira/browse/TORQUE-359?jql=project%20%3D%20TORQUE%20AND%20status%20%3D%20Resolved%20AND%20fixVersion%20%3D%204.1


>
>
>   (note, this is still "fix version 4.1", but should be updated to 5.0)
> - a lot of bugfixes, cleanup and refactoring, e.g.
> time/date/timestamp-string formatting, deprecated DBCP1 adapters, DBCP2 
is
>
> the default now...
> - Java 8, tested and build in Java 8 and 14 with JUnit 5 and Log4j2
> - updated almost all plugin, build and database dependencies, major
> updates: velocity 2.0, groovy 3.0.4
> - added Docker testcontainer profiles for mysql and postgresql
> - new refactored ant task Torque4JDBCTransformTask
>
> Keys:
> https://svn.apache.org/repos/asf/db/torque/torque4/trunk/KEYS
> https://dist.apache.org/repos/dist/release/db/torque/KEYS (after release
> to be updated)
>
>
> Please verify this release candidate carefully, give feedback or/and 
vote
>
>
> [ ] +1 release it
> [ ] +0 go ahead I don't care
> [ ] -1 no, do not release it because
>
>
> Have fun!
>
>
> Best regards, Georg
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]





Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to