[
https://issues.apache.org/jira/browse/JCR-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13452020#comment-13452020
]
Randall Hauch edited comment on JCR-3421 at 9/11/12 1:58 AM:
-------------------------------------------------------------
Thanks for clarifying, Julian. I would strongly oppose removing any existing
feature, even if it were optional. It is extremely useful to have the node
types exposed as content in a standard way.
I think there are two options:
1) Do nothing. Yes, it is a bug, but IMO the bug is merely an inconvenience in
that JCR doesn't provide a utility that will convert between the
"jcr:requireType" STRING value and the integer value returned by the
PropertyDefinition.getRequireType() method. If clients need to do this, they
can easily implement the correct logic on their own. Jackrabbit and other
implementations will likely need to do this, but of course we/they can (and
probably already) do it however they want and it will not be exposed. The bug
was found because Michael tried to use
"javax.jcr.PropertyType.valueFromName(String)" to perform the conversion.
2) Change JCR's utility method for converting between String and integer
representations of property types by making the
"javax.jcr.PropertyType.valueFromName(String)" method be case-insensitive.
Obviously this can only be done in the JSR, though Jackrabbit could provide a
public utility to do this.
I definitely prefer 1, since the issue is not major, does not likely affect
many clients, should not affect any implementations, and has a trivial
workaround.
was (Author: rhauch):
Thanks for clarifying, Julian. I would strongly oppose removing any
existing feature, even if it were optional. It is extremely useful to have the
node types exposed as content in a standard way.
I think there are two options:
1) Do nothing. Yes, it is a bug, but IMO the bug is merely an inconvenience in
that JCR doesn't provide a utility that will convert between the
"jcr:requireType" STRING value and the integer value returned by the
PropertyDefinition.getRequireType() method. If clients need to do this, they
can easily implement the correct logic on their own. Implementations will
likely need to do this, but of course they can (and probably already) do it
however they want and it will not be exposed. The bug was found because Michael
tried to use "javax.jcr.PropertyType.valueFromName(String)" to perform the
conversion.
2) Change JCR's utility method for converting between String and integer
representations of property types by making the
"javax.jcr.PropertyType.valueFromName(String)" method be case-insensitive. Note
that the PropertyType.nameFromValue(int) method will be unchanged, so I think
this change will be entirely backward compatible (though I'd prefer others
double check me here). However, publishing an updated JCR API means
implementations will have to update their dependencies, and since this will
happen over time clients will likely still have to rely upon their own
implementation.
I definitely prefer 1, since the issue is not major, does not likely affect
many clients, should not affect any implementations, and has a trivial
workaround.
> nt:propertyDefinition has incorrect value constraints for property types
> -------------------------------------------------------------------------
>
> Key: JCR-3421
> URL: https://issues.apache.org/jira/browse/JCR-3421
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Reporter: Michael Dürig
> Priority: Minor
>
> The values should match those defined in javax.jcr.PropertyType.
> See http://java.net/jira/browse/JSR_283-811
> and http://markmail.org/message/asyaqqkn5nucvcjk
--
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
