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.
Cheers,
Christoph
