[jira] Commented: (JCR-741) Handling of multiple residual prop defs in EffectiveNodeTypeImpl
[ https://issues.apache.org/jira/browse/JCR-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477963 ] Marcel Reutegger commented on JCR-741: -- Not convinced. If the node type allows multiple property definitions here, obtaining the right one from the store doesn't seem to be any harder than selecting one of the ones supplied by the caller. 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? Anyway; if we do that, do we still need RepositoryService.getPropertyDefinition? Right now it's not used by JCR2SPI which makes me a bit nervous :-). 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). 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(). 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.
[VOTE] Release Apache Jackrabbit 1.2.3
Hi, I have posted a candidate for the Apache Jackrabbit 1.2.3 release at http://people.apache.org/~jukka/jackrabbit/1.2.3/ See the included RELEASE-NOTES.txt file for details on release contents and latest changes. The release was made from the 1.2 branch after merging all the bug fixes listed in the release notes. Please vote on releasing these packages as Apache Jackrabbit 1.2.3. The vote is open for the next 72 hours. Only votes from Jackrabbit committers are binding, but everyone is welcome to check the release candidate and voice their approval or disapproval. The vote passes if at least three binding +1 votes are cast. [ ] +1 Release the packages as Apache Jackrabbit 1.2.3 [ ] -1 Do not release the packages because... BR, Jukka Zitting
Re: [VOTE] Release Apache Jackrabbit 1.2.3
Hi, On 3/5/07, Jukka Zitting [EMAIL PROTECTED] wrote: Please vote on releasing these packages as Apache Jackrabbit 1.2.3. [x] +1 Release the packages as Apache Jackrabbit 1.2.3 BR, Jukka Zitting
Re: [VOTE] Release Apache Jackrabbit 1.2.3
[x] +1 Release the packages as Apache Jackrabbit 1.2.3 -- GIT Consultors S.L. c\ Francesc Rover 2-B 07003 Palma de Mallorca (Illes Balears)
[jira] Created: (JCR-776) More verbose message on reference constraint violation
More verbose message on reference constraint violation -- Key: JCR-776 URL: https://issues.apache.org/jira/browse/JCR-776 Project: Jackrabbit Issue Type: Improvement Components: core Affects Versions: 1.2.2 Reporter: Christoph Kiehl -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-776) More verbose message on reference constraint violation
[ https://issues.apache.org/jira/browse/JCR-776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christoph Kiehl updated JCR-776: Attachment: patch.txt This patch is just a proposal. Please review More verbose message on reference constraint violation -- Key: JCR-776 URL: https://issues.apache.org/jira/browse/JCR-776 Project: Jackrabbit Issue Type: Improvement Components: core Affects Versions: 1.2.2 Reporter: Christoph Kiehl Attachments: patch.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-741) Handling of multiple residual prop defs in EffectiveNodeTypeImpl
[ 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.
Spec compliance regarding child node types of nt:frozenNode
Hi all, When checking in a versionable Node A, with a child B (OnParentVersion=COPY) of whatever nodetype, the corresponding nt:frozenNode has a child node B of type nt:frozenNode and not of its initial nodetype. From the JCR spec, section 8.2.11.1 : On checkin of N, C and all its descendent items, down to the leaves of the subtree, will be copied to the version storage as a child subtree of VN. By copy I also understood the copy of the nodetypes of the child nodes of the versionable node. I'm wondering if the currently implemented behaviour is compliant with the spec ? Or am I missing something ? Regards, -- Cédric Damioli ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 73 47 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com
Re: Spec compliance regarding child node types of nt:frozenNode
hi, there was a lot of arguing respecting how to organize the version storage. i don't know if it's explicitly mentioned in the spec, but the problem is, that the frozen nodes can't have neither the original uuid nor primary or mixin types, because constraints can't be enforced (e.g. missing opv=vesion child nodes). therefor the frozen nodes have the primary type nt:frozenNode and the original nodetype is recorded in the jcr:frozenPrimaryType. the same is true for references that are not enforced in the version storage (otherwise you could not delete a node just because it's referenced in a version of anode node). however, assigning the original nodetype to a frozen node might be possible in jackrabbit, it might certainly not work in all other repositories. regards, toby On 3/5/07, Cédric Damioli [EMAIL PROTECTED] wrote: Hi all, When checking in a versionable Node A, with a child B (OnParentVersion=COPY) of whatever nodetype, the corresponding nt:frozenNode has a child node B of type nt:frozenNode and not of its initial nodetype. From the JCR spec, section 8.2.11.1 : On checkin of N, C and all its descendent items, down to the leaves of the subtree, will be copied to the version storage as a child subtree of VN. By copy I also understood the copy of the nodetypes of the child nodes of the versionable node. I'm wondering if the currently implemented behaviour is compliant with the spec ? Or am I missing something ? Regards, -- Cédric Damioli ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 73 47 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: Spec compliance regarding child node types of nt:frozenNode
On 3/5/07, Cédric Damioli [EMAIL PROTECTED] wrote: When checking in a versionable Node A, with a child B (OnParentVersion=COPY) of whatever nodetype, the corresponding nt:frozenNode has a child node B of type nt:frozenNode and not of its initial nodetype. I recently noticed this too and, if I am not wrong, the behavior of jackrabbit 1.0.x was different. Only in recent builds (surely with 1.2.x, not tested on 1.1.x) child nodes seems to inherit the nt:frozenNode nodetype, while in 1.0 they keep the original nodetype. I couldn't find any trace of this change in release notes so I am not sure this is intentional... specs are not really clear about that... does anybody know the reason for such change or it could simply be a bug? fabrizio
