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 ? 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 > -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
