On 8/28/06, Christoph Kiehl <[EMAIL PROTECTED]> wrote:
Jukka Zitting wrote:
>> I still don't get what this FileSystem is used for. Maybe someone with
>> deeper
>> knowlegde of the system could explain it to me? Or is it just there for
>> historical reasons?
>
> It is used extensively by the Object and XML persistence managers, but
> the more "modern" database persistence managers generally ignore the
> configured FileSystem for anything else than locally stored binary
> properties.
I think this file system abstraction idea does not for all parts of Jackrabbit
as the current process in development shows. Every persistence manager and index
implementation knows best how to save its data and it's sufficient to configure
their storage layer through the repository configuration.
As I understand right now there are basically three places where data is
persisted:
1. Jackrabbit core (repository.xml, workspace.xml, locking)
2. Persistence manager
3. Search index
There are already working solutions for 2. and 3. So, as you wrote, the right
way would be to refactor jackrabbits core to use an own storage. This could even
be the current FileSystem, while this FileSystem lacks a proper locking
mechanism which probably could be added.
locking is imo not required in the jr FileSystem abstraction since jr (or the
relevant subcomponent) *owns* the file system.
Would that work? The mentioned persistence managers could still use an own
instance of the Jackrabbit FileSystem, while they might be better off to use the
file system directly. I mean there is no sense in telling an XML persistence
manager to use memory or database based FileSystem. You could as well exchange
the persistence manager for a memory or database persistence manager.
i disagree. you might e.g. want to use the XMLPersistenceManager on a
DbPersistenceManager.
back to your original use case (which i think is a valid one)...
there are imo 3 issues which make it currently impossible to run jr
exclusively in memory, i.e. without leaving any traces on the disk:
1. there's obviously an issue with the InMemPersistenceManager;
it uses a LocalFileSystem to persist blob's even with 'persistent=false'
feel free to open a jira issue for this.
2. lucene doesn't use the jr FileSystem abstraction (there are valid reasons
for this and they were explained on the mailing list).
you seem to have found a workaround for this. another option could perhaps
be to disable SearchIIndex entirely.
3. there's currently no InMemFileSystem available in jr. since you wrote one
we'd be very interested if you'd consider contributing it ;-)
with the above 3 issues resolved it should imo be possible to run jackrabbit
entirely in memory.
cheers
stefan
Cheers,
Christoph
