On Tue, Sep 13, 2011 at 1:06 AM, Sergiu Dumitriu <[email protected]> wrote: > 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
Done. > >> 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
