Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[corona-dev] FW: Corona Collaboration Context to JCR Mapping - correction on red

 

 

From: Kalka, Edyta
Sent: Friday, November 10, 2006 9:09 AM
Subject: Corona Collaboration Context to JCR Mapping - correction on red

 

 

We are investigating the use of Jackrabbit a JCR (JSR-170) compliant repository as a repository for holding items associated with a Collaboration Context.  These are questions I had while I was reading through the JCR specification.  I apologize for the random nature.

 

Should we revamp the existing Corona Repository Interface to be a subset of the JCR API?  The current Corona Repository Interface is very simple but not very powerful. 

Is the session interface and workspace interface general enough to replace Repository Interface

 

The JCR Session Api looks similar:

getRepository

getItem

itemExists

 

Should  we just expose the JCR Session interface and the Workspace interface using the Corona SOA support as web services?

 

 

 

It is true that JCR api is similar to our repository interface but I would not go into direct exposing subset of JCR interfaces instead of corona-specific repository interfaces.

Why would we want some façade?

1.       Let’s say we expose JCR methods like getItem or getNodeByUUID instead of our specific resource getters. In such case some client will receive instance of javax.jcr.Item or javax.jcr.Node – not too convenient. Client would have to take the effort needed to recognize what type of node he received (node.isNodeType), what properties such node has (node.hasProperty) etc.

2.       In some cases it would be better to expose some “more corse-grained” services e.g. openRepositoryWorkspace that will cover set of steps needed (e.g. if workspace doesn’t exist, create new one, establish new session, create initial node set etc.).

3.       We should have some mapping layer between JCR nodes and our specific object (Sandro mentioned that in his email). In our initial corona-jackrabbit approach I created some DTOs like document, directory but it would be better to use more generic mapping framework. Such specific object should be exposed externally instead of jcr nodes.

 

 

It looks like there can be an almost direct mapping from Eclipse objects to JCR objects:

            Eclipse Workspace   è JCR Workspace

            Eclipse Projects è        ??? JCR Nodes - node

            Eclipse Folders  è JCR Nodes

            Eclipse Resource è JCR Property (PropertyType.BINARY) – node with property content

 

How should we handle a ContextContainer – should we store it in the JCR Jackrabbit repository?  Review section 5.4 of JCR Spec (jsr170-1.0.pdf)

 

            ContextContainer è JCR Workspace – why not node? Nodes can be copied, cloned, referenced – might be useful.

            RepositoryDescriptor è JCR Node (with name Property)

            RepositoryConfigurations è JCR Node

            RepositoryConfiguration è JCR Node

            RepositoryConnection è JCR Node

            RepositoryConnectionParameters è JCR Node

            RepositoryConnectionParameter è JCR Property – node with properties name, value

            RelatedContainers è JCR Node???

            RelatedContainerUri è JCR Reference Property (section 4.9.1.2) – we might not need that if we use referenceable nodes.

 

Jackrabbit is JCR level 2 compliant how well does it support Workspace versioning? To check

Can we take advantage of Workspace versioning to help synchronizing Cached Context Container and Server Context Container? To check

 

Should we change the Repository Interface to closely match the Eclipse and wrap the JCR API’s to fit into the Eclipse API’s?

org.eclipse.core.resources.IFile;

org.eclipse.core.resources.IFolder;

org.eclipse.core.resources.IProject;

org.eclipse.core.resources.IProjectNature;

rg.eclipse.core.resources.IResource;

org.eclipse.core.resources.IResourceChangeEvent;

org.eclipse.core.resources.IResourceDelta;

 

I would not try to match Eclipse interfaces.

 

JCR allows Nodes in one Workspace to reference nodes in another Workspace does it make sense to create multiple projections of the documents contained in the Repository.

 

Don’t understand the question.

 

The idea is to create “physical” layout Workspace for the documents perhaps by document type.

Then define Workspace based upon defined roles that reference nodes in the “physical” Workspace

For example, we could create specific Workspaces for people with the roles: Analyst, Architect, Developer, Tester, Operations (Deployment)

Each Workspace could be tailored to fit the role.

Perhaps the Role-base Workspace could be dynamically modified by monitoring items accessed/changed by people in difference roles

 

Please clarify this issue.

 

Edyta

 

 

 

           

The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.

Back to the top