jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-2028) JSR 283: JCR Path
Date Thu, 07 May 2009 07:51:31 GMT

    [ https://issues.apache.org/jira/browse/JCR-2028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12706750#action_12706750
] 

Thomas Mueller commented on JCR-2028:
-------------------------------------

Hi,

A few remarks about JCR-2028_core.patch

  try {
    addPathValue(doc, fieldName, value.getPath());
  } catch (RepositoryException e) {
    // will never occur
  }

This is very dangerous. Maybe the implementation of addPathValue change, and the method sometimes
does throw an exception. What about converting the RepositoryException to a RuntimeException
instead?

+        if (value == null) {
+            throw new IllegalArgumentException("null value");
+        }
         if (USE_DATA_STORE) {
             return new InternalValue(BLOBInResource.getInstance(value));
         }

I would prefer a NullPointerException in that case. Could this be simplified, for example
using a method 'checkNull'? Or moved the check to the constructor to avoid copy&paste?

-        val = new Long(value);
-        type = PropertyType.LONG;
+        super(new Long(value));

Now that we can use Java 1.5, we should use Long.valueOf(...) because it has a cache.

Did you overload equals without overloading hashCode? That's dangerous, it might break hash
tables.


> JSR 283: JCR Path
> -----------------
>
>                 Key: JCR-2028
>                 URL: https://issues.apache.org/jira/browse/JCR-2028
>             Project: Jackrabbit Content Repository
>          Issue Type: Sub-task
>          Components: JCR 2.0
>            Reporter: angela
>             Fix For: 2.0.0
>
>         Attachments: JCR-2028_commons.patch, JCR-2028_core.patch, JCR-2028_jcr2spi_spiimpls.patch,
JCR-2028_spi.diff, JCR-2028_spicommons.diff, JCR-2028_tests.diff
>
>
> with jsr 283 the jcr path is defined to consist of a combination of the following segments
> •	a name segment, (J, I), where J is a JCR name and I is an integer index (I ≥ 1).
> •	an identifier segment, U, where U is a JCR identifier.
> •	the root segment.
> •	the self segment.
> •	the parent segment.
> -> the name segment can be in extended or qualified form -> see issue JCR-1712
> -> the identifier segment is new for jsr283 and always identifies a node (-> see
new method Node.getIdentifier())
> Non-standard parts always need to be standardized. Any of the following makes a path
non-standard:
> - expanded name segments
> - trailing /
> - index [1]
> Identifier-segments
> - get resolved upon being passed to any API calls that take path to an existing Node
> - don't get resolved when being used to create a PATH value object.
> Except for PATH values, all jcr paths returned by the API are normalized and standard,
thus never identifier-based.
> PATH values in contrast:
> - must be converted to standard form
> - must NOT be normalized. i.e. redundant segments and identifiers must be preserved.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message