[HACKYSTAT-DEV-L] testshellcommand & TimeZoneChanger problems

[Aaron Kagawa]

Hey Guys,

I'm working on one of my Jira issues and I have a question:

Take a look at < http://hackydev.ics.hawaii.edu:8080/browse/HACK-257>.

Problem: This is the output from tomcat, which shows a TimeZoneChangerException from changing the testshellcommand XML data. The problem is that testshellcommand shouldn't need changing since the XML sensor data is already adjusted properly, because the XML data is generated during the Unit Tests.

However, other test users contain "static" test data and basically the TimeZoneChanger assumes that all test user XML data needs to be changed. In normal situations, after changing the xml data during startup of tomcat, the TimeZoneChanger sets a property in the user.default.xml indicating that the test data has already been changed (and shouldn't be changed in the future) for other users like testdataset, testprojectdataset, etc. Again, the testshellcommand data is different from the other test users and shouldn't need to be changed by the TimeZoneChanger.


Solution 1. Some background information first: the org.hackystat.kernel.soap.Receive class automatically creates a Hackystat user when the server receives sensor data from a user with the hackystat.test domain . We have a bunch of Sensor test cases that use [EMAIL PROTECTED] to send sensor data to the server (for example TestBuild, TestActivity, etc).

Change the Receive class to call the TimeZoneChanger to set a property when receiving data from test users. This solution is very general. If we every have another testshellcommand type user then the fix for this current problem will also fix future problems. For example something like this

    // Automatically define the user if the received key is a testcase userEmail.
    if (key.endsWith(serverProperties.getTestDomain())) {
      User testUser = null;
      // Make sure the test user doesn't exist
      if (!userManager.isUserEmail(key) {
        testUser = userManager.getUser(key);
        // No make sure that the xml data won't be changed in the future
        TimeZoneChanger.getInstance().noChangeNeeded(testUser);
      }
      else {
        testUser = userManager.getUser(key);
      }
      // Change the passed key (a test case userEmail) into its corresponding userKey.
      key = testUser.getUserKey();
    }

Solution 2: Hack the TimeZoneChanger to ignore the testshellcommand user.  Less general than Solution 1.

Solution 3: Delete the testshellcommand user after the unit tests are finished executing.


I suppose Solution 1 is the best. Does anyone see any problems with that proposed solution?

thanks, aaron

ps.. Mike do you see any other problems with the TimeZoneChanger out there on the East coast?