[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=14711465#comment-14711465 ] Timothee Maret commented on SLING-2939: --- As of today, an embedded implementation using ZK would be still challenging as the zk code still invoke System.exit statements (planned to be solved in ZOOKEEPER-575) and AFAIK requires Netty dependency to be embedded. A dedicated ZK deployment may make sense though, especially considering large deployment involving many 3rd party libraries. I have opened SLING-2939 to track the implementation based on ZK (non embedded). 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 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
[jira] [Updated] (SLING-4968) ZooKeeper based discovery mechanism
[ https://issues.apache.org/jira/browse/SLING-4968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SLING-4968: --- Assignee: Timothee Maret ZooKeeper based discovery mechanism --- Key: SLING-4968 URL: https://issues.apache.org/jira/browse/SLING-4968 Project: Sling Issue Type: New Feature Components: Extensions Reporter: Timothee Maret Assignee: Timothee Maret Labels: discovery As described in SLING-2939, an embedded ZK still is not optimal since 1. Still uses System.exit statements in its code 2. Requires Netty server dependencies (Sling ships Jetty) - extra dependencies to manage / embed - most probably requires to run on a new port However, using ZooKeeper as discovery mechanism in a non embedded mode (dedicated infrastructure) still makes a lot of sense in large deployments. Indeed, considering that ZK is widely adopted in 3rd party products a large deployment would typically already deploy a ZK infrastructure which could be reused by a Sling discovery implementation. Furthermore, in terms of efficiency (# of requests), a ZK discovery implementation is expected to score high as it provides an efficient (non polling based) mechanism for receiving notifications. This would guarantee a fast propagation of Sling instances properties and state. This issue covers the implementation of the Sling discovery API based on ZK deployed in a dedicated infrastructure (not embedded) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4967) Script rendering performance degradation on Sling Launchpad 8-SNAPSHOT
Radu Cotescu created SLING-4967: --- Summary: Script rendering performance degradation on Sling Launchpad 8-SNAPSHOT Key: SLING-4967 URL: https://issues.apache.org/jira/browse/SLING-4967 Project: Sling Issue Type: Task Components: Scripting Reporter: Radu Cotescu The [Sightly performance tests|https://github.com/apache/sling/blob/trunk/bundles/scripting/sightly/testing-content/src/main/resources/SLING-INF/apps/sightlyperf/test/] show an almost 5 times performance degradation when running them on a Sling 8-SNAPSHOT launchpad compared to Sling 7. A performance analysis should be performed to uncover what changes have led to this, since both the JSP and the Sightly scripting engines seem to be affected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4968) ZooKeeper based discovery mechanism
[ https://issues.apache.org/jira/browse/SLING-4968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14711459#comment-14711459 ] Bertrand Delacretaz commented on SLING-4968: If needed we could add a ZooKeeper server to (a variant of) my https://github.com/bdelacretaz/docker-sling-cluster prototype to be able to test a non-embedded ZK variant. ZooKeeper based discovery mechanism --- Key: SLING-4968 URL: https://issues.apache.org/jira/browse/SLING-4968 Project: Sling Issue Type: New Feature Components: Extensions Reporter: Timothee Maret Labels: discovery As described in SLING-2939, an embedded ZK still is not optimal since 1. Still uses System.exit statements in its code 2. Requires Netty server dependencies (Sling ships Jetty) - extra dependencies to manage / embed - most probably requires to run on a new port However, using ZooKeeper as discovery mechanism in a non embedded mode (dedicated infrastructure) still makes a lot of sense in large deployments. Indeed, considering that ZK is widely adopted in 3rd party products a large deployment would typically already deploy a ZK infrastructure which could be reused by a Sling discovery implementation. Furthermore, in terms of efficiency (# of requests), a ZK discovery implementation is expected to score high as it provides an efficient (non polling based) mechanism for receiving notifications. This would guarantee a fast propagation of Sling instances properties and state. This issue covers the implementation of the Sling discovery API based on ZK deployed in a dedicated infrastructure (not embedded) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4866) JSP scripting engine performance degraded in org.apache.sling.scripting.jsp 2.1.6
[
https://issues.apache.org/jira/browse/SLING-4866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-4866.
-
Resolution: Cannot Reproduce
I figured out that this is not an issue of the JSP scripting engine.
The tests in question were initially run on a Sling Launchpad 7 instance, to
which the Sightly bundles were installed through the maven-launchpad-plugin.
The performance degradation was discovered after switching to the provisioning
model for the tests, which required Sling Launchpad 8-SNAPSHOT.
JSP scripting engine performance degraded in org.apache.sling.scripting.jsp
2.1.6
-
Key: SLING-4866
URL: https://issues.apache.org/jira/browse/SLING-4866
Project: Sling
Issue Type: Bug
Components: Scripting
Affects Versions: Scripting JSP 2.1.6
Reporter: Radu Cotescu
Priority: Critical
Fix For: Scripting JSP 2.1.8
The commit applied in
[r1629144|https://svn.apache.org/viewvc?view=revisionrevision=1629144] seems
to have affected the JSP scripting engine performance.
The Sightly JSP [performance
tests|https://github.com/apache/sling/blob/trunk/bundles/scripting/sightly/testing-content/src/main/resources/SLING-INF/apps/sightlyperf/test/test.jsp]
show a 5x degradation on my machine when compared to running the same tests
on {{org.apache.sling.scripting.jsp}} 2.1.4.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-4968) ZooKeeper based discovery mechanism
Timothee Maret created SLING-4968: - Summary: ZooKeeper based discovery mechanism Key: SLING-4968 URL: https://issues.apache.org/jira/browse/SLING-4968 Project: Sling Issue Type: New Feature Components: Extensions Reporter: Timothee Maret As described in SLING-2939, an embedded ZK still is not optimal since 1. Still uses System.exit statements in its code 2. Requires Netty server dependencies (Sling ships Jetty) - extra dependencies to manage / embed - most probably requires to run on a new port However, using ZooKeeper as discovery mechanism in a non embedded mode (dedicated infrastructure) still makes a lot of sense in large deployments. Indeed, considering that ZK is widely adopted in 3rd party products a large deployment would typically already deploy a ZK infrastructure which could be reused by a Sling discovery implementation. Furthermore, in terms of efficiency (# of requests), a ZK discovery implementation is expected to score high as it provides an efficient (non polling based) mechanism for receiving notifications. This would guarantee a fast propagation of Sling instances properties and state. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4968) ZooKeeper based discovery mechanism
[ https://issues.apache.org/jira/browse/SLING-4968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret updated SLING-4968: -- Description: As described in SLING-2939, an embedded ZK still is not optimal since 1. Still uses System.exit statements in its code 2. Requires Netty server dependencies (Sling ships Jetty) - extra dependencies to manage / embed - most probably requires to run on a new port However, using ZooKeeper as discovery mechanism in a non embedded mode (dedicated infrastructure) still makes a lot of sense in large deployments. Indeed, considering that ZK is widely adopted in 3rd party products a large deployment would typically already deploy a ZK infrastructure which could be reused by a Sling discovery implementation. Furthermore, in terms of efficiency (# of requests), a ZK discovery implementation is expected to score high as it provides an efficient (non polling based) mechanism for receiving notifications. This would guarantee a fast propagation of Sling instances properties and state. This issue covers the implementation of the Sling discovery API based on ZK deployed in a dedicated infrastructure (not embedded) was: As described in SLING-2939, an embedded ZK still is not optimal since 1. Still uses System.exit statements in its code 2. Requires Netty server dependencies (Sling ships Jetty) - extra dependencies to manage / embed - most probably requires to run on a new port However, using ZooKeeper as discovery mechanism in a non embedded mode (dedicated infrastructure) still makes a lot of sense in large deployments. Indeed, considering that ZK is widely adopted in 3rd party products a large deployment would typically already deploy a ZK infrastructure which could be reused by a Sling discovery implementation. Furthermore, in terms of efficiency (# of requests), a ZK discovery implementation is expected to score high as it provides an efficient (non polling based) mechanism for receiving notifications. This would guarantee a fast propagation of Sling instances properties and state. ZooKeeper based discovery mechanism --- Key: SLING-4968 URL: https://issues.apache.org/jira/browse/SLING-4968 Project: Sling Issue Type: New Feature Components: Extensions Reporter: Timothee Maret Labels: discovery As described in SLING-2939, an embedded ZK still is not optimal since 1. Still uses System.exit statements in its code 2. Requires Netty server dependencies (Sling ships Jetty) - extra dependencies to manage / embed - most probably requires to run on a new port However, using ZooKeeper as discovery mechanism in a non embedded mode (dedicated infrastructure) still makes a lot of sense in large deployments. Indeed, considering that ZK is widely adopted in 3rd party products a large deployment would typically already deploy a ZK infrastructure which could be reused by a Sling discovery implementation. Furthermore, in terms of efficiency (# of requests), a ZK discovery implementation is expected to score high as it provides an efficient (non polling based) mechanism for receiving notifications. This would guarantee a fast propagation of Sling instances properties and state. This issue covers the implementation of the Sling discovery API based on ZK deployed in a dedicated infrastructure (not embedded) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4968) ZooKeeper based discovery mechanism
[ https://issues.apache.org/jira/browse/SLING-4968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14711536#comment-14711536 ] Timothee Maret commented on SLING-4968: --- Thanks Bertrand for the link. I think it would indeed be a good testbed once the discovery implementation is available. ZooKeeper based discovery mechanism --- Key: SLING-4968 URL: https://issues.apache.org/jira/browse/SLING-4968 Project: Sling Issue Type: New Feature Components: Extensions Reporter: Timothee Maret Labels: discovery As described in SLING-2939, an embedded ZK still is not optimal since 1. Still uses System.exit statements in its code 2. Requires Netty server dependencies (Sling ships Jetty) - extra dependencies to manage / embed - most probably requires to run on a new port However, using ZooKeeper as discovery mechanism in a non embedded mode (dedicated infrastructure) still makes a lot of sense in large deployments. Indeed, considering that ZK is widely adopted in 3rd party products a large deployment would typically already deploy a ZK infrastructure which could be reused by a Sling discovery implementation. Furthermore, in terms of efficiency (# of requests), a ZK discovery implementation is expected to score high as it provides an efficient (non polling based) mechanism for receiving notifications. This would guarantee a fast propagation of Sling instances properties and state. This issue covers the implementation of the Sling discovery API based on ZK deployed in a dedicated infrastructure (not embedded) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4968) ZooKeeper based discovery mechanism
[ https://issues.apache.org/jira/browse/SLING-4968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14711535#comment-14711535 ] Timothee Maret commented on SLING-4968: --- Thanks Bertrand for the link. I think it would indeed be a good testbed once the discovery implementation is available. ZooKeeper based discovery mechanism --- Key: SLING-4968 URL: https://issues.apache.org/jira/browse/SLING-4968 Project: Sling Issue Type: New Feature Components: Extensions Reporter: Timothee Maret Labels: discovery As described in SLING-2939, an embedded ZK still is not optimal since 1. Still uses System.exit statements in its code 2. Requires Netty server dependencies (Sling ships Jetty) - extra dependencies to manage / embed - most probably requires to run on a new port However, using ZooKeeper as discovery mechanism in a non embedded mode (dedicated infrastructure) still makes a lot of sense in large deployments. Indeed, considering that ZK is widely adopted in 3rd party products a large deployment would typically already deploy a ZK infrastructure which could be reused by a Sling discovery implementation. Furthermore, in terms of efficiency (# of requests), a ZK discovery implementation is expected to score high as it provides an efficient (non polling based) mechanism for receiving notifications. This would guarantee a fast propagation of Sling instances properties and state. This issue covers the implementation of the Sling discovery API based on ZK deployed in a dedicated infrastructure (not embedded) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (SLING-4968) ZooKeeper based discovery mechanism
[ https://issues.apache.org/jira/browse/SLING-4968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret updated SLING-4968: -- Comment: was deleted (was: Thanks Bertrand for the link. I think it would indeed be a good testbed once the discovery implementation is available. ) ZooKeeper based discovery mechanism --- Key: SLING-4968 URL: https://issues.apache.org/jira/browse/SLING-4968 Project: Sling Issue Type: New Feature Components: Extensions Reporter: Timothee Maret Labels: discovery As described in SLING-2939, an embedded ZK still is not optimal since 1. Still uses System.exit statements in its code 2. Requires Netty server dependencies (Sling ships Jetty) - extra dependencies to manage / embed - most probably requires to run on a new port However, using ZooKeeper as discovery mechanism in a non embedded mode (dedicated infrastructure) still makes a lot of sense in large deployments. Indeed, considering that ZK is widely adopted in 3rd party products a large deployment would typically already deploy a ZK infrastructure which could be reused by a Sling discovery implementation. Furthermore, in terms of efficiency (# of requests), a ZK discovery implementation is expected to score high as it provides an efficient (non polling based) mechanism for receiving notifications. This would guarantee a fast propagation of Sling instances properties and state. This issue covers the implementation of the Sling discovery API based on ZK deployed in a dedicated infrastructure (not embedded) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4604) Multiple Content-Disposition headers added
[ https://issues.apache.org/jira/browse/SLING-4604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Sanso closed SLING-4604. Multiple Content-Disposition headers added -- Key: SLING-4604 URL: https://issues.apache.org/jira/browse/SLING-4604 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Security 1.0.10 Reporter: Rob Ryan Assignee: Antonio Sanso Fix For: Security 1.0.12 Attachments: 4604patch.txt Multiple content-disposition headers can be added under some conditions. This seems to happen because setContentType is actually called more than once for the same response when multiple sling scripts are involved in rendering, e.g. via org.apache.sling.scripting.core.impl.DefaultSlingScript.service(javax.servlet.ServletRequest, javax.servlet.ServletResponse) line: 448 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4883) Extend content disposition filter protection to jcr:data
[
https://issues.apache.org/jira/browse/SLING-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonio Sanso closed SLING-4883.
Extend content disposition filter protection to jcr:data
Key: SLING-4883
URL: https://issues.apache.org/jira/browse/SLING-4883
Project: Sling
Issue Type: Improvement
Components: Extensions
Reporter: Antonio Sanso
Assignee: Antonio Sanso
Fix For: Security 1.0.12
Attachments: SLING-4883-patch.txt
The current version of content disposition filter targets response content
type.
It would be nice to have a feature to also target forcing download of
{{jcr:data}} under configured paths
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[RESULT] [VOTE] Release Apache Sling Security 1.0.12
The vote is successful with three binding +1 votes and one non binding +1 vote regards antonio
[jira] [Created] (SLING-4965) Native Code Aliases not available in Sling
David Bosschaert created SLING-4965: --- Summary: Native Code Aliases not available in Sling Key: SLING-4965 URL: https://issues.apache.org/jira/browse/SLING-4965 Project: Sling Issue Type: Bug Components: Launchpad Affects Versions: Launchpad Base 2.6.2 Reporter: David Bosschaert The OSGi specifications define a number of aliases for native code OSes and processors: http://www.osgi.org/Specifications/Reference These aliases are defined by the Felix Framework in the default.properties. However they are not transferred to the sling.properties file which means they are not available for bundles running in Sling. The best thing to do would probable be to avoid overwriting the default.properties from Felix as it contains quite a lot of information for the framework and add any customizations separately. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4965) Native Code Aliases not available in Sling
[ https://issues.apache.org/jira/browse/SLING-4965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-4965: Fix Version/s: Launchpad Base 2.6.4 Native Code Aliases not available in Sling -- Key: SLING-4965 URL: https://issues.apache.org/jira/browse/SLING-4965 Project: Sling Issue Type: Bug Components: Launchpad Affects Versions: Launchpad Base 2.6.2 Reporter: David Bosschaert Fix For: Launchpad Base 2.6.4 The OSGi specifications define a number of aliases for native code OSes and processors: http://www.osgi.org/Specifications/Reference These aliases are defined by the Felix Framework in the default.properties. However they are not transferred to the sling.properties file which means they are not available for bundles running in Sling. The best thing to do would probable be to avoid overwriting the default.properties from Felix as it contains quite a lot of information for the framework and add any customizations separately. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (SLING-4965) Native Code Aliases not available in Sling
[ https://issues.apache.org/jira/browse/SLING-4965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-4965: --- Assignee: Carsten Ziegeler Native Code Aliases not available in Sling -- Key: SLING-4965 URL: https://issues.apache.org/jira/browse/SLING-4965 Project: Sling Issue Type: Bug Components: Launchpad Affects Versions: Launchpad Base 2.6.2 Reporter: David Bosschaert Assignee: Carsten Ziegeler Fix For: Launchpad Base 2.6.4 The OSGi specifications define a number of aliases for native code OSes and processors: http://www.osgi.org/Specifications/Reference These aliases are defined by the Felix Framework in the default.properties. However they are not transferred to the sling.properties file which means they are not available for bundles running in Sling. The best thing to do would probable be to avoid overwriting the default.properties from Felix as it contains quite a lot of information for the framework and add any customizations separately. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4941) JMX-configurable OK/NOK-Check for testing purposes
[ https://issues.apache.org/jira/browse/SLING-4941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Georg Henzler updated SLING-4941: - Attachment: JMX-adjustable-HC-for-testing.png [~npeltier] See attached screenshot on how this patch would allow you to dynamically add a WARN/CRITICAL health check result for given tags. reset() removes the test check again. Would this fulfil your requirement? JMX-configurable OK/NOK-Check for testing purposes -- Key: SLING-4941 URL: https://issues.apache.org/jira/browse/SLING-4941 Project: Sling Issue Type: New Feature Components: Health Check Reporter: Georg Henzler Attachments: JMX-adjustable-HC-for-testing.png, SLING-4941-JMX-adjustable-HC.patch For testing purposes (infrastructure tests with load balancers etc.) it can be useful to make the result for a given tag(s) fail manually. There are two options: # provide a check that is configurable via JCR (using metatype configuration). # provide a check that can be dynamically added via JMX The second options is IMHO nicer, because it's easier to run a JMX operation (compared to adding/changing a configuration in JCR). Also if this feature is not being used, it should not clutter the list of available health checks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (SLING-3966) ErrorAwareQueueDistributionStrategy should be implemented as an ImporterDistributionStrategy
[ https://issues.apache.org/jira/browse/SLING-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marius Petria reassigned SLING-3966: Assignee: Marius Petria (was: Tommaso Teofili) ErrorAwareQueueDistributionStrategy should be implemented as an ImporterDistributionStrategy Key: SLING-3966 URL: https://issues.apache.org/jira/browse/SLING-3966 Project: Sling Issue Type: Improvement Components: Distribution Reporter: Marius Petria Assignee: Marius Petria Treating replication errors should be done right after the import not when package queuing is done. Hence we might need to define a different extension point (ImporterDistributionStrategy) and treat the error at that place. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-3966) ErrorAwareQueueDistributionStrategy should be implemented as an ImporterDistributionStrategy
[ https://issues.apache.org/jira/browse/SLING-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marius Petria resolved SLING-3966. -- Resolution: Fixed Fix Version/s: Content Distribution Core 0.1.8 Committed revision 1697652. Implemented a way to configure the errorqueuestrategy after the import fails a certain number of times. ErrorAwareQueueDistributionStrategy should be implemented as an ImporterDistributionStrategy Key: SLING-3966 URL: https://issues.apache.org/jira/browse/SLING-3966 Project: Sling Issue Type: Improvement Components: Distribution Reporter: Marius Petria Assignee: Marius Petria Fix For: Content Distribution Core 0.1.8 Treating replication errors should be done right after the import not when package queuing is done. Hence we might need to define a different extension point (ImporterDistributionStrategy) and treat the error at that place. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SLING-4825) Add ability to handle webdav based DELETE requests
[ https://issues.apache.org/jira/browse/SLING-4825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14706447#comment-14706447 ] Satya Deep Maheshwari edited comment on SLING-4825 at 8/25/15 11:04 AM: Handler support for webdav DELETE requests is now released in jackrabbit version 2.11.0 . So I think we are now good to incorporate the proposed changes in sling. I am attaching a consolidated patch containing all the changes in sling to leverage this support. The patch also contains the integration-tests for testing this enhancement. Please review. was (Author: satyadeep): Handler support for webdav DELETE requests is now released in jackrabbit version 2.11.0 . So I think we are now good to incorporate the proposed changes in sling. I am attaching a consolidated patch containing all the changes in sling to leverage this support. The patch also contains the integration-tests for testing this enhancement. Please review. Add ability to handle webdav based DELETE requests -- Key: SLING-4825 URL: https://issues.apache.org/jira/browse/SLING-4825 Project: Sling Issue Type: Improvement Components: JCR Reporter: Satya Deep Maheshwari Attachments: SLING-4825.patch Recently 'delete handler' was added in jackrabbit. This provides the ability to add handlers for handling webdav based 'delete' requests. See JCR-3884 containing details on this feature. Earlier this ability was just available for other webdav operations like to copy/move etc. but was missing for 'delete' . Sling has written its own managers to keep track of these handlers. See [1] which has pre-existing handler managers like SlingCopyMoveManager. The intent of this jira issue is to add a delete handler manager so that the delete handler functionality can now be leveraged in Sling. [1] - https://github.com/apache/sling/tree/trunk/bundles/jcr/webdav/src/main/java/org/apache/sling/jcr/webdav/impl/handler -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4966) Use default properties from Felix framework
Carsten Ziegeler created SLING-4966: --- Summary: Use default properties from Felix framework Key: SLING-4966 URL: https://issues.apache.org/jira/browse/SLING-4966 Project: Sling Issue Type: Improvement Components: Launchpad Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Launchpad Base 2.6.4 Sling is currently not using the default.properties from the Felix framework. This requires to always sync any change in these properties in Sling when upgrading to a new framework version. SLING-4965 shows that this is error prone and should be avoided. We should therefore simply use the default properties from Felix and overlay them with the Sling properties -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4966) Use default properties from Felix framework
[ https://issues.apache.org/jira/browse/SLING-4966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-4966. - Resolution: Fixed Implemented in rev 1697662 by including the default.properties and loading them in SlingFelix. As we're using a different set of packages for the jre (excluding activation, transaction and xml stuff), we still have to keep this copy. We're also using a complicated setup for the system packages, so we need to keep the copy as well. But now we're doing to copying/checking two properties when upgrading Use default properties from Felix framework --- Key: SLING-4966 URL: https://issues.apache.org/jira/browse/SLING-4966 Project: Sling Issue Type: Improvement Components: Launchpad Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Launchpad Base 2.6.4 Sling is currently not using the default.properties from the Felix framework. This requires to always sync any change in these properties in Sling when upgrading to a new framework version. SLING-4965 shows that this is error prone and should be avoided. We should therefore simply use the default properties from Felix and overlay them with the Sling properties -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4965) Native Code Aliases not available in Sling
[ https://issues.apache.org/jira/browse/SLING-4965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-4965. - Resolution: Fixed This should be fixed with SLING-4966 Native Code Aliases not available in Sling -- Key: SLING-4965 URL: https://issues.apache.org/jira/browse/SLING-4965 Project: Sling Issue Type: Bug Components: Launchpad Affects Versions: Launchpad Base 2.6.2 Reporter: David Bosschaert Assignee: Carsten Ziegeler Fix For: Launchpad Base 2.6.4 The OSGi specifications define a number of aliases for native code OSes and processors: http://www.osgi.org/Specifications/Reference These aliases are defined by the Felix Framework in the default.properties. However they are not transferred to the sling.properties file which means they are not available for bundles running in Sling. The best thing to do would probable be to avoid overwriting the default.properties from Felix as it contains quite a lot of information for the framework and add any customizations separately. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
