Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <28334205.1147993446763.JavaMail.jira@brutus>
Date: Thu, 18 May 2006 23:04:06 +0000 (GMT+00:00)
From: "Tobias Bocanegra (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Reopened: (JCR-428) Constructor
 org.apache.jackrabbit.core.value.BLOBFileValue(InputStream in) does not
 initialize field 'temp' correctly.
In-Reply-To: <17652417.1147101800964.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

     [ http://issues.apache.org/jira/browse/JCR-428?page=all ]
     
Tobias Bocanegra reopened JCR-428:
----------------------------------

     Assign To: Tobias Bocanegra  (was: Stefan Guggisberg)

the problem is, that in the first place, BLOBFileValues were not thought of beeing produced by the backend, but rather via the client, from the transient side. the late introduction of db-stored blobs just reused them without checking all invariants. 

the following example shows this error (when having db-blobs):

            Node rootNode = session.getRootNode();

            Node blobNode = rootNode.addNode("blobNode");
            rootNode.save();

            blobNode.setProperty("data", BlobTest3.createStream(70000));
            blobNode.save();

            blobNode.setProperty("data", BlobTest3.createStream(70000));
            blobNode.refresh(false);

            blobNode.getProperty("data").getString();

and throws an exception on the last .getString() since the BLOBFileValue gets discarded in the 2nd setProperty() call.

i think in the long run, we need a proper Blob/BlobFactory/reference counting framework in place, in order to properly support both client and backend usage of those blob file values. that's why i also opt for having a new value type: Binary in the jcr283 spec.

in the meantime, i think it helps to make the blobvalues of the transient items non-temporary, so that they don't get discarded.

> Constructor org.apache.jackrabbit.core.value.BLOBFileValue(InputStream in) does not initialize field 'temp' correctly.
> ----------------------------------------------------------------------------------------------------------------------
>
>          Key: JCR-428
>          URL: http://issues.apache.org/jira/browse/JCR-428
>      Project: Jackrabbit
>         Type: Bug

>   Components: core
>     Versions: 1.0
>     Reporter: Michael Frericks
>     Assignee: Tobias Bocanegra

>
> Situation:
> if the internal value of a property of type binary is created by the constructor BLOBFileValue(InputStream in) and the content is not stored in an temp-file, then calling the methods 
> a) #setProperty(InputStream in) on this node and then
> b) #refresh(false) on the node of this property 
> on the node of this property leads to an internal value of this property with an erased byte[].
> Solution:
> Only if the spoolFile is created the field 'temp' should be set to true.
> If the InputStream is stored in the byte[] the field 'temp' should be set to false.
> Patch:
> Index: BLOBFileValue.java
> ===================================================================
> retrieving revision 1.1
> diff -u -r1.1 BLOBFileValue.java
> --- BLOBFileValue.java	8 May 2006 13:57:49 -0000	1.1
> +++ BLOBFileValue.java	8 May 2006 15:19:54 -0000
> @@ -142,6 +142,7 @@
>                      len += read;
>                  }
>              }
> +            in.close();
>          } finally {
>              if (out != null) {
>                  out.close();
> @@ -151,8 +152,15 @@
>          // init vars
>          file = spoolFile;
>          fsResource = null;
> -        // this instance is backed by a temporarily allocated resource/buffer
> -        temp = true;
> +        if (file != null)
> +        {
> +            // this instance is backed by a temporarily allocated resource
> +            temp = true;
> +        }
> +        else
> +        {
> +            temp = true;
> +        }
>      }
>  
>      /**

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira