Hi Aaron,
* Let's define isTestUser() to check for @hackystat.test domain, and use that alone as the discriminant for test users. That's what we use in the soap code: key.endsWith(serverProperties.getTestDomain()))
* As for other test user accounts not be deleted, that is a problem. Individual modules are responsible for housekeeping during their install target, just as you do for hackyPRI.
Please go ahead and have the timezone changer do its magic on all test users. That seems to make sense to me. (Please also reset your time on your local machine and see if this breaks anything!)
Cheers, Philip
--On Thursday, April 21, 2005 2:16 PM -1000 Aaron Kagawa <[EMAIL PROTECTED]> wrote:
At 11:41 AM 4/21/2005, you wrote:
Hi Aaron,
I have a question about timechanger. Can we use the TimezoneChanger to change Mike's data on a Sun Server? And how does the TimezoneChanger know not to change sensor data after it already has done so?
Thanks Philip
Bad news: I designed TimezoneChanger to only change UserManager.getInstance().TestUser();
Good news: To change TimezoneChanger to change all test users should be relatively easy.
Proposal: I need to use this iterator to get all the test users:
/** * Returns a thread - safe iterator over the set of User instances. * Includes both test and real users. Use User.isTestUser() to check. * May not include very recently added Users. * @return An iterator over the set of Users. */ public Iterator iterator () { return this .userSet.iterator(); }
There is no isTestUser(User) method. So, I'll make one. Just to be sure, what defines a test user? (1) a testuser has a userKey that starts in "test" and a userEmail that contains the @hackystat.test domain or (2) userKey = "test<something>" and any userEmail?
FYI: the TimezoneChanger checks the
<KeyValuePair key="timezonechanger.hasbeenchanged" value="true" />
KeyValuePair in the user.default.xml to determine if the sensor data has been changed. I think this is the ideal situation. However, I would be careful to not upload more data once the TimezoneChanger has already changed the sensor data, because any newly uploaded data will not be changed! The current mechanism works great for "real" test data (ie testdataset) because the testdataset user should be deleted each time during a new build. On the other hand, if no build occurs, no change is required.
Which reminds me, we need to add a mechanism to make sure all test users are removed during a build. I've noticed that some test users like testuserxml is never deleted using this ant target:
<target name= "initializeHackystatDataDir" depends= "checkProperties" if= "initialize.hackystatDataDir" description= "Deletes the hackystat.data.dir/users/testdataset directory." > <echo message= "(${ant.project.name}) Deleting ${hackystat.data.dir}/users/testdataset." /> <delete dir= "${hackystat.data.dir}/users/testdataset" /> <delete dir= "${hackystat.data.dir}/users/testprojectdataset" /> <delete dir= "${hackystat.data.dir}/users/testshellcommand" /> </target>
therefore, in my hackyPRI module I have the following ant target.. that makes sure I delete my test user before copying it over.
<!-- *********************************************************************** --> <target name= "installTestDataSets" description= "Copies all of the testdatasets to the installation directory. Crufty implementation." > <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>
if we don't delete test users (in a different timezone), the property "timezonechanger.hasbeenchanged" could be set to true, then if any new data is copied over (via a build) it will not be changed.
please let me know if you have any questions or concerns.
thanks, aaron
At 11:41 AM 4/21/2005, you wrote:
Hi Aaron,
I have a question about timechanger.
Thanks Philip
