| [corona-dev] JCR / Jackrabbit Integration Issues |
|
Edyta sent me an email with some questions
that turned into an entire conversation that should be shared with others
working on From: Everitt, Glenn I added comments marked with * Glenn Everitt From: Everitt, Glenn A few questions: Can we add optional
property for icon to corona:document ? Yes. Isn’t corona:typecode
redundant with mime type? So far property: jcr:mimeType is only added
to corona:content node (node storing binary content) – rest of nodes like
directory, document don’t have such property. Typecode was to store the code of
system-recognizable node type – this can be exchanged with mimeType if we
are sure mimeType will be good identification of each node content (including
directory)? * I understand now, I don’t think it
is redundant and we should keep it although it seems like there should already
a be jcr:xxxxx defined for these. Should we add a “user note”
property on a document similar to jLibrary – so user can put an
additional note about a document. Since we are not planning on hold the
users in Jackrabbit we will just have to use the member url instead of a
REFERENCE to a user node. http://jlibrary.sourceforge.net/6/hierarchy.html I wasn’t sure if we need notes or not.
Adding this is not a problem. Question: do we want note as string
property or as separate node with properties such as: memberUrl, noteMessage,
creationDate etc.? * I like you’re approach of adding
new Note Node with additional properties. corona:path – I’m not sure I understand
what this is for. javax.jcr.Node contains getPath method
– this returns jcr path e.g.: “/corona:root/TestJackrabbitDirectory%5b2%5d/corona.log” Our additional path property was to store
more readable form of such path e.g.:
“//TestJackrabbitDirectory[2]/corona.log”. * I am worried that they will get out of
sync. One will be updated without the other being updated. Is there
a way to just provide a translation method from jcr to “simple” path?
or are they really different things: jcr path is logical path within an
individual workspace and path property is physical path on disk? Is there a way to find the revision
history of a document I see that there is a jcr:lastModified but is there a way
to get dates of when and who modified a document? JCR API enables us to retrieve information
“when” document was modified (but not “who” modified
it): //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()); }Version do not include information on
“who” but because it extends Node we could make sure to
overwrite/modify corona:creator property of new version of given node or we
could add quite new property e.g. corona:modifier. * I think I like adding a new property
corona:modifier but maybe called corona:editor ? * One other property I would like is the
corona:owner – the person responsible for the document, they may
delegate editing the document to someone else but they are responsible for the
its content. For example, a lawyer is the owner of a contract but a
legal secretary is the editor of the contract. * corona:resource
– I think this should have a corona:uri property to uniquely identify
every corona resource. * If we put the corona:uri property on
corona:resource then I think corona:document extends
corona:resource not corona:node. Maybe I am not understanding
relationship between corona:corona and corona:resources and
corona:content. I thought nt:base -> corona:corona ->
corona:node -> corona:document -> corona:content which
doesn’t seem to match your definition. You are (almost) always
right so, I am missing something. nt:base -> corona:corona ->
corona:node -> corona:directory To store node history such mixin has to be
added: “mix:versionable” – for now it is added to document
only. I suppose it should be added to each type of corona node. I think that the Corona Client code such
as the PCM should use the mime type to map to the document viewer. Should we define some set of
supported/recognized mime types? * Yes – start with items we want initially
and provide a way to register more. I think that on the Corona Server code
Indexing Programs should use the mime type to determine if the document can be
indexed. Don’t know yet much about that
– I noticed that lucene is integrated within jackrabbit. I think Tomcat uses a mime type file to
hold it mappings – I wonder if we could also use it? Default mime types mappings for tomcat are
stored inside <tomcat_home>/conf/web.xml – it is not small set of
globally supported mime type mappings but will this be enough for us in terms:
how could we describe nodes like: directory or distinguish open office
documents from others ? What would it mean if a document is
referenced in 2 different workspaces and locked only in one? Should there
be a “master” workspace? * Could you please make sure that the
jLibrary copyright noticed is maintained in the code. I added to our plugin LockUtility used by
jLibrary: /** * Utility to obtain a lock attached to a node. These locks can
be shared * between different sessions to handle synchronization and
concurrency. * A better synchronization system could be created using the
Lock facility * from the JCR specification, but that is currently out of the
scope of this * simple implementation. */ public class LockUtility { private
static HashMap locks = new
HashMap(); /** * Obtains a lock object for a
given node. As every session will use this * object to synchronize access
we can use it to handle locking and to * synchronize operations like
multiple access to the same node from * different sessions * * @param node node for which we want to obtain a lock
synchronization * object * * @return Object shared object associated with the same node
that can be * used to synchronize access to
the repository * * @throws RepositoryException if the lock object cannot be
obtained */ public
static synchronized Object obtainLock(
javax.jcr.Node node) throws
RepositoryException {
String id = node.getUUID();
Object lock = locks.get(id); if (lock == null) {
lock = new Object();
locks.put(id,lock); } return lock; } } It should be
enough to share locks between sessions/workspaces. According to
“master” workspace – we already have “system”
workspace. http://wiki.apache.org/jackrabbit/nt:resource
- note to myself about mime type character encoding Edyta From: Everitt, Glenn A few questions: Can we add optional
property for icon to corona:document ? Isn’t corona:typecode
redundant with mime type? Should we add a “user note”
property on a document similar to jLibrary – so user can put an
additional note about a document. Since we are not planning on hold the
users in Jackrabbit we will just have to use the member url instead of a
REFERENCE to a user node. http://jlibrary.sourceforge.net/6/hierarchy.html corona:path – I’m not sure I understand
what this is for. Is there a way to find the revision
history of a document I see that there is a jcr:lastModified but is there a way
to get dates of when and who modified a document? I think that the Corona Client code such
as the PCM should use the mime type to map to the document viewer. I think that on the Corona Server code
Indexing Programs should use the mime type to determine if the document can be
indexed. I think Tomcat uses a mime type file to
hold it mappings – I wonder if we could also use it? What would it mean if a document is
referenced in 2 different workspaces and locked only in one? Should there
be a “master” workspace? http://wiki.apache.org/jackrabbit/nt:resource
- note to myself about mime type character encoding From: CNT file with comments (red): <nt =
"http://www.jcp.org/jcr/nt/1.0"> <mix =
"http://www.jcp.org/jcr/mix/1.0"> <corona =
"http://www.eclipse.org/corona"> Base corona type containing name property and allowing for nested
nodes (children) of the same type: [corona:corona] orderable mixin - corona:name
(string) // name property, not required + corona:corona
(nt:base) multiple // allowed nested
nodes of the same type [corona:node] >
corona:corona orderable mixin - corona:lockUser
(string) // property containing id of
user that locked given node - mix:lockToken
(string) // lock token - corona:size (long)
mandatory // document size - corona:position
(long) mandatory // document position
– might be not needed - corona:path
(string) mandatory // document path -
shows location in a tree node e.g. //testDirectory/testDocument.txt - corona:created
(date) mandatory // when node was added - corona:typecode
(long) mandatory // document type code:
TEXT – 0, XML – 1, ZIP – 2, FOLDER - 3 - corona:creator
(string) mandatory // document creator
– user name - corona:description
(string) mandatory // description [corona:resource] >
corona:node orderable mixin [corona:directory] >
corona:node orderable mixin + corona:resource
(nt:base) multiple // allowed nested
nodes of the resource type + corona:document
(nt:base) multiple // allowed nested
nodes of the document type + corona:directory
(nt:base) multiple // allowed nested
nodes of the directory type [corona:document] >
corona:node orderable mixin - corona:resources
(reference) mandatory multiple //
references to corona:resource nodes – might be not needed - corona:url (string)
// document url - corona:creationDate
(date) mandatory // document creation
date - corona:language
(string) mandatory // document language + corona:content
(nt:base) multiple // allowed nested
nodes of the content type [corona:content] >
corona:corona orderable mixin Binary content is stored with use of jcr properties like jcr:data,
jcr:mimeType, jcr:encoding etc. |