Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <8514184.1193297210617.JavaMail.jira@brutus>
Date: Thu, 25 Oct 2007 00:26:50 -0700 (PDT)
From: "Felix Meschberger (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Commented: (JCR-1187) Asking a property twice for it's
 stream returns the same stream instance
In-Reply-To: <2455649.1193240510593.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/JCR-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537527 ] 

Felix Meschberger commented on JCR-1187:
----------------------------------------

You are right, but there is a very small point to this: To get a new stream, you have to reaquire the value through Property.getValue(), which is exactly how Property.getStream() is defined. Thus, as a consequence, Property.getStream() MUST always return a new stream.

> Asking a property twice for it's stream returns the same stream instance
> ------------------------------------------------------------------------
>
>                 Key: JCR-1187
>                 URL: https://issues.apache.org/jira/browse/JCR-1187
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: jackrabbit-core
>            Reporter: Esteban Franqueiro
>         Attachments: DataStoreTestUtils.java, TestTwoGetStreams.java
>
>
> If you ask a property stored in the database data store (JCR-1154) for it's associated stream twice, the stream instance returned is the same. This behavior is not consistent with the file data store, which returns a different stream instance each time Property.getStream() is called.
> I'm attaching a test case wich demostrates the issue.
> We're working on this and have a potencial fix for it.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.