Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of justinedelson@gmail.com
 designates 209.85.212.42 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:reply-to:user-agent:mime-version:to:subject
         :references:in-reply-to:content-type:content-transfer-encoding;
        b=kX8F+nQV8E/sg42FNXOHMgg5R+ifI7iu4FvqCCIRNbQFJe/h9BjFE9MeVsKXP6ArAC
         auGe7NskeXT78tQD467gkXKNJdwztmcqxCzbKnuN1XC2gzbksF9sQgLJCRsRbCrrLrF7
         vqKw5WmL6mYoHD0iRuZUZeFp+uT6j5HECUis8=
Message-ID: <4C8E2439.3010004@gmail.com>
Date: Mon, 13 Sep 2010 09:16:41 -0400
From: Justin Edelson <justinedelson@gmail.com>
Reply-To: justin@justinedelson.com
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3
MIME-Version: 1.0
To: users@jackrabbit.apache.org
Subject: Re: Spring configuration?
References: <AANLkTimD3b=ogPVEX9DrM2ULomRpCijQXffpGbMA5Cd+@mail.gmail.com>
	<AANLkTi=TKM1ZeHH8wWOCOUHbFUa8b+C-bjSmanSb1T-z@mail.gmail.com>
	<AANLkTim-Fsq2b12weqrKvqhgyQFhwkEwOgEB63dh8Y33@mail.gmail.com>
	<AANLkTik+XJxPvYd=W9J1MOWmx2GeE3t2TcDMTZzqO5eu@mail.gmail.com>
	<AANLkTikN8VZetbFJOhbidhByp0kR2cOYc77Ro1g1mMqc@mail.gmail.com>
	<AANLkTik3+8sRGuZA9xzWOxLW=7hQoB3UhYYQRxLa_rih@mail.gmail.com>
 <AANLkTikgCt7PqHKG81uB3XmF4FRtBY5D54NcT-zut56q@mail.gmail.com>
In-Reply-To: <AANLkTikgCt7PqHKG81uB3XmF4FRtBY5D54NcT-zut56q@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

On 9/13/10 8:37 AM, Joseph Ottinger wrote:
> On Mon, Sep 13, 2010 at 8:29 AM, Thomas M�ller <thomas.mueller@day.com>wrote:
> 
>> Hi,
>>
>>> Well, I want to use a FileSystem which is configured via Spring
>>
>> What is your use case? Why do you want to use a FileSystem which is
>> configured via Spring? Why do you need to use your own FileSystem
>> implementation?
>>
>> My use case is that I have a distributed datastore (persistent IMDG) and I
> don't want the speed problems an RDMS has (plus, I don't want to run a DB at
> all.) Plus, it'd be fun.
It sounds like you'll want to implement both a PersistenceManager and a
FileSystem. The FileSystem is used primarily to store configuration
files, both at the repository level and per-workspace.

The PersistenceManager is what actually stores the node and property data.

In terms of wiring these via Spring, the problem I see with this is that
Jackrabbit needs to be able to create newly configured FileSystem and
PersistenceManager instances per workspace, i.e. what's in the
repository.xml is merely a template which Jackrabbit populates with the
appropriate substitution variables when a new workspace is needed.

Your best bet is probably to expose your ApplicationContext as a
Singleton, create some facade implementations of the FileSystem and
PersistenceManager interfaces and then using the Singleton in the init()
methods of those facade implementations to look up component factories
from Spring and then use those component factories to get a
workspace-specific instance of File System or PersistenceManager. This
is probably less code than it sounds like.

Justin

> 
> As far as why configured via Spring: primarily transaction propagation. It's
> also to centralize configuration.
> 
> I have to say that I'm not sure if I should be using a FileSystem or a
> PersistenceManager. I went with FileSystem because that's what the
> repository configuration specified first, and that seemed like the first
> logical thing to get rid of (and locate in the IMDG.)
> 
> 
> 
>>> When is JackRabbit 3 likely to be finalized?
>>
>> I'm afraid it will take quite a while until it contains as much
>> features as the current Jackrabbit.
>>
>> *nod* Well, I look forward to it, then - but I would rather work on
> something other than vaporware. If it's not "near completion" then I don't
> want to postpone development for it.
> 
> 
>>> How will it manage data storage?
>>
>> That's not yet completely decided. Most likely it will have less
>> storage components. Possibly everything will be stored in one place by
>> default. That means no external / separate data store, no Lucene index
>> (again, by default), no configuration file, and no FileSystem or
>> similar mechanism. Everything stored in one (SQL- or NoSQL-) storage.
>> My guess is that the first storage implementation will be JDBC.
>>
>>
> If you want NoSQL help, let me know. :)
> 
> 
>>> Can I see it now?
>>
>> What we have is a prototype I wrote a while ago, but it's far from
>> being usable or complete. Unfortunately I didn't have time to work on
>> it for quite some time now:
>> http://wiki.apache.org/jackrabbit/MicroKernelPrototype
>>
>>> Is it documented? (If it is, that's a first for JCR... :)
>>
>> In my view, the JCR specification is well written. Jackrabbit
>> documentation is here: http://wiki.apache.org/jackrabbit/FrontPage -
>> if anything is missing please let us know
>>
>> I've found the specification to be all right, but the references on USING
> the specification tend to be sparse.
> 
> In other words, it satisfies the language lawyers, but not the users. (In MY
> experience. I'm sure other users have fewer issues.)
> 
>