Jackrabbit Content Repository
  1. Jackrabbit Content Repository
  2. JCR-1346

InternalValue.createCopy for binary properties (jcr:data) causes problems

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.4
    • Fix Version/s: core 1.4.1
    • Component/s: jackrabbit-core
    • Labels:
      None

      Description

      Running 1.4 with no data store configured, and option org.jackrabbit.useDataStore not set (i.e true), the following code gives 0 for the property length.

      Node n = root.getNode(relPath);
      session.getWorkspace().copy(n.getPath(), destPath);
      Node contentNode = n.getNode(JcrConstants.JCR_CONTENT);
      Property p = contentNode.getProperty(JcrConstants.JCR_DATA);
      System.out.println("length = "+p.getLength());

      InternalValue.createCopy checks USE_DATA_STORE and returns the same value for the source node's state. BundleBinding.writeState() calls BLOBInMemory.discard() when persisting the new node. This has now changed the value of the existing nodes property. Setting the option org.jackrabbit.useDataStore to false works fine. Possibly the check for binary property type in InternalValue.createCopy should be done first?

        Activity

        Hide
        Jukka Zitting added a comment -

        Resolving as fixed based on comments above.

        Show
        Jukka Zitting added a comment - Resolving as fixed based on comments above.
        Hide
        Thomas Mueller added a comment -

        Merged to the 1.4 branch in revision 617383

        Show
        Thomas Mueller added a comment - Merged to the 1.4 branch in revision 617383
        Hide
        Rob Owen added a comment -

        Yes, this fixes the problem that I was seeing.
        Thanks,
        Rob.

        Show
        Rob Owen added a comment - Yes, this fixes the problem that I was seeing. Thanks, Rob.
        Hide
        Thomas Mueller added a comment -

        Hi Rob,

        My plan was to commit the changes to the 1.4.1 branch after you have tested them

        Regards,
        Thomas

        Show
        Thomas Mueller added a comment - Hi Rob, My plan was to commit the changes to the 1.4.1 branch after you have tested them Regards, Thomas
        Hide
        Rob Owen added a comment -

        Hi Thomas,

        Thanks. Will the changes apply to 1.4 (which I can try), or will you be committing this patch to 1.4.1 soon?

        Cheers,
        Rob.

        Show
        Rob Owen added a comment - Hi Thomas, Thanks. Will the changes apply to 1.4 (which I can try), or will you be committing this patch to 1.4.1 soon? Cheers, Rob.
        Hide
        Thomas Mueller added a comment -

        Hi Rob,

        The bug is fixed in the trunk now. Do you need a jar file to try out if it works now?

        Regards,
        Thomas

        Show
        Thomas Mueller added a comment - Hi Rob, The bug is fixed in the trunk now. Do you need a jar file to try out if it works now? Regards, Thomas
        Hide
        Thomas Mueller added a comment -

        Committed in revision 616442 (trunk)

        Show
        Thomas Mueller added a comment - Committed in revision 616442 (trunk)
        Hide
        Thomas Mueller added a comment -

        I can now reproduce the problem. A workaround is to set the system property "org.jackrabbit.useDataStore" to "false" (on the command line, or before starting Jackrabbit).

        Show
        Thomas Mueller added a comment - I can now reproduce the problem. A workaround is to set the system property "org.jackrabbit.useDataStore" to "false" (on the command line, or before starting Jackrabbit).

          People

          • Assignee:
            Thomas Mueller
            Reporter:
            Rob Owen
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development