>>>>> "DJD(" == Daniel John Debrunner (JIRA) <[email protected]> writes:
DJD(> This patch added two new tests, RecoveryAfterBackup and
DJD(> RecoveryAfterBackupSetup, both of which are being run
DJD(> without a SecurityManager due to the noSecurityManager=true
DJD(> in their _app.properties files.
DJD(> Why are these tests excluded from running with a
DJD(> SecurityManager? It should be rare that a test is to not to
DJD(> be run with a SecurityManager, if such a need arises the
DJD(> noSecurityManager=true must be commented to indicate why
DJD(> this is the case.
DJD(> The default for any new tests in the existing harness should
DJD(> be to run with the SecurityManager.
DJD(> There are a handful of tests that have
DJD(> noSecurityManager=true with no comment or a comment that
DJD(> says needs investigating, I'm working on all of these since
DJD(> they are exisiting tests, but it's not my itch to clean up
DJD(> new tests.
When my test failed to run because it was not allowed to create a
backup, I checked what other backup tests do, and all of them, also
new ones, in addition to a dozen other store tests, handle this by
disabling the SecurityManager. I thought this was the accepted way of
doing it, especially since you seemed to be the person that had
changed the property files. (I now understand that the jira reports
referred in the property files explain why it was disabled. I thought
it just referred to the JIRA issues for introducing the
SecurityManager. I would prefer a more verbose comment.)
I am sorry that I misunderstood how things was supposed to be done.
However, as long as there are so many examples of tests that just
disables the security manager, I think it is not unlikely that others
will do the same mistake.
How should I fix this? Should I edit a policy file or make a comment
to why it is disabled?
A related question: How is Derby users supposed to deal with this? It
seems like it would create some hassle for them to run with the
SecurityManager.
--
Øystein
