[ https://jira.jboss.org/jira/browse/DNA-563?page=com.atlassian.jira.plugin... ] Randall Hauch updated DNA-563: ------------------------------ Priority: Blocker (was: Major) Dan summarized what was in the JCR specifications: The requirements for generating events for children of nodes that have been added/removed/moved/copied seems to be different between JCR 1.0 to JCR 2.0. For JCR 1.0 it seems these events are required. For JCR 2.0 it they are optional. These 2 TCK observation tests are failing because of this: NodeRemovedTest.testMultiNodesRemoved WorkspaceOperationTest.testCopy Here are the spec details: 1. JSR 170 1.0 (JCR 1.0 11 May 2005) a. Section 8.3.7.1 Creating a new Node ... as well for each of the automatically created child nodes or properties (either NODE_ADDED or PROPERTY_ADDED, as the case may be). b. Section 8.3.7.4 Removing a Child Node ... Additionally, an implementation should also generate a NODE_REMOVE or PROPERTY_REMOVE (as appropriate) for each item in the removed subtree. c. Section 8.3.7.6 Copying a Subtree ... Additionally, an implementation should generate appropriate events for each resulting node and property addition in the copied subtree. d Section 8.3.7.7 Moving a Subtree ... Additionally, an implementation should generate a NODE_REMOVE or PROPERTY_REMOVE (as appropriate) for each node and property removed from its source path location and a NODE_ADDED or PROPERTY_ADDED (as appropriate) for each node and property added at its destination path location. e. Section 8.3.7.8 Re-ordering a set of Child Nodes ... Additionally, an implementation should generate appropriate events reflecting the "shifting over" of the node B and any nodes that come after it in the child node ordering. Each such shifted node would also produce a NODE_REMOVED and NODE_ADDED event pair with paths differing at most by a final index. 2. JSR 283 FCS (JCR 2.0 10 Aug 2009)- Section 12.2 Scope of Event Reporting The scope of event reporting is implementation-dependent. An implementation should make a best-effort attempt to report all events, but may exclude events if reporting them would be impractical given implementation or resource limitations. For example, on an import, move or remove of a subgraph containing a large number of items, an implementation may choose to report only events associated with the root node of the affected graph and not those for every subitem in the structure. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/DNA-563?page=com.atlassian.jira.plugin... ] Randall Hauch commented on DNA-563: ----------------------------------- This is a blocker for DNA-456 (Observation feature). Be sure to uncomment all the remaining observation-related unit and TCK tests. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/DNA-563?page=com.atlassian.jira.plugin... ] Randall Hauch commented on DNA-563: ----------------------------------- It seems intuitive that the LOE for each approach is about the same, primarily because the largest part of the effort is changing the connectors to determine the correct information. When considering whether to augment the original ChangeRequest or simply generate additional ChangeRequest objects in the event stream, it may be important to know what information is required. For example, a DeleteBranchRequest could be addressed by either adding a Collection<Location> for all nodes that were deleted, or it could be addressed by generating additional DeleteBranchRequest for each node. (This latter is a bit odd.) But for a CopyBranchRequest, the events need to know about the Location of each created node (for the NODE_ADDED event) and that node's property names (for the PROPERTY_ADDED events). So the augmenting approach could add a LinkedHashMap<Location,Set<Name>>, since that would retain the order of insertion of Location (which should probably be the top-down order of the nodes being created). Augmenting might actually work out better than generating extra events, especially because I think the existing ChangeRequest types won't fit our need well. Consider that we don't have a DeleteNodeRequest (because semantically when a node is deleted all nodes below it must also be deleted). CopyBranchRequest is similar: each connector would need to generate a CreateNodeRequest for each of the new nodes, but the CreateNodeRequest only has a slot for the collection of the Property objects whereas we only need the property names to generate the correct PROPERTY_ADDED events. We could require the event store the values, but that would increase the size of the Changes and seems unnecessary (especially for Binary objects) considering that we may not need the values on the Observer side (NetChangeObserver certainly does NOT need them) and that it may place an extra burden on the connectors to retrieve the values. I would tentatively vote for the 'augmenting' approach. It is more straightforward (a connector must simply fill out the information in each request) and thus easier for us to document and connector developers and Observer developers to understand the semantics (one request maps into one event). Before we go much further, however, I'd like to see a list of every ChangeRequest that is affected by this issue, and how it would be augmented to provide the information that is currently missing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira