How many test user accounts need to be changed?
All test users that have "static" data needs to be changed.
testshellcommand is an unusual case because its the only test user that is
created during runtime of the unit tests (and data is ). Therefore,
testshellcommand and other future test users like it do not need to be
changed.
hackystat.timezonechanger.users=testdataset,testprojectuser,testprojectuser2
Actually, this also sounds a little brittle. The problem is that it is hard
to know what test users are associated with a specific configuration. So,
Hackystat administrators would have to know what test users are in each of
the modules in their configuration to be able to properly configure that
property.
I can implement it.. but, I'm not sure its the best solution.
Hongbing Wrote:
I think solution 1 is good. I don't see side effects it will cause. But, the
problem is that this hacking will make SOAP receive class looks
odd. A new person may wonder why the hell a SOAP receive method
needs to declare there is no time shift for data from users in test domain.
Plus, it has nothing to do with receive function.
I completely agree. It took me a while to figure out that the Recieve class
creates test users, which is really strange. But, it seems like the only
place on server-side code that can do that, short of an HTTP testing
facility that registers test users.
For example, the TestBuild class just constructs a string
"[EMAIL PROTECTED]" and related build information and sends
that to the server. Currently, the Receive class checks to see if the user
that send the sensor data is a Test User and makes sure the test user has
been created before storing the data. In my opinion, the Receive class is
incorrectly creating test users, because test users that are created
dynamically should indicate that the data does not need to be changed by
the TimeZoneChanger.
thanks, aaron
At 12:41 PM 6/23/2005, you wrote:
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?
