On Sep 12, 2011, at 12:19 PM, Thomas Mortagne wrote:
On Mon, Sep 12, 2011 at 12:16 PM, Vincent Massol
<vincent(a)massol.net> wrote:
On Sep 12, 2011, at 12:13 PM, Thomas Mortagne wrote:
> On Mon, Sep 12, 2011 at 12:02 PM, Vincent Massol <vincent(a)massol.net> wrote:
>>
>> On Sep 12, 2011, at 11:58 AM, Thomas Mortagne 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.
>>
>> * use the java system property for finding the servlet work dir
There is no such thing in Servlet specs AFAIK
Indeed (I mixed up with servlet tmp dir: javax.servlet.context.tempdir) but that
doesn't change the fact that we can configure the location of the work dir in
xwiki.properties.
* use a config
property in xwiki.properties instead of in xwiki.cfg
I know what XWiki#getWorkDirectory() but I would like to not have to
rewrite it if possible…
Yes but IMO it's better to rewrite it cleanly than putting the getWorkDirectory in a
bad location or doing some hacks to depend on the old core.
It's also not like it's a big thing to rewrite.
What I mean is that I did not planned to start now a new
implementation/property and a debate on where should work dir be
located, I just wanted a working API.
By located I didn't mean where the dir is located but where the api is located. For me
the right place is in the Container API. Moving to another place because container api
implementation module doesn't have access to the old is not a strong enough reason to
not put the new api in the Container API IMO.
Thanks
-Vincent