[xwiki-devs] [PROPOSAL] Introduce a work directory concept in the Container API
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
On Sep 12, 2011, at 11:53 AM, Thomas Mortagne 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 ?
+1 Thanks -Vincent
On Mon, Sep 12, 2011 at 11:53 AM, Thomas Mortagne <thomas.mortagne@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
On Sep 12, 2011, at 11:58 AM, Thomas Mortagne wrote:
On Mon, Sep 12, 2011 at 11:53 AM, Thomas Mortagne <thomas.mortagne@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 * use a config property in xwiki.properties instead of in xwiki.cfg ? Thanks -Vincent
On Mon, Sep 12, 2011 at 12:02 PM, Vincent Massol <vincent@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@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 * 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...
?
Thanks -Vincent
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Sep 12, 2011, at 12:13 PM, Thomas Mortagne wrote:
On Mon, Sep 12, 2011 at 12:02 PM, Vincent Massol <vincent@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@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 * 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. Thanks -Vincent
On Mon, Sep 12, 2011 at 12:16 PM, Vincent Massol <vincent@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@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@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
* 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.
Thanks -Vincent _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Sep 12, 2011, at 12:19 PM, Thomas Mortagne wrote:
On Mon, Sep 12, 2011 at 12:16 PM, Vincent Massol <vincent@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@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@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
On Mon, Sep 12, 2011 at 12:27 PM, Vincent Massol <vincent@massol.net> wrote:
On Sep 12, 2011, at 12:19 PM, Thomas Mortagne wrote:
On Mon, Sep 12, 2011 at 12:16 PM, Vincent Massol <vincent@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@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@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.
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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
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@xwiki.com> wrote:
On Mon, Sep 12, 2011 at 11:53 AM, Thomas Mortagne <thomas.mortagne@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
-- Thomas Mortagne
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() 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@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@xwiki.com> wrote:
On Mon, Sep 12, 2011 at 11:53 AM, Thomas Mortagne <thomas.mortagne@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
-- Thomas Mortagne
-- Thomas Mortagne
On Sep 12, 2011, at 3:47 PM, 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()
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
+1 Thanks -Vincent
On Mon, Sep 12, 2011 at 12:59 PM, Thomas Mortagne <thomas.mortagne@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@xwiki.com> wrote:
On Mon, Sep 12, 2011 at 11:53 AM, Thomas Mortagne <thomas.mortagne@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
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 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@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@xwiki.com> wrote:
On Mon, Sep 12, 2011 at 11:53 AM, Thomas Mortagne <thomas.mortagne@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/
On Mon, Sep 12, 2011 at 5:35 PM, Sergiu Dumitriu <sergiu@xwiki.com> 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 ? 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@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@xwiki.com> wrote:
On Mon, Sep 12, 2011 at 11:53 AM, Thomas Mortagne <thomas.mortagne@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@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Sep 12, 2011, at 7:27 PM, Thomas Mortagne wrote:
On Mon, Sep 12, 2011 at 5:35 PM, Sergiu Dumitriu <sergiu@xwiki.com> 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 ?
I already just committed getWorkDirectory but can change it anytime before 3.2M3 release.
getPermanentDirectory() is fine with me too. Thanks -Vincent
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@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@xwiki.com> wrote:
On Mon, Sep 12, 2011 at 11:53 AM, Thomas Mortagne <thomas.mortagne@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
On 09/12/2011 01:27 PM, Thomas Mortagne wrote:
On Mon, Sep 12, 2011 at 5:35 PM, Sergiu Dumitriu<sergiu@xwiki.com> 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
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@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@xwiki.com> wrote:
On Mon, Sep 12, 2011 at 11:53 AM, Thomas Mortagne <thomas.mortagne@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/
On Tue, Sep 13, 2011 at 1:06 AM, Sergiu Dumitriu <sergiu@xwiki.com> wrote:
On 09/12/2011 01:27 PM, Thomas Mortagne wrote:
On Mon, Sep 12, 2011 at 5:35 PM, Sergiu Dumitriu<sergiu@xwiki.com> 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 <thomas.mortagne@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@xwiki.com> wrote:
On Mon, Sep 12, 2011 at 11:53 AM, Thomas Mortagne <thomas.mortagne@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@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Hi Thomas, On Mon, Sep 12, 2011 at 4:47 PM, Thomas Mortagne <thomas.mortagne@xwiki.com>wrote:
Ok new proposal:
* introduce ApplicationContext#getWorkDirectory * introduce container.workDirectory in xwiki.properties
AFAIK, we were supposed to deprecate xwiki.properties and use xwiki.cfg instead. I notice that nobody is saying anything so I`d like to make it clear for myself :) Which one is it, xwiki.properties or xwiki.cfg? Thanks, Eduard
* for now keep same behavior as XWiki#getWorkDirectory: if container.workDirectory is not defined then fallback on getTemporaryDirectory()
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@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@xwiki.com> wrote:
On Mon, Sep 12, 2011 at 11:53 AM, Thomas Mortagne <thomas.mortagne@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
-- Thomas Mortagne
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
On Sep 13, 2011, at 12:58 PM, Eduard Moraru wrote:
Hi Thomas,
On Mon, Sep 12, 2011 at 4:47 PM, Thomas Mortagne <thomas.mortagne@xwiki.com>wrote:
Ok new proposal:
* introduce ApplicationContext#getWorkDirectory * introduce container.workDirectory in xwiki.properties
AFAIK, we were supposed to deprecate xwiki.properties and use xwiki.cfg instead.
No that's not correct. xwiki.cfg is the old one. xwiki.properties is the new one :) Thanks -Vincent
I notice that nobody is saying anything so I`d like to make it clear for myself :) Which one is it, xwiki.properties or xwiki.cfg?
Thanks, Eduard
* for now keep same behavior as XWiki#getWorkDirectory: if container.workDirectory is not defined then fallback on getTemporaryDirectory()
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@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@xwiki.com> wrote:
On Mon, Sep 12, 2011 at 11:53 AM, Thomas Mortagne <thomas.mortagne@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
On Tue, Sep 13, 2011 at 12:58 PM, Eduard Moraru <enygma2002@gmail.com> wrote:
Hi Thomas,
On Mon, Sep 12, 2011 at 4:47 PM, Thomas Mortagne <thomas.mortagne@xwiki.com>wrote:
Ok new proposal:
* introduce ApplicationContext#getWorkDirectory * introduce container.workDirectory in xwiki.properties
AFAIK, we were supposed to deprecate xwiki.properties and use xwiki.cfg instead. I notice that nobody is saying anything so I`d like to make it clear for myself :) Which one is it, xwiki.properties or xwiki.cfg?
That's the opposite actually, xwiki.cfg is the old one ;)
Thanks, Eduard
* for now keep same behavior as XWiki#getWorkDirectory: if container.workDirectory is not defined then fallback on getTemporaryDirectory()
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@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@xwiki.com> wrote:
On Mon, Sep 12, 2011 at 11:53 AM, Thomas Mortagne <thomas.mortagne@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
-- Thomas Mortagne
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Big +1 Caleb On 09/12/2011 05:53 AM, Thomas Mortagne 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 ?
participants (5)
-
Caleb James DeLisle -
Eduard Moraru -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol