[ http://issues.apache.org/jira/browse/JCR-551?page=comments#action_12431879 ] Jaka Jaksic commented on JCR-551: ---------------------------------
The exception will occur the next time the property gets read from the file system. So just call node.refresh(false) afterwards, or something like that, and it should "work". > 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
