[jira] [Commented] (SLING-8793) Content Distribution Core doesn't build with java 11

[Tommaso Teofili (Jira)]

[ 
https://issues.apache.org/jira/browse/SLING-8793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16957666#comment-16957666
 ] 

Tommaso Teofili commented on SLING-8793:


are there recommended guidelines for migrating annotations and related plugins 
we should follow ?

> Content Distribution Core doesn't build with java 11
> 
>
> Key: SLING-8793
> URL: https://issues.apache.org/jira/browse/SLING-8793
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>        Reporter: Tommaso Teofili
>Priority: Minor
>
> When running _mvn clean install_ on _org.apache.sling.distribution.core_ I 
> get a build failure like the following:
> {noformat}
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 01:07 min
> [INFO] Finished at: 2019-10-21T13:28:53+02:00
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-enforcer-plugin:1.4.1:enforce (enforce-java) 
> on project org.apache.sling.distribution.core: Execution enforce-java of goal 
> org.apache.maven.plugins:maven-enforcer-plugin:1.4.1:enforce failed: An API 
> incompatibility was encountered while executing 
> org.apache.maven.plugins:maven-enforcer-plugin:1.4.1:enforce: 
> java.lang.ExceptionInInitializerError: null
> [ERROR] -
> [ERROR] realm =plugin>org.apache.maven.plugins:maven-enforcer-plugin:1.4.1
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] = 
> file:/Users/teofili/.m2/repository/org/apache/maven/plugins/maven-enforcer-plugin/1.4.1/maven-enforcer-plugin-1.4.1.jar
> [ERROR] urls[1] = 
> file:/Users/teofili/.m2/repository/backport-util-concurrent/backport-util-concurrent/3.1/backport-util-concurrent-3.1.jar
> [ERROR] urls[2] = 
> file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.11/plexus-interpolation-1.11.jar
> [ERROR] urls[3] = 
> file:/Users/teofili/.m2/repository/org/slf4j/slf4j-jdk14/1.5.6/slf4j-jdk14-1.5.6.jar
> [ERROR] urls[4] = 
> file:/Users/teofili/.m2/repository/org/slf4j/jcl-over-slf4j/1.5.6/jcl-over-slf4j-1.5.6.jar
> [ERROR] urls[5] = 
> file:/Users/teofili/.m2/repository/org/apache/maven/reporting/maven-reporting-api/2.2.1/maven-reporting-api-2.2.1.jar
> [ERROR] urls[6] = 
> file:/Users/teofili/.m2/repository/org/apache/maven/doxia/doxia-sink-api/1.1/doxia-sink-api-1.1.jar
> [ERROR] urls[7] = 
> file:/Users/teofili/.m2/repository/org/apache/maven/doxia/doxia-logging-api/1.1/doxia-logging-api-1.1.jar
> [ERROR] urls[8] = 
> file:/Users/teofili/.m2/repository/commons-cli/commons-cli/1.2/commons-cli-1.2.jar
> [ERROR] urls[9] = 
> file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.jar
> [ERROR] urls[10] = 
> file:/Users/teofili/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
> [ERROR] urls[11] = 
> file:/Users/teofili/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
> [ERROR] urls[12] = 
> file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-utils/3.0.22/plexus-utils-3.0.22.jar
> [ERROR] urls[13] = 
> file:/Users/teofili/.m2/repository/commons-lang/commons-lang/2.3/commons-lang-2.3.jar
> [ERROR] urls[14] = 
> file:/Users/teofili/.m2/repository/org/apache/maven/enforcer/enforcer-api/1.4.1/enforcer-api-1.4.1.jar
> [ERROR] urls[15] = 
> file:/Users/teofili/.m2/repository/org/apache/maven/enforcer/enforcer-rules/1.4.1/enforcer-rules-1.4.1.jar
> [ERROR] urls[16] = 
> file:/Users/teofili/.m2/repository/org/apache/maven/shared/maven-common-artifact-filters/1.4/maven-common-artifact-filters-1.4.jar
> [ERROR] urls[17] = 
> file:/Users/teofili/.m2/repository/org/beanshell/bsh/2.0b4/bsh-2.0b4.jar
> [ERROR] urls[18] = 
> file:/Users/teofili/.m2/repository/org/apache/maven/shared/maven-dependency-tree/2.2/maven-dependency-tree-2.2.jar
> [ERROR] urls[19] = 
> file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
> [ERROR] urls[20] = 
> file:/Users/teofili/.m2/repository/org/eclipse/aether/aether-util/0.9.0.M2/aether-util-0.9.0.M2.jar
> [ERROR] urls[21] = 
> file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-i18n/1.0-beta-6/plexus-i18n-1.0-beta-6.jar
> [ERROR] urls[22] = 
> file:/Users/teofili/.m2/repository/org/apache/maven/plugin-testing/maven-plugin-testing-harness/1.3/mave

[jira] [Resolved] (SLING-8797) Static analysis improvements on Journal code

[Tommaso Teofili (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-8797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili resolved SLING-8797.

  Assignee: Tommaso Teofili
Resolution: Fixed

> Static analysis improvements on Journal code
> 
>
> Key: SLING-8797
> URL: https://issues.apache.org/jira/browse/SLING-8797
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>        Reporter: Tommaso Teofili
>    Assignee: Tommaso Teofili
>Priority: Minor
> Fix For: Content Distribution Journal Core 0.1.6
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> In order to get up to speed with SCD Journal I am going through the codebase. 
> While doing this I also run some static analysis and would like to include a 
> few minor improvements, mostly related to javadoc, log statements, etc.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (SLING-8797) Static analysis improvements on Journal code

[Tommaso Teofili (Jira)]

Tommaso Teofili created SLING-8797:
--

 Summary: Static analysis improvements on Journal code
 Key: SLING-8797
 URL: https://issues.apache.org/jira/browse/SLING-8797
 Project: Sling
  Issue Type: Bug
  Components: Content Distribution
Reporter: Tommaso Teofili
 Fix For: Content Distribution Journal Core 0.1.6


In order to get up to speed with SCD Journal I am going through the codebase. 
While doing this I also run some static analysis and would like to include a 
few minor improvements, mostly related to javadoc, log statements, etc.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SLING-8793) Content Distribution Core doesn't build with java 11

[Tommaso Teofili (Jira)]

[ 
https://issues.apache.org/jira/browse/SLING-8793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16956026#comment-16956026
 ] 

Tommaso Teofili commented on SLING-8793:


thanks Robert.
It seems that to fix this we need to upgrade to a more recent parent release 
which, in turn, requires upgrading from Felix SCR to OSGi annotations.

> Content Distribution Core doesn't build with java 11
> 
>
> Key: SLING-8793
> URL: https://issues.apache.org/jira/browse/SLING-8793
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>        Reporter: Tommaso Teofili
>Priority: Minor
>
> When running _mvn clean install_ on _org.apache.sling.distribution.core_ I 
> get a build failure like the following:
> {noformat}
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 01:07 min
> [INFO] Finished at: 2019-10-21T13:28:53+02:00
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-enforcer-plugin:1.4.1:enforce (enforce-java) 
> on project org.apache.sling.distribution.core: Execution enforce-java of goal 
> org.apache.maven.plugins:maven-enforcer-plugin:1.4.1:enforce failed: An API 
> incompatibility was encountered while executing 
> org.apache.maven.plugins:maven-enforcer-plugin:1.4.1:enforce: 
> java.lang.ExceptionInInitializerError: null
> [ERROR] -
> [ERROR] realm =plugin>org.apache.maven.plugins:maven-enforcer-plugin:1.4.1
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] = 
> file:/Users/teofili/.m2/repository/org/apache/maven/plugins/maven-enforcer-plugin/1.4.1/maven-enforcer-plugin-1.4.1.jar
> [ERROR] urls[1] = 
> file:/Users/teofili/.m2/repository/backport-util-concurrent/backport-util-concurrent/3.1/backport-util-concurrent-3.1.jar
> [ERROR] urls[2] = 
> file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.11/plexus-interpolation-1.11.jar
> [ERROR] urls[3] = 
> file:/Users/teofili/.m2/repository/org/slf4j/slf4j-jdk14/1.5.6/slf4j-jdk14-1.5.6.jar
> [ERROR] urls[4] = 
> file:/Users/teofili/.m2/repository/org/slf4j/jcl-over-slf4j/1.5.6/jcl-over-slf4j-1.5.6.jar
> [ERROR] urls[5] = 
> file:/Users/teofili/.m2/repository/org/apache/maven/reporting/maven-reporting-api/2.2.1/maven-reporting-api-2.2.1.jar
> [ERROR] urls[6] = 
> file:/Users/teofili/.m2/repository/org/apache/maven/doxia/doxia-sink-api/1.1/doxia-sink-api-1.1.jar
> [ERROR] urls[7] = 
> file:/Users/teofili/.m2/repository/org/apache/maven/doxia/doxia-logging-api/1.1/doxia-logging-api-1.1.jar
> [ERROR] urls[8] = 
> file:/Users/teofili/.m2/repository/commons-cli/commons-cli/1.2/commons-cli-1.2.jar
> [ERROR] urls[9] = 
> file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.jar
> [ERROR] urls[10] = 
> file:/Users/teofili/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
> [ERROR] urls[11] = 
> file:/Users/teofili/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
> [ERROR] urls[12] = 
> file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-utils/3.0.22/plexus-utils-3.0.22.jar
> [ERROR] urls[13] = 
> file:/Users/teofili/.m2/repository/commons-lang/commons-lang/2.3/commons-lang-2.3.jar
> [ERROR] urls[14] = 
> file:/Users/teofili/.m2/repository/org/apache/maven/enforcer/enforcer-api/1.4.1/enforcer-api-1.4.1.jar
> [ERROR] urls[15] = 
> file:/Users/teofili/.m2/repository/org/apache/maven/enforcer/enforcer-rules/1.4.1/enforcer-rules-1.4.1.jar
> [ERROR] urls[16] = 
> file:/Users/teofili/.m2/repository/org/apache/maven/shared/maven-common-artifact-filters/1.4/maven-common-artifact-filters-1.4.jar
> [ERROR] urls[17] = 
> file:/Users/teofili/.m2/repository/org/beanshell/bsh/2.0b4/bsh-2.0b4.jar
> [ERROR] urls[18] = 
> file:/Users/teofili/.m2/repository/org/apache/maven/shared/maven-dependency-tree/2.2/maven-dependency-tree-2.2.jar
> [ERROR] urls[19] = 
> file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
> [ERROR] urls[20] = 
> file:/Users/teofili/.m2/repository/org/eclipse/aether/aether-util/0.9.0.M2/aether-util-0.9.0.M2.jar
> [ERROR] urls[21] = 
> file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-i18n/1.0-beta-6/plexus-i18n-1.0-beta-6.jar
> [ERROR] urls[22] = 
> file:/Users/teofili/.m2/repository

[jira] [Created] (SLING-8793) Content Distribution Core doesn't build with java 11

[Tommaso Teofili (Jira)]

Tommaso Teofili created SLING-8793:
--

 Summary: Content Distribution Core doesn't build with java 11
 Key: SLING-8793
 URL: https://issues.apache.org/jira/browse/SLING-8793
 Project: Sling
  Issue Type: Bug
  Components: Content Distribution
Reporter: Tommaso Teofili


When running _mvn clean install_ on _org.apache.sling.distribution.core_ I get 
a build failure like the following:
{noformat}
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 01:07 min
[INFO] Finished at: 2019-10-21T13:28:53+02:00
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-enforcer-plugin:1.4.1:enforce (enforce-java) on 
project org.apache.sling.distribution.core: Execution enforce-java of goal 
org.apache.maven.plugins:maven-enforcer-plugin:1.4.1:enforce failed: An API 
incompatibility was encountered while executing 
org.apache.maven.plugins:maven-enforcer-plugin:1.4.1:enforce: 
java.lang.ExceptionInInitializerError: null
[ERROR] -
[ERROR] realm =plugin>org.apache.maven.plugins:maven-enforcer-plugin:1.4.1
[ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] = 
file:/Users/teofili/.m2/repository/org/apache/maven/plugins/maven-enforcer-plugin/1.4.1/maven-enforcer-plugin-1.4.1.jar
[ERROR] urls[1] = 
file:/Users/teofili/.m2/repository/backport-util-concurrent/backport-util-concurrent/3.1/backport-util-concurrent-3.1.jar
[ERROR] urls[2] = 
file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.11/plexus-interpolation-1.11.jar
[ERROR] urls[3] = 
file:/Users/teofili/.m2/repository/org/slf4j/slf4j-jdk14/1.5.6/slf4j-jdk14-1.5.6.jar
[ERROR] urls[4] = 
file:/Users/teofili/.m2/repository/org/slf4j/jcl-over-slf4j/1.5.6/jcl-over-slf4j-1.5.6.jar
[ERROR] urls[5] = 
file:/Users/teofili/.m2/repository/org/apache/maven/reporting/maven-reporting-api/2.2.1/maven-reporting-api-2.2.1.jar
[ERROR] urls[6] = 
file:/Users/teofili/.m2/repository/org/apache/maven/doxia/doxia-sink-api/1.1/doxia-sink-api-1.1.jar
[ERROR] urls[7] = 
file:/Users/teofili/.m2/repository/org/apache/maven/doxia/doxia-logging-api/1.1/doxia-logging-api-1.1.jar
[ERROR] urls[8] = 
file:/Users/teofili/.m2/repository/commons-cli/commons-cli/1.2/commons-cli-1.2.jar
[ERROR] urls[9] = 
file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.jar
[ERROR] urls[10] = 
file:/Users/teofili/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
[ERROR] urls[11] = 
file:/Users/teofili/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
[ERROR] urls[12] = 
file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-utils/3.0.22/plexus-utils-3.0.22.jar
[ERROR] urls[13] = 
file:/Users/teofili/.m2/repository/commons-lang/commons-lang/2.3/commons-lang-2.3.jar
[ERROR] urls[14] = 
file:/Users/teofili/.m2/repository/org/apache/maven/enforcer/enforcer-api/1.4.1/enforcer-api-1.4.1.jar
[ERROR] urls[15] = 
file:/Users/teofili/.m2/repository/org/apache/maven/enforcer/enforcer-rules/1.4.1/enforcer-rules-1.4.1.jar
[ERROR] urls[16] = 
file:/Users/teofili/.m2/repository/org/apache/maven/shared/maven-common-artifact-filters/1.4/maven-common-artifact-filters-1.4.jar
[ERROR] urls[17] = 
file:/Users/teofili/.m2/repository/org/beanshell/bsh/2.0b4/bsh-2.0b4.jar
[ERROR] urls[18] = 
file:/Users/teofili/.m2/repository/org/apache/maven/shared/maven-dependency-tree/2.2/maven-dependency-tree-2.2.jar
[ERROR] urls[19] = 
file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
[ERROR] urls[20] = 
file:/Users/teofili/.m2/repository/org/eclipse/aether/aether-util/0.9.0.M2/aether-util-0.9.0.M2.jar
[ERROR] urls[21] = 
file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-i18n/1.0-beta-6/plexus-i18n-1.0-beta-6.jar
[ERROR] urls[22] = 
file:/Users/teofili/.m2/repository/org/apache/maven/plugin-testing/maven-plugin-testing-harness/1.3/maven-plugin-testing-harness-1.3.jar
[ERROR] urls[23] = 
file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-archiver/2.2/plexus-archiver-2.2.jar
[ERROR] urls[24] = 
file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-io/2.0.4/plexus-io-2.0.4.jar
[ERROR] urls[25] = 
file:/Users/teofili/.m2/repository/junit/junit/4.11/junit-4.11.jar
[ERROR] urls[26] = 
file:/Users/teofili/.m2/repository/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar
[ERROR] Number of foreign imports: 1
[ERROR] import: Entry[import  from realm 
ClassRealm[project>org.apache.sling:org.apache.sling.distribution.core:0.4.1-SNAPSHOT,
 parent: ClassRealm[maven.api, parent: null]]]
[ERROR] 

[jira] [Commented] (SLING-8408) DistributionQueueHealthCheck should deal with failing queries

[Tommaso Teofili (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-8408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16837018#comment-16837018
 ] 

Tommaso Teofili commented on SLING-8408:


I think the suggested patch looks good, assuming an 
{{IllegalArgumentException}} can only be thrown when an index is not available.

> DistributionQueueHealthCheck should deal with failing queries
> -
>
> Key: SLING-8408
> URL: https://issues.apache.org/jira/browse/SLING-8408
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Thomas Mueller
>Priority: Major
>
> The following health check indirectly runs a queries which might fail:
>  * 
> [DistributionQueueHealthCheck|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/monitor/DistributionQueueHealthCheck.java]:
>  
> sling-org-apache-sling-distribution-core/src/main/java/org/apache/sling/distribution/monitor
> The call 
> [JobManagerImpl.findJobs|https://github.com/apache/sling-org-apache-sling-event/blob/master/src/main/java/org/apache/sling/event/impl/jobs/JobManagerImpl.java#L373],
>  which can throw an exception with SLING-8407, if the index is not yet 
> available. The health checks should catch this exception and return 
> HEALTH_CHECK_ERROR for this case.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (SLING-8345) IP clearance of Journal based Sling Content Distribution donation

[Tommaso Teofili (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-8345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810886#comment-16810886
 ] 

Tommaso Teofili edited comment on SLING-8345 at 4/5/19 2:27 PM:


for SCD, formerly Sling Replication, IIRC a CCLA for my employer was already in 
place and I already had a ICLA as well, in addition to that my employer issued 
a SGA [1].

Hope it helps [~rombert].

[1] : http://www.apache.org/licenses/software-grant.txt


was (Author: teofili):
for SCD formerly Sling Replication IIRC a CCLA for my employer was already in 
place and I already had a ICLA as well, in addition to that my employer issued 
a SGA [1].

Hope it helps [~rombert].

[1] : http://www.apache.org/licenses/software-grant.txt

> IP clearance of Journal based Sling Content Distribution donation
> -
>
> Key: SLING-8345
> URL: https://issues.apache.org/jira/browse/SLING-8345
> Project: Sling
>  Issue Type: Sub-task
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
>
> See http://incubator.apache.org/ip-clearance/
> Working page at 
> http://incubator.apache.org/ip-clearance/sling-distribution-journal.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-8345) IP clearance of Journal based Sling Content Distribution donation

[Tommaso Teofili (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-8345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810886#comment-16810886
 ] 

Tommaso Teofili commented on SLING-8345:


for SCD formerly Sling Replication IIRC a CCLA for my employer was already in 
place and I already had a ICLA as well, in addition to that my employer issued 
a SGA [1].

Hope it helps [~rombert].

[1] : http://www.apache.org/licenses/software-grant.txt

> IP clearance of Journal based Sling Content Distribution donation
> -
>
> Key: SLING-8345
> URL: https://issues.apache.org/jira/browse/SLING-8345
> Project: Sling
>  Issue Type: Sub-task
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
>
> See http://incubator.apache.org/ip-clearance/
> Working page at 
> http://incubator.apache.org/ip-clearance/sling-distribution-journal.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (SLING-6088) Distribution ITs fail on Jenkins

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili reassigned SLING-6088:
--

Assignee: (was: Tommaso Teofili)

> Distribution ITs fail on Jenkins
> 
>
> Key: SLING-6088
> URL: https://issues.apache.org/jira/browse/SLING-6088
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
> Environment: Jenkins
>Reporter: Robert Munteanu
>Priority: Major
>
> The tests give up after 60 seconds:
> {noformat}
> 60433 [main] INFO org.apache.sling.testing.tools.sling.SlingTestBase - Server 
> not ready after 60 seconds, giving up
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 60.479 sec 
> <<< FAILURE! - in 
> org.apache.sling.distribution.it.DistributionPackageExporterImporterTemporaryFoldersTest
> testAddExportImportTemp(org.apache.sling.distribution.it.DistributionPackageExporterImporterTemporaryFoldersTest)
>   Time elapsed: 0.006 sec  <<< FAILURE!
> java.lang.AssertionError: Server not ready after 60 seconds, giving up
>   at org.junit.Assert.fail(Assert.java:88)
>   at 
> org.apache.sling.testing.tools.sling.SlingTestBase.waitForServerReady(SlingTestBase.java:326)
>   at 
> org.apache.sling.testing.tools.sling.SlingTestBase.startServerIfNeeded(SlingTestBase.java:169)
>   at 
> org.apache.sling.testing.tools.sling.SlingTestBase.getServerBaseUrl(SlingTestBase.java:231)
>   at 
> org.apache.sling.distribution.it.DistributionIntegrationTestBase.init(DistributionIntegrationTestBase.java:87)
>   at 
> org.apache.sling.distribution.it.DistributionIntegrationTestBase.(DistributionIntegrationTestBase.java:63)
>   at 
> org.apache.sling.distribution.it.DistributionIntegrationTestBase.(DistributionIntegrationTestBase.java:59)
>   at 
> org.apache.sling.distribution.it.DistributionPackageExporterImporterTemporaryFoldersTest.(DistributionPackageExporterImporterTemporaryFoldersTest.java:36){noformat}
> The only relevant snippet that I can find in the logs is related to the 
> health check bundles:
> {noformat}01.10.2016 18:09:51.724 *ERROR* [FelixDispatchQueue] 
> org.apache.sling.hc.webconsole FrameworkEvent ERROR 
> (org.osgi.framework.BundleException: Unable to resolve 
> org.apache.sling.hc.webconsole [114](R 114.0): missing requirement 
> [org.apache.sling.hc.webconsole [114](R 114.0)] osgi.wiring.package; 
> (&(osgi.wiring.package=org.apache.sling.hc.api.execution)(version>=1.1.0)(!(version>=2.0.0)))
>  Unresolved requirements: [[org.apache.sling.hc.webconsole [114](R 114.0)] 
> osgi.wiring.package; 
> (&(osgi.wiring.package=org.apache.sling.hc.api.execution)(version>=1.1.0)(!(version>=2.0.0)))])
> org.osgi.framework.BundleException: Unable to resolve 
> org.apache.sling.hc.webconsole [114](R 114.0): missing requirement 
> [org.apache.sling.hc.webconsole [114](R 114.0)] osgi.wiring.package; 
> (&(osgi.wiring.package=org.apache.sling.hc.api.execution)(version>=1.1.0)(!(version>=2.0.0)))
>  Unresolved requirements: [[org.apache.sling.hc.webconsole [114](R 114.0)] 
> osgi.wiring.package; 
> (&(osgi.wiring.package=org.apache.sling.hc.api.execution)(version>=1.1.0)(!(version>=2.0.0)))]
>   at 
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4111)
>   at org.apache.felix.framework.Felix.startBundle(Felix.java:2117)
>   at 
> org.apache.felix.framework.Felix$RefreshHelper.restart(Felix.java:5063)
>   at org.apache.felix.framework.Felix.refreshPackages(Felix.java:4253)
>   at 
> org.apache.felix.framework.FrameworkWiringImpl.run(FrameworkWiringImpl.java:188)
>   at java.lang.Thread.run(Thread.java:745){noformat}
> but I'm not sure that this leads to the test failures.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (SLING-4075) Improve test coverage of SCD

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-4075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili reassigned SLING-4075:
--

Assignee: (was: Tommaso Teofili)

> Improve test coverage of SCD
> 
>
> Key: SLING-4075
> URL: https://issues.apache.org/jira/browse/SLING-4075
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>        Reporter: Tommaso Teofili
>Priority: Major
>
> Currently we moved lots of testing to the IT module but it'd be good to have 
> a better test coverage via unit testing in core module, at least to test 
> basic use cases and maybe some edge cases.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (SLING-6617) Improve dev-level documentation for SCD

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili reassigned SLING-6617:
--

Assignee: (was: Tommaso Teofili)

> Improve dev-level documentation for SCD
> ---
>
> Key: SLING-6617
> URL: https://issues.apache.org/jira/browse/SLING-6617
> Project: Sling
>  Issue Type: Task
>  Components: Content Distribution
>        Reporter: Tommaso Teofili
>Priority: Major
>
> It'd be nice to have a good technical documentation about SCD.
> While on one hand [1] should cover user level documentation, it would be 
> useful for developers to have a more technical one, that should be placed 
> near to the code [2] and expanded to reflect recent changes.
> [1] : http://sling.apache.org/documentation/bundles/content-distribution.html
> [2] : 
> https://github.com/apache/sling/blob/trunk/contrib/extensions/distribution/README.md



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (SLING-4776) Document how to create system user for loginService

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-4776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili reassigned SLING-4776:
--

Assignee: (was: Tommaso Teofili)

> Document how to create system user for loginService
> ---
>
> Key: SLING-4776
> URL: https://issues.apache.org/jira/browse/SLING-4776
> Project: Sling
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Alex COLLIGNON
>Priority: Major
>
> The Service Authentication documentation [0] describes the API.
> We now need to describe how to create and ship the service user along with 
> the services.
> [0] 
> https://sling.apache.org/documentation/the-sling-engine/service-authentication.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (SLING-4148) Put JCR dependent components into a distribution.jcr bundle

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-4148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili reassigned SLING-4148:
--

Assignee: (was: Tommaso Teofili)

> Put JCR dependent components into a distribution.jcr bundle
> ---
>
> Key: SLING-4148
> URL: https://issues.apache.org/jira/browse/SLING-4148
> Project: Sling
>  Issue Type: Task
>  Components: Content Distribution
>        Reporter: Tommaso Teofili
>Priority: Major
>
> Some components (triggers, serialization, etc.) in 
> _org.apache.sling.distribution.core_ are JCR dependent, meaning that they 
> will only work if Sling is backed by JCR, so they should be put in a separate 
> _org.apache.sling.distribution.jcr_ bundle.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (SLING-6211) Clarify AbstractJcrEventTrigger request addition strategy

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili reassigned SLING-6211:
--

Assignee: (was: Tommaso Teofili)

> Clarify AbstractJcrEventTrigger request addition strategy
> -
>
> Key: SLING-6211
> URL: https://issues.apache.org/jira/browse/SLING-6211
> Project: Sling
>  Issue Type: Task
>  Components: Content Distribution
>        Reporter: Tommaso Teofili
>Priority: Major
>
> We should clarify the logic behind 
> [AbstractJcrEventListener#addToList|https://github.com/apache/sling/blob/trunk/contrib/extensions/distribution/core/src/main/java/org/apache/sling/distribution/trigger/impl/AbstractJcrEventTrigger.java#L150]
>  as that the addition mechanism seems to rely on the last request added, 
> which seems wrong as events may come in in an unsorted manner (not consistent 
> with the order the changes they refer to were done).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (SLING-5916) Remove all usages of jobManager.findJobs in SCD

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili reassigned SLING-5916:
--

Assignee: (was: Tommaso Teofili)

> Remove all usages of jobManager.findJobs in SCD
> ---
>
> Key: SLING-5916
> URL: https://issues.apache.org/jira/browse/SLING-5916
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>        Reporter: Tommaso Teofili
>Priority: Major
>
> Given the latest discussions on the Sling dev@ list it'd be good to stop 
> using {{JobManager#findJobs}} API at all in the SCD code (for the jobs based 
> queues).
> This would require either accepting queues cannot be inspected in detail 
> (which / how many items there are in each queue) or rely on different 
> constructs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [PROPOSAL] Donating a tool able to generate markdown documentation from annotations

[Tommaso Teofili]

Thanks Simo,

I think the idea is very interesting!
When browsing source code, especially on github, that should help people
better understand what components / services / etc. are doing.
Being Sling a big project I think this is especially useful when browsing
through portions of the code / bundles you are not using / developing
frequently.

My 2 cents,
Tommaso


Il giorno mar 31 lug 2018 alle ore 17:10 Robert Munteanu 
ha scritto:

> Hi Simo,
>
> On Tue, 2018-07-31 at 14:06 +0200, Simone Tripodi wrote:
> > Hi all,
> > due to a private need I implemented a tool that, as a Sling
> > committer, I
> > would like to promote inside this community in order to have it as a
> > public
> > domain.
> >
> > The basic idea is to automate the production of documentation,
> > providing to
> > both developers and customers a centralised documentation of all HTTP
> > entry
> > points and Metatype configurations.
>
> This looks nice, thanks for bringing it up for discussion. I think we
> could use a tool to enhance documentation for Sling.
>
> A couple of notes/questions:
>
> 1. The sample markdown output is wrapped, it would be more useful if
> attached as a plain-text file.
>
> 2. Is there any support for removing certain classes or properties from
> the output? I can see situations where we don't want to expose
> something, based on whether it's deprecated or internal.
>
> 3. Is there support (or planned support) for adding additional data to
> the output? I think a plain descriptive output for a certain component
> is good, but it might be useful to complement it with other
> information, such as a free-text description.
>
> 4. Does this tool depend on Sling in any matter? Briefly looking over
> your email it looks like it builds on top of the OSGi annotations ( +
> Felix/Sling specific ones ) so it could also potentially find a home in
> the Felix project.
>
> Thanks!
>
> Robert
>
>

Re: [ANN] New committer: David Bosschaert

[Tommaso Teofili]

welcome David, well deserved!

Il giorno ven 9 mar 2018 alle ore 14:43 Antonio Sanso
 ha scritto:

> +1
> On Mar 9, 2018, at 12:52 PM, Stefan Seifert 
> wrote:
>
> > welcome david!
> >
> > stefan
> >
> >> -Original Message-
> >> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> >> Sent: Friday, March 9, 2018 10:36 AM
> >> To: Sling Developers
> >> Subject: [ANN] New committer: David Bosschaert
> >>
> >> The Project Management Committee (PMC) for Apache Sling
> >> has invited David Bosschaert to become a committer and we are pleased
> >> to announce that he has accepted.
> >>
> >> Please welcome David.
> >>
> >> David, you might want to introduce yourself.
> >>
> >> Being a committer enables easier contribution to the
> >> project since there is no need to go via the patch
> >> submission process. This should enable better productivity.
> >> Being a PMC member enables assistance with the management
> >> and to guide the direction of the project.
> >>
> >> Regards
> >> Carsten
> >> --
> >> Carsten Ziegeler
> >> Adobe Research Switzerland
> >> cziege...@apache.org
> >
>
>

[jira] [Commented] (SLING-7468) Allow to configure the Distribution Resource Provider

[Tommaso Teofili (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16351293#comment-16351293
 ] 

Tommaso Teofili commented on SLING-7468:


big +1 on my side as well, and btw I would opt for configuration-less (figure 
out mappings at runtime).

> Allow to configure the Distribution Resource Provider
> -
>
> Key: SLING-7468
> URL: https://issues.apache.org/jira/browse/SLING-7468
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
>
> SCD maintain its own Resource Provider
> https://github.com/apache/sling-org-apache-sling-distribution-core/tree/master/src/main/java/org/apache/sling/distribution/resources
> The implementation maps OSGI configurations and services as sling resources.
> The implementation is not flexible to allow plugging a custom agent in the 
> resource tree.
> The mapping seems to be done currently in enums, for instance
> https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/component/impl/DistributionComponentKind.java
> This issue is about making the configuration flexible (OSGI properties) or 
> even configuration-less (figure out the mappings at runtime). As a side 
> effect, the implementation may be simplified. 
> [~teofili],[~simone.tripodi] FYI



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7168) Allow to implement custom distribution agents/queues

[Tommaso Teofili (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350573#comment-16350573
 ] 

Tommaso Teofili commented on SLING-7168:


+1 sounds good to me.

> Allow to implement custom distribution agents/queues
> 
>
> Key: SLING-7168
> URL: https://issues.apache.org/jira/browse/SLING-7168
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.8
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Core 0.2.12, Content Distribution 
> API 0.4.0
>
>
> Currently, it is not possible to implements distribution agents and queues, 
> implemented in another bundle than the {{org.apache.sling.distribution.core}} 
> bundle.
> Implementing a custom distribution agent outside of the 
> {{org.apache.sling.distribution.core}} bundle is useful when leveraging an 
> ad-hoc communication layer.
> This issue is about allowing to plug an external distribution agent/queue 
> provided via a separate bundle.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Sling to Solr integration using Sling Content Distribution

[Tommaso Teofili]

thanks Dirk, I'm going to review the PR in the next days.

Regards,
Tommaso

Il giorno mer 17 gen 2018 alle ore 14:58 Dirk Rudolph <
dirk.rudo...@netcentric.biz> ha scritto:

> Hey.
>
> I opened a PR for SLING-7364, the missing piece making SCD compatible with
> solr out of the box:
>
> https://github.com/apache/sling-org-apache-sling-distribution-core/pull/6
> <https://github.com/apache/sling-org-apache-sling-distribution-core/pull/6
> >
>
> Beside of that I created an API to create solr documents from resources
> for serialisation here:
>
>
> https://github.com/Buuhuu/sling-content-distribution-solr/tree/master/sling-content-distribution-solr-bundle/src/main/java/com/github/buuhuu/sling/distribution/solr/documents
> <
> https://github.com/Buuhuu/sling-content-distribution-solr/tree/master/sling-content-distribution-solr-bundle/src/main/java/com/github/buuhuu/sling/distribution/solr/documents
> >
>
> With a sample implementation using Adobes AEM Sample “we retail” here:
>
>
> https://github.com/Buuhuu/sling-content-distribution-solr/tree/master/sling-content-distribution-solr-weretail
> <
> https://github.com/Buuhuu/sling-content-distribution-solr/tree/master/sling-content-distribution-solr-weretail
> >
>
> Let me know what you think.
>
> /Dirk
>
> > On 11 Jan 2018, at 15:38, Dirk Rudolph <dirk.rudo...@netcentric.biz>
> wrote:
> >
> > Many thanks for the positive Feedback.
> >
> > The last thing missing to make it work ootb with solr is SLING-7364. I
> added a some thoughts to it. Option 1) is instead of sending the package
> info as binary header prepended to the request’s body, sending them as http
> headers. As the overall size of http headers is limited this would require
> SLING-3967 to be implemented. Another feasible and probably the more simple
> solutions for now is 3) omitting the package info if the agent is
> configured to so. Wdyt?
> >
> > I will keep working on defining an API for the documents to export of
> solr. From my experience with AEM the following approach comes to my mind:
> >
> > For each Resource:
> >
> > 1. Adapt to SolrFieldsIterator, iterating over SolrField (name, value)
> > 2. If not null, add each SolrField to the document and done
> > 3. If null, adapt to SolrFields, a marker interface that can be used
> together with any (existing) model, that has getters annotated with
> @SolrField.
> > 4. If not null add each @SolrField getter to the document and done
> > 5. If null, log and skip
> >
> > About step 1) Thinking about cq:Page or dam:Asset in AEM, or anything
> Resource that should be exported as an aggregate of child resources. The
> SolrFieldsIterator implementation would traverse and itself adapt each
> resource to SolrFields to do the same as step 3).
> >
> > This would be done as a service so it could be replaced by any other
> implementation, like a simple property=>field mapping.
> >
> > Thoughts?
> >
> >> On 10 Jan 2018, at 10:59, Tommaso Teofili <tommaso.teof...@gmail.com>
> wrote:
> >>
> >> +1
> >>
> >> thanks a lot Dirk for your contributions (4 PRs so far!). This sounds
> like
> >> a very interesting use case for Sling and SCD.
> >>
> >> Regards,
> >> Tommaso
> >>
> >>
> >>
> >> Il giorno mar 9 gen 2018 alle ore 02:22 Daniel Klco <
> daniel.k...@gmail.com>
> >> ha scritto:
> >>
> >>> This is a great idea! I could see this as a use case for a number of
> >>> different integrations and an example would be very helpful for anyone
> >>> looking to do this.
> >>>
> >>> On Mon, Jan 8, 2018 at 1:44 PM, Stefan Seifert <sseif...@pro-vision.de
> >
> >>> wrote:
> >>>
> >>>> hello dirk.
> >>>>
> >>>> i think such a feature would be very useful. integration of an
> external
> >>>> search engine on a "higher level" than the oak-level search
> integration
> >>> is
> >>>> a common use case in our projects as well. it's important to be quite
> >>>> flexible what is indexed and what not and how it's indexed - for best
> >>> match
> >>>> of the business requirements and the special features of the targeted
> >>>> search engine.
> >>>>
> >>>> stefan
> >>>>
> >>>>> -Original Message-
> >>>>> From: Dirk Rudolph [mailto:dirk.rudo...@netcentric.biz]
> >>>>> Sent: Monday, January 8, 201

Re: Sling to Solr integration using Sling Content Distribution

[Tommaso Teofili]

+1

thanks a lot Dirk for your contributions (4 PRs so far!). This sounds like
a very interesting use case for Sling and SCD.

Regards,
Tommaso



Il giorno mar 9 gen 2018 alle ore 02:22 Daniel Klco 
ha scritto:

> This is a great idea! I could see this as a use case for a number of
> different integrations and an example would be very helpful for anyone
> looking to do this.
>
> On Mon, Jan 8, 2018 at 1:44 PM, Stefan Seifert 
> wrote:
>
> > hello dirk.
> >
> > i think such a feature would be very useful. integration of an external
> > search engine on a "higher level" than the oak-level search integration
> is
> > a common use case in our projects as well. it's important to be quite
> > flexible what is indexed and what not and how it's indexed - for best
> match
> > of the business requirements and the special features of the targeted
> > search engine.
> >
> > stefan
> >
> > >-Original Message-
> > >From: Dirk Rudolph [mailto:dirk.rudo...@netcentric.biz]
> > >Sent: Monday, January 8, 2018 4:45 PM
> > >To: dev@sling.apache.org
> > >Subject: Sling to Solr integration using Sling Content Distribution
> > >
> > >Hi devs,
> > >
> > >Recently I was evaluating if it is easily possible to integrate Sling
> into
> > >Solr using Sling Content Distributions and made some great progress
> here:
> > >
> > >https://github.com/Buuhuu/sling-content-distribution-solr
> > >
> > >
> > >The repository explains the goal, the why and who also giving
> instructions
> > >on how to use it. To sum it up a bit:
> > >
> > >- SCD’s features map perfectly fine to the requirements when integrating
> > >into solr
> > >- It enables us to ingest content on business perspective (not technical
> > >perspective as with Oak’s internal indexes)
> > >- It’s flexible (thanks for that already :)
> > >
> > >Though there are some things that require a bit of attention to make it
> > >work out of the box. I opened a couple of issues for that:
> > >
> > >SLING-7357
> > >SLING-7358
> > >SLING-7359
> > >SLING-7360
> > >SLING-7364
> > >
> > >And made proposals accordingly (not for the last one as I want to
> discuss
> > >that first)
> > >
> > >So my general question is:
> > >
> > >Is integrating Sling into Solr (or potentially any other kind of system
> > >that offers APIs to do so) a valid and envisaged use-case for Sling
> > Content
> > >Distribution? And if so would it make sense to implement a module for
> lets
> > >say Solr as example directly in Sling?
> > >
> > >If so I would volunteer to propose something for that but I think
> flexibly
> > >integrating Sling as framework for any kind of content driven web
> > >applications into Solr as enterprise search application would be a nice
> > >feature to offer.
> > >
> > >Thanks for any kind of feedback,
> > >
> > >/Dirk
> >
>

[jira] [Resolved] (SLING-7360) Support creation of DistributionPackages for delete by DistributionContentSerializer

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-7360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili resolved SLING-7360.

Resolution: Fixed
  Assignee: Dirk Rudolph

> Support creation of DistributionPackages for delete by 
> DistributionContentSerializer
> 
>
> Key: SLING-7360
> URL: https://issues.apache.org/jira/browse/SLING-7360
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Minor
> Fix For: Content Distribution Core 0.2.12
>
>
> For the integration into systems or then sling, that support 
> creation/deletion as part of their API [1], we can implement a 
> {{DistributionContentSerializer}} writing the format the API expects. That 
> currently works well for creation but not for deletion because both 
> {{FileDistributionPackageBuilder}} and {{ResourceDistributionPackageBuilder}} 
> inherit from {{AbstractDistributionPackageBuilder}} which [returns a 
> SimpleDistributionPackage|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/packaging/impl/AbstractDistributionPackageBuilder.java#L72]
>  for {{DistributionRequestType.DELETE}}. 
> The other system's API might expect a different format then the one written 
> by {{SimpleDistributionPackage}} so it would be create if it would be 
> possible to delegate the creation of a deletion package to the serializer as 
> well, in case the serializer supports that.
> [1] 
> https://lucene.apache.org/solr/guide/7_2/uploading-data-with-index-handlers.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SLING-7360) Support creation of DistributionPackages for delete by DistributionContentSerializer

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-7360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili updated SLING-7360:
---
Fix Version/s: Content Distribution Core 0.2.12

> Support creation of DistributionPackages for delete by 
> DistributionContentSerializer
> 
>
> Key: SLING-7360
> URL: https://issues.apache.org/jira/browse/SLING-7360
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Dirk Rudolph
>Priority: Minor
> Fix For: Content Distribution Core 0.2.12
>
>
> For the integration into systems or then sling, that support 
> creation/deletion as part of their API [1], we can implement a 
> {{DistributionContentSerializer}} writing the format the API expects. That 
> currently works well for creation but not for deletion because both 
> {{FileDistributionPackageBuilder}} and {{ResourceDistributionPackageBuilder}} 
> inherit from {{AbstractDistributionPackageBuilder}} which [returns a 
> SimpleDistributionPackage|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/packaging/impl/AbstractDistributionPackageBuilder.java#L72]
>  for {{DistributionRequestType.DELETE}}. 
> The other system's API might expect a different format then the one written 
> by {{SimpleDistributionPackage}} so it would be create if it would be 
> possible to delegate the creation of a deletion package to the serializer as 
> well, in case the serializer supports that.
> [1] 
> https://lucene.apache.org/solr/guide/7_2/uploading-data-with-index-handlers.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SLING-7359) DistributionEventDistributeDistributionTrigger causes distribution loop

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-7359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili resolved SLING-7359.

Resolution: Fixed
  Assignee: Dirk Rudolph

> DistributionEventDistributeDistributionTrigger causes distribution loop
> ---
>
> Key: SLING-7359
> URL: https://issues.apache.org/jira/browse/SLING-7359
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.10
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
> Fix For: Content Distribution Core 0.2.12
>
>
> The DistributionEventDistributeDistributionTrigger [is listening for 
> org/apache/sling/distribution/agent/package/distributed 
> events|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/trigger/impl/DistributionEventDistributeDistributionTrigger.java#L67].
>  
> Assuming we have 
> - an agent configured for the allowed root path /foo with 
> DistributionEventDistributeDistributionTrigger "trigger-on-foo-distrib" and
> - a DistributionEventDistributeDistributionTrigger "trigger-on-foo-distrib" 
> for /foo as well, 
> the agent's successful delivery will trigger another distribution on the same 
> agent. 
> To circumvent that the DistributionEventDistributeDistributionTrigger should 
> check the DistributionRequestHandler against the component that fired the 
> event it handles and should stop propagation when the event's origin is the 
> same request handler. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SLING-7358) FileDistributionPackageBuilder fails with no temp directory configured

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-7358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili updated SLING-7358:
---
Fix Version/s: Content Distribution Core 0.2.12

> FileDistributionPackageBuilder fails with no temp directory configured
> --
>
> Key: SLING-7358
> URL: https://issues.apache.org/jira/browse/SLING-7358
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.10
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Minor
> Fix For: Content Distribution Core 0.2.12
>
>
> When no temp directory is configured the 
> [FileDistributionPackageBuilder|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/packaging/impl/FileDistributionPackageBuilder.java#L86]
>  uses null to create a new temp file which, according to the java docs will 
> use the default temp directory. 
> On the other hand [reading the file 
> internally|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/packaging/impl/FileDistributionPackageBuilder.java#L160]
>  uses the {{File}} constructor passing {{null}} as directory to it. This 
> causes a non-existing file to be returned. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SLING-7357) Send Content-Type header along with the DistributionPackage's content in forward distribution

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-7357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili resolved SLING-7357.

Resolution: Fixed

> Send Content-Type header along with the DistributionPackage's content in 
> forward distribution
> -
>
> Key: SLING-7357
> URL: https://issues.apache.org/jira/browse/SLING-7357
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Minor
> Fix For: Content Distribution Core 0.2.12
>
>
> Currently SimpleHttpDistributionTransport only adds Connection and Digest 
> http header (if configured to do so) to the http request. When integrating 
> into other systems then sling the API might require the content type of the 
> package transmitted to be present. 
> I see to options to support that:
> a) implement configureable headers for the http transport similar to the 
> timeouts. This might clash with headers set by the implementation
> b) let the serializer specify the type of the content it generates. This will 
> be an API change in the core bundle.
> From my perspective b) will be simpler to implement.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (SLING-7357) Send Content-Type header along with the DistributionPackage's content in forward distribution

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-7357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili reassigned SLING-7357:
--

Assignee: Dirk Rudolph

> Send Content-Type header along with the DistributionPackage's content in 
> forward distribution
> -
>
> Key: SLING-7357
> URL: https://issues.apache.org/jira/browse/SLING-7357
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Minor
> Fix For: Content Distribution Core 0.2.12
>
>
> Currently SimpleHttpDistributionTransport only adds Connection and Digest 
> http header (if configured to do so) to the http request. When integrating 
> into other systems then sling the API might require the content type of the 
> package transmitted to be present. 
> I see to options to support that:
> a) implement configureable headers for the http transport similar to the 
> timeouts. This might clash with headers set by the implementation
> b) let the serializer specify the type of the content it generates. This will 
> be an API change in the core bundle.
> From my perspective b) will be simpler to implement.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (SLING-7358) FileDistributionPackageBuilder fails with no temp directory configured

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-7358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili reassigned SLING-7358:
--

Assignee: Dirk Rudolph

> FileDistributionPackageBuilder fails with no temp directory configured
> --
>
> Key: SLING-7358
> URL: https://issues.apache.org/jira/browse/SLING-7358
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.10
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Minor
> Fix For: Content Distribution Core 0.2.12
>
>
> When no temp directory is configured the 
> [FileDistributionPackageBuilder|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/packaging/impl/FileDistributionPackageBuilder.java#L86]
>  uses null to create a new temp file which, according to the java docs will 
> use the default temp directory. 
> On the other hand [reading the file 
> internally|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/packaging/impl/FileDistributionPackageBuilder.java#L160]
>  uses the {{File}} constructor passing {{null}} as directory to it. This 
> causes a non-existing file to be returned. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SLING-7358) FileDistributionPackageBuilder fails with no temp directory configured

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-7358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili resolved SLING-7358.

Resolution: Fixed

> FileDistributionPackageBuilder fails with no temp directory configured
> --
>
> Key: SLING-7358
> URL: https://issues.apache.org/jira/browse/SLING-7358
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.10
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Minor
> Fix For: Content Distribution Core 0.2.12
>
>
> When no temp directory is configured the 
> [FileDistributionPackageBuilder|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/packaging/impl/FileDistributionPackageBuilder.java#L86]
>  uses null to create a new temp file which, according to the java docs will 
> use the default temp directory. 
> On the other hand [reading the file 
> internally|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/packaging/impl/FileDistributionPackageBuilder.java#L160]
>  uses the {{File}} constructor passing {{null}} as directory to it. This 
> causes a non-existing file to be returned. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SLING-7359) DistributionEventDistributeDistributionTrigger causes distribution loop

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-7359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili updated SLING-7359:
---
Fix Version/s: Content Distribution Core 0.2.12

> DistributionEventDistributeDistributionTrigger causes distribution loop
> ---
>
> Key: SLING-7359
> URL: https://issues.apache.org/jira/browse/SLING-7359
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.10
>Reporter: Dirk Rudolph
> Fix For: Content Distribution Core 0.2.12
>
>
> The DistributionEventDistributeDistributionTrigger [is listening for 
> org/apache/sling/distribution/agent/package/distributed 
> events|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/trigger/impl/DistributionEventDistributeDistributionTrigger.java#L67].
>  
> Assuming we have 
> - an agent configured for the allowed root path /foo with 
> DistributionEventDistributeDistributionTrigger "trigger-on-foo-distrib" and
> - a DistributionEventDistributeDistributionTrigger "trigger-on-foo-distrib" 
> for /foo as well, 
> the agent's successful delivery will trigger another distribution on the same 
> agent. 
> To circumvent that the DistributionEventDistributeDistributionTrigger should 
> check the DistributionRequestHandler against the component that fired the 
> event it handles and should stop propagation when the event's origin is the 
> same request handler. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SLING-7357) Send Content-Type header along with the DistributionPackage's content in forward distribution

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-7357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili updated SLING-7357:
---
Fix Version/s: Content Distribution Core 0.2.12

> Send Content-Type header along with the DistributionPackage's content in 
> forward distribution
> -
>
> Key: SLING-7357
> URL: https://issues.apache.org/jira/browse/SLING-7357
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Dirk Rudolph
>Priority: Minor
> Fix For: Content Distribution Core 0.2.12
>
>
> Currently SimpleHttpDistributionTransport only adds Connection and Digest 
> http header (if configured to do so) to the http request. When integrating 
> into other systems then sling the API might require the content type of the 
> package transmitted to be present. 
> I see to options to support that:
> a) implement configureable headers for the http transport similar to the 
> timeouts. This might clash with headers set by the implementation
> b) let the serializer specify the type of the content it generates. This will 
> be an API change in the core bundle.
> From my perspective b) will be simpler to implement.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] Release Apache Sling Distribution Core 0.2.10

[Tommaso Teofili]

+1 (not binding) build and sigs ok.

Regards,
Tommaso

Il giorno ven 5 gen 2018 alle ore 10:49 Timothee Maret 
ha scritto:

> +1 (not binding), SLING-7017 has been resolved, checked build, signature.
>
> Regards,
>
> Timothee
>
> 2018-01-04 17:24 GMT+01:00 Karl Pauls :
>
> > That JIRA release actually has 20 issues (6 still open). Are you planning
> > to move them out to the next release (and in that case, it looks like
> > at least SLING-7017 has something commited already - does that need to
> > be resolved)?
> >
> > regards,
> >
> > Karl
> >
> > On Thu, Jan 4, 2018 at 5:06 PM, Simone Tripodi  >
> > wrote:
> > > Hi all,
> > >
> > > We solved 14 issue in this release:
> > > https://issues.apache.org/jira/projects/SLING/versions/12340677
> > >
> > > Staging repository:
> > > https://repository.apache.org/content/repositories/orgapachesling-1844
> > >
> > > You can use this UNIX script to download the release and verify the
> > > signatures:
> > > https://raw.githubusercontent.com/apache/sling-tooling-
> > > release/master/check_staged_release.sh
> > >
> > > Usage:
> > > curl
> > > https://raw.githubusercontent.com/apache/sling-tooling-
> > > release/master/check_staged_release.sh
> > > | bash -s 1844
> > >
> > > Please vote to approve this release:
> > >
> > >   [ ] +1 Approve the release
> > >   [ ]  0 Don't care
> > >   [ ] -1 Don't release, because ...
> > >
> > > This majority vote is open for at least 72 hours.
> > >
> > > All the best!
> > > ~Simo
> > >
> > > http://people.apache.org/~simonetripodi/
> > > http://twitter.com/simonetripodi
> >
> >
> >
> > --
> > Karl Pauls
> > karlpa...@gmail.com
> >
>

Re: [VOTE] Release Apache Sling Event Support version 4.2.10

[Tommaso Teofili]

+1

Tommaso

Il giorno mer 8 nov 2017 alle ore 06:38 Carsten Ziegeler <
cziege...@apache.org> ha scritto:

> +1
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

[jira] [Commented] (SLING-7142) Allow to pull a set of packages per request

[Tommaso Teofili (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16187840#comment-16187840
 ] 

Tommaso Teofili commented on SLING-7142:


thanks [~marett], it sounds like a possibly nice improvement, but I agree on 
the code complexity. Maybe we should look at streaming packages in a single 
requests or directly create "multi packages" (bigger payload). 

> Allow to pull a set of packages per request
> ---
>
> Key: SLING-7142
> URL: https://issues.apache.org/jira/browse/SLING-7142
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.8
>Reporter: Timothee Maret
>
> Currently, the sync/reverse agent pull one package per request. 
> This protocol is really simple and it is already possible to decrease the 
> polling interval (via the trigger) to increase the sync throughput. 
> However, establishing a request has a cost which is applied to every packages.
> In order to improve the throughput when processing the queue, we could avoid 
> establishing most of the request, by allowing to pull more than one package 
> per request.
> In order to allow for some flow control, we could let the receiving side 
> define how many packages could be fetched (similarly to how TCP works).
> Allowing to pull more than more package per request adds more complexity to 
> the code, so we may first build a PoC to demonstrate if the improved 
> throughput is worth the added complexity.
> cc [~teofili], [~simone.tripodi]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [git] Which git system do we want to use?

[Tommaso Teofili]

Il giorno mer 27 set 2017 alle ore 09:12 Bertrand Delacretaz <
bdelacre...@apache.org> ha scritto:

> Hi Tommaso,
>
> On Wed, Sep 27, 2017 at 9:00 AM, Tommaso Teofili
> <tommaso.teof...@gmail.com> wrote:
> > ...In Sling however it might be too much to require to fire a PR for
> each and
> > every commit, given the amount of active committers and commits we have
> on
> > a weekly basis...
>
> Do you mean that gitbox requires pull requests and prevents us from
> pushing directly to our own repositories?
>

no, you can push directly to github (just done a minor commit and push
directly to https://github.com/apache/opennlp-sandbox in [1], no PR).
So gitbox allows easier PR driven workflow but we can also keep working
with "direct" commits.

Regards,
Tommaso

[1] :
https://github.com/apache/opennlp-sandbox/commit/f764dbdfd16358b9b42617672eaa210b183e9b07


>
> (and if yes is that documented somewhere)
>
> -Bertrand
>

Re: [git] Which git system do we want to use?

[Tommaso Teofili]

sorry for the late replies, however moving from wip to gitbox was not hard
at all, Infra helped us and it went smooth.
With gitbox in OpenNLP we simply create a PR, check Travis results and
eventually click the "merge PR" button from github, which is fairly
different from most of the other ASF projects I have seen, but also allows
for a more controlled (and safe) commit history.
In Sling however it might be too much to require to fire a PR for each and
every commit, given the amount of active committers and commits we have on
a weekly basis.

Regards,
Tommaso

Il giorno gio 21 set 2017 alle ore 14:52 Karl Pauls 
ha scritto:

> On Thu, Sep 21, 2017 at 2:32 PM, Bertrand Delacretaz
>  wrote:
> > On Thu, Sep 21, 2017 at 2:07 PM, Oliver Lietz 
> wrote:
> >> ...we should not use GitHub for issues, wiki or pages but stay with
> JIRA,
> >> Confluence and our existing site...
>
> +1 I agree with that.
>
> However (and maybe I misunderstood), I thought this question was about
> the git part of github. I (and again, personally) think that the
> biggest benefit of moving to git is more seemless integration with
> github on the level of e.g., pullrequests, fork, etc - especially
> considering change/commiter history.
>
> In this regard, if I understand correctly, we have two options namely,
> wip and dual-master. I'm in favour of the one that makes working with
> us on github the easiest.
>
> If this was about wiki or jira, I'm sorry.
>
> regards,
>
> Karl
>
>
>
> > +1
> >
> > -Bertrand
>
>
>
> --
> Karl Pauls
> karlpa...@gmail.com
>

Re: [git] Which git system do we want to use?

[Tommaso Teofili]

in Apache OpenNLP we were on wip and then switched to gitbox afterwards
because we found that easier when merging pull requests (less forks/origins
to maintain) and wanted to enforce a stricter review process for commits so
that now every contribution goes through a PR which needs +1s, on the other
hand in Apache Lucene / Solr we have git-wip because we use it not much
differently from how we used SVN in terms of development workflows.
So I would say it depends on what we look for.
For now I would opt for git-wip, but I see Justin's point and if more
people want to go that way I can see the benefits.

My 2 cents,
Tommaso

Il giorno mer 20 set 2017 alle ore 18:06 Justin Edelson <
jus...@justinedelson.com> ha scritto:

> Hi,
> While it is true that this project does not have an existing Github-centric
> workflow, I suspect that most of us use such a workflow on other projects,
> so I would be more in favor of the dual-master system.
>
> Regards,
> Justin
>
> On Wed, Sep 20, 2017 at 11:48 AM Robert Munteanu 
> wrote:
>
> > Hi,
> >
> > According to http://git.apache.org/ , there are two systems in use at
> > the ASF:
> >
> > - the "Git Wip" system
> > - the "Github Dual Master"
> >
> > I have not found any more information about these - Ian referenced the
> > dual master some time ago [1], but AFAICT the "Wip" system is basically
> > ASF hosted git mirrored to Github, while the "Dual Master" system
> > allows us to push to Github as well as to the ASF Git.
> >
> > IMO the dual master system is for projects with a Github-centric
> > workflow coming to the ASF, which is not our situation at all, so I'd
> > go with the "Wip" system.
> >
> > What do others think?
> >
> > Thanks,
> >
> > Robert
> >
> >
> > [1]: https://lists.apache.org/thread.html/b8b0003cf9fcb1c365a9ed354fe7c
> > 20c2c4c5b465c952829e0eb4c78@1458668880@%3Cdev.sling.apache.org%3E
> >
>

Re: [git] Naming of git repositories

[Tommaso Teofili]

+1

Tommaso

Il giorno ven 15 set 2017 alle ore 12:58 Robert Munteanu 
ha scritto:

> On Fri, 2017-09-08 at 22:40 +0200, Oliver Lietz wrote:
> > On Friday 08 September 2017 16:48:24 Stefan Seifert wrote:
> > > in our last discussion [1] our plan was this:
> > >
> > >
> > > > - name pattern for the git repository should be something like
> > > > "sling-"
> >
> >  - we drop the folder grouping from svn today in
> > > > "extensions", "servlets", "commons" etc. only the hierarchy of
> > > > artifactId
> > > > is relevant. - with the prefix "sling-" they
> > > > - question: how are "contrib" and "samples" repos marked? by
> > > > another
> > > > prefix like "sling-contrib-" and "sling-samples-"?
> > >
> > > i'm in favor of using the artifactid because it's unique and easy
> > > to find.
> >
> > +1 for artifactId (with prefix sling if really required – we only
> > have four
> > maintained artifacts without sling) because it's a dead simple
> > pattern (for
> > automation also).
>
> Seems that everyone else seem to like the artifact id so we'll go with
> that.
>
> Thanks for the input.
>
> Robert
>
> >
> > O.
> >
> > > stefan
> > >
> > > [1]
> > > https://lists.apache.org/thread.html/37765304556b17a04e7eb122afd895
> > > ea7beae9
> > > 57d56c9d4501a9f2e0@%3Cdev.sling.apache.org%3E
> >
> >
> > >
> > >
> > > > -Original Message-
> > > > From: Robert Munteanu [mailto:romb...@apache.org]
> > > > Sent: Friday, September 8, 2017 3:34 PM
> > > > To: dev@sling.apache.org
> > > > Subject: [git] Naming of git repositories
> > > >
> > > > Hi,
> > > >
> > > > I've started thinking a bit about the Git migration process. I
> > > > don't
> > > > think we've discussed naming individual Sling modules after being
> > > > extracted from SVN.
> > > >
> > > > ASF mandates that we use a pattern of 'TLP-module' for the git
> > > > repositories, so the modules must be name sling-${something}.
> > > >
> > > > As for that ${something}, it can be one of
> > > >
> > > > 1. artifactId / Bundle-SymbolicName
> > > > 2. short name ( as currently used in the SVN repo )
> > > >
> > > > I would favour option 2, as I think option 1 has too much
> > > > redundancy:
> > > >
> > > >
> > > >  sling-org.apache.sling.auth.core
> > > >
> > > >
> > > > is too verbose compared to
> > > >
> > > >
> > > >  sling-auth-core
> > > >
> > > >
> > > >
> > > > Refining option #2, we should remove some commons prefixes, such
> > > > as:
> > > >
> > > > - bundles
> > > > - contrib/bundles
> > > > - bundles/extensions
> > > > - contrib
> > > > - contrib/extensions
> > > > - karaf
> > > > - tooling/maven
> > > >
> > > > Thoughts?
> > > >
> > > > Robert
> > >
> > >
> >
> >
>
>

Re: [VOTE] Release Apache Sling Commons Scheduler 2.7.2

[Tommaso Teofili]

+1

Tommaso

Il giorno mer 13 set 2017 alle ore 17:33 Karl Pauls 
ha scritto:

> +1
>
> regards,
>
> Karl
>
> On Wed, Sep 13, 2017 at 5:14 PM, Robert Munteanu 
> wrote:
> > On Wed, 2017-09-13 at 13:07 +0200, Stefan Egli wrote:
> >> Please vote to approve this release:
> >
> > +1
> >
> > Robert
>
>
>
> --
> Karl Pauls
> karlpa...@gmail.com
>

Re: [VOTE] Release Apache Sling Pipe version 1.0.4

[Tommaso Teofili]

+1

Tommaso

Il giorno mar 29 ago 2017 alle ore 22:35 Nicolas Peltier <
peltier.nico...@gmail.com> ha scritto:

> Hi,
>
> We solved 18 issues in this release:
> https://issues.apache.org/jira/projects/SLING/versions/12338435
>
> There are still some outstanding issues:
> https://issues.apache.org/jira/browse/SLING-6593
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1777/
>
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 1777 /tmp/sling-staging
>
> Please vote to approve this release:
>
>   [ ] +1 Approve the release
>   [ ]  0 Don't care
>   [ ] -1 Don't release, because ...
>
> This majority vote is open for at least 72 hours.
>

Re: [VOTE] Release Apache Sling Commons Scheduler 2.7.0

[Tommaso Teofili]

+1

Tommaso

Il giorno mar 22 ago 2017 alle ore 12:08 Robert Munteanu 
ha scritto:

> On Tue, 2017-08-22 at 11:35 +0200, Carsten Ziegeler wrote:
> > Please vote to approve this release:
>
> +1
>
> Robert

Re: [VOTE] Release Apache Sling Launchpad Base 5.6.6-2.6.20

[Tommaso Teofili]

+1

Tommaso

Il giorno lun 31 lug 2017 alle ore 16:01 Robert Munteanu 
ha scritto:

> On Mon, 2017-07-31 at 13:34 +0200, Karl Pauls wrote:
> > Please vote to approve these releases:
>
> +1
>
> Robert

[jira] [Commented] (SLING-7017) Make it possible to mount packages at different paths

[Tommaso Teofili (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16096163#comment-16096163
 ] 

Tommaso Teofili commented on SLING-7017:


thanks [~simone.tripodi] the patch looks good to me! thanks :)

> Make it possible to mount packages at different paths
> -
>
> Key: SLING-7017
> URL: https://issues.apache.org/jira/browse/SLING-7017
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>        Reporter: Tommaso Teofili
>Assignee: Simone Tripodi
> Fix For: Content Distribution Core 0.2.10
>
> Attachments: SLING-7017.1.patch, SLING-7017.2.patch, 
> SLING-7017.3.patch
>
>
> In some scenarios (e.g. multi tenant instances) it may be useful to be able 
> to mount packages at configurable paths.
> For example mounting a package for _/foo/bar/_ at _/tenant1/foo/bar_; we can 
> leverage FileVault [configuration 
> options|https://github.com/apache/jackrabbit-filevault/blob/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/ExportOptions.java#L126]
>  to support that.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] Release Apache Sling Service User Mapper 1.3.4, Resource Resolver 1.5.28, JCR Base 3.0.4, and JCR Resource 3.0.4

[Tommaso Teofili]

+1

Tommaso

Il giorno mer 19 lug 2017 alle ore 10:09 Carsten Ziegeler <
cziege...@apache.org> ha scritto:

> +1
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

[jira] [Created] (SLING-7017) Make it possible to mount packages at different paths

[Tommaso Teofili (JIRA)]

Tommaso Teofili created SLING-7017:
--

 Summary: Make it possible to mount packages at different paths
 Key: SLING-7017
 URL: https://issues.apache.org/jira/browse/SLING-7017
 Project: Sling
  Issue Type: Improvement
  Components: Content Distribution
Reporter: Tommaso Teofili
 Fix For: Content Distribution Core 0.2.10


In some scenarios (e.g. multi tenant instances) it may be useful to be able to 
mount packages at configurable paths.
For example mounting a package for _/foo/bar/_ at _/tenant1/foo/bar_; we can 
leverage FileVault [configuration 
options|https://github.com/apache/jackrabbit-filevault/blob/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/ExportOptions.java#L126]
 to support that.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SLING-6654) Test distribution has a wrong header

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili resolved SLING-6654.

Resolution: Fixed

> Test distribution has a wrong header
> 
>
> Key: SLING-6654
> URL: https://issues.apache.org/jira/browse/SLING-6654
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.6
>    Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution Core 0.2.10
>
>
> {{SimpleDistributionPackage}} doesn't set the paths if they are empty and, 
> most importantly, its delimiter, therefore {{ResourcePackageBuilder}} may 
> fail at persisting it because of the resulting wrong header in the package.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [DISCUSS] wrong conversion typisation in SCD source

[Tommaso Teofili]

+1 thanks Simo
Il giorno lun 10 lug 2017 alle 16:30 Timothee Maret  ha
scritto:

> Hi Simo!
>
> I guess the best is to JIRA with a failing test :-)
> I don't think this is tracked anywhere.
>
> Cheers,
>
> Timothee
>
> 2017-07-10 15:05 GMT+02:00 Simone Tripodi :
>
> > Hi mates,
> > there still is a completely wrong type conversion in the source code
> which
> > can potentially throw unexpected troubles...
> > Did you have a chance already to have a look at it?
> > Would it be ok filling an issue to track it and avoid to release such
> > error in the next release?
> > TIA!
> > -Simo
> >
> > [1] https://svn.apache.org/viewvc/sling/trunk/contrib/
> > extensions/distribution/core/src/main/java/org/apache/
> > sling/distribution/resources/impl/common/SimpleReadableResource.java?
> > view=markup#l123
> >
> > http://people.apache.org/~simonetripodi/
> > http://twitter.com/simonetripodi
> >
>

Re: ANN] New Apache Sling committer: Simone Tripodi

[Tommaso Teofili]

hooray! very well deserved recognition of your efforts Simo!

Cheers,
Tommaso

Il giorno ven 7 lug 2017 alle ore 14:12 Antonio Sanso
 ha scritto:

> Hi *,
>
> Please welcome Simone Tripodi as a new committer of the Apache Sling
> project.
> The Apache Sling PMC recently decided to offer Simone committership based
> on his contributions.
> I'm happy to announce that he accepted the offer.
>
> Welcome to the team, Simo!
>
> @Simo if you want to honor the old tradition of new committers
> briefly introducing themselves to the list, feel free.
>
> regards
>
> antonio

Re: [VOTE] Release Apache Sling Resource Resolver 1.5.26

[Tommaso Teofili]

+1

Tommaso

Il giorno gio 6 lug 2017 alle ore 09:33 Antonio Sanso
 ha scritto:

> +1
> On Jul 5, 2017, at 4:04 PM, Karl Pauls  wrote:
>
> > I would like to call a vote on the following release,
> >
> > Apache Sling Resource Resolver 1.5.26
> >
> > We solved 1 issue in this release:
> > https://issues.apache.org/jira/projects/SLING/versions/12340514
> >
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachesling-1751/
> >
> > You can use this UNIX script to download the release and verify the
> signatures:
> > http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
> >
> > Usage:
> > sh check_staged_release.sh 1751 /tmp/sling-staging
> >
> > Please vote to approve these releases:
> >
> >  [ ] +1 Approve the releases
> >  [ ]  0 Don't care
> >  [ ] -1 Don't release, because ...
>
>

Re: [VOTE] Release Apache Sling Discovery Base 2.0.4 and Discovery Oak 1.2.20

[Tommaso Teofili]

+1

Tommaso

Il giorno mar 4 lug 2017 alle ore 14:30 Stefan Egli 
ha scritto:

> On 04/07/17 14:28, "Stefan Egli"  wrote:
>
> >We solved 2 issues in these 2 release:
>
> 3 issues that is...
>
>
>

[jira] [Resolved] (SLING-6977) Improve SCD compilation by suppressing warnings

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili resolved SLING-6977.

   Resolution: Fixed
Fix Version/s: Content Distribution Core 0.2.10

> Improve SCD compilation by suppressing warnings
> ---
>
> Key: SLING-6977
> URL: https://issues.apache.org/jira/browse/SLING-6977
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Simone Tripodi
>    Assignee: Tommaso Teofili
> Fix For: Content Distribution Core 0.2.10
>
> Attachments: SLING-6977.patch
>
>
> After some cleanups, there are still compilation issues due to the fact we 
> want to be compliant to OSGi APIs that don't support generics, the incoming 
> patch will supply them in order to drastically reduce warnings in the IDEs 
> and on the compiler output.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-6977) Improve SCD compilation by suppressing warnings

[Tommaso Teofili (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16070011#comment-16070011
 ] 

Tommaso Teofili commented on SLING-6977:


thanks Simo for your patch, I've applied it in r1800389.

> Improve SCD compilation by suppressing warnings
> ---
>
> Key: SLING-6977
> URL: https://issues.apache.org/jira/browse/SLING-6977
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Simone Tripodi
>    Assignee: Tommaso Teofili
> Fix For: Content Distribution Core 0.2.10
>
> Attachments: SLING-6977.patch
>
>
> After some cleanups, there are still compilation issues due to the fact we 
> want to be compliant to OSGi APIs that don't support generics, the incoming 
> patch will supply them in order to drastically reduce warnings in the IDEs 
> and on the compiler output.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SLING-6988) Async delivery should create an unordererd delivery queue

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili resolved SLING-6988.

Resolution: Fixed

fixed in r1800364.

> Async delivery should create an unordererd delivery queue
> -
>
> Key: SLING-6988
> URL: https://issues.apache.org/jira/browse/SLING-6988
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>        Reporter: Tommaso Teofili
>    Assignee: Tommaso Teofili
> Fix For: Content Distribution Core 0.2.10
>
>
> Currently {{AsyncDeliveryDispatchingStrategy}} does not create a parallel 
> queue for delivery if it doesn't exist, therefore the deriving improvements 
> in throughput are less impacting than expected.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SLING-6988) Async delivery should create an unordererd delivery queue

[Tommaso Teofili (JIRA)]

Tommaso Teofili created SLING-6988:
--

 Summary: Async delivery should create an unordererd delivery queue
 Key: SLING-6988
 URL: https://issues.apache.org/jira/browse/SLING-6988
 Project: Sling
  Issue Type: Bug
  Components: Content Distribution
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
 Fix For: Content Distribution Core 0.2.10


Currently {{AsyncDeliveryDispatchingStrategy}} does not create a parallel queue 
for delivery if it doesn't exist, therefore the deriving improvements in 
throughput are less impacting than expected.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] Release Apache Sling Authentication Service

[Tommaso Teofili]

+1

Tommaso

Il giorno mar 27 giu 2017 alle ore 20:51 Antonio Sanso
 ha scritto:

> my own +1
>
> On Jun 26, 2017, at 1:55 PM, Antonio Sanso 
> wrote:
>
> > Hi,
> >
> > We solved 1 issue in this release:
> > https://issues.apache.org/jira/browse/SLING-6972
> >
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachesling-1748
> >
> > You can use this UNIX script to download the release and verify the
> signatures:
> > http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
> >
> > Usage:
> > sh check_staged_release.sh 1748 /tmp/sling-staging
> >
> > Please vote to approve this release:
> >
> >  [ ] +1 Approve the release
> >  [ ]  0 Don't care
> >  [ ] -1 Don't release, because ...
> >
> > This majority vote is open for at least 72 hours.
>
>

[jira] [Commented] (SLING-6977) Improve SCD compilation by suppressing warnings

[Tommaso Teofili (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16059303#comment-16059303
 ] 

Tommaso Teofili commented on SLING-6977:


thanks a lot Simo for your restless work on making our code cleaner and nicer!


> Improve SCD compilation by suppressing warnings
> ---
>
> Key: SLING-6977
> URL: https://issues.apache.org/jira/browse/SLING-6977
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Simone Tripodi
>    Assignee: Tommaso Teofili
> Attachments: SLING-6977.patch
>
>
> After some cleanups, there are still compilation issues due to the fact we 
> want to be compliant to OSGi APIs that don't support generics, the incoming 
> patch will supply them in order to drastically reduce warnings in the IDEs 
> and on the compiler output.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] Apache Sling Event 4.2.4

[Tommaso Teofili]

+1

Tommaso

Il giorno mer 21 giu 2017 alle ore 22:04 Stefan Seifert <
sseif...@pro-vision.de> ha scritto:

> +1
>
>

[jira] [Commented] (SLING-6942) DistributionUtils#getResourceResolver should use the user session

[Tommaso Teofili (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16042394#comment-16042394
 ] 

Tommaso Teofili commented on SLING-6942:


+1 thanks Tim!

> DistributionUtils#getResourceResolver should use the user session
> -
>
> Key: SLING-6942
> URL: https://issues.apache.org/jira/browse/SLING-6942
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.1.12
>Reporter: Timothee Maret
> Attachments: SLING-6942.patch
>
>
> According to SLING-5281, the resource resolver should use the user session 
> when no subservice user is configured. Currently, this is not the case. See 
> also SLING-6939.
> cc [~teofili]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [VOTE] Apache Sling Resource Inventory 1.0.8, Content Distribution Core 0.2.8, Testing Sling Mock 2.2.12, Log Tracer 1.0.4, Commons Metrics 1.2.2

[Tommaso Teofili]

+1

Tommaso

Il giorno lun 5 giu 2017 alle ore 16:24 Carsten Ziegeler <
cziege...@apache.org> ha scritto:

> +1
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

Re: [VOTE] Retire o.a.s.xss.compat module to the Sling Attic

[Tommaso Teofili]

+1

Tommaso

Il giorno mer 31 mag 2017 alle ore 08:18 Robert Munteanu 
ha scritto:

> On Tue, 2017-05-30 at 22:56 +0200, Karl Pauls wrote:
> > Please vote to accept this retirement, this majority vote is open for
> > at least 72 hours.
>
> +1
>
> Robert

Re: [VOTE] Retire o.a.s.commons.json module to the Sling Attic

[Tommaso Teofili]

+1

Tommaso

Il giorno mer 31 mag 2017 alle ore 08:17 Robert Munteanu 
ha scritto:

> On Tue, 2017-05-30 at 22:50 +0200, Karl Pauls wrote:
> > Please vote to accept this retirement, this majority vote is open for
> > at least 72 hours.
>
> +1
>
> Robert

[jira] [Resolved] (SLING-6848) Package level monitoring should be only enabled consciously

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili resolved SLING-6848.

Resolution: Fixed
  Assignee: Tommaso Teofili

fixed in r1794817.

> Package level monitoring should be only enabled consciously
> ---
>
> Key: SLING-6848
> URL: https://issues.apache.org/jira/browse/SLING-6848
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>        Reporter: Tommaso Teofili
>    Assignee: Tommaso Teofili
> Fix For: Content Distribution Core 0.2.8
>
> Attachments: SLING-6848.0.patch
>
>
> I have noticed that by default all {{DistributionPackages}} get an MBean 
> registered by {{MonitoringDistributionPackageBuilder}}. 
> While that's fine for monitoring purposes, I think that slows down a 
> distribution request a bit, therefore I was wondering if it wouldn't be 
> better to set the default _monitored package size_ to 0 (currently it's 100) 
> and do MBean registration only if that value is higher than 0.
> [~simone.tripodi] what do you think ?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6848) Package level monitoring should be only enabled consciously

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili updated SLING-6848:
---
Attachment: SLING-6848.0.patch

attaching draft patch.

> Package level monitoring should be only enabled consciously
> ---
>
> Key: SLING-6848
> URL: https://issues.apache.org/jira/browse/SLING-6848
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>        Reporter: Tommaso Teofili
> Fix For: Content Distribution Core 0.2.8
>
> Attachments: SLING-6848.0.patch
>
>
> I have noticed that by default all {{DistributionPackages}} get an MBean 
> registered by {{MonitoringDistributionPackageBuilder}}. 
> While that's fine for monitoring purposes, I think that slows down a 
> distribution request a bit, therefore I was wondering if it wouldn't be 
> better to set the default _monitored package size_ to 0 (currently it's 100) 
> and do MBean registration only if that value is higher than 0.
> [~simone.tripodi] what do you think ?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (SLING-6848) Package level monitoring should be only enabled consciously

[Tommaso Teofili (JIRA)]

Tommaso Teofili created SLING-6848:
--

 Summary: Package level monitoring should be only enabled 
consciously
 Key: SLING-6848
 URL: https://issues.apache.org/jira/browse/SLING-6848
 Project: Sling
  Issue Type: Improvement
  Components: Content Distribution
Reporter: Tommaso Teofili
 Fix For: Content Distribution Core 0.2.8


I have noticed that by default all {{DistributionPackages}} get an MBean 
registered by {{MonitoringDistributionPackageBuilder}}. 
While that's fine for monitoring purposes, I think that slows down a 
distribution request a bit, therefore I was wondering if it wouldn't be better 
to set the default _monitored package size_ to 0 (currently it's 100) and do 
MBean registration only if that value is higher than 0.
[~simone.tripodi] what do you think ?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (SLING-6838) Do not use persistence connections in SCD HTTP

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili resolved SLING-6838.

Resolution: Fixed

fixed in r1794300

> Do not use persistence connections in SCD HTTP
> --
>
> Key: SLING-6838
> URL: https://issues.apache.org/jira/browse/SLING-6838
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>        Reporter: Tommaso Teofili
>    Assignee: Tommaso Teofili
> Fix For: Content Distribution Core 0.2.8
>
>
> In order to avoid connections to stale it'd be better to let explicitly avoid 
> persistent connections (aka keep-alive) in HTTP requests.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (SLING-6838) Do not use persistence connections in SCD HTTP

[Tommaso Teofili (JIRA)]

Tommaso Teofili created SLING-6838:
--

 Summary: Do not use persistence connections in SCD HTTP
 Key: SLING-6838
 URL: https://issues.apache.org/jira/browse/SLING-6838
 Project: Sling
  Issue Type: Improvement
  Components: Content Distribution
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
 Fix For: Content Distribution Core 0.2.8


In order to avoid connections to stale it'd be better to let explicitly avoid 
persistent connections (aka keep-alive) in HTTP requests.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (SLING-5952) Add support for configurable SO and connection timeouts

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili resolved SLING-5952.

Resolution: Fixed

> Add support for configurable SO and connection timeouts
> ---
>
> Key: SLING-5952
> URL: https://issues.apache.org/jira/browse/SLING-5952
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Timothee Maret
>Assignee: Tommaso Teofili
> Fix For: Content Distribution Core 0.2.8
>
> Attachments: SLING-SLING-5952.0.patch
>
>
> Currently the SDC transport is using the default HTTP client timeouts
> 1. Connection Timeout (by default it is infinite)
> 2. SO Socket Timeout (by default it is infinite)
> Allowing to configure a bounded timeouts is needed in most deployments in 
> order to avoid leaving a resource stuck.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-5952) Add support for configurable SO and connection timeouts

[Tommaso Teofili (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15996764#comment-15996764
 ] 

Tommaso Teofili commented on SLING-5952:


I've fixed this in r1793803.

> Add support for configurable SO and connection timeouts
> ---
>
> Key: SLING-5952
> URL: https://issues.apache.org/jira/browse/SLING-5952
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Timothee Maret
>Assignee: Tommaso Teofili
> Fix For: Content Distribution Core 0.2.8
>
> Attachments: SLING-SLING-5952.0.patch
>
>
> Currently the SDC transport is using the default HTTP client timeouts
> 1. Connection Timeout (by default it is infinite)
> 2. SO Socket Timeout (by default it is infinite)
> Allowing to configure a bounded timeouts is needed in most deployments in 
> order to avoid leaving a resource stuck.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-5952) Add support for configurable SO and connection timeouts

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili updated SLING-5952:
---
Attachment: SLING-SLING-5952.0.patch

attaching trivial patch with fixed socket / connect timeout of 10s.

> Add support for configurable SO and connection timeouts
> ---
>
> Key: SLING-5952
> URL: https://issues.apache.org/jira/browse/SLING-5952
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Content Distribution Core 0.2.8
>
> Attachments: SLING-SLING-5952.0.patch
>
>
> Currently the SDC transport is using the default HTTP client timeouts
> 1. Connection Timeout (by default it is infinite)
> 2. SO Socket Timeout (by default it is infinite)
> Allowing to configure a bounded timeouts is needed in most deployments in 
> order to avoid leaving a resource stuck.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [RT] Configurationless Sling?

[Tommaso Teofili]

Il giorno mar 28 mar 2017 alle ore 15:13 Bertrand Delacretaz <
bdelacre...@apache.org> ha scritto:

> On Tue, Mar 28, 2017 at 3:01 PM, Carsten Ziegeler 
> wrote:
> > Julian Sedding wrote
> >>... As a convention for service users, would it make sense to use the
> >> bundle-symbolic-name as the user-ID (or principal-name)?...
>
> > ...We could use the bundle
> > symbolic name and the sub service information. That should be enough. We
> > don't need the class name
>
> +1 and we might prefix this with bundle_ or b_ to make it clear where
> these usernames come from?
>
> I suppose in the vast majority of cases there's one service user per
> bundle, so that would remove a lot of boring configurations.
>

+1

Tommaso


>
> -Bertrand
>

[jira] [Created] (SLING-6654) Test distribution has a wrong header

[Tommaso Teofili (JIRA)]

Tommaso Teofili created SLING-6654:
--

 Summary: Test distribution has a wrong header
 Key: SLING-6654
 URL: https://issues.apache.org/jira/browse/SLING-6654
 Project: Sling
  Issue Type: Bug
  Components: Content Distribution
Affects Versions: Content Distribution Core 0.2.6
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
 Fix For: Content Distribution Core 0.2.8


{{SimpleDistributionPackage}} doesn't set the paths if they are empty and, most 
importantly, its delimiter, therefore {{ResourcePackageBuilder}} may fail at 
persisting it because of the resulting wrong header in the package.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (SLING-6617) Improve dev-level documentation for SCD

[Tommaso Teofili (JIRA)]

Tommaso Teofili created SLING-6617:
--

 Summary: Improve dev-level documentation for SCD
 Key: SLING-6617
 URL: https://issues.apache.org/jira/browse/SLING-6617
 Project: Sling
  Issue Type: Task
  Components: Content Distribution
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili


It'd be nice to have a good technical documentation about SCD.
While on one hand [1] should cover user level documentation, it would be useful 
for developers to have a more technical one, that should be placed near to the 
code [2] and expanded to reflect recent changes.

[1] : http://sling.apache.org/documentation/bundles/content-distribution.html
[2] : 
https://github.com/apache/sling/blob/trunk/contrib/extensions/distribution/README.md



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (SLING-4540) Update sling distribution documentation to reflect latest changes

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-4540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili resolved SLING-4540.

Resolution: Fixed

> Update sling distribution documentation to reflect latest changes
> -
>
> Key: SLING-4540
> URL: https://issues.apache.org/jira/browse/SLING-4540
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Reporter: Marius Petria
>Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (SLING-6325) Split Avro and Kryo serializers into their own bundles

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili resolved SLING-6325.

   Resolution: Fixed
Fix Version/s: Content Distribution Extensions 0.1.0

> Split Avro and Kryo serializers into their own bundles
> --
>
> Key: SLING-6325
> URL: https://issues.apache.org/jira/browse/SLING-6325
> Project: Sling
>  Issue Type: Task
>  Components: Content Distribution
>        Reporter: Tommaso Teofili
>    Assignee: Tommaso Teofili
> Fix For: Content Distribution Extensions 0.1.0
>
>
> A while ago we created the _sling.distribution.extensions_ bundle to host 
> some PoCs for SCD extension points.
> Now that the {{DistributionContentSerializer}} API is exposed it'd be 
> probably better to create two separate bundles for Kryo and Avro serializers 
> as it's more likely that people will only use one of those serializers only, 
> also for decoupling and separation of dependencies concerns.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (SLING-6611) Improve FileVaultContentSerializer performance

[Tommaso Teofili (JIRA)]

Tommaso Teofili created SLING-6611:
--

 Summary: Improve FileVaultContentSerializer performance
 Key: SLING-6611
 URL: https://issues.apache.org/jira/browse/SLING-6611
 Project: Sling
  Issue Type: Improvement
  Components: Content Distribution
Reporter: Tommaso Teofili
 Fix For: Content Distribution Core 0.2.8


It would be good if we could improve FileVault serializer performance by 
avoiding writing several (temp) files on FS and avoid compressing binaries that 
are already compressed (e.g. images like jpg, png, etc.).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [VOTE] Release Apache Sling Content Distribution Core version 0.2.6

[Tommaso Teofili]

+1 (unbinding)

Regards,
Tommaso

Il giorno gio 2 mar 2017 alle ore 14:43 Oliver Lietz 
ha scritto:

> On Thursday 02 March 2017 13:34:12 Timothee Maret wrote:
> > Hi,
> >
> > We solved 4 issues in this release:
> > https://issues.apache.org/jira/browse/SLING/fixforversion/12339616
>
> +1
>
> O.
>
> > There are still some outstanding issues:
> > https://issues.apache.org/jira/browse/SLING/component/12323405
>
> (for those 5 open issues fix version needs to be adjusted)
>
>

[jira] [Commented] (SLING-6566) ResourceDistributionPackageBuilder package files are never collected

[Tommaso Teofili (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15882959#comment-15882959
 ] 

Tommaso Teofili commented on SLING-6566:


they should be definitely removed, if that's not the case it's a bug.

> ResourceDistributionPackageBuilder package files are never collected
> 
>
> Key: SLING-6566
> URL: https://issues.apache.org/jira/browse/SLING-6566
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.4
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Content Distribution Core 0.2.6
>
>
> While testing SCD with Sling running the tempdir on a ramdisk, I noticed the 
> temporary files created to contain the content package at
> https://github.com/apache/sling/blob/trunk/contrib/extensions/distribution/core/src/main/java/org/apache/sling/distribution/packaging/impl/FileDistributionPackageBuilder.java#L86
> are never removed, even when the distribution succeeds.
> [~teofili] is this a known issue or expected behaviour ? I would expect those 
> files should be removed when no longer used. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (SLING-6564) Failures in queue processing do not appear in the SLF4J logging

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili resolved SLING-6564.

Resolution: Fixed

fixed in r1784266.

> Failures in queue processing do not appear in the SLF4J logging
> ---
>
> Key: SLING-6564
> URL: https://issues.apache.org/jira/browse/SLING-6564
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.4
>    Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution Core 0.2.6
>
>
> {{SimpleDistributionAgentQueueProcessor}} only logs on {{DistributionLog}} 
> whereas it should also log on a plain {{Logger}} because admins often look at 
> the latter first.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (SLING-6564) Failures in queue processing do not appear in the SLF4J logging

[Tommaso Teofili (JIRA)]

Tommaso Teofili created SLING-6564:
--

 Summary: Failures in queue processing do not appear in the SLF4J 
logging
 Key: SLING-6564
 URL: https://issues.apache.org/jira/browse/SLING-6564
 Project: Sling
  Issue Type: Bug
  Components: Content Distribution
Affects Versions: Content Distribution Core 0.2.4
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
 Fix For: Content Distribution Core 0.2.6


{{SimpleDistributionAgentQueueProcessor}} only logs on {{DistributionLog}} 
whereas it should also log on a plain {{Logger}} because admins often look at 
the latter first.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6325) Split Avro and Kryo serializers into their own bundles

[Tommaso Teofili (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15880648#comment-15880648
 ] 

Tommaso Teofili commented on SLING-6325:


split done in r1784154.

> Split Avro and Kryo serializers into their own bundles
> --
>
> Key: SLING-6325
> URL: https://issues.apache.org/jira/browse/SLING-6325
> Project: Sling
>  Issue Type: Task
>  Components: Content Distribution
>        Reporter: Tommaso Teofili
>    Assignee: Tommaso Teofili
>
> A while ago we created the _sling.distribution.extensions_ bundle to host 
> some PoCs for SCD extension points.
> Now that the {{DistributionContentSerializer}} API is exposed it'd be 
> probably better to create two separate bundles for Kryo and Avro serializers 
> as it's more likely that people will only use one of those serializers only, 
> also for decoupling and separation of dependencies concerns.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (SLING-6554) Cache resource package size

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili resolved SLING-6554.

Resolution: Fixed

fixed in r1784108.

> Cache resource package size
> ---
>
> Key: SLING-6554
> URL: https://issues.apache.org/jira/browse/SLING-6554
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>        Reporter: Tommaso Teofili
>    Assignee: Tommaso Teofili
>Priority: Minor
> Fix For: Content Distribution Core 0.2.6
>
>
> {{ResourceDistributionPackage}} size should be calculated exactly once at 
> instance creation time, that would reduce the amount of reads on the 
> repository.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (SLING-6554) Cache resource package size

[Tommaso Teofili (JIRA)]

Tommaso Teofili created SLING-6554:
--

 Summary: Cache resource package size
 Key: SLING-6554
 URL: https://issues.apache.org/jira/browse/SLING-6554
 Project: Sling
  Issue Type: Improvement
  Components: Content Distribution
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
Priority: Minor
 Fix For: Content Distribution Core 0.2.6


{{ResourceDistributionPackage}} size should be calculated exactly once at 
instance creation time, that would reduce the amount of reads on the repository.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [VOTE] Release Apache Sling Content Distribution Core 0.2.4

[Tommaso Teofili]

+1 (not binding)

Tommaso

Il giorno ven 17 feb 2017 alle ore 15:14 Carsten Ziegeler <
cziege...@apache.org> ha scritto:

> +1
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

[jira] [Resolved] (SLING-6523) Priority queues are wrongly set as passive

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili resolved SLING-6523.

Resolution: Fixed

fixed in r1783186.

> Priority queues are wrongly set as passive
> --
>
> Key: SLING-6523
> URL: https://issues.apache.org/jira/browse/SLING-6523
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.0
>    Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution Core 0.2.2
>
>
> When configuring priority queues, they are wrongly set as _passive_ therefore 
> items in there are not processed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6523) Priority queues are wrongly set as passive

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili updated SLING-6523:
---
Description: When configuring priority queues, they are wrongly set as 
_passive_ therefore items in there are not processed.  (was: When configuring 
priority queues, they are wrongly set as _passive_.)

> Priority queues are wrongly set as passive
> --
>
> Key: SLING-6523
> URL: https://issues.apache.org/jira/browse/SLING-6523
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.0
>    Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution Core 0.2.2
>
>
> When configuring priority queues, they are wrongly set as _passive_ therefore 
> items in there are not processed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (SLING-6523) Priority queues are wrongly set as passive

[Tommaso Teofili (JIRA)]

Tommaso Teofili created SLING-6523:
--

 Summary: Priority queues are wrongly set as passive
 Key: SLING-6523
 URL: https://issues.apache.org/jira/browse/SLING-6523
 Project: Sling
  Issue Type: Bug
  Components: Content Distribution
Affects Versions: Content Distribution Core 0.2.0
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
 Fix For: Content Distribution Core 0.2.2


When configuring priority queues, they are wrongly set as _passive_.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6512) Distribution ITs fail as they expect packages to be deleted synchronously

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili updated SLING-6512:
---
Attachment: SLING-6512.0.patch

attaching a patch which I think it could fix the issue by setting a shorter 
cleanup delay within the VaultFactories, however the IT failures stay. 


> Distribution ITs fail as they expect packages to be deleted synchronously
> -
>
> Key: SLING-6512
> URL: https://issues.apache.org/jira/browse/SLING-6512
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>        Reporter: Tommaso Teofili
>    Assignee: Tommaso Teofili
> Attachments: SLING-6512.0.patch
>
>
> After the fix for SLING-6503, packages are not deleted upon release 
> synchronously, they are removed asynchronously in a separate thread.
> We should adjust the test not to expect such packages to be removed 
> immediately after their processing, /cc [~marett]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (SLING-6514) Test distributions should not go through the queues

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili resolved SLING-6514.

Resolution: Fixed

fixed in r1782306.


> Test distributions should not go through the queues
> ---
>
> Key: SLING-6514
> URL: https://issues.apache.org/jira/browse/SLING-6514
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.1.18
>    Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution Core 0.2.2
>
>
> When performing distributions of type TEST the test package goes through the 
> packages like any other package, this should not be the case as TEST 
> distributions are usually meant to check that the agent can deliver 
> (permissions and network / disk IO are fine) and therefore they should be 
> delivered without going through the queues.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (SLING-6514) Test distributions should not go through the queues

[Tommaso Teofili (JIRA)]

Tommaso Teofili created SLING-6514:
--

 Summary: Test distributions should not go through the queues
 Key: SLING-6514
 URL: https://issues.apache.org/jira/browse/SLING-6514
 Project: Sling
  Issue Type: Bug
  Components: Content Distribution
Affects Versions: Content Distribution Core 0.1.18
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
 Fix For: Content Distribution Core 0.2.2


When performing distributions of type TEST the test package goes through the 
packages like any other package, this should not be the case as TEST 
distributions are usually meant to check that the agent can deliver 
(permissions and network / disk IO are fine) and therefore they should be 
delivered without going through the queues.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (SLING-6512) Distribution ITs fail as they expect packages to be deleted synchronously

[Tommaso Teofili (JIRA)]

Tommaso Teofili created SLING-6512:
--

 Summary: Distribution ITs fail as they expect packages to be 
deleted synchronously
 Key: SLING-6512
 URL: https://issues.apache.org/jira/browse/SLING-6512
 Project: Sling
  Issue Type: Bug
  Components: Content Distribution
Reporter: Tommaso Teofili


After the fix for SLING-6503, packages are not deleted upon release 
synchronously, they are removed asynchronously in a separate thread.
We should adjust the test not to expect such packages to be removed immediately 
after their processing, /cc [~marett]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [VOTE] Release Apache Sling Content Distribution Core 0.2.0

[Tommaso Teofili]

+1 (not binding)

Tommaso

Il giorno mar 7 feb 2017 alle ore 17:19 Timothee Maret 
ha scritto:

> Hi,
>
> We solved 50 issues in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12328963
>
> There are still some outstanding issues:
> https://issues.apache.org/jira/browse/SLING/component/12323405
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1634/
>
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 1634 /tmp/sling-staging
>
> Please vote to approve this release:
>
>   [ ] +1 Approve the release
>   [ ]  0 Don't care
>   [ ] -1 Don't release, because ...
>
> This majority vote is open for at least 72 hours.
>

[jira] [Commented] (SLING-6503) Concurrency issue can prevent repository packages to be cleaned up

[Tommaso Teofili (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15851579#comment-15851579
 ] 

Tommaso Teofili commented on SLING-6503:


+1 LGTM

> Concurrency issue can prevent repository packages to be cleaned up   
> -
>
> Key: SLING-6503
> URL: https://issues.apache.org/jira/browse/SLING-6503
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Content Distribution Core 0.1.20
>
> Attachments: SLING-6503.patch
>
>
> In SCD setups with more than one export queue and storing packages in the 
> repository, packages may not be collected after being distributed to all 
> queues.
> This is typically the case on the author instance of a Sync setup.
> The current implementation [0] stores a resource in the repository in order 
> to keep track of each consumer of the package. When each consumer is done 
> distributing to its queue, it checks if there is no more registered resources 
> and remove the package if it is the case.
> The problem is that consumers run concurrently and without synchronisation, 
> thus leading to situation where all consumers concurrently observe remaining 
> consumers and the cleanup is never executed.
> [0] 
> https://github.com/apache/sling/blob/trunk/contrib/extensions/distribution/core/src/main/java/org/apache/sling/distribution/packaging/impl/ResourceDistributionPackage.java



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Deleted] (SLING-6456) Local importer should not fail if package stream is unnecessarily reset

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili deleted SLING-6456:
---


> Local importer should not fail if package stream is unnecessarily reset
> ---
>
> Key: SLING-6456
> URL: https://issues.apache.org/jira/browse/SLING-6456
> Project: Sling
>  Issue Type: Bug
>    Reporter: Tommaso Teofili
>        Assignee: Tommaso Teofili
>
> {{LocalDistributionPackageImporter}} has a {{InputStream#reset}} call at the 
> beginning of the block for handling non reference package as to support also 
> those package sent by the {{AsyncDeliveryDispatchingStrategy}}. 
> Currently it fails if reset is called unnecessarily, while it shouldn't be 
> the case.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-5759) Distribution agents cannot be created via API

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili resolved SLING-5759.

   Resolution: Fixed
Fix Version/s: Content Distribution 0.2.0

> Distribution agents cannot be created via API
> -
>
> Key: SLING-5759
> URL: https://issues.apache.org/jira/browse/SLING-5759
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Reporter: Marius Petria
> Fix For: Content Distribution 0.2.0
>
>
> The IT tes 
> {{DistributionAgentResourcesIntegrationTest.testAgentConfigurationResourceCreate}}
>  fails and should be fixed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-3311) Add facilities to monitor replication status

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili resolved SLING-3311.

   Resolution: Fixed
Fix Version/s: Content Distribution 0.2.0

> Add facilities to monitor replication status
> 
>
> Key: SLING-3311
> URL: https://issues.apache.org/jira/browse/SLING-3311
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>        Reporter: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
>
> It'd be good to have one or more ways of monitoring the status of replication 
> agents / queues / etc.
> Possible (not mutually exclusive) ways of doing that include: JMX, Sling 
> HealthChecks, HTTP Monitoring API.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-4575) Failure registering MBean HealthCheckMBean [healthCheck=org.apache.sling.distribution.monitor.DistributionQueueHealthCheck@...]

[Tommaso Teofili (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-4575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830035#comment-15830035
 ] 

Tommaso Teofili commented on SLING-4575:


I think this has been resolved already, [~olli] WDYT? 

> Failure registering MBean HealthCheckMBean 
> [healthCheck=org.apache.sling.distribution.monitor.DistributionQueueHealthCheck@...]
> ---
>
> Key: SLING-4575
> URL: https://issues.apache.org/jira/browse/SLING-4575
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution 0.1.0
> Environment: Apache Karaf 3.0.3
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>
> {noformat}
> 2015-04-03 10:04:36,282 | INFO  | FelixStartLevel  | 
> DistributionQueueHealthCheck | 169 - org.apache.sling.distribution.core - 
> 0.1.0 | Activated, numberOfRetriesAllowed=3
> 2015-04-03 10:04:36,285 | ERROR | FelixStartLevel  | MBeanHolder  
> | 85 - org.apache.aries.jmx.whiteboard - 1.0.0 | register: Failure 
> registering MBean HealthCheckMBean 
> [healthCheck=org.apache.sling.distribution.monitor.DistributionQueueHealthCheck@36a6f19c]
> javax.management.InstanceAlreadyExistsException: 
> org.apache.sling.healthcheck:type=HealthCheck,name=slingDistributionQueue
>   at 
> com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)[:1.8.0_40]
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)[:1.8.0_40]
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)[:1.8.0_40]
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)[:1.8.0_40]
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)[:1.8.0_40]
>   at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)[:1.8.0_40]
>   at Proxya4a7f910_bd0e_4598_92cf_9a73d8dff844.registerMBean(Unknown 
> Source)
>   at 
> org.apache.aries.jmx.whiteboard.MBeanHolder.register(MBeanHolder.java:114)
>   at 
> org.apache.aries.jmx.whiteboard.JmxWhiteboardSupport.registerMBean(JmxWhiteboardSupport.java:86)
>   at 
> org.apache.aries.jmx.whiteboard.Activator$MBeanTracker.addingService(Activator.java:102)
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:932)[karaf-org.osgi.core.jar:]
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:864)[karaf-org.osgi.core.jar:]
>   at 
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)[karaf-org.osgi.core.jar:]
>   at 
> org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)[karaf-org.osgi.core.jar:]
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:894)[karaf-org.osgi.core.jar:]
>   at 
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932)[org.apache.felix.framework-4.2.1.jar:]
>   at 
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)[org.apache.felix.framework-4.2.1.jar:]
>   at 
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)[org.apache.felix.framework-4.2.1.jar:]
>   at 
> org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4419)[org.apache.felix.framework-4.2.1.jar:]
>   at 
> org.apache.felix.framework.Felix.registerService(Felix.java:3423)[org.apache.felix.framework-4.2.1.jar:]
>   at 
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346)
>   at 
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:320)
>   at 
> org.apache.sling.hc.jmx.impl.HealthCheckMBeanCreator$Registration.register(HealthCheckMBeanCreator.java:177)
>   at 
> org.apache.sling.hc.jmx.impl.HealthCheckMBeanCreator.registerHCMBean(HealthCheckMBeanCreator.java:121)
>   at 
> org.apache.sling.hc.jmx.impl.HealthCheckMBeanCreator.access$000(HealthCheckMBeanCreator.java:46)
>   at 
> org.apache.sling.hc.jmx.impl.HealthCheckMBeanCreator$1.addingService(HealthCheckMBeanCreator.java:62)
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:932)[karaf-org.osgi

[jira] [Resolved] (SLING-5915) Fix IT failures in Content Distribution

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili resolved SLING-5915.

Resolution: Duplicate

> Fix IT failures in Content Distribution
> ---
>
> Key: SLING-5915
> URL: https://issues.apache.org/jira/browse/SLING-5915
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>        Reporter: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
>
> Currently there're the following IT failures that we should fix before 
> releasing SDC core 0.2.0.
> {noformat}
> Tests run: 13, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 215.478 sec 
> <<< FAILURE! - in 
> org.apache.sling.distribution.it.DistributionAgentResourcesIntegrationTest
> testAgentConfigurationResourceExtended(org.apache.sling.distribution.it.DistributionAgentResourcesIntegrationTest)
>   Time elapsed: 100.974 sec  <<< FAILURE!
> java.lang.AssertionError: path 
> /etc/distribution/sample-create-config067f89fb-b059-4fde-84c8-411130681261 
> doesn't exist
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at 
> org.apache.sling.distribution.it.DistributionUtils.assertExists(DistributionUtils.java:198)
>   at 
> org.apache.sling.distribution.it.DistributionAgentResourcesIntegrationTest.testAgentConfigurationResourceExtended(DistributionAgentResourcesIntegrationTest.java:174)
> Tests run: 4, Failures: 3, Errors: 1, Skipped: 0, Time elapsed: 46.174 sec 
> <<< FAILURE! - in 
> org.apache.sling.distribution.it.MultipleForwardDistributionTest
> testDeleteContent(org.apache.sling.distribution.it.MultipleForwardDistributionTest)
>   Time elapsed: 9.193 sec  <<< FAILURE!
> java.lang.AssertionError: POST request to 
> http://localhost:59247/libs/sling/distribution/services/agents/publish-multiple/queues/passivequeue1:
>  expecting status 200 expected:<200> but was:<500>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:743)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:555)
>   at 
> org.apache.sling.testing.tools.http.RequestExecutor.assertStatus(RequestExecutor.java:155)
>   at 
> org.apache.sling.distribution.it.DistributionUtils.assertPostResourceWithParameters(DistributionUtils.java:96)
>   at 
> org.apache.sling.distribution.it.MultipleForwardDistributionTest.clean(MultipleForwardDistributionTest.java:103)
> testAddContentCheckPassiveQueue(org.apache.sling.distribution.it.MultipleForwardDistributionTest)
>   Time elapsed: 9.197 sec  <<< ERROR!
> org.apache.sling.commons.json.JSONException: JSONObject["items"] not found.
>   at org.apache.sling.commons.json.JSONObject.get(JSONObject.java:372)
>   at 
> org.apache.sling.commons.json.JSONObject.getJSONArray(JSONObject.java:448)
>   at 
> org.apache.sling.distribution.it.MultipleForwardDistributionTest.testAddContentCheckPassiveQueue(MultipleForwardDistributionTest.java:75)
> testAddContentCheckPassiveQueue(org.apache.sling.distribution.it.MultipleForwardDistributionTest)
>   Time elapsed: 9.197 sec  <<< FAILURE!
> java.lang.AssertionError: POST request to 
> http://localhost:59247/libs/sling/distribution/services/agents/publish-multiple/queues/passivequeue1:
>  expecting status 200 expected:<200> but was:<500>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:743)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:555)
>   at 
> org.apache.sling.testing.tools.http.RequestExecutor.assertStatus(RequestExecutor.java:155)
>   at 
> org.apache.sling.distribution.it.DistributionUtils.assertPostResourceWithParameters(DistributionUtils.java:96)
>   at 
> org.apache.sling.distribution.it.MultipleForwardDistributionTest.clean(MultipleForwardDistributionTest.java:103)
> testAddContent(org.apache.sling.distribution.it.MultipleForwardDistributionTest)
>   Time elapsed: 9.197 sec  <<< FAILURE!
> java.lang.AssertionError: POST request to 
> http://localhost:59247/libs/sling/distribution/services/agents/publish-multiple/queues/passivequeue1:
>  expecting status 200 expected:<200> but was:<500>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:743)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Asser

[jira] [Resolved] (SLING-6391) DefaultDistributionConfigurationManager overrides existing persisted properties

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili resolved SLING-6391.

Resolution: Fixed

> DefaultDistributionConfigurationManager overrides existing persisted 
> properties
> ---
>
> Key: SLING-6391
> URL: https://issues.apache.org/jira/browse/SLING-6391
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>    Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
>
> {{DefaultDistributionConfigurationManager}} doesn't take care of existing 
> properties in the resource tree, so that persisted configs are not merged.
> Also defaults sometimes override actual parameters.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6251) SCD integration tests fail due to blocked loginAdministrative

[Tommaso Teofili (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830025#comment-15830025
 ] 

Tommaso Teofili commented on SLING-6251:


we have removed _loginAdmin_ and they now pass thanks to [~marett]'s work on 
SLING-6475.

> SCD integration tests fail due to blocked loginAdministrative
> -
>
> Key: SLING-6251
> URL: https://issues.apache.org/jira/browse/SLING-6251
> Project: Sling
>  Issue Type: Task
>  Components: Content Distribution
>Reporter: Julian Sedding
>Assignee: Julian Sedding
> Fix For: Content Distribution 0.2.0
>
>
> The Sling Content Distribution integration tests currently fail due to 
> {{loginAdministrative}} being blocked.
> The log files of the tested instances show messages like these:
> {noformat}
> 02.11.2016 11:15:35.056 *ERROR* [qtp875477671-46] 
> org.apache.sling.event.impl.jobs Unable to create new resource resolver: 
> Bundle is not whitelisted for loginAdministrative:org.apache.sling.event
> org.apache.sling.api.resource.LoginException: Bundle is not whitelisted for 
> loginAdministrative:org.apache.sling.event
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrProviderStateFactory.checkLoginAdminWhitelist(JcrProviderStateFactory.java:93)
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrProviderStateFactory.createProviderState(JcrProviderStateFactory.java:111)
> {noformat}
> At least the Event bundle needs to be updated and the "Sling Distribution 
> Sample" needs to be adjusted to refrain from using {{loginAdministrative}}.
> cc [~teofili], [~simone.tripodi]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-6251) SCD integration tests fail due to blocked loginAdministrative

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili resolved SLING-6251.

   Resolution: Fixed
Fix Version/s: Content Distribution 0.2.0

> SCD integration tests fail due to blocked loginAdministrative
> -
>
> Key: SLING-6251
> URL: https://issues.apache.org/jira/browse/SLING-6251
> Project: Sling
>  Issue Type: Task
>  Components: Content Distribution
>Reporter: Julian Sedding
>Assignee: Julian Sedding
> Fix For: Content Distribution 0.2.0
>
>
> The Sling Content Distribution integration tests currently fail due to 
> {{loginAdministrative}} being blocked.
> The log files of the tested instances show messages like these:
> {noformat}
> 02.11.2016 11:15:35.056 *ERROR* [qtp875477671-46] 
> org.apache.sling.event.impl.jobs Unable to create new resource resolver: 
> Bundle is not whitelisted for loginAdministrative:org.apache.sling.event
> org.apache.sling.api.resource.LoginException: Bundle is not whitelisted for 
> loginAdministrative:org.apache.sling.event
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrProviderStateFactory.checkLoginAdminWhitelist(JcrProviderStateFactory.java:93)
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrProviderStateFactory.createProviderState(JcrProviderStateFactory.java:111)
> {noformat}
> At least the Event bundle needs to be updated and the "Sling Distribution 
> Sample" needs to be adjusted to refrain from using {{loginAdministrative}}.
> cc [~teofili], [~simone.tripodi]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)