jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Randall Hauch (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (JCR-3421) nt:propertyDefinition has incorrect value constraints for property types
Date Sat, 08 Sep 2012 15:34:07 GMT

    [ 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

Mime
View raw message