Hi *,
lately updating the org.apache.sling.jcr.resource from version 2.0.10 to
version 2.1 I hit a little issue.
The same call to the JcrPropertyMap#containsKey that used to work in the former
version fails in the latest with stacktrace
java.lang.IllegalArgumentException: javax.jcr.RepositoryException: failed to
resolve path relative to node /test1340468918488
at org.apache.sling.jcr.resource.JcrPropertyMap.read(JcrPropertyMap.java:355)
at org.apache.sling.jcr.resource.JcrPropertyMap.get(JcrPropertyMap.java:162)
at
org.apache.sling.jcr.resource.JcrPropertyMap.containsKey(JcrPropertyMap.java:171)
at
org.apache.sling.jcr.resource.internal.JcrPropertyMapTest.testDefaultValue(JcrPropertyMapTest.java:206)
at
org.apache.sling.jcr.resource.internal.JcrPropertyMapTest.testDefaultValue(JcrPropertyMapTest.java:134)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
if containsKey empty string argument e.g. jcrPropertyMap.containsKey("").
Now, java.lang.IllegalArgumentException is a runtime exception so fair enough,
but since I have starting to grasp the essence of semantic versioning I wonder
if this is "legitimate" for the consumer.
Here some related notes:
- the package version is kept the same
org.apache.sling.jcr.resource;version=2.1 in both bundle version
- the containsKey method is not part of any API (AFAIK) but is part of the
org.apache.sling.jcr.resource package and is public
- the exception is thrown from the read method that now is public and declares
the runtime exception in the Java Doc (before the method was package protected)
- previously the Exception was "swallowed" in the read method
Again probably is not an issue at all but I am still "curious" to know WDYT :)
Regards
Antonio
