Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <14462190.1172571485756.JavaMail.jira@brutus>
Date: Tue, 27 Feb 2007 02:18:05 -0800 (PST)
From: "Julian Reschke (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Commented: (JCR-741) Handling of multiple residual prop defs
 in EffectiveNodeTypeImpl
In-Reply-To: <30127424.1171299613572.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/JCR-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476122 ] 

Julian Reschke commented on JCR-741:
------------------------------------

That would work, but why would the SPI implementation would ever need the definitions parameter? For an existing property, an SPI implementation should always precisely know the QPropDef right?

Or is this about requesting the definition of a property *before* it is being created? That would be useful, but again I don't see what the definitions parameters would do here?


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