Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (asf.osuosl.org: domain of stefan.guggisberg@gmail.com
 designates 64.233.162.202 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=eqObuIsl34CmtlBkSC+VAICQ0m+RugMU9s5AAmcph5NfxXNr/VZxLWh+gUumT2ouRNv2kRf0HZga/gqoPTyZ6nQvG5HcsvMr/pO0HCdSnsEu34l3MsDAD281/aALOY2i+z4WxHmxslA59Is3kB3ESQsOj6zs68iRLCPSOogyFMs=
Message-ID: <90a8d1c00608300308w73ff275cp987296f40f3fe924@mail.gmail.com>
Date: Wed, 30 Aug 2006 12:08:38 +0200
From: "Stefan Guggisberg" <stefan.guggisberg@gmail.com>
To: dev@jackrabbit.apache.org
Subject: Re: Jackrabbits own FileSystem and unit tests
In-Reply-To: <ecvd82$oa5$1@sea.gmane.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <ecnbqh$g75$1@sea.gmane.org>
	 <510143ac0608270703h78e4863bm8a2040aca36455c4@mail.gmail.com>
	 <ecvd82$oa5$1@sea.gmane.org>

On 8/28/06, Christoph Kiehl <kiehl@subshell.com> 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
>
>
>