SystemView Import and UUID
I am trying to do a SystemView Import, and have a UUID created if the node does not already exist. I use an XSLT to x-form my XML into the proper SystemView, and include a node for jcr:uuid. If this value is empty, the JCR throws an exception. If I remove the jcr:uuid node, the JCR imports the XML without Exception. My problem is that I don't want to maintain 2 XSLT's or have to post process the XML to remove the jcr:uuid node. Is there any way to import XML with the following jcr:uuid node value in the imported XML? sv:property sv:name=jcr:uuid sv:type=String sv:value/ /sv:property -- View this message in context: http://www.nabble.com/SystemView-Import-and-UUID-tf4102939.html#a11667706 Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Re: [jira] Commented: (JCR-388) add support for RFC 3253 to the simple server
Angela Schreiber wrote: but that's a different story isn't it? i was talking about the compliance class (and the method set). Probably. I just wanted to make sure that no time is spent on something that is broken in the spec... RFC 3253 defines a separate behaviour for version-controlled collections. I'm not completely sure what the issue is? A version controlled collection is a specific type of a regular version controlled resource, it just also records information about version controlled children... what i meant: http://www.webdav.org/deltav/protocol/rfc3253.html#version-controlled-collection.feature states the following: As with any versionable resource, when a collection is put under version control, a version history resource is created to contain versions for that version-controlled collection. In order to preserve standard versioning semantics (a version of a collection should not be modifiable), a collection version only records information about the version-controlled bindings of that collection. In order to cleanly separate a modification to the namespace from a modification to content or dead properties, a version of a collection has no members, but instead records in its DAV:version-controlled-binding-set property the binding name and version history resource of each version-controlled internal member of that collection. [...] A version-controlled collection has all the properties of a collection and of a version-controlled resource. In addition, the version-controlled-collection feature introduces the following REQUIRED property for a version-controlled collection. 14.1.1 DAV:eclipsed-set (computed) [...] Clarifying: the difference between a collection and a non-collection with respect to WebDAV versioning is that the version-controlled state of a collection *additionally* includes the binding-set (for the members), but not the members itself. however: the patch provided by jeremi and modified by rob does not distinguish between collections and non-collection resources. in both cases the underlying repository Node is made 'versionable'. consequently both collections and non-collections behave the same way (i.e. like version-controlled resources), which is from my understanding not what the RFC defines. see quote above. do i miss something? Hm, probably I'm partly confused because I've grown up with RFC3253 semantics, and haven't used collection versioning in JCR so far (the system I currently work on only can version leaf files + properties). It seems the counterpart of a version controlled collection in WebDAV would be a JCR node where all children have OnParentVersionAction=IGNORE, meaning they are always version-controlled independently of the parent. I'm not sure whether anything else can be exposed in a RCF3253 compliant way. We may have to ask Geoff for advice :-). Best regards, Julian
[jira] Commented: (JCR-537) Failure to remove a versionable node
[ https://issues.apache.org/jira/browse/JCR-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513577 ] Shane Preater commented on JCR-537: --- I am also seeing this error when trying to remove the version mixin from a node. Failure to remove a versionable node Key: JCR-537 URL: https://issues.apache.org/jira/browse/JCR-537 Project: Jackrabbit Issue Type: Bug Components: versioning Affects Versions: 1.1 Reporter: Florent Guillaume Assignee: Tobias Bocanegra Attachments: var.tgz This happens on current trunk. When running the following code on the attached jackrabbit repository, (sorry, Jython code, I trust the conversion to Java is trivial): from javax.jcr import SimpleCredentials from org.apache.jackrabbit.core import TransientRepository uuid = 83f6e473-3fe2-4584-9570-4e18a0cd6688 repoconf = var/jackrabbit.xml repopath = var/jackrabbit credentials = SimpleCredentials(username, password) repository = TransientRepository(repoconf, repopath) session = repository.login(credentials, default) root = session.getRootNode() node = session.getNodeByUUID(uuid) node.remove() root.save() I get the following error: org.apache.jackrabbit.core.state.NoSuchItemStateException: c147b847-8ba5-4fe9-a890-481586476510 at org.apache.jackrabbit.core.state.SharedItemStateManager.getNodeReferences(SharedItemStateManager.java:307) at org.apache.jackrabbit.core.state.SharedItemStateManager.updateReferences(SharedItemStateManager.java:1046) at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:484) at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:687) at org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:717) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:316) at org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:323) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:292) at org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:258) at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1209) ... javax.jcr.RepositoryException: javax.jcr.RepositoryException: /: unable to update item.: c147b847-8ba5-4fe9-a890-481586476510: c147b847-8ba5-4fe9-a890-481586476510 The uuid I'm trying to delete is that of a document at path /workspaces/ecm:children/subfolder/ecm:children/ghtgh The uuid mentioned in the error is the one of its version history. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (JCR-388) add support for RFC 3253 to the simple server
hi Clarifying: the difference between a collection and a non-collection with respect to WebDAV versioning is that the version-controlled state of a collection *additionally* includes the binding-set (for the members), but not the members itself. jup... and that's currently missing. Hm, probably I'm partly confused because I've grown up with RFC3253 semantics, and haven't used collection versioning in JCR so far (the system I currently work on only can version leaf files + properties). It seems the counterpart of a version controlled collection in WebDAV would be a JCR node where all children have OnParentVersionAction=IGNORE, meaning they are always version-controlled independently of the parent. I'm not sure whether anything else can be exposed in a RCF3253 compliant way. here we go. the simple-server currently leaves it to the configuration to decide which nodes are collections and which are not. potentially any of them can be made versionable in jcr (and currently in dav as well). i don't see a smart solution up to know. a simple one would probably be to ignore the versioning stuff for the collections at all only allow non-collections to be version-controlled resources. disregarding whether the underlying node is mix:versionable or not. leading to the question: will it cause problems if the dav-client can 'see' dav VersionHistoryResources and VersionResources that don't have a corresponding versionable dav resource? or would that be an negligible inconsistency? angela
Re: [jira] Commented: (JCR-388) add support for RFC 3253 to the simple server
Angela Schreiber wrote: ... leading to the question: will it cause problems if the dav-client can 'see' dav VersionHistoryResources and VersionResources that don't have a corresponding versionable dav resource? or would that be an negligible inconsistency? ... That shouldn't be a problem, because it could also be cause of the VCR being removed, while versioning information was preserved. Best regards, Julian
