Forum Discussion

EmilyS's avatar
EmilyS
Occasional Contributor
14 years ago

Home folder changed by itself? Now loadui won't run.

Hi,

I'm seeing some very strange behavior with loadui. I a month or so ago I installed loadui on a Team City build agent, and it's been running smoothly ever since (it runs several times per day). I have it running without any special system settings, and by default it uses "C:\Documents and Settings\Default User\.loadui" as its home folder. I've put all the necessary config files in this directory, so there are no issues.

Today, the tests suddenly started failing with the following error:
java.lang.RuntimeException: java.io.FileNotFoundException: C:\Documents and Settings\antony\.loadui\keystore.jks (The system cannot find the file specified)

Antony is another developer at our company, and he had briefly logged into the build agent these tests are running on earlier this morning. He did install an updated version of Flash on the machine, but didn't make any changes related to loadui.

Somehow, loadui now thinks it's supposed to use Antony's documents and settings folder as its home directory, and I can't figure out why or how to get it back to using the Default User directory like it was previously. I've tried rebooting the build agent machine, but that didn't help.

I've also tried to force loadui to use the Default User home directory by passing in system properties on the command line:

"-Dloadui.ssl.trustStore=C:\Documents and Settings\Default User\.loadui\keystore.jks" "-Dloadui.ssl.keyStore=C:\Documents and Settings\Default User\.loadui\keystore.jks" "-Dloadui.home=C:\Documents and Settings\Default User\.loadui" --local -p %teamcity.build.workingDir%\LockerLoadTests.xml --reports %teamcity.build.workingDir%\output --format HTML --statistics

However, this results in a completely different error:

[15:15:51]: 15:15:51,083 INFO [CommandRunner] Loading default Workspace
[15:15:51]: 15:15:51,098 INFO [WorkspaceProviderImpl] Loading workspace from file: C:\Documents and Settings\Default User\.loadui\workspace.xml
[15:15:51]: 15:15:51,364 INFO [WorkspaceItemImpl] Workspace 'WorkspaceItemImpl[label=null]' loaded successfully
[15:15:51]: 15:15:51,427 INFO [CommandRunner] Loading Project: C:\BuildAgent\work\f1138bd24ae22e5a\LockerLoadTests.xml
[15:15:51]: 15:15:51,505 ERROR [CommandRunner] An error occured when executing the script
[15:15:51]: java.lang.IllegalArgumentException: No Bean found for class: interface com.eviware.loadui.api.statistics.StatisticsAggregator
[15:15:51]: at com.eviware.loadui.util.BeanInjector.doGetBean(BeanInjector.java:68)
[15:15:51]: at com.eviware.loadui.util.BeanInjector.getBean(BeanInjector.java:45)
[15:15:51]: at com.eviware.loadui.impl.statistics.AbstractStatisticsWriter.<init>(AbstractStatisticsWriter.java:71)
[15:15:51]: at com.eviware.loadui.impl.statistics.CounterStatisticsWriter.<init>(CounterStatisticsWriter.java:39)
[15:15:51]: at com.eviware.loadui.impl.statistics.CounterStatisticsWriter$Factory.createStatisticsWriter(CounterStatisticsWriter.java:142)

Can you please help? At this point I'm completely unable to run loadui on the build server due to the above issues.

Thanks,
Emily
  • SmartBear_Suppo's avatar
    SmartBear_Suppo
    Icon for Alumni rankAlumni
    14 years ago
    Hi,

    The reason for this is likely that you're logged into Windows as antony when you're starting loadUI, as loadUI will attempt to use the .loadui folder in the current users home folder (C:\Documents and Settings\<current user>\.loadui). You can override this behaviour by specifying -Dloadui.home=C:\Your\Path\Here\.loadui on the command line, as you seem to have already figured out.

    Regarding the error you're getting, can you try starting using only the -Dloadui.home parameter, as well as the other test related ones and see if you still get the error? If you do, can you check the if there is any error above the one you posted?

    Regards,
    Dain
    SmartBear Software
  • EmilyS's avatar
    EmilyS
    Occasional Contributor
    14 years ago
    Hi Dain,

    Thanks for your prompt reply.

    The tests are run automatically on a scheduled basis by a Team City build agent, which is definitely not running under Antony's account (I've double checked - it runs on a system account). After a bit more digging, I have found that the Java "user.home" for the system account that runs the tests mysteriously changed from "C:\Documents and Settings\Default User" to "C:\Documents and Settings\antony", even though USERPROFILE is still correctly set to "C:\Documents and Settings\Default User".

    I have no idea how or why this change has occurred, but can pinpoint it to a 3 hour window yesterday, during which time Antony logged onto the machine that the tests run on and installed some automatic updates. Somehow during this time Java has gotten confused over the user.home directory for the system account that the tests run under.

    Here are a few related Java bugs that have been reported.
    http://stackoverflow.com/questions/2134 ... g-resolved
    http://bugs.sun.com/view_bug.do?bug_id=4787931

    Anyway, none of this appears to be directly related to loadui - it appears to be related to either Java itself or some unexplained event on the build machine that the tests run on.

    Today I attempted to run loadui from the command line without any system properties passed in, and now it's working again.

    --local -p %teamcity.build.workingDir%\LockerLoadTests.xml --reports %teamcity.build.workingDir%\output --format HTML --statistics

    Again, I have no idea why it stopped working yesterday and why it's working again now. It had been running for many weeks several times per day without any issues, so it's a bit disconcerting that some unexplained event temporarily confused it!

    Thanks,
    Emily