jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "angela (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-2028) JSR 283: JCR Path
Date Fri, 17 Apr 2009 17:38:14 GMT

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

angela commented on JCR-2028:

Value handling in jackrabbit-core:

I spent some time with the issues listed above and came to the conclusion that we should take
a similar approach
as in jcr2spi: Instead of using the commons ValueFactory and creating the Value objects manually
in the InternalValue,
the jackrabbit-core should have it's own ValueFactory implementation that creates value objects
directly based on the InternalValue. With some minor effort this could be based on code already
present in spi-commons (ValueFactoryQImpl, QValueValue created by Julian some time ago), which
would be beneficial for the conversion from JCR-value to InternalValue and vice versa... those
are already used within jackrabbit-core query-row somewhere.

I will prepare a patch and upload it here as soon as possible.

> 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
>         Attachments: 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
> - 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.

View raw message