Hey Guys,
I just finished an improvement to the TimeZoneChanger to change the
Sensor Data for all test users. For the most part, every thing seems ok.
I have tested the TimeZoneChanger manually for the Pacific Standard
Time. And I have committed my changes.
However, because I built a bunch of the modules I've never built before,
I've discovered a few problems. People that need to look at this email
are: Philip, Christoph, Takuya, and Hongbing. the best way to find your
respective problems/questions is to do a search for your first
name.
thanks, aaron
-------------------------------------------------------------------------------------
The following is the output from the tomcat window when I changed my
TimeZone to Pacific Standard Time.
04/22 03:55:35
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
04/22 03:55:35 Hackystat: Initializing system.
04/22 03:55:41 Admin: [EMAIL PROTECTED] (kagawaa)
04/22 03:55:41 TimeZoneChanger: Server Time Zone = Pacific Standard
Time
04/22 03:55:41 TimeZoneChanger: Changing TimeStamps in Test Data for
testdataset
04/22 03:55:42 TimeZoneChanger: Changing TimeStamps in Test Data for
testpridataset
04/22 03:55:43 TimeZoneChanger: Changing TimeStamps in Test Data for
testprojectdataset
04/22 03:55:44 TimeZoneChanger: Changing TimeStamps in Test Data for
testuserCgqm
04/22 03:55:49 TimeZoneChangerException: Error processing
c:\java\cvs\hackystatdata\users\testuserCgqm\data\FileMetric\2005-04-03.xml
org.hackystat.kernel.admin.TimeZoneChangerException: The calculated
offset causes a change in day. [day(from file)=03-Apr-2005|
originalTimeStamp=1112524009000, day=03-Apr-2005, date=Sun Apr 03
03:26:49 PDT 2005 | adjustedTimeStamp=1112513209000, day=02-Apr-2005,
date=Sat Apr 02 23:26:49 PST 2005]
04/22 03:55:53 TimeZoneChangerException: Error processing
c:\java\cvs\hackystatdata\users\testuserCgqm\data\Build\2005-04-03.xml
org.hackystat.kernel.admin.TimeZoneChangerException: The calculated
offset causes a change in day. [day(from file)=03-Apr-2005|
originalTimeStamp=1112522967794, day=03-Apr-2005, date=Sun Apr 03
03:09:27 PDT 2005 | adjustedTimeStamp=1112512167794, day=02-Apr-2005,
date=Sat Apr 02 23:09:27 PST 2005]
04/22 03:55:54 Users directory is: c:\java\cvs\hackystatdata\users
04/22 03:55:54 Startup Summary: SDTs: 16, Commands: 99, Sensors: 17,
Users: 15
04/22 03:55:54 Version: 6.5.422 Buildtime: April 22 2005 03:54:31
04/22 03:55:54
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Note that there were two failures in hackyCGQM before and after changing
my local timezone. So, I don't think the TimeZoneChangerExceptions
affected the results of the unit tests. None of the other tests failed.
There are a couple problems with the testuserCgqm data. Actually, the
problems identified here are not problems with Christophs data, instead
it is a problem with the TimeZoneChanger, because the change in day is a
result of the Day Light Savings time change on April 3 2005.
Let me explain further. The TimeZoneChanger figures out if the server is
running in a TimeZone that has daylight savings. Then it calculates the
time to adjust the timestamps. Currently, Los Angeles is not in Daylight
Savings. So, the adjustment from PST to HST is three hours. If we were in
daylight savings then the adjustment would be an hour less. (Of course
this calculation is all automatic for any TimeZone.) However, because
April 2, 2005 is in Daylight savings time, the change of 3 hours for this
specific data results in a change in day.
If you think that is confusing.. The implementation to correct this would
be much more confusing. There are two options: (1) I change the
implementation. I suppose the TimeZoneChanger should re-calculate the
timestamp adjustment for each individual timestamp change. This would
require calculating the adjustment then checking if the resulting day is
in or out of the Daylight Savings, then re-calculate the adjustment due
to knowledge of the daylight savings change. or (2) Christoph
changes the Sensor Data to pad the timestamps an extra hour for the weird
day of April 3, 2005 (change of daylight savings).
Philip: Which do you prefer? Normally, I would say that the
TimeZoneChanger needs to be changed, but I think it is pretty complicated
change for such a rare event. And honestly, I don't really have a lot
time to fix this quickly.
There seems to be only 4 test users. Is this correct? please let me know
if you are using a test user and don't see yours listed below. (Note that
I cannot build hackyTDD or hackyZorro on my local machine).
Hongbing, you might want to change the timezone on your local machine to
test this out for yourself.
-------------------------------------------------------------------------------------
Philip: The following is small part of the TimeZoneChanger that got
improved. This makes me really nervous. If someone changes isTestUser()
on accident to return true for every user, then the TimeZoneChanger could
change every users' data. I guess there is nothing I can do about that
right?
Note: that our public server will never need to change data because we
are in Hawaii Standard Time.
if
(this
.isChangeNeeded()) {
for
(Iterator i =
UserManager.getInstance().iterator(); i.hasNext(); ) {
User user = (User)
i.next();
if
(user.isTestUser()) {
if
(!this
.hasBeenChanged(user)) {
this
.changeTestData(user);
this
.writeHasBeenChangedProperty(user);
}
else
{
ServerProperties.getInstance().getLogger().info(
"TimeZoneChanger:
No change needed "
+ "for test
user [userKey=" +
user.getUserKey() +
",
userEmail="
+ user.getUserEmail() +
"]");
}
}
}
}
-------------------------------------------------------------------------------------
- [Christoph, Critical] The test user from hackyCGQM,
"testuserCgqm" has a user email address of
"[EMAIL PROTECTED]" should be
"[EMAIL PROTECTED]". We should never use a valid
domain such as @hawaii.edu for testing. I fixed this on my local
machine to test the TimeZoneChanger but did _not_ commit it.
-------------------------------------------------------------------------------------
- [Christoph, Major] As of April 21, 11:46 pm, I got these unit test
failures before changing my local timezone and after changing my local
timezone.
[echo] (hackyBuildUtils) Sending JUnit data to
hackystat.
[echo] (hackyBuildUtils) Invoking junit for
hackyCGQM.
[echo] (hackyBuildUtils) Running JUnit tests on
module hackyCGQM.
[junit] Test
cGQM.plugin.buildFailures.TestQNightlyBuildFailuresModuleOverview
FAILED
[junit] Test
cGQM.plugin.overview.TestQLastWeeksModuleEffort FAILED
-------------------------------------------------------------------------------------
- [Christoph, Minor] Your local.build.xml breaks our convention of
putting test data into the install.testdata.users.dir and letting the
build process copy it over to the hackystat data directory. The following
code seems to be the ideal code for doing this.
<!--
***********************************************************************
-->
<target name="installTestDataSets"
description="Copies all of the testdatasets to
the installation directory.">
<echo message="(${ant.project.name}) Deleting
${hackystat.data.dir}\users\testpridataset."/>
<delete
dir="${hackystat.data.dir}\users\testpridataset"/>
<copy
todir="${install.testdata.users.dir}">
<fileset
dir="${src.dir}/org/hackystat/app/pri"
includes="testpridataset/**"/>
</copy>
</target>
-------------------------------------------------------------------------------------
- [Christoph, Minor] Is this output from a "-q quickStart" or
"-q freshStart" necessary?
[echo] Finished jixb binding
[echo] (hackyCGQM-local) Invoking
war.
[java] Apr 21, 2005 11:08:52 PM
org.hackystat.app.cgqm.common.classloaders.JarClassLoader findClass
[java] INFO: Loading class
cGQM.plugin.overview.QTopography from file
C:\java\cvs\hackyCGQM\build\plugins\overview\build\lib\overview-plugin.jar
[java] Apr 21, 2005 11:08:52 PM
org.hackystat.app.cgqm.common.classloaders.JarClassLoader findClass
[java] INFO: Loading class
cGQM.plugin.overview.QModuleActiveTime from file
C:\java\cvs\hackyCGQM\build\plugins\overview\build\lib\overview-plugin.jar
[java] Apr 21, 2005 11:09:01 PM
org.hackystat.app.cgqm.common.classloaders.JarClassLoader findClass
[java] INFO: Loading class
cGQM.plugin.buildFailures.GIncreaseBuildSuccessRate from file
C:\java\cvs\hackyCGQM\build\plugins\buildFailures\build\lib\buildFailures-plugin.jar
[java] Apr 21, 2005 11:09:01 PM
org.hackystat.app.cgqm.common.classloaders.JarClassLoader findClass
[java] INFO: Loading class
cGQM.plugin.buildFailures.QLocalBuildTime from file
C:\java\cvs\hackyCGQM\build\plugins\buildFailures\build\lib\buildFailures-plugin.jar
[java] Apr 21, 2005 11:09:01 PM
org.hackystat.app.cgqm.common.classloaders.JarClassLoader findClass
[java] INFO: Loading class
cGQM.plugin.buildFailures.QNightlyBuildFailuresModuleOverview from file
C:\java\cvs\hackyCGQM\build\plugins\buildFailures\build\lib\buildFailures-plugin.jar
[java] Apr 21, 2005 11:09:01 PM
org.hackystat.app.cgqm.common.classloaders.JarClassLoader findClass
[java] INFO: Loading class
cGQM.plugin.buildFailures.QNightlyBuildFailures
from file
C:\java\cvs\hackyCGQM\build\plugins\buildFailures\build\lib\buildFailures-plugin.jar
[java] Apr 21, 2005 11:09:01 PM
org.hackystat.app.cgqm.common.classloaders.JarClassLoader findClass
[java] INFO: Loading class
cGQM.plugin.buildFailures.QNightlyBuildFailuresReasonOverview from file
C:\java\cvs\hackyCGQM\build\plugins\buildFailures\build\lib\buildFailures-plugin.jar
[java] Apr 21, 2005 11:09:01 PM
org.hackystat.app.cgqm.common.classloaders.JarClassLoader findClass
[java] INFO: Loading class
cGQM.plugin.buildFailures.MNightlyBuildData from file
C:\java\cvs\hackyCGQM\build\plugins\buildFailures\build\lib\buildFailures-plugin.jar
-------------------------------------------------------------------------------------
- [Christoph, Trivial] Tomcat window output. should this be printed under
logger.fine?
04/21 23:11:11 Loaded cGQM plugin 'buildFailures' successfully
Loaded cGQM plugin 'buildFailures' successfully
04/21 23:11:11 Loaded cGQM plugin 'common' successfully
Loaded cGQM plugin 'common' successfully
04/21 23:11:11 Loaded cGQM plugin 'overview' successfully
Loaded cGQM plugin 'overview' successfully
-------------------------------------------------------------------------------------
- [Takuya, Trivial] Tomcat window output. Probably just a testing output
that should be deleted.
ReviewGroupManager was instantiated:::::::::::
-------------------------------------------------------------------------------------
- [Developer Unknown, Trivial/ maybe Major] Tomcat window
output:
04/21 23:19:50 invalid project
04/21 23:19:50 invalid project
04/21 23:19:50 invalid project
-------------------------------------------------------------------------------------
- [Philip, Trivial] Delete testuserxml via build.xml. the test user
"testuserxml" never gets deleted when building the system.
I fixed this for you.. added
<delete
dir=
"${hackystat.data.dir}/users/testuserxml"
/>
