8 Replies Latest reply on Oct 8, 2014 6:05 AM by rstachowiak

    JQOM problems with expanded names and problem with removing mixin

    rstachowiak

      Hi all

       

      I am trying to use Modeshape in an application that already works with Jackrabbit, but I have encountered two problems.

       

      1. Why Modeshape doesn't support expanded names in JQOM? If I read the specification correctly, this is in violation of point 3.2.6 of the specification. This is a problem to me, because JCR API only defines constants with expanded names (except nt:versionLabels, which is missing altogether) and Jackrabbit supports expanded names in JQOM happily.

      Relevant part of stacktrace:

      Caused by: javax.jcr.query.InvalidQueryException: Table '{http://www.jcp.org/jcr/nt/1.0}unstructured' does not exist.

      Table 'parent' does not exist.

      Table 'parent' does not exist.

      Column '{http://www.jcp.org/jcr/1.0}primaryType' does not exist on the table 'npe'

       

          at org.modeshape.jcr.query.JcrAbstractQuery.checkForProblems(JcrAbstractQuery.java:109)

          at org.modeshape.jcr.query.JcrQuery.execute(JcrQuery.java:123)

          at org.modeshape.jcr.query.JcrQuery.execute(JcrQuery.java:43)

      :

       

      2. When I try to remove mix:lastModified from a node that has this mixin added (node.isNodeType(NodeType.MIX_LAST_MODIFIED) returns true) I get an exception (irrelevant parts of stacktrace ommited, this is for Modeshape 4.0.0):

      Caused by: javax.jcr.nodetype.ConstraintViolationException: Cannot find a definition for the property named 'jcr:lastModifiedBy' on the node at '{some path}' with primary type '{my type}' and mixin types: []

          at org.modeshape.jcr.AbstractJcrNode.removeMixin(AbstractJcrNode.java:2594)

          (...)

         Why is it failing?

      3. I am also getting a NullPointerException from Modeshape in a lock cleaning thread.  Stacktrace is as follows:

      14:32:54.899 ERROR org.modeshape.jcr.RepositoryLockManager - Error while cleaning up locks for the "Test Repository" repository

      java.lang.NullPointerException: null

          at org.modeshape.jcr.SystemContent.systemKey(SystemContent.java:133) ~[modeshape-jcr-4.0.0.Final.jar:4.0.0.Final]

          at org.modeshape.jcr.SystemContent.systemNode(SystemContent.java:190) ~[modeshape-jcr-4.0.0.Final.jar:4.0.0.Final]

          at org.modeshape.jcr.SystemContent.locksKey(SystemContent.java:172) ~[modeshape-jcr-4.0.0.Final.jar:4.0.0.Final]

          at org.modeshape.jcr.SystemContent.mutableLocksNode(SystemContent.java:226) ~[modeshape-jcr-4.0.0.Final.jar:4.0.0.Final]

          at org.modeshape.jcr.RepositoryLockManager.cleanupLocks(RepositoryLockManager.java:133) ~[modeshape-jcr-4.0.0.Final.jar:4.0.0.Final]

          at org.modeshape.jcr.JcrRepository$RunningState.cleanUpLocks(JcrRepository.java:1814) [modeshape-jcr-4.0.0.Final.jar:4.0.0.Final]

          at org.modeshape.jcr.JcrRepository$LockGarbageCollectionTask.doRun(JcrRepository.java:2012) [modeshape-jcr-4.0.0.Final.jar:4.0.0.Final]

          at org.modeshape.jcr.JcrRepository$BackgroundRepositoryTask.run(JcrRepository.java:1982) [modeshape-jcr-4.0.0.Final.jar:4.0.0.Final]

          at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_20]

          at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [na:1.8.0_20]

          at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [na:1.8.0_20]

          at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [na:1.8.0_20]

          at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_20]

          at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_20]

          at java.lang.Thread.run(Thread.java:745) [na:1.8.0_20]

       

       

       

      All of these happen with a simple configuration almost completely default and Infinispan set to ram storage with JTA run in an OSGi environment. All three problems happen with Modeshape 3.8.0 and 4.0.0. Am I doing something wrong?