JCR & versioning

[anweber]

Hi,

   I have a little problem when I try to create a node with "versionable" aspect.  When I look at the created node with the webClient, I see it as checked-out (without the working node) but I want to obtain a checked-in node.

There is an extract of my code :

            Node document = folder.addNode("cm:aweTestDoc", "cm:content");
            document.setProperty("cm:name", "AWE test doc");
            document.setProperty("cm:description", "AWE test document, created with JCR");
            document.setProperty("cm:title", "AWE document");
            document.setProperty("cm:content", "xxxxxxxxxxxxx");
            document.addMixin("mix:versionable");
            
            document.checkin();
            
             session.save();
 
‍‍‍‍‍‍‍‍‍‍‍‍‍

          Thanks for your help,

                Andr

[steel]

> I am migrating some documents over from another type of repository, and would like to just create the version nodes myself rather than doing a checkin/checkout each time for the new version as I have specific version labels as well.

You might be able to use the Alfresco VersionService interface directly to create versions of a node.  I think you can set the version label too.

An alternative approach is to use the Importer to populate the version store directly.  For an example of the xml, you can perform a 'Complete Repository Export' in v1.3 and view the contents of the file 'xxx_version.acp'.

All of my operations are operating over JCR-RMI for the session transaction support so I do not have access to the versionservice nor the COCIservice.  If I use the Webservice interface along with JCR-RMI would the web service calls belong to the same JCR-RMI session transaction or would they be separate?

[steel]

The problem here is that the JCR API is following the versioning semantics of the JSR-170 specification, which are different to those exposed in the Alfresco Web Client.  When a JSR-170 node supports mix:versionable, it is locked whilst checked-in and unlocked whilst checked-out.  Essentially, you are seeing the checked-in item in the Web Client, but it's locked, which is why there's a lock icon and no associated working copy.

The workaround for Alfresco Web Client compatibility is to assign the cm:versionable aspect via the JSR-170 api, and then use the Alfresco native api calls on the COCIService to checkin/out.  This will provide the same behaviour as exhibited in the web client.

It's possible to mix JCR/Alfresco native api calls as described in http://wiki.alfresco.com/wiki/Introducing_the_Alfresco_Java_Content_Repository_API#Mixing_JCR_and_Al....

I found that doing a checkout() after the checkin() will resolve this issue. I am taking this route as I am connecting via JCR-RMI and to keep everything in the same session transaction.

[jharrop]

Hi David

The workaround for Alfresco Web Client compatibility is to assign the cm:versionable aspect via the JSR-170 api, and then use the Alfresco native api calls on the COCIService to checkin/out. This will provide the same behaviour as exhibited in the web client.

Could you please clarify your advice here?  Are you suggesting we call unlock() after a JCR checkin?

If we do that, the Alfresco JCR implementation would think the node is checked out when it isn't, since isCheckedOut() returns true if there is no lock.

I wonder whether you mean either of the following:

• use CheckOutCheckInService to check out then check in, *instead of* the JCR methods checkout() and checkin()?


• use CheckOutCheckInService to check out immediately after a JCR checkout(),  and CheckOutCheckInService to check in immediately before a JCR checkin()?

But either of these would create then delete working copies (and maybe have other side effects?).


thanks

[jharrop]

The problem here is that the JCR API is following the versioning semantics of the JSR-170 specification, which are different to those exposed in the Alfresco Web Client. When a JSR-170 node supports mix:versionable, it is locked whilst checked-in and unlocked whilst checked-out.

The JCR API is not quite following the JSR-170 specification.  In JSR 170, a node becomes read-only (as opposed to locked) on check in (see spec 8.2.5), and on check out, a node loses its read-only status (see 8.2.6).

In JSR 170, the concept of locking is orthogonal to read-only.  At 8.4.11, the spec says:

Note that it is possible to lock a node even if it is checked-in (the lock-related properties will be changed despite the checked-in status).
:
Note also that it is possible to unlock a node even if it is checked-in (the lock-related properties will be changed despite the checked-in status).