[jira] [Resolved] (WICKET-4554) WicketTester tries to create a directory called "tester" every time the tests run and thus fails when run under the security manager

["Martin Grigorov (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-4554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Grigorov resolved WICKET-4554.
-------------------------------------

       Resolution: Fixed
    Fix Version/s: 6.0.0-RC1
                   1.5.7
         Assignee: Martin Grigorov

Added a way to set your own work folder with JVM option: -Dwicket.tester.work.folder.
By default if this option is not set it will fallback to the old relative 'target/work'.
If any of these fail with SecurityException then the final fallback is -Djava.io.tmpdir.

I hope this is good enough for you. Let us know if there is something more to be improved.
                
> WicketTester tries to create a directory called "tester" every time the tests run and thus fails when run under the security manager
> ------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WICKET-4554
>                 URL: https://issues.apache.org/jira/browse/WICKET-4554
>             Project: Wicket
>          Issue Type: Improvement
>          Components: wicket
>    Affects Versions: 1.5.5
>            Reporter: Trejkaz
>            Assignee: Martin Grigorov
>              Labels: security, wicket-tester
>             Fix For: 1.5.7, 6.0.0-RC1
>
>
> Back story: after countless frustrating moments of having to clean up my working copy after unit tests have randomly dropped files in it, I am on the warpath. I created a security policy and am now trying to get tests to run under it. This has resulted in finding a few real bugs in our software so it turns out to be a worthwhile exercise for improving stability as well as reducing the amount of future hassles with files appearing and having to be deleted again.
> Anyway, WicketTester appears to be a major culprit at present:
> {noformat}
> java.security.AccessControlException: access denied ("java.io.FilePermission" "target\work" "write")
> 	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:366)
> 	at java.security.AccessController.checkPermission(AccessController.java:555)
> 	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> 	at java.lang.SecurityManager.checkWrite(SecurityManager.java:979)
> 	at java.io.File.mkdir(File.java:1237)
> 	at java.io.File.mkdirs(File.java:1266)
> 	at org.apache.wicket.protocol.http.mock.MockServletContext.<init>(MockServletContext.java:103)
> 	at org.apache.wicket.util.tester.BaseWicketTester.<init>(BaseWicketTester.java:272)
> 	at org.apache.wicket.util.tester.BaseWicketTester.<init>(BaseWicketTester.java:245)
> 	at org.apache.wicket.util.tester.WicketTester.<init>(WicketTester.java:196)
> 	at com.acme.server.webui.WebUITestCase.setUp(WebUITestCase.java:83)
> {noformat}
> Looking in MockServletContext I find this nasty piece of work:
> {code}
>     // assume we're running in maven or an eclipse project created by maven,
>     // so the sessions directory will be created inside the target directory,
>     // and will be cleaned up with a mvn clean
>     File file = new File("target/work/");
>     file.mkdirs();
>     attributes.put("javax.servlet.context.tempdir", file);
> {code}
> Not only is it accessing the local directory but it is forcibly creating a directory there even though it doesn't have permission. And then because it doesn't catch the SecurityException which might arise either, every test for our Wicket UI code fails.
> I think that if Wicket absolutely must create a directory for temporary data, that directory should be in java.io.tmpdir and not anywhere else (certainly not the current working directory where I have all my code.)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira