[ 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. -- 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
