[
https://issues.apache.org/jira/browse/OAK-722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13615292#comment-13615292
]
Marcel Reutegger edited comment on OAK-722 at 3/27/13 2:13 PM:
---------------------------------------------------------------
Hmm, I'd say all {{setProperty()}} methods without type parameter should call
{{internalSetProperty()}} with exactType = {{false}}. E.g. the JavaDoc of
{{setProperty(String, long)}} says:
bq. The behavior of this method is identical to that of setProperty(String
name, Value value) except that the value is specified as a long and, if
possible, the type assigned to the property is LONG, otherwise a best-effort
conversion is attempted.
And in {{NodeImpl.setProperty(String, Value)}} we pass exactType = {{false}}.
All tests pass with this modification.
I'm wondering why we enforced exact type before in those methods and how this
worked in the past...
was (Author: mreutegg):
Hmm, I'd say all {{setProperty()}} methods without type parameter should
call {{internalSetProperty()}} with exactType = {{false}}. E.g. the JavaDoc of
{{setProperty(String, long)}} says:
bq. The behavior of this method is identical to that of setProperty(String
name, Value value) except that the value is specified as a long and, if
possible, the type assigned to the property is LONG, otherwise a best-effort
conversion is attempted.
And in {{setProperty(String, Value)}} set pass exactType = {{false}}.
All tests pass with this modification.
I'm wondering why we enforced exact type before in those methods and how this
worked in the past...
> Type conversion broken
> ----------------------
>
> Key: OAK-722
> URL: https://issues.apache.org/jira/browse/OAK-722
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, jcr
> Affects Versions: 0.6
> Reporter: Marcel Reutegger
> Assignee: Marcel Reutegger
>
> The fix for OAK-702 introduced a regression not caught by our tests but is
> visible with Apache Sling on top of an Oak repository. The JSP compiler in
> Sling creates an nt:resource node with a jcr:lastModified property using a
> long value. As of svn revision 1461058 this results in a
> ConstraintViolationException:
> {code}
> javax.jcr.nodetype.ConstraintViolationException: No matching property
> definition found for jcr:lastModified
> at
> org.apache.jackrabbit.oak.plugins.nodetype.EffectiveNodeType.getPropertyDefinition(EffectiveNodeType.java:354)
> at
> org.apache.jackrabbit.oak.plugins.nodetype.ReadOnlyNodeTypeManager.getDefinition(ReadOnlyNodeTypeManager.java:435)
> at org.apache.jackrabbit.oak.jcr.NodeImpl$32.perform(NodeImpl.java:1610)
> at org.apache.jackrabbit.oak.jcr.NodeImpl$32.perform(NodeImpl.java:1599)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:101)
> at org.apache.jackrabbit.oak.jcr.ItemImpl.perform(ItemImpl.java:60)
> at
> org.apache.jackrabbit.oak.jcr.NodeImpl.internalSetProperty(NodeImpl.java:1599)
> at org.apache.jackrabbit.oak.jcr.NodeImpl.setProperty(NodeImpl.java:519)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
