[JSR_283-810] Export packages at version 1.1 in addition to 2.0 Created: 13/Aug/12  Updated: 13/Aug/12

Status: Open
Project: jsr-283
Component/s: javadoc/api
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: fmeschbe Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File export-version.patch    

 Description   

The JCR API bundle/library exports the JCR API at version 2.0 – specifically the API is exported with the same version as the bundle version.

Compared to JCR 1.0 (JSR-170) this signifies a major version change. According to the OSGi Semantic Versioning recommendation [1] a major version change on an exported package indicates backwards incompatible changes.

It is my understanding, though, that JCR 2.0 is fully backwards compatible with JCR 1.0 hence the API exports should not indicate backwards incompatiblity.

As a fix I propose to export the API with two versions:

1.1 to support OSGi bundles written against the JCR 1.0 API and
importing with recommended version range [1.0,2)
2.0 to not break bundles written against the JCR 2.0 API bundle

Patch attached.






[JSR_283-809] error in javadoc of Property interface Created: 13/May/11  Updated: 13/May/11

Status: Open
Project: jsr-283
Component/s: javadoc/api
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dbu Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

hi,
there is a mistake in the javadoc for jcr 2.0

Property.getDate() is a shortcut to Property.getValue().getDate()
Value.getDate() throws a ValueFormatException if the property can not be converted to Calendar
Property.getDate() says it throws that exception if the value can not be converted to string. it should say Calendar here too.

http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/Property.html#getDate%28%29

http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/Value.html#getDate%28%29






[JSR_283-811] nt:propertyDefinition has incorrect value constraints for property types Created: 07/Sep/12  Updated: 10/Sep/12

Status: Open
Project: jsr-283
Component/s: node types
Affects Version/s: not determined
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: reschke Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Discovered by Michael Dürig:

[nt:propertyDefinition]
...

  • jcr:requiredType (STRING) protected mandatory
    < 'STRING', 'URI', 'BINARY', 'LONG', 'DOUBLE',
    'DECIMAL', 'BOOLEAN', 'DATE', 'NAME', 'PATH',
    'REFERENCE', 'WEAKREFERENCE', 'UNDEFINED'

The type names are defined in javax.jcr.PropertyType. For example

TYPENAME_STRING = "String";

Now JSR-283 says about string constraints (3.7.3.6.1): "For STRING and URI properties, the constraint string is a regular expression pattern according to the syntax of java.util.regex.Pattern."

So jcr:requiredType can be for example "STRING" but not "String". The former however results in an IllegalArgumentException when passed to PropertyType.valueFromName().

It appears the simplest possible fix would be to tune the type names in the value constraints.



 Comments   
Comment by rhauch [ 08/Sep/12 ]

(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'.

Comment by rhauch [ 10/Sep/12 ]

I've logged a similar issue with proposed fix on JSR-333: http://java.net/jira/browse/JSR_333-52





Generated at Wed Sep 28 04:59:04 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.