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