[
https://issues.apache.org/jira/browse/JCR-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475846
]
Marcel Reutegger commented on JCR-741:
--------------------------------------
Hmm, this would move the responsibility to pick an item definition to the SPI
implementation but at the same time also increase the complexity of the SPI
implementation. ItemInfo can currently be implemented as a simple bean without
the need for additional logic. Your suggestion would break this rule, but maybe
it's worth it.
I see two other options:
A) JCR2SPI first tries to resolve the ItemDefinition based on the available
node type information. E.g. the property jcr:primaryType is always well
defined. If there is more than one matching residual definition present,
JCR2SPI asks the repository service for a matching definition.
B) Change methods RepositoryService.get[Node|Property]Definition() in a way
that they can be implemented without a need for a server roundtrip and then
always use those methods to lookup an ItemDefinition.
Or even better implement both A & B?
Angela, what do you think?
> Handling of multiple residual prop defs in EffectiveNodeTypeImpl
> ----------------------------------------------------------------
>
> Key: JCR-741
> URL: https://issues.apache.org/jira/browse/JCR-741
> Project: Jackrabbit
> Issue Type: Bug
> Components: SPI
> Reporter: Julian Reschke
> Assigned To: Julian Reschke
> Priority: Minor
>
> org.apache.jackrabbit.jcr2spi.nodetype.EffectiveNodeTypeImpl currently
> rejects multiple residual property definitions, if they do not differ in
> getMultiple(). In fact, it should accept all combinations, so differing
> values for getOnParentVersionAction and other aspects should be accepted as
> well.
> See JSR 170, 6.7.8:
> "For purposes of the above, the notion of two definitions having the same
> name does not apply to two residual definitions. Two (or more) residual
> property or child node definitions with differing subattributes must be
> permitted to co-exist in the same effective node type. They are interpreted
> as disjunctive (ORed) options."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
