[jira] [Commented] (SLING-2939) 3rd-party based implementation of discovery.api
[ https://issues.apache.org/jira/browse/SLING-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13697563#comment-13697563 ] Stefan Egli commented on SLING-2939: [~olli] Agreed, should be a good example of a Hazelcast implementation. 3rd-party based implementation of discovery.api --- Key: SLING-2939 URL: https://issues.apache.org/jira/browse/SLING-2939 Project: Sling Issue Type: Task Components: Extensions Affects Versions: Discovery API 1.0.0 Reporter: Stefan Egli Assignee: Stefan Egli The Sling Discovery API introduces the abstraction of a topology which contains (Sling) clusters and instances, supports liveliness-detection, leader-election within a cluster and property-propagation between the instances. As a default and reference implementation a resource-based, OOTB implementation was created (org.apache.sling.discovery.impl). Pros and cons of the discovery.impl Although the discovery.impl supports everything required in discovery.api, it has a few limitations. Here's a list of pros and cons: Pros No additional software required (leverages repository for intra-cluster communication/storage and HTTP-REST calls for cross-cluster communication) Very small footprint Perfectly suited for a single clusters, instance and for small, rather stable hub-based topologies Cons Config-/deployment-limitations (aka embedded-limitation): connections between clusters are peer-to-peer and explicit. To span a topology, a number of instances must (be made) know (to) each other, changes in the topology typically requires config adjustments to guarantee high availability of the discovery service Except if a natural hub cluster exists that can serve as connection point for all satellite clusters Other than that, it is less suited for large and/or dynamic topologies Change propagation (for topology parts reported via connectors) is non-atomic and slow, hop-by-hop based No guarantee on order of TopologyEvents sent in individual instances - ie different instances might see different orders of TopologyEvents (ie changes in the topology) but eventually the topology is guaranteed to be consistent Robustness of discovery.impl wrt storm situations depends on robustness of underlying cluster (not a real negative but discovery.impl might in theory unveil repository bugs which would otherwise not have been a problem) Rather new, little tested code which might have issues with edge cases wrt network problems although partitioning-support is not a requirement per se, similar edge-cases might exist wrt network-delays/timing/crashes Reusing a suitable 3rd party library To provide an additional option as implementation of the discovery.api one idea is to use a suitable 3rd party library. Requirements The following is a list of requirements a 3rd party library must support: liveliness detection: detect whether an instance is up and running stable leader election within a cluster: stable describes the fact that a leader will remain leader until it leaves/crashes and no new, joining instance shall take over while a leader exists stable instance ordering: the list of instances within a cluster is ordered and stable, new, joining instances are put at the end of the list property propagation: propagate the properties provided within one instance to everybody in the topology. there are no timing requirements bound to this but the intention of this is not to be used as messaging but to announce config parameters to the topology support large, dynamic clusters: configuration of the new discovery implementation should be easy and support frequent changes in the (large) topology no single point of failure: this is obvious, there should of course be no single point of failure in the setup embedded or dedicated: this might be a hot topic: embedding a library has the advantages of not having to install anything additional. a dedicated service on the other hand requires additional handling in deployment. embedding implies a peer-to-peer setup: nodes communicate peer-to-peer rather than via a centralized service. this IMHO is a negative for large topologies which would typically be cross data-centers. hence a dedicated service could be seen as an advantage in the end. due to need for cross data-center deployments, the transport protocol must be TCP (or HTTP for that matter) -- 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-2939) 3rd-party based implementation of discovery.api
[ https://issues.apache.org/jira/browse/SLING-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13697567#comment-13697567 ] Stefan Egli commented on SLING-2939: [~ianeboston] great points. I agree that JGroups probably requires every member of the cluster to agree while ZooKeeper typically has a rather small set of servers (3, 5, 7) which do the consensus. Thus having an advantage there. Another aspect I think is the fact that JGroups is a messaging channel and is excellent at that. What the discovery.api needs though is not messaging, it only needs leader consensus and liveliness detection (and a bit of property propagation). But I agree that in a reasonable sized cluster setup JGroups would be a lean fit. 3rd-party based implementation of discovery.api --- Key: SLING-2939 URL: https://issues.apache.org/jira/browse/SLING-2939 Project: Sling Issue Type: Task Components: Extensions Affects Versions: Discovery API 1.0.0 Reporter: Stefan Egli Assignee: Stefan Egli The Sling Discovery API introduces the abstraction of a topology which contains (Sling) clusters and instances, supports liveliness-detection, leader-election within a cluster and property-propagation between the instances. As a default and reference implementation a resource-based, OOTB implementation was created (org.apache.sling.discovery.impl). Pros and cons of the discovery.impl Although the discovery.impl supports everything required in discovery.api, it has a few limitations. Here's a list of pros and cons: Pros No additional software required (leverages repository for intra-cluster communication/storage and HTTP-REST calls for cross-cluster communication) Very small footprint Perfectly suited for a single clusters, instance and for small, rather stable hub-based topologies Cons Config-/deployment-limitations (aka embedded-limitation): connections between clusters are peer-to-peer and explicit. To span a topology, a number of instances must (be made) know (to) each other, changes in the topology typically requires config adjustments to guarantee high availability of the discovery service Except if a natural hub cluster exists that can serve as connection point for all satellite clusters Other than that, it is less suited for large and/or dynamic topologies Change propagation (for topology parts reported via connectors) is non-atomic and slow, hop-by-hop based No guarantee on order of TopologyEvents sent in individual instances - ie different instances might see different orders of TopologyEvents (ie changes in the topology) but eventually the topology is guaranteed to be consistent Robustness of discovery.impl wrt storm situations depends on robustness of underlying cluster (not a real negative but discovery.impl might in theory unveil repository bugs which would otherwise not have been a problem) Rather new, little tested code which might have issues with edge cases wrt network problems although partitioning-support is not a requirement per se, similar edge-cases might exist wrt network-delays/timing/crashes Reusing a suitable 3rd party library To provide an additional option as implementation of the discovery.api one idea is to use a suitable 3rd party library. Requirements The following is a list of requirements a 3rd party library must support: liveliness detection: detect whether an instance is up and running stable leader election within a cluster: stable describes the fact that a leader will remain leader until it leaves/crashes and no new, joining instance shall take over while a leader exists stable instance ordering: the list of instances within a cluster is ordered and stable, new, joining instances are put at the end of the list property propagation: propagate the properties provided within one instance to everybody in the topology. there are no timing requirements bound to this but the intention of this is not to be used as messaging but to announce config parameters to the topology support large, dynamic clusters: configuration of the new discovery implementation should be easy and support frequent changes in the (large) topology no single point of failure: this is obvious, there should of course be no single point of failure in the setup embedded or dedicated: this might be a hot topic: embedding a library has the advantages of not having to install anything additional. a dedicated service on the other hand requires additional handling in deployment. embedding implies a peer-to-peer setup: nodes communicate peer-to-peer rather than via a centralized service. this IMHO is a negative for large topologies
[jira] [Comment Edited] (SLING-2939) 3rd-party based implementation of discovery.api
[ https://issues.apache.org/jira/browse/SLING-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13697563#comment-13697563 ] Stefan Egli edited comment on SLING-2939 at 7/2/13 7:55 AM: [~olli] Agreed, should be a good example of an implementation using Hazelcast. was (Author: egli): [~olli] Agreed, should be a good example of a Hazelcast implementation. 3rd-party based implementation of discovery.api --- Key: SLING-2939 URL: https://issues.apache.org/jira/browse/SLING-2939 Project: Sling Issue Type: Task Components: Extensions Affects Versions: Discovery API 1.0.0 Reporter: Stefan Egli Assignee: Stefan Egli The Sling Discovery API introduces the abstraction of a topology which contains (Sling) clusters and instances, supports liveliness-detection, leader-election within a cluster and property-propagation between the instances. As a default and reference implementation a resource-based, OOTB implementation was created (org.apache.sling.discovery.impl). Pros and cons of the discovery.impl Although the discovery.impl supports everything required in discovery.api, it has a few limitations. Here's a list of pros and cons: Pros No additional software required (leverages repository for intra-cluster communication/storage and HTTP-REST calls for cross-cluster communication) Very small footprint Perfectly suited for a single clusters, instance and for small, rather stable hub-based topologies Cons Config-/deployment-limitations (aka embedded-limitation): connections between clusters are peer-to-peer and explicit. To span a topology, a number of instances must (be made) know (to) each other, changes in the topology typically requires config adjustments to guarantee high availability of the discovery service Except if a natural hub cluster exists that can serve as connection point for all satellite clusters Other than that, it is less suited for large and/or dynamic topologies Change propagation (for topology parts reported via connectors) is non-atomic and slow, hop-by-hop based No guarantee on order of TopologyEvents sent in individual instances - ie different instances might see different orders of TopologyEvents (ie changes in the topology) but eventually the topology is guaranteed to be consistent Robustness of discovery.impl wrt storm situations depends on robustness of underlying cluster (not a real negative but discovery.impl might in theory unveil repository bugs which would otherwise not have been a problem) Rather new, little tested code which might have issues with edge cases wrt network problems although partitioning-support is not a requirement per se, similar edge-cases might exist wrt network-delays/timing/crashes Reusing a suitable 3rd party library To provide an additional option as implementation of the discovery.api one idea is to use a suitable 3rd party library. Requirements The following is a list of requirements a 3rd party library must support: liveliness detection: detect whether an instance is up and running stable leader election within a cluster: stable describes the fact that a leader will remain leader until it leaves/crashes and no new, joining instance shall take over while a leader exists stable instance ordering: the list of instances within a cluster is ordered and stable, new, joining instances are put at the end of the list property propagation: propagate the properties provided within one instance to everybody in the topology. there are no timing requirements bound to this but the intention of this is not to be used as messaging but to announce config parameters to the topology support large, dynamic clusters: configuration of the new discovery implementation should be easy and support frequent changes in the (large) topology no single point of failure: this is obvious, there should of course be no single point of failure in the setup embedded or dedicated: this might be a hot topic: embedding a library has the advantages of not having to install anything additional. a dedicated service on the other hand requires additional handling in deployment. embedding implies a peer-to-peer setup: nodes communicate peer-to-peer rather than via a centralized service. this IMHO is a negative for large topologies which would typically be cross data-centers. hence a dedicated service could be seen as an advantage in the end. due to need for cross data-center deployments, the transport protocol must be TCP (or HTTP for that matter) -- This message is automatically generated by JIRA. If you think it was sent
[jira] [Comment Edited] (SLING-428) [Javascript] allow Server-side inclusion of Javascript files
[ https://issues.apache.org/jira/browse/SLING-428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12626954#comment-12626954 ] Bertrand Delacretaz edited comment on SLING-428 at 7/2/13 9:11 AM: --- Integration tests for the load() and print() functions added in http://svn.apache.org/r690209 and http://svn.apache.org/r690210 was (Author: bdelacretaz): Integration tests for the load() and print() functions added in revisions 690209 and 690210 [Javascript] allow Server-side inclusion of Javascript files Key: SLING-428 URL: https://issues.apache.org/jira/browse/SLING-428 Project: Sling Issue Type: Improvement Components: Scripting Reporter: Lars Trieloff Assignee: Bertrand Delacretaz Fix For: 3 Attachments: SLING-428.patch For the sake of modularizing server-side Javascript libraries, it is advisable to have an inclusion mechanism. Javascript does not have an standardized way of handling inclusions, so I propose to use the conventions established by the Rhino Javascript Shell (http://www.mozilla.org/rhino/shell.html) which is introducing a load() function in the global scope, loading and evaluating a Javascript file in the current scope. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSS] SLING-2936 - passing selector as POST parameter
Hi, On Thu, Jun 27, 2013 at 5:46 PM, Justin Edelson jus...@justinedelson.com wrote: ...I think there is a significant need to be able to select amongst multiple POST servlets for a particular resource. Thus, I propose that we allow for the selector to be passed via a request parameter Why is that better than using a selector? -Bertrand (not contesting, trying to understand ;-)
[jira] [Commented] (SLING-2939) 3rd-party based implementation of discovery.api
[ https://issues.apache.org/jira/browse/SLING-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13697729#comment-13697729 ] Stefan Egli commented on SLING-2939: An alternative approach could be a configurable mix of zookeeper embedded and zookeeper clients: given a deployment of a Sling topology that has a natural 'central cluster', those instances from that central cluster could have embedded zookeeper (with the requirement of being ideally 2n+1), and the remaining Sling instances are configured to be zookeeper clients. 3rd-party based implementation of discovery.api --- Key: SLING-2939 URL: https://issues.apache.org/jira/browse/SLING-2939 Project: Sling Issue Type: Task Components: Extensions Affects Versions: Discovery API 1.0.0 Reporter: Stefan Egli Assignee: Stefan Egli The Sling Discovery API introduces the abstraction of a topology which contains (Sling) clusters and instances, supports liveliness-detection, leader-election within a cluster and property-propagation between the instances. As a default and reference implementation a resource-based, OOTB implementation was created (org.apache.sling.discovery.impl). Pros and cons of the discovery.impl Although the discovery.impl supports everything required in discovery.api, it has a few limitations. Here's a list of pros and cons: Pros No additional software required (leverages repository for intra-cluster communication/storage and HTTP-REST calls for cross-cluster communication) Very small footprint Perfectly suited for a single clusters, instance and for small, rather stable hub-based topologies Cons Config-/deployment-limitations (aka embedded-limitation): connections between clusters are peer-to-peer and explicit. To span a topology, a number of instances must (be made) know (to) each other, changes in the topology typically requires config adjustments to guarantee high availability of the discovery service Except if a natural hub cluster exists that can serve as connection point for all satellite clusters Other than that, it is less suited for large and/or dynamic topologies Change propagation (for topology parts reported via connectors) is non-atomic and slow, hop-by-hop based No guarantee on order of TopologyEvents sent in individual instances - ie different instances might see different orders of TopologyEvents (ie changes in the topology) but eventually the topology is guaranteed to be consistent Robustness of discovery.impl wrt storm situations depends on robustness of underlying cluster (not a real negative but discovery.impl might in theory unveil repository bugs which would otherwise not have been a problem) Rather new, little tested code which might have issues with edge cases wrt network problems although partitioning-support is not a requirement per se, similar edge-cases might exist wrt network-delays/timing/crashes Reusing a suitable 3rd party library To provide an additional option as implementation of the discovery.api one idea is to use a suitable 3rd party library. Requirements The following is a list of requirements a 3rd party library must support: liveliness detection: detect whether an instance is up and running stable leader election within a cluster: stable describes the fact that a leader will remain leader until it leaves/crashes and no new, joining instance shall take over while a leader exists stable instance ordering: the list of instances within a cluster is ordered and stable, new, joining instances are put at the end of the list property propagation: propagate the properties provided within one instance to everybody in the topology. there are no timing requirements bound to this but the intention of this is not to be used as messaging but to announce config parameters to the topology support large, dynamic clusters: configuration of the new discovery implementation should be easy and support frequent changes in the (large) topology no single point of failure: this is obvious, there should of course be no single point of failure in the setup embedded or dedicated: this might be a hot topic: embedding a library has the advantages of not having to install anything additional. a dedicated service on the other hand requires additional handling in deployment. embedding implies a peer-to-peer setup: nodes communicate peer-to-peer rather than via a centralized service. this IMHO is a negative for large topologies which would typically be cross data-centers. hence a dedicated service could be seen as an advantage in the end. due to need for cross data-center deployments, the transport protocol
Re: Sling Posthandling - thougts about the current behavior
On Tue, Jul 2, 2013 at 2:38 PM, Dominik Süß dominik.su...@gmail.com wrote: Facing some questions about how to prevent the SlingPostServlet to be able to perform a change I had a closer look at the current implementation and it looks like there is currently no secure way of doing that beside locking the target on persistancelevel (alias setting ACLs)... ...which looks to me like the right way of locking things. But maybe for the post servlet we need a parallel structure to define who's allowed to do what. You could for example have /user-rights/sling/post-servlet/post/content/foo and whoever's allowed to read that is allowed to post to /content/foo, barring other ACL limitations. Just thinking outloud mostly...my point is that any security-related stuff should be driven by ACLs, and in some case indirect ACLs can be useful. -Bertrand
Re: Sling Posthandling - thougts about the current behavior
Well, if locking is just about permission I do agree with ACLs being the right solution (the permission set on the node itself might be sufficient for that case) - if it is about businessconstraints that need to be fullfilled an ACL cannot solve this requirement[0]. This is why validation and so on should be performed first, I would think of a pipeline having a contract on each phase what can be done and what cannot be done, while a first phase might not write any data (even as transient changes) the next phase might be perform (transient) change, then the postoperations would be performed in a transient followed by another phase that might perform transient changes and/or stop the processing, followed by a last phase that is called after the resourceResolve has performed a commit(). This is purely about giving developers a contract on what they can and cannot do (and therefore what they can expect 3rd party code to do) at a specific point in this pipeline. [0] a businessconstraint to control sepecific operations by permissions could be solved by a shadowstructure like proposed by Bertrand. -- Dominik On Tue, Jul 2, 2013 at 2:47 PM, Bertrand Delacretaz bdelacre...@apache.orgwrote: On Tue, Jul 2, 2013 at 2:38 PM, Dominik Süß dominik.su...@gmail.com wrote: Facing some questions about how to prevent the SlingPostServlet to be able to perform a change I had a closer look at the current implementation and it looks like there is currently no secure way of doing that beside locking the target on persistancelevel (alias setting ACLs)... ...which looks to me like the right way of locking things. But maybe for the post servlet we need a parallel structure to define who's allowed to do what. You could for example have /user-rights/sling/post-servlet/post/content/foo and whoever's allowed to read that is allowed to post to /content/foo, barring other ACL limitations. Just thinking outloud mostly...my point is that any security-related stuff should be driven by ACLs, and in some case indirect ACLs can be useful. -Bertrand
[jira] [Updated] (SLING-2938) AdapterMethods annotation and adapter proxy service
[
https://issues.apache.org/jira/browse/SLING-2938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Delacretaz updated SLING-2938:
---
Attachment: SLING-2938-api.patch
Here's my proposed SLING-2938-api.patch to integrate this in trunk.
The adapter bundle changes can be found under
https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/adapter-methods/extensions-adapter,
it's 3 new classes (AdapterMethodsManagerImplTest, AdapterMethodManagerIT,
AdapterMethodsManagerImpl) and changes to the pom to enable pax exam tests.
AdapterMethods annotation and adapter proxy service
---
Key: SLING-2938
URL: https://issues.apache.org/jira/browse/SLING-2938
Project: Sling
Issue Type: Bug
Components: Engine, Extensions
Affects Versions: Adapter 2.1.0
Reporter: Bertrand Delacretaz
Priority: Minor
Attachments: SLING-2938-api.patch
Following up on an idea that Olaf Otto presented at CQCon last week, I've
been working on an @AdapterMethod annotation that makes it easier to create
Sling adapters, as in
@Component
@Service
public class MyAdapters implements AdapterMethodProvider {
@AdapterMethod
public Bar toBar(Foo f) { ... adapt Foo to Bar ... }
}
As this requires changes to the sling.api bundle, I'll commit to my
whiteboard first, for review
--
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-2938) AdapterMethods annotation and adapter proxy service
[
https://issues.apache.org/jira/browse/SLING-2938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Delacretaz updated SLING-2938:
---
Attachment: console.jpg
Here's a screenshot of how an @Adapter method looks in the console plugin (at
the bottom)
AdapterMethods annotation and adapter proxy service
---
Key: SLING-2938
URL: https://issues.apache.org/jira/browse/SLING-2938
Project: Sling
Issue Type: Bug
Components: Engine, Extensions
Affects Versions: Adapter 2.1.0
Reporter: Bertrand Delacretaz
Priority: Minor
Attachments: console.jpg, SLING-2938-api.patch
Following up on an idea that Olaf Otto presented at CQCon last week, I've
been working on an @AdapterMethod annotation that makes it easier to create
Sling adapters, as in
@Component
@Service
public class MyAdapters implements AdapterMethodProvider {
@AdapterMethod
public Bar toBar(Foo f) { ... adapt Foo to Bar ... }
}
As this requires changes to the sling.api bundle, I'll commit to my
whiteboard first, for review
--
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
@Adapter methods, ready to integrate in trunk, WDYT?
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
[jira] [Created] (SLING-2942) symbol in OSGI config is resulting in an error at build time
Bala Kondepudi created SLING-2942: - Summary: symbol in OSGI config is resulting in an error at build time Key: SLING-2942 URL: https://issues.apache.org/jira/browse/SLING-2942 Project: Sling Issue Type: Bug Components: Maven Plugins and Archetypes Environment: Using the latest Apache Sling that is bundled in CQ 5.6.1.20130606 Reporter: Bala Kondepudi Priority: Critical When an ampersand() is used in OSGI config string it is resulting in error on the maven at build time. When the ampersand is removed from the OSGI config is making the build to pass. com.a.b.c.TestClass.xml ?xml version=1.0 encoding=UTF-8? jcr:root xmlns:sling=http://sling.apache.org/jcr/sling/1.0; xmlns:jcr=http://www.jcp.org/jcr/1.0; jcr:primaryType=sling:OsgiConfig login.url=https://aa.bb.com/external/auth/login.action?request_locale=en_USurl=http://aaa.bbb.ccom/ maven-error: [INFO] [ERROR] Failed to execute goal org.codehaus.mojo:xml-maven-plugin:1.0:validate (default) on project app: While parsing C:\sources\trunk\app\jcr_root\apps\aaa\config.author\com.a.b.c.TestClass.xml, at file:/C/sources/trunk/app/aaa/jcr_root/apps/aaa/config.author/com.a.b.c.TestClass.xml, line 6, column 113: The entity name must immediately follow the '' in the entity reference. - [Help 1] [ERROR] -- 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-2942) symbol in OSGI config is resulting in an error at build time
[ https://issues.apache.org/jira/browse/SLING-2942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz resolved SLING-2942. Resolution: Invalid Your XML is not well-formed, ampersand should be escaped: login.url=https://aa.bb.com/external/auth/login.action?request_locale=en_USamp;url=http://aaa.bbb.ccom; Resolving invalid - not a Sling problem. symbol in OSGI config is resulting in an error at build time -- Key: SLING-2942 URL: https://issues.apache.org/jira/browse/SLING-2942 Project: Sling Issue Type: Bug Components: Maven Plugins and Archetypes Environment: Using the latest Apache Sling that is bundled in CQ 5.6.1.20130606 Reporter: Bala Kondepudi Priority: Critical Labels: osgi-config, sling When an ampersand() is used in OSGI config string it is resulting in error on the maven at build time. When the ampersand is removed from the OSGI config is making the build to pass. com.a.b.c.TestClass.xml ?xml version=1.0 encoding=UTF-8? jcr:root xmlns:sling=http://sling.apache.org/jcr/sling/1.0; xmlns:jcr=http://www.jcp.org/jcr/1.0; jcr:primaryType=sling:OsgiConfig login.url=https://aa.bb.com/external/auth/login.action?request_locale=en_USurl=http://aaa.bbb.ccom/ maven-error: [INFO] [ERROR] Failed to execute goal org.codehaus.mojo:xml-maven-plugin:1.0:validate (default) on project app: While parsing C:\sources\trunk\app\jcr_root\apps\aaa\config.author\com.a.b.c.TestClass.xml, at file:/C/sources/trunk/app/aaa/jcr_root/apps/aaa/config.author/com.a.b.c.TestClass.xml, line 6, column 113: The entity name must immediately follow the '' in the entity reference. - [Help 1] [ERROR] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Build failed in Jenkins: sling-healthcheck-1.6 #36
See https://builds.apache.org/job/sling-healthcheck-1.6/36/changes Changes: [bdelacretaz] SLING-2822 - support attributes in InternalRequest -- [...truncated 338 lines...] 677 [main] WARN org.apache.sling.hc.api.Rule - Value [TEST_PASSED TEST_PASSED] does not match expression [TEST_PASSED] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec Running org.apache.sling.hc.sling.impl.ServletTagsSelectionTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.115 sec Running org.apache.sling.hc.sling.impl.rules.JUnitTestSelectorTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.1 sec Running org.apache.sling.hc.sling.LoginRuleBuilderTest 3259 [main] INFO org.apache.jackrabbit.core.RepositoryImpl - Starting repository... 3263 [main] INFO org.apache.jackrabbit.core.fs.local.LocalFileSystem - LocalFileSystem initialized at path https://builds.apache.org/job/sling-healthcheck-1.6/ws/healthcheck/hc-sling/target/repository/repository 3622 [main] INFO org.apache.jackrabbit.core.nodetype.NodeTypeRegistry - no custom node type definitions found 3630 [main] INFO org.apache.jackrabbit.core.fs.local.LocalFileSystem - LocalFileSystem initialized at path https://builds.apache.org/job/sling-healthcheck-1.6/ws/healthcheck/hc-sling/target/repository/version 7988 [main] INFO org.apache.jackrabbit.core.RepositoryImpl - initializing workspace 'default'... 7988 [main] INFO org.apache.jackrabbit.core.fs.local.LocalFileSystem - LocalFileSystem initialized at path https://builds.apache.org/job/sling-healthcheck-1.6/ws/healthcheck/hc-sling/target/repository/workspaces/default 11382 [main] INFO org.apache.jackrabbit.core.query.lucene.SearchIndex - Index initialized: https://builds.apache.org/job/sling-healthcheck-1.6/ws/healthcheck/hc-sling/target/repository/repository/index Version: 3 11649 [main] INFO org.apache.jackrabbit.core.query.lucene.SearchIndex - Index initialized: https://builds.apache.org/job/sling-healthcheck-1.6/ws/healthcheck/hc-sling/target/repository/workspaces/default/index Version: 3 11650 [main] INFO org.apache.jackrabbit.core.RepositoryImpl - workspace 'default' initialized 11656 [main] INFO org.apache.jackrabbit.core.RepositoryImpl - SecurityManager = class org.apache.jackrabbit.core.DefaultSecurityManager 11657 [main] INFO org.apache.jackrabbit.core.RepositoryImpl - initializing workspace 'security'... 11657 [main] INFO org.apache.jackrabbit.core.fs.local.LocalFileSystem - LocalFileSystem initialized at path https://builds.apache.org/job/sling-healthcheck-1.6/ws/healthcheck/hc-sling/target/repository/workspaces/security 12818 [main] INFO org.apache.jackrabbit.core.query.lucene.SearchIndex - Index initialized: https://builds.apache.org/job/sling-healthcheck-1.6/ws/healthcheck/hc-sling/target/repository/workspaces/security/index Version: 3 12819 [main] INFO org.apache.jackrabbit.core.RepositoryImpl - workspace 'security' initialized 12821 [main] INFO org.apache.jackrabbit.core.DefaultSecurityManager - init: use Repository Login-Configuration for Jackrabbit 12903 [main] INFO org.apache.jackrabbit.core.RepositoryImpl - Repository started (9644ms) 12904 [main] INFO org.apache.jackrabbit.core.TransientRepository - Transient repository initialized 12978 [main] INFO org.apache.jackrabbit.core.TransientRepository - Session opened 13006 [main] INFO org.apache.jackrabbit.core.TransientRepository - Session opened 13006 [main] WARN org.apache.sling.hc.api.Rule - Login as user [admin] successful, should have failed 13006 [main] INFO org.apache.jackrabbit.core.TransientRepository - Session closed 13007 [main] WARN org.apache.sling.hc.api.Rule - Value [] does not match expression [LOGIN_OK] 13008 [main] WARN org.apache.sling.hc.api.Rule - Value [] does not match expression [OK] 13010 [main] WARN org.apache.sling.hc.api.Rule - Value [] does not match expression [OK] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.11 sec 13076 [Thread-4] INFO org.apache.jackrabbit.core.TransientRepository - Session closed 13077 [Thread-4] INFO org.apache.jackrabbit.core.RepositoryImpl - Shutting down repository... 13080 [Thread-4] INFO org.apache.jackrabbit.core.query.lucene.SearchIndex - Index closed: https://builds.apache.org/job/sling-healthcheck-1.6/ws/healthcheck/hc-sling/target/repository/repository/index 13081 [Thread-4] INFO org.apache.jackrabbit.core.RepositoryImpl - shutting down workspace 'default'... 13082 [Thread-4] INFO org.apache.jackrabbit.core.observation.ObservationDispatcher - Notification of EventListeners stopped. 13083 [Thread-4] INFO org.apache.jackrabbit.core.query.lucene.SearchIndex - Index closed: https://builds.apache.org/job/sling-healthcheck-1.6/ws/healthcheck/hc-sling/target/repository/workspaces/default/index 13193 [Thread-4] INFO org.apache.jackrabbit.core.util.db.DerbyConnectionHelper - Database
Re: [Status Update] Apache Cassandra backend for Sling
Hi Ian, Does each bundle in sling made to run their junit tests separately at build time ? If so each pom should have configured to junit test cases. Where and how to define them ? On Mon, Jul 1, 2013 at 5:32 AM, Ian Boston i...@tfd.co.uk wrote: Hi Dishara, I've taken the liberty of creating a code review at [1]. This is all commits. I've emailed you separately with the comments. I think it would be good if we can get into the habit of looking at the code in this way as it often removes confusion introduced by the english language (which has many compilers ;), mine has been known to be buggy at times.). More comments inline below: (BTW, excellent progress!) Best Regards Ian 1 https://codereview.appspot.com/10811044/ On 30 June 2013 22:52, Dishara Wijewardana ddwijeward...@gmail.com wrote: On Fri, Jun 28, 2013 at 4:37 AM, Ian Boston i...@tfd.co.uk wrote: Hi, Have you tried the TypeInferringSerializer for the value serializer ? That claims to be detect what the column value is based on the Byte array. Failing that, I would consider making everything byte[] and using your own serializer that writes and read values to a byte[] using DataInputStream DataOutputStream. [2] Is an example of a serializer written for that purpose that was used with Cassandra over raw Thrift. Its not easy to read what it outputs to the storage layer, but it is compact and efficient. I would not use it directly as it does some very specific things like slicing large byte[]s into 1MB chunks and bypassing the 64K limit on reading and writing UTF8 strings with DataInputStream. Try the TypeInferringSerializer first. If it works great, no need to do anything more complex. Hi, In fact I was able to add as many params as I wanted with the same configurations. But TypeInferringSerializer is a useful one too which might need in future. Also I was thinking rather than storing resource meta data as String values, how about storing a serialized object as you mentioned ? I suspect that TypeInferringSerializer will do a better job of serializing than the approach I mentioned. Only consider writing your own, if there is a real and demonstrated need for it. It will be clear. But I am not sure about the performance. Because when we have multi valued columns like meta data we have to insert them in a single String as comma separated values. It is scalable if we have a Bean for Cassandra Resource ? What do you think ? Put one property per column in Cassandra if possible. IIRC it does a good job of serializing data, and doesnt need a pre-defined schema as traditional RDBMS's do. The serialisation I mentioned was mostly used to get schemaless storage into an RDBMS. And I did a first cut of this but with many TODOs ;-), where getResource method is implemented and currently all the content is printed, but I have not implemented methods in CassandraResource yet. This is just a POC to test whether the proposed model works. Apparently it works [1]. Yes, this is a great start! I didn't find to many issues with the approach, as you will see from the comments on the code review. See CassandraDataPopulator class which is a plain java test class added for the moment to test the POC.(I am moving this to a proper JUnit) Good. TODOs - I am in the process of finishing the implementation of Cassandra Resource, CassandaResource Provider and etc END to END. - Move to JUnit test framework and write more tests for each scenario where I can extend this to Mockito (I am still not clear how Mockito comes in to the picture) in near future. When you write the Unit tests, if you find that you need to mock anything (ie ResourceResolver) to make your unit tests work, dont. Use Mocks. You can even Mockup concrete clases so could mockup the behaviour of the Hector API to respond in a pre-defined way to certain CQL queries. This will eliminate the need to have a real cassandra server present when doing the basic unit tests. - Change the implementation based on the feedbacks from the community. - Parameterize the constants as much as possible to read from a property file. These should come from OSGi Properties. See the comments on CassandraResoureProvider [1] - https://cassandra-backend-for-sling.googlecode.com/svn/trunk/main/cassandra Thanks Excellent progress, thank you! Ian Ian 1 http://hector-client.github.io/hector/source/content/API/core/0.8.0-2/me/prettyprint/cassandra/serializers/TypeInferringSerializer.html 2 https://github.com/ieb/sparsemapcontent/tree/master/core/src/main/java/org/sakaiproject/nakamura/lite/storage/spi/types On 28 June 2013 05:14, Dishara Wijewardana ddwijeward...@gmail.com wrote: Hi Ian, I am having a problem with CQL.. For example:
[jira] [Resolved] (SLING-2834) sling:include support two new attributes
[ https://issues.apache.org/jira/browse/SLING-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Klco resolved SLING-2834. - Resolution: Fixed Added the new variables and support for saving included content into the sling:include tag sling:include support two new attributes Key: SLING-2834 URL: https://issues.apache.org/jira/browse/SLING-2834 Project: Sling Issue Type: Improvement Components: Servlets Affects Versions: Scripting JSP-Taglib 2.1.8 Reporter: Michael J. Kelleher Assignee: Dan Klco Priority: Minor Labels: features Original Estimate: 72h Remaining Estimate: 72h Look at the functionality of c:import for context to this request: http://docs.oracle.com/cd/E17802_01/products/products/jsp/jstl/1.1/docs/tlddocs/index.html That tag supports 2 attributes: var and varReader. These two variable prevent the included resource from automatically being including the output of current requests 'out' Stream. They do the following: var - stores the output of the included resource as a String in the scoped variable identified by 'var'. varReader - stores a Reader to the included content in the scoped variable 'varReader'. Both of these would likely need the 'scope' attribute as well. The current use case I have for this is that I do not want to extend or modify the functionality of the included resource to serve my new requirement. The change I need to make to the markup is fairly small, and would not want to have to maintain a new component for such a small change. I want to include a transformed version of the included resource. The addition of these two attributes would allow me to store the resultant markup and transform it before including it within my current request. I can certainly write this functionality myself (and will be using sling:include) but it would be nice if sling:include itself supported this functionality. -- 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-2803) Create a Validation module capable of validating POST requests or Resources
[ https://issues.apache.org/jira/browse/SLING-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-2803: Attachment: org.apache.sling.validation-2.zip I've improved the API and added more functionality to the default implementation and testing modules. The changes from the new attached archive (org.apache.sling.validation-2.zip, 3c00ec5e0a9fd983841e07194479fd30) include: * API improvements / changes: - removed the ValidatorArgument object which was passed in lists in favour of a simple key-value arguments map - created a ValidatorException that can be thrown by Validators in case the validate method is called with missing but expected arguments * CORE (default implementation): - implemented API changes - implemented validation models cache invalidation in ValidationServiceImpl - implemented validation models overlaying in ValidationServiceImpl (/apps/sling/validation/models vs. /libs/sling/validation/models) - provided a default RegexValidator that is more flexible than the previous AlphaCharactersValidator * TEST SERVICES / IT - separated the test services from the integration tests by creating two additional submodules: 1. test-services - some test services needed for triggering the validation code 2. it-http - a jar containing integration tests that are run automatically on a customised Sling Launchpad Create a Validation module capable of validating POST requests or Resources --- Key: SLING-2803 URL: https://issues.apache.org/jira/browse/SLING-2803 Project: Sling Issue Type: New Feature Reporter: Radu Cotescu Attachments: org.apache.sling.validation-2.zip, org.apache.sling.validation.zip Several Sling users have asked in the past [1] about a Validation mechanism in Sling that's able to validate data coming from the user. However, such a module is still missing. This issue is meant to track the work progress on such a module. Ideally the module should be able to validate both request parameters and Resources, by obtaining their properties via a ValueMap and provide feedback in case of a validation error. [1] - http://sling.markmail.org/search/?q=validation -- 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: Wrong handling of service.ranking property in Sling Filter ordering
On 18.06.2013, at 15:19, Felix Meschberger fmesc...@adobe.com wrote: So, I tend to switch over to the fix-the-implementation-camp. +1 It's what you expect (higher service ranking picked up first) and if the wrong cases are few and can be easily handled (big documentation note to sling users) that's definitely better. Cheers, Alex
Re: Sling Posthandling - thougts about the current behavior
Ack on the overall goal. The way I see it, it boils down to having the sling post servlet (or more specifically that new POST-pipeline) not just one special servlet out of many, but an integral part of Sling. Registering operations, post processors or whatever we need by resource type sounds good. By path not so much, don't know. IMHO, the rt would be taken from the addressed resource (what the URL addresses, to be 1:1 with how GET servlet resolution works; not any resources that additional request parameters might address) and if not present (creating a new resource) from the sling:resourceType param. It would actually be nice if those operations or postprocessor could become servlets or servlet filters again. They could get the necessary state passed via a request attribute for example + a utility to fetch them. And thinking about it, filters are actually the right thing, they are designed for pipelines. I am not sure if adding a :selector parameter as proposed by Justin (SLING-2936) is a good idea - maybe the integration with this new pipeline is the better long-term approach. You'd register by resource type + http method + :operation. Having both :operation and :selector (in the combined overall picture) seems like duplication. But it's difficult. It was mentioned that using selectors in the URL for POST requests, such as POST /content/page.createChild.html, is not RESTful. Is that really the case? As long as the server provides the URL instead of the client building it himself, such as path + .createChild.html as it happens way too much, and you use the right HTTP methods for changing/deleting content, nothing here would be unRESTful afaics. It would only look nicer if you put all the POST related information into the request parameters instead of into the URL. But then it's the old action=create topic again, which should be covered very well with the default features of the Sling post servlet already, which only requires you to add custom code (actions) for very specific things. This is even less once we have a validation framework in place (also resource type based), where Radu did a lot of work already! Cheers, Alex On 02.07.2013, at 15:26, Dominik Süß dominik.su...@gmail.com wrote: Well, if locking is just about permission I do agree with ACLs being the right solution (the permission set on the node itself might be sufficient for that case) - if it is about businessconstraints that need to be fullfilled an ACL cannot solve this requirement[0]. This is why validation and so on should be performed first, I would think of a pipeline having a contract on each phase what can be done and what cannot be done, while a first phase might not write any data (even as transient changes) the next phase might be perform (transient) change, then the postoperations would be performed in a transient followed by another phase that might perform transient changes and/or stop the processing, followed by a last phase that is called after the resourceResolve has performed a commit(). This is purely about giving developers a contract on what they can and cannot do (and therefore what they can expect 3rd party code to do) at a specific point in this pipeline. [0] a businessconstraint to control sepecific operations by permissions could be solved by a shadowstructure like proposed by Bertrand. -- Dominik On Tue, Jul 2, 2013 at 2:47 PM, Bertrand Delacretaz bdelacre...@apache.orgwrote: On Tue, Jul 2, 2013 at 2:38 PM, Dominik Süß dominik.su...@gmail.com wrote: Facing some questions about how to prevent the SlingPostServlet to be able to perform a change I had a closer look at the current implementation and it looks like there is currently no secure way of doing that beside locking the target on persistancelevel (alias setting ACLs)... ...which looks to me like the right way of locking things. But maybe for the post servlet we need a parallel structure to define who's allowed to do what. You could for example have /user-rights/sling/post-servlet/post/content/foo and whoever's allowed to read that is allowed to post to /content/foo, barring other ACL limitations. Just thinking outloud mostly...my point is that any security-related stuff should be driven by ACLs, and in some case indirect ACLs can be useful. -Bertrand
Issue Adding GPG Key
All, I am getting ready to create a release for the Sling taglib changes, unfortunately, I seem to have run into a snag trying to add my GPG key. According to the directions here: http://sling.apache.org/documentation/development/release-management.html#appendix-a-create-and-add-your-key-to-httpwwwapacheorgdistslingkeys I should be able to copy the exported key into /x1/www/ www.apache.org/dist/sling/KEYS, however I am getting a permission denied error: -bash: /x1/www/www.apache.org/dist/sling/KEYS: Permission denied Is there a new procedure or do I need to get additional permissions? I have reached out to the infrastructure team, but have not heard back. Thanks, Dan
Re: Sling Proposal
Justin, Felix, Thanks for your responses and please excuse that my terminology makes it a little too clear that I'm coming from CQ ;-). Justins's solution is actually very close to what I had in mind with the template based solution. I will mull over this and create ticket also referencing Justin's solution. Ben Am 01.07.13 11:48 schrieb Justin Edelson unter jus...@justinedelson.com: Ben- Have you looked at the filter at http://svn.apache.org/repos/asf/sling/trunk/samples/urlfilter ? It sounds like your solution is roughly inline with this implementation. Justin On Mon, Jul 1, 2013 at 2:30 AM, Ben Zahler ben.zah...@inside-solutions.chwrote: Hi all, I have done some work on selectors and security in CQ lately, and in the process I've had an idea how to handle some of the issues in Sling. From my point of view, this could well be intergrated into Sling, but it can also easily work as an addition, so I'd like to hear some feedback from you. The basic idea is to have the developer of a component/template define the selectors allowed on the component. I've used a property sling:allowedSelectors to do so. In a servlet filter, we can then check for all the allowed selectors in the application and verify if the request's selector are valid. Of course, there are a quite a few open questions/points: - should the allowed selectors be cached? - Servlets with sling.servlet.selectors property need to be included as well - Should the sling:allowedSelectors configuration be component or template based? Component based means the definition is where the selectors are actually implemented, template based provides more accurate means of checking whether request selectors are valid. - How can multisites be configured? Attached is a very basic implementation of the Servlet Filter. Be aware that installing this into a CQ author instance will break some things as the default CQ selectors are not supported. So basically, my question to you is if you think this is an interesting feature or if you consider this rather unnecessary. ;-) Mit besten Grüssen Ben Zahler Inside Solutions AG | Felsenstrasse 11 | 4450 Sissach | Schweiz Telefon: +41 61 551 00 40 | Direkt: +41 61 551 00 43 http://www.inside-solutions.ch
Re: Sling Proposal
Ben- You also might want to take a look at https://github.com/justinedelson/cq-urlfilter, which is virtually the same code, just adapted to work better in a CQ/AEM environment. Regards, Justin On Tue, Jul 2, 2013 at 4:49 PM, Ben Zahler ben.zah...@inside-solutions.chwrote: Justin, Felix, Thanks for your responses and please excuse that my terminology makes it a little too clear that I'm coming from CQ ;-). Justins's solution is actually very close to what I had in mind with the template based solution. I will mull over this and create ticket also referencing Justin's solution. Ben Am 01.07.13 11:48 schrieb Justin Edelson unter jus...@justinedelson.com: Ben- Have you looked at the filter at http://svn.apache.org/repos/asf/sling/trunk/samples/urlfilter ? It sounds like your solution is roughly inline with this implementation. Justin On Mon, Jul 1, 2013 at 2:30 AM, Ben Zahler ben.zah...@inside-solutions.chwrote: Hi all, I have done some work on selectors and security in CQ lately, and in the process I've had an idea how to handle some of the issues in Sling. From my point of view, this could well be intergrated into Sling, but it can also easily work as an addition, so I'd like to hear some feedback from you. The basic idea is to have the developer of a component/template define the selectors allowed on the component. I've used a property sling:allowedSelectors to do so. In a servlet filter, we can then check for all the allowed selectors in the application and verify if the request's selector are valid. Of course, there are a quite a few open questions/points: - should the allowed selectors be cached? - Servlets with sling.servlet.selectors property need to be included as well - Should the sling:allowedSelectors configuration be component or template based? Component based means the definition is where the selectors are actually implemented, template based provides more accurate means of checking whether request selectors are valid. - How can multisites be configured? Attached is a very basic implementation of the Servlet Filter. Be aware that installing this into a CQ author instance will break some things as the default CQ selectors are not supported. So basically, my question to you is if you think this is an interesting feature or if you consider this rather unnecessary. ;-) Mit besten Grüssen Ben Zahler Inside Solutions AG | Felsenstrasse 11 | 4450 Sissach | Schweiz Telefon: +41 61 551 00 40 | Direkt: +41 61 551 00 43 http://www.inside-solutions.ch
