Hi Jeffery, hi Torque devs, thanks!

I now count three binding +1 votes and the release could be done. I will of 
course announce the result appropriately as soon as possible.

As soon as I am available I will proceed, but expect it to be mid/end of 
September. Feel free to update Torque site, we might use then the trunk..

Best regards, Georg


On August 28, 2020 4:56:29 PM GMT+02:00, Jeffery Painter <[email protected]> 
wrote:
>Hi Georg,
>
>I read through your notes below and followed your advice.
>
>If we update the readme to reflect the following:
>
>======================================================
>Running test-profile for mysql in your local time zone
>======================================================
>
>First, the JDBC connection is stored in two places which
>should be updated to match your local timezone.
>
>
>1. torque-test/pom.xml
>2. torque-test/src/test/profile/mysql/Torque.properties
>
>
>After changing the timezone settings in both of the jdbc connection
>URLs,
>I ran:
>
>$ mvn clean test -Pmysql,manager,beans
>
>
>[INFO] Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>0.374 s - in org.apache.torque.map.DatabaseMapTest
>[INFO]
>[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-28T10:52:44-04:00
>[INFO]
>------------------------------------------------------------------------
>
>
>I see no reason to stop the release and change my vote to +1
>
>Glad you figured it out!  :-)
>
>-
>Jeffery
>
>
>
>> 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]
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [email protected]
>For additional commands, e-mail: [email protected]

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Reply via email to