2 May
2012
2 May
'12
3:20 p.m.
Hi Caleb,
On May 2, 2012, at 3:12 PM, Caleb James DeLisle wrote:
Just committed the patch to a branch, you can see it
here
https://github.com/xwiki/xwiki-commons/commit/32fb77049fe9d8f758e776d26bfe5…
Since it contains an API break in EnvironmentConfiguration, I wanted to run it by the
list before merging it into the master.
I'll push later on today if nobody objects.
We should no longer break APIs. So this will need to go through deprecation and legacy.
Why is File an issue?
Big -1 to the code I've seen. We should never ever use System.exit().
Also I've seen a lot of "final" used in the code. Please don't use them
since they're unnecessary and bad in most cases and we don't have any best
practice to use them in methods for ex (this prevents extensibility). As for variables I
don't see the point at all.
Re the fail fast I was expecting some event listener listening on Application started
event to check if the directories were writable for example and throw some exception if
not.
Thanks
-Vincent
Caleb
On 04/23/2012 09:43 AM, Caleb James DeLisle wrote:
> Hi,
>
> In order to fix XWIKI-7748 and XWIKI-7749, we need a plan for deleting temporary
file.
> XWikiAttachmentContent uses File.deleteOnExit(), but in Sun's implementation,
deleteOnExit()
> only deletes on a *clean* exit, in a crash it can't delete the files but it
doesn't tag them
> so they can be deleted in the next run either. Since temp files are usually
pseudo-randomly
> named, they are impossible to find and delete later.
>
> I propose that we create a subdirectory, `java.io.tmpdir`/xwiki/ which will be
removed on
> application exit. If the jvm crashes, the files will be removed next time around.
Then alter
> ApplicationContext.getTemporaryDirectory() to yield this directory.
>
> WDYT?
>
> Caleb