In your application, are you accessing the repository remotely from the
RMI client?
I have noticed that handling of nulls in the RMI client is inconsistent,
some methods don't handle nulls correctly. We managed to sort out which
methods work and are using that way. This doesn't happen with the local
client. I was going to report this but I haven't had time to put a test
case.
Carlos
Jaka Jaksic (JIRA) wrote:
[ http://issues.apache.org/jira/browse/JCR-551?page=comments#action_12432261 ]
Jaka Jaksic commented on JCR-551:
---------------------------------
Hey, Stefan.. This is rather embarrassing, but as I went to prepare the
stand-alone test case, I was unable to reproduce it either. I used the same
configuration (as much as I could), but no matter what I did, if I set the
property to null, the BLOB was simply deleted, just like it should be. I really
don't know what could have made the difference in my application (the bug was
perfectly reproducible there - occured plenty of times in a fresh repository
etc.), and I still think this bug does exist, but it is obviously not as common
and as critical as I thought. So let's just leave it at that for now and I'll
get back to you if I manage to learn more about it. I'm really sorry for
wasting your time.
Null values cause BLOB corruption
---------------------------------
Key: JCR-551
URL: http://issues.apache.org/jira/browse/JCR-551
Project: Jackrabbit
Issue Type: Bug
Components: core
Affects Versions: 1.0.1
Reporter: Jaka Jaksic
Assigned To: Stefan Guggisberg
Priority: Critical
Using the file persistence manager (not sure about other managers) there is a way to
produce a corrupt property BLOB, which can then be neither read nor modified nor deleted.
Once this happens, Jackrabbit starts throwing "failed to read property state"
exceptions every time it hits that property, and essentially becomes useless until the
BLOB is fixed (e.g. with a hex editor).
The problem is caused by passing a null value to a setProperty overload other
than setProperty(String, Value).
For example:
node.setProperty("corruptionTest", null, PropertyType.STRING);
This produces a corrupt BLOB (the data in the BLOB indicates value count = 1,
then the BLOB ends) instead of removing the property or at least throwing an
exception.
setProperty(String, Value) properly removes the property if a null is passed to
it, as documented in the JCR spec. I think other overloads should do the same,
although this is not explicitly stated in the spec. In any case they should not
corrupt repository data.
