Writing anywhere else than the XWiki temporary or permanent folder is a very bad practice.
I just discovered Loading... where I did the mistake (pretty sure I knew it was bad back then, but I still did the mistake), I would like to propose a new Spoon rule to forbid the use of API which makes a bit too easy to make this kind of mistake:
(don’t hesitate if you have others in mind, I will check for stuff like this in Apache commons too)
All those APIs have a version where you can pass a parent folder, so it’s not like it was going to make it harder to code some stuff, it’s just a gentle reminder.
I gave this too little time before posting for sure, anyway: doesn’t that API use the environment set temp folder? And couldn’t it be changed in a number of places (config, startup, etc.)?
Asking because two minute searches on the net didn’t bring up reliable / complete docs, but maybe instead of forbidding it, you may configure it to fit XWiki?
Yes, you’re right, the check will need to ignore the Environment implementation (in AbstractEnvironment.javato be precise, where System.getProperty("java.io.tmpdir"); is used a fallback if the servlet tmp dir cannot be found).
It’s very rarely the same as what the Environment returns. It entirely depends on the application server configuration, and it’s generally the temporary directory of the application server itself so not really what an application should ever use IMO.
Sure, you can generally set it with a Java command line parameter. But I would prefer to not require admins to have to set it to an XWiki related folder as much as possible, and you simply can’t when you have an application server with more than XWiki in it (this system property applies to the whole JVM). An application should use the temporary folder which was allocated to it by the application server, I’m just trying to make sure it’s the case for XWiki.