jackrabbit-dev mailing list archives

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

     [ https://issues.apache.org/jira/browse/JCR-2028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

angela updated JCR-2028:
------------------------

    Attachment: JCR-2028_tests.diff
                JCR-2028_spicommons.diff
                JCR-2028_spi.diff

Initial proposal for the identifier-based path attempting to incorporate that extension into
the general path handling used with both jackrabbit-core and jsr2spi. Main goal was to avoid
spreading identifier-path handling through the core/jcr2spi code but instead having it localized
in a single place.

This implies from my point of view the following if we want to stick with the current path
handling:

- Normalization of identifier-based paths is defined to be its replacement by a root-based
  absolute path, which depends on an Session that is able to resolve id to path.
  Since the Path object we are having is uncoupled from any Session, normalization of
  identifier-based paths must occur before the Path object is created.

- PATH values on the other hand need to preserve there standard from as entered.
  Immediate normalization to the an absolute path consisting of qualified name segments is

  not desired (not allowed). Which means that the internal representation of the jcr path

  must be able to deal with identifier-segments.

This lead to the following changes:

- Path may consist of a single IdentifierElement
- Path has additional method 'denotesIdentifier'
- Path.Element can be created from an identifier (which currently is String) and gets a
  method to determine if a given element is an identifier-element.
  The validation of the id (same as with jcr name) is left to the parser.

- PathParser is extended to handle identifier-based paths upon demand:
  > validation of the format without requirement that the normalization would succeed.
  > normalization that requires that a Node exists with that identifier.
- Introduction of a IdentifierResolver: 
  Used to convert identifier-based paths to a normalized path and validate the validity 
  of an identifier during parsing.
- PathResolver: additional method getQPath(String jcrPath, boolean normalizeIdentifier)
  that allows to trigger normalization of identifiers before creating the path objects.
  the existing method without the flag by default resolves identifier-based path or throws
if
  no IdentifierResolver present (i.e. identifier-based not supported -> path syntax invalid)

- The changes required to make core/jcr2spi properly deal with identifier-based paths
  where ever normalization is required (API calls except for values generation) seemed 
  to be straight forward (and very limited)... (not included in the patches).

Still I came accross of the following issues, which I didn't address yet, since i wanted
to get some input regarding the overall approach before digging into the details here.

Issues:

- In order to properly validate the format of PATH values the ValueFactory will have a
  dependency to the implementation that defines the format of the identifiers.
  This was straight forward with the ValueFactory present in spi-commons and thus with
  jcr2spi that consistently uses the ValueFactory defined on the Session object.

- In jackrabbit-core the session's valuefactory is rarely used. Instead instance
  of the jcr-commons ValueFactory are used, which is neither enabled to standardize
  expanded name-segments nor able to deal with identifiers.

- In the InternalValue the Value objects are even created directly without make use of 
  any ValueFactory... this seems to cause troubles in contrast to jcr2spi where all
  jcr and internal values are handled/created by the factories exposed by the Session.

Notes about the identifier path elements:

- I first thought about forcing the identifier-element be constructed from an ItemID 
  instead of a simple String, but dropped that again... for simplicity of the initial proposal...
  and because I wasn't totally convinced if it would be any beneficial.

The tests included in the 3rd attachement are just for completeness (TCK) and to have them
saved away. Failing at the moment due to missing functionality in core/jcr2spi.

angela


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

-- 
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