db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: [jira] Commented: (DERBY-2644) multiple junit failures during nightly of the form: 2) Encryption Algorithm: defaultjava.security.AccessControlException: Access denied (java.util.PropertyPermission derby.system.home read)
Date Mon, 21 May 2007 16:48:38 GMT
Kathey Marsden (JIRA) wrote:
>     [ https://issues.apache.org/jira/browse/DERBY-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497457
> Kathey Marsden commented on DERBY-2644:
> ---------------------------------------
> I can no longer reproduce the failures.  I think in fact that the failures I was seeing
were in different tests. If upgrade is causing the problem, it would seem sensible to either
move the Encryption suite before the upgrade tests or remove it all together since it is not
very functional.
> The EncryptionKeyXXXTest failures that I have been seeing have been resolved in my client
by adding
> permission java.util.PropertyPermission "user.dir", "read";
> permission.  
> So, I propose the following approach:
> Today I will disable the Encryption suite.
> Tuesday I will reenable the EncryptionKeyXXXTests with the new permission.
> Does that sound reasonable?


I don't see any reason to disable working tests, the Encryption suite. 
It does produce a somewhat useful function, ensure that databases can be 
created with various encryption algorithms. It is also a initial step in 
duplicating that old harness that run a number of standard tests with 
encryption. Ie. the idea was that once old harness store tests that run 
with & without encryption were converted to JUnit they could be added to 
the Encryption suite. If certain environments are having trouble running 
  tests then the problems should be tracked down in those environments, 
not by making changes to svn to see the effect in those environments.

On adding the property I agree with Kristian, the reason why this 
property is suddenly needed should be tracked down.

FYI - running the tests through ant junit-all gives me clean runs using 
a 1.5 jvm as of the latest check-in (Revision: 540150). Running the 
tests using ant is different to running them using suites.All.


View raw message