[
https://issues.apache.org/jira/browse/JCR-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478035
]
Julian Reschke commented on JCR-741:
------------------------------------
> my point is to possibly avoid a call (by an spi implementation) to the store
> and give an spi implementation the opportunity to implement the method as an
> entirely local call. Would this work in your case, or would you still have to
> ask the store to pick the right definition?
In my case it wouldn't make a difference; only the store knows the right answer.
> IMO we should remove the method RepositoryService.getPropertyDefinition()
> anyway. It does not scale well and in almost all cases it can be infered from
> the node type definition which property definition applies to a certain
> property. I think the same also applies to child node definitions (jcr2spi
> only uses the method to get the node definition for the root node).
+1 on removing stuff from the API that isn't used by JCR2SPI.
> Using the node type definition and its item definitions require much lesser
> calls to the SPI than using getPropertyDefinition() and getNodeDefinition().
> So, I think jcr2spi does it the right way, even though it doesn't use
> getPropertyDefinition().
Avoiding round-trips is good; we just need to make the special cases work. So
what's the next step? Add resolvePropertyDefinition() as proposed?
> 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.
