You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Andreas Hartmann <an...@apache.org> on 2005/07/22 12:23:28 UTC
[jcr] Scope of JCRNodeSource
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?
2) How about storing additional custom properties (e.g., meta data)
in the node which is represented by the source?
3) How about locking and versioning?
I read a comment by Ugo Cei that it would make sense to drop the Cocoon
Repository block in favor of the JCR block. Does that mean that the
JCRNodeSource would be extended to provide access to JCR functionality?
Sorry if these questions have been answered before, I didn't find anything
on this list.
Thanks!
-- Andreas
Re: [jcr] Scope of JCRNodeSource
Posted by Andreas Hartmann <an...@apache.org>.
Sylvain Wallez wrote:
[...]
>> 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?
>
> Yes it makes sense! As Cedric said this stuff is fairly new, and
> currently the session management is definitely suboptimal and doesn't
> allow for transaction management.
>
> Now what should be the scope of the session? I'm not sure there is a
> single answer to this and the plan was to allow to configure the
> Repostory object with input/output modules that whould be used to
> get/store the session. Such modules would typically store the JCR
> session in a request attribute or in a servlet session attribute.
That sounds quite useful, but maybe a special service (interface)
would make more sense than an input + output module?
> And this leads to yet another problem: calling session.logout(), which
> happens at different times depending on the session scope...
>
> The solution (thinking as a type) can be to have some kind of
> JCRSessionPolicy object that would take care of getting/storing/closing
> the session.
Would that be something like this?
public Source getSource(String uri, Map parameters) ... {
JCRSessionPolicy policy = null;
try {
policy = (...) this.manager.lookup(JCRSessionPolicy.ROLE);
// policy logs in or restores JCR session from wherever
Session session = policy.getSession();
source = createSource(session, path);
// policy stores session for further use
policy.storeSession();
}
finally {
... release policy
}
}
> For now, you can simply override the login() method to manage the session!
Good idea, I'll try that.
[...]
>> I read a comment by Ugo Cei that it would make sense to drop the Cocoon
>> Repository block in favor of the JCR block. Does that mean that the
>> JCRNodeSource would be extended to provide access to JCR functionality?
>
>
>
> I'm not sure this is a good idea. The repository block defines some
> Source extensions that can be used by source implementations that wrap a
> repository (JCR, webdav, etc).
That sounds very useful and would dovetail with the Lenya repo integration
(see my other mail).
Thanks for your answer!
-- Andreas
Re: [jcr] Scope of JCRNodeSource
Posted by Sylvain Wallez <sy...@apache.org>.
Andreas Hartmann wrote:
> 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?
Yes it makes sense! As Cedric said this stuff is fairly new, and
currently the session management is definitely suboptimal and doesn't
allow for transaction management.
Now what should be the scope of the session? I'm not sure there is a
single answer to this and the plan was to allow to configure the
Repostory object with input/output modules that whould be used to
get/store the session. Such modules would typically store the JCR
session in a request attribute or in a servlet session attribute.
And this leads to yet another problem: calling session.logout(), which
happens at different times depending on the session scope...
The solution (thinking as a type) can be to have some kind of
JCRSessionPolicy object that would take care of getting/storing/closing
the session.
For now, you can simply override the login() method to manage the session!
> 2) How about storing additional custom properties (e.g., meta data)
> in the node which is represented by the source?
Could be done by having JCRSource implementing InspectableSource (in the
repository block)
> 3) How about locking and versioning?
LockableSource in the repository block :-)
There's also a VersionableSource there, but it somehow competes with the
VersionedSource I wrote for the CVSSource [1].
> I read a comment by Ugo Cei that it would make sense to drop the Cocoon
> Repository block in favor of the JCR block. Does that mean that the
> JCRNodeSource would be extended to provide access to JCR functionality?
I'm not sure this is a good idea. The repository block defines some
Source extensions that can be used by source implementations that wrap a
repository (JCR, webdav, etc).
> Sorry if these questions have been answered before, I didn't find
> anything
> on this list.
Well, there hasn't been much discussion about this :-)
Sylvain, hacking with Bertrand and Daniel at the ApacheCon :-)
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [jcr] Scope of JCRNodeSource
Posted by Michael Wechner <mi...@wyona.com>.
Cédric Damioli wrote:
>
>
> 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.
I think both ;-) In the case of Lenya one probably is more nt:directory and
nt:file oriented, but for less document oriented applications this doesn't
necessarily makes sense.
Michi
>
>
> Regards,
> Cédric
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
Re: [jcr] Scope of JCRNodeSource
Posted by Michael Wechner <mi...@wyona.com>.
Cédric Damioli wrote:
> Andreas Hartmann a écrit :
>
>> 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.
>>>
>>> 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.
>>
>>
>>
>> BTW - are you planning to provide your work to the project?
>> I'm just asking because I want to avoid doing work which has already
>> been done :)
>>
>> -- Andreas
>>
> Yes, it is in our TODO list...
> We have to fix some bugs and so on, and we will contribute our changes.
> But I'm afraid we won't have much time in the next few days to play
> with the JCR stuff...
you might want to attach the fixes to Bugzilla and someone else will
contribute them ;-)
Michi
>
>
> BTW the JCRNodeSource in itself does not do much : it is only
> Traversable and Modifiable.
> IMHO, one of its most interesting method is getNode(), which provide
> access to JCR Node :-)
>
> Regards,
> Cédric
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
Re: [jcr] Scope of JCRNodeSource
Posted by Cédric Damioli <ce...@anyware-tech.com>.
Andreas Hartmann a écrit :
> 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.
>>
>> 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.
>
>
> BTW - are you planning to provide your work to the project?
> I'm just asking because I want to avoid doing work which has already
> been done :)
>
> -- Andreas
>
Yes, it is in our TODO list...
We have to fix some bugs and so on, and we will contribute our changes.
But I'm afraid we won't have much time in the next few days to play with
the JCR stuff...
BTW the JCRNodeSource in itself does not do much : it is only
Traversable and Modifiable.
IMHO, one of its most interesting method is getNode(), which provide
access to JCR Node :-)
Regards,
Cédric
--
Cédric Damioli
Chef de projets systèmes d'informations
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com
Re: [jcr] Scope of JCRNodeSource
Posted by Andreas Hartmann <an...@apache.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.
>
> 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.
BTW - are you planning to provide your work to the project?
I'm just asking because I want to avoid doing work which has already
been done :)
-- Andreas
Re: [jcr] Scope of JCRNodeSource
Posted by Andreas Hartmann <an...@apache.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
Re: [jcr] Scope of JCRNodeSource
Posted by Cédric Damioli <ce...@anyware-tech.com>.
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
implemented.
>
> 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.
Regards,
Cédric
--
Cédric Damioli
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com