jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph Kiehl <ki...@subshell.com>
Subject Re: Jackrabbits own FileSystem and unit tests
Date Mon, 28 Aug 2006 18:39:53 GMT
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.
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.


View raw message