Re: AccessControlUtil.addEntry(), @scr private=, deactivate bundles in mvn?

2009-03-18 Thread Marc Speck
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 eric.d.nor...@gmail.comwrote:

 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 marcsp...@gmail.com 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: JCR/Sling meetup in Amsterdam, confirmed? (was: sling for apachecon site)

2009-03-18 Thread Jukka Zitting
Hi,

The latest sign up figures look more promising and we've secured
sponsors for the meetup, so let's go forward with the event.

To reduce the conflict with the Lucene meetup that at least a few of
us would like to attend and to give late arrivals a better chance to
attend the JCR meetup, I suggest that we start the meetup only at 8pm
instead of the originally planned 7pm.

BR,

Jukka Zitting


Re: JCR/Sling meetup in Amsterdam, confirmed? (was: sling for apachecon site)

2009-03-18 Thread Vidar Ramdal
On Wed, Mar 18, 2009 at 12:03 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:

 The latest sign up figures look more promising and we've secured
 sponsors for the meetup, so let's go forward with the event.

 To reduce the conflict with the Lucene meetup that at least a few of
 us would like to attend and to give late arrivals a better chance to
 attend the JCR meetup, I suggest that we start the meetup only at 8pm
 instead of the originally planned 7pm.

On Tuesday 24th, right?


-- 
Vidar S. Ramdal vi...@idium.no - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway
+47 21 531941, ext 2070


Re: JCR/Sling meetup in Amsterdam, confirmed? (was: sling for apachecon site)

2009-03-18 Thread Jukka Zitting
Hi,

On Wed, Mar 18, 2009 at 12:33 PM, Vidar Ramdal vi...@idium.no wrote:
 On Wed, Mar 18, 2009 at 12:03 PM, Jukka Zitting jukka.zitt...@gmail.com 
 wrote:
 To reduce the conflict with the Lucene meetup that at least a few of
 us would like to attend and to give late arrivals a better chance to
 attend the JCR meetup, I suggest that we start the meetup only at 8pm
 instead of the originally planned 7pm.

 On Tuesday 24th, right?

Yes.

BR,

Jukka Zitting


[jira] Closed: (SLING-696) Add externalizeHref() to SlingHttpServletResponse

2009-03-18 Thread Alexander Klimetschek (JIRA)

 [ 
https://issues.apache.org/jira/browse/SLING-696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Klimetschek closed SLING-696.
---


 Add externalizeHref() to SlingHttpServletResponse
 -

 Key: SLING-696
 URL: https://issues.apache.org/jira/browse/SLING-696
 Project: Sling
  Issue Type: New Feature
  Components: API, Engine
Reporter: Alexander Klimetschek

 A SlingHttpServletResponse.externalizeHref() method, that correctly maps a 
 JCR resource path back to the URL that has to be used externally to access 
 that resource, would be very helpful for use in HTML rendering scripts and 
 servlets.
 The implementation would need to:
 - reverse map any resource resolver mappings, ie. call ResourceResolver.map()
 - add the servlet context path at the beginning
 - (maybe check if the resource actually exists)
 (I hope this list is complete)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (SLING-696) Add externalizeHref() to SlingHttpServletResponse

2009-03-18 Thread Alexander Klimetschek (JIRA)

 [ 
https://issues.apache.org/jira/browse/SLING-696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Klimetschek resolved SLING-696.
-

Resolution: Won't Fix

I think this can be closed as wontfix as the proper mechanisms are already 
present:

1) simple servlet api style: request.getContextPath() + path

2) aware of sling mappings (in new jcrresourcersolver): 
request.getResource().getResourceResolver().map(request, path)

 Add externalizeHref() to SlingHttpServletResponse
 -

 Key: SLING-696
 URL: https://issues.apache.org/jira/browse/SLING-696
 Project: Sling
  Issue Type: New Feature
  Components: API, Engine
Reporter: Alexander Klimetschek

 A SlingHttpServletResponse.externalizeHref() method, that correctly maps a 
 JCR resource path back to the URL that has to be used externally to access 
 that resource, would be very helpful for use in HTML rendering scripts and 
 servlets.
 The implementation would need to:
 - reverse map any resource resolver mappings, ie. call ResourceResolver.map()
 - add the servlet context path at the beginning
 - (maybe check if the resource actually exists)
 (I hope this list is complete)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Created: (SLING-892) Allow servlets to be registered with extensions for all request methods

2009-03-18 Thread Alexander Klimetschek (JIRA)
Allow servlets to be registered with extensions for all request methods
---

 Key: SLING-892
 URL: https://issues.apache.org/jira/browse/SLING-892
 Project: Sling
  Issue Type: Improvement
  Components: Servlets Resolver
Reporter: Alexander Klimetschek


As SLING-754 introduced/fixed registering servlets for non-GET methods with 
selectors (eg. /apps/myapp/selector.POST.servlet), the same should be possible 
for extensions: /apps/myapp/extension.POST.servlet

Use case: symmetric URLs when you import and export stuff at a given resource 
path:

Export = GET @ /some/path/foo.ext
Import/Update = POST @ /some/path/foo.ext

Currently you are forced to either use a selector for the POST case 
(/some/path/foo.ext.ext) or to have a sling resource type set on the 
/some/path/foo, but then you could only have a single POST servlet for that 
resource type, regardless of the extension (which is unpractical if you for 
example have a resource type like calendar, but want to import various 
calendar formats, separated by their file extension).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



Re: AccessControlUtil.addEntry(), @scr private=, deactivate bundles in mvn?

2009-03-18 Thread 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.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 

[jira] Updated: (SLING-879) New Bundle to provide actions for interacting with the jackrabbit AccessManager

2009-03-18 Thread Juan Jose Vazquez Delgado (JIRA)

 [ 
https://issues.apache.org/jira/browse/SLING-879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Juan Jose Vazquez Delgado updated SLING-879:


Remaining Estimate: 0h
 Original Estimate: 0h

jackrabbit-accessmanager bundle created in trunk (rev. 755539). Integration 
tests stuff not applied because fail. Leave this issue opened until integration 
tests pass. 

 New Bundle to provide actions for interacting with the jackrabbit 
 AccessManager
 ---

 Key: SLING-879
 URL: https://issues.apache.org/jira/browse/SLING-879
 Project: Sling
  Issue Type: New Feature
  Components: Servlets Get, Servlets Post
Reporter: Eric Norman
 Attachments: accessManager_patch.diff, 
 org.apache.sling.jcr.jackrabbit.accessmanager.zip

   Original Estimate: 0h
  Remaining Estimate: 0h

 This is a new bundle that provides servlets to support modifying the 
 jackrabbit access control policies for JCR nodes.
 1. The servlet bound to [nodePath].modifyAce.html can be invoked to add or 
 modify the access control privileges for a given principal.
 2. The servlet bound to [nodePath].deleteAce.html can be invoked to remove 
 the access control entries for one or more principals.
 3. The servlet bound to [nodePath].acl.json can be invoked to get a JSON 
 representation of the ACL for a node.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



Re: AccessControlUtil.addEntry(), @scr private=, deactivate bundles in mvn?

2009-03-18 Thread Eric Norman
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 juanjo.vazq...@gmail.com

 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
 

[jira] Commented: (SLING-891) Some usermanager integration tests are failing

2009-03-18 Thread Eric Norman (JIRA)

[ 
https://issues.apache.org/jira/browse/SLING-891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12683332#action_12683332
 ] 

Eric Norman commented on SLING-891:
---

The usermanager_as_servlets.zip patch attached to SLING-875 should fix these 
integration tests as well.

 Some usermanager integration tests are failing
 --

 Key: SLING-891
 URL: https://issues.apache.org/jira/browse/SLING-891
 Project: Sling
  Issue Type: Bug
  Components: Testing
Affects Versions: 3
 Environment: Maven version: 2.0.10
 Java version: 1.5.0_14
 OS name: windows vista version: 6.0 arch: x86 Family: windows
Reporter: Juan Jose Vazquez Delgado
   Original Estimate: 0h
  Remaining Estimate: 0h

 mvn clean install in trunk fails for me:
 Results :
 Failed tests:
   
 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)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.