13 Sep
2011
13 Sep
'11
8:35 a.m.
On Tue, Sep 13, 2011 at 1:06 AM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
--
Thomas Mortagne
On 09/12/2011 01:27 PM, Thomas Mortagne wrote:
Done.
On Mon, Sep 12, 2011 at 5:35 PM, Sergiu
Dumitriu<sergiu(a)xwiki.com> wrote:
Indeed, +1 for getPermanentDirectory On 09/12/2011 09:47 AM, Thomas Mortagne wrote:
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 ? 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 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
>> <thomas.mortagne(a)xwiki.com> 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
>>> <thomas.mortagne(a)xwiki.com> wrote:
>>>> On Mon, Sep 12, 2011 at 11:53 AM, Thomas Mortagne
>>>> <thomas.mortagne(a)xwiki.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs