You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Michael Dürig (JIRA)" <ji...@apache.org> on 2012/09/07 16:40:08 UTC
[jira] [Created] (JCR-3421) nt:propertyDefinition has incorrect
value constraints for property types
Michael Dürig created JCR-3421:
----------------------------------
Summary: 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
[jira] [Commented] (JCR-3421) nt:propertyDefinition has incorrect
value constraints for property types
Posted by "Randall Hauch (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13451349#comment-13451349 ]
Randall Hauch commented on JCR-3421:
------------------------------------
(This is the same comment I just added to the http://java.net/jira/browse/JSR_283-811 issue.)
While I agree that this was a problem in JSR-283, I don't believe it's necessary or even advisable to fix or address.
First of all, changing the "jcr:requiredType" property definition to use the same case as the constants in javax.jcr.PropertyType without causing a backward compatibility issue for all existing repositories that are compliant with JSR-283. This is because a JSR-283 repository can represent the node type definitions, property definitions, and child node definitions within the "/jcr:system/jcr:nodeTypes" subgraph. Changing the constraints would make all these "nt:propertyDefinition" nodes in existing repositories invalid. (Note that the "jcr:requiredType" property is mandatory.
Secondly, this shouldn't be an issue for an implementation. This is because the javax.jcr.nodetype.PropertyDefinition interface defines the "getRequiredType()" method as returning an int, not a string. In other words, the string representation of the required type within the "/jcr:system/jcr:nodeType" subgraph cannot be used within the implementations javax.jcr.nodetype.PropertyDefinition implementation without converting to an integer. Yes, an implementation will not be able to use existing javax.jcr.PropertyType.valueFromName(String) to perform the conversion, and instead needs to use a case-insensitive version. But that is purely an implementation detail.
Perhaps a better alternative change would be to change the existing "javax.jcr.PropertyType.valueFromName(String)" implementation to be case-insensitive. Consider that the CND notation introduced in JSR-283 specifically states in Section 25.2.3.1 "Case Insensitive Keywords" specifically states:
The keywords of CND, though defined above as terminal strings with specific cases, are in fact case-insensitive.
For example, STRING can be written string, String or even StRiNg.
Therefore, an implementation that parses a CND file already has to convert a property definition's type in a case-insensitive manner, and changing the existing "javax.jcr.PropertyType.valueFromName(String)" implementation to be case-insensitive would allow an implementation to use that method in CND parsing rather than its own custom implementation.
However, I'm actually in favor of doing none of these, and marking this issue as 'not a bug'.
> 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
[jira] [Commented] (JCR-3421) nt:propertyDefinition has incorrect
value constraints for property types
Posted by "Michael Dürig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13452027#comment-13452027 ]
Michael Dürig commented on JCR-3421:
------------------------------------
I generally agree with Randall. That's why I proposed to resolve this issue as won't fix for JR. Wrt. the JSRs I can follow Randall's argument and it makes perfect sense to me. However having such an inconsistency in a specification will always cause confusion and probably bugs. So it would be good to at least clarify the current situation.
> 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
[jira] [Comment Edited] (JCR-3421) nt:propertyDefinition has
incorrect value constraints for property types
Posted by "Randall Hauch (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (JCR-3421) nt:propertyDefinition has incorrect
value constraints for property types
Posted by "Michael Dürig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13451930#comment-13451930 ]
Michael Dürig commented on JCR-3421:
------------------------------------
Agreed. At least for Jackrabbit I suggest to resolve this as won't fix.
> 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
[jira] [Comment Edited] (JCR-3421) nt:propertyDefinition has
incorrect value constraints for property types
Posted by "Randall Hauch (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13452383#comment-13452383 ]
Randall Hauch edited comment on JCR-3421 at 9/11/12 7:04 AM:
-------------------------------------------------------------
I've logged a similar issue (http://java.net/jira/browse/JSR_333-52) against JSR-333, with a proposal to change the javax.jcr.PropertyType.valueFromName(String) method implementation to be case-insensitive.
was (Author: rhauch):
I've logged a [similar issue|http://java.net/jira/browse/JSR_333-52] against JSR-333, with a proposal to change the javax.jcr.PropertyType.valueFromName(String) method implementation to be case-insensitive.
> 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
[jira] [Commented] (JCR-3421) nt:propertyDefinition has incorrect
value constraints for property types
Posted by "Randall Hauch (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13452383#comment-13452383 ]
Randall Hauch commented on JCR-3421:
------------------------------------
I've logged a [similar issue|http://java.net/jira/browse/JSR_333-52] against JSR-333, with a proposal to change the javax.jcr.PropertyType.valueFromName(String) method implementation to be case-insensitive.
> 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
[jira] [Comment Edited] (JCR-3421) nt:propertyDefinition has
incorrect value constraints for property types
Posted by "Randall Hauch (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13451349#comment-13451349 ]
Randall Hauch edited comment on JCR-3421 at 9/9/12 2:32 AM:
------------------------------------------------------------
(This is the same comment I just added to the http://java.net/jira/browse/JSR_283-811 issue.)
While I agree that this was a problem in JSR-283, I don't believe it's necessary or even advisable to fix or address.
First of all, changing the "jcr:requiredType" property definition to use the same case as the constants in javax.jcr.PropertyType will not be backward compatible. This is because a JSR-283 repository can represent the node type definitions, property definitions, and child node definitions within the "/jcr:system/jcr:nodeTypes" subgraph. Changing the constraints would make all these "nt:propertyDefinition" nodes in existing repositories invalid. (Note that the "jcr:requiredType" property is mandatory.
Secondly, this shouldn't be an issue for an implementation. This is because the javax.jcr.nodetype.PropertyDefinition interface defines the "getRequiredType()" method as returning an int, not a string. In other words, the string representation of the required type within the "/jcr:system/jcr:nodeType" subgraph cannot be used within the implementations javax.jcr.nodetype.PropertyDefinition implementation without converting to an integer. Yes, an implementation will not be able to use existing javax.jcr.PropertyType.valueFromName(String) to perform the conversion, and instead needs to use a case-insensitive version. But that is purely an implementation detail.
Perhaps a better alternative change would be to change the existing "javax.jcr.PropertyType.valueFromName(String)" implementation to be case-insensitive. Consider that the CND notation introduced in JSR-283 specifically states in Section 25.2.3.1 "Case Insensitive Keywords" specifically states:
The keywords of CND, though defined above as terminal strings with specific cases, are in fact case-insensitive.
For example, STRING can be written string, String or even StRiNg.
Therefore, an implementation that parses a CND file already has to convert a property definition's type in a case-insensitive manner, and changing the existing "javax.jcr.PropertyType.valueFromName(String)" implementation to be case-insensitive would allow an implementation to use that method in CND parsing rather than its own custom implementation.
However, I'm actually in favor of doing none of these, and marking this issue as 'not a bug'.
was (Author: rhauch):
(This is the same comment I just added to the http://java.net/jira/browse/JSR_283-811 issue.)
While I agree that this was a problem in JSR-283, I don't believe it's necessary or even advisable to fix or address.
First of all, changing the "jcr:requiredType" property definition to use the same case as the constants in javax.jcr.PropertyType without causing a backward compatibility issue for all existing repositories that are compliant with JSR-283. This is because a JSR-283 repository can represent the node type definitions, property definitions, and child node definitions within the "/jcr:system/jcr:nodeTypes" subgraph. Changing the constraints would make all these "nt:propertyDefinition" nodes in existing repositories invalid. (Note that the "jcr:requiredType" property is mandatory.
Secondly, this shouldn't be an issue for an implementation. This is because the javax.jcr.nodetype.PropertyDefinition interface defines the "getRequiredType()" method as returning an int, not a string. In other words, the string representation of the required type within the "/jcr:system/jcr:nodeType" subgraph cannot be used within the implementations javax.jcr.nodetype.PropertyDefinition implementation without converting to an integer. Yes, an implementation will not be able to use existing javax.jcr.PropertyType.valueFromName(String) to perform the conversion, and instead needs to use a case-insensitive version. But that is purely an implementation detail.
Perhaps a better alternative change would be to change the existing "javax.jcr.PropertyType.valueFromName(String)" implementation to be case-insensitive. Consider that the CND notation introduced in JSR-283 specifically states in Section 25.2.3.1 "Case Insensitive Keywords" specifically states:
The keywords of CND, though defined above as terminal strings with specific cases, are in fact case-insensitive.
For example, STRING can be written string, String or even StRiNg.
Therefore, an implementation that parses a CND file already has to convert a property definition's type in a case-insensitive manner, and changing the existing "javax.jcr.PropertyType.valueFromName(String)" implementation to be case-insensitive would allow an implementation to use that method in CND parsing rather than its own custom implementation.
However, I'm actually in favor of doing none of these, and marking this issue as 'not a bug'.
> 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
[jira] [Commented] (JCR-3421) nt:propertyDefinition has incorrect
value constraints for property types
Posted by "Randall Hauch (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13451981#comment-13451981 ]
Randall Hauch commented on JCR-3421:
------------------------------------
Julian, what do you mean by "subtract 'exposing node types in content'"?
> 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
[jira] [Commented] (JCR-3421) nt:propertyDefinition has incorrect
value constraints for property types
Posted by "Randall Hauch (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13452020#comment-13452020 ]
Randall Hauch commented on JCR-3421:
------------------------------------
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
[jira] [Commented] (JCR-3421) nt:propertyDefinition has incorrect
value constraints for property types
Posted by "Julian Reschke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13451998#comment-13451998 ]
Julian Reschke commented on JCR-3421:
-------------------------------------
What I mean is: if we didn't have this (optional) feature then there wouldn't be a problem. Right? So **if* something needs to be fixed, it should happen in the definition of this feature.
> 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
[jira] [Commented] (JCR-3421) nt:propertyDefinition has incorrect
value constraints for property types
Posted by "Julian Reschke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13451965#comment-13451965 ]
Julian Reschke commented on JCR-3421:
-------------------------------------
I think we do have a inconsistency in the spec.
It appears that if we substract "exposing node types in content" from the spec (an optional feature), we're fine right? So it seems that this is where a fix needs to be done...
> 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