jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcel Reutegger (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-741) Handling of multiple residual prop defs in EffectiveNodeTypeImpl
Date Mon, 26 Feb 2007 09:05:06 GMT

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


Mime
View raw message