You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@jackrabbit.apache.org by to...@apache.org on 2013/05/10 10:14:45 UTC
svn commit: r1480921 -
/jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/data/DataIdentifier.java
Author: tommaso
Date: Fri May 10 08:14:45 2013
New Revision: 1480921
URL: http://svn.apache.org/r1480921
Log:
JCR-3534 - avoiding backward compatibility issue by adding back constructor DataIdentifier(byte[])
Modified:
jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/data/DataIdentifier.java
Modified: jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/data/DataIdentifier.java
URL: http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/data/DataIdentifier.java?rev=1480921&r1=1480920&r2=1480921&view=diff
==============================================================================
--- jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/data/DataIdentifier.java (original)
+++ jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/data/DataIdentifier.java Fri May 10 08:14:45 2013
@@ -61,6 +61,16 @@ public class DataIdentifier implements S
}
/**
+ * Creates a data identifier from the hexadecimal string
+ * representation of the given bytes.
+ *
+ * @param identifier data identifier
+ */
+ public DataIdentifier(byte[] identifier) {
+ this(AbstractDataStore.encodeHexString(identifier), null);
+ }
+
+ /**
* Returns a secure reference to the identified binary, or {@code null}
* if no such reference is available.
*
Re: svn commit: r1480921 -
/jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/data/DataIdentifier.java
Posted by Tommaso Teofili <te...@adobe.com>.
On 10/mag/2013, at 10:28, Jukka Zitting wrote:
> Hi,
>
> On Fri, May 10, 2013 at 11:14 AM, <to...@apache.org> wrote:
>> JCR-3534 - avoiding backward compatibility issue by adding back constructor DataIdentifier(byte[])
>
> DataIdentifier is an internal class so there's only a very limited
> backwards compatibility issue to consider.
>
> We've generally only promised strict binary compatibility for external
> implementations of extension points like the DataStore or
> PersistenceManager interfaces within a stable maintenance branch. For
> example upgrading from 2.6.0 to 2.6.1 should not require changes in
> such components. However, across minor versions or unstable releases,
> like from 2.4.x to 2.6.y or from 2.7.x to 2.7.y, we can expect such
> implementations to be updated to match any relevant changes in
> Jackrabbit internals.
agree, thanks for pointing out.
>
> In this case for example any DataStore implementations will in any
> case need to be adapted to implement the new
> getIdentifierFromReference() method (even if that implementation
> always returns null), so the value of keeping DataIdentifier intact
> isn't too high.
i see, you're right that isn't too important for compatibility issues; also I thought it'd have made sense to keep having it.
Thanks,
Tommaso
>
> BR,
>
> Jukka Zitting
Re: svn commit: r1480921 - /jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/data/DataIdentifier.java
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Fri, May 10, 2013 at 11:14 AM, <to...@apache.org> wrote:
> JCR-3534 - avoiding backward compatibility issue by adding back constructor DataIdentifier(byte[])
DataIdentifier is an internal class so there's only a very limited
backwards compatibility issue to consider.
We've generally only promised strict binary compatibility for external
implementations of extension points like the DataStore or
PersistenceManager interfaces within a stable maintenance branch. For
example upgrading from 2.6.0 to 2.6.1 should not require changes in
such components. However, across minor versions or unstable releases,
like from 2.4.x to 2.6.y or from 2.7.x to 2.7.y, we can expect such
implementations to be updated to match any relevant changes in
Jackrabbit internals.
In this case for example any DataStore implementations will in any
case need to be adapted to implement the new
getIdentifierFromReference() method (even if that implementation
always returns null), so the value of keeping DataIdentifier intact
isn't too high.
BR,
Jukka Zitting