On 09/12/2011 01:27 PM, Thomas Mortagne wrote: > On Mon, Sep 12, 2011 at 5:35 PM, Sergiu Dumitriu<[email protected]> wrote: >> On 09/12/2011 09:47 AM, Thomas Mortagne wrote: >>> Ok new proposal: >>> >>> * introduce ApplicationContext#getWorkDirectory >>> * introduce container.workDirectory in xwiki.properties >>> * for now keep same behavior as XWiki#getWorkDirectory: if >>> container.workDirectory is not defined then fallback on >>> getTemporaryDirectory() >> >> +1. Not sure getWorkDirectory is the best name, though. It doesn't >> contrast enough with getTemporaryDirectory, especially since >> getTemporaryDirectory usually returns something called "work". >> >> The meaning of the function is: get me a directory where I can safely >> write some data that will be available after restarts (best effort). By >> the way, it should be mentioned in the javadoc that there's no hard >> guarantee that the data won't be removed between restarts. >> >> Some proposals: >> >> - getPermanentDataDirectory >> - getPermanentStorageDirectory >> - getSafeStorageDirectory >> - getDataStorageDirectory >> - getDataDirectory >> - getWorkDataDirectory >> >> I think my slightly favorite is getPermanentDataDirectory. > > I think I would prefer "getPermanentDirectory" which fits better when > you compare it to "getTemporaryDirectory". Permanent vs Temporary > sounds good. Both are about datas anyway. Same renaming for the > property, right ?
Indeed, +1 for getPermanentDirectory > I already just committed getWorkDirectory but can change it anytime > before 3.2M3 release. > >> >>> I would really like to start using the API and I don't really care how >>> it's implemented at EM level as long as I get a persisting folder when >>> I can write stuff. We can always add more fallbacks before >>> getTemporaryDirectory() later. >>> >>> WDYT ? >>> >>> Here is my +1 >>> >>> On Mon, Sep 12, 2011 at 12:59 PM, Thomas Mortagne >>> <[email protected]> wrote: >>>> I think I finally understand why XE has a hack to add >>>> >>>> xwiki.work.dir=work >>>> >>>> at the end the generated xwiki.cfg file. It just hope to be run in a >>>> folder where it has the right to write and which is persisted between >>>> restarts. >>>> >>>> Because if you don't set this then it will use >>>> javax.servlet.context.tempdir which can be removed anytime... >>>> So basically even XWiki#getWorkDirectory has no clue where to find a >>>> proper work directory and it has to be explicitly specified. >>>> >>>> It was kind of OK for the Lucene index but seems pretty fuzzy for >>>> filesystem attachments or extension manager local repository to me. >>>> >>>> So I guess we will have to really start defining something about work >>>> directory. >>>> >>>> On Mon, Sep 12, 2011 at 11:58 AM, Thomas Mortagne >>>> <[email protected]> wrote: >>>>> On Mon, Sep 12, 2011 at 11:53 AM, Thomas Mortagne >>>>> <[email protected]> wrote: >>>>>> Hi devs, >>>>>> >>>>>> Right now there is no way for a component to know where is the >>>>>> standard work directory (the one used for Lucene or filesystem >>>>>> attachments for example) so I would like to add an API to access it. >>>>>> >>>>>> That said I propose to add a >>>>>> >>>>>> File getWorkDirectory() >>>>>> >>>>>> in org.xwiki.container.ApplicationContext which will use >>>>>> XWiki#getWorkDirectory() behind the scene probably for now. >>>>>> >>>>>> WDYT ? >>>>>> >>>>>> -- >>>>>> Thomas Mortagne >>>>>> >>>>> >>>>> Actually ServletApplicationContext does not have access to old XWiki >>>>> API right now so I'm not sure what's the best for implementing this >>>>> method yet. >>>>> >>>>> -- >>>>> Thomas Mortagne >>>>> -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
