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]
