Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: domain of ap-cocoon-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: dev@cocoon.apache.org
From: Andreas Hartmann <andreas@apache.org>
Subject: Re: [jcr] Scope of JCRNodeSource
Date: Fri, 22 Jul 2005 14:20:08 +0200
Lines: 116
Message-ID: <dbqo9o$d8c$1@sea.gmane.org>
References: <dbqhf0$q7r$1@sea.gmane.org> <42E0CEFF.3020401@anyware-tech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206)
In-Reply-To: <42E0CEFF.3020401@anyware-tech.com>
Sender: news <news@sea.gmane.org>

C�dric Damioli wrote:
> Hi Andreas,
> 
> This block is really in an very early stage of development.
> In the actually committed version, it does not work as expected.

Yesterday I configured Lenya to use the JCRSourceFactory to generate
sources for storing content - it works fine :)

Maybe a short introduction: In Lenya, we're planning to support JCR
repositories for quite a long time now. But we want to leverage Cocoon
components, if available, instead of implementing our own ones. That's
why I'm interested in extending the JCR block to our needs.

Basically we need the following functionality:

   - content storage (XML and binary data)
   - properties (meta data)
   - locking
   - versioning
   - transactions

We can't afford to switch to JCR in one step, that's why it would probably
help us to have a set of generic repository Source interfaces (like the
JCR block), which would be implemented by the JCRNodeSource and by our
own sources (using the Lenya revision controller, locking mechanism etc.).

That would allow us to support both our existing repository access mechanism
and the JCRSourceFactory:

   - interface         o.a.cocoon.RepositorySource (locking, versioning, etc.)
     - implementation  o.a.cocoon.JCRNodeSource
     - implementation  o.a.lenya.LenyaRepositorySource

If the JCRNodeSource doesn't implement generic interfaces, we need another
layer in Lenya to provide this abstraction:

   - interface         o.a.lenya.LenyaSource (locking, versioning, etc.)
     - implementation  o.a.lenya.LenyaRepoSource
     - implementation  o.a.lenya.LenyaJCRSourceImpl

The LenyaJCRSourceImpl would resolve a JCRNodeSource and use its
functionality.

[...]

>> 1) IIUC, every time a source is resolved a new JCR session is created.
>>    Does this mean that no transactions can be used?
>>    Maybe it would make sense to attach the JCR session to the Cocoon
>>    session, so that all resolved JCRNodeSources save their data to a
>>    single session which would allow them to take part in a single
>>    transaction?
> 
> 
> There are many points here : some may wants to attach to the JCR Session 
> to the Servlet Session, others will want to attach JCR Session to the 
> Request (as a JDBC Connection, this is my case), others will want to 
> have one single JCR Session for the entire application.
> This IMHO must be a configurable thing.

Yes, you're right. Attaching it to the servlet session is just one example.

> Other problem is the logout one :  when called, the repository.login() 
> is made by the JCR block classes, but the logout must be made by the 
> application. But when ? I choose to implement this via Servlet's 
> RequestListeners or SessionListeners.

I'm not familiar with these concepts - would that mean that the logout
happens for instance when the session expires?

> You may also extend the 
> CocoonServlet to logout at the end of the service() method.

>> 2) How about storing additional custom properties (e.g., meta data)
>>    in the node which is represented by the source?
> 
> 
> good point :-)
> The JCRNodeSource is actually made for Nodes :-)
> This idea was to also have a JCRPropertySource. But it has never been 
> implemented.

I would be very interested in this functionality.

>>
>> 3) How about locking and versioning?
> 
> 
> Another good point.
> 
> At the begining of my JCR-related work, I wanted to have 
> VersionedSource, LockableSource, and then 
> LockableModifiableTraversableVersionableSource :-p
> And I then realized that such business logic things may overrun the goal 
> of Sources.
> So I finally simply get the JCR Node from the JCRNodeSource and directly 
> play with JCR API in my own business logic classes.

I guess we have to use the same approach in Lenya.
Maybe it really isn't necessary to mimic the JCR Node functionality
in the source layer.

> Sylvain and I have actually had different ideas about what a JCRSource 
> must be.
> I personally thought about an entry point to every JCR Item in the 
> Repository (it appears it is what you want too)

Yes, that's what I imagined.

> Sylvain thought more about a TraversableSource with directories and 
> files (actually nt:directory and nt:file Nodes).

IIUC that wouldn't allow to leverage JCR features apart from content
storage?

-- Andreas