Community
Participate
Working Groups
When I run RSE tests on my localhost, it asks me about the secure storage password. Now I deleted the .eclipse directory, but it still does the same. If I do not provide a password, tests cannot proceed and that leads to the build hangout. I suspect this causes hangout of the hudson job as well. Currently junit tests are disabled.
Is this really still open, and what is missing ?
The problem is that the secure storage support in the base is asking for the password to unlock the store making this incapable of running as part of a build. We can disable this particular test for the build (easiest) or put a preference in that disables access to secure storage in any way so that the tests run as part of the build.
Created attachment 216745 [details] patch to add test "API" to prohibit access to secure storage The patch adds test methods to the PasswordPersistenceManager that will cause it to not access secure preferences. The PasswordsTest class has also been modified to be sensitive to this setting.
Martin and Anna - please review the patch. Anna - you will need to use the API as part of the test setup so that secure storage isn't accessed during tests. I'm not sure how you want to handle this.
Dave, should I set up some preference to disable secure storage? Which one exactly?
Anna -- I added a test-only "API" method to turn it off. PasswordPersistenceManager ppm = PasswordPersistenceManager.getInstance(); ppm.disableSecureStorageAccess(); If you want to use a preference or a defines you can implement that and then invoke this test-only API.
I believe I need two signoffs at this stage before integrating, correct?
(In reply to comment #6) > Anna -- > > I added a test-only "API" method to turn it off. > > PasswordPersistenceManager ppm = PasswordPersistenceManager.getInstance(); > ppm.disableSecureStorageAccess(); > > If you want to use a preference or a defines you can implement that and then > invoke this test-only API. I would probably need it in the rse.tests Activator#start method unless you can suggest some other way to disable it for headless builds.
I think so. (In reply to comment #7) > I believe I need two signoffs at this stage before integrating, correct?
I'm afraid it's too late for this kind of changes. I'm not in favor of adding API just for tests (if this is just about a toggle, a System Property would also do or maybe "internal" non-API). Plus, I don't quite see how you intend logging in to a remote system during tests. The last scheduled build was yesterday. We can think about putting a solution without using public API into 3.4.1.
The public methods added are not API. They are tagged as "@noreference" and the javadoc explicitly states they are not API. I'm not a big fan of defining new system properties because of the potential for misuse and conflict. Documenting them is outside the usual scope of javadoc. They are hard to track and hard to discover. This is a personal bias and I can be persuaded otherwise if it convenient. That said, I agree it is probably too late to put this in. So we can discuss how best to implement the switch for testing in this bugzilla. Anna -- from your perspective is a system property easier to incorporate into the test regimen? If so, I'll remove the methods I added and define an appropriate property.
(In reply to comment #11) > > Anna -- from your perspective is a system property easier to incorporate into > the test regimen? If so, I'll remove the methods I added and define an > appropriate property. I think it's about the same difficulty as disabling in Activator#start.
Has this been committed into TM 3.5 yet ?
This is will integrated into 3.4.2 as a property change instead of the original "test API" change. Since this is still the master branch it will make it into 3.5 as well.
Resetting the review counters.
I will be attaching a patch for review later today. Anna are you available for review?
Created attachment 225643 [details] patch to avoid accessing secure store using a property The patch looks for the "rse.enableSecureStoreAccess" property. If absent it defaults to true. If present then the value must be true to enable access to the secure store. To disable access to the secure store during JUnit testing you would do the following: System.setProperty("rse.enableSecureStoreAccess", "false");
change reviewed and committed
