Adding a mix:versionable mixin implies a ConcurrentModificationException

[napartar]

Just following with the integration of modeshape into my application, I go on testing the federation example and adding some custom features to that test case. The basic test case creates a repository from an existing file system an checks the nodes are properly created. Now, what I want to do is to add my custom versionable file nodes. That's the code I've tried out:

public void createOwnNode() {
    try {

        Node folder = session.getNode("/rootFolder/files");

        Assert.assertFalse(session.itemExists("/rootFolder/files/test.xml"));

        // Add xml file node
        Node fileNode = folder.addNode("test.xml", "nt:file");

        // Commenting this line solves the problem!!
        fileNode.addMixin("mix:versionable");

        Node resNode = fileNode.addNode("jcr:content", "nt:resource");

        resNode.setProperty(
                "jcr:data",
                session.getValueFactory().createBinary(
                        ClassLoader.getSystemResource("test.xml")
                                .openStream()));
        session.save();

    } catch (Exception e) {
        e.printStackTrace();
        Assert.fail();
    }
}

After creating the repo, I just add a file node with my own content. Adding the mix:versionable mixin provokes an exception to be thrown when session.save() gets called. That however doesn't happen if the mixin is not added:

javax.jcr.RepositoryException: java.util.ConcurrentModificationException
    at org.modeshape.jcr.JcrSession.save(JcrSession.java:1162)
    at org.modeshape.example.federation.ModeShapeExampleTest.createOwnNode(ModeShapeExampleTest.java:154)
    at org.modeshape.example.federation.ModeShapeExampleTest.test(ModeShapeExampleTest.java:250)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
    at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
    at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
    at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
    at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: java.util.ConcurrentModificationException
    at java.util.HashMap$HashIterator.nextEntry(HashMap.java:894)
    at java.util.HashMap$ValueIterator.next(HashMap.java:922)
    at org.modeshape.jcr.cache.document.WritableSessionCache.runPreSaveBeforeTransaction(WritableSessionCache.java:534)
    at org.modeshape.jcr.cache.document.WritableSessionCache.save(WritableSessionCache.java:596)
    at org.modeshape.jcr.JcrSession.save(JcrSession.java:1145)
    ... 27 more

Why could it be happening? I've forked the examples showcase, edited it and uploaded this test case to my own fork at GitHub. Any help will be greatly appreciated!

[hchiorean]

mix:versionable (and therefore versionable nodes) is not allowed for nodes stored outside the repository (i.e. via a connector). The exception is a side-effect of this. We'll have a better looking exception for 4.0 (see [MODE-2147] External nodes should not allow mix:versionable - JBoss Issue Tracker)

[napartar]

Ok, thanks for the response Horia,

Will be possible then to do that when 4.0 available? Or 4.0 will just throw a custom exception when trying it?

Apart from that is it possible to perform full text search for nodes that reference external content (for metadata and content itself)?

[rhauch]

I've corrected the title of [MODE-2147] External nodes should not allow mix:versionable, so in 4.0 there will be an exception with meaning message should any clients add the mixin to their nodes. Note that this exception is a form of validation, and like other validation-related exceptions it may be thrown only upon save.

We have on our roadmap the ability to enhance the connector SPI to make use of native versioning support in the external source (MODE-1188), but that is a ways off and lower priority than many other things. It is currently targeted to 4.1, but I would not be surprised if it gets pushed to a later release.