Re: AccessControlUtil.addEntry(), @scr private=, deactivate bundles in mvn?
> Hmm. I don't know what is different. It seems to work for me. I just > checked out the latest code to an empty folder and ran a clean build and I > got this result from the integration tests: > > Tests run: 235, Failures: 0, Errors: 0, Skipped: 0 >> > > And then I applied the "accessManager_patch.diff" patch from SLING-879 and > ran the clean build again and got this: > > Tests run: 239, Failures: 0, Errors: 0, Skipped: 0 Eric, finally it seems to be a memory problem. I configured MAVEN_OPTS=-Xmx512M and clean build doesn´t fail anymore. I applied and commited the access manager integration tests patched in SLING-879 [1] (rev. 756376). Anyway, I´m concerned about memory requirements when integration tests are executed. Thanks Eric, BR, Juanjo. [1] https://issues.apache.org/jira/browse/SLING-879
Re: AccessControlUtil.addEntry(), @scr private=, deactivate bundles in mvn?
Hmm. I don't know what is different. It seems to work for me. I just checked out the latest code to an empty folder and ran a clean build and I got this result from the integration tests: Tests run: 235, Failures: 0, Errors: 0, Skipped: 0 > And then I applied the "accessManager_patch.diff" patch from SLING-879 and ran the clean build again and got this: Tests run: 239, Failures: 0, Errors: 0, Skipped: 0 > Is anyone else seeing any failing integration tests? -Eric 2009/3/19 Juan José Vázquez Delgado > > that's odd. I didn't get any errors when I ran the clean build. Inside > the > > "usermanager_as_servlet.zip" file, there were two patches. Did you apply > > both of those .diff files? It seems like you may be missing the changes > > that were made to the integration tests. > > I applied and commited both of them but integration tests continue > failing for me. Any idea? > > BR, > > Juanjo. >
Re: AccessControlUtil.addEntry(), @scr private=, deactivate bundles in mvn?
> that's odd. I didn't get any errors when I ran the clean build. Inside the > "usermanager_as_servlet.zip" file, there were two patches. Did you apply > both of those .diff files? It seems like you may be missing the changes > that were made to the integration tests. I applied and commited both of them but integration tests continue failing for me. Any idea? BR, Juanjo.
Re: AccessControlUtil.addEntry(), @scr private=, deactivate bundles in mvn?
that's odd. I didn't get any errors when I ran the clean build. Inside the "usermanager_as_servlet.zip" file, there were two patches. Did you apply both of those .diff files? It seems like you may be missing the changes that were made to the integration tests. --- T E S T S --- Running org.apache.sling.launchpad.webapp.integrationtest.servlets.post.SlingAutoPropertiesTest Checking if the required Sling services are started... (base URLs= http://localhost:/org.apache.sling.launchpad.testing-4-incubator-SNAPSHOTand http://localhost:/org.a pache.sling.launchpad.testing-4-incubator-SNAPSHOT) Sling services seem to be started, continuing with integration tests. Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 32.359 sec Running org.apache.sling.launchpad.webapp.integrationtest.PropertyRenderingTest Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1 sec Running org.apache.sling.launchpad.webapp.integrationtest.JsonRenderingTest Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.516 sec Running org.apache.sling.launchpad.webapp.integrationtest.accessManager.RemoveAcesTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.625 sec Running org.apache.sling.launchpad.webapp.integrationtest.NodetypeRenderingTest Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.421 sec Running org.apache.sling.launchpad.webapp.integrationtest.ValueFromTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.235 sec Running org.apache.sling.launchpad.webapp.integrationtest.servlets.post.PostServletCreateTest Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.453 sec Running org.apache.sling.launchpad.webapp.integrationtest.servlets.post.PostServletOrderTest Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.234 sec Running org.apache.sling.launchpad.webapp.integrationtest.servlets.post.SlingDateValuesTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.203 sec Running org.apache.sling.launchpad.webapp.integrationtest.servlets.post.PostServletCopyTest Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.453 sec Running org.apache.sling.launchpad.webapp.integrationtest.SyntheticResourceTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.156 sec Running org.apache.sling.launchpad.webapp.integrationtest.userManager.UpdateGroupTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.297 sec Running org.apache.sling.launchpad.webapp.integrationtest.servlets.post.PostServletAtMoveTest Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.657 sec Running org.apache.sling.launchpad.webapp.integrationtest.HttpPingTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.046 sec Running org.apache.sling.launchpad.webapp.integrationtest.RedirectTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.188 sec Running org.apache.sling.launchpad.webapp.integrationtest.servlets.post.PostServletAtCopyTest Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.281 sec Running org.apache.sling.launchpad.webapp.integrationtest.accessManager.ModifyAceTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.406 sec Running org.apache.sling.launchpad.webapp.integrationtest.CreateNodeTest Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.297 sec Running org.apache.sling.launchpad.webapp.integrationtest.servlets.post.SlingDefaultValuesTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.265 sec Running org.apache.sling.launchpad.webapp.integrationtest.servlets.post.SlingSessionInfoTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec Running org.apache.sling.launchpad.webapp.integrationtest.StaticContentTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec Running org.apache.sling.launchpad.webapp.integrationtest.JspIncludeTest 48422 [main] WARN org.apache.commons.httpclient.HttpMethodBase - Going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended. 54875 [main] WARN org.apache.commons.httpclient.HttpMethodBase - Going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended. Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 11.547 sec Running org.apache.sling.launchpad.webapp.integrationtest.StreamServletTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.266 sec Running org.apache.sling.launchpad.webapp.integrationtest.issues.SLING760Test Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.547 sec Running org.apache.sling.launchpad.webapp.integrationtest.userManager.UpdateUserTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.281 sec Running org.apa
Re: AccessControlUtil.addEntry(), @scr private=, deactivate bundles in mvn?
Hi Eric, > Thanks for applying the accessmanager bundle. You´re welcome. > I took a look at the unit > test failures and I think I see what the issue is. When I wrote those tests > I had the latest patch from SLING-875 (see usermanager_as_servlets.zip) > already applied. So the test code that creates the users and groups used to > test updating the ACL was relying on the changes from the > usermanager_as_servlets patch. > > Can you (or someone else) review the SLING-875 patch and apply those changes > along with the accessmanager integration tests from SLING-879? > > I think the SLING-875 patch also fixes SLING-891 so we could probably > resolve those 3 issues at the same time... I have applied in my environment "usermanager_as_servlet.zip" found in SLING-875 and the integration tests fail [1]. Is this working for you?. BR, Juanjo. [1] Results : Failed tests: testUpdateGroup(org.apache.sling.launchpad.webapp.integrationtest.userManager.UpdateGroupTest) testUpdateGroupMembers(org.apache.sling.launchpad.webapp.integrationtest.userManager.UpdateGroupTest) testUpdateUser(org.apache.sling.launchpad.webapp.integrationtest.userManager.UpdateUserTest) testChangeUserPassword(org.apache.sling.launchpad.webapp.integrationtest.userManager.UpdateUserTest) testChangeUserPasswordWrongOldPwd(org.apache.sling.launchpad.webapp.integrationtest.userManager.UpdateUserTest) testChangeUserPasswordWrongConfirmPwd(org.apache.sling.launchpad.webapp.integrationtest.userManager.UpdateUserTest) testCreateUser(org.apache.sling.launchpad.webapp.integrationtest.userManager.CreateUserTest) testCreateUserMissingUserId(org.apache.sling.launchpad.webapp.integrationtest.userManager.CreateUserTest) testCreateUserMissingPwd(org.apache.sling.launchpad.webapp.integrationtest.userManager.CreateUserTest) testCreateUserWrongConfirmPwd(org.apache.sling.launchpad.webapp.integrationtest.userManager.CreateUserTest) testCreateUserUserAlreadyExists(org.apache.sling.launchpad.webapp.integrationtest.userManager.CreateUserTest) testCreateUserWithExtraProperties(org.apache.sling.launchpad.webapp.integrationtest.userManager.CreateUserTest) testCreateGroup(org.apache.sling.launchpad.webapp.integrationtest.userManager.CreateGroupTest) testCreateGroupMissingGroupId(org.apache.sling.launchpad.webapp.integrationtest.userManager.CreateGroupTest) testCreateGroupAlreadyExists(org.apache.sling.launchpad.webapp.integrationtest.userManager.CreateGroupTest) testCreateGroupWithExtraProperties(org.apache.sling.launchpad.webapp.integrationtest.userManager.CreateGroupTest) testRemoveUser(org.apache.sling.launchpad.webapp.integrationtest.userManager.RemoveAuthorizablesTest) testRemoveGroup(org.apache.sling.launchpad.webapp.integrationtest.userManager.RemoveAuthorizablesTest) testRemoveAuthorizables(org.apache.sling.launchpad.webapp.integrationtest.userManager.RemoveAuthorizablesTest) Tests run: 235, Failures: 19, Errors: 0, Skipped: 0
Re: AccessControlUtil.addEntry(), @scr private=, deactivate bundles in mvn?
Hi Junajo, Thanks for applying the accessmanager bundle. I took a look at the unit test failures and I think I see what the issue is. When I wrote those tests I had the latest patch from SLING-875 (see usermanager_as_servlets.zip) already applied. So the test code that creates the users and groups used to test updating the ACL was relying on the changes from the usermanager_as_servlets patch. Can you (or someone else) review the SLING-875 patch and apply those changes along with the accessmanager integration tests from SLING-879? I think the SLING-875 patch also fixes SLING-891 so we could probably resolve those 3 issues at the same time... Regards, -Eric ** 2009/3/18 Juan José Vázquez Delgado > Hi Eric, > > > Yes, it seemed to be working for me. I was using that method in the > patch I > > submitted for SLING-879 > > I have added the jackrabbit-accessmanager stuff into trunk (rev. > 755539). I have run some testing and everything seems to be ok. Cool > stuff, thank you!. > > Although, I haven´t applied the integration tests patch because they > are failing [1]. Please, tell me if you see the reason at first sight. > > BR, > > Juanjo. > > [1] > > > --- > Test set: > org.apache.sling.launchpad.webapp.integrationtest.accessManager.ModifyAceTest > > --- > Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 23.538 > sec <<< FAILURE! > > testModifyAceForUser(org.apache.sling.launchpad.webapp.integrationtest.accessManager.ModifyAceTest) > Time elapsed: 23.514 sec <<< FAILURE! > junit.framework.AssertionFailedError: expected:<200> but was:<500> >at junit.framework.Assert.fail(Assert.java:47) >at junit.framework.Assert.failNotEquals(Assert.java:277) >at junit.framework.Assert.assertEquals(Assert.java:64) >at junit.framework.Assert.assertEquals(Assert.java:195) >at junit.framework.Assert.assertEquals(Assert.java:201) >at > org.apache.sling.launchpad.webapp.integrationtest.accessManager.AbstractAccessManagerTest.assertAuthenticatedPostStatus(AbstractAccessManagerTest.java:65) >at > org.apache.sling.launchpad.webapp.integrationtest.accessManager.ModifyAceTest.testModifyAceForUser(ModifyAceTest.java:81) >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >at java.lang.reflect.Method.invoke(Method.java:585) >at junit.framework.TestCase.runTest(TestCase.java:168) >at junit.framework.TestCase.runBare(TestCase.java:134) >at junit.framework.TestResult$1.protect(TestResult.java:110) >at junit.framework.TestResult.runProtected(TestResult.java:128) >at junit.framework.TestResult.run(TestResult.java:113) >at junit.framework.TestCase.run(TestCase.java:124) >at junit.framework.TestSuite.runTest(TestSuite.java:232) >at junit.framework.TestSuite.run(TestSuite.java:227) >at > org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:76) >at > org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) >at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) >at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) >at org.apache.maven.surefire.Surefire.run(Surefire.java:177) >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >at java.lang.reflect.Method.invoke(Method.java:585) >at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345) >at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009) > > > testModifyAceForGroup(org.apache.sling.launchpad.webapp.integrationtest.accessManager.ModifyAceTest) > Time elapsed: 0.016 sec <<< FAILURE! > junit.framework.AssertionFailedError: expected:<200> but was:<201> >at junit.framework.Assert.fail(Assert.java:47) >at junit.framework.Assert.failNotEquals(Assert.java:277) >at junit.framework.Assert.assertEquals(Assert.java:64) >at junit.framework.Assert.assertEquals(Assert.java:195) >at junit.framework.Assert.assertEquals(Assert.java:201) >at > org.apache.sling.launchpad.webapp.integrationtest.accessManager.AbstractAccessManagerTest.assertAuthenticatedPostStatus(AbstractAccessManagerTest.java:65) >at > org.apache.sling.launchpad.webapp.integrationtest.ac
Re: AccessControlUtil.addEntry(), @scr private=, deactivate bundles in mvn?
Hi Eric, > Yes, it seemed to be working for me. I was using that method in the patch I > submitted for SLING-879 I have added the jackrabbit-accessmanager stuff into trunk (rev. 755539). I have run some testing and everything seems to be ok. Cool stuff, thank you!. Although, I haven´t applied the integration tests patch because they are failing [1]. Please, tell me if you see the reason at first sight. BR, Juanjo. [1] --- Test set: org.apache.sling.launchpad.webapp.integrationtest.accessManager.ModifyAceTest --- Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 23.538 sec <<< FAILURE! testModifyAceForUser(org.apache.sling.launchpad.webapp.integrationtest.accessManager.ModifyAceTest) Time elapsed: 23.514 sec <<< FAILURE! junit.framework.AssertionFailedError: expected:<200> but was:<500> at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:277) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:195) at junit.framework.Assert.assertEquals(Assert.java:201) at org.apache.sling.launchpad.webapp.integrationtest.accessManager.AbstractAccessManagerTest.assertAuthenticatedPostStatus(AbstractAccessManagerTest.java:65) at org.apache.sling.launchpad.webapp.integrationtest.accessManager.ModifyAceTest.testModifyAceForUser(ModifyAceTest.java:81) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:76) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009) testModifyAceForGroup(org.apache.sling.launchpad.webapp.integrationtest.accessManager.ModifyAceTest) Time elapsed: 0.016 sec <<< FAILURE! junit.framework.AssertionFailedError: expected:<200> but was:<201> at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:277) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:195) at junit.framework.Assert.assertEquals(Assert.java:201) at org.apache.sling.launchpad.webapp.integrationtest.accessManager.AbstractAccessManagerTest.assertAuthenticatedPostStatus(AbstractAccessManagerTest.java:65) at org.apache.sling.launchpad.webapp.integrationtest.accessManager.AbstractAccessManagerTest.createTestGroup(AbstractAccessManagerTest.java:178) at org.apache.sling.launchpad.webapp.integrationtest.accessManager.ModifyAceTest.testModifyAceForGroup(ModifyAceTest.java:106) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at juni
Re: AccessControlUtil.addEntry(), @scr private=, deactivate bundles in mvn?
Appreciate your feedback, Eric. Once the code is committed, I will study your implementation. Marc On Tue, Mar 17, 2009 at 6:48 PM, Eric Norman wrote: > Yes, it seemed to be working for me. I was using that method in the patch > I > submitted for SLING-879 > > > On Tue, Mar 17, 2009 at 7:33 AM, Marc Speck wrote: > > > I've just tested the patch and got the following error message: > > > > ... javax.jcr.RepositoryException: addEntry: > > > > > org.apache.jackrabbit.core.security.authorization.acl.ACLTemplate.addEntry(): > > > > > org.apache.jackrabbit.core.security.authorization.acl.ACLTemplate.addEntry() > >at > > > > > org.apache.sling.jcr.base.util.AccessControlUtil.safeInvokeRepoMethod(AccessControlUtil.java:233) > >at > > > > > org.apache.sling.jcr.base.util.AccessControlUtil.addEntry(AccessControlUtil.java:184) > > ... > > Caused by: java.lang.NoSuchMethodException: > > > > > org.apache.jackrabbit.core.security.authorization.acl.ACLTemplate.addEntry() > >at java.lang.Class.getMethod(Unknown Source) > >at > > > > > org.apache.sling.jcr.base.util.AccessControlUtil.safeInvokeRepoMethod(AccessControlUtil.java:211) > >... 32 more > > java.lang.NoSuchMethodException: > > > > > org.apache.jackrabbit.core.security.authorization.acl.ACLTemplate.addEntry() > >at java.lang.Class.getMethod(Unknown Source) > >at > > > > > org.apache.sling.jcr.base.util.AccessControlUtil.safeInvokeRepoMethod(AccessControlUtil.java:211) > >at > > > > > org.apache.sling.jcr.base.util.AccessControlUtil.addEntry(AccessControlUtil.java:184) > > ... > > > > > > Has anybody successfully used AccessControlUtil.addEntry()? I used the > code > > posted in my initial mail (there are also some more question ;) > > Thanks, > > Marc > > > > > > > > > > On Mon, Feb 23, 2009 at 7:48 PM, Juan José Vázquez Delgado < > > juanjo.vazq...@gmail.com> wrote: > > > > > > Thanks for the quick fix, Juanjo. Once I update to the new Sling > > > structure, > > > > I'll test it. > > > > Marc > > > > > > You´re welcome. Please report any issues about it. > > > > > > Regards, > > > > > > Juanjo. > > > > > >
Re: AccessControlUtil.addEntry(), @scr private=, deactivate bundles in mvn?
Yes, it seemed to be working for me. I was using that method in the patch I submitted for SLING-879 On Tue, Mar 17, 2009 at 7:33 AM, Marc Speck wrote: > I've just tested the patch and got the following error message: > > ... javax.jcr.RepositoryException: addEntry: > > org.apache.jackrabbit.core.security.authorization.acl.ACLTemplate.addEntry(): > > org.apache.jackrabbit.core.security.authorization.acl.ACLTemplate.addEntry() >at > > org.apache.sling.jcr.base.util.AccessControlUtil.safeInvokeRepoMethod(AccessControlUtil.java:233) >at > > org.apache.sling.jcr.base.util.AccessControlUtil.addEntry(AccessControlUtil.java:184) > ... > Caused by: java.lang.NoSuchMethodException: > > org.apache.jackrabbit.core.security.authorization.acl.ACLTemplate.addEntry() >at java.lang.Class.getMethod(Unknown Source) >at > > org.apache.sling.jcr.base.util.AccessControlUtil.safeInvokeRepoMethod(AccessControlUtil.java:211) >... 32 more > java.lang.NoSuchMethodException: > > org.apache.jackrabbit.core.security.authorization.acl.ACLTemplate.addEntry() >at java.lang.Class.getMethod(Unknown Source) >at > > org.apache.sling.jcr.base.util.AccessControlUtil.safeInvokeRepoMethod(AccessControlUtil.java:211) >at > > org.apache.sling.jcr.base.util.AccessControlUtil.addEntry(AccessControlUtil.java:184) > ... > > > Has anybody successfully used AccessControlUtil.addEntry()? I used the code > posted in my initial mail (there are also some more question ;) > Thanks, > Marc > > > > > On Mon, Feb 23, 2009 at 7:48 PM, Juan José Vázquez Delgado < > juanjo.vazq...@gmail.com> wrote: > > > > Thanks for the quick fix, Juanjo. Once I update to the new Sling > > structure, > > > I'll test it. > > > Marc > > > > You´re welcome. Please report any issues about it. > > > > Regards, > > > > Juanjo. > > >
Re: AccessControlUtil.addEntry(), @scr private=, deactivate bundles in mvn?
I've just tested the patch and got the following error message: ... javax.jcr.RepositoryException: addEntry: org.apache.jackrabbit.core.security.authorization.acl.ACLTemplate.addEntry(): org.apache.jackrabbit.core.security.authorization.acl.ACLTemplate.addEntry() at org.apache.sling.jcr.base.util.AccessControlUtil.safeInvokeRepoMethod(AccessControlUtil.java:233) at org.apache.sling.jcr.base.util.AccessControlUtil.addEntry(AccessControlUtil.java:184) ... Caused by: java.lang.NoSuchMethodException: org.apache.jackrabbit.core.security.authorization.acl.ACLTemplate.addEntry() at java.lang.Class.getMethod(Unknown Source) at org.apache.sling.jcr.base.util.AccessControlUtil.safeInvokeRepoMethod(AccessControlUtil.java:211) ... 32 more java.lang.NoSuchMethodException: org.apache.jackrabbit.core.security.authorization.acl.ACLTemplate.addEntry() at java.lang.Class.getMethod(Unknown Source) at org.apache.sling.jcr.base.util.AccessControlUtil.safeInvokeRepoMethod(AccessControlUtil.java:211) at org.apache.sling.jcr.base.util.AccessControlUtil.addEntry(AccessControlUtil.java:184) ... Has anybody successfully used AccessControlUtil.addEntry()? I used the code posted in my initial mail (there are also some more question ;) Thanks, Marc On Mon, Feb 23, 2009 at 7:48 PM, Juan José Vázquez Delgado < juanjo.vazq...@gmail.com> wrote: > > Thanks for the quick fix, Juanjo. Once I update to the new Sling > structure, > > I'll test it. > > Marc > > You´re welcome. Please report any issues about it. > > Regards, > > Juanjo. >
Re: AccessControlUtil.addEntry(), @scr private=, deactivate bundles in mvn?
> Thanks for the quick fix, Juanjo. Once I update to the new Sling structure, > I'll test it. > Marc You´re welcome. Please report any issues about it. Regards, Juanjo.
Re: AccessControlUtil.addEntry(), @scr private=, deactivate bundles in mvn?
Thanks for the quick fix, Juanjo. Once I update to the new Sling structure, I'll test it. Marc On Mon, Feb 23, 2009 at 2:14 PM, Juan José Vázquez Delgado < juanjo.vazq...@gmail.com> wrote: > > You mean it's not supported with addAccessControlEntry()? At least > > AccessControlUtil.addEntry() offers a method to apply restrictions. I > guess > > it calls ACLTemplate.addEntry() (that implements > > JackrabbitAccessControlList) and there is a signature that accepts > > "isAllow". > > There are 2 methods in jackrabbit core (ACLTemplate) to deal with this: > > (1) public boolean addEntry(Principal principal, Privilege[] > privileges, boolean isAllow) and > > (2) public boolean addEntry(Principal principal, Privilege[] > privileges, boolean isAllow, Map restrictions) > > For the time being, Jackrabbit 1.5 only supports to invoke the first > one or the second one without restrictions (restrictions = null). > These features belong to jsr-283 specification (AKA JCR 2.0) [1] and > the Jackrabbit implemention is only a developer preview. > > > So if it is really not possible to apply restrictions, I suggest > > removing the isAllow parameter from AccessControlUtil.addEntry(). Though > I > > think there might be just a problem floating around the > > AccessControlUtil.addEntry(). > > In the other hand, we are using reflection to invoke > addEntry(Principal principal, Privilege[] privileges, boolean isAllow) > but this implemention has a bug. I have created an issue [2] to deal > with this problem. > > Please, follow the issue to know about their resolution. Sorry for the > problems. > > BR, > > Juanjo. > > [1] http://jcp.org/en/jsr/detail?id=283 > [2] https://issues.apache.org/jira/browse/SLING-867 >
Re: AccessControlUtil.addEntry(), @scr private=, deactivate bundles in mvn?
> You mean it's not supported with addAccessControlEntry()? At least > AccessControlUtil.addEntry() offers a method to apply restrictions. I guess > it calls ACLTemplate.addEntry() (that implements > JackrabbitAccessControlList) and there is a signature that accepts > "isAllow". There are 2 methods in jackrabbit core (ACLTemplate) to deal with this: (1) public boolean addEntry(Principal principal, Privilege[] privileges, boolean isAllow) and (2) public boolean addEntry(Principal principal, Privilege[] privileges, boolean isAllow, Map restrictions) For the time being, Jackrabbit 1.5 only supports to invoke the first one or the second one without restrictions (restrictions = null). These features belong to jsr-283 specification (AKA JCR 2.0) [1] and the Jackrabbit implemention is only a developer preview. > So if it is really not possible to apply restrictions, I suggest > removing the isAllow parameter from AccessControlUtil.addEntry(). Though I > think there might be just a problem floating around the > AccessControlUtil.addEntry(). In the other hand, we are using reflection to invoke addEntry(Principal principal, Privilege[] privileges, boolean isAllow) but this implemention has a bug. I have created an issue [2] to deal with this problem. Please, follow the issue to know about their resolution. Sorry for the problems. BR, Juanjo. [1] http://jcp.org/en/jsr/detail?id=283 [2] https://issues.apache.org/jira/browse/SLING-867
Re: AccessControlUtil.addEntry(), @scr private=, deactivate bundles in mvn?
> > > > I want to add restrictions to nodes > > (isAllow=false) . Is this possible with addAccessControlEntry()? > > I´m sorry Marc, for the time being this feature is not supported. > There are some problems with building a jackrabbit-core osgizied > bundle [1]. AFAIK, It´s planned to erase this restriction in next > major Jackrabbit release (2.0). You mean it's not supported with addAccessControlEntry()? At least AccessControlUtil.addEntry() offers a method to apply restrictions. I guess it calls ACLTemplate.addEntry() (that implements JackrabbitAccessControlList) and there is a signature that accepts "isAllow". So if it is really not possible to apply restrictions, I suggest removing the isAllow parameter from AccessControlUtil.addEntry(). Though I think there might be just a problem floating around the AccessControlUtil.addEntry(). Marc
Re: AccessControlUtil.addEntry(), @scr private=, deactivate bundles in mvn?
> Thanks for the answer, Juanjo. You´re welcome. > I want to add restrictions to nodes > (isAllow=false) . Is this possible with addAccessControlEntry()? I´m sorry Marc, for the time being this feature is not supported. There are some problems with building a jackrabbit-core osgizied bundle [1]. AFAIK, It´s planned to erase this restriction in next major Jackrabbit release (2.0). Although, I will have a look at "AccessControlUtil.addEntry" method. BR, Juanjo. [1] http://markmail.org/message/rqqouyr63bebhdjy
Re: AccessControlUtil.addEntry(), @scr private=, deactivate bundles in mvn?
Thanks for the answer, Juanjo. I use acl.addAccessControlEntry(userPrincipal, supportedPrivileges); in other places and it works fine. However, I want to add restrictions to nodes (isAllow=false) . Is this possible with addAccessControlEntry()? Marc On Wed, Feb 18, 2009 at 1:44 PM, Juan José Vázquez Delgado < juanjo.vazq...@gmail.com> wrote: > Hi Marc, > > > 1. AccessControlUtil.addEntry() throws "java.lang.NoSuchMethodException: > > > org.apache.jackrabbit.core.security.authorization.acl.ACLTemplate.addEntry()" > > as rootCause. I use > *;resolution:=optional > > for that bundle and the following code. > > > > accessController = AccessControlUtil.getAccessControlManager(session); > > AccessControlPolicyIterator applicablePolicies = > > accessController.getApplicablePolicies(pagePath); > > AccessControlList acl = (AccessControlList) > > applicablePolicies.nextAccessControlPolicy(); > > Privilege[] supportedPrivileges = > > accessController.getSupportedPrivileges(pagePath); > > AccessControlUtil.addEntry(acl, userPrincipal, supportedPrivileges, > false); > > accessController.setPolicy(pagePath, acl); > > > > What's wrong here? > > Please, you can try this instead: > > acl.addAccessControlEntry(userPrincipal, supportedPrivileges); > accessController.setPolicy(path_to_apply_policy, acl); > session.save(); > > where session is the opened jcr session over security workspace. > > Hope this helps. > > Regards, > > Juanjo.
Re: AccessControlUtil.addEntry(), @scr private=, deactivate bundles in mvn?
Hi Marc, > 1. AccessControlUtil.addEntry() throws "java.lang.NoSuchMethodException: > org.apache.jackrabbit.core.security.authorization.acl.ACLTemplate.addEntry()" > as rootCause. I use *;resolution:=optional > for that bundle and the following code. > > accessController = AccessControlUtil.getAccessControlManager(session); > AccessControlPolicyIterator applicablePolicies = > accessController.getApplicablePolicies(pagePath); > AccessControlList acl = (AccessControlList) > applicablePolicies.nextAccessControlPolicy(); > Privilege[] supportedPrivileges = > accessController.getSupportedPrivileges(pagePath); > AccessControlUtil.addEntry(acl, userPrincipal, supportedPrivileges, false); > accessController.setPolicy(pagePath, acl); > > What's wrong here? Please, you can try this instead: acl.addAccessControlEntry(userPrincipal, supportedPrivileges); accessController.setPolicy(path_to_apply_policy, acl); session.save(); where session is the opened jcr session over security workspace. Hope this helps. Regards, Juanjo.
