Handle mix:versionable properly

[jazeren1]

Encountered exception is as follows (on the client)

02.02.2015 22:08:07.101 [clientJobLauncherTaskExecutor-3] com.twcable.grabbit.client.batch.steps.jcrnodes.JcrNodesWriter *INFO* Encountered invalid mixin type while unmarshalling for Proto values : value {
  stringValue: "mix:versionable"
}

02.02.2015 22:08:07.102 [clientJobLauncherTaskExecutor-3] com.twcable.grabbit.client.batch.steps.jcrnodes.JcrNodesWriter *INFO* Encountered invalid mixin type while unmarshalling for Proto values : value {
  stringValue: "mix:lockable"
}

02.02.2015 22:08:07.103 [clientJobLauncherTaskExecutor-3] com.twcable.grabbit.client.batch.steps.jcrnodes.JcrNodesWriter *ERROR* Exception writing JCR Nodes to current JCR Session : session-admin-334713.  javax.jcr.version.VersionException: Unable to perform operation. Node is checked-in.
    at org.apache.jackrabbit.core.ItemValidator.checkCondition(ItemValidator.java:284)
    at org.apache.jackrabbit.core.ItemValidator.checkModify(ItemValidator.java:248)

For starters, may be look at how filevault does it : https://github.com/apache/jackrabbit-filevault/blob/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/ImportInfoImpl.java#L228-L234 (using node.checkIn() )

[jdigger]

Suspect this is highly related to GH-96 and GH-65

[viveksachdeva]

@jazeren1 @jdigger : Are there some specific steps to reproduce this issue...I tried copying nodes with mixins lockable and versionable and I did not get any error..

[jbornemann]

@jazeren1 @jdigger @viveksachdeva I think this has more to do with us not properly handling mix:versionable SCM type features properly.

My presumption for the above example is that we are attempting to write to a version of a node that is checked-in, thus read-only. https://docs.adobe.com/content/docs/en/spec/jcr/2.0/15_Versioning.html For more info

In these cases I don't know if we want to sync node history instead, or what. If so, we would have to implement weak/strong links first

[sagarsane]

I think we actually fixed this issue when we changed how mixins are a. transmitted from Grabbit thought to Grabbit destination and b. how mixins are written out to the JCR (not using "addNode" but using "addMixin" instead before checking if you "canAddMixin" ) ..

We definitely don't copy over the version history.

[jdigger]

@viveksachdeva Can you please verify @sagarsane's assumption? Hopefully we can just close this.

[viveksachdeva]

@sagarsane, @jdigger : Looking at the logs above, it seems that this was/is happening even after handling the mixins differently. Moreover, one of the cases in which canAddMixin method returns false is when node is already checked in... I think we should have an additional check to check out node(if not already checked out) and then do mixin addition part..

[sagarsane]

Ah ok. I see. Yeah if you already have a failing case for this and a possible approach for solution, I think that makes sense.