cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cédric Damioli <>
Subject Re: [jcr] Scope of JCRNodeSource
Date Fri, 22 Jul 2005 10:48:31 GMT
Hi Andreas,

This block is really in an very early stage of development.
In the actually committed version, it does not work as expected.

Sylvain first wrote this JCRNodeSource for my own needs (I am one of his 
coworkers) and I've applied many many patches to it without contributing 
them back to Cocoon. I obviously apologize for that :-)
With this introduction beeing made, I'll try to answer your questions :

Andreas Hartmann a écrit :

> Hi Cocoon devs,
> I'm currently examining the JCR block (thanks, Sylvain, Michi and all 
> others
> who were involved!)
> Some questions:
> 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.
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. 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 

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

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)
Sylvain thought more about a TraversableSource with directories and 
files (actually nt:directory and nt:file Nodes).

I would be interested to known your usecases.


Cédric Damioli
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46

View raw message