[
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
