Some more info on suggested binary
resource storage and jackrabbit versioning.
Example of binary resoure storage:
public Node importFile (Node folderNode, File file, String mimeType,
String encoding) throws RepositoryException, IOException
{
//create the file node - see section 6.7.22.6 of the spec
Node fileNode = folderNode.addNode (file.getName (), "nt:file");
//create the mandatory child node - jcr:content
Node resNode = fileNode.addNode ("jcr:content", "nt:resource");
resNode.setProperty ("jcr:mimeType", mimeType);
resNode.setProperty ("jcr:encoding", encoding);
resNode.setProperty ("jcr:data", new FileInputStream (file));
Calendar lastModified = Calendar.getInstance ();
lastModified.setTimeInMillis (file.lastModified ());
resNode.setProperty ("jcr:lastModified", lastModified);
return fileNode;
}
Example of jackrabbit versioning basics:
public void versioningBasics (Node parentNode, Session session) throws RepositoryException
{
//create versionable node
Node n = parentNode.addNode("childNode", "nt:unstructured");
n.addMixin("mix:versionable");
n.setProperty("anyProperty", "Blah");
session.save();
Version firstVersion = n.checkin();
//add new version
Node child = parentNode.getNode("childNode");
child.checkout();
child.setProperty("anyProperty", "Blah2");
session.save();
child.checkin();
//print version history
VersionHistory history = child.getVersionHistory();
for (VersionIterator it = history.getAllVersions(); it.hasNext();) {
Version version = (Version) it.next();
System.out.println(version.getCreated().getTime());
}
//restoring old version
child.checkout();
child.restore(firstVersion, true);
}
From:
corona-dev-bounces@xxxxxxxxxxx [mailto:corona-dev-bounces@xxxxxxxxxxx] On Behalf Of Everitt, Glenn
Sent: 11 listopada 2006 00:13
To: Corona
development
Subject: [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.
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.