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