On Sep 12, 2011, at 12:19 PM, Thomas Mortagne wrote: > On Mon, Sep 12, 2011 at 12:16 PM, Vincent Massol <[email protected]> wrote: >> >> On Sep 12, 2011, at 12:13 PM, Thomas Mortagne wrote: >> >>> On Mon, Sep 12, 2011 at 12:02 PM, Vincent Massol <[email protected]> wrote: >>>> >>>> On Sep 12, 2011, at 11:58 AM, Thomas Mortagne 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. >>>> >>>> * 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
