On Mon, Sep 12, 2011 at 12:27 PM, Vincent Massol <[email protected]> wrote:
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.
The goal of this proposal to to provide an standard API accessible by components so obviously the right place is Contaner API and I never suggested otherwise. I'm only talking about implementation here which have nothing to do with the API. And starting a new implemention mean having a debate on where the work dir should be located which is what I meant.
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne