[jira] [Commented] (SLING-2240) move org.apache.sling.servlets.post.impl.helper.DateParser to commons
[ https://issues.apache.org/jira/browse/SLING-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13486691#comment-13486691 ] Ian Boston commented on SLING-2240: --- I guess they should be made available. Thanks for reminding me. move org.apache.sling.servlets.post.impl.helper.DateParser to commons - Key: SLING-2240 URL: https://issues.apache.org/jira/browse/SLING-2240 Project: Sling Issue Type: Wish Components: Commons Affects Versions: Servlets Post 2.1.0 Reporter: Ben Peter Assignee: Ian Boston DateParser is a nice utility and comes in handy in a lot of cases. As such, it would be great to have it in a place where it is part of an exported package instead of being locked in in the private org.apache.sling.servlets.post.impl.helper -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSS] Proposal for a minimal access gate on resource level
2012/10/29 Alexander Klimetschek aklim...@adobe.com: On 29.10.2012, at 18:02, Carsten Ziegeler cziege...@apache.org wrote: And it's totally transparent and doesn't need any changes to the core. Depends on what you define as core. The proposal definitely mentions a change to the resource resolver core. No, the resource resolver does not need any change - it can be done by a resource decorator alone. Carsten On 26.10.2012, at 10:43, Mike Müller mike...@mysign.ch wrote: Okay, how should it work: First of all, if there's no registered ResourceAccessGateService, nothing changes. If one ore more ResourceAccessGateServices are registered Sling takes them in account as follows: Sling registers a ResourceDecorator and wraps with that service all resources into a AccessGateResourceWrapper. Couldn't a custom ResourceDecorator do this without any changes to the core resource bundles? Cheers, Alex -- Carsten Ziegeler cziege...@apache.org
[jira] [Updated] (SLING-2240) move org.apache.sling.servlets.post.impl.helper.DateParser to commons
[ https://issues.apache.org/jira/browse/SLING-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston updated SLING-2240: -- Attachment: SLING-2240.patch The patch moves the classes into the exported package and leaves a note in the Usermanager pom for when its dependencies are upgraded. I have not updated the exported version of the package. Maybee I should. Passes full build ok. move org.apache.sling.servlets.post.impl.helper.DateParser to commons - Key: SLING-2240 URL: https://issues.apache.org/jira/browse/SLING-2240 Project: Sling Issue Type: Wish Components: Commons Affects Versions: Servlets Post 2.1.0 Reporter: Ben Peter Assignee: Ian Boston Attachments: SLING-2240.patch DateParser is a nice utility and comes in handy in a lot of cases. As such, it would be great to have it in a place where it is part of an exported package instead of being locked in in the private org.apache.sling.servlets.post.impl.helper -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: [DISCUSS] Proposal for a minimal access gate on resource level
And it's totally transparent and doesn't need any changes to the core. Depends on what you define as core. The proposal definitely mentions a change to the resource resolver core. No existing API will be changed. The changes are only under the hood. These changes only come to life if someone implements a ResourceAccessGateService. The proposal only suggest a new service interface which can be implemented by a user of sling or not. In the case of not using this service, nothing changes from an API-view. On 26.10.2012, at 10:43, Mike Müller mike...@mysign.ch wrote: Okay, how should it work: First of all, if there's no registered ResourceAccessGateService, nothing changes. If one ore more ResourceAccessGateServices are registered Sling takes them in account as follows: Sling registers a ResourceDecorator and wraps with that service all resources into a AccessGateResourceWrapper. Couldn't a custom ResourceDecorator do this without any changes to the core resource bundles? A custom ResourceDecorator can not do the same job. There are different issues. You can't write a ResourceDecorator only for a specific path, so to restrict access for resources under /my/resources/only-during-day/ you have to write a ResourceDecorator which wraps all resources from every path, which is a lot of overhead. With the proposed ResourceAccessGateService only resources with restrictions will be wrapped. Finally the proposal is about to let the user define restrictions for all CRUD operations, not only read. best regards mike
[jira] [Commented] (SLING-2240) move org.apache.sling.servlets.post.impl.helper.DateParser to commons
[ https://issues.apache.org/jira/browse/SLING-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13486722#comment-13486722 ] Carsten Ziegeler commented on SLING-2240: - Yes, the exported version needs to be changed move org.apache.sling.servlets.post.impl.helper.DateParser to commons - Key: SLING-2240 URL: https://issues.apache.org/jira/browse/SLING-2240 Project: Sling Issue Type: Wish Components: Commons Affects Versions: Servlets Post 2.1.0 Reporter: Ben Peter Assignee: Ian Boston Attachments: SLING-2240.patch DateParser is a nice utility and comes in handy in a lot of cases. As such, it would be great to have it in a place where it is part of an exported package instead of being locked in in the private org.apache.sling.servlets.post.impl.helper -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2240) move org.apache.sling.servlets.post.impl.helper.DateParser to commons
[ https://issues.apache.org/jira/browse/SLING-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13486725#comment-13486725 ] Felix Meschberger commented on SLING-2240: -- I am weary of this change: * Why is RequestProperty exported ? * Export version must be increased but this will break implementors of extension interfaces Particularly the second issue makes me nervous. I would prefer another solution. move org.apache.sling.servlets.post.impl.helper.DateParser to commons - Key: SLING-2240 URL: https://issues.apache.org/jira/browse/SLING-2240 Project: Sling Issue Type: Wish Components: Commons Affects Versions: Servlets Post 2.1.0 Reporter: Ben Peter Assignee: Ian Boston Attachments: SLING-2240.patch DateParser is a nice utility and comes in handy in a lot of cases. As such, it would be great to have it in a place where it is part of an exported package instead of being locked in in the private org.apache.sling.servlets.post.impl.helper -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2240) move org.apache.sling.servlets.post.impl.helper.DateParser to commons
[ https://issues.apache.org/jira/browse/SLING-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13486732#comment-13486732 ] Carsten Ziegeler commented on SLING-2240: - I haven't looked at the classes so far, having done so I think RequestProperty should not be exported, it really seems more like an internal class. JSONResponse is already exported. So we're back to DateParser - if we increase the package version (which we have to if we add something to the package) then like Felix explained this breaks implementor bundles. If we start with this fact, it means we shouldn't increase the package version which means we shouldn't add DateParser to that package. We have three options then: 1) leave everything as is 2) Create a new public package in the post servlet bundle and move the class there 3) Add the class to another common bundle - whatever this is I don't think we have a good place for 3) atm, so we either go with 2) or 1) move org.apache.sling.servlets.post.impl.helper.DateParser to commons - Key: SLING-2240 URL: https://issues.apache.org/jira/browse/SLING-2240 Project: Sling Issue Type: Wish Components: Commons Affects Versions: Servlets Post 2.1.0 Reporter: Ben Peter Assignee: Ian Boston Attachments: SLING-2240.patch DateParser is a nice utility and comes in handy in a lot of cases. As such, it would be great to have it in a place where it is part of an exported package instead of being locked in in the private org.apache.sling.servlets.post.impl.helper -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSS] Proposal for a minimal access gate on resource level
Hi,
On Fri, Oct 26, 2012 at 10:43 AM, Mike Müller mike...@mysign.ch wrote:
...The main goal of this proposal is to provide a easy to use service in
Sling to restrict (or grant) access to resources for special use cases
(like giving access to some resources only between 8am and 5pm). The
service should be very lightweight and should NOT be a replacement of ACLs...
You have my bet that people *will* use this service as a replacement
for ACLs, and reinvent a few wheels in the process ;-)
In the end, between this and the CRUD resource API changes we are
moving to two flavors of Sling: JCR-based, where the repository fully
handles such things, and non-JCR, where you need to implement your own
ResourceAccessGates and other niceties that JCR provides.
I'm not against that, as long as it's a conscious decision and as long
as we're clear about best practices in either case.
...I propose a new service interface ResourceAccessGateService...
I'd call that just ResourceAccessGate.
enum GateResult { GRANTED, DENIED, NOTRESPONSIBLE };
DONTCARE instead of NOTRESPONSIBLE maybe?
...Alternatively, to make the interface more flexible, we could combine the
canXXX() methods in a method named hasPermission with a parameter
operation as String
I'd much prefer that, if this model can be closer to JCR's
Session.checkPermission(String absPath, String actions) that's helpful
IMO.
(which makes me think that a new Resource.checkPermission method might
be more in line with Sling's resource-centric view on things).
-Bertrand
Re: [DISCUSS] Proposal for a minimal access gate on resource level
On 30 October 2012 20:18, Bertrand Delacretaz bdelacre...@apache.org wrote:
Hi,
On Fri, Oct 26, 2012 at 10:43 AM, Mike Müller mike...@mysign.ch wrote:
...The main goal of this proposal is to provide a easy to use service in
Sling to restrict (or grant) access to resources for special use cases
(like giving access to some resources only between 8am and 5pm). The
service should be very lightweight and should NOT be a replacement of ACLs...
You have my bet that people *will* use this service as a replacement
for ACLs, and reinvent a few wheels in the process ;-)
In the end, between this and the CRUD resource API changes we are
moving to two flavors of Sling: JCR-based, where the repository fully
handles such things, and non-JCR, where you need to implement your own
ResourceAccessGates and other niceties that JCR provides.
I'm not against that, as long as it's a conscious decision and as long
as we're clear about best practices in either case.
...I propose a new service interface ResourceAccessGateService...
I'd call that just ResourceAccessGate.
enum GateResult { GRANTED, DENIED, NOTRESPONSIBLE };
DONTCARE instead of NOTRESPONSIBLE maybe?
...Alternatively, to make the interface more flexible, we could combine the
canXXX() methods in a method named hasPermission with a parameter
operation as String
I'd much prefer that, if this model can be closer to JCR's
Session.checkPermission(String absPath, String actions) that's helpful
IMO.
(which makes me think that a new Resource.checkPermission method might
be more in line with Sling's resource-centric view on things).
I agree with the single method checkPermissions as its a lot less
overhead to those who have to implement, and the String actions allows
for extension being out of band. What about String[] actions to allow
one call to check many actions ?
I am not certain about Resource.checkPermission (unless you mean a
static), as that assumes read is granted ?
Ian
-Bertrand
[jira] [Updated] (SLING-2523) Improve the JCR Installer
[ https://issues.apache.org/jira/browse/SLING-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-2523: --- Attachment: SLING-2523_2.patch new version of the patch which avoids sync issues if any observation event reach the installer before the rendezVous phase ends. Still need some time for making the other changes. Improve the JCR Installer - Key: SLING-2523 URL: https://issues.apache.org/jira/browse/SLING-2523 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: JCR Installer 3.1.4 Reporter: Carsten Ziegeler Attachments: SLING-2523_1.patch, SLING-2523_2.patch The current implementation has some drawbacks: - it registers several observation listeners - to handle deletes it has to register even more listeners - observation events are just used as markers and there is a polling thread running continously to check for changed markers and then rescan a sub tree in the repository - changes are not reported to the OSGi installer in one method call I think we can simplify and improve the implementation by - just registering a single observation listener for root and then do simple path matching operations - use the observation events to detect what has changed - report the changes in a single method call In addition it would be nice if the jcr installer waits befire reporting changes from an observation event and looks if there is not another observation event coming in right after. This could improve situations where changes are not done by a single save but by a serious of saves -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Build failed in Jenkins: sling-trunk-1.5 » Apache Sling Integration Tests #1837
See https://builds.apache.org/job/sling-trunk-1.5/org.apache.sling$org.apache.sling.launchpad.integration-tests/1837/ -- projectStarted org.apache.sling:org.apache.sling.launchpad.integration-tests:1.0.1-SNAPSHOT [INFO] [INFO] [INFO] Building Apache Sling Integration Tests 1.0.1-SNAPSHOT [INFO] mojoStarted org.apache.maven.plugins:maven-clean-plugin:2.4.1(default-clean)[INFO] Deleting https://builds.apache.org/job/sling-trunk-1.5/org.apache.sling$org.apache.sling.launchpad.integration-tests/ws/target [INFO] [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ org.apache.sling.launchpad.integration-tests --- mojoSucceeded org.apache.maven.plugins:maven-clean-plugin:2.4.1(default-clean) mojoStarted org.apache.maven.plugins:maven-enforcer-plugin:1.0(enforce-java) [INFO] [INFO] --- maven-enforcer-plugin:1.0:enforce (enforce-java) @ org.apache.sling.launchpad.integration-tests --- mojoSucceeded org.apache.maven.plugins:maven-enforcer-plugin:1.0(enforce-java) mojoStarted org.apache.maven.plugins:maven-remote-resources-plugin:1.1(default) [INFO] [INFO] --- maven-remote-resources-plugin:1.1:process (default) @ org.apache.sling.launchpad.integration-tests --- mojoSucceeded org.apache.maven.plugins:maven-remote-resources-plugin:1.1(default) [INFO] Using 'UTF-8' encoding to copy filtered resources. mojoStarted org.apache.maven.plugins:maven-resources-plugin:2.4.3(default-resources) [INFO] [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ org.apache.sling.launchpad.integration-tests --- [INFO] Copying 75 resources [INFO] Copying 3 resources mojoSucceeded org.apache.maven.plugins:maven-resources-plugin:2.4.3(default-resources) mojoStarted org.apache.maven.plugins:maven-antrun-plugin:1.6(default)[INFO] Executing tasks main: [echo] WARNING (SLING-443/SLING-1782) ** [echo] On most platforms, you'll get OutOfMemoryErrors when building unless you set [echo] on 32bit platforms: MAVEN_OPTS=-Xmx256M -XX:MaxPermSize=256M, see SLING-443 [echo] on 64bit platforms: MAVEN_OPTS=-Xmx512M -XX:MaxPermSize=512M, see SLING-1782 [echo] ** [INFO] Executed tasks [INFO] [INFO] --- maven-antrun-plugin:1.6:run (default) @ org.apache.sling.launchpad.integration-tests --- mojoSucceeded org.apache.maven.plugins:maven-antrun-plugin:1.6(default) mojoStarted org.apache.maven.plugins:maven-compiler-plugin:2.5.1(default-compile) [INFO] [INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ org.apache.sling.launchpad.integration-tests --- [INFO] Compiling 113 source files to https://builds.apache.org/job/sling-trunk-1.5/org.apache.sling$org.apache.sling.launchpad.integration-tests/ws/target/classes [INFO] - [ERROR] COMPILATION ERROR : [INFO] - [ERROR] Failure executing javac, but could not parse the error: An exception has occurred in the compiler (1.5.0_22). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. com.sun.tools.javac.code.Symbol$CompletionFailure: file org/apache/sling/adapter/annotations/Adaptable.class not found [INFO] 1 error [INFO] - mojoFailed org.apache.maven.plugins:maven-compiler-plugin:2.5.1(default-compile) projectFailed org.apache.sling:org.apache.sling.launchpad.integration-tests:1.0.1-SNAPSHOT
Jenkins build is back to stable : sling-trunk-1.5 » Apache Sling JCR Installer #1837
See https://builds.apache.org/job/sling-trunk-1.5/org.apache.sling$org.apache.sling.installer.provider.jcr/1837/
Re: [DISCUSS] Proposal for a minimal access gate on resource level
I'm not sure about checkPermission with a String (or String[]). This
would imho only make sense if we see that we will have more
permissions in the future which I really don't see. And we don't need
an extension here as each additional permission would require changes
in the implementation to check those anyway.
So I would go with the separate methods - we could provide an abstract
class which already implements all methods, so implementing would be
just overwriting the required ones.
I also don't see a need to do it in the same way as JCR does - we
should do it what fits best in our resource api and what is the best
way to cover the use cases :)
Adding checks on the resource interface is problematic as this would
require each and every resource provider to implement these methods -
and this proposal is orthogonal so to speak to acl checks done by a
resource provider.
Carsten
2012/10/30 Ian Boston i...@tfd.co.uk:
On 30 October 2012 20:18, Bertrand Delacretaz bdelacre...@apache.org wrote:
Hi,
On Fri, Oct 26, 2012 at 10:43 AM, Mike Müller mike...@mysign.ch wrote:
...The main goal of this proposal is to provide a easy to use service in
Sling to restrict (or grant) access to resources for special use cases
(like giving access to some resources only between 8am and 5pm). The
service should be very lightweight and should NOT be a replacement of
ACLs...
You have my bet that people *will* use this service as a replacement
for ACLs, and reinvent a few wheels in the process ;-)
In the end, between this and the CRUD resource API changes we are
moving to two flavors of Sling: JCR-based, where the repository fully
handles such things, and non-JCR, where you need to implement your own
ResourceAccessGates and other niceties that JCR provides.
I'm not against that, as long as it's a conscious decision and as long
as we're clear about best practices in either case.
...I propose a new service interface ResourceAccessGateService...
I'd call that just ResourceAccessGate.
enum GateResult { GRANTED, DENIED, NOTRESPONSIBLE };
DONTCARE instead of NOTRESPONSIBLE maybe?
...Alternatively, to make the interface more flexible, we could combine the
canXXX() methods in a method named hasPermission with a parameter
operation as String
I'd much prefer that, if this model can be closer to JCR's
Session.checkPermission(String absPath, String actions) that's helpful
IMO.
(which makes me think that a new Resource.checkPermission method might
be more in line with Sling's resource-centric view on things).
I agree with the single method checkPermissions as its a lot less
overhead to those who have to implement, and the String actions allows
for extension being out of band. What about String[] actions to allow
one call to check many actions ?
I am not certain about Resource.checkPermission (unless you mean a
static), as that assumes read is granted ?
Ian
-Bertrand
--
Carsten Ziegeler
cziege...@apache.org
Re: [DISCUSS] Proposal for a minimal access gate on resource level
On 30 October 2012 20:59, Carsten Ziegeler cziege...@apache.org wrote:
I'm not sure about checkPermission with a String (or String[]). This
would imho only make sense if we see that we will have more
permissions in the future which I really don't see. And we don't need
an extension here as each additional permission would require changes
in the implementation to check those anyway.
true.
what about being able to check for a set of permissions in one go ?
So I would go with the separate methods - we could provide an abstract
class which already implements all methods, so implementing would be
just overwriting the required ones.
that works for me.
Ian
I also don't see a need to do it in the same way as JCR does - we
should do it what fits best in our resource api and what is the best
way to cover the use cases :)
Adding checks on the resource interface is problematic as this would
require each and every resource provider to implement these methods -
and this proposal is orthogonal so to speak to acl checks done by a
resource provider.
Carsten
2012/10/30 Ian Boston i...@tfd.co.uk:
On 30 October 2012 20:18, Bertrand Delacretaz bdelacre...@apache.org wrote:
Hi,
On Fri, Oct 26, 2012 at 10:43 AM, Mike Müller mike...@mysign.ch wrote:
...The main goal of this proposal is to provide a easy to use service in
Sling to restrict (or grant) access to resources for special use cases
(like giving access to some resources only between 8am and 5pm). The
service should be very lightweight and should NOT be a replacement of
ACLs...
You have my bet that people *will* use this service as a replacement
for ACLs, and reinvent a few wheels in the process ;-)
In the end, between this and the CRUD resource API changes we are
moving to two flavors of Sling: JCR-based, where the repository fully
handles such things, and non-JCR, where you need to implement your own
ResourceAccessGates and other niceties that JCR provides.
I'm not against that, as long as it's a conscious decision and as long
as we're clear about best practices in either case.
...I propose a new service interface ResourceAccessGateService...
I'd call that just ResourceAccessGate.
enum GateResult { GRANTED, DENIED, NOTRESPONSIBLE };
DONTCARE instead of NOTRESPONSIBLE maybe?
...Alternatively, to make the interface more flexible, we could combine the
canXXX() methods in a method named hasPermission with a parameter
operation as String
I'd much prefer that, if this model can be closer to JCR's
Session.checkPermission(String absPath, String actions) that's helpful
IMO.
(which makes me think that a new Resource.checkPermission method might
be more in line with Sling's resource-centric view on things).
I agree with the single method checkPermissions as its a lot less
overhead to those who have to implement, and the String actions allows
for extension being out of band. What about String[] actions to allow
one call to check many actions ?
I am not certain about Resource.checkPermission (unless you mean a
static), as that assumes read is granted ?
Ian
-Bertrand
--
Carsten Ziegeler
cziege...@apache.org
Re: [DISCUSS] Proposal for a minimal access gate on resource level
On Tue, Oct 30, 2012 at 10:59 AM, Carsten Ziegeler cziege...@apache.org wrote: ...I'm not sure about checkPermission with a String (or String[]). This would imho only make sense if we see that we will have more permissions in the future which I really don't see... Thinking that no new types of permissions will come up is unrealistic IMO. Moving a resource to a different path, changing a resource's owner...back to Mike's changing theno access between 8AM and 5PM access rule can also very well be a permission type. But I agree that this would require handling the unknown permission type case. ...I also don't see a need to do it in the same way as JCR does - we should do it what fits best in our resource api and what is the best way to cover the use cases :)... Of course, but some consistency wouldn't hurt either, I don't see what makes the multiple methods better than the single method + permission name, and we already have that latter pattern in our codebase. -Bertrand
Jenkins build became unstable: sling-trunk-1.6 #1491
See https://builds.apache.org/job/sling-trunk-1.6/1491/changes
[jira] [Commented] (SLING-2636) [Tooling] Add ability to Import from Sling Repository
[ https://issues.apache.org/jira/browse/SLING-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13486909#comment-13486909 ] Antonio Sanso commented on SLING-2636: -- patch applied in revision 1403719. Thanks Dan for your patch. I am working on the importing phase now that the UI is there, [Tooling] Add ability to Import from Sling Repository - Key: SLING-2636 URL: https://issues.apache.org/jira/browse/SLING-2636 Project: Sling Issue Type: Sub-task Components: Extensions Reporter: Dan Klco Assignee: Antonio Sanso Priority: Minor Attachments: SLING-2636-Import-Wizard.diff -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSS] Proposal for a minimal access gate on resource level
2012/10/30 Bertrand Delacretaz bdelacre...@apache.org: ...I also don't see a need to do it in the same way as JCR does - we should do it what fits best in our resource api and what is the best way to cover the use cases :)... Of course, but some consistency wouldn't hurt either, I don't see what makes the multiple methods better than the single method + permission name, and we already have that latter pattern in our codebase. It's slower as it requires checking of the permission check :) More serious, a string is open, it allows for typos (even if we provide constants) and unexpected values which you also have to check in your implementation. So instead of a serious of if permission is this and else throw/do nothing, separate methods make it imho easier to use and implement. But I don't really have a strong preference and would leave it up to Mike providing the patch :) Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [DISCUSS] Proposal for a minimal access gate on resource level
2012/10/30 Ian Boston i...@tfd.co.uk:
what about being able to check for a set of permissions in one go ?
As far as the proposal goes, there is no need for this as usually
always exactly one permission is checked.
Carsten
So I would go with the separate methods - we could provide an abstract
class which already implements all methods, so implementing would be
just overwriting the required ones.
that works for me.
Ian
I also don't see a need to do it in the same way as JCR does - we
should do it what fits best in our resource api and what is the best
way to cover the use cases :)
Adding checks on the resource interface is problematic as this would
require each and every resource provider to implement these methods -
and this proposal is orthogonal so to speak to acl checks done by a
resource provider.
Carsten
2012/10/30 Ian Boston i...@tfd.co.uk:
On 30 October 2012 20:18, Bertrand Delacretaz bdelacre...@apache.org
wrote:
Hi,
On Fri, Oct 26, 2012 at 10:43 AM, Mike Müller mike...@mysign.ch wrote:
...The main goal of this proposal is to provide a easy to use service in
Sling to restrict (or grant) access to resources for special use cases
(like giving access to some resources only between 8am and 5pm). The
service should be very lightweight and should NOT be a replacement of
ACLs...
You have my bet that people *will* use this service as a replacement
for ACLs, and reinvent a few wheels in the process ;-)
In the end, between this and the CRUD resource API changes we are
moving to two flavors of Sling: JCR-based, where the repository fully
handles such things, and non-JCR, where you need to implement your own
ResourceAccessGates and other niceties that JCR provides.
I'm not against that, as long as it's a conscious decision and as long
as we're clear about best practices in either case.
...I propose a new service interface ResourceAccessGateService...
I'd call that just ResourceAccessGate.
enum GateResult { GRANTED, DENIED, NOTRESPONSIBLE };
DONTCARE instead of NOTRESPONSIBLE maybe?
...Alternatively, to make the interface more flexible, we could combine
the
canXXX() methods in a method named hasPermission with a parameter
operation as String
I'd much prefer that, if this model can be closer to JCR's
Session.checkPermission(String absPath, String actions) that's helpful
IMO.
(which makes me think that a new Resource.checkPermission method might
be more in line with Sling's resource-centric view on things).
I agree with the single method checkPermissions as its a lot less
overhead to those who have to implement, and the String actions allows
for extension being out of band. What about String[] actions to allow
one call to check many actions ?
I am not certain about Resource.checkPermission (unless you mean a
static), as that assumes read is granted ?
Ian
-Bertrand
--
Carsten Ziegeler
cziege...@apache.org
--
Carsten Ziegeler
cziege...@apache.org
[jira] [Updated] (SLING-2636) [Tooling] Add ability to Import from Sling Repository
[ https://issues.apache.org/jira/browse/SLING-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Klco updated SLING-2636: Attachment: SLING-2636-Import-IN-PROGRESS.diff Okay, cool. I have some code (attached) that is a work in progress, if you want that. One of the things I was thinking is that the FileInfo class would be a lot more useful if it could be directly instantiated from the Eclipse internal classes and then from it you could get the Filesystem File, Eclipse resource and corresponding Resource path. Also, how were you planning on parsing/constructing the JSON? It seems like Apache projects can use org.json code (http://www.apache.org/legal/resolved.html#json), so I was using that, but I don't think it's really optimal to directly include the source in our project. That being said, the way dependencies are handled in Eclipse plugins makes loading the code from the POM awkward as the classes handling the JSON parsing would have to be ouside of the reactor build. [Tooling] Add ability to Import from Sling Repository - Key: SLING-2636 URL: https://issues.apache.org/jira/browse/SLING-2636 Project: Sling Issue Type: Sub-task Components: Extensions Reporter: Dan Klco Assignee: Antonio Sanso Priority: Minor Attachments: SLING-2636-Import-IN-PROGRESS.diff, SLING-2636-Import-Wizard.diff -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SLING-2640) NPE in JcrResourceProviderFactory due to impossible null Repository reference
Bertrand Delacretaz created SLING-2640: -- Summary: NPE in JcrResourceProviderFactory due to impossible null Repository reference Key: SLING-2640 URL: https://issues.apache.org/jira/browse/SLING-2640 Project: Sling Issue Type: Bug Components: JCR Affects Versions: JCR Resource 2.1.0 Reporter: Bertrand Delacretaz After heavy SCR-related activity, I get an NPE at JcrResourceProviderFactory.java:136, which is session = repository.loginAdministrative(workspace); and repository is null, which in theory cannot happen as that's an @Reference. This looks similar to FELIX-3317, but reporting here as it affects Sling and is reproducible as follows: 1. Start the sling launchpad/builder 2. Install my test bundle from https://github.com/bdelacretaz/bundle-start-stop-test, which semi-randomly stops and restarts bundles to trigger SCR activity 3. When the test bundle says Waiting up to 1 msec to start next cycle in the log, request / and check the logs for the NPE. Maybe set a breakpoint on that log message to better control the sequence In my case I get the NPE after 3-4 cycles of the test stopping/restarting bundles. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2636) [Tooling] Add ability to Import from Sling Repository
[ https://issues.apache.org/jira/browse/SLING-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13486931#comment-13486931 ] Antonio Sanso commented on SLING-2636: -- Thanks for this new patch Dan, I will look into it, For the Json part we can probably use org.apache.sling.commons.json. WDYT? [Tooling] Add ability to Import from Sling Repository - Key: SLING-2636 URL: https://issues.apache.org/jira/browse/SLING-2636 Project: Sling Issue Type: Sub-task Components: Extensions Reporter: Dan Klco Assignee: Antonio Sanso Priority: Minor Attachments: SLING-2636-Import-IN-PROGRESS.diff, SLING-2636-Import-Wizard.diff -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2636) [Tooling] Add ability to Import from Sling Repository
[ https://issues.apache.org/jira/browse/SLING-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13486938#comment-13486938 ] Robert Munteanu commented on SLING-2636: Is org.apache.sling.commons.json available in a p2 repo? If not, I'd suggest using something which is available in [Eclipse Orbit|http://download.eclipse.org/tools/orbit/downloads/drops/R20120526062928/], like org.json or gson. The advantages would be - reduced size as we would not need to include the sling-json bundle in our feature - Eclipse developers would already be familiar with these bundles [Tooling] Add ability to Import from Sling Repository - Key: SLING-2636 URL: https://issues.apache.org/jira/browse/SLING-2636 Project: Sling Issue Type: Sub-task Components: Extensions Reporter: Dan Klco Assignee: Antonio Sanso Priority: Minor Attachments: SLING-2636-Import-IN-PROGRESS.diff, SLING-2636-Import-Wizard.diff -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2631) [Tooling] Multiple logged exceptions related to Invalid URIs
[ https://issues.apache.org/jira/browse/SLING-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13486976#comment-13486976 ] Robert Munteanu commented on SLING-2631: I've added some logging and found some problematic use cases. I'll add them all here for tracking and send in the patches once I've polished the code. Note that line numbers might be a bit off due to my changing the code locally. h2. Created a new 'jcr_root' folder !ENTRY org.apache.sling.slingclipse 4 0 2012-10-30 18:06:15.589 !MESSAGE Failed visiting resource based on delta ResourceDelta(/test/jcr_root) !STACK 0 java.lang.StringIndexOutOfBoundsException: String index out of range: -2 at java.lang.String.substring(String.java:1875) at org.apache.sling.slingclipse.helper.SlingclipseHelper.getSlingProjectPath(SlingclipseHelper.java:30) at org.apache.sling.slingclipse.SlingclipseListener$1.visitInternal(SlingclipseListener.java:93) at org.apache.sling.slingclipse.SlingclipseListener$1.visit(SlingclipseListener.java:56) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:69) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:49) at org.apache.sling.slingclipse.SlingclipseListener.resourceChanged(SlingclipseListener.java:43) at org.eclipse.core.internal.events.NotificationManager$1.run(NotificationManager.java:291) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:285) at org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:149) at org.eclipse.core.internal.resources.Workspace.broadcastPostChange(Workspace.java:395) at org.eclipse.core.internal.resources.Workspace.endOperation(Workspace.java:1530) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2353) at org.eclipse.ui.ide.undo.AbstractWorkspaceOperation.execute(AbstractWorkspaceOperation.java:204) at org.eclipse.ui.dialogs.WizardNewFolderMainPage$4.run(WizardNewFolderMainPage.java:466) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121) h2. Deleted a project containing a jcr_root folder !ENTRY org.eclipse.core.resources 4 2 2012-10-30 18:07:51.131 !MESSAGE Problems occurred when invoking code from plug-in: org.eclipse.core.resources. !STACK 0 java.lang.NullPointerException at org.apache.sling.slingclipse.SlingclipseListener.resourceChanged(SlingclipseListener.java:43) at org.eclipse.core.internal.events.NotificationManager$1.run(NotificationManager.java:291) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:285) at org.eclipse.core.internal.events.NotificationManager.handleEvent(NotificationManager.java:261) at org.eclipse.core.internal.resources.Workspace.broadcastEvent(Workspace.java:390) at org.eclipse.core.internal.resources.Resource.broadcastPreDeleteEvent(Resource.java:2030) at org.eclipse.core.internal.resources.Resource.delete(Resource.java:788) at org.eclipse.core.internal.resources.Project.delete(Project.java:344) at org.eclipse.ltk.core.refactoring.resource.DeleteResourceChange.perform(DeleteResourceChange.java:160) at org.eclipse.ltk.core.refactoring.CompositeChange.perform(CompositeChange.java:278) at org.eclipse.ltk.core.refactoring.CompositeChange.perform(CompositeChange.java:278) at org.eclipse.ltk.core.refactoring.PerformChangeOperation$1.run(PerformChangeOperation.java:258) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344) at org.eclipse.ltk.core.refactoring.PerformChangeOperation.executeChange(PerformChangeOperation.java:306) at org.eclipse.ltk.internal.ui.refactoring.UIPerformChangeOperation.executeChange(UIPerformChangeOperation.java:92) at org.eclipse.ltk.core.refactoring.PerformChangeOperation.run(PerformChangeOperation.java:218) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344) at org.eclipse.ltk.internal.ui.refactoring.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:87) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121) [Tooling] Multiple logged exceptions related to Invalid URIs Key: SLING-2631 URL:
[jira] [Commented] (SLING-2631) [Tooling] Slingclipse should only try to sync files
[ https://issues.apache.org/jira/browse/SLING-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13486988#comment-13486988 ] Robert Munteanu commented on SLING-2631: The problem is that non-file resources are sync'ed. I'll attach a patch which fixes this for me. I'll supply the rest of the patches ( when done ) on SLING-2635 . [Tooling] Slingclipse should only try to sync files --- Key: SLING-2631 URL: https://issues.apache.org/jira/browse/SLING-2631 Project: Sling Issue Type: Sub-task Components: Extensions Reporter: Robert Munteanu Assignee: Antonio Sanso Attachments: SLING-2631.diff Original Estimate: 0h Remaining Estimate: 0h I get lots of such exceptions when I start Eclipse. I disabled sync after every save for now. !ENTRY org.eclipse.core.resources 4 2 2012-10-25 23:30:31.945 !MESSAGE Problems occurred when invoking code from plug-in: org.eclipse.core.resources. !STACK 0 java.lang.IllegalArgumentException: Invalid uri 'http://localhost:8080metrixx-commons-core/target/classes/META-INF#39;: invalid port number at org.apache.commons.httpclient.HttpMethodBase.init(HttpMethodBase.java:222) at org.apache.commons.httpclient.methods.ExpectContinueMethod.init(ExpectContinueMethod.java:93) at org.apache.commons.httpclient.methods.EntityEnclosingMethod.init(EntityEnclosingMethod.java:119) at org.apache.commons.httpclient.methods.PostMethod.init(PostMethod.java:106) at org.apache.sling.slingclipse.http.impl.RepositoryImpl.addNode(RepositoryImpl.java:37) at org.apache.sling.slingclipse.SlingclipseListener$1.visit(SlingclipseListener.java:91) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:69) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:49) at org.apache.sling.slingclipse.SlingclipseListener.resourceChanged(SlingclipseListener.java:42) at org.eclipse.core.internal.events.NotificationManager$1.run(NotificationManager.java:291) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:285) at org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:149) at org.eclipse.core.internal.resources.Workspace.broadcastPostChange(Workspace.java:395) at org.eclipse.core.internal.resources.Workspace.endOperation(Workspace.java:1530) at org.eclipse.core.internal.resources.Resource.refreshLocal(Resource.java:1712) at org.eclipse.core.internal.refresh.RefreshJob.runInWorkspace(RefreshJob.java:167) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-2631) [Tooling] Slingclipse should only try to sync files
[ https://issues.apache.org/jira/browse/SLING-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-2631: --- Attachment: SLING-2631.diff [Tooling] Slingclipse should only try to sync files --- Key: SLING-2631 URL: https://issues.apache.org/jira/browse/SLING-2631 Project: Sling Issue Type: Sub-task Components: Extensions Reporter: Robert Munteanu Assignee: Antonio Sanso Attachments: SLING-2631.diff Original Estimate: 0h Remaining Estimate: 0h I get lots of such exceptions when I start Eclipse. I disabled sync after every save for now. !ENTRY org.eclipse.core.resources 4 2 2012-10-25 23:30:31.945 !MESSAGE Problems occurred when invoking code from plug-in: org.eclipse.core.resources. !STACK 0 java.lang.IllegalArgumentException: Invalid uri 'http://localhost:8080metrixx-commons-core/target/classes/META-INF#39;: invalid port number at org.apache.commons.httpclient.HttpMethodBase.init(HttpMethodBase.java:222) at org.apache.commons.httpclient.methods.ExpectContinueMethod.init(ExpectContinueMethod.java:93) at org.apache.commons.httpclient.methods.EntityEnclosingMethod.init(EntityEnclosingMethod.java:119) at org.apache.commons.httpclient.methods.PostMethod.init(PostMethod.java:106) at org.apache.sling.slingclipse.http.impl.RepositoryImpl.addNode(RepositoryImpl.java:37) at org.apache.sling.slingclipse.SlingclipseListener$1.visit(SlingclipseListener.java:91) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:69) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:49) at org.apache.sling.slingclipse.SlingclipseListener.resourceChanged(SlingclipseListener.java:42) at org.eclipse.core.internal.events.NotificationManager$1.run(NotificationManager.java:291) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:285) at org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:149) at org.eclipse.core.internal.resources.Workspace.broadcastPostChange(Workspace.java:395) at org.eclipse.core.internal.resources.Workspace.endOperation(Workspace.java:1530) at org.eclipse.core.internal.resources.Resource.refreshLocal(Resource.java:1712) at org.eclipse.core.internal.refresh.RefreshJob.runInWorkspace(RefreshJob.java:167) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-2631) [Tooling] Slingclipse should only try to sync files
[ https://issues.apache.org/jira/browse/SLING-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-2631: --- Summary: [Tooling] Slingclipse should only try to sync files (was: [Tooling] Multiple logged exceptions related to Invalid URIs) [Tooling] Slingclipse should only try to sync files --- Key: SLING-2631 URL: https://issues.apache.org/jira/browse/SLING-2631 Project: Sling Issue Type: Sub-task Components: Extensions Reporter: Robert Munteanu Assignee: Antonio Sanso Attachments: SLING-2631.diff Original Estimate: 0h Remaining Estimate: 0h I get lots of such exceptions when I start Eclipse. I disabled sync after every save for now. !ENTRY org.eclipse.core.resources 4 2 2012-10-25 23:30:31.945 !MESSAGE Problems occurred when invoking code from plug-in: org.eclipse.core.resources. !STACK 0 java.lang.IllegalArgumentException: Invalid uri 'http://localhost:8080metrixx-commons-core/target/classes/META-INF#39;: invalid port number at org.apache.commons.httpclient.HttpMethodBase.init(HttpMethodBase.java:222) at org.apache.commons.httpclient.methods.ExpectContinueMethod.init(ExpectContinueMethod.java:93) at org.apache.commons.httpclient.methods.EntityEnclosingMethod.init(EntityEnclosingMethod.java:119) at org.apache.commons.httpclient.methods.PostMethod.init(PostMethod.java:106) at org.apache.sling.slingclipse.http.impl.RepositoryImpl.addNode(RepositoryImpl.java:37) at org.apache.sling.slingclipse.SlingclipseListener$1.visit(SlingclipseListener.java:91) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:69) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:49) at org.apache.sling.slingclipse.SlingclipseListener.resourceChanged(SlingclipseListener.java:42) at org.eclipse.core.internal.events.NotificationManager$1.run(NotificationManager.java:291) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:285) at org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:149) at org.eclipse.core.internal.resources.Workspace.broadcastPostChange(Workspace.java:395) at org.eclipse.core.internal.resources.Workspace.endOperation(Workspace.java:1530) at org.eclipse.core.internal.resources.Resource.refreshLocal(Resource.java:1712) at org.eclipse.core.internal.refresh.RefreshJob.runInWorkspace(RefreshJob.java:167) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SLING-2639) vanity paths don't work properly for file (and file-like resources)
[ https://issues.apache.org/jira/browse/SLING-2639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson resolved SLING-2639. --- Resolution: Fixed Fix Version/s: Resource Resolver 1.0.0 Assignee: Justin Edelson fixed in r1403772 vanity paths don't work properly for file (and file-like resources) --- Key: SLING-2639 URL: https://issues.apache.org/jira/browse/SLING-2639 Project: Sling Issue Type: Bug Components: ResourceResolver Reporter: Justin Edelson Assignee: Justin Edelson Fix For: Resource Resolver 1.0.0 Attachments: SLING-2639.patch Consider the case where a file is stored as a resource and is assigned a vanity path, e.g. /content/assets/myimage.jpg is assigned a sling:vanityPath of /myimage with sling:redirect = true. The desired behavior is for GET /myimage to redirect to /content/assets/myimage.jpg. Currently, the redirect is to /content/assets/myimage.jpg.html. If a resource's name contains a ., then the html addition on a vanity path should not take place. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSS] Proposal for a minimal access gate on resource level
On 30.10.2012, at 08:43, Mike Müller mike...@mysign.ch wrote: And it's totally transparent and doesn't need any changes to the core. Depends on what you define as core. The proposal definitely mentions a change to the resource resolver core. No existing API will be changed. The changes are only under the hood. These changes only come to life if someone implements a ResourceAccessGateService. The proposal only suggest a new service interface which can be implemented by a user of sling or not. In the case of not using this service, nothing changes from an API-view. I am confused. You mentioned this: First of all, if there's no registered ResourceAccessGateService, nothing changes. If one ore more ResourceAccessGateServices are registered Sling takes them in account as follows: Sling registers a ResourceDecorator and wraps with that service all resources into a AccessGateResourceWrapper. Who is Sling in this case? Couldn't a custom ResourceDecorator do this without any changes to the core resource bundles? A custom ResourceDecorator can not do the same job. There are different issues. You can't write a ResourceDecorator only for a specific path, so to restrict access for resources under /my/resources/only-during-day/ you have to write a ResourceDecorator which wraps all resources from every path, which is a lot of overhead. With the proposed ResourceAccessGateService only resources with restrictions will be wrapped. Finally the proposal is about to let the user define restrictions for all CRUD operations, not only read. Ok, didn't know that the ResourceDecorator is still about read only. Cheers, Alex
[jira] [Commented] (SLING-2631) [Tooling] Slingclipse should only try to sync files
[ https://issues.apache.org/jira/browse/SLING-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13487038#comment-13487038 ] Antonio Sanso commented on SLING-2631: -- thanks for your patch Robert. It would be nice to handle folder as well though. It does handle them quite well I think. I know there is an issue with empty file and folder though. Are you sure that the issue above is not isolated to jcr_root folder though? if yes this could be handled differentely [Tooling] Slingclipse should only try to sync files --- Key: SLING-2631 URL: https://issues.apache.org/jira/browse/SLING-2631 Project: Sling Issue Type: Sub-task Components: Extensions Reporter: Robert Munteanu Assignee: Antonio Sanso Attachments: SLING-2631.diff Original Estimate: 0h Remaining Estimate: 0h I get lots of such exceptions when I start Eclipse. I disabled sync after every save for now. !ENTRY org.eclipse.core.resources 4 2 2012-10-25 23:30:31.945 !MESSAGE Problems occurred when invoking code from plug-in: org.eclipse.core.resources. !STACK 0 java.lang.IllegalArgumentException: Invalid uri 'http://localhost:8080metrixx-commons-core/target/classes/META-INF#39;: invalid port number at org.apache.commons.httpclient.HttpMethodBase.init(HttpMethodBase.java:222) at org.apache.commons.httpclient.methods.ExpectContinueMethod.init(ExpectContinueMethod.java:93) at org.apache.commons.httpclient.methods.EntityEnclosingMethod.init(EntityEnclosingMethod.java:119) at org.apache.commons.httpclient.methods.PostMethod.init(PostMethod.java:106) at org.apache.sling.slingclipse.http.impl.RepositoryImpl.addNode(RepositoryImpl.java:37) at org.apache.sling.slingclipse.SlingclipseListener$1.visit(SlingclipseListener.java:91) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:69) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:49) at org.apache.sling.slingclipse.SlingclipseListener.resourceChanged(SlingclipseListener.java:42) at org.eclipse.core.internal.events.NotificationManager$1.run(NotificationManager.java:291) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:285) at org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:149) at org.eclipse.core.internal.resources.Workspace.broadcastPostChange(Workspace.java:395) at org.eclipse.core.internal.resources.Workspace.endOperation(Workspace.java:1530) at org.eclipse.core.internal.resources.Resource.refreshLocal(Resource.java:1712) at org.eclipse.core.internal.refresh.RefreshJob.runInWorkspace(RefreshJob.java:167) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-1245) Add pax runner support to maven-launchpad-plugin
[ https://issues.apache.org/jira/browse/SLING-1245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre COLLIGNON updated SLING-1245: --- Attachment: 0001-SLING-1245-Add-Pax-Runner-support-for-mvn-launchpad-.patch Attaching a patch that provides a Mojo which generates a pax config file according to the documentation [0]. The bundle dependencies are defined following the maven package syntax with version and start level. For example: mvn:org.apache.sling/org.apache.sling.extensions.webconsolebranding/1.0.0@5 [0] http://team.ops4j.org/wiki/display/paxrunner/Provision+bundles+from+a+text+file Add pax runner support to maven-launchpad-plugin Key: SLING-1245 URL: https://issues.apache.org/jira/browse/SLING-1245 Project: Sling Issue Type: Improvement Components: Maven Plugins and Archetypes Reporter: Justin Edelson Priority: Minor Attachments: 0001-SLING-1245-Add-Pax-Runner-support-for-mvn-launchpad-.patch In addition to the Karaf descriptor, it would be nice to output a Pax Runner file as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SLING-2240) move org.apache.sling.servlets.post.impl.helper.DateParser to commons
[ https://issues.apache.org/jira/browse/SLING-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston resolved SLING-2240. --- Resolution: Later We might do this later, but for the moment here is a work around used in bundles/jcr/jackrabbit-usermanager/pom.xml Embed-Dependency org.apache.sling.servlets.post;inline=org/apache/sling/servlets/post/impl/helper/DateParser* /Embed-Dependency move org.apache.sling.servlets.post.impl.helper.DateParser to commons - Key: SLING-2240 URL: https://issues.apache.org/jira/browse/SLING-2240 Project: Sling Issue Type: Wish Components: Commons Affects Versions: Servlets Post 2.1.0 Reporter: Ben Peter Assignee: Ian Boston Attachments: SLING-2240.patch DateParser is a nice utility and comes in handy in a lot of cases. As such, it would be great to have it in a place where it is part of an exported package instead of being locked in in the private org.apache.sling.servlets.post.impl.helper -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
