jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: Jackrabbits own FileSystem and unit tests
Date Sun, 27 Aug 2006 14:03:36 GMT
Hi,

On 8/25/06, Christoph Kiehl <kiehl@subshell.com> wrote:
> I'm trying to modify Jackrabbit to work _only_ in memory and persist _nothing_
> in the file system. I want this for testing purposes, where I don't like any
> files being created besides the fact that memory should be the fastest. My test
> data sets aren't that large anyway so memory usage is not a concern.

I think that's impossible with the current Jackrabbit. There was some
discussion quite a while ago about implementing a simple in-memory
repository for testing purposes, but that idea never went anywhere. I
think a more realistic plan for implementing that would be to go
through and refactor all the filesystem dependencies in Jackrabbit.

> 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.

> However, maybe someone has a better strategy to get a lightweight repository
> which could be quickly initialized and is usable in unit tests. I don't like the
> idea to mock the JCR API because this way our tests become to unnatural and complex.

Agreed, the JCR API is quite difficult to Mock properly for any
non-trivial test case.

BR,

Jukka Zitting

-- 
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development

Mime
View raw message