Question

Currently doing a test-app with JCR (Modeshape).

• The abstracted flow is as follows: session.open, a repository fetches on or more nodes related to a query, session.close.

• The resulting nodes contain properties, etc. that I need to present to the view. I currently have the naive setup of letting the view take properties from the jcrNode directly. However this gives an error like: “The session with an ID of ‘e2881d98-56fd-4a57-9cce-1a7d087a11e8’ has been closed”, which makes sense.

I believe the general approach (please correct if otherwise) would be to create some sort of nodeDTO which is populated by the jcrNode when the session is still active. The view is then free to use the nodeDTO however it wants.

Now, the perfect structure for such a nodeDTO would mimic the structure of the jcrNode 1-to-1 so why not use the jcrNode as the DTO itself? This would be accomplished with something akin to hibernate detach/attach. I realize that a jcrNode (with its children) can contain lots of data, so there should likely be some parameters to determine the depth of detachment, etc.

Another approach would be to have something like the openSessionInView-pattern, although this would be mvc-framework specific.

So I can see several approaches to this, best approach first (imo):

1. detach/attach functionality for jcrNodes
2. good library of helper classes to create the DTOs
3. openSessionInView

Any comments on to the ‘best-practice’ approach, etc. much appreciated.

Answer 1

Unfortunately, the JCR 2.0 specification does not define a way for the nodes to be detached from a session, so this kind of functionality would be implementation-specific.

In lieu of a JCR method, the only technique that is agnostic of a JCR implementation would be to copy the properties and child references in a very simple structure of your own creation. Yes, that structure would at a high-level be very similar to a JCR node, but it wouldn’t need to have 90% of the methods defined on Node: a simple map of properties (by name), and a list (or ordered map) of child nodes. And by doing this, your code would be responsible for copying the nodes and subgraphs you’re interested in, so you can define the semantics to suit your needs.

However, as the project lead for ModeShape, I do agree that detaching JCR nodes does seem like a good feature, and so I’ve logged it as an enhancement request in the ModeShape project. There are a lot of details to work out in terms of the proper semantics (especially relating to child or descendant nodes), so I’d invite you to watch that request and participate in the discussion on that issue.