Yes I can confirm that using the DefaultAccessManager in Sling trunk without any other modifications or code results in the same problem. The question that remains is why?
Ian On 29 Dec 2009, at 11:02, Ian Boston wrote: > In my repository.xml I have > > <AccessManager > class="org.apache.jackrabbit.core.security.DefaultAccessManager"> > > if I change it to > > <AccessManager > class="org.apache.sling.jcr.jackrabbit.server.impl.security.PluggableDefaultAccessManager"> > > the problem goes away, I am just checking that I can reproduce the problem > with unmodified Sling. If I can this is a bit odd since IIRC the > PluggableDefaultAccessManager simply delegates to the DefaultAccessManager > and has nothing to do with the hierarchy manager ? > > Ian > > On 27 Dec 2009, at 23:45, Alexander Klimetschek wrote: > >> The problem sounds a bit like >> https://issues.apache.org/jira/browse/JCR-2321 but I am not sure if it >> really is the same issue, as JCR-2321 depended on the specific >> implementation of an AccessManager. >> >> Regards, >> Alex >> >> On Wed, Dec 23, 2009 at 17:27, Ian Boston <[email protected]> wrote: >>> To confirm. >>> In my local bundling of Sling, which fails. >>> >>> New Node ID is >>> Old Node is 5bc87894-135e-4363-83ce-d5548e727104 >>> New Node is 095b58ec-297f-41d1-867e-0042bf132769 >>> Session node is 5bc87894-135e-4363-83ce-d5548e727104 >>> Same as old node (which it should not be) >>> >>> And from the Sling standalone launchpad app >>> Old Node is d7232acd-dd13-4c4f-b78f-f6f00d0c561d >>> New Node is bc3922f3-ef1a-410d-8019-64545ccd8eab >>> Session node is bc3922f3-ef1a-410d-8019-64545ccd8eab >>> ie Same as New node, >>> >>> >>> Old node is nodeID at time of removal, retrieved by parentNode.getNode(...) >>> New Node is hte nodeID of the node just after its added to the parentNode >>> with parentNode.addNode(...) >>> Session node is the node ID used in session.getItem(...) >>> >>> The server bundle in each instance has the same set of jars in its private >>> classpath, and the same set of imports. >>> >>> It does have a customized access control manager, and does export some >>> extra classes. >>> >>> Everything else is working perfectly. (we have a large set of Ruby based >>> integration tests with a few 100 ACL related tests that runs for about 5 >>> mins but this is the only failure) >>> >>> Ian >>> >>> On 23 Dec 2009, at 15:59, Ian Boston wrote: >>> >>>> I have a problem that I cant reproduce in Sling, but can reproduce in my >>>> local packaging of the same Sling components, and was wondering if anyone >>>> had some insights. >>>> >>>> The steps are >>>> create 2 nodes >>>> /a1 >>>> /a2 >>>> Then copy /a1 onto /a2 with overwrite = true using >>>> curl -F:operation=copy -F:dest=/a2 -F:replace=true >>>> http://admin:ad...@localhost:8080/a1 >>>> >>>> >>>> Tracing the code through, >>>> >>>> The copy operation succeeds but session.getItem("/a2") in the call or >>>> oderNode line 136 of AbstractCopyOperation fails, PathNotFound >>>> >>>> in more detail >>>> Node /a2 is removed and re-added (new node UUID) but >>>> session.getItem("/a2") tried to load the original node UUID, not the new >>>> node UUID. >>>> >>>> session.getItem("/a2") uses the hierachyManger to get the node ID. >>>> >>>> --------------------------- >>>> Any Ideas ? >>>> >>>> AFAICT, all jars are identical JR in Sling and the local Packaging, and >>>> this is a 100% clean startup. >>>> >>>> Ian >>> >>> >> >> -- >> Alexander Klimetschek >> [email protected] >
