Re: @Adapter methods, ready to integrate in trunk, WDYT?
For now I'm against committing this to trunk, as previously mentioned I would prefer having a build time annotation. If this is not possible, then the annotation and the AdapterProvider should be in the same package as there is no use case for using one without the other. One solution for a build time annotation would be to define a server registration property for a AdapterProvider containing the method names and at build time the value of this property would be generated by using the annotation. This would be similar to the bind/unbind methods of DS. Regards Carsten 2013/7/3 Carsten Ziegeler cziege...@apache.org Just read the answer in the issue :) I like the general intention - however it feels a little bit strange to register a AdapterProvider, annotate a method and then this gets picked up at runtime and a new AdapterFactory is registered. Can't we make this annoation build time only - as an extensions of the SCR annotations? Carsten 2013/7/3 Carsten Ziegeler cziege...@apache.org Hi, sounds interesting - could you please elaborate a little bit on who is processing this annotation and when? Thanks Carsten 2013/7/3 Bertrand Delacretaz bdelacre...@apache.org On Wed, Jul 3, 2013 at 3:07 PM, Justin Edelson jus...@justinedelson.com wrote: ... @Adapter(condition=if the resource type is slingbucks/list). ... Makes sense, noted in SLING-2938 -Bertrand -- Carsten Ziegeler cziege...@apache.org -- Carsten Ziegeler cziege...@apache.org -- Carsten Ziegeler cziege...@apache.org
[jira] [Created] (SLING-2944) Replace administrative login by service-based login
Felix Meschberger created SLING-2944: Summary: Replace administrative login by service-based login Key: SLING-2944 URL: https://issues.apache.org/jira/browse/SLING-2944 Project: Sling Issue Type: New Feature Components: API, JCR, ResourceResolver Affects Versions: Resource Resolver 1.0.6, API 2.4.2, JCR API 2.1.0, JCR Base 2.1.2, JCR Jackrabbit Server 2.1.0, JCR Resource 2.2.8 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: JCR Resource 2.2.10, JCR Jackrabbit Server 2.1.2, JCR Base 2.1.4, JCR API 2.1.2, API 2.4.4, Resource Resolver 1.0.8 From the start Sling tried to solve the problem of providing services access to the repository and resource tree without having to hard code and configure any passwords. This was done first with the SlingRepository.loginAdministrative and later with the ResourceResolverFactory.getAdministrativeResourceResolver methods. Over time this mechanism proved to be the hammer to hit all nails. Particularly these methods while truly useful have the disadvantage of providing full administrative privileges to services where just some specific kind of privilege would be enough. For example for the JSP compiler it would be enough to be able to read the JSP source scripts and write the Java classes out to the JSP compiler's target location. Other access is not required. Similarly to manage users user management privileges are enough and no access to /content is really required. To solve this problem a new API for Service Authentication has been proposed at https://cwiki.apache.org/confluence/display/SLING/Service+Authentication. The prototype of which is implemented in http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/deprecate_login_administrative. This issue is about merging the prototype code back into trunk and thus fully implementing the feature. -- 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-2944) Replace administrative login by service-based login
[ https://issues.apache.org/jira/browse/SLING-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-2944: - Component/s: Service User Mapper Replace administrative login by service-based login --- Key: SLING-2944 URL: https://issues.apache.org/jira/browse/SLING-2944 Project: Sling Issue Type: New Feature Components: API, JCR, ResourceResolver, Service User Mapper Affects Versions: JCR Resource 2.2.8, JCR Jackrabbit Server 2.1.0, JCR Base 2.1.2, JCR API 2.1.0, API 2.4.2, Resource Resolver 1.0.6 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: JCR Resource 2.2.10, JCR Jackrabbit Server 2.1.2, JCR Base 2.1.4, JCR API 2.1.2, API 2.5.0, Resource Resolver 1.0.8 From the start Sling tried to solve the problem of providing services access to the repository and resource tree without having to hard code and configure any passwords. This was done first with the SlingRepository.loginAdministrative and later with the ResourceResolverFactory.getAdministrativeResourceResolver methods. Over time this mechanism proved to be the hammer to hit all nails. Particularly these methods while truly useful have the disadvantage of providing full administrative privileges to services where just some specific kind of privilege would be enough. For example for the JSP compiler it would be enough to be able to read the JSP source scripts and write the Java classes out to the JSP compiler's target location. Other access is not required. Similarly to manage users user management privileges are enough and no access to /content is really required. To solve this problem a new API for Service Authentication has been proposed at https://cwiki.apache.org/confluence/display/SLING/Service+Authentication. The prototype of which is implemented in http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/deprecate_login_administrative. This issue is about merging the prototype code back into trunk and thus fully implementing the feature. -- 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-2944) Replace administrative login by service-based login
[ https://issues.apache.org/jira/browse/SLING-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-2944: - Fix Version/s: Service User Mapper 1.0.0 Replace administrative login by service-based login --- Key: SLING-2944 URL: https://issues.apache.org/jira/browse/SLING-2944 Project: Sling Issue Type: New Feature Components: API, JCR, ResourceResolver, Service User Mapper Affects Versions: JCR Resource 2.2.8, JCR Jackrabbit Server 2.1.0, JCR Base 2.1.2, JCR API 2.1.0, API 2.4.2, Resource Resolver 1.0.6 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Service User Mapper 1.0.0, JCR Resource 2.2.10, JCR Jackrabbit Server 2.1.2, JCR Base 2.1.4, JCR API 2.1.2, API 2.5.0, Resource Resolver 1.0.8 From the start Sling tried to solve the problem of providing services access to the repository and resource tree without having to hard code and configure any passwords. This was done first with the SlingRepository.loginAdministrative and later with the ResourceResolverFactory.getAdministrativeResourceResolver methods. Over time this mechanism proved to be the hammer to hit all nails. Particularly these methods while truly useful have the disadvantage of providing full administrative privileges to services where just some specific kind of privilege would be enough. For example for the JSP compiler it would be enough to be able to read the JSP source scripts and write the Java classes out to the JSP compiler's target location. Other access is not required. Similarly to manage users user management privileges are enough and no access to /content is really required. To solve this problem a new API for Service Authentication has been proposed at https://cwiki.apache.org/confluence/display/SLING/Service+Authentication. The prototype of which is implemented in http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/deprecate_login_administrative. This issue is about merging the prototype code back into trunk and thus fully implementing the feature. -- 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: @Adapter methods, ready to integrate in trunk, WDYT?
Hi Carsten, On Thu, Jul 4, 2013 at 8:56 AM, Carsten Ziegeler cziege...@apache.org wrote: ...For now I'm against committing this to trunk, as previously mentioned I would prefer having a build time annotation. If this is not possible, then the annotation and the AdapterProvider should be in the same package as there is no use case for using one without the other Yes, I was actually wondering about putting the annotation and AdapterProvider in the org.apache.sling.adapter bundle instead of sling.api. That's slightly inconsistent with having the AdapterFactory in the sling.api bundle, but we can rightly consider these new interfaces as being adapter extensions, WDYT?. OTOH I don't like @Adapter being a build-time only annotation - by doing this you either tie people to Maven, or have to provide build-time extensions for all common build tools (Maven, ant command-line etc) which is a lot of work for such a simple feature. If you want to create a build-time tool in addition why not, but I don't want to make this build-time only. If you compare with declarative services, the build-time plugin is very useful but you can also perfectly work without it. One solution for a build time annotation would be to define a server registration property for a AdapterProvider containing the method names... That's much more complicated to write than just an @Adapter annotation on a method. -Bertrand
Re: @Adapter methods, ready to integrate in trunk, WDYT?
On Thu, Jul 4, 2013 at 10:28 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Thu, Jul 4, 2013 at 8:56 AM, Carsten Ziegeler cziege...@apache.org wrote: One solution for a build time annotation would be to define a server registration property for a AdapterProvider containing the method names... That's much more complicated to write than just an @Adapter annotation on a method... Ah sorry, reread your message and I overlooked the at build time the value of this property would be generated by using the annotation part - still, I don't want this to be build-time only. -Bertrand
[jira] [Resolved] (SLING-2926) Wasted work in AbstractGetAclServlet.doGet()
[ https://issues.apache.org/jira/browse/SLING-2926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-2926. - Resolution: Fixed Fix Version/s: JCR Jackrabbit Access Manager 2.1.2 Thanks for your patch, it's applied Wasted work in AbstractGetAclServlet.doGet() Key: SLING-2926 URL: https://issues.apache.org/jira/browse/SLING-2926 Project: Sling Issue Type: Bug Components: JCR Environment: any Reporter: Adrian Nistor Assignee: Carsten Ziegeler Labels: patch, perfomance Fix For: JCR Jackrabbit Access Manager 2.1.2 Attachments: patch.diff The problem appears in revision 1495454. I attached a one-line patch that fixes it. In method AbstractGetAclServlet.doGet, the loop over selectors should break immediately after isTidy is set to true. All the iterations after isTidy is set to true do not perform any useful work, at best they just set isTidy again to true. Method isLive in class ResourceResolverContext has a similar loop (over dynamicProviders), and this loop breaks immediately after result is set to false, just like in the proposed patch. Other methods (e.g., FactoryPreconditions.checkPreconditions, JspUtil.checkAttributes, EclipseJavaCompiler.compile, SecondPassVisitor.appendPageDirective) also have similar loops with similar breaks, just like in the proposed patch. -- 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] [Assigned] (SLING-2926) Wasted work in AbstractGetAclServlet.doGet()
[ https://issues.apache.org/jira/browse/SLING-2926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-2926: --- Assignee: Carsten Ziegeler Wasted work in AbstractGetAclServlet.doGet() Key: SLING-2926 URL: https://issues.apache.org/jira/browse/SLING-2926 Project: Sling Issue Type: Bug Components: JCR Environment: any Reporter: Adrian Nistor Assignee: Carsten Ziegeler Labels: patch, perfomance Attachments: patch.diff The problem appears in revision 1495454. I attached a one-line patch that fixes it. In method AbstractGetAclServlet.doGet, the loop over selectors should break immediately after isTidy is set to true. All the iterations after isTidy is set to true do not perform any useful work, at best they just set isTidy again to true. Method isLive in class ResourceResolverContext has a similar loop (over dynamicProviders), and this loop breaks immediately after result is set to false, just like in the proposed patch. Other methods (e.g., FactoryPreconditions.checkPreconditions, JspUtil.checkAttributes, EclipseJavaCompiler.compile, SecondPassVisitor.appendPageDirective) also have similar loops with similar breaks, just like in the proposed patch. -- 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-2927) Wasted work in ValidateVisitor.isExpression()
[ https://issues.apache.org/jira/browse/SLING-2927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-2927. - Resolution: Fixed Fix Version/s: Scripting JSP 2.0.30 Assignee: Carsten Ziegeler Thanks for your patch, I've applied a slightly different version Wasted work in ValidateVisitor.isExpression() - Key: SLING-2927 URL: https://issues.apache.org/jira/browse/SLING-2927 Project: Sling Issue Type: Bug Components: Scripting Environment: any Reporter: Adrian Nistor Assignee: Carsten Ziegeler Labels: patch, performance Fix For: Scripting JSP 2.0.30 Attachments: patch.diff The problem appears in version 6 and in revision 1495454. I attached a two-line patch that fixes it. In method ValidateVisitor.isExpression, the loop over nodes should break immediately after elExpression is set to true. All the iterations after elExpression is set to true do not perform any useful work, at best they just set elExpression again to true. Method isLive in class ResourceResolverContext has a similar loop (over dynamicProviders), and this loop breaks immediately after result is set to false, just like in the proposed patch. Other methods (e.g., FactoryPreconditions.checkPreconditions, JspUtil.checkAttributes, EclipseJavaCompiler.compile, SecondPassVisitor.appendPageDirective) also have similar loops with similar breaks, just like in the proposed patch. -- 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
Jenkins build is back to normal : sling-trunk-1.6 » Apache Sling Jackrabbit Embedded Repository #1713
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.jcr.jackrabbit.server/1713/
Jenkins build is unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing WAR version #1713
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing-war/1713/
Jenkins build is unstable: sling-trunk-1.6 » Apache Sling Resource-Based Discovery Service #1713
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.discovery.impl/1713/
[jira] [Resolved] (SLING-2934) Wasted work in ValidateVisitor.checkXmlAttributes()
[ https://issues.apache.org/jira/browse/SLING-2934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-2934. - Resolution: Fixed Fix Version/s: Scripting JSP 2.0.30 Assignee: Carsten Ziegeler Thanks for your patch, it's applied Wasted work in ValidateVisitor.checkXmlAttributes() --- Key: SLING-2934 URL: https://issues.apache.org/jira/browse/SLING-2934 Project: Sling Issue Type: Bug Components: Scripting Environment: any Reporter: Adrian Nistor Assignee: Carsten Ziegeler Labels: patch, performance Fix For: Scripting JSP 2.0.30 Attachments: patch.diff The problem appears in version 6 and in revision 1495454. I attached a one-line patch that fixes it. In method ValidateVisitor.checkXmlAttributes, the loop over nodes should break immediately after elExpression and deferredValueIsLiteral are set to true. All the iterations after elExpression and deferredValueIsLiteral are set to true do not perform any useful work, at best they just set elExpression and deferredValueIsLiteral again to true. Method isLive in class ResourceResolverContext has a similar loop (over dynamicProviders), and this loop breaks immediately after result is set to false, just like in the proposed patch. Other methods (e.g., FactoryPreconditions.checkPreconditions, JspUtil.checkAttributes, EclipseJavaCompiler.compile, SecondPassVisitor.appendPageDirective) also have similar loops with similar breaks, just like in the proposed patch. -- 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-2933) Wasted work in ValidateVisitor.getJspAttribute()
[ https://issues.apache.org/jira/browse/SLING-2933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-2933. - Resolution: Fixed Fix Version/s: Scripting JSP 2.0.30 Assignee: Carsten Ziegeler Thanks for your patch. I've applied a slightly modified version Wasted work in ValidateVisitor.getJspAttribute() Key: SLING-2933 URL: https://issues.apache.org/jira/browse/SLING-2933 Project: Sling Issue Type: Bug Components: Scripting Environment: any Reporter: Adrian Nistor Assignee: Carsten Ziegeler Labels: patch, performance Fix For: Scripting JSP 2.0.30 Attachments: patch.diff The problem appears in version 6 and in revision 1495454. I attached a one-line patch that fixes it. In method ValidateVisitor.getJspAttribute, the loop over nodes should break immediately after deferred is set to true. All the iterations after deferred is set to true do not perform any useful work, at best they just set deferred again to true. Method isLive in class ResourceResolverContext has a similar loop (over dynamicProviders), and this loop breaks immediately after result is set to false, just like in the proposed patch. Other methods (e.g., FactoryPreconditions.checkPreconditions, JspUtil.checkAttributes, EclipseJavaCompiler.compile, SecondPassVisitor.appendPageDirective) also have similar loops with similar breaks, just like in the proposed patch. -- 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: @Adapter methods, ready to integrate in trunk, WDYT?
Why not build-time only? For the tooling, the scr tooling we have in the Felix project is extensible and works with Maven, Ant and bndtools support is there as well. I already see people implementing AdapterProvider but forgetting the annotation on a method or vice versa. And they don't notice their problem until late at runtime and only at the point where the adapter is needed. If we can move all the checking to build time, this is much safer. As the code resides in a bundle and the bundle needs to be build anyway, I don't see a use case for runtime annotation processing. Regards Carsten 2013/7/4 Bertrand Delacretaz bdelacre...@apache.org On Thu, Jul 4, 2013 at 10:28 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Thu, Jul 4, 2013 at 8:56 AM, Carsten Ziegeler cziege...@apache.org wrote: One solution for a build time annotation would be to define a server registration property for a AdapterProvider containing the method names... That's much more complicated to write than just an @Adapter annotation on a method... Ah sorry, reread your message and I overlooked the at build time the value of this property would be generated by using the annotation part - still, I don't want this to be build-time only. -Bertrand -- Carsten Ziegeler cziege...@apache.org
[jira] [Resolved] (SLING-2932) Wasted work in BundleEventListener.assertNoBundleEvents()
[ https://issues.apache.org/jira/browse/SLING-2932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-2932. - Resolution: Fixed Fix Version/s: Installer Core 3.4.8 Assignee: Carsten Ziegeler Thanks for your patch, it's applied Wasted work in BundleEventListener.assertNoBundleEvents() - Key: SLING-2932 URL: https://issues.apache.org/jira/browse/SLING-2932 Project: Sling Issue Type: Bug Components: Installer Environment: any Reporter: Adrian Nistor Assignee: Carsten Ziegeler Labels: patch, performance Fix For: Installer Core 3.4.8 Attachments: patch.diff The problem appears in version 6 and in revision 1495454. I attached a one-line patch that fixes it. In method BundleEventListener.assertNoBundleEvents, the loop over events should break immediately after found is set to true. All the iterations after found is set to true do not perform any useful work, at best they just set found again to true. Method isLive in class ResourceResolverContext has a similar loop (over dynamicProviders), and this loop breaks immediately after result is set to false, just like in the proposed patch. Other methods (e.g., FactoryPreconditions.checkPreconditions, JspUtil.checkAttributes, EclipseJavaCompiler.compile, SecondPassVisitor.appendPageDirective) also have similar loops with similar breaks, just like in the proposed patch. -- 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-2944) Replace administrative login by service-based login
[ https://issues.apache.org/jira/browse/SLING-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-2944: - Attachment: serviceusermapper.tgz SLING-2944.patch Proposed patch against existing bundles (Sling API, Sling JCR API, JCR Base, Jackrabbit Server, JCR Resource Provider, Resource Resovler) and package of the new Service User Mapper bundle (MD5 2e8e5d920e9ce8a175c562d18dc49eed; will be svn cp-ed from http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/deprecate_login_administrative/serviceusermapper). The notable changes are the introduction of the new ResourceResolverFactory.getServiceResourceresolver and SlingRepository.loginService methods and deprecation of the former administrative login methods. In addition the ResourceProviderFactory and SlingRepository services are now registered as service factories to be able to get the calling bundle. This required some refactoring in the AbstractSlingRepository causing extensions to be adapted, too (the registerService method is now final and two methods are added to provide custom registration properties and registration interfaces). Replace administrative login by service-based login --- Key: SLING-2944 URL: https://issues.apache.org/jira/browse/SLING-2944 Project: Sling Issue Type: New Feature Components: API, JCR, ResourceResolver, Service User Mapper Affects Versions: JCR Resource 2.2.8, JCR Jackrabbit Server 2.1.0, JCR Base 2.1.2, JCR API 2.1.0, API 2.4.2, Resource Resolver 1.0.6 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Service User Mapper 1.0.0, JCR Resource 2.3.0, JCR Jackrabbit Server 2.2.0, JCR Base 2.1.4, JCR API 2.2.0, API 2.5.0, Resource Resolver 1.1.0 Attachments: serviceusermapper.tgz, SLING-2944.patch From the start Sling tried to solve the problem of providing services access to the repository and resource tree without having to hard code and configure any passwords. This was done first with the SlingRepository.loginAdministrative and later with the ResourceResolverFactory.getAdministrativeResourceResolver methods. Over time this mechanism proved to be the hammer to hit all nails. Particularly these methods while truly useful have the disadvantage of providing full administrative privileges to services where just some specific kind of privilege would be enough. For example for the JSP compiler it would be enough to be able to read the JSP source scripts and write the Java classes out to the JSP compiler's target location. Other access is not required. Similarly to manage users user management privileges are enough and no access to /content is really required. To solve this problem a new API for Service Authentication has been proposed at https://cwiki.apache.org/confluence/display/SLING/Service+Authentication. The prototype of which is implemented in http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/deprecate_login_administrative. This issue is about merging the prototype code back into trunk and thus fully implementing the feature. -- 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-2931) Wasted work in SlingServletResolver.activate()
[ https://issues.apache.org/jira/browse/SLING-2931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-2931. - Resolution: Fixed Fix Version/s: Servlets Resolver 2.2.6 Assignee: Carsten Ziegeler Thanks for your patch, it's applied Wasted work in SlingServletResolver.activate() -- Key: SLING-2931 URL: https://issues.apache.org/jira/browse/SLING-2931 Project: Sling Issue Type: Bug Components: Servlets Environment: any Reporter: Adrian Nistor Assignee: Carsten Ziegeler Labels: patch, perfomance Fix For: Servlets Resolver 2.2.6 Attachments: patch.diff The problem appears in version 6 and in revision 1495454. I attached a one-line patch that fixes it. In method SlingServletResolver.activate, the loop over executionPaths should break immediately after hasRoot is set to true. All the iterations after hasRoot is set to true do not perform any useful work, at best they just set hasRoot again to true. Method isLive in class ResourceResolverContext has a similar loop (over dynamicProviders), and this loop breaks immediately after result is set to false, just like in the proposed patch. Other methods (e.g., FactoryPreconditions.checkPreconditions, JspUtil.checkAttributes, EclipseJavaCompiler.compile, SecondPassVisitor.appendPageDirective) also have similar loops with similar breaks, just like in the proposed patch. -- 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-2930) Wasted work in ClusterViewServiceImpl.getClusterView()
[ https://issues.apache.org/jira/browse/SLING-2930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-2930. - Resolution: Fixed Fix Version/s: Discovery Impl 1.0.0 Assignee: Carsten Ziegeler Thanks for your patch, it's applied Wasted work in ClusterViewServiceImpl.getClusterView() -- Key: SLING-2930 URL: https://issues.apache.org/jira/browse/SLING-2930 Project: Sling Issue Type: Bug Components: Extensions Environment: any Reporter: Adrian Nistor Assignee: Carsten Ziegeler Labels: patch, performance Fix For: Discovery Impl 1.0.0 Attachments: patch.diff The problem appears in revision 1495454. I attached a one-line patch that fixes it. In method ClusterViewServiceImpl.getClusterView, the loop over clusterViewImpl.getInstances() should break immediately after foundLocal is set to true. All the iterations after foundLocal is set to true do not perform any useful work, at best they just set foundLocal again to true. Method isLive in class ResourceResolverContext has a similar loop (over dynamicProviders), and this loop breaks immediately after result is set to false, just like in the proposed patch. Other methods (e.g., FactoryPreconditions.checkPreconditions, JspUtil.checkAttributes, EclipseJavaCompiler.compile, SecondPassVisitor.appendPageDirective) also have similar loops with similar breaks, just like in the proposed patch. -- 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
Jenkins build is unstable: sling-trunk-1.6 #1713
See https://builds.apache.org/job/sling-trunk-1.6/1713/changes
Service Authentication
Hi all It has been noted that our SlingRepository.loginAdministrative and ResourceResolverFactory.getAdministrativeResourceResolver solve a problem but are suboptimal in that they provide administrative privileges. To solve this dilemma I have created the Service Authentication concept [1] and implemented a prototype [2]. I am now ready to reintegrate this prototype into the main code base tracked by SLING-2944 [3]. The proposed changes to the code base are attached as a patch (of existing code) and a package of the new Service User Mapper bundle. I would like you to review that code before I go ahead integrating it into the code base sometime next week. Thank you very much. Regards Felix [1] https://cwiki.apache.org/confluence/display/SLING/Service+Authentication [2] http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/deprecate_login_administrative [3] https://issues.apache.org/jira/browse/SLING-2944
[jira] [Resolved] (SLING-2928) Wasted work in LaunchpadConfigInstaller.isActive()
[ https://issues.apache.org/jira/browse/SLING-2928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-2928. - Resolution: Fixed Fix Version/s: Launchpad Installer 1.2.2 Assignee: Carsten Ziegeler Thanks for your patch, it's applied Wasted work in LaunchpadConfigInstaller.isActive() -- Key: SLING-2928 URL: https://issues.apache.org/jira/browse/SLING-2928 Project: Sling Issue Type: Bug Components: Launchpad Environment: any Reporter: Adrian Nistor Assignee: Carsten Ziegeler Labels: patch, perfomance Fix For: Launchpad Installer 1.2.2 Attachments: patch.diff The problem appears in revision 1495454. I attached a one-line patch that fixes it. In method LaunchpadConfigInstaller.isActive, the loop over runModes should break immediately after active is set to false. All the iterations after active is set to false do not perform any useful work, at best they just set active again to false. Method isLive in class ResourceResolverContext has a similar loop (over dynamicProviders), and this loop breaks immediately after result is set to false, just like in the proposed patch. Other methods (e.g., FactoryPreconditions.checkPreconditions, JspUtil.checkAttributes, EclipseJavaCompiler.compile, SecondPassVisitor.appendPageDirective) also have similar loops with similar breaks, just like in the proposed patch. -- 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-2944) Replace administrative login by service-based login
[ https://issues.apache.org/jira/browse/SLING-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13699874#comment-13699874 ] Felix Meschberger commented on SLING-2944: -- Discussion on dev@sling: http://markmail.org/message/2ucwgneqdsiffnbw Replace administrative login by service-based login --- Key: SLING-2944 URL: https://issues.apache.org/jira/browse/SLING-2944 Project: Sling Issue Type: New Feature Components: API, JCR, ResourceResolver, Service User Mapper Affects Versions: JCR Resource 2.2.8, JCR Jackrabbit Server 2.1.0, JCR Base 2.1.2, JCR API 2.1.0, API 2.4.2, Resource Resolver 1.0.6 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Service User Mapper 1.0.0, JCR Resource 2.3.0, JCR Jackrabbit Server 2.2.0, JCR Base 2.1.4, JCR API 2.2.0, API 2.5.0, Resource Resolver 1.1.0 Attachments: serviceusermapper.tgz, SLING-2944.patch From the start Sling tried to solve the problem of providing services access to the repository and resource tree without having to hard code and configure any passwords. This was done first with the SlingRepository.loginAdministrative and later with the ResourceResolverFactory.getAdministrativeResourceResolver methods. Over time this mechanism proved to be the hammer to hit all nails. Particularly these methods while truly useful have the disadvantage of providing full administrative privileges to services where just some specific kind of privilege would be enough. For example for the JSP compiler it would be enough to be able to read the JSP source scripts and write the Java classes out to the JSP compiler's target location. Other access is not required. Similarly to manage users user management privileges are enough and no access to /content is really required. To solve this problem a new API for Service Authentication has been proposed at https://cwiki.apache.org/confluence/display/SLING/Service+Authentication. The prototype of which is implemented in http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/deprecate_login_administrative. This issue is about merging the prototype code back into trunk and thus fully implementing the feature. -- 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] [Comment Edited] (SLING-2944) Replace administrative login by service-based login
[ https://issues.apache.org/jira/browse/SLING-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13699874#comment-13699874 ] Felix Meschberger edited comment on SLING-2944 at 7/4/13 9:03 AM: -- Discussion on the dev list: http://markmail.org/message/2ucwgneqdsiffnbw was (Author: fmeschbe): Discussion on dev@sling: http://markmail.org/message/2ucwgneqdsiffnbw Replace administrative login by service-based login --- Key: SLING-2944 URL: https://issues.apache.org/jira/browse/SLING-2944 Project: Sling Issue Type: New Feature Components: API, JCR, ResourceResolver, Service User Mapper Affects Versions: JCR Resource 2.2.8, JCR Jackrabbit Server 2.1.0, JCR Base 2.1.2, JCR API 2.1.0, API 2.4.2, Resource Resolver 1.0.6 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Service User Mapper 1.0.0, JCR Resource 2.3.0, JCR Jackrabbit Server 2.2.0, JCR Base 2.1.4, JCR API 2.2.0, API 2.5.0, Resource Resolver 1.1.0 Attachments: serviceusermapper.tgz, SLING-2944.patch From the start Sling tried to solve the problem of providing services access to the repository and resource tree without having to hard code and configure any passwords. This was done first with the SlingRepository.loginAdministrative and later with the ResourceResolverFactory.getAdministrativeResourceResolver methods. Over time this mechanism proved to be the hammer to hit all nails. Particularly these methods while truly useful have the disadvantage of providing full administrative privileges to services where just some specific kind of privilege would be enough. For example for the JSP compiler it would be enough to be able to read the JSP source scripts and write the Java classes out to the JSP compiler's target location. Other access is not required. Similarly to manage users user management privileges are enough and no access to /content is really required. To solve this problem a new API for Service Authentication has been proposed at https://cwiki.apache.org/confluence/display/SLING/Service+Authentication. The prototype of which is implemented in http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/deprecate_login_administrative. This issue is about merging the prototype code back into trunk and thus fully implementing the feature. -- 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-920) Jenkins continuous integration setup
[ https://issues.apache.org/jira/browse/SLING-920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13699876#comment-13699876 ] Robert Munteanu commented on SLING-920: --- Updated all sling jobs to be restricted on the ubuntu label. This currently expands to all ubuntu slaves, so we should have enough processing power. I did this because builds on solaris slaves fail, with the typical root cause being Caused by: java.io.IOException: error=12, Not enough space at java.lang.UNIXProcess.forkAndExec(Native Method) at java.lang.UNIXProcess.init(UNIXProcess.java:53) at java.lang.ProcessImpl.start(ProcessImpl.java:65) at java.lang.ProcessBuilder.start(ProcessBuilder.java:453) ... 41 more Jenkins continuous integration setup Key: SLING-920 URL: https://issues.apache.org/jira/browse/SLING-920 Project: Sling Issue Type: Task Components: Testing Reporter: Bertrand Delacretaz Use this issue to record changes to the Hudson continuous environment setup at http://hudson.zones.apache.org/hudson/view/Sling/ -- 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: Sling Posthandling - thougts about the current behavior
...what about using POST.jsp for validations, implementing custom behavior etc. in POST.jsp * add / remove / modify / handle post parameters * call the default POST servlet to do the actually persistence * handle any errors --- The reason why it doesn't work at the moment is that: - post parameters are not mutable - it is hard to call the default implementation (perhaps I just don't know how) - exceptions coming from the POST servlet may not be detailed enough in order to provide error handling on granularity needed I think approach could be very useful for intercepting other requests as well,without need to write custom filters. Ondrej On 26 Jun 2013, at 12:35, Dominik Süß dominik.su...@gmail.com wrote: Hi everyone, within the last weeks I spent some time on a project that is heavily relying on data being submitted by users of the system and setting up complex structures, users, groups and ACLs based on the operations performed by a user. I reallized that a lot of those things could be done by utilizing the SlingPostServlet and extending it by custom Postprocessors and custom operations. This worked out well but I realized some things that I'm not so happy with and would like to start off a discussion how the handling of Posts, and therefore the interactive part of Sling could be improved. Here the points that I think are discussabble: a) (non-Brainer) Postoperations and Postprocessors are rarely covered by documentation (Postprocessors are marked as TBD) this gives the impression of not being ready for productive usage so the gap should be closed b) Postoperations and Postprocessors are always defined and called global so it is up to the developer to check and skip processing (Blacklisting approach) which is errorprone if this manual check is not restrictive enough (can lead to subtle regressions in completely different areas of the app) - I'd propose to have a declarative approach that is a whitelistapproach based on path and propably even by resourceType (here comes the clash between posted resourceType and potentially already existing resourceType c) Sometimes data submitted should just be used as parameters for postprocessors or operations and not persisted. Using the dot-slash prefixing does give such options, but since the ./ notation acts as kind of a magic trigger of behaviour I'd prefer to have a way to annotate such fields (like name@ignore or @noPersistance) All in all the web is moving in a direction where almost no page is delivered with options to interact with the the webpage - so Sling should try to give developers the tools to do this wireing without having the dev to write boilerplatecode for those checks over and over again and enabling them to implement complete interactive userstories up to a certain point of complexity in a standardized way. WDYT? Best regards Dominik
Jenkins build became unstable: sling-trunk-1.6 » Apache Sling Sample Integration Tests #1714
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.testing.samples.integrationtests/1714/
Jenkins build is still unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing WAR version #1714
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing-war/1714/
Jenkins build is still unstable: sling-trunk-1.6 » Apache Sling Resource-Based Discovery Service #1714
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.discovery.impl/changes
Jenkins build is still unstable: sling-trunk-1.6 #1714
See https://builds.apache.org/job/sling-trunk-1.6/changes
Re: Service Authentication
Hi Felix,
... have created the Service Authentication concept [1]..
I like it - here are some comments on the proposed APIs.
1) getServiceResourceResolver
In ResourceResolver getServiceResourceResolver(MapString, Object
authenticationInfo), authenticationInfo MUST contain some attributes,
wouldn't it be better to use a more specific argument than MapString,
Object ?
Maybe
getServiceResourceResolver(ServicerUserURI uri, Bundle
serviceBundle, String optionalServiceInfo)
2) ServiceUserMapper
Like Angela I think the naming is a bit confusing, I would suggest having
ServicerUserURI - identifies a service, like service:MailSender:server
userId - a User ID as used by the Sling security services
You could then have, IIUC
interface ServiceUserMapper {
ServicerUserURI getServiceURI(Bundle b, String serviceName)
String getServiceUserID(ServicerUserURI URI, Bundle serviceBundle)
}
The main idea is to clearly define what's a service name
(mail.sender), service URI (service:someBundle:mail.sender) and
User ID (mailsender).
-Bertrand
[1] https://cwiki.apache.org/confluence/display/SLING/Service+Authentication
Jenkins build is still unstable: sling-trunk-1.7 » Apache Sling Resource-Based Discovery Service #83
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.discovery.impl/83/
Build failed in Jenkins: sling-trunk-1.7 » Apache Sling Event Support #83
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.event/83/ -- [...truncated 6711 lines...] 04.07.2013 09:51:35.082 *INFO* [FelixStartLevel] org.apache.jackrabbit.jackrabbit-jcr-rmi BundleEvent STOPPED 04.07.2013 09:51:35.082 *INFO* [FelixStartLevel] org.apache.jackrabbit.jackrabbit-spi-commons BundleEvent STOPPING 04.07.2013 09:51:35.082 *INFO* [FelixStartLevel] org.apache.jackrabbit.jackrabbit-spi-commons BundleEvent STOPPED 04.07.2013 09:51:35.082 *INFO* [FelixStartLevel] org.apache.jackrabbit.jackrabbit-spi BundleEvent STOPPING 04.07.2013 09:51:35.082 *INFO* [FelixStartLevel] org.apache.jackrabbit.jackrabbit-spi BundleEvent STOPPED 04.07.2013 09:51:35.082 *INFO* [FelixStartLevel] org.apache.jackrabbit.jackrabbit-jcr-commons BundleEvent STOPPING 04.07.2013 09:51:35.082 *INFO* [FelixStartLevel] org.apache.jackrabbit.jackrabbit-jcr-commons BundleEvent STOPPED 04.07.2013 09:51:35.082 *INFO* [FelixStartLevel] org.apache.jackrabbit.jackrabbit-api BundleEvent STOPPING 04.07.2013 09:51:35.083 *INFO* [FelixStartLevel] org.apache.jackrabbit.jackrabbit-api BundleEvent STOPPED 04.07.2013 09:51:35.083 *INFO* [FelixStartLevel] org.apache.sling.jcr.base BundleEvent STOPPING 04.07.2013 09:51:35.083 *INFO* [FelixStartLevel] org.apache.sling.jcr.base BundleEvent STOPPED 04.07.2013 09:51:35.083 *INFO* [FelixStartLevel] org.apache.sling.jcr.api BundleEvent STOPPING 04.07.2013 09:51:35.083 *INFO* [FelixStartLevel] org.apache.sling.jcr.api BundleEvent STOPPED 04.07.2013 09:51:35.083 *INFO* [FelixStartLevel] org.apache.sling.jcr.jcr-wrapper BundleEvent STOPPING 04.07.2013 09:51:35.084 *INFO* [FelixStartLevel] org.apache.sling.jcr.jcr-wrapper BundleEvent STOPPED 04.07.2013 09:51:35.084 *INFO* [FelixStartLevel] org.apache.sling.engine Service [org.apache.sling.engine.impl.SlingSettingsServiceImpl,106] ServiceEvent UNREGISTERING 04.07.2013 09:51:35.085 *INFO* [FelixStartLevel] org.apache.sling.engine Service [org.apache.sling.engine.impl.debug.RequestProgressTrackerLogFilter,46] ServiceEvent UNREGISTERING 04.07.2013 09:51:35.085 *INFO* [FelixStartLevel] org.apache.sling.engine Service [47] ServiceEvent UNREGISTERING 04.07.2013 09:51:35.086 *INFO* [FelixStartLevel] org.apache.sling.engine Service [49] ServiceEvent UNREGISTERING 04.07.2013 09:51:35.086 *INFO* [FelixStartLevel] org.apache.sling.engine Service [org.apache.sling.engine.impl.log.RequestLoggerFilter,50] ServiceEvent UNREGISTERING 04.07.2013 09:51:35.086 *INFO* [FelixStartLevel] org.apache.sling.engine Service [48] ServiceEvent UNREGISTERING 04.07.2013 09:51:35.087 *INFO* [FelixStartLevel] org.apache.sling.engine Service [Sling Request Processor,58] ServiceEvent UNREGISTERING 04.07.2013 09:51:35.087 *INFO* [FelixStartLevel] org.apache.sling.engine Service [57] ServiceEvent UNREGISTERING 04.07.2013 09:51:35.088 *INFO* [FelixStartLevel] org.apache.sling.engine Service [org.apache.sling.engine.impl.request.RequestHistoryConsolePlugin$Plugin,56] ServiceEvent UNREGISTERING 04.07.2013 09:51:35.088 *INFO* [FelixStartLevel] org.apache.felix.inventory Service [55] ServiceEvent UNREGISTERING 04.07.2013 09:51:35.088 *INFO* [FelixStartLevel] org.apache.felix.inventory Service [54] ServiceEvent UNREGISTERING 04.07.2013 09:51:35.088 *INFO* [FelixStartLevel] org.apache.sling.engine Service [Apache Sling Servlet Filter Configuration Printer,53] ServiceEvent UNREGISTERING 04.07.2013 09:51:35.089 *INFO* [FelixStartLevel] org.apache.sling.engine Service [org.apache.sling.engine.impl.helper.SlingServletContext,52] ServiceEvent UNREGISTERING 04.07.2013 09:51:35.089 *INFO* [FelixStartLevel] org.apache.sling.engine.impl.SlingMainServlet ApacheSling/2.2 (jetty/6.1.x, Java HotSpot(TM) Server VM 1.7.0_15, SunOS 5.10 x86) shut down 04.07.2013 09:51:35.090 *INFO* [FelixStartLevel] org.apache.sling.commons.mime Service [51] ServiceEvent UNREGISTERING 04.07.2013 09:51:35.090 *INFO* [FelixStartLevel] org.apache.sling.engine BundleEvent STOPPING 04.07.2013 09:51:35.090 *INFO* [FelixStartLevel] org.apache.sling.engine BundleEvent STOPPED 04.07.2013 09:51:35.090 *INFO* [FelixStartLevel] org.apache.sling.jcr.contentloader Service [org.apache.sling.jcr.contentloader.internal.DefaultContentImporter,45] ServiceEvent UNREGISTERING 04.07.2013 09:51:35.090 *INFO* [FelixStartLevel] org.apache.sling.jcr.contentloader BundleEvent STOPPING 04.07.2013 09:51:35.091 *INFO* [FelixStartLevel] org.apache.sling.jcr.contentloader BundleEvent STOPPED 04.07.2013 09:51:35.091 *INFO* [FelixStartLevel] org.apache.sling.jcr.classloader BundleEvent STOPPING 04.07.2013 09:51:35.091 *INFO* [FelixStartLevel] org.apache.sling.jcr.classloader BundleEvent STOPPED 04.07.2013 09:51:35.091 *INFO* [FelixStartLevel] org.apache.sling.jcr.resource Service [org.apache.sling.jcr.resource.internal.scripting.JcrObjectsBindingsValuesProvider,43] ServiceEvent UNREGISTERING 04.07.2013 09:51:35.092 *INFO* [FelixStartLevel]
Build failed in Jenkins: sling-trunk-1.7 #83
See https://builds.apache.org/job/sling-trunk-1.7/83/changes Changes: [fmeschbe] Clarify the exception to be unused since session pooling has been removed and TooManySessionsException is not thrown any longer. -- [...truncated 17270 lines...] [INFO] Apache Sling API .. SUCCESS [42.470s] [INFO] Apache Sling Resource Resolver SUCCESS [1:33.363s] [INFO] Apache Sling System Bundle Extension: Java Transaction API SUCCESS [49.612s] [INFO] Apache Sling System Bundle Extension: XML APIs SUCCESS [41.140s] [INFO] Apache Sling System Bundle Extension: Activation API SUCCESS [44.789s] [INFO] Apache Sling System Bundle Extension: WS APIs . SUCCESS [46.172s] [INFO] Apache Sling Dynamic Class Loader Support . SUCCESS [3:16.485s] [INFO] Apache Sling JSON Library . SUCCESS [1:45.547s] [INFO] Apache Sling SLF4J Implementation . SUCCESS [1:40.729s] [INFO] Apache Sling OSGi LogService Implementation ... SUCCESS [1:09.997s] [INFO] Apache Sling MIME type mapping support SUCCESS [1:17.057s] [INFO] Apache Sling Commons OSGi support . SUCCESS [1:04.074s] [INFO] Apache Sling Scheduler Support SUCCESS [51.177s] [INFO] Apache Sling Testing Utilities SUCCESS [1:48.568s] [INFO] Apache Sling Thread Support ... SUCCESS [37.368s] [INFO] Apache Sling Authentication Service ... SUCCESS [57.066s] [INFO] Apache Sling OpenID Authentication SUCCESS [47.473s] [INFO] Apache Sling Form Based Authentication Handler SUCCESS [58.528s] [INFO] Apache Sling Authentication Selector .. SUCCESS [34.329s] [INFO] Apache Sling Engine Implementation SUCCESS [1:02.191s] [INFO] Apache Sling Repository API Bundle SUCCESS [35.018s] [INFO] Apache Sling JCR Base Bundle .. SUCCESS [38.819s] [INFO] Apache Sling JCR ClassLoader .. SUCCESS [32.592s] [INFO] Apache Sling Initial Content Loader ... SUCCESS [47.280s] [INFO] Apache Sling Jackrabbit Embedded Repository ... SUCCESS [44.867s] [INFO] Apache Sling Jackrabbit UserManager Support ... SUCCESS [39.330s] [INFO] Apache Sling Jackrabbit JSR-283 Access Control Manager Support SUCCESS [44.205s] [INFO] Apache Sling Wrapper Bundle for the JCR API ... SUCCESS [30.021s] [INFO] Apache Sling Object Content Mapping ... SUCCESS [40.153s] [INFO] Apache Sling JCR Resource Resolver SUCCESS [1:35.221s] [INFO] Apache Sling JCR Repository Registration .. SUCCESS [56.115s] [INFO] Apache Sling Simple WebDAV Access to repositories . SUCCESS [1:23.064s] [INFO] Apache Sling DavEx Access to repositories . SUCCESS [59.064s] [INFO] Apache Sling JCR WebConsole Bundle SUCCESS [36.390s] [INFO] Apache Sling Servlet Resolver . SUCCESS [48.189s] [INFO] Apache Sling Default GET Servlets . SUCCESS [38.235s] [INFO] Apache Sling Default POST Servlets SUCCESS [50.759s] [INFO] Apache Sling Compat Servlets .. SUCCESS [35.671s] [INFO] Apache Sling Scripting Implementation API . SUCCESS [38.972s] [INFO] Apache Sling Scripting Core implementation SUCCESS [42.075s] [INFO] Apache Sling Scripting JavaScript Support . SUCCESS [54.911s] [INFO] Apache Sling Scripting JSP Support SUCCESS [37.471s] [INFO] Apache Sling JSP Tag Library .. SUCCESS [52.488s] [INFO] Apache Sling JSP Standard Tag Library . SUCCESS [38.399s] [INFO] Apache Sling Adapter Manager Implementation ... SUCCESS [1:31.438s] [INFO] Apache Sling Bundle Resource Provider . SUCCESS [48.447s] [INFO] Apache Sling Discovery API SUCCESS [43.825s] [INFO] Apache Sling Resource-Based Discovery Service . SUCCESS [13:59.156s] [INFO] Apache Sling Discovery Support Bundle . SUCCESS [34.809s] [INFO] Apache Sling Discovery Standalone Implementation .. SUCCESS [34.774s] [INFO] Apache Sling Event Support FAILURE [8:17.119s] [INFO] Apache Sling Filesystem Resource Provider . SKIPPED [INFO] Apache Sling javax.activation bundle .. SKIPPED [INFO] Apache Sling Settings . SKIPPED [INFO] Apache Sling Thread Dumper SKIPPED [INFO] Apache Sling Web Console Branding . SKIPPED [INFO] Apache Sling Web Console Security Provider SKIPPED [INFO] Apache Sling Groovy Extensions SKIPPED [INFO] Apache Sling Explorer . SKIPPED [INFO] Apache Sling Test Tools ... SKIPPED [INFO] Apache Sling JUnit Core ... SKIPPED [INFO] Apache Sling JUnit Scriptable Tests Provider ..
Jenkins build is back to stable : sling-trunk-1.7 » Apache Sling Sample Integration Tests #84
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.testing.samples.integrationtests/84/
Jenkins build is back to stable : sling-trunk-1.7 » Apache Sling Launchpad Testing #84
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.launchpad.testing/84/
Re: SLING-2803 validation module, hierarchical structures and extensible types
To sum things up: a. there's also a need for hierarchical structures validation b. we shouldn't rely on the ValueMap to provide the properties of child resources - there's only one ValueMap implementation that provides this, and only for read operations The proposed API currently: a. does not assume hierarchical structures - they could be defined in the ValidationModel (by extending the Field concept to also contain children) b. validates only ValueMaps and, given the recent discussions, should not assume that the ValueMaps provide the properties of a tree-like structure c. can be used to validate requests and resources as long as we don't expect tree-like structures However the ValueMap accepted by the validation service could contain path-like keys if it was obtained by adapting a request to it. Depending on what we need in Sling I see two solutions: 1. extend the current API and implementation to be able to validate tree-like structures - better suited for validating requests rather than resources, given that most ValueMap implementations don't provide us with the children's properties 2. erase and start over with a new validation framework at the ResourceResolver level that would handle validation right before the commit phase - this implies that we actually validate changed resources (credits to Carsten for this idea) Devs, which solution sounds better to you and why? Thanks, Radu On Thu, Jul 4, 2013 at 8:54 AM, Carsten Ziegeler cziege...@apache.orgwrote: As I wrote, a hierarchy is only supported by a single implementation for reading - not for writing, so it doesn't make sense to me to support this in validation as this can't be written through the resource api in the same way. The post servlet is splitting paths and creates a resource for each part of the path except the last part which is the property on the last resource. Carsten 2013/7/4 Radu Cotescu r...@cotescu.com Hi, Found what Alex was talking about in the org.apache.sling.jcr.resource.JcrPropertyMap class. I'm sorry for my previous answer. The implementation wasn't that obvious at first. What do you think the best approach would be given the hierarchical structures problem and the currently proposed validation API? The ValidationModel could describe the expected tree structure if we change the Fields to allow them to have children (in which case, judging from a JCR perspective, these Fields would actually translate to nodes instead of properties). Thanks, Radu Radu Cotescu | Software Engineer, Tech Blogger, Author Web:radu.cotescu.comEmail:radu@cotescu.comCell:+40 744 406 353 On Wed, Jul 3, 2013 at 10:18 PM, Carsten Ziegeler cziege...@apache.org wrote: 2013/7/3 Alexander Klimetschek aklim...@adobe.com On 03.07.2013, at 17:34, Radu Cotescu r...@apache.org wrote: 1. Currently there's no support for hierarchical structures. ValueMap doesn't provide this kind of support. Yes, the jcr property value map implementation supports relative paths. This should definitely be supported, as you very quickly have a nested structure with JCR and the sling post servlet. So field names supporting relative paths should all there is required - this is in line with the sling post servlet. It was a mistake to add support for paths to the jcr value map - note that the jcr implementation of the modifiable value map does not support setting a property with a path - same with the whole create and update stuff in Sling's resource api. Other resource implementations don't allow paths for properties. If I could turn back the time I wouldn't add path support to the value map. It creates several problems implementation wise and blures the difference between a resource and its properties. For all future things we should have clean approaches. There might be resource types which require child resource (types) to exist - and we need a way to validate this. I think the correct way would be to have a validator which checks for such a child resource of a type and have separate validator sets for both, the parent and the child resource. Carsten 2. As long as the Field from the ValidationModel specifies a certain Validator to be used for validating the field's value I don't see why we couldn't have a Validator that checks the data in an external system. The single current constraint of a Validator is that it has to provide a validate method, returning a boolean. The implementation can be done however the developer sees fit. If the Validator is a service/component, then it can easily reference other services. Cheers, Alex -- Carsten Ziegeler cziege...@apache.org -- Carsten Ziegeler cziege...@apache.org
Jenkins build is unstable: sling-trunk-1.7 #84
See https://builds.apache.org/job/sling-trunk-1.7/84/changes
Build failed in Jenkins: sling-trunk-1.6 #1715
See https://builds.apache.org/job/sling-trunk-1.6/1715/changes Changes: [cziegeler] SLING-2928: Wasted work in LaunchpadConfigInstaller.isActive() . Apply patch from Adrian Nistor -- [...truncated 9871 lines...] [INFO] --- maven-enforcer-plugin:1.0.1:enforce (enforce-java) @ org.apache.sling.discovery.api --- [INFO] [INFO] --- maven-antrun-plugin:1.7:run (set-bundle-required-execution-environment) @ org.apache.sling.discovery.api --- [INFO] Executing tasks main: [INFO] Executed tasks Jul 4, 2013 10:10:57 AM hudson.maven.ExecutedMojo init WARNING: Failed to getClass for org.apache.maven.plugin.source.SourceJarMojo [INFO] [INFO] --- maven-source-plugin:2.2.1:jar (attach-sources) @ org.apache.sling.discovery.api --- [INFO] Building jar: https://builds.apache.org/job/sling-trunk-1.6/ws/trunk/bundles/extensions/discovery/api/target/org.apache.sling.discovery.api-1.0.1-SNAPSHOT-sources.jar [INFO] [INFO] --- maven-site-plugin:3.2:attach-descriptor (attach-descriptor) @ org.apache.sling.discovery.api --- [INFO] Checking legal files in: org.apache.sling.discovery.api-1.0.1-SNAPSHOT.jar [INFO] [INFO] Checking legal files in: org.apache.sling.discovery.api-1.0.1-SNAPSHOT-sources.jar [INFO] --- ianal-maven-plugin:1.0-alpha-1:verify-legal-files (default) @ org.apache.sling.discovery.api --- [INFO] Installing https://builds.apache.org/job/sling-trunk-1.6/ws/trunk/bundles/extensions/discovery/api/target/org.apache.sling.discovery.api-1.0.1-SNAPSHOT.jar to /home/jenkins/jenkins-slave/maven-repositories/1/org/apache/sling/org.apache.sling.discovery.api/1.0.1-SNAPSHOT/org.apache.sling.discovery.api-1.0.1-SNAPSHOT.jar [INFO] [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ org.apache.sling.discovery.api --- [INFO] Installing https://builds.apache.org/job/sling-trunk-1.6/ws/trunk/bundles/extensions/discovery/api/pom.xml to /home/jenkins/jenkins-slave/maven-repositories/1/org/apache/sling/org.apache.sling.discovery.api/1.0.1-SNAPSHOT/org.apache.sling.discovery.api-1.0.1-SNAPSHOT.pom [INFO] Installing https://builds.apache.org/job/sling-trunk-1.6/ws/trunk/bundles/extensions/discovery/api/target/org.apache.sling.discovery.api-1.0.1-SNAPSHOT-sources.jar to /home/jenkins/jenkins-slave/maven-repositories/1/org/apache/sling/org.apache.sling.discovery.api/1.0.1-SNAPSHOT/org.apache.sling.discovery.api-1.0.1-SNAPSHOT-sources.jar [INFO] Local OBR update disabled (enable with -DobrRepository) [INFO] [INFO] --- maven-bundle-plugin:2.3.7:install (default-install) @ org.apache.sling.discovery.api --- [INFO] [INFO] [INFO] Building Apache Sling Resource-Based Discovery Service 0.1.0-SNAPSHOT [INFO] [INFO] Deleting https://builds.apache.org/job/sling-trunk-1.6/ws/trunk/bundles/extensions/discovery/impl/target [INFO] [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ org.apache.sling.discovery.impl --- [INFO] [INFO] --- maven-enforcer-plugin:1.0.1:enforce (enforce-java) @ org.apache.sling.discovery.impl --- [INFO] [INFO] --- maven-antrun-plugin:1.7:run (set-bundle-required-execution-environment) @ org.apache.sling.discovery.impl --- [INFO] Executing tasks main: [INFO] Executed tasks [INFO] [INFO] --- maven-remote-resources-plugin:1.4:process (default) @ org.apache.sling.discovery.impl --- [INFO] [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ org.apache.sling.discovery.impl --- [INFO] Copying 1 resource [INFO] Copying 3 resources [INFO] [INFO] --- maven-antrun-plugin:1.7:run (check-memory-task) @ org.apache.sling.discovery.impl --- [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-compiler-plugin:2.5.1:compile (default-compile) @ org.apache.sling.discovery.impl --- [INFO] Compiling 29 source files to https://builds.apache.org/job/sling-trunk-1.6/ws/trunk/bundles/extensions/discovery/impl/target/classes [INFO] [INFO] --- maven-scr-plugin:1.12.0:scr (generate-scr-scrdescriptor) @ org.apache.sling.discovery.impl --- [WARNING] https://builds.apache.org/job/sling-trunk-1.6/ws/trunk/bundles/extensions/discovery/impl/src/main/java/org/apache/sling/discovery/impl/topology/connector/TopologyConnectorServlet.java [0:0]: Property sling.servlet.paths in class
Re: SLING-2803 validation module, hierarchical structures and extensible types
While rethinking the hierarchy problem and other things I came to the conclusion, that the best point for validation is when ResourceResolver#commit is called. At this point all changes are known. Validation should be based on resource types and validate a resource - therefore the validation service does not only need to validate new/updated values but also existing values. Especially as soon as you have dependencies between properties. Basing the validation on the transient space elegantly solves this problem. Adding this - maybe as an optional service - into the resource resolver makes it also impossible to bypass validation - the validation is always done regardless whether the changes are done through the post servlet, any other servlet, or some server side code running in the background. For this to work, we only have to build up a list of added and changed resources and then validate these resources, each resource can be adapted to a value map to validate it's properties. For the hierarchy we can add validators which check for the existence of a child node with a specific resource type (or whatever is required). I think this is the most flexbile way and does validation at the right place. Carsten 2013/7/4 Radu Cotescu r...@apache.org To sum things up: a. there's also a need for hierarchical structures validation b. we shouldn't rely on the ValueMap to provide the properties of child resources - there's only one ValueMap implementation that provides this, and only for read operations The proposed API currently: a. does not assume hierarchical structures - they could be defined in the ValidationModel (by extending the Field concept to also contain children) b. validates only ValueMaps and, given the recent discussions, should not assume that the ValueMaps provide the properties of a tree-like structure c. can be used to validate requests and resources as long as we don't expect tree-like structures However the ValueMap accepted by the validation service could contain path-like keys if it was obtained by adapting a request to it. Depending on what we need in Sling I see two solutions: 1. extend the current API and implementation to be able to validate tree-like structures - better suited for validating requests rather than resources, given that most ValueMap implementations don't provide us with the children's properties 2. erase and start over with a new validation framework at the ResourceResolver level that would handle validation right before the commit phase - this implies that we actually validate changed resources (credits to Carsten for this idea) Devs, which solution sounds better to you and why? Thanks, Radu On Thu, Jul 4, 2013 at 8:54 AM, Carsten Ziegeler cziege...@apache.org wrote: As I wrote, a hierarchy is only supported by a single implementation for reading - not for writing, so it doesn't make sense to me to support this in validation as this can't be written through the resource api in the same way. The post servlet is splitting paths and creates a resource for each part of the path except the last part which is the property on the last resource. Carsten 2013/7/4 Radu Cotescu r...@cotescu.com Hi, Found what Alex was talking about in the org.apache.sling.jcr.resource.JcrPropertyMap class. I'm sorry for my previous answer. The implementation wasn't that obvious at first. What do you think the best approach would be given the hierarchical structures problem and the currently proposed validation API? The ValidationModel could describe the expected tree structure if we change the Fields to allow them to have children (in which case, judging from a JCR perspective, these Fields would actually translate to nodes instead of properties). Thanks, Radu Radu Cotescu | Software Engineer, Tech Blogger, Author Web:radu.cotescu.comEmail:radu@cotescu.comCell:+40 744 406 353 On Wed, Jul 3, 2013 at 10:18 PM, Carsten Ziegeler cziege...@apache.org wrote: 2013/7/3 Alexander Klimetschek aklim...@adobe.com On 03.07.2013, at 17:34, Radu Cotescu r...@apache.org wrote: 1. Currently there's no support for hierarchical structures. ValueMap doesn't provide this kind of support. Yes, the jcr property value map implementation supports relative paths. This should definitely be supported, as you very quickly have a nested structure with JCR and the sling post servlet. So field names supporting relative paths should all there is required - this is in line with the sling post servlet. It was a mistake to add support for paths to the jcr value map - note that the jcr implementation of the modifiable value map does not support setting a property with a path - same with the whole create and update stuff in Sling's resource api. Other resource implementations don't allow paths
Re: Service Authentication
Hi
Am 04.07.2013 um 12:01 schrieb Bertrand Delacretaz:
Hi Felix,
... have created the Service Authentication concept [1]..
I like it - here are some comments on the proposed APIs.
1) getServiceResourceResolver
In ResourceResolver getServiceResourceResolver(MapString, Object
authenticationInfo), authenticationInfo MUST contain some attributes,
wouldn't it be better to use a more specific argument than MapString,
Object ?
Maybe
getServiceResourceResolver(ServicerUserURI uri, Bundle
serviceBundle, String optionalServiceInfo)
I thougt about having a signature with just the serviceInfo. But the map may
contain more fields, which are not available in the single signature.
Plus: the only required property is the service Info which is optional. The
bundle is available implicitly and the service base is derived from the bundle
which is available as the bundle using the ResourceResolverFactory. There is no
such thing as a freely definable ServiceUserURI: The
ServiceUserMapper.getServiceName just exists for informational purposes or to
configure the ServiceUserMapper.
The service name is either the value of the Sling-Service bundle header or the
bundle symbolic name.
2) ServiceUserMapper
Like Angela I think the naming is a bit confusing, I would suggest having
ServicerUserURI - identifies a service, like service:MailSender:server
userId - a User ID as used by the Sling security services
I don't really see the need to define this as a URI. After all calling this a
resource is kind of esoteric ;-)
How about calling this the service ID comprised of the bundle-derived service
name and the optional service Info.
Hence how about: ServiceUserMapper.getServiceID ?
Regards
Felix
You could then have, IIUC
interface ServiceUserMapper {
ServicerUserURI getServiceURI(Bundle b, String serviceName)
String getServiceUserID(ServicerUserURI URI, Bundle serviceBundle)
}
The main idea is to clearly define what's a service name
(mail.sender), service URI (service:someBundle:mail.sender) and
User ID (mailsender).
-Bertrand
[1] https://cwiki.apache.org/confluence/display/SLING/Service+Authentication
Re: @Adapter methods, ready to integrate in trunk, WDYT?
Hi Some comments * The new AdapterProvider interface needs a @since tag (I generally list the API export version and bundle version) * Technically exporting the o.a.s.api.adapter package at 2.2.1 is wrong and may lead to erroneous Import-Package statements for implementors: [2.2,3) instead of [2.2.1,3). I have quickly scanned our Sling-based application: The only bundle having the narrow [2.2,2.3) import version range is the Adpater Manager bundle (which is to be adapted anyways). All other bundles either import [2.x,3) or even 2.x. So I would suggest to export at 2.3. Regards Felix Am 02.07.2013 um 16:09 schrieb Bertrand Delacretaz: Hi, As this touches the sling.api bundle, I have attached a patch [1] for review ,see SLING-2938 for more details. All the TODOs in that issue have been implemented. I plan to commit this later this week, unless someone objects. -Bertrand [1] https://issues.apache.org/jira/secure/attachment/12590435/SLING-2938-api.patch
Re: @Adapter methods, ready to integrate in trunk, WDYT?
Hi Am 04.07.2013 um 10:28 schrieb Bertrand Delacretaz: Hi Carsten, On Thu, Jul 4, 2013 at 8:56 AM, Carsten Ziegeler cziege...@apache.org wrote: ...For now I'm against committing this to trunk, as previously mentioned I would prefer having a build time annotation. If this is not possible, then the annotation and the AdapterProvider should be in the same package as there is no use case for using one without the other Yes, I was actually wondering about putting the annotation and AdapterProvider in the org.apache.sling.adapter bundle instead of sling.api. I was proposing it to be in another package. Reconsidering this to be a runtime annotation and thus be kind of some special API it would indeed make sense to have it in the o.a.s.api.adapter package. That's slightly inconsistent with having the AdapterFactory in the sling.api bundle, but we can rightly consider these new interfaces as being adapter extensions, WDYT?. I'd keep the annotation in the Sling API bundle. OTOH I don't like @Adapter being a build-time only annotation - by doing this you either tie people to Maven, or have to provide build-time extensions for all common build tools (Maven, ant command-line etc) which is a lot of work for such a simple feature. If you want to create a build-time tool in addition why not, but I don't want to make this build-time only. If you compare with declarative services, the build-time plugin is very useful but you can also perfectly work without it. Actually, that is not entirely true: The single point of truth in providing the method names would be the service registration property. The annotation would be synthactic sugar for build tools. One solution for a build time annotation would be to define a server registration property for a AdapterProvider containing the method names... That's much more complicated to write than just an @Adapter annotation on a method. Plus that would not only be the method names but the fully signatures to cope with method overloading ! Am 04.07.2013 um 08:56 schrieb Carsten Ziegeler: One solution for a build time annotation would be to define a server registration property for a AdapterProvider containing the method names and at build time the value of this property would be generated by using the annotation. This would be similar to the bind/unbind methods of DS. The problem is with method overloading: In DS there is a defined algorithm to find the named method in case of method overloading. In this case we want to explicitly name a method. So we would have to define the actual method signature in the property, which would be cumbersome when not using the tooling. Regards Felix
Re: @Adapter methods, ready to integrate in trunk, WDYT?
2013/7/4 Felix Meschberger fmesc...@adobe.com The problem is with method overloading: In DS there is a defined algorithm to find the named method in case of method overloading. In this case we want to explicitly name a method. So we would have to define the actual method signature in the property, which would be cumbersome when not using the tooling. Yes, that's right - but I doubt that anyone is using AdapterProvider without the tooling - right now I don't see any advandate of doing runtime annotation checking, but the problem that things go wrong (interface implemented but no method annotation, method annotation but not AdapterProvider service). And having a marker interface for annotation scanning looks a little bit ugly as well - if we do runtime scanning, we could scan classes for the annotations like this is usually done with runtime scanning for annotations. But of course this would come with a high cost. So the current approach looks like a wrong compromise to me. Carsten -- Carsten Ziegeler cziege...@apache.org
[jira] [Updated] (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated SLING-1778: -- Attachment: 130704_symlinks-0.0.4.patch it passed some time since the last update on this ticket... thanks julian for this initial patch proposal, good work. we had a requirement within our project to implement exactly such behavior to mirror some hundred sites with a lot of pages/nodes without really copying them in the JCR, but with allowing some small overlays of single nodes. exactly what was provided by the patch. when working with the patch we detected some fixes, optimizations and enhancements are required, attached is a new patch: [^130704_symlinks-0.0.4.patch] the relevant changes where: * prefix all properties with symlink, add symlinkRegisterParent property * use sling api instead of JCR api where possible * detect invalid symlink definitions * refactor overlay implementation * fixed resource handling in Wrapper objects * cache toString method call execution as optimization * added configuration to enable/disable symlink functionality * add public access to registered providers and their configurations * change provider map to concurrent hash map there are probably still some issues left that where not relevant for our usecases. still the current code seems to be quite stable, we're using it in production. i would be glad if the initial patch and our contributions can make it into the extensions section of the sling project to get a wider audience if others are interested as well. Symlinks Key: SLING-1778 URL: https://issues.apache.org/jira/browse/SLING-1778 Project: Sling Issue Type: New Feature Components: JCR Reporter: Julian Sedding Attachments: 130704_symlinks-0.0.4.patch, symlinks.patch I have implemented a ResourceProvider, which allows to create symlink nodes in the JCR repository. A symlink node has a sling:symlinkTarget property, which should contain a valid JCR path. JCR content from the sling:symlinkTarget path is then exposed below the symlink node. There is a mixin node type, sling:Symlink with a mandatory property sling:symlinkTarget and an optional property sling:overlayable. Additionally, there is a convenience node type, sling:SymlinkResource, which extends from sling:symlinkTarget and nt:unstructured. ResourceProvider instances are registered for existing symlinks when the bundle is started. Modifications are taken care of via JCR observation. To get started: * apply the attached patch to a trunk checkout * build and install the bundle * create a symlink node, pointing to some existing content * access the symlink node e.g. via a browser -- 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
Does Sling has a Resource Resolver for Cassandra already ?
Hi Ian,
Does Sling has a Resource Resolver for Cassandra already ? I am in the
process of re factoring the code based on code reviews.
public class CassandraResourceResolver implements ResourceResolver {
You wont need this implementation. ResourceResolver is implemented for
you, all you need to implement is the resource provider.
What is the name of the resource resolver we already have ? So that I can
use it directly.
--
Thanks
/Dishara
Re: [Status Update] Apache Cassandra backend for Sling
Hi Ian, I have refactored almost all the code review changes requested. In the process of the rest of the implementation. On Wed, Jul 3, 2013 at 12:52 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi Dishara, On Tue, Jul 2, 2013 at 6:51 PM, Dishara Wijewardana ddwijeward...@gmail.com wrote: ...Does each bundle in sling made to run their junit tests separately at build time... Could you start new threads with new subject lines when you start a new question or discussion? Otherwise it's very hard to find things in our mailing list archives. OK. That's a good idea. I will follow that. Thanks, and keep up the good work! -Bertrand -- Thanks /Dishara
Problem with form based authentication
Hi all,
I'm about to switch to form based authentication for some of my sites.
I deployed the org.apache.sling.auth.form bundle in version 1.0.2 as I
believe that later versions are not compatible with CRX 2.2.
After some config, the login form pops up and sends the two required
fields j_username and j_password. Unfortunately, the request gets never
approved. Instead, the error.log says the following:
... org.apache.sling.auth.core.impl.SlingAuthenticator
handleLoginFailure: Unable to authenticate jurg: null
Most likely, this is generated by SlingAuthenticator.handleLoginFailure():
} else if (reason instanceof LoginException) {
// request authentication information and send 403 (Forbidden)
// if no handler can request authentication information.
log.info(handleLoginFailure: Unable to authenticate {}: {}, user,
reason.getMessage());
This now raises the following questions:
- using basic authentication, login with the same credentials works fine. So
what's keeping form based authenticator from verifying the credentials properly?
- what causes the reason to be empty?
Thanks for any hint,
Juerg
Re: Does Sling has a Resource Resolver for Cassandra already ?
Hi Dishara,
It does,
All you need to do, in a OSGI Component annotated with @Component is add a
private property and annotate it with @Reference. Eg
@Reference
private ResourceResolver resourceResolver;
When the component is activated, the ResourceResolver implementation will
in set.
hTH
Ian
On Friday, July 5, 2013, Dishara Wijewardana wrote:
Hi Ian,
Does Sling has a Resource Resolver for Cassandra already ? I am in the
process of re factoring the code based on code reviews.
public class CassandraResourceResolver implements ResourceResolver {
You wont need this implementation. ResourceResolver is implemented for
you, all you need to implement is the resource provider.
What is the name of the resource resolver we already have ? So that I can
use it directly.
--
Thanks
/Dishara
