Re: Enabling Github integration for Apache Sling Infra
Hi I agree, this certainly would not hurt doing :-) +1 Regards Felix Am 17.02.2014 um 08:07 schrieb Chetan Mehrotra chetan.mehro...@gmail.com: Saw this news regarding Github and Apache infra integration [1]. I would be good if we get these features enabled for Sling. thoughts? Chetan Mehrotra [1] https://blogs.apache.org/infra/entry/improved_integration_between_apache_and
Re: Enabling Github integration for Apache Sling Infra
+1 On Mon, Feb 17, 2014 at 2:58 AM, Felix Meschberger fmesc...@adobe.comwrote: Hi I agree, this certainly would not hurt doing :-) +1 Regards Felix Am 17.02.2014 um 08:07 schrieb Chetan Mehrotra chetan.mehro...@gmail.com : Saw this news regarding Github and Apache infra integration [1]. I would be good if we get these features enabled for Sling. thoughts? Chetan Mehrotra [1] https://blogs.apache.org/infra/entry/improved_integration_between_apache_and
Re: [VOTE] Release Apache Sling JCR API 2.2.0, JCR Base 2.2.0 and JCR Resource 2.3.0
Anyone, please? 2014-02-06 19:17 GMT+01:00 Carsten Ziegeler cziege...@apache.org: We're missing some binding votes here, anyone? Thanks Carsten 2014-01-30 21:19 GMT+01:00 Oliver Lietz apa...@oliverlietz.de: Am Donnerstag, 30. Januar 2014 schrieb Carsten Ziegeler: Hi, this vote is about three related modules in the jcr space, apart from bug fixes it contains the base for the replacement of login administrative JCR API 2.2.0 https://issues.apache.org/jira/browse/SLING/fixforversion/12315316 JCR Base 2.2.0 https://issues.apache.org/jira/browse/SLING/fixforversion/12319516 JCR Resource https://issues.apache.org/jira/browse/SLING/fixforversion/12324379 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1008 You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1008 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours. +1 O. Regards Carsten -- Carsten Ziegeler cziege...@apache.org -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release Apache Sling JCR API 2.2.0, JCR Base 2.2.0 and JCR Resource 2.3.0
+1 Ian On 17 February 2014 08:37, Carsten Ziegeler cziege...@apache.org wrote: Anyone, please? 2014-02-06 19:17 GMT+01:00 Carsten Ziegeler cziege...@apache.org: We're missing some binding votes here, anyone? Thanks Carsten 2014-01-30 21:19 GMT+01:00 Oliver Lietz apa...@oliverlietz.de: Am Donnerstag, 30. Januar 2014 schrieb Carsten Ziegeler: Hi, this vote is about three related modules in the jcr space, apart from bug fixes it contains the base for the replacement of login administrative JCR API 2.2.0 https://issues.apache.org/jira/browse/SLING/fixforversion/12315316 JCR Base 2.2.0 https://issues.apache.org/jira/browse/SLING/fixforversion/12319516 JCR Resource https://issues.apache.org/jira/browse/SLING/fixforversion/12324379 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1008 You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1008 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours. +1 O. Regards Carsten -- Carsten Ziegeler cziege...@apache.org -- Carsten Ziegeler cziege...@apache.org
Request Parameter Themes
Hi all I have been working in my whiteboard extending Sling's request parameter support with the following goals: 1. Support both Servlet API 2 and Servlet API 3 which brings multipart/form-data support with additional API. 2. Support Sling's request parameter support for non-Sling servlets. 3. Make sure request parameters are provided in the order they have been stated in the request 4. Suppport an application requirement to get access to the request parameters in the order they have been defined on the request The third goal actually goes back to a Servlet API deficiency which does not define this order. Unfortunately some of our application require such an order and so we have to make sure. Also some servlet containers (Jetty) support such a request parameter order by internally using a LinkedHashMap while others (Tomcat) don't. With the new implementation of parsing the parameters we solve this difference and always provide a defined order. The implementation can be found at [1] BTW: The hack in the engine bundle using an ant compile step is to be able to compile for both Servlet API 2 and Servlet API 3. If someone has a better, more elegant solution, I am more than happy to change the current hack :-) WDYT ? Regards Felix [1] http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/parameters
Re: Enabling Github integration for Apache Sling Infra
Am Montag, 17. Februar 2014 schrieb Chetan Mehrotra: Saw this news regarding Github and Apache infra integration [1]. I would be good if we get these features enabled for Sling. thoughts? +1 What about switching from Subversion to Git like Karaf did it recently? O. Chetan Mehrotra [1] https://blogs.apache.org/infra/entry/improved_integration_between_apache_a nd
[jira] [Updated] (SLING-3384) Simplify AbstractSlingRepository implementation
[ https://issues.apache.org/jira/browse/SLING-3384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-3384: Fix Version/s: (was: JCR Base 2.2.0) JCR Base 2.2.2 Simplify AbstractSlingRepository implementation --- Key: SLING-3384 URL: https://issues.apache.org/jira/browse/SLING-3384 Project: Sling Issue Type: New Feature Components: JCR Affects Versions: JCR Jackrabbit Server 2.1.0, JCR Base 2.1.2 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: JCR Jackrabbit Server 2.1.2, JCR Base 2.2.2 With the introduction of the SlingRepository.loginService method the existing setup of the AbstractSlingRepository became quite complex in that it hacks in a SlingRepository proxy to be able to register the SlingRepository as a service and implement the new method. An additional problem of the AbstractSlingRepository class is that it expects the implementation to be implemented using Declarative Services. While this was simple and easy in the beginning it created a runtime dependency which does not go well with the OSGi framework. So, I propose to create a new couple of (abstract) classes which simplify the setup and implementation of SlingRepository services. Another feature of the original AbstractSlingRepository base class was access to foreign repositories as well as repository pinging which turns out to be functionality not being usefull in an abstract base class. Rather this would be something in an actual implementation which knows how to deal with such pre-existing foreign repository instances. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: Installation and start order for logging (was: [jira] [Commented] (SLING-3386) Enable support starting bundle in custom oreder at start level 1)
Can someone please summarize what exactly is proposed, especially for SLING-3388 ? Thanks Carsten 2014-02-12 11:14 GMT+01:00 Felix Meschberger fmesc...@adobe.com: Am 12.02.2014 um 11:01 schrieb Chetan Mehrotra chetan.mehro...@gmail.com : For now I think we can keep the implementation simple. For example in current case we do not have to change start level for Fragments and Slf4j related bundle. So need to change start level of some listed bundles only startlevel 20 40 Do not see a requirement to move all existing bundle to different level ok startlevel .* 2 startlevel .*\.installer\..* 2 For now would like to keep it simple to changestartlevel symbolic name:version? target level I still would suggest to support a version range, though. If need arises for more advance usecase then they can be added later Created SLING-3388 for the same. Thanks Felix Chetan Mehrotra On Wed, Feb 12, 2014 at 2:58 PM, Felix Meschberger fmesc...@adobe.com wrote: Hi Am 12.02.2014 um 09:58 schrieb Felix Meschberger fmesc...@adobe.com: Hi Am 12.02.2014 um 09:22 schrieb Chetan Mehrotra chetan.mehro...@gmail.com: On Wed, Feb 12, 2014 at 1:26 PM, Felix Meschberger fmesc...@adobe.com wrote: Hence, I would really prefer to get our start levels straight and reserve 1 to logging and move the install stuff to 2. You never allow to take the short cut :) I fight special cases as long as possible, yes :-) Okie thinking about tackling the real problem of moving existing bundle to start level 1 I can think of following approach 1. Currently we are not using startlevel 2,3,4 Yes. 2. Introduce a new command ChangeStartLevelCommand which would use the StartLevel service to change the start level of non fragment bundle having existing level 1. or it can be generic to change the level from a - b. One thing to decide at this step is that command should work on explicit parameters e.g. change start level only for list bundles OR Is an automatic one where it would find all bundles at 1 and change levels for non fragment and non logging related bundle You mean a command for bootstrap.txt like uninstall ? Sounds good. This command could take a regular expression for symbolic names and optionally a version range to select bundles and then a target start level. Optionally it could take a source start level and a target start level to move all bundles with the source start level to the target start level EBND definition: StartLevelCommand = startlevel Source TargetStartLevel . Source = SourceStartLevel | Bundle . SourceStartLevel = numeric startlevel value 0 . TargetStartLevel = numeric startlevel value 0 . Bundle = BundleSymbolicName VersionRange . BundleSymbolicName = regular expression match for bundle symbolic name . VersionRange = OSGi version range to match bundles . Examples: # move all bundles currently set to startlevel 20 to startlevel 40 startlevel 20 40 # move all bundles to startlevel 2 startlevel .* 2 # move installer bundles to startlevel 2 startlevel .*\.installer\..* 2 Regards Felix +1 3. Change the list.xml and move non fragment bundle (except loggging related) to level 2 +1 Would this work or is something missing here? Sounds good to me. Regards Felix Chetan Mehrotra -- Carsten Ziegeler cziege...@apache.org
Re: Installation and start order for logging (was: [jira] [Commented] (SLING-3386) Enable support starting bundle in custom oreder at start level 1)
Hi Carsten, To summarize. 1. Need to clear the start level 1 and keep only logging related bundles and framework fragments at that level. Move all other bundles to Start Level 2 2. For upgraded system we implement a new Bootstrap command say ChangeStartLevelCommand. This would change the start level of bundle from a to b. This would then be used to implement #1 3. For new system the list.xml needs to be updated I would be trying out #2 and come back to the list on how it works in practice. It might take some time given some other work in progress Chetan Mehrotra On Mon, Feb 17, 2014 at 5:37 PM, Carsten Ziegeler cziege...@apache.org wrote: Can someone please summarize what exactly is proposed, especially for SLING-3388 ? Thanks Carsten 2014-02-12 11:14 GMT+01:00 Felix Meschberger fmesc...@adobe.com: Am 12.02.2014 um 11:01 schrieb Chetan Mehrotra chetan.mehro...@gmail.com : For now I think we can keep the implementation simple. For example in current case we do not have to change start level for Fragments and Slf4j related bundle. So need to change start level of some listed bundles only startlevel 20 40 Do not see a requirement to move all existing bundle to different level ok startlevel .* 2 startlevel .*\.installer\..* 2 For now would like to keep it simple to changestartlevel symbolic name:version? target level I still would suggest to support a version range, though. If need arises for more advance usecase then they can be added later Created SLING-3388 for the same. Thanks Felix Chetan Mehrotra On Wed, Feb 12, 2014 at 2:58 PM, Felix Meschberger fmesc...@adobe.com wrote: Hi Am 12.02.2014 um 09:58 schrieb Felix Meschberger fmesc...@adobe.com: Hi Am 12.02.2014 um 09:22 schrieb Chetan Mehrotra chetan.mehro...@gmail.com: On Wed, Feb 12, 2014 at 1:26 PM, Felix Meschberger fmesc...@adobe.com wrote: Hence, I would really prefer to get our start levels straight and reserve 1 to logging and move the install stuff to 2. You never allow to take the short cut :) I fight special cases as long as possible, yes :-) Okie thinking about tackling the real problem of moving existing bundle to start level 1 I can think of following approach 1. Currently we are not using startlevel 2,3,4 Yes. 2. Introduce a new command ChangeStartLevelCommand which would use the StartLevel service to change the start level of non fragment bundle having existing level 1. or it can be generic to change the level from a - b. One thing to decide at this step is that command should work on explicit parameters e.g. change start level only for list bundles OR Is an automatic one where it would find all bundles at 1 and change levels for non fragment and non logging related bundle You mean a command for bootstrap.txt like uninstall ? Sounds good. This command could take a regular expression for symbolic names and optionally a version range to select bundles and then a target start level. Optionally it could take a source start level and a target start level to move all bundles with the source start level to the target start level EBND definition: StartLevelCommand = startlevel Source TargetStartLevel . Source = SourceStartLevel | Bundle . SourceStartLevel = numeric startlevel value 0 . TargetStartLevel = numeric startlevel value 0 . Bundle = BundleSymbolicName VersionRange . BundleSymbolicName = regular expression match for bundle symbolic name . VersionRange = OSGi version range to match bundles . Examples: # move all bundles currently set to startlevel 20 to startlevel 40 startlevel 20 40 # move all bundles to startlevel 2 startlevel .* 2 # move installer bundles to startlevel 2 startlevel .*\.installer\..* 2 Regards Felix +1 3. Change the list.xml and move non fragment bundle (except loggging related) to level 2 +1 Would this work or is something missing here? Sounds good to me. Regards Felix Chetan Mehrotra -- Carsten Ziegeler cziege...@apache.org
[jira] [Resolved] (SLING-2986) Merged Resource Provider
[ https://issues.apache.org/jira/browse/SLING-2986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-2986. - Resolution: Fixed Merged Resource Provider Key: SLING-2986 URL: https://issues.apache.org/jira/browse/SLING-2986 Project: Sling Issue Type: New Feature Components: Extensions Reporter: Gilles Knobloch Assignee: Carsten Ziegeler Fix For: Resource Merger 1.0.0 Attachments: SLING-2986-WithService.zip, SLING-2986.zip As exchanged once with Felix Meschberger, the idea is to implement a custom resource provider, with ability to merge multiple resources based on your search paths. For instance, if your search paths are /apps /libs Hitting /merge/my/resource/is/here will check /apps/my/resource/is/here /libs/my/resource/is/here There are some options like: - add/override property - delete a property of the resource under /libs - reorder nodes if available I intend to submit this patch as soon as possible. Code is currently located at https://github.com/gknob/sling-resourcemerger -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (SLING-2986) Merged Resource Provider
[ https://issues.apache.org/jira/browse/SLING-2986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13903236#comment-13903236 ] Carsten Ziegeler commented on SLING-2986: - I've changed the default mount path to /mnt/overlay Setting this to fixed now Merged Resource Provider Key: SLING-2986 URL: https://issues.apache.org/jira/browse/SLING-2986 Project: Sling Issue Type: New Feature Components: Extensions Reporter: Gilles Knobloch Assignee: Carsten Ziegeler Fix For: Resource Merger 1.0.0 Attachments: SLING-2986-WithService.zip, SLING-2986.zip As exchanged once with Felix Meschberger, the idea is to implement a custom resource provider, with ability to merge multiple resources based on your search paths. For instance, if your search paths are /apps /libs Hitting /merge/my/resource/is/here will check /apps/my/resource/is/here /libs/my/resource/is/here There are some options like: - add/override property - delete a property of the resource under /libs - reorder nodes if available I intend to submit this patch as soon as possible. Code is currently located at https://github.com/gknob/sling-resourcemerger -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: Installation and start order for logging (was: [jira] [Commented] (SLING-3386) Enable support starting bundle in custom oreder at start level 1)
Thanks, I don't think we need 2 if we have 3. If we have support in list.xml for different boot start levels (that's actually the hard part), then the implementation can just adjust the start level of available bundles according to the new info - this is what the installer does and works quiet well. Carsten 2014-02-17 13:54 GMT+01:00 Chetan Mehrotra chetan.mehro...@gmail.com: Hi Carsten, To summarize. 1. Need to clear the start level 1 and keep only logging related bundles and framework fragments at that level. Move all other bundles to Start Level 2 2. For upgraded system we implement a new Bootstrap command say ChangeStartLevelCommand. This would change the start level of bundle from a to b. This would then be used to implement #1 3. For new system the list.xml needs to be updated I would be trying out #2 and come back to the list on how it works in practice. It might take some time given some other work in progress Chetan Mehrotra On Mon, Feb 17, 2014 at 5:37 PM, Carsten Ziegeler cziege...@apache.org wrote: Can someone please summarize what exactly is proposed, especially for SLING-3388 ? Thanks Carsten 2014-02-12 11:14 GMT+01:00 Felix Meschberger fmesc...@adobe.com: Am 12.02.2014 um 11:01 schrieb Chetan Mehrotra chetan.mehro...@gmail.com : For now I think we can keep the implementation simple. For example in current case we do not have to change start level for Fragments and Slf4j related bundle. So need to change start level of some listed bundles only startlevel 20 40 Do not see a requirement to move all existing bundle to different level ok startlevel .* 2 startlevel .*\.installer\..* 2 For now would like to keep it simple to changestartlevel symbolic name:version? target level I still would suggest to support a version range, though. If need arises for more advance usecase then they can be added later Created SLING-3388 for the same. Thanks Felix Chetan Mehrotra On Wed, Feb 12, 2014 at 2:58 PM, Felix Meschberger fmesc...@adobe.com wrote: Hi Am 12.02.2014 um 09:58 schrieb Felix Meschberger fmesc...@adobe.com : Hi Am 12.02.2014 um 09:22 schrieb Chetan Mehrotra chetan.mehro...@gmail.com: On Wed, Feb 12, 2014 at 1:26 PM, Felix Meschberger fmesc...@adobe.com wrote: Hence, I would really prefer to get our start levels straight and reserve 1 to logging and move the install stuff to 2. You never allow to take the short cut :) I fight special cases as long as possible, yes :-) Okie thinking about tackling the real problem of moving existing bundle to start level 1 I can think of following approach 1. Currently we are not using startlevel 2,3,4 Yes. 2. Introduce a new command ChangeStartLevelCommand which would use the StartLevel service to change the start level of non fragment bundle having existing level 1. or it can be generic to change the level from a - b. One thing to decide at this step is that command should work on explicit parameters e.g. change start level only for list bundles OR Is an automatic one where it would find all bundles at 1 and change levels for non fragment and non logging related bundle You mean a command for bootstrap.txt like uninstall ? Sounds good. This command could take a regular expression for symbolic names and optionally a version range to select bundles and then a target start level. Optionally it could take a source start level and a target start level to move all bundles with the source start level to the target start level EBND definition: StartLevelCommand = startlevel Source TargetStartLevel . Source = SourceStartLevel | Bundle . SourceStartLevel = numeric startlevel value 0 . TargetStartLevel = numeric startlevel value 0 . Bundle = BundleSymbolicName VersionRange . BundleSymbolicName = regular expression match for bundle symbolic name . VersionRange = OSGi version range to match bundles . Examples: # move all bundles currently set to startlevel 20 to startlevel 40 startlevel 20 40 # move all bundles to startlevel 2 startlevel .* 2 # move installer bundles to startlevel 2 startlevel .*\.installer\..* 2 Regards Felix +1 3. Change the list.xml and move non fragment bundle (except loggging related) to level 2 +1 Would this work or is something missing here? Sounds good to me. Regards Felix Chetan Mehrotra -- Carsten Ziegeler cziege...@apache.org -- Carsten Ziegeler cziege...@apache.org
[jira] [Resolved] (SLING-3396) [discovery] Increase default heartbeatInterval from 15s to 30s and timeout from 45s to 60s
[ https://issues.apache.org/jira/browse/SLING-3396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli resolved SLING-3396. Resolution: Fixed Fix Version/s: Discovery Impl 1.0.4 fixed. [discovery] Increase default heartbeatInterval from 15s to 30s and timeout from 45s to 60s -- Key: SLING-3396 URL: https://issues.apache.org/jira/browse/SLING-3396 Project: Sling Issue Type: Task Components: Extensions Affects Versions: Discovery Impl 1.0.2 Reporter: Stefan Egli Assignee: Stefan Egli Fix For: Discovery Impl 1.0.4 The default for heartbeatInterval is 15sec currently. This is rather fast and should be lowered to 30sec. The default heartbeatTimeout can also be upped from 45sec to 60sec. Note that this lowered chattyness and provides higher stability in high-load situations, but also increases reaction time slightly when an instance indeed crashes. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (SLING-3396) [discovery] Increase default heartbeatInterval from 15s to 30s and timeout from 45s to 60s
Stefan Egli created SLING-3396: -- Summary: [discovery] Increase default heartbeatInterval from 15s to 30s and timeout from 45s to 60s Key: SLING-3396 URL: https://issues.apache.org/jira/browse/SLING-3396 Project: Sling Issue Type: Task Components: Extensions Affects Versions: Discovery Impl 1.0.2 Reporter: Stefan Egli Assignee: Stefan Egli The default for heartbeatInterval is 15sec currently. This is rather fast and should be lowered to 30sec. The default heartbeatTimeout can also be upped from 45sec to 60sec. Note that this lowered chattyness and provides higher stability in high-load situations, but also increases reaction time slightly when an instance indeed crashes. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: [VOTE] Release Apache Sling JCR API 2.2.0, JCR Base 2.2.0 and JCR Resource 2.3.0
Still missing one binding vote :( Sigh Carsten 2014-02-17 10:13 GMT+01:00 Ian Boston i...@tfd.co.uk: +1 Ian On 17 February 2014 08:37, Carsten Ziegeler cziege...@apache.org wrote: Anyone, please? 2014-02-06 19:17 GMT+01:00 Carsten Ziegeler cziege...@apache.org: We're missing some binding votes here, anyone? Thanks Carsten 2014-01-30 21:19 GMT+01:00 Oliver Lietz apa...@oliverlietz.de: Am Donnerstag, 30. Januar 2014 schrieb Carsten Ziegeler: Hi, this vote is about three related modules in the jcr space, apart from bug fixes it contains the base for the replacement of login administrative JCR API 2.2.0 https://issues.apache.org/jira/browse/SLING/fixforversion/12315316 JCR Base 2.2.0 https://issues.apache.org/jira/browse/SLING/fixforversion/12319516 JCR Resource https://issues.apache.org/jira/browse/SLING/fixforversion/12324379 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1008 You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1008 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours. +1 O. Regards Carsten -- Carsten Ziegeler cziege...@apache.org -- Carsten Ziegeler cziege...@apache.org -- Carsten Ziegeler cziege...@apache.org
Re: Request Parameter Themes
Hi, thanks - this looks good to me, especially as the performance impact should be neglectable. I'm not sure if we really should split this into a separate bundle for now - we can do it later if the need arises. So basically +1 Carsten 2014-02-17 10:35 GMT+01:00 Felix Meschberger fmesc...@adobe.com: Hi all I have been working in my whiteboard extending Sling's request parameter support with the following goals: 1. Support both Servlet API 2 and Servlet API 3 which brings multipart/form-data support with additional API. 2. Support Sling's request parameter support for non-Sling servlets. 3. Make sure request parameters are provided in the order they have been stated in the request 4. Suppport an application requirement to get access to the request parameters in the order they have been defined on the request The third goal actually goes back to a Servlet API deficiency which does not define this order. Unfortunately some of our application require such an order and so we have to make sure. Also some servlet containers (Jetty) support such a request parameter order by internally using a LinkedHashMap while others (Tomcat) don't. With the new implementation of parsing the parameters we solve this difference and always provide a defined order. The implementation can be found at [1] BTW: The hack in the engine bundle using an ant compile step is to be able to compile for both Servlet API 2 and Servlet API 3. If someone has a better, more elegant solution, I am more than happy to change the current hack :-) WDYT ? Regards Felix [1] http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/parameters -- Carsten Ziegeler cziege...@apache.org
Re: Request Parameter Themes
Hi You are right. And as we discussed off-line: Maybe we should make it really clean with the ListNamedRequestParameter getRequestParameterList() method and enance the API: RequestParameter: add String getName(); SlingHttpServletRequest: add ListRequestParameter getRequestParameterList(); The drawback here is, that we add to the API with consequences for implementors of this API, which I actually expect to only be the engine bundle … (others should just extend the SlingHttpServletRequestWrapper class and be fine) WDYT ? Regards Felix Am 17.02.2014 um 16:14 schrieb Carsten Ziegeler cziege...@apache.org: Hi, thanks - this looks good to me, especially as the performance impact should be neglectable. I'm not sure if we really should split this into a separate bundle for now - we can do it later if the need arises. So basically +1 Carsten 2014-02-17 10:35 GMT+01:00 Felix Meschberger fmesc...@adobe.com: Hi all I have been working in my whiteboard extending Sling's request parameter support with the following goals: 1. Support both Servlet API 2 and Servlet API 3 which brings multipart/form-data support with additional API. 2. Support Sling's request parameter support for non-Sling servlets. 3. Make sure request parameters are provided in the order they have been stated in the request 4. Suppport an application requirement to get access to the request parameters in the order they have been defined on the request The third goal actually goes back to a Servlet API deficiency which does not define this order. Unfortunately some of our application require such an order and so we have to make sure. Also some servlet containers (Jetty) support such a request parameter order by internally using a LinkedHashMap while others (Tomcat) don't. With the new implementation of parsing the parameters we solve this difference and always provide a defined order. The implementation can be found at [1] BTW: The hack in the engine bundle using an ant compile step is to be able to compile for both Servlet API 2 and Servlet API 3. If someone has a better, more elegant solution, I am more than happy to change the current hack :-) WDYT ? Regards Felix [1] http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/parameters -- Carsten Ziegeler cziege...@apache.org
[VOTE RESULT] Release Apache Sling JCR API 2.2.0, JCR Base 2.2.0 and JCR Resource 2.3.0
The vote to release JCR API 2.2.0 JCR Base 2.2.0 JCR Resource 2.3.0 passed with three binding +1 votes from Felix Meschberger, Ian Boston, and Carsten Ziegeler and one non binding +1 vote from Oliver Lietz. Thanks Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release Apache Sling JCR API 2.2.0, JCR Base 2.2.0 and JCR Resource 2.3.0
Yes, I agree, new releases will follow soon :) 2014-02-17 16:15 GMT+01:00 Felix Meschberger fmesc...@adobe.com: +1 Sorry for the delay BTW: I think JCR Resource will soon warrant another release for SLING-3380 (and I hope MOVE event support) and JCR Base will probably have an upcomgin 2.3.0 release for an improved base SlingRepository mechanism (already also supported in the Jackrabbit Server and Oak Server bundles). Regards Felix Am 30.01.2014 um 10:24 schrieb Carsten Ziegeler cziege...@apache.org: Hi, this vote is about three related modules in the jcr space, apart from bug fixes it contains the base for the replacement of login administrative JCR API 2.2.0 https://issues.apache.org/jira/browse/SLING/fixforversion/12315316 JCR Base 2.2.0 https://issues.apache.org/jira/browse/SLING/fixforversion/12319516 JCR Resource https://issues.apache.org/jira/browse/SLING/fixforversion/12324379 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1008 You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1008 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours. Regards Carsten -- Carsten Ziegeler cziege...@apache.org -- Carsten Ziegeler cziege...@apache.org
[jira] [Closed] (SLING-3010) Managing Permissions using Sling with Aggregate Privileges
[
https://issues.apache.org/jira/browse/SLING-3010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler closed SLING-3010.
---
Managing Permissions using Sling with Aggregate Privileges
--
Key: SLING-3010
URL: https://issues.apache.org/jira/browse/SLING-3010
Project: Sling
Issue Type: Bug
Components: API
Affects Versions: JCR Base 2.1.2
Reporter: Anjan
Assignee: Eric Norman
Priority: Minor
Labels: aggregate, permissions, privileges
Fix For: JCR Base 2.2.0
I am using Sling's REST interface to modify the permissions on a Node. I
noticed an issue.
The issue I am facing can be best explained by showing the curl commands I
executed and the output I received:
(1) Here is the initial set of privileges present on the node:
$ curl -u admin:admin http://localhost:8080/content/pertest.eacl.json
{test:{principal:test,denied:[jcr:versionManagement,jcr:read,jcr:modifyAccessControl,rep:write],order:0},everyone:{principal:everyone,granted:[jcr:read,jcr:readAccessControl],order:1},administrators:{principal:administrators,granted:[jcr:all],order:2}}
(2) Run the below command to grant all the privileges for test principal
$ curl -u admin:admin -FprincipalId=test
-Fprivilege@jcr:versionManagement=granted -Fprivilege@jcr:read=granted
-Fprivilege@jcr:modifyAccessControl=granted
-Fprivilege@jcr:nodeTypeManagement=granted -Fprivilege@jcr:write=granted
http://localhost:8080/content/pertest.modifyAce.json
(3) As you can see from the below output, jcr:write is still present under
denied privileges for test even though I granted all the privileges in
the previous command
$ curl -u admin:admin http://localhost:8080/content/pertest.eacl.json
{test:{principal:test,granted:[jcr:nodeTypeManagement,jcr:versionManagement,jcr:read,jcr:modifyAccessControl],denied:[jcr:write],order:0},everyone:{principal:everyone,granted:[jcr:read,jcr:readAccessControl],order:1},administrators:{principal:administrators,granted:[jcr:all],order:2}}
Initially I thought it's a bug in Jackrabbit, but after getting the
clarification from Jackrabbit forum, I think it might need to be corrected in
Sling.
Here is the link to the question I raised in Jackrabbit forum:
http://jackrabbit.510166.n4.nabble.com/Bug-or-intended-behavior-getAggregatePrivileges-td4659272.html
Potential fix:
In the class org.apache.sling.jcr.base.util.AccessControlUtil.java, there is
a private method with the below signature:
private static SetString disaggregateToPrivilegeNames(Privilege privilege)
{}
Inside this method, there is a for loop
for (Privilege disaggregate : privileges) {
disaggregatedPrivilegeNames.add(disaggregate.getName());
}
If I modify the above snippet with the below code snippet, then the issue
seems to be resolved.
for (Privilege disaggregate : privileges) {
if(!disaggregate.isAggregate())
disaggregatedPrivilegeNames.add(disaggregate.getName());
}
Based on my initial testing the change seems to be working fine.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (SLING-2964) JcrResourceUtil.createPath() API should handle paths ending with /
[ https://issues.apache.org/jira/browse/SLING-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-2964: Component/s: JCR JcrResourceUtil.createPath() API should handle paths ending with / Key: SLING-2964 URL: https://issues.apache.org/jira/browse/SLING-2964 Project: Sling Issue Type: Improvement Components: JCR Affects Versions: JCR Resource 2.3.0 Reporter: Amrit Verma Priority: Minor Fix For: JCR Resource 2.3.2 Attachments: sling_diff.txt Calling JcrResourceUtil.createPath(String path, String intermediateNodeType, String nodeType, Session session, boolean autoSave) with the parameter as /a/b/c/ , throws following exception if the path doesn't exist: javax.jcr.RepositoryException: Failed to resolve path relative to node /a/b/c at org.apache.jackrabbit.core.NodeImpl.resolveRelativePath(NodeImpl.java:239) at org.apache.jackrabbit.core.NodeImpl.resolveRelativeNodePath(NodeImpl.java:222) at org.apache.jackrabbit.core.NodeImpl.hasNode(NodeImpl.java:2265) at org.apache.sling.jcr.resource.JcrResourceUtil.createPath(JcrResourceUtil.java:341) at org.apache.sling.jcr.resource.JcrResourceUtil.createPath(JcrResourceUtil.java:285) But if the path /a/b/c already exists and we still pass the path parameter as /a/b/c/ the API returns the 'c' node. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (SLING-2964) JcrResourceUtil.createPath() API should handle paths ending with /
[ https://issues.apache.org/jira/browse/SLING-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-2964: --- Assignee: Carsten Ziegeler JcrResourceUtil.createPath() API should handle paths ending with / Key: SLING-2964 URL: https://issues.apache.org/jira/browse/SLING-2964 Project: Sling Issue Type: Improvement Components: JCR Affects Versions: JCR Resource 2.3.0 Reporter: Amrit Verma Assignee: Carsten Ziegeler Priority: Minor Fix For: JCR Resource 2.3.2 Attachments: sling_diff.txt Calling JcrResourceUtil.createPath(String path, String intermediateNodeType, String nodeType, Session session, boolean autoSave) with the parameter as /a/b/c/ , throws following exception if the path doesn't exist: javax.jcr.RepositoryException: Failed to resolve path relative to node /a/b/c at org.apache.jackrabbit.core.NodeImpl.resolveRelativePath(NodeImpl.java:239) at org.apache.jackrabbit.core.NodeImpl.resolveRelativeNodePath(NodeImpl.java:222) at org.apache.jackrabbit.core.NodeImpl.hasNode(NodeImpl.java:2265) at org.apache.sling.jcr.resource.JcrResourceUtil.createPath(JcrResourceUtil.java:341) at org.apache.sling.jcr.resource.JcrResourceUtil.createPath(JcrResourceUtil.java:285) But if the path /a/b/c already exists and we still pass the path parameter as /a/b/c/ the API returns the 'c' node. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (SLING-2964) JcrResourceUtil.createPath() API should handle paths ending with /
[ https://issues.apache.org/jira/browse/SLING-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-2964: Affects Version/s: JCR Resource 2.3.0 JcrResourceUtil.createPath() API should handle paths ending with / Key: SLING-2964 URL: https://issues.apache.org/jira/browse/SLING-2964 Project: Sling Issue Type: Improvement Components: JCR Affects Versions: JCR Resource 2.3.0 Reporter: Amrit Verma Priority: Minor Fix For: JCR Resource 2.3.2 Attachments: sling_diff.txt Calling JcrResourceUtil.createPath(String path, String intermediateNodeType, String nodeType, Session session, boolean autoSave) with the parameter as /a/b/c/ , throws following exception if the path doesn't exist: javax.jcr.RepositoryException: Failed to resolve path relative to node /a/b/c at org.apache.jackrabbit.core.NodeImpl.resolveRelativePath(NodeImpl.java:239) at org.apache.jackrabbit.core.NodeImpl.resolveRelativeNodePath(NodeImpl.java:222) at org.apache.jackrabbit.core.NodeImpl.hasNode(NodeImpl.java:2265) at org.apache.sling.jcr.resource.JcrResourceUtil.createPath(JcrResourceUtil.java:341) at org.apache.sling.jcr.resource.JcrResourceUtil.createPath(JcrResourceUtil.java:285) But if the path /a/b/c already exists and we still pass the path parameter as /a/b/c/ the API returns the 'c' node. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (SLING-2964) JcrResourceUtil.createPath() API should handle paths ending with /
[ https://issues.apache.org/jira/browse/SLING-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-2964: Fix Version/s: JCR Resource 2.3.2 JcrResourceUtil.createPath() API should handle paths ending with / Key: SLING-2964 URL: https://issues.apache.org/jira/browse/SLING-2964 Project: Sling Issue Type: Improvement Components: JCR Affects Versions: JCR Resource 2.3.0 Reporter: Amrit Verma Priority: Minor Fix For: JCR Resource 2.3.2 Attachments: sling_diff.txt Calling JcrResourceUtil.createPath(String path, String intermediateNodeType, String nodeType, Session session, boolean autoSave) with the parameter as /a/b/c/ , throws following exception if the path doesn't exist: javax.jcr.RepositoryException: Failed to resolve path relative to node /a/b/c at org.apache.jackrabbit.core.NodeImpl.resolveRelativePath(NodeImpl.java:239) at org.apache.jackrabbit.core.NodeImpl.resolveRelativeNodePath(NodeImpl.java:222) at org.apache.jackrabbit.core.NodeImpl.hasNode(NodeImpl.java:2265) at org.apache.sling.jcr.resource.JcrResourceUtil.createPath(JcrResourceUtil.java:341) at org.apache.sling.jcr.resource.JcrResourceUtil.createPath(JcrResourceUtil.java:285) But if the path /a/b/c already exists and we still pass the path parameter as /a/b/c/ the API returns the 'c' node. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (SLING-2964) JcrResourceUtil.createPath() API should handle paths ending with /
[ https://issues.apache.org/jira/browse/SLING-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13903324#comment-13903324 ] Carsten Ziegeler commented on SLING-2964: - While I think the client should not pass in a path ending with slash, I agree that both cases should be handled in the same way. As its already working if the node exists, enabling the create seems to be the compatible option to choose JcrResourceUtil.createPath() API should handle paths ending with / Key: SLING-2964 URL: https://issues.apache.org/jira/browse/SLING-2964 Project: Sling Issue Type: Improvement Components: JCR Affects Versions: JCR Resource 2.3.0 Reporter: Amrit Verma Assignee: Carsten Ziegeler Priority: Minor Fix For: JCR Resource 2.3.2 Attachments: sling_diff.txt Calling JcrResourceUtil.createPath(String path, String intermediateNodeType, String nodeType, Session session, boolean autoSave) with the parameter as /a/b/c/ , throws following exception if the path doesn't exist: javax.jcr.RepositoryException: Failed to resolve path relative to node /a/b/c at org.apache.jackrabbit.core.NodeImpl.resolveRelativePath(NodeImpl.java:239) at org.apache.jackrabbit.core.NodeImpl.resolveRelativeNodePath(NodeImpl.java:222) at org.apache.jackrabbit.core.NodeImpl.hasNode(NodeImpl.java:2265) at org.apache.sling.jcr.resource.JcrResourceUtil.createPath(JcrResourceUtil.java:341) at org.apache.sling.jcr.resource.JcrResourceUtil.createPath(JcrResourceUtil.java:285) But if the path /a/b/c already exists and we still pass the path parameter as /a/b/c/ the API returns the 'c' node. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (SLING-2964) JcrResourceUtil.createPath() API should handle paths ending with /
[ https://issues.apache.org/jira/browse/SLING-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-2964. - Resolution: Fixed I've added additional checks for the two create methods in rev 1569034 JcrResourceUtil.createPath() API should handle paths ending with / Key: SLING-2964 URL: https://issues.apache.org/jira/browse/SLING-2964 Project: Sling Issue Type: Improvement Components: JCR Affects Versions: JCR Resource 2.3.0 Reporter: Amrit Verma Assignee: Carsten Ziegeler Priority: Minor Fix For: JCR Resource 2.3.2 Attachments: sling_diff.txt Calling JcrResourceUtil.createPath(String path, String intermediateNodeType, String nodeType, Session session, boolean autoSave) with the parameter as /a/b/c/ , throws following exception if the path doesn't exist: javax.jcr.RepositoryException: Failed to resolve path relative to node /a/b/c at org.apache.jackrabbit.core.NodeImpl.resolveRelativePath(NodeImpl.java:239) at org.apache.jackrabbit.core.NodeImpl.resolveRelativeNodePath(NodeImpl.java:222) at org.apache.jackrabbit.core.NodeImpl.hasNode(NodeImpl.java:2265) at org.apache.sling.jcr.resource.JcrResourceUtil.createPath(JcrResourceUtil.java:341) at org.apache.sling.jcr.resource.JcrResourceUtil.createPath(JcrResourceUtil.java:285) But if the path /a/b/c already exists and we still pass the path parameter as /a/b/c/ the API returns the 'c' node. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (SLING-3397) Provide a way for path operations
Carsten Ziegeler created SLING-3397: --- Summary: Provide a way for path operations Key: SLING-3397 URL: https://issues.apache.org/jira/browse/SLING-3397 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Resource Merger 1.0.0 With the resource merger we have a new resource provider which is mounted somewhere in the resource tree. While the resource resolver has a method to get the search path, there is no way to find out, the mnt point for the resource merger. In addition, in some cases you already have a resource from within a search path and you want to access the merged resource -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (SLING-3397) Provide a way for path operations
[ https://issues.apache.org/jira/browse/SLING-3397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13903345#comment-13903345 ] Carsten Ziegeler commented on SLING-3397: - I suggest an API consisting of an Utility class with these methods: /** * Return the absolute path for the merged resource */ String getMergedResourcePath(String relativePath) /** * Returns a merged resource if the provided resource is from one of the search paths */ Resource getMergedResource(Resource rsrc) boolean isMergedResource(Resource rsrc) Provide a way for path operations - Key: SLING-3397 URL: https://issues.apache.org/jira/browse/SLING-3397 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Resource Merger 1.0.0 With the resource merger we have a new resource provider which is mounted somewhere in the resource tree. While the resource resolver has a method to get the search path, there is no way to find out, the mnt point for the resource merger. In addition, in some cases you already have a resource from within a search path and you want to access the merged resource -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (SLING-3393) Parameter re-encoding does not work for Jetty 7 and above
[ https://issues.apache.org/jira/browse/SLING-3393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reassigned SLING-3393: Assignee: Felix Meschberger (was: Amit Gupta) Parameter re-encoding does not work for Jetty 7 and above - Key: SLING-3393 URL: https://issues.apache.org/jira/browse/SLING-3393 Project: Sling Issue Type: Bug Components: Engine Affects Versions: Engine 2.2.10 Reporter: Dominique Pfister Assignee: Felix Meschberger Attachments: SLING-3393.patch SLING-559 changed the query encoding to 8859-1 when used in combination with Jetty, by setting a request attribute called: org.mortbay.jetty.Request.queryEncoding With Jetty 7 and above, this attribute has been changed to: org.eclipse.jetty.server.Request.queryEncoding [1], so the fix no longer works. I suggest to either use both attribute names or only the new one, if support for Jetty 6 or earlier is no longer a must. [1] http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/server/Request.html#setQueryEncoding(java.lang.String) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (SLING-3393) Parameter re-encoding does not work for Jetty 7 and above
[ https://issues.apache.org/jira/browse/SLING-3393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-3393. -- Resolution: Fixed Fix Version/s: Engine 2.2.12 Thanks for providing the patch. I have applied it (slightly reformatted) in Rev. 1569040. Please note, that the approach discussed on the Sling dev list [Request Parameter Themes|http://sling.markmail.org/thread/iw5lxsb6ewpefvvv] might render this patch obsolete. At least it solves the short term problem. Parameter re-encoding does not work for Jetty 7 and above - Key: SLING-3393 URL: https://issues.apache.org/jira/browse/SLING-3393 Project: Sling Issue Type: Bug Components: Engine Affects Versions: Engine 2.2.10 Reporter: Dominique Pfister Assignee: Felix Meschberger Fix For: Engine 2.2.12 Attachments: SLING-3393.patch SLING-559 changed the query encoding to 8859-1 when used in combination with Jetty, by setting a request attribute called: org.mortbay.jetty.Request.queryEncoding With Jetty 7 and above, this attribute has been changed to: org.eclipse.jetty.server.Request.queryEncoding [1], so the fix no longer works. I suggest to either use both attribute names or only the new one, if support for Jetty 6 or earlier is no longer a must. [1] http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/server/Request.html#setQueryEncoding(java.lang.String) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (SLING-3397) Provide a way for path operations
[ https://issues.apache.org/jira/browse/SLING-3397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13903357#comment-13903357 ] Gilles Knobloch commented on SLING-3397: +1 Provide a way for path operations - Key: SLING-3397 URL: https://issues.apache.org/jira/browse/SLING-3397 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Resource Merger 1.0.0 With the resource merger we have a new resource provider which is mounted somewhere in the resource tree. While the resource resolver has a method to get the search path, there is no way to find out, the mnt point for the resource merger. In addition, in some cases you already have a resource from within a search path and you want to access the merged resource -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (SLING-3397) Provide a way for path operations
[
https://issues.apache.org/jira/browse/SLING-3397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Knobloch updated SLING-3397:
---
Attachment: SLING-3397.patch
I think this has to be done through a service, and not just a utility class.
Indeed, you need to get the value of the merge root path and access to resolver
search paths (which you could solve through passing the resolved as first
argument - but merge root path would still be missing).
My proposal is to make the {{ResourceProviderFactory}} implement a new service
{{ResourceMergerService}}, which contains the 3 methods [~cziegeler] proposed.
Misc:
* Fixed {{sling.mergedResource}} as metadata flag instead of
{{sling.mappedResource}} - I guess it's a typo from my initial patch
* Fixed an issue in how the merge root path is initialized if it ends with a
{{/}}
I tested the provided patch in my application and it seems to work fine.
Provide a way for path operations
-
Key: SLING-3397
URL: https://issues.apache.org/jira/browse/SLING-3397
Project: Sling
Issue Type: Improvement
Components: Extensions
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
Fix For: Resource Merger 1.0.0
Attachments: SLING-3397.patch
With the resource merger we have a new resource provider which is mounted
somewhere in the resource tree.
While the resource resolver has a method to get the search path, there is no
way to find out, the mnt point for the resource merger.
In addition, in some cases you already have a resource from within a search
path and you want to access the merged resource
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
Tenant Implementation in Sling
Hi I am working for a client which needs support for tenants and because the current implementation of the Tenants in Sling is just that but no integration I started to code a workaround. For now I have a patch that does the trick but it is not clean because I use a Servlet Filter to place the tenant id on a thread local instance. Afterwards I started to look into how to implemented this cleanly into the current version of Sling. There are a few areas that need to be changed in order to implement tenant support. For now I am only looking into how to implement a “per-call overlays of servlets / JSPs” in order to give tenants the chance to change aspects of their presentation. 1) Tenant Identification: Sling must be able to identify a tenant. This can be a sub domain, path, cookies or even parameters. This means the client needs to provide a service which is then used by Sling in order to retrieve the tenant and provide it to whomever wants to use it. 2) Servlet Resolver needs to be changed twofolds a) Being able to extend the search path for Servlets / JSPs based on the tenant’s data b) Caching the Servlets / JPSs separated for different tenants 3) Change the Felix OSGi Web Plugin to allow the clients to add properties (single and multi values) For 1) I would suggest just to define an interface the client can implement as an OSGi service which is used to identify a tenant. Then somewhere in the SlingMainServlet or the Request Data the Tenant is retrieved set on the Sling Http Servlet Request and if applicable the Search Path of the Resource Resolver is “enhanced/extended”. For 2) I would suggest to add a new property to the Resource Resolver which contains the Search Path Extension. Because the Servlet Resolver uses the Administrative Resource Resolver we need a way to “Enhance the Search Path” for that particular call. This could be done with a one-off wrapper. Based on the Extended Search Path we can determine which Servlet is an overlay and cache the overlays separately. 3) should be straight forward. Carsten was suggesting something like a TenantProvider like the ServletProvider but in the current code the ServletProvider is called with either the Sling Servlet Request, the Resource or a Resource Resolver and path. This means the tenant id must be available to any of these calls which would require to put the tenant id inside the Resource Resolver. Let me know what you think. - Andy Schaefer
Re: Tenant Implementation in Sling
Hi Andy, Thank you for bringing this up. I have a similar requirement. I don’t see any way of integrating Tenants other than patching Servlet Resolver. This is what I had done for my customer but for a really specific case (they are not truly multi-tenant). I also had to use ThreadLocal. I didn’t really see a better approach because a request is not always available in servlet resolver. So, if you have to map your tenant id to any information in the request you have to. Please let me know if you can think of something better. Also, for 1) I think beyond an interface you can provide some generic implementation and configuration factory. With configuration factory you can create and configure multiple instances with different configurations (sub-domain/path/cookies/parameters). With this I would say 3) is not a requirement unless I miss-undertood what you meant. Maybe you could open a JIRA ticket and post a patch there. Henry On Feb 17, 2014, at 6:58 PM, Andreas Schaefer Sr. schaef...@me.com wrote: Hi I am working for a client which needs support for tenants and because the current implementation of the Tenants in Sling is just that but no integration I started to code a workaround. For now I have a patch that does the trick but it is not clean because I use a Servlet Filter to place the tenant id on a thread local instance. Afterwards I started to look into how to implemented this cleanly into the current version of Sling. There are a few areas that need to be changed in order to implement tenant support. For now I am only looking into how to implement a “per-call overlays of servlets / JSPs” in order to give tenants the chance to change aspects of their presentation. 1) Tenant Identification: Sling must be able to identify a tenant. This can be a sub domain, path, cookies or even parameters. This means the client needs to provide a service which is then used by Sling in order to retrieve the tenant and provide it to whomever wants to use it. 2) Servlet Resolver needs to be changed twofolds a) Being able to extend the search path for Servlets / JSPs based on the tenant’s data b) Caching the Servlets / JPSs separated for different tenants 3) Change the Felix OSGi Web Plugin to allow the clients to add properties (single and multi values) For 1) I would suggest just to define an interface the client can implement as an OSGi service which is used to identify a tenant. Then somewhere in the SlingMainServlet or the Request Data the Tenant is retrieved set on the Sling Http Servlet Request and if applicable the Search Path of the Resource Resolver is “enhanced/extended”. For 2) I would suggest to add a new property to the Resource Resolver which contains the Search Path Extension. Because the Servlet Resolver uses the Administrative Resource Resolver we need a way to “Enhance the Search Path” for that particular call. This could be done with a one-off wrapper. Based on the Extended Search Path we can determine which Servlet is an overlay and cache the overlays separately. 3) should be straight forward. Carsten was suggesting something like a TenantProvider like the ServletProvider but in the current code the ServletProvider is called with either the Sling Servlet Request, the Resource or a Resource Resolver and path. This means the tenant id must be available to any of these calls which would require to put the tenant id inside the Resource Resolver. Let me know what you think. - Andy Schaefer
[jira] [Resolved] (SLING-3397) Provide a way for path operations
[ https://issues.apache.org/jira/browse/SLING-3397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-3397. - Resolution: Fixed Thanks for your patch, Gilles. I've applied a slightly modified version which also corrects the name of the other metadata entry (from sling.mappedResources to sling.mergedResources) Provide a way for path operations - Key: SLING-3397 URL: https://issues.apache.org/jira/browse/SLING-3397 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Resource Merger 1.0.0 Attachments: SLING-3397.patch With the resource merger we have a new resource provider which is mounted somewhere in the resource tree. While the resource resolver has a method to get the search path, there is no way to find out, the mnt point for the resource merger. In addition, in some cases you already have a resource from within a search path and you want to access the merged resource -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (SLING-3398) Implement techempower.com benchmarks for Sling
Felix Meschberger created SLING-3398: Summary: Implement techempower.com benchmarks for Sling Key: SLING-3398 URL: https://issues.apache.org/jira/browse/SLING-3398 Project: Sling Issue Type: Wish Components: General Reporter: Felix Meschberger TechEmpore provides a benchmark framework for Web Application frameworks to compare their performance. See http://www.techempower.com/benchmarks/ We should implement these benchmarks for Sling to see where Sling stands in this comparison. It would be great if we could contribute the Sling benchmarks to TechEmpower to include it in their comparison chart. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
