Hi Aaron, I am reluctant to hack the Receive class with TimeZoneChanger calls; it introduces a kind of coupling that "smells bad" to me.
How many test user accounts need to be changed? Another approach would be to have a property in hackystat.properties called something like hackystat.timezonechanger.users: hackystat.timezonechanger.users=testdataset,testprojectuser,testprojectuser2 The timezonechanger would read this comma-separated list and determine which accounts to change from that. How does this sound to you? Cheers, Philip --On Thursday, June 23, 2005 12:16 AM -1000 Aaron Kagawa <[EMAIL PROTECTED]> wrote:
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?
