I'm running the 2.9 dev release. For the last couple of days I've been playing with the JCR API from within the same JVM as Alfresco.
I was unsure from existing documentation on a few questions:
- what's the point of jcrModel.xml?
- do I need to define my own content model to use JCR?
- can I put an nt:file into a cm:folder? would i want to?
- can other people edit a resource via JCR if Alfresco thinks I have it locked?
Here is a summary of what I've found (by experimentation, rather than reading the org.alfresco.jcr source) . Maybe someone might find it useful. But I'd also appreciate it if the Alfresco folks could correct any misconceptions.
1. Following http://issues.alfresco.com/browse/AR-659, I've found that you can add mixin:versionable to a node, provided you add cm:versionable first.
getMixinNodeTypes() shows that what this actually does is add a mixin named cm:versionable. The mixin nodetypes I found on a cm:content node included cm:auditable, sys:referenceable, cm:lockable, cm:versionable. This is consistent with the definition of jcr:mixinTypes in jcrModel.xml. (But jcrModel.xml is not really relevant, given that this is a cm:content node.)
The JCR properties include jcr:lockIsDeep, jcr
rimaryType, and jcr:lockOwner. These are not Alfresco node properties as such (and hence don't need to be defined in the model for cm:content) - they are sort of maintained in parallel.
Each Alfresco property on the cm:content node is also represented as a JCR property name with the same QName (eg cm:creator)
So you can think of JCR in Alfresco as just a few extra semantics added to plain old Alfresco nodes.
2. You don't need to define your own content model to use JCR.
But you will need to if you want to add properties with names you have invented (otherwise getPropertyDefinition() in org.alfresco.jcr.item.PropertyImpl returns null)
3. But what is the relevance of jcrContentModel.xml? If you add a new node using something like addNode("myNewNode", "cm:content" ), it will be a cm:content node. Is jcrContentModel.xml used internally (to do what?)?
From a 3rd party dev point of view, the value of jcrContentModel.xml:
(i) it is what lets you put an nt:file or nt:folder in a cm:folder (because nt:base inherits from sys:base). (But if you do this, your object won't show up in the Alfresco web client end user view - even if you use cm:, as in: addNode("cm:myNewFolder", "nt:folder"). It will show up in the admin node browser is any case though.)
(ii) it can be used when migrating content models from other JCR implementations. If you are lucky (and haven't invented your own property names), you might not even need to provide Alfresco with a content model definition. But if you do need to, and it uses nt:file etc, then you can import Alfresco's jcrModel.xml into your model.
4. As per http://issues.alfresco.com/browse/AR-659, when you checkin a node, it becomes locked - to the person who checked it in. This sounds worrying:- Checked in does mean read only (in JCR speak), but that shouldn't mean somebody else (call them person 2) can't check it out (either via the Alfresco web client, or JCR).
Happily though (from the perspective of someone working with JCR), even though person 1 has a lock, person 2 can check it out using JCR, modify it, then check it in! After doing this, person 2 is the lockOwner of the READ_ONLY_LOCK.
cheers
Jason
I was unsure from existing documentation on a few questions:
- what's the point of jcrModel.xml?
- do I need to define my own content model to use JCR?
- can I put an nt:file into a cm:folder? would i want to?
- can other people edit a resource via JCR if Alfresco thinks I have it locked?
Here is a summary of what I've found (by experimentation, rather than reading the org.alfresco.jcr source) . Maybe someone might find it useful. But I'd also appreciate it if the Alfresco folks could correct any misconceptions.
1. Following http://issues.alfresco.com/browse/AR-659, I've found that you can add mixin:versionable to a node, provided you add cm:versionable first.
getMixinNodeTypes() shows that what this actually does is add a mixin named cm:versionable. The mixin nodetypes I found on a cm:content node included cm:auditable, sys:referenceable, cm:lockable, cm:versionable. This is consistent with the definition of jcr:mixinTypes in jcrModel.xml. (But jcrModel.xml is not really relevant, given that this is a cm:content node.)
The JCR properties include jcr:lockIsDeep, jcr
rimaryType, and jcr:lockOwner. These are not Alfresco node properties as such (and hence don't need to be defined in the model for cm:content) - they are sort of maintained in parallel. Each Alfresco property on the cm:content node is also represented as a JCR property name with the same QName (eg cm:creator)
So you can think of JCR in Alfresco as just a few extra semantics added to plain old Alfresco nodes.
2. You don't need to define your own content model to use JCR.
But you will need to if you want to add properties with names you have invented (otherwise getPropertyDefinition() in org.alfresco.jcr.item.PropertyImpl returns null)
3. But what is the relevance of jcrContentModel.xml? If you add a new node using something like addNode("myNewNode", "cm:content" ), it will be a cm:content node. Is jcrContentModel.xml used internally (to do what?)?
From a 3rd party dev point of view, the value of jcrContentModel.xml:
(i) it is what lets you put an nt:file or nt:folder in a cm:folder (because nt:base inherits from sys:base). (But if you do this, your object won't show up in the Alfresco web client end user view - even if you use cm:, as in: addNode("cm:myNewFolder", "nt:folder"). It will show up in the admin node browser is any case though.)
(ii) it can be used when migrating content models from other JCR implementations. If you are lucky (and haven't invented your own property names), you might not even need to provide Alfresco with a content model definition. But if you do need to, and it uses nt:file etc, then you can import Alfresco's jcrModel.xml into your model.
4. As per http://issues.alfresco.com/browse/AR-659, when you checkin a node, it becomes locked - to the person who checked it in. This sounds worrying:- Checked in does mean read only (in JCR speak), but that shouldn't mean somebody else (call them person 2) can't check it out (either via the Alfresco web client, or JCR).
Happily though (from the perspective of someone working with JCR), even though person 1 has a lock, person 2 can check it out using JCR, modify it, then check it in! After doing this, person 2 is the lockOwner of the READ_ONLY_LOCK.
cheers
Jason
