Hi, On 8/25/06, Christoph Kiehl <[EMAIL PROTECTED]> 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/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
