Re: [VOTE] Release Apache Sling XSS Protection API 2.2.10
+1 On Mon, Feb 15, 2021 at 8:33 AM Julian Sedding wrote: > +1 > > Regards > Julian > > On Mon, Feb 15, 2021 at 2:22 PM Carsten Ziegeler > wrote: > > > > +1 > > > > Carsten > > > > Am 15.02.2021 um 11:45 schrieb Radu Cotescu: > > > Hi, > > > > > > We solved 2 issues in this release: > > > https://issues.apache.org/jira/browse/SLING/fixforversion/12349351 > > > > > > Staging repository: > > > > https://repository.apache.org/content/repositories/orgapachesling-2411/ > > > > > > You can use this UNIX script to download the release and verify the > signatures: > > > > https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD > > > > > > Usage: > > > sh check_staged_release.sh 2411 /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. > > > > > > Regards, > > > Radu Cotescu > > > > > > > -- > > -- > > Carsten Ziegeler > > Adobe Research Switzerland > > cziege...@apache.org >
Running Apache Sling on Apache Karaf on OpenShift
We run multiple application pods on OpenShift(AWS) that talk to an external mongo db cluster which spreads out in datacenters(not AWS). During a deployment, it normally takes about 10 mins for "Apache Sling Repository Startup Thread" to do its thing. What is it doing? Any idea what it takes so long? Why is every application pod doing repository startup? Do you recommend attaching a persistent volume to the application pods? Is there a way for Sling to tell other pods there is no need to do repository startup if it was done already? -- Lisa Davidson, RHCE Sr. Software Engineer Red Hat, Inc.
Re: [VOTE] Release Apache Sling Repoinit Parser 1.6.6, Repoinit JCR 1.1.32
+1 regards, Karl On Mon, Feb 15, 2021 at 6:59 AM Carsten Ziegeler wrote: > > +1 > > Carsten > > Am 12.02.2021 um 17:25 schrieb Bertrand Delacretaz: > > Hi, > > > > We solved 2 issues in this release: > > > > https://issues.apache.org/jira/projects/SLING/versions/12349670 > > https://issues.apache.org/jira/projects/SLING/versions/12349669 > > > > Staging repository: > > https://repository.apache.org/content/repositories/orgapachesling-2410 > > > > You can use this UNIX script to download the release and verify the > > signatures: > > https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD > > > > Usage: > > sh check_staged_release.sh 2410 /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. > > > > Here's my +1 > > > > -Bertrand > > > > -- > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org -- Karl Pauls karlpa...@gmail.com
[jira] [Comment Edited] (SLING-10143) bundles referenced in sling starter are out of date
[
https://issues.apache.org/jira/browse/SLING-10143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17284991#comment-17284991
]
Eric Norman edited comment on SLING-10143 at 2/16/21, 1:14 AM:
---
FYI: If I recall correctly, the apache jackrabbit project uses the even-odd
policy for numbering their release versions. The even numbered releases are
the stable releases that are ready for production, while the odd numbered
releases are considered unstable and only suitable for testing. So while
2.21.5 is the largest version number of jackrabbit, that is an unstable release
and you would probably want to use the the latest (stable) even numbered
release 2.20.2 instead.
Also, is there any chance you can submit the changes as a github pull request
instead of attaching patch files? I find those a bit easier to review.
I use a custom maven-version-rules.xml locally to filter out some of the known
bad versions that exist in central from consideration in the
versions:display-dependency-updates report. I could share that somewhere if
anyone is interested.
was (Author: enorman):
FYI: If I recall correctly, the apache jackrabbit project uses the even-odd
policy for numbering their release versions. The even numbered releases are
the stable releases that are ready for production, while the odd numbered
releases are considered unstable and only suitable for testing. So while
2.21.5 is the largest version number of jackrabbit, that is an unstable release
and you would probably want to use the the latest (stable) even numbered
release 2.20.2 instead.
Also, is there any chance you can submit the changes as a github pull request
instead of attaching patch files? I find those a bit easier to review.
> bundles referenced in sling starter are out of date
> ---
>
> Key: SLING-10143
> URL: https://issues.apache.org/jira/browse/SLING-10143
> Project: Sling
> Issue Type: Improvement
> Components: Starter
>Reporter: Ruben Reusser
>Priority: Major
> Fix For: Starter 12
>
> Attachments:
> 0001-updated-3rd-party-dependencies-of-sling-starter.patch,
> 0002-javax.activation-dependency-needed-to-be-increased.patch,
> 0003-updated-to-latest-sling-bundles-added-missing-felix-.patch
>
>
> Would be nice to make sure the sling starter uses the latest bundles -
> according to
> {code:java}
> mvn versions:display-dependency-updates{code}
> the sling starter is a bit out of date with the dependencies
> {code:java}
> [INFO] The following dependencies in Dependencies have newer versions:
> [INFO] com.composum.nodes:composum-nodes-commons . 2.1.1 ->
> 2.3.0
> [INFO] com.composum.nodes:composum-nodes-console . 2.1.1 ->
> 2.3.0
> [INFO] com.composum.nodes:composum-nodes-jslibs .. 2.1.1 ->
> 2.3.0
> [INFO] com.composum.nodes:composum-nodes-pckgmgr . 2.1.1 ->
> 2.3.0
> [INFO] com.composum.nodes:composum-nodes-usermgr . 2.1.1 ->
> 2.3.0
> [INFO] com.fasterxml.jackson.core:jackson-annotations .. 2.11.1 ->
> 2.12.1
> [INFO] com.fasterxml.jackson.core:jackson-core . 2.11.1 ->
> 2.12.1
> [INFO] com.fasterxml.jackson.core:jackson-databind . 2.11.1 ->
> 2.12.1
> [INFO] com.google.guava:guava .. 15.0 ->
> 30.1-jre
> [INFO] com.h2database:h2-mvstore . 1.4.194 ->
> 1.4.200
> [INFO] commons-codec:commons-codec . 1.14 ->
> 1.15
> [INFO] commons-collections:commons-collections 3.2.2 ->
> 20040616
> [INFO] commons-io:commons-io ... 2.6 ->
> 2.8.0
> [INFO] io.dropwizard.metrics:metrics-core . 3.2.6 ->
> 4.2.0-beta.1
> [INFO] org.antlr:antlr4-runtime .. 4.7.2 ->
> 4.9.1
> [INFO] org.apache.commons:commons-lang3 . 3.9 ->
> 3.11
> [INFO] org.apache.felix:org.apache.felix.configadmin ... 1.9.16 ->
> 1.9.20
> [INFO] org.apache.felix:org.apache.felix.eventadmin .. 1.5.0 ->
> 1.6.2
> [INFO] org.apache.felix:org.apache.felix.http.jetty . 4.0.18 ->
> 4.1.4
> [INFO] org.apache.felix:org.apache.felix.metatype 1.2.2 ->
> 1.2.4
> [INFO] org.apache.felix:org.apache.felix.scr ... 2.1.20 ->
> 2.1.24
> [INFO] org.apache.felix:org.apache.felix.utils . 1.11.2 ->
> 1.11.6
> [INFO] org.apache.felix:org.apache.felix.webconsole .. 4.5.0 ->
> 4.6.0
> [INFO] org.apache.geronimo.specs:geronimo-annotation_1.3_spec 1.1 ->
> 1.3
> [INFO] org.apache.geronimo.specs:geronimo-atinject_1.0_spec .. 1.1 ->
> 1.2
> [INFO] org.apache.httpcomponents:httpclient 4.5.10 ->
> 4.5.13
> [INFO]
[jira] [Commented] (SLING-10143) bundles referenced in sling starter are out of date
[
https://issues.apache.org/jira/browse/SLING-10143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17284991#comment-17284991
]
Eric Norman commented on SLING-10143:
-
FYI: If I recall correctly, the apache jackrabbit project uses the even-odd
policy for numbering their release versions. The even numbered releases are
the stable releases that are ready for production, while the odd numbered
releases are considered unstable and only suitable for testing. So while
2.21.5 is the largest version number of jackrabbit, that is an unstable release
and you would probably want to use the the latest (stable) even numbered
release 2.20.2 instead.
Also, is there any chance you can submit the changes as a github pull request
instead of attaching patch files? I find those a bit easier to review.
> bundles referenced in sling starter are out of date
> ---
>
> Key: SLING-10143
> URL: https://issues.apache.org/jira/browse/SLING-10143
> Project: Sling
> Issue Type: Improvement
> Components: Starter
>Reporter: Ruben Reusser
>Priority: Major
> Fix For: Starter 12
>
> Attachments:
> 0001-updated-3rd-party-dependencies-of-sling-starter.patch,
> 0002-javax.activation-dependency-needed-to-be-increased.patch,
> 0003-updated-to-latest-sling-bundles-added-missing-felix-.patch
>
>
> Would be nice to make sure the sling starter uses the latest bundles -
> according to
> {code:java}
> mvn versions:display-dependency-updates{code}
> the sling starter is a bit out of date with the dependencies
> {code:java}
> [INFO] The following dependencies in Dependencies have newer versions:
> [INFO] com.composum.nodes:composum-nodes-commons . 2.1.1 ->
> 2.3.0
> [INFO] com.composum.nodes:composum-nodes-console . 2.1.1 ->
> 2.3.0
> [INFO] com.composum.nodes:composum-nodes-jslibs .. 2.1.1 ->
> 2.3.0
> [INFO] com.composum.nodes:composum-nodes-pckgmgr . 2.1.1 ->
> 2.3.0
> [INFO] com.composum.nodes:composum-nodes-usermgr . 2.1.1 ->
> 2.3.0
> [INFO] com.fasterxml.jackson.core:jackson-annotations .. 2.11.1 ->
> 2.12.1
> [INFO] com.fasterxml.jackson.core:jackson-core . 2.11.1 ->
> 2.12.1
> [INFO] com.fasterxml.jackson.core:jackson-databind . 2.11.1 ->
> 2.12.1
> [INFO] com.google.guava:guava .. 15.0 ->
> 30.1-jre
> [INFO] com.h2database:h2-mvstore . 1.4.194 ->
> 1.4.200
> [INFO] commons-codec:commons-codec . 1.14 ->
> 1.15
> [INFO] commons-collections:commons-collections 3.2.2 ->
> 20040616
> [INFO] commons-io:commons-io ... 2.6 ->
> 2.8.0
> [INFO] io.dropwizard.metrics:metrics-core . 3.2.6 ->
> 4.2.0-beta.1
> [INFO] org.antlr:antlr4-runtime .. 4.7.2 ->
> 4.9.1
> [INFO] org.apache.commons:commons-lang3 . 3.9 ->
> 3.11
> [INFO] org.apache.felix:org.apache.felix.configadmin ... 1.9.16 ->
> 1.9.20
> [INFO] org.apache.felix:org.apache.felix.eventadmin .. 1.5.0 ->
> 1.6.2
> [INFO] org.apache.felix:org.apache.felix.http.jetty . 4.0.18 ->
> 4.1.4
> [INFO] org.apache.felix:org.apache.felix.metatype 1.2.2 ->
> 1.2.4
> [INFO] org.apache.felix:org.apache.felix.scr ... 2.1.20 ->
> 2.1.24
> [INFO] org.apache.felix:org.apache.felix.utils . 1.11.2 ->
> 1.11.6
> [INFO] org.apache.felix:org.apache.felix.webconsole .. 4.5.0 ->
> 4.6.0
> [INFO] org.apache.geronimo.specs:geronimo-annotation_1.3_spec 1.1 ->
> 1.3
> [INFO] org.apache.geronimo.specs:geronimo-atinject_1.0_spec .. 1.1 ->
> 1.2
> [INFO] org.apache.httpcomponents:httpclient 4.5.10 ->
> 4.5.13
> [INFO] org.apache.httpcomponents:httpclient-osgi ... 4.5.10 ->
> 4.5.13
> [INFO] org.apache.httpcomponents:httpcore-osgi . 4.4.12 ->
> 4.4.14
> [INFO] org.apache.jackrabbit:jackrabbit-data ... 2.20.0 ->
> 2.21.5
> [INFO] org.apache.jackrabbit:jackrabbit-jcr-commons 2.20.0 ->
> 2.21.5
> [INFO] org.apache.jackrabbit:jackrabbit-jcr-rmi 2.20.0 ->
> 2.21.5
> [INFO] org.apache.jackrabbit:jackrabbit-spi 2.20.0 ->
> 2.21.5
> [INFO] org.apache.jackrabbit:jackrabbit-spi-commons 2.20.0 ->
> 2.21.5
> [INFO] org.apache.jackrabbit:jackrabbit-webdav . 2.20.0 ->
> 2.21.5
> [INFO] org.apache.jackrabbit:oak-api ... 1.32.0 ->
> 1.38.0
> [INFO] org.apache.jackrabbit:oak-authorization-principalbased ...
> [INFO] 1.32.0 ->
> 1.38.0
> [INFO] org.apache.jackrabbit:oak-blob
[jira] [Updated] (SLING-4075) Improve test coverage of SCD
[ https://issues.apache.org/jira/browse/SLING-4075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated SLING-4075: --- Fix Version/s: (was: Content Distribution Core 0.4.4) Content Distribution Core 0.4.6 > 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 >Assignee: Timothee Maret >Priority: Major > Fix For: Content Distribution Core 0.4.6 > > > 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 (v8.3.4#803005)
[jira] [Updated] (SLING-9332) Error logged for NonRecoverableDistributionException in SimpleDistributionAgentQueueProcessor does not log queuename
[
https://issues.apache.org/jira/browse/SLING-9332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider updated SLING-9332:
---
Fix Version/s: (was: Content Distribution Core 0.4.4)
Content Distribution Core 0.4.6
> Error logged for NonRecoverableDistributionException in
> SimpleDistributionAgentQueueProcessor does not log queuename
>
>
> Key: SLING-9332
> URL: https://issues.apache.org/jira/browse/SLING-9332
> Project: Sling
> Issue Type: Bug
> Components: Content Distribution
>Reporter: Mohit Arora
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Core 0.4.6
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The [error message logged
> in|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/agent/impl/SimpleDistributionAgentQueueProcessor.java#L157]
> SimpleDistributionAgentQueueProcessor uses an _Object_ to log
> distributionpackage ID and queuename. However, from version 1.7 onward, log4j
> seems to have stopped processing the object arrays for log statements.
> Because of this the error logged in case of unsuccessful distribution looks
> like -
> {noformat}06.04.2020 07:48:30.411 *ERROR*
> [sling-default-1-resource-queueProcessor-bpdistributionagent0-queue-bpdistributionagent0]
>
> org.apache.sling.distribution.agent.impl.SimpleDistributionAgentQueueProcessor
> could not deliver package
> [dstrpck-1586159284848-e4c369fc-5bbf-4cfc-9ea3-2819af650784,
> queue-bpdistributionagent0] from queue {}
> org.apache.sling.distribution.common.DistributionException:
> org.apache.http.client.HttpResponseException: Bad Gateway
> at
> org.apache.sling.distribution.transport.impl.SimpleHttpDistributionTransport.deliverPackage(SimpleHttpDistributionTransport.java:162)
> [org.apache.sling.distribution.core:0.4.2]
> at
> org.apache.sling.distribution.packaging.impl.importer.RemoteDistributionPackageImporter.importPackage(RemoteDistributionPackageImporter.java:66)
> [org.apache.sling.distribution.core:0.4.2]
> at
> org.apache.sling.distribution.agent.impl.SimpleDistributionAgentQueueProcessor.processQueueItem(SimpleDistributionAgentQueueProcessor.java:134)
> [org.apache.sling.distribution.core:0.4.2]
> at
> org.apache.sling.distribution.agent.impl.SimpleDistributionAgentQueueProcessor.process(SimpleDistributionAgentQueueProcessor.java:91)
> [org.apache.sling.distribution.core:0.4.2]
> at
> org.apache.sling.distribution.queue.impl.simple.SimpleDistributionQueueProcessor.run(SimpleDistributionQueueProcessor.java:53)
> [org.apache.sling.distribution.core:0.4.2]
> at
> org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:347)
> [org.apache.sling.commons.scheduler:2.7.6]
> at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
> [org.apache.sling.commons.scheduler:2.7.6]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: org.apache.http.client.HttpResponseException: Bad Gateway
> at
> org.apache.http.impl.client.AbstractResponseHandler.handleResponse(AbstractResponseHandler.java:70)
> [org.apache.httpcomponents.httpclient:4.5.4]
> at
> org.apache.http.client.fluent.Response.handleResponse(Response.java:90)
> [org.apache.httpcomponents.httpclient:4.5.4]
> at
> org.apache.http.client.fluent.Response.returnContent(Response.java:97)
> [org.apache.httpcomponents.httpclient:4.5.4]
> at
> org.apache.sling.distribution.transport.impl.SimpleHttpDistributionTransport.deliverPackage(SimpleHttpDistributionTransport.java:148)
> [org.apache.sling.distribution.core:0.4.2]
> ... 9 common frames omitted{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-9873) A comma in node name causes Sling Content Distribution to fail
[ https://issues.apache.org/jira/browse/SLING-9873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated SLING-9873: --- Fix Version/s: (was: Content Distribution Core 0.4.4) Content Distribution Core 0.4.6 > A comma in node name causes Sling Content Distribution to fail > -- > > Key: SLING-9873 > URL: https://issues.apache.org/jira/browse/SLING-9873 > Project: Sling > Issue Type: Bug > Components: Content Distribution >Affects Versions: Content Distribution Core 0.4.2 >Reporter: Rahul Bhardwaj >Assignee: Timothee Maret >Priority: Major > Fix For: Content Distribution Core 0.4.6 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Sling content distribution uses comma as a path delimiter [0]but comma is a > valid jcr character name and hence must not be used as a path delimiter. > Usage of a comma in name breaks Delete operation of forward replication. > [0] - > https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/packaging/impl/SimpleDistributionPackage.java#L101 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-9582) OsgiConfigurationManager should use Configuration#getProcessedProperties
[ https://issues.apache.org/jira/browse/SLING-9582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated SLING-9582: --- Fix Version/s: (was: Content Distribution Core 0.4.4) Content Distribution Core 0.4.6 > OsgiConfigurationManager should use Configuration#getProcessedProperties > > > Key: SLING-9582 > URL: https://issues.apache.org/jira/browse/SLING-9582 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Affects Versions: Content Distribution Core 0.4.2 >Reporter: Carsten Ziegeler >Assignee: Christian Schneider >Priority: Major > Fix For: Content Distribution Core 0.4.6 > > Time Spent: 50m > Remaining Estimate: 0h > > OsgiConfigurationManager uses Configuration#getProperties to get properties > from an OSGi configuration (in two places). However, it should rather use > Configuration#getProcessedProperties(ServiceReference) instead. THis way > configuration plugins like the Apache Felix interpolation plugin are run -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-9363) SimpleDistributionAgentQueueProcessor performs duplicate logging
[
https://issues.apache.org/jira/browse/SLING-9363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider updated SLING-9363:
---
Fix Version/s: (was: Content Distribution Core 0.4.4)
Content Distribution Core 0.4.6
> SimpleDistributionAgentQueueProcessor performs duplicate logging
>
>
> Key: SLING-9363
> URL: https://issues.apache.org/jira/browse/SLING-9363
> Project: Sling
> Issue Type: Bug
> Components: Content Distribution
>Reporter: Ashish Chopra
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Core 0.4.6
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In case of recoverable distribution errors, currently the logs are being
> generated twice. AFAICT it has been the case since [0].
> While SLING-9030 tried to improve the situation, but at that time it wasn't
> realized that {{DefaultDistributionLog}} impl [1] not only collects the
> log-lines for distribution-log-servlet [2], but also logs them using slf4j
> loggers [3]. This causes duplicate logging to be generated for the location
> at [5].
> I propose that [5] be fixed to remove explicit logging on slf4j logger and
> just rely on {{DefaultDistributionLog}} instance.
> [0]
> https://github.com/apache/sling-org-apache-sling-distribution-core/commit/aae95faa14a56c5d5b4cc06cd1a331eb1e107a8b#diff-22682477f3d90f687d6e57f6754b9c86R149-R152
> [1]
> https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/log/impl/DefaultDistributionLog.java
> [2]
> https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/servlet/DistributionAgentLogServlet.java
> [3]
> https://github.com/apache/sling-org-apache-sling-distribution-core/blob/481ddec86400c7889899216e2edfc7bda66d1a2e/src/main/java/org/apache/sling/distribution/log/impl/DefaultDistributionLog.java#L103
> [5]
> https://github.com/apache/sling-org-apache-sling-distribution-core/blob/481ddec86400c7889899216e2edfc7bda66d1a2e/src/main/java/org/apache/sling/distribution/agent/impl/SimpleDistributionAgentQueueProcessor.java#L148-L152
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-10123) Distribution agent queue processor should implement a backoff in case of retries for processing an item
[ https://issues.apache.org/jira/browse/SLING-10123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated SLING-10123: Fix Version/s: (was: Content Distribution Core 0.4.4) Content Distribution Core 0.4.6 > Distribution agent queue processor should implement a backoff in case of > retries for processing an item > --- > > Key: SLING-10123 > URL: https://issues.apache.org/jira/browse/SLING-10123 > Project: Sling > Issue Type: Bug > Components: Content Distribution >Affects Versions: Content Distribution Core 0.4.2 >Reporter: Mohit Arora >Priority: Major > Fix For: Content Distribution Core 0.4.6 > > > In case of recoverable exceptions, distribution agent queue processor does > not evict the queue item from the processing queue [0]. Rather, the item is > retried infinitely until either the distribution of the item is successful or > a non-recoverable exception is thrown for the item. However, since there is > "something wrong" because of which an exception is thrown in the first place, > we should add a cool off period before trying to reattempt to distribute the > same item. This can be achieved through a linear or exponential backoff. > cc - [~ashishc] > [0] > https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/agent/impl/SimpleDistributionAgentQueueProcessor.java#L147-L150 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-9212) Distribution code checks for jcr:removeNode permissions on importer side for DELETE request
[
https://issues.apache.org/jira/browse/SLING-9212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider updated SLING-9212:
---
Fix Version/s: (was: Content Distribution Core 0.4.4)
Content Distribution Core 0.4.6
> Distribution code checks for jcr:removeNode permissions on importer side for
> DELETE request
> ---
>
> Key: SLING-9212
> URL: https://issues.apache.org/jira/browse/SLING-9212
> Project: Sling
> Issue Type: Bug
> Components: Content Distribution
>Reporter: Mohit Arora
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Core 0.4.6
>
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> When a resource is distributed from one endpoint to other with RequestType
> set to DELETE, the execute method of SimpleDistributionAgent [checks the
> permissions for the passed resolver on given
> path(s)|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/agent/impl/SimpleDistributionAgent.java#L175].
> In case of DELETE request, apart from the [configured
> permissions|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/agent/impl/PrivilegeDistributionRequestAuthorizationStrategy.java#L85],
> it also checks for {{jcr:removeNode}} permissions for the user on the path.
> This check happens on the exporter side but AFAIU, the actual deletion
> happens on the importer endpoint. The content does not get deleted on
> exporter side. In that case, this permission check should happen on importer
> side.
> cc - [~marett], [~ashishc]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-8354) Migrate all existing Health Checks in Sling to Felix HC API
[
https://issues.apache.org/jira/browse/SLING-8354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider updated SLING-8354:
---
Fix Version/s: (was: Content Distribution Core 0.4.4)
Content Distribution Core 0.4.6
> Migrate all existing Health Checks in Sling to Felix HC API
> ---
>
> Key: SLING-8354
> URL: https://issues.apache.org/jira/browse/SLING-8354
> Project: Sling
> Issue Type: New Feature
> Components: Health Check
>Reporter: Georg Henzler
>Assignee: Georg Henzler
>Priority: Major
> Fix For: JUnit Health Check 1.0.8, Content Distribution Core
> 0.4.6, Installer Health Checks 2.0.4, Discovery Oak 1.2.32, Commons Scheduler
> 2.7.14
>
>
> Migrate all health checks in Sling project to use the new Felix HC API.
> Generally make the package import to {{org.apache.felix.hc.api}} optional (to
> make the base functionality still available if the HC framework is not
> available)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SLING-10131) Unpack extension causes java.io.NotSerializableException: org.apache.sling.feature.ArtifactId
[ https://issues.apache.org/jira/browse/SLING-10131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls closed SLING-10131. -- > Unpack extension causes java.io.NotSerializableException: > org.apache.sling.feature.ArtifactId > - > > Key: SLING-10131 > URL: https://issues.apache.org/jira/browse/SLING-10131 > Project: Sling > Issue Type: Bug > Components: Feature Model >Affects Versions: Feature Model Unpack Extension 0.1.0 >Reporter: Karl Pauls >Assignee: Karl Pauls >Priority: Major > Fix For: Feature Model Unpack Extension 0.2.0 > > > The unpack extension puts an artiactId into the context of the osgi > installer. However, ArtifactId is not serializable which can cause issues. We > should just put the mvn id string into the context and recreated the artifact > id object from it as needed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-9874) Allow adapting SlingHttpServletRequest and ResourceResolver to XSSAPI
[
https://issues.apache.org/jira/browse/SLING-9874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17284650#comment-17284650
]
Julian Sedding commented on SLING-9874:
---
Thanks [~radu] for reverting. This was still on my todo list. Would it help if
I take care of the release?
> Allow adapting SlingHttpServletRequest and ResourceResolver to XSSAPI
> -
>
> Key: SLING-9874
> URL: https://issues.apache.org/jira/browse/SLING-9874
> Project: Sling
> Issue Type: New Feature
> Components: XSS Protection API
>Affects Versions: XSS Protection API 2.2.6
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
> Fix For: XSS Protection API 2.2.8
>
>
> Most commonly an {{XSSAPI}} instance is needed when rendering a response
> body. In such circumstances, it can be cumbersome to retrieve the {{XSSAPI}}
> service. To add some convenience, it would be nice to be able to adapt a
> {{SlingHttpServletRequest}} or a {{ResourceResolver}} to an {{XSSAPI}}
> instance.
> *15.02.2021: This has been reverted in [commit
> dd7ff4b|https://github.com/apache/sling-org-apache-sling-xss/commit/dd7ff4b]*
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[RESULT] [VOTE] Release Apache Sling Feature Model Unpack Extension 0.2.0
Time to call the vote on the Apache Sling Feature Model Unpack Extension 0.2.0 release. * +1 votes from David Bosschaert, Carsten Ziegeler, Daniel Klco, and Karl Pauls. * No other votes. The vote is successful. I will make the artifacts available as soon as possible.
[VOTE] Release Apache Sling XSS Protection API 2.2.10
Hi, We solved 2 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12349351 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2411/ You can use this UNIX script to download the release and verify the signatures: https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD Usage: sh check_staged_release.sh 2411 /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. Regards, Radu Cotescu
[RESULT] [VOTE] Release Apache Sling Service User Mapper 1.5.2
Time to call the vote on the Apache Sling Service User Mapper 1.5.2 release. * +1 votes from David Bosschaert, Carsten Ziegeler, and Karl Pauls. * No other votes. The vote is successful. I will make the artifacts available as soon as possible.
[jira] [Closed] (SLING-10099) Validators should all agree for a service user to be valid and should be configurable
[ https://issues.apache.org/jira/browse/SLING-10099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls closed SLING-10099. -- > Validators should all agree for a service user to be valid and should be > configurable > - > > Key: SLING-10099 > URL: https://issues.apache.org/jira/browse/SLING-10099 > Project: Sling > Issue Type: Improvement > Components: Service User Mapper >Affects Versions: Service User Mapper 1.4.6 >Reporter: Karl Pauls >Assignee: Karl Pauls >Priority: Major > Fix For: Service User Mapper 1.5.2 > > Time Spent: 5.5h > Remaining Estimate: 0h > > Currently, we only require any validator to validate a service user to make > it valid. In case we have more than one validator they should instead all > validate a service user to make it valid. > Furthermore, we right now restart the mappings for each validator that > arrives - we should make the required validators configurable to make sure we > have all we want when we start validating. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SLING-9026) Reduce unused code and move embedded classes to own package space
[ https://issues.apache.org/jira/browse/SLING-9026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls closed SLING-9026. - > Reduce unused code and move embedded classes to own package space > - > > Key: SLING-9026 > URL: https://issues.apache.org/jira/browse/SLING-9026 > Project: Sling > Issue Type: Improvement > Components: Service User Mapper >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: Service User Mapper 1.5.2 > > > We can slightly improve the code of ServiceUserMapperImpl by removing some > extra checks: > - by using a constructor we don't need to check whether bundle context is null > - we always have an executor - the boolean flag was only there for testing; > we can solve this in the tests > In addition we should move the embedded Felix utils class to a package space > of this module -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Questions surfaced by SLING-9999
So, looking at this proposal by Radu, it sounds to me like this is addressing what Olli wanted and just needs a decision on whether we want a new scripting.spi bundle or rather only have the scripting.api bundle. Olli, what are your thoughts - would you be fine with the separate bundle provided it is renamed to scripting.spi (and the package in question is renamed to scripting.spi.bundle)? Regards, Karl On Mon, Feb 8, 2021 at 11:49 AM Radu Cotescu wrote: > > Hi Olli, > > Which of the two options below do you prefer? > > 1. The API from o.a.s.servlets.resolver.api bundle [0] gets moved to the > o.a.s.scripting.api bundle, in the o.a.s.scripting.api.bundle package. That > means that we’ll have the following import chains: > > o.a.s.scripting.api > o.a.s.scripting.core > o.a.s.servlets.resolver > > 2. Alternatively, we can extract the API from [0] into a new scripting bundle > - o.a.s.scripting.spi - in the o.a.s.scripting.spi.bundle package, with the > following import chains: > > o.a.s.scripting.bundle.api > o.a.s.scripting.core > o.a.s.servlets.resolver > > Either way, we’d ask INFRA to either delete the repository from [0] (option 1 > above) or rename it (option 2 above) and the Servlets Resolver would depend > on a Scripting API bundle (the one we already have or a new one). > > Thanks, > Radu > > [0] - > https://github.com/apache/sling-org-apache-sling-servlets-resolver-api/tree/master/src/main/java/org/apache/sling/servlets/resolver/bundle/tracker > > > On 1 Feb 2021, at 22:01, Oliver Lietz wrote: > > > > On Monday, February 1, 2021 1:17:23 PM CET Karl Pauls wrote: > >> Hi, > > > > Hi, > > > >> we have a discussion going on at SLING- that needs some resolving. > >> > >> As far as I can see, there are the following proposals in the issue: > >> > >> #1 move the o.a.s.servlets.resolver.bundle.tracker package to another > >> artifact #2 rename the package to something else > >> #3 split up the package to move the ResourceType class to sling api > >> > >> As far as the positioning goes, I guess my summary would be: > >> > >> On the one hand, to not have the scripting bundles depend on the > >> servlets.resolver (#1 above) and on the other hand (#2), would it be > >> better to have the package name include "scripting" (I’m not sure we > >> have to discuss #3 right now as that seems to be orthogonal)? Please > >> correct me if I'm missing something (we could work with optional > >> imports as well but that isn't the nicest way to handle dependencies). > >> > >> One option to achieve #1 is to introduce a servlets.api bundle. I guess the > >> idea behind that one is that this way, the servlets.resolver doesn’t > >> require the scripting.api and the scripting doesn’t require the > >> servlets.resolver (just this new api bundle). > >> > >> Another way to do it is to move the package to scripting.api. Which > >> solves it as well with the downside of having the servlets.resolver > >> require the scripting.api. Granted, if #2 is taken into account > >> (renaming the package to be the in scripting namespace) it makes > >> sense. > >> > >> Ultimately, I guess the question for this list to get consensus on is: > >> > >> Do we want the servlets.resolver to have a dependency on scripting.api > >> or do we rather introduce a new servlets.resolver.api bundle - with a > >> possible tie-breaking subquestion of do we think the bundle.tracker > >> api package should stay in the namespace it is in right now or should > >> it move to the scripting namespace? > >> > >> Personally, I think the package namespace is a slightly better fit for > >> the servlets resolver rather than the scripting and consequently, > >> would go with the servlets.resolver.api bundle as a reasonable > >> compromise. > > > > > > #1 move the o.a.s.servlets.resolver.bundle.tracker package to another > > artifact > > > > Package o.a.s.servlets.resolver.bundle.tracker contains the new Bundle API > > for > > _Scripts_. > > > > The API is a new dependency for Scripting Core, Scripting HTL, Scripting JSP > > and Servlets Resolver. > > > > To provide its full functionality Servlets Resolver requires the optional > > dependency Scripting Core. Therefore it makes sense to move the package out > > of > > Servlets Resolver to not have a cyclic dependency. > > > > As Karl said optional imports are not a nice way to handle dependencies. > > > > > > #2 rename the package to something else > > > > See dependents (mostly scripting) above. > > > > The classes in the package reference or deal with Script(ing) and not > > Servlets > > Resolver, see [1]. > > > > I see the API/SPI therefore in a "scripting" package (without tracker as it > > is > > an implementation detail) and matching bundle: > > > > a) o.a.s.scripting.api.bundle (bundle o.a.s.scripting.api) > > > > b) o.a.s.scripting.spi.bundle (new bundle o.a.s.scripting.spi) > > > > c) o.a.s.api.scripting.bundle (bundle o.a.s.api) > > > > d) o.a.s.spi.scripting.bundle (bundle o.a.s.api) >
[jira] [Created] (SLING-10142) Remove the adapter factory from o.a.s.xss
Radu Cotescu created SLING-10142: Summary: Remove the adapter factory from o.a.s.xss Key: SLING-10142 URL: https://issues.apache.org/jira/browse/SLING-10142 Project: Sling Issue Type: Improvement Components: XSS Protection API Affects Versions: XSS Protection API 2.2.8 Reporter: Radu Cotescu Assignee: Radu Cotescu Fix For: XSS Protection API 2.2.10 SLING-9874 reintroduced an adapter factory for the XSS API which was removed in SLING-6793. Since the XSS API is available as an OSGi service, the adapter factory doesn't make sense, since a request or a resource resolver have nothing to do with the XSS API in terms of instantiation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-10142) Remove the adapter factory from o.a.s.xss
[ https://issues.apache.org/jira/browse/SLING-10142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu resolved SLING-10142. -- Resolution: Fixed Fixed in [commit dd7ff4b|https://github.com/apache/sling-org-apache-sling-xss/commit/dd7ff4b]. > Remove the adapter factory from o.a.s.xss > - > > Key: SLING-10142 > URL: https://issues.apache.org/jira/browse/SLING-10142 > Project: Sling > Issue Type: Improvement > Components: XSS Protection API >Affects Versions: XSS Protection API 2.2.8 >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: XSS Protection API 2.2.10 > > > SLING-9874 reintroduced an adapter factory for the XSS API which was removed > in SLING-6793. Since the XSS API is available as an OSGi service, the adapter > factory doesn't make sense, since a request or a resource resolver have > nothing to do with the XSS API in terms of instantiation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-10094) Update embedded version of xalan
[ https://issues.apache.org/jira/browse/SLING-10094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu resolved SLING-10094. -- Resolution: Fixed Updated in [commit 88f17df|https://github.com/apache/sling-org-apache-sling-xss/commit/88f17df]. > Update embedded version of xalan > - > > Key: SLING-10094 > URL: https://issues.apache.org/jira/browse/SLING-10094 > Project: Sling > Issue Type: Improvement > Components: XSS Protection API >Reporter: Antonio Sanso >Assignee: Radu Cotescu >Priority: Major > Fix For: XSS Protection API 2.2.10 > > > org.apache.sling.xss 2.2.2 and above still embed Xalan 2.7.0. > It would be beneficial to use the most recent version of Xalan: 2.7.2 or above > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-8639) VltUtils does not escape path in when creating filter patterns
[
https://issues.apache.org/jira/browse/SLING-8639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider updated SLING-8639:
---
Fix Version/s: (was: Content Distribution Core 0.4.4)
Content Distribution Core 0.4.6
> VltUtils does not escape path in when creating filter patterns
> --
>
> Key: SLING-8639
> URL: https://issues.apache.org/jira/browse/SLING-8639
> Project: Sling
> Issue Type: Bug
> Components: Content Distribution
>Affects Versions: Content Distribution Core 0.4.0
>Reporter: Timothee Maret
>Assignee: Christian Schneider
>Priority: Major
> Fix For: Content Distribution Core 0.4.6
>
>
> When distributing a deep content path that includes parenthesis using
> FileVault, the content package produced does not contain content under that
> path.
> As an example, consider distributing the following path
> {code:java}
> /content/dam/we-retail/planet(1).jpg{code}
> which will yield a content package with the following filter.xml
> {code:java}
>
>
>
>
>
>
>
> matchProperties="true"/>
>
>
> {code}
> The include and exclude patterns are treated by FileVault [as regular
> expression|https://github.com/apache/jackrabbit-filevault/blob/6df76ba4a45316a84ec1cd10636296d191a82260/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/filter/DefaultPathFilter.java#L84].
> Thus the {{(1)}} part of the {{/content/dam/we-retail/planet(1).jpg}} and
> {{/content/dam/we-retail/planet(1).jpg/.*}} patterns is treated as a group
> rather than literally.
> The path should be escaped when building the patterns, in
> https://github.com/apache/sling-org-apache-sling-distribution-core/blob/3d51ac0b09c9a057b590349727392eaedba26aea/src/main/java/org/apache/sling/distribution/serialization/impl/vlt/VltUtils.java#L84
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-9505) Failure to retry distributing content
[
https://issues.apache.org/jira/browse/SLING-9505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider updated SLING-9505:
---
Fix Version/s: (was: Content Distribution Core 0.4.4)
Content Distribution Core 0.4.6
> Failure to retry distributing content
> -
>
> Key: SLING-9505
> URL: https://issues.apache.org/jira/browse/SLING-9505
> Project: Sling
> Issue Type: Bug
> Components: Content Distribution
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Core 0.4.6
>
>
> {code}
> 05.06.2020 20:23:33.066 *ERROR* [127.0.0.1 [1591388613038] POST
> /libs/sling/distribution/services/agents/publish-test HTTP/1.1]
> org.apache.sling.distribution.agent.impl.SimpleDistributionAgent
> [agent][publish-test] an error happened during package import
> org.apache.sling.distribution.common.DistributionException:
> org.apache.http.client.ClientProtocolException
> at
> org.apache.sling.distribution.transport.impl.SimpleHttpDistributionTransport.deliverPackage(SimpleHttpDistributionTransport.java:164)
> [org.apache.sling.distribution.core:0.4.3.T202004281829-70214c0]
> at
> org.apache.sling.distribution.packaging.impl.importer.RemoteDistributionPackageImporter.importPackage(RemoteDistributionPackageImporter.java:69)
> [org.apache.sling.distribution.core:0.4.3.T202004281829-70214c0]
> at
> org.apache.sling.distribution.agent.impl.ImportingDistributionPackageProcessor.process(ImportingDistributionPackageProcessor.java:78)
> [org.apache.sling.distribution.core:0.4.3.T202004281829-70214c0]
> at
> org.apache.sling.distribution.packaging.impl.exporter.LocalDistributionPackageExporter.exportPackages(LocalDistributionPackageExporter.java:47)
> [org.apache.sling.distribution.core:0.4.3.T202004281829-70214c0]
> at
> org.apache.sling.distribution.agent.impl.SimpleDistributionAgent.exportPackages(SimpleDistributionAgent.java:218)
> [org.apache.sling.distribution.core:0.4.3.T202004281829-70214c0]
> at
> org.apache.sling.distribution.agent.impl.SimpleDistributionAgent.execute(SimpleDistributionAgent.java:182)
> [org.apache.sling.distribution.core:0.4.3.T202004281829-70214c0]
> at
> org.apache.sling.distribution.servlet.DistributionAgentServlet.doPost(DistributionAgentServlet.java:62)
> [org.apache.sling.distribution.core:0.4.3.T202004281829-70214c0]
> at
> org.apache.sling.api.servlets.SlingAllMethodsServlet.mayService(SlingAllMethodsServlet.java:146)
> [org.apache.sling.api:2.22.0]
> at
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:342)
> [org.apache.sling.api:2.22.0]
> at
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:374)
> [org.apache.sling.api:2.22.0]
> at
> org.apache.sling.engine.impl.request.RequestData.service(RequestData.java:552)
> [org.apache.sling.engine:2.7.2]
> at
> org.apache.sling.engine.impl.filter.SlingComponentFilterChain.render(SlingComponentFilterChain.java:44)
> [org.apache.sling.engine:2.7.2]
> at
> org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:82)
> [org.apache.sling.engine:2.7.2]
> at
> com.day.cq.wcm.core.impl.WCMDebugFilter.doFilter(WCMDebugFilter.java:138)
> [com.day.cq.wcm.cq-wcm-core:5.13.122]
> at
> org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:72)
> [org.apache.sling.engine:2.7.2]
> at
> org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:78)
> [org.apache.sling.engine:2.7.2]
> at
> com.day.cq.wcm.core.impl.WCMComponentFilter.filterRootInclude(WCMComponentFilter.java:375)
> [com.day.cq.wcm.cq-wcm-core:5.13.122]
> at
> com.day.cq.wcm.core.impl.WCMComponentFilter.doFilter(WCMComponentFilter.java:190)
> [com.day.cq.wcm.cq-wcm-core:5.13.122]
> at
> org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:72)
> [org.apache.sling.engine:2.7.2]
> at
> com.day.cq.wcm.core.impl.page.PageLockFilter.doFilter(PageLockFilter.java:91)
> [com.day.cq.wcm.cq-wcm-core:5.13.122]
> at
> org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:72)
> [org.apache.sling.engine:2.7.2]
> at
> com.day.cq.personalization.impl.TargetComponentFilter.doFilter(TargetComponentFilter.java:94)
> [com.day.cq.cq-personalization:5.13.14]
> at
> org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:72)
> [org.apache.sling.engine:2.7.2]
> at
>
[jira] [Updated] (SLING-10133) Memory leak in MonitoringDistributionPackageBuilder
[ https://issues.apache.org/jira/browse/SLING-10133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated SLING-10133: Fix Version/s: (was: Content Distribution Core 0.4.4) Content Distribution Core 0.4.6 > Memory leak in MonitoringDistributionPackageBuilder > --- > > Key: SLING-10133 > URL: https://issues.apache.org/jira/browse/SLING-10133 > Project: Sling > Issue Type: Bug > Components: Content Distribution >Affects Versions: Content Distribution Core 0.4.0 >Reporter: Timothee Maret >Priority: Major > Fix For: Content Distribution Core 0.4.6 > > > The MonitoringDistributionPackageBuilder maintain a list of MBean for the > latest packages. The number of packages to be monitored is passed as the > [queueCapacity|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/b80cd8f3bae6b7875387ee7caaea271b7e9baec6/src/main/java/org/apache/sling/distribution/monitor/impl/MonitoringDistributionPackageBuilder.java#L49] > via the constructor. When the queueCapacity is 0, the monitoring is disabled. > [VaultDistributionPackageBuilderFactory|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/b80cd8f3bae6b7875387ee7caaea271b7e9baec6/src/main/java/org/apache/sling/distribution/serialization/impl/vlt/VaultDistributionPackageBuilderFactory.java#L201] > and > [DistributionPackageBuilderFactory|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/b80cd8f3bae6b7875387ee7caaea271b7e9baec6/src/main/java/org/apache/sling/distribution/serialization/impl/DistributionPackageBuilderFactory.java] > disable this feature by default. An environment that runs for multiple weeks > without restart and with the default configuration will experience a memory > leak that leads to the JVM running out of memory. > The implementation has two flaws that explain the memory leak. > > h2. #1 - Registering a MBean when the queueCapacity is 0 > The code [unconditionally registers a > MBean|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/b80cd8f3bae6b7875387ee7caaea271b7e9baec6/src/main/java/org/apache/sling/distribution/monitor/impl/MonitoringDistributionPackageBuilder.java#L106] > even if the queueCapacity is 0. We need to only register a MBean when the > capacity is > 0. > h2. #2 - Concurrency issue when un-registering MBean > The code [attempts to > remove|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/b80cd8f3bae6b7875387ee7caaea271b7e9baec6/src/main/java/org/apache/sling/distribution/monitor/impl/MonitoringDistributionPackageBuilder.java#L108] > by checking if the queueCapacity equals the list of MBeans. This check works > in a single threaded context but it falls short when > registerDistributionPackageMBean is invoked concurrently. In the latter case, > it can happen that the check never holds true leading the mBeans queue to > grow indefinitely. One solution is to leverage the features of the > LinkedBlockingDeque. Create a LinkedBlockingDeque with bounded capacity and > rely on the returned status from the offer method to decide if an item needs > to be removed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (SLING-10094) Update embedded version of xalan
[ https://issues.apache.org/jira/browse/SLING-10094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu reassigned SLING-10094: Assignee: Radu Cotescu > Update embedded version of xalan > - > > Key: SLING-10094 > URL: https://issues.apache.org/jira/browse/SLING-10094 > Project: Sling > Issue Type: Task > Components: XSS Protection API >Reporter: Antonio Sanso >Assignee: Radu Cotescu >Priority: Major > > org.apache.sling.xss 2.2.2 and above still embed Xalan 2.7.0. > It would be beneficial to use the most recent version of Xalan: 2.7.2 or above > -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSS] AdapterFactory for adapting SlingHttpServletRequest to XSSAPI
Hi, I have to work on an update for the XSS Bundle and noticed that the adapter factory is still around. Is it ok if I revert the change from [2] as well? Thanks, Radu [2] - https://issues.apache.org/jira/browse/SLING-9874 > On 9 Nov 2020, at 17:02, Bertrand Delacretaz wrote: > > Hi, > > On Mon, Nov 9, 2020 at 1:31 PM Julian Sedding wrote: >> ...In SLING-9874 I added an adapter factory to the XSS Protection API >> module, which can adapt a SlingHttpServletRequest or a >> ResourceResolver to an XSSAPI... > > Although we've been doing such things in the past I don't think it's a > good idea, as it's adapting a Request to not a request>. > > IOW I think adaptation should, in general, only be used to convert > between "different views of the same thing" which is not the case > here. Converting a Sling Resource to a JCR Node for example is clearly > "different views of the same thing", so ok from that perspective. > > I have the impression that there's an implicit consensus among several > of us about this but we might want to document it better. Sorry that > this lack of clarity is causing extra work for you. > >> ...Now, according to comments in SLING-9874 it seems that Konrad and Radu >> are opposed to this adapter factory... > > Given the above comments I also prefer that you omit that adapter > factory. I suppose the XSSAPI is an OSGi service, if that's the case > there are other, better, less "magic" ways to acquire it. > > -Bertrand
[jira] [Updated] (SLING-9874) Allow adapting SlingHttpServletRequest and ResourceResolver to XSSAPI
[
https://issues.apache.org/jira/browse/SLING-9874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-9874:
Description:
Most commonly an {{XSSAPI}} instance is needed when rendering a response body.
In such circumstances, it can be cumbersome to retrieve the {{XSSAPI}} service.
To add some convenience, it would be nice to be able to adapt a
{{SlingHttpServletRequest}} or a {{ResourceResolver}} to an {{XSSAPI}} instance.
*15.02.2021: This has been reverted in [commit
dd7ff4b|https://github.com/apache/sling-org-apache-sling-xss/commit/dd7ff4b]*
was:Most commonly an {{XSSAPI}} instance is needed when rendering a response
body. In such circumstances, it can be cumbersome to retrieve the {{XSSAPI}}
service. To add some convenience, it would be nice to be able to adapt a
{{SlingHttpServletRequest}} or a {{ResourceResolver}} to an {{XSSAPI}} instance.
> Allow adapting SlingHttpServletRequest and ResourceResolver to XSSAPI
> -
>
> Key: SLING-9874
> URL: https://issues.apache.org/jira/browse/SLING-9874
> Project: Sling
> Issue Type: New Feature
> Components: XSS Protection API
>Affects Versions: XSS Protection API 2.2.6
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
> Fix For: XSS Protection API 2.2.8
>
>
> Most commonly an {{XSSAPI}} instance is needed when rendering a response
> body. In such circumstances, it can be cumbersome to retrieve the {{XSSAPI}}
> service. To add some convenience, it would be nice to be able to adapt a
> {{SlingHttpServletRequest}} or a {{ResourceResolver}} to an {{XSSAPI}}
> instance.
> *15.02.2021: This has been reverted in [commit
> dd7ff4b|https://github.com/apache/sling-org-apache-sling-xss/commit/dd7ff4b]*
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-10094) Update embedded version of xalan
[ https://issues.apache.org/jira/browse/SLING-10094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-10094: - Issue Type: Improvement (was: Task) > Update embedded version of xalan > - > > Key: SLING-10094 > URL: https://issues.apache.org/jira/browse/SLING-10094 > Project: Sling > Issue Type: Improvement > Components: XSS Protection API >Reporter: Antonio Sanso >Assignee: Radu Cotescu >Priority: Major > Fix For: XSS Protection API 2.2.10 > > > org.apache.sling.xss 2.2.2 and above still embed Xalan 2.7.0. > It would be beneficial to use the most recent version of Xalan: 2.7.2 or above > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-10094) Update embedded version of xalan
[ https://issues.apache.org/jira/browse/SLING-10094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-10094: - Fix Version/s: XSS Protection API 2.2.10 > Update embedded version of xalan > - > > Key: SLING-10094 > URL: https://issues.apache.org/jira/browse/SLING-10094 > Project: Sling > Issue Type: Task > Components: XSS Protection API >Reporter: Antonio Sanso >Assignee: Radu Cotescu >Priority: Major > Fix For: XSS Protection API 2.2.10 > > > org.apache.sling.xss 2.2.2 and above still embed Xalan 2.7.0. > It would be beneficial to use the most recent version of Xalan: 2.7.2 or above > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-9874) Allow adapting SlingHttpServletRequest and ResourceResolver to XSSAPI
[
https://issues.apache.org/jira/browse/SLING-9874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17284651#comment-17284651
]
Radu Cotescu commented on SLING-9874:
-
[~jsedding], don't worry. I'm anyways working on SLING-10094 and I'll start a
release in the next couple of minutes.
> Allow adapting SlingHttpServletRequest and ResourceResolver to XSSAPI
> -
>
> Key: SLING-9874
> URL: https://issues.apache.org/jira/browse/SLING-9874
> Project: Sling
> Issue Type: New Feature
> Components: XSS Protection API
>Affects Versions: XSS Protection API 2.2.6
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
> Fix For: XSS Protection API 2.2.8
>
>
> Most commonly an {{XSSAPI}} instance is needed when rendering a response
> body. In such circumstances, it can be cumbersome to retrieve the {{XSSAPI}}
> service. To add some convenience, it would be nice to be able to adapt a
> {{SlingHttpServletRequest}} or a {{ResourceResolver}} to an {{XSSAPI}}
> instance.
> *15.02.2021: This has been reverted in [commit
> dd7ff4b|https://github.com/apache/sling-org-apache-sling-xss/commit/dd7ff4b]*
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [DISCUSS] AdapterFactory for adapting SlingHttpServletRequest to XSSAPI
+1 Konrad > On 15. Feb 2021, at 10:46, Radu Cotescu wrote: > > Hi, > > I have to work on an update for the XSS Bundle and noticed that the adapter > factory is still around. Is it ok if I revert the change from [2] as well? > > Thanks, > Radu > > [2] - https://issues.apache.org/jira/browse/SLING-9874 > >> On 9 Nov 2020, at 17:02, Bertrand Delacretaz wrote: >> >> Hi, >> >> On Mon, Nov 9, 2020 at 1:31 PM Julian Sedding wrote: >>> ...In SLING-9874 I added an adapter factory to the XSS Protection API >>> module, which can adapt a SlingHttpServletRequest or a >>> ResourceResolver to an XSSAPI... >> >> Although we've been doing such things in the past I don't think it's a >> good idea, as it's adapting a Request to > not a request>. >> >> IOW I think adaptation should, in general, only be used to convert >> between "different views of the same thing" which is not the case >> here. Converting a Sling Resource to a JCR Node for example is clearly >> "different views of the same thing", so ok from that perspective. >> >> I have the impression that there's an implicit consensus among several >> of us about this but we might want to document it better. Sorry that >> this lack of clarity is causing extra work for you. >> >>> ...Now, according to comments in SLING-9874 it seems that Konrad and Radu >>> are opposed to this adapter factory... >> >> Given the above comments I also prefer that you omit that adapter >> factory. I suppose the XSSAPI is an OSGi service, if that's the case >> there are other, better, less "magic" ways to acquire it. >> >> -Bertrand >
Re: [VOTE] Release Apache Sling Service User Mapper 1.5.0 and Feature Model Unpack Extension 0.2.0
+1 for the Feature Model Unpack Extension. regards, Karl On Wed, Feb 10, 2021 at 4:42 PM Daniel Klco wrote: > > +1 > > As a note it appears that Feature Model Upack Extension is not onboarded to > Jenkins. > > On Wed, Feb 10, 2021 at 8:45 AM Carsten Ziegeler > wrote: > > > +1 > > > > Carsten > > > > Am 10.02.2021 um 12:27 schrieb Karl Pauls: > > > We solved 3 issue in these releases: > > > https://issues.apache.org/jira/projects/SLING/versions/12349693 > > > https://issues.apache.org/jira/projects/SLING/versions/12348803 > > > > > > Staging repository: > > > https://repository.apache.org/content/repositories/orgapachesling-2408 > > > > > > You can use this UNIX script to download the release and verify the > > signatures: > > > > > https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD > > > > > > Usage: > > > sh check_staged_release.sh 2408 /tmp/sling-staging > > > > > > Please vote to approve these releases: > > > > > >[ ] +1 Approve the releases > > >[ ] 0 Don't care > > >[ ] -1 Don't release, because ... > > > > > > > -- > > -- > > Carsten Ziegeler > > Adobe Research Switzerland > > cziege...@apache.org > > -- Karl Pauls karlpa...@gmail.com
Re: [VOTE] Release Apache Sling Service User Mapper 1.5.2
+1 regards, Karl On Sun, Feb 14, 2021 at 8:35 PM wrote: > > +1 > > David > > On Fri, 12 Feb 2021 at 13:29, Carsten Ziegeler wrote: > > > +1 > > > > Carsten > > > > Am 12.02.2021 um 11:41 schrieb Karl Pauls: > > > We solved 2 issue in these releases: > > > https://issues.apache.org/jira/projects/SLING/versions/12349693 > > > > > > Staging repository: > > > https://repository.apache.org/content/repositories/orgapachesling-2409 > > > > > > You can use this UNIX script to download the release and verify the > > signatures: > > > > > https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD > > > > > > Usage: > > > sh check_staged_release.sh 2409 /tmp/sling-staging > > > > > > Please vote to approve these releases: > > > > > >[ ] +1 Approve the releases > > >[ ] 0 Don't care > > >[ ] -1 Don't release, because ... > > > > > > > -- > > -- > > Carsten Ziegeler > > Adobe Research Switzerland > > cziege...@apache.org > > -- Karl Pauls karlpa...@gmail.com
[Jenkins] Sling » Modules » sling-org-apache-sling-launchpad-testing » master #348 is BROKEN
che.sling.servlets.get.DefaultGetServlet#0}
3613 LOG Filter timing:
filter=org.apache.sling.engine.impl.debug.RequestProgressTrackerLogFilter,
inner=0, total=0, outer=0
3620 LOG Filter timing:
filter=org.apache.sling.launchpad.testservices.filters.SlingFilterWithPattern,
inner=0, total=0, outer=0
3625 LOG Filter timing:
filter=org.apache.sling.launchpad.testservices.filters.NoPropertyFilter,
inner=0, total=0, outer=0
3630 LOG Filter timing:
filter=org.apache.sling.launchpad.testservices.filters.SlingFilter, inner=0,
total=0, outer=0
3714 LOG Applying Error filters
3721 LOG Calling filter: org.apache.sling.i18n.impl.I18NFilter
3728 TIMER_START{handleError:status=404}
4045 TIMER_END{315,handleError:status=404} Using handler
org.apache.sling.servlets.resolver.internal.defaults.DefaultErrorHandlerServlet
4280 TIMER_END{4279,Request Processing} Dumping SlingRequestProgressTracker
Entries
ApacheSling/2.7 (jetty/9.4.28.v20200408, Java HotSpot(TM) 64-Bit
Server VM 1.8.0_281, Linux 4.15.0-58-generic amd64)
) expected:<200> but was:<404>
[ERROR] InitialContentTest.testInitialContentInSubNodeRoot:54 Content
contains "testProperty":"value"
({"jcr:primaryType":"sling:Folder","jcr:createdBy":"sling-jcr-content-loader","jcr:created":"Mon
Feb 15 2021 11:17:59 GMT+"})
[ERROR] ServerSideInstallerTest.noUntransformedResources:52 Untransformed
resources found:
[RegisteredResource(url=jcrinstall:/apps/sling-test/install/org.apache.sling.scripting.jsp.JspScriptEngineFactory.json,
digest=1613244282427)]
[INFO]
[ERROR] Tests run: 665, Failures: 6, Errors: 0, Skipped: 1
[INFO]
[INFO]
[INFO] --- feature-launcher-maven-plugin:0.1.0:stop (default) @
org.apache.sling.launchpad.testing ---
[INFO] Stopping launch with id sling-12-oak-tar
[INFO]
[INFO] --- ianal-maven-plugin:1.0-alpha-1:verify-legal-files (default) @
org.apache.sling.launchpad.testing ---
[INFO] Checking legal files in:
org.apache.sling.launchpad.testing-12-SNAPSHOT.jar
[INFO] Checking legal files in:
org.apache.sling.launchpad.testing-12-SNAPSHOT-sources.jar
[INFO]
[INFO] --- apache-rat-plugin:0.11:check (default) @
org.apache.sling.launchpad.testing ---
[INFO] 51 implicit excludes (use -debug for more details).
[INFO] Exclude: DEPENDENCIES
[INFO] Exclude: src/main/appended-resources/META-INF/*
[INFO] Exclude: velocity.log
[INFO] Exclude: target/*
[INFO] Exclude: README.md
[INFO] Exclude: maven-eclipse.xml
[INFO] Exclude: .*
[INFO] Exclude: .*/**
[INFO] Exclude: **/*.json
[INFO] Exclude: DEPENDENCIES
[INFO] Exclude: **/*.rej
[INFO] Exclude: hs_err_*.log
[INFO] Exclude: **/repository/index/*/index-details.txt
[INFO] Exclude: bnd.bnd
[INFO] 6 resources included (use -debug for more details)
[INFO] Rat check: Summary of files. Unapproved: 0 unknown: 0 generated: 0
approved: 5 licence.
[INFO]
[INFO] --- maven-failsafe-plugin:2.21.0:verify (default) @
org.apache.sling.launchpad.testing ---
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 03:27 min
[INFO] Finished at: 2021-02-15T11:20:54Z
[INFO]
[WARNING] The requested profile "ci" could not be activated because it does not
exist.
[INFO] [jenkins-event-spy] Generated
/home/jenkins/jenkins-agent/workspace/e-sling-launchpad-testing_master@tmp/withMaven46eb9863/maven-spy-20210215-111727-724374120638417341532.log
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-failsafe-plugin:2.21.0:verify (default) on
project org.apache.sling.launchpad.testing: There are test failures.
[ERROR]
[ERROR] Please refer to
/home/jenkins/jenkins-agent/workspace/e-sling-launchpad-testing_master/target/failsafe-reports
for the individual test results.
[ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump,
[date].dumpstream and [date]-jvmRun[N].dumpstream.
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[Pipeline] }
[withMaven] junitPublisher - Archive test results for Maven artifact
org.apache.sling:org.apache.sling.launchpad.testing:jar:12-SNAPSHOT generated
by maven-surefire-plugin:test (default-test): target/surefire-reports/*.xml
Recording test results
None of the test reports contained any result
[withMaven] junitPublisher - Archive test results for Maven artifact
org.apache.sling:org.apache.sling.launchpad.testing:jar:12-SNAPSHOT generated
by maven-failsafe-plugin:integration-test (default):
target/failsafe-repo
[jira] [Issue Comment Deleted] (SLING-10012) Lookup of precompiled template files does not work
[
https://issues.apache.org/jira/browse/SLING-10012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olena updated SLING-10012:
--
Comment: was deleted
(was: The same scenario reproduces for the “data-sly-use”
- A resource type _page_ with a bundled script page.html contains
{code:java}
data-sly-use.head="head.html"{code}
- The extending resource type _myPage_ which has _page_ as resourceSuperType
contains head.html as a precompiled script file.
The same error on rendering the _myPage_:
{code:java}
Caused by: org.apache.sling.scripting.sightly.SightlyException: No use provider
could resolve identifier head.html at
org.apache.sling.scripting.sightly.impl.engine.extension.use.UseRuntimeExtension.call(UseRuntimeExtension.java:79)
[org.apache.sling.scripting.sightly:1.4.6.140] at
org.apache.sling.scripting.sightly.impl.engine.runtime.RenderContextImpl.call(RenderContextImpl.java:72)
[org.apache.sling.scripting.sightly:1.4.6.140] at
libs.core.wcm.components.page.v2.page.page__002e__html.render(page__002e__html.java:46)
[aem-precompiled-scripts:6.6.0.SNAPSHOT]
{code})
> Lookup of precompiled template files does not work
> --
>
> Key: SLING-10012
> URL: https://issues.apache.org/jira/browse/SLING-10012
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting HTL Engine 1.4.6-1.4.0
>Reporter: Konrad Windszus
>Assignee: Radu Cotescu
>Priority: Major
>
> I have a resource type {{a}} with a bundled script {{a.html}} which contains
> {code}
> data-sly-call="${simpleTemplate.simple}">
> {code}
> I have an extended resource type {{myA}} which has {{a}} as
> resourceSuperType. That one contains {{simple.html}} as precompiled script
> file. Still the lookup when trying to render a resource based on {{myA}}
> fails with
> {code}
> Caused by: org.apache.sling.scripting.sightly.SightlyException: No use
> provider could resolve identifier simple.html
> at
> org.apache.sling.scripting.sightly.impl.engine.extension.use.UseRuntimeExtension.call(UseRuntimeExtension.java:79)
> [org.apache.sling.scripting.sightly:1.4.6.140]
> at
> org.apache.sling.scripting.sightly.impl.engine.runtime.RenderContextImpl.call(RenderContextImpl.java:72)
> [org.apache.sling.scripting.sightly:1.4.6.140]
> at
> org.apache.sling.scripting.sightly.__002e__html.render(container__002e__html.java:62)
> {code}
> It works fine when trying to render a resource directly leveraging {{a}}, but
> in that case obviously the bundled {{a/simple.html}} is used
> Seems that the fix from SLING-9718 has not yet covered this use case.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [VOTE] Release Apache Sling XSS Protection API 2.2.10
+1 Regards Julian On Mon, Feb 15, 2021 at 2:22 PM Carsten Ziegeler wrote: > > +1 > > Carsten > > Am 15.02.2021 um 11:45 schrieb Radu Cotescu: > > Hi, > > > > We solved 2 issues in this release: > > https://issues.apache.org/jira/browse/SLING/fixforversion/12349351 > > > > Staging repository: > > https://repository.apache.org/content/repositories/orgapachesling-2411/ > > > > You can use this UNIX script to download the release and verify the > > signatures: > > https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD > > > > Usage: > > sh check_staged_release.sh 2411 /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. > > > > Regards, > > Radu Cotescu > > > > -- > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
[jira] [Commented] (SLING-10143) bundles referenced in sling starter are out of date
[
https://issues.apache.org/jira/browse/SLING-10143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17284754#comment-17284754
]
Ruben Reusser commented on SLING-10143:
---
patch files to bring dependencies up to latest versions attached to this issue
out of date dependencies are now greatly reduced, however, hard to say if this
introduces new issues.
{code:java}
[INFO] artifact org.apache.felix:org.apache.felix.cm.json: checking for updates
from central
[INFO] The following dependencies in Dependencies have newer versions:
[INFO] com.google.guava:guava .. 15.0 -> 30.1-jre
[INFO] commons-collections:commons-collections 3.2.2 -> 20040616
[INFO] io.dropwizard.metrics:metrics-core . 3.2.6 -> 4.2.0-beta.1
[INFO] org.apache.tika:tika-core 1.24 -> 2.0.0-ALPHA
[INFO] org.apache.tika:tika-parsers . 1.24 -> 2.0.0-ALPHA
[INFO] org.jvnet.staxex:stax-ex .. 1.7.6 -> 2.0.0
[INFO] org.slf4j:jcl-over-slf4j .. 1.7.30 -> 2.0.0-alpha1
[INFO] org.slf4j:log4j-over-slf4j 1.7.30 -> 2.0.0-alpha1
[INFO] org.slf4j:slf4j-api ... 1.7.30 -> 2.0.0-alpha1
{code}
> bundles referenced in sling starter are out of date
> ---
>
> Key: SLING-10143
> URL: https://issues.apache.org/jira/browse/SLING-10143
> Project: Sling
> Issue Type: Improvement
> Components: Starter
>Reporter: Ruben Reusser
>Priority: Major
> Fix For: Starter 12
>
> Attachments:
> 0001-updated-3rd-party-dependencies-of-sling-starter.patch,
> 0002-javax.activation-dependency-needed-to-be-increased.patch,
> 0003-updated-to-latest-sling-bundles-added-missing-felix-.patch
>
>
> Would be nice to make sure the sling starter uses the latest bundles -
> according to
> {code:java}
> mvn versions:display-dependency-updates{code}
> the sling starter is a bit out of date with the dependencies
> {code:java}
> [INFO] The following dependencies in Dependencies have newer versions:
> [INFO] com.composum.nodes:composum-nodes-commons . 2.1.1 ->
> 2.3.0
> [INFO] com.composum.nodes:composum-nodes-console . 2.1.1 ->
> 2.3.0
> [INFO] com.composum.nodes:composum-nodes-jslibs .. 2.1.1 ->
> 2.3.0
> [INFO] com.composum.nodes:composum-nodes-pckgmgr . 2.1.1 ->
> 2.3.0
> [INFO] com.composum.nodes:composum-nodes-usermgr . 2.1.1 ->
> 2.3.0
> [INFO] com.fasterxml.jackson.core:jackson-annotations .. 2.11.1 ->
> 2.12.1
> [INFO] com.fasterxml.jackson.core:jackson-core . 2.11.1 ->
> 2.12.1
> [INFO] com.fasterxml.jackson.core:jackson-databind . 2.11.1 ->
> 2.12.1
> [INFO] com.google.guava:guava .. 15.0 ->
> 30.1-jre
> [INFO] com.h2database:h2-mvstore . 1.4.194 ->
> 1.4.200
> [INFO] commons-codec:commons-codec . 1.14 ->
> 1.15
> [INFO] commons-collections:commons-collections 3.2.2 ->
> 20040616
> [INFO] commons-io:commons-io ... 2.6 ->
> 2.8.0
> [INFO] io.dropwizard.metrics:metrics-core . 3.2.6 ->
> 4.2.0-beta.1
> [INFO] org.antlr:antlr4-runtime .. 4.7.2 ->
> 4.9.1
> [INFO] org.apache.commons:commons-lang3 . 3.9 ->
> 3.11
> [INFO] org.apache.felix:org.apache.felix.configadmin ... 1.9.16 ->
> 1.9.20
> [INFO] org.apache.felix:org.apache.felix.eventadmin .. 1.5.0 ->
> 1.6.2
> [INFO] org.apache.felix:org.apache.felix.http.jetty . 4.0.18 ->
> 4.1.4
> [INFO] org.apache.felix:org.apache.felix.metatype 1.2.2 ->
> 1.2.4
> [INFO] org.apache.felix:org.apache.felix.scr ... 2.1.20 ->
> 2.1.24
> [INFO] org.apache.felix:org.apache.felix.utils . 1.11.2 ->
> 1.11.6
> [INFO] org.apache.felix:org.apache.felix.webconsole .. 4.5.0 ->
> 4.6.0
> [INFO] org.apache.geronimo.specs:geronimo-annotation_1.3_spec 1.1 ->
> 1.3
> [INFO] org.apache.geronimo.specs:geronimo-atinject_1.0_spec .. 1.1 ->
> 1.2
> [INFO] org.apache.httpcomponents:httpclient 4.5.10 ->
> 4.5.13
> [INFO] org.apache.httpcomponents:httpclient-osgi ... 4.5.10 ->
> 4.5.13
> [INFO] org.apache.httpcomponents:httpcore-osgi . 4.4.12 ->
> 4.4.14
> [INFO] org.apache.jackrabbit:jackrabbit-data ... 2.20.0 ->
> 2.21.5
> [INFO] org.apache.jackrabbit:jackrabbit-jcr-commons 2.20.0 ->
> 2.21.5
> [INFO] org.apache.jackrabbit:jackrabbit-jcr-rmi 2.20.0 ->
> 2.21.5
> [INFO] org.apache.jackrabbit:jackrabbit-spi 2.20.0 ->
> 2.21.5
>
Re: [DISCUSS] AdapterFactory for adapting SlingHttpServletRequest to XSSAPI
+1 - thanks for taking care of this! Regards Julian On Mon, Feb 15, 2021 at 10:48 AM Konrad Windszus wrote: > > +1 > > Konrad > > > On 15. Feb 2021, at 10:46, Radu Cotescu wrote: > > > > Hi, > > > > I have to work on an update for the XSS Bundle and noticed that the adapter > > factory is still around. Is it ok if I revert the change from [2] as well? > > > > Thanks, > > Radu > > > > [2] - https://issues.apache.org/jira/browse/SLING-9874 > > > >> On 9 Nov 2020, at 17:02, Bertrand Delacretaz > >> wrote: > >> > >> Hi, > >> > >> On Mon, Nov 9, 2020 at 1:31 PM Julian Sedding wrote: > >>> ...In SLING-9874 I added an adapter factory to the XSS Protection API > >>> module, which can adapt a SlingHttpServletRequest or a > >>> ResourceResolver to an XSSAPI... > >> > >> Although we've been doing such things in the past I don't think it's a > >> good idea, as it's adapting a Request to >> not a request>. > >> > >> IOW I think adaptation should, in general, only be used to convert > >> between "different views of the same thing" which is not the case > >> here. Converting a Sling Resource to a JCR Node for example is clearly > >> "different views of the same thing", so ok from that perspective. > >> > >> I have the impression that there's an implicit consensus among several > >> of us about this but we might want to document it better. Sorry that > >> this lack of clarity is causing extra work for you. > >> > >>> ...Now, according to comments in SLING-9874 it seems that Konrad and Radu > >>> are opposed to this adapter factory... > >> > >> Given the above comments I also prefer that you omit that adapter > >> factory. I suppose the XSSAPI is an OSGi service, if that's the case > >> there are other, better, less "magic" ways to acquire it. > >> > >> -Bertrand > > >
Re: [VOTE] Release Apache Sling XSS Protection API 2.2.10
+1 Konrad > On 15. Feb 2021, at 11:45, Radu Cotescu wrote: > > Hi, > > We solved 2 issues in this release: > https://issues.apache.org/jira/browse/SLING/fixforversion/12349351 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-2411/ > > You can use this UNIX script to download the release and verify the > signatures: > https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD > > Usage: > sh check_staged_release.sh 2411 /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. > > Regards, > Radu Cotescu
[jira] [Created] (SLING-10143) bundles referenced in sling starter are out of date
Ruben Reusser created SLING-10143:
-
Summary: bundles referenced in sling starter are out of date
Key: SLING-10143
URL: https://issues.apache.org/jira/browse/SLING-10143
Project: Sling
Issue Type: Improvement
Components: Starter
Reporter: Ruben Reusser
Fix For: Starter 12
Would be nice to make sure the sling starter uses the latest bundles -
according to
{code:java}
mvn versions:display-dependency-updates{code}
the sling starter is a bit out of date with the dependencies
{code:java}
[INFO] The following dependencies in Dependencies have newer versions:
[INFO] com.composum.nodes:composum-nodes-commons . 2.1.1 -> 2.3.0
[INFO] com.composum.nodes:composum-nodes-console . 2.1.1 -> 2.3.0
[INFO] com.composum.nodes:composum-nodes-jslibs .. 2.1.1 -> 2.3.0
[INFO] com.composum.nodes:composum-nodes-pckgmgr . 2.1.1 -> 2.3.0
[INFO] com.composum.nodes:composum-nodes-usermgr . 2.1.1 -> 2.3.0
[INFO] com.fasterxml.jackson.core:jackson-annotations .. 2.11.1 -> 2.12.1
[INFO] com.fasterxml.jackson.core:jackson-core . 2.11.1 -> 2.12.1
[INFO] com.fasterxml.jackson.core:jackson-databind . 2.11.1 -> 2.12.1
[INFO] com.google.guava:guava .. 15.0 -> 30.1-jre
[INFO] com.h2database:h2-mvstore . 1.4.194 -> 1.4.200
[INFO] commons-codec:commons-codec . 1.14 -> 1.15
[INFO] commons-collections:commons-collections 3.2.2 -> 20040616
[INFO] commons-io:commons-io ... 2.6 -> 2.8.0
[INFO] io.dropwizard.metrics:metrics-core . 3.2.6 -> 4.2.0-beta.1
[INFO] org.antlr:antlr4-runtime .. 4.7.2 -> 4.9.1
[INFO] org.apache.commons:commons-lang3 . 3.9 -> 3.11
[INFO] org.apache.felix:org.apache.felix.configadmin ... 1.9.16 -> 1.9.20
[INFO] org.apache.felix:org.apache.felix.eventadmin .. 1.5.0 -> 1.6.2
[INFO] org.apache.felix:org.apache.felix.http.jetty . 4.0.18 -> 4.1.4
[INFO] org.apache.felix:org.apache.felix.metatype 1.2.2 -> 1.2.4
[INFO] org.apache.felix:org.apache.felix.scr ... 2.1.20 -> 2.1.24
[INFO] org.apache.felix:org.apache.felix.utils . 1.11.2 -> 1.11.6
[INFO] org.apache.felix:org.apache.felix.webconsole .. 4.5.0 -> 4.6.0
[INFO] org.apache.geronimo.specs:geronimo-annotation_1.3_spec 1.1 -> 1.3
[INFO] org.apache.geronimo.specs:geronimo-atinject_1.0_spec .. 1.1 -> 1.2
[INFO] org.apache.httpcomponents:httpclient 4.5.10 -> 4.5.13
[INFO] org.apache.httpcomponents:httpclient-osgi ... 4.5.10 -> 4.5.13
[INFO] org.apache.httpcomponents:httpcore-osgi . 4.4.12 -> 4.4.14
[INFO] org.apache.jackrabbit:jackrabbit-data ... 2.20.0 -> 2.21.5
[INFO] org.apache.jackrabbit:jackrabbit-jcr-commons 2.20.0 -> 2.21.5
[INFO] org.apache.jackrabbit:jackrabbit-jcr-rmi 2.20.0 -> 2.21.5
[INFO] org.apache.jackrabbit:jackrabbit-spi 2.20.0 -> 2.21.5
[INFO] org.apache.jackrabbit:jackrabbit-spi-commons 2.20.0 -> 2.21.5
[INFO] org.apache.jackrabbit:jackrabbit-webdav . 2.20.0 -> 2.21.5
[INFO] org.apache.jackrabbit:oak-api ... 1.32.0 -> 1.38.0
[INFO] org.apache.jackrabbit:oak-authorization-principalbased ...
[INFO] 1.32.0 -> 1.38.0
[INFO] org.apache.jackrabbit:oak-blob .. 1.32.0 -> 1.38.0
[INFO] org.apache.jackrabbit:oak-blob-plugins .. 1.32.0 -> 1.38.0
[INFO] org.apache.jackrabbit:oak-commons ... 1.32.0 -> 1.38.0
[INFO] org.apache.jackrabbit:oak-core .. 1.32.0 -> 1.38.0
[INFO] org.apache.jackrabbit:oak-core-spi .. 1.32.0 -> 1.38.0
[INFO] org.apache.jackrabbit:oak-jackrabbit-api 1.32.0 -> 1.38.0
[INFO] org.apache.jackrabbit:oak-jcr ... 1.32.0 -> 1.38.0
[INFO] org.apache.jackrabbit:oak-lucene 1.32.0 -> 1.38.0
[INFO] org.apache.jackrabbit:oak-query-spi . 1.32.0 -> 1.38.0
[INFO] org.apache.jackrabbit:oak-security-spi .. 1.32.0 -> 1.38.0
[INFO] org.apache.jackrabbit:oak-segment-tar ... 1.32.0 -> 1.38.0
[INFO] org.apache.jackrabbit:oak-store-composite ... 1.32.0 -> 1.38.0
[INFO] org.apache.jackrabbit:oak-store-document 1.32.0 -> 1.38.0
[INFO] org.apache.jackrabbit:oak-store-spi . 1.32.0 -> 1.38.0
[INFO] org.apache.jackrabbit.vault:org.apache.jackrabbit.vault ...
[INFO] 3.4.6 -> 3.4.8
[INFO] org.apache.pdfbox:fontbox ... 2.0.17 ->
[jira] [Updated] (SLING-10143) bundles referenced in sling starter are out of date
[
https://issues.apache.org/jira/browse/SLING-10143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruben Reusser updated SLING-10143:
--
Attachment: 0001-updated-3rd-party-dependencies-of-sling-starter.patch
0002-javax.activation-dependency-needed-to-be-increased.patch
0003-updated-to-latest-sling-bundles-added-missing-felix-.patch
> bundles referenced in sling starter are out of date
> ---
>
> Key: SLING-10143
> URL: https://issues.apache.org/jira/browse/SLING-10143
> Project: Sling
> Issue Type: Improvement
> Components: Starter
>Reporter: Ruben Reusser
>Priority: Major
> Fix For: Starter 12
>
> Attachments:
> 0001-updated-3rd-party-dependencies-of-sling-starter.patch,
> 0002-javax.activation-dependency-needed-to-be-increased.patch,
> 0003-updated-to-latest-sling-bundles-added-missing-felix-.patch
>
>
> Would be nice to make sure the sling starter uses the latest bundles -
> according to
> {code:java}
> mvn versions:display-dependency-updates{code}
> the sling starter is a bit out of date with the dependencies
> {code:java}
> [INFO] The following dependencies in Dependencies have newer versions:
> [INFO] com.composum.nodes:composum-nodes-commons . 2.1.1 ->
> 2.3.0
> [INFO] com.composum.nodes:composum-nodes-console . 2.1.1 ->
> 2.3.0
> [INFO] com.composum.nodes:composum-nodes-jslibs .. 2.1.1 ->
> 2.3.0
> [INFO] com.composum.nodes:composum-nodes-pckgmgr . 2.1.1 ->
> 2.3.0
> [INFO] com.composum.nodes:composum-nodes-usermgr . 2.1.1 ->
> 2.3.0
> [INFO] com.fasterxml.jackson.core:jackson-annotations .. 2.11.1 ->
> 2.12.1
> [INFO] com.fasterxml.jackson.core:jackson-core . 2.11.1 ->
> 2.12.1
> [INFO] com.fasterxml.jackson.core:jackson-databind . 2.11.1 ->
> 2.12.1
> [INFO] com.google.guava:guava .. 15.0 ->
> 30.1-jre
> [INFO] com.h2database:h2-mvstore . 1.4.194 ->
> 1.4.200
> [INFO] commons-codec:commons-codec . 1.14 ->
> 1.15
> [INFO] commons-collections:commons-collections 3.2.2 ->
> 20040616
> [INFO] commons-io:commons-io ... 2.6 ->
> 2.8.0
> [INFO] io.dropwizard.metrics:metrics-core . 3.2.6 ->
> 4.2.0-beta.1
> [INFO] org.antlr:antlr4-runtime .. 4.7.2 ->
> 4.9.1
> [INFO] org.apache.commons:commons-lang3 . 3.9 ->
> 3.11
> [INFO] org.apache.felix:org.apache.felix.configadmin ... 1.9.16 ->
> 1.9.20
> [INFO] org.apache.felix:org.apache.felix.eventadmin .. 1.5.0 ->
> 1.6.2
> [INFO] org.apache.felix:org.apache.felix.http.jetty . 4.0.18 ->
> 4.1.4
> [INFO] org.apache.felix:org.apache.felix.metatype 1.2.2 ->
> 1.2.4
> [INFO] org.apache.felix:org.apache.felix.scr ... 2.1.20 ->
> 2.1.24
> [INFO] org.apache.felix:org.apache.felix.utils . 1.11.2 ->
> 1.11.6
> [INFO] org.apache.felix:org.apache.felix.webconsole .. 4.5.0 ->
> 4.6.0
> [INFO] org.apache.geronimo.specs:geronimo-annotation_1.3_spec 1.1 ->
> 1.3
> [INFO] org.apache.geronimo.specs:geronimo-atinject_1.0_spec .. 1.1 ->
> 1.2
> [INFO] org.apache.httpcomponents:httpclient 4.5.10 ->
> 4.5.13
> [INFO] org.apache.httpcomponents:httpclient-osgi ... 4.5.10 ->
> 4.5.13
> [INFO] org.apache.httpcomponents:httpcore-osgi . 4.4.12 ->
> 4.4.14
> [INFO] org.apache.jackrabbit:jackrabbit-data ... 2.20.0 ->
> 2.21.5
> [INFO] org.apache.jackrabbit:jackrabbit-jcr-commons 2.20.0 ->
> 2.21.5
> [INFO] org.apache.jackrabbit:jackrabbit-jcr-rmi 2.20.0 ->
> 2.21.5
> [INFO] org.apache.jackrabbit:jackrabbit-spi 2.20.0 ->
> 2.21.5
> [INFO] org.apache.jackrabbit:jackrabbit-spi-commons 2.20.0 ->
> 2.21.5
> [INFO] org.apache.jackrabbit:jackrabbit-webdav . 2.20.0 ->
> 2.21.5
> [INFO] org.apache.jackrabbit:oak-api ... 1.32.0 ->
> 1.38.0
> [INFO] org.apache.jackrabbit:oak-authorization-principalbased ...
> [INFO] 1.32.0 ->
> 1.38.0
> [INFO] org.apache.jackrabbit:oak-blob .. 1.32.0 ->
> 1.38.0
> [INFO] org.apache.jackrabbit:oak-blob-plugins .. 1.32.0 ->
> 1.38.0
> [INFO] org.apache.jackrabbit:oak-commons ... 1.32.0 ->
> 1.38.0
> [INFO] org.apache.jackrabbit:oak-core .. 1.32.0 ->
> 1.38.0
> [INFO] org.apache.jackrabbit:oak-core-spi .. 1.32.0 ->
> 1.38.0
> [INFO] org.apache.jackrabbit:oak-jackrabbit-api
[jira] [Commented] (SLING-9874) Allow adapting SlingHttpServletRequest and ResourceResolver to XSSAPI
[
https://issues.apache.org/jira/browse/SLING-9874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17284697#comment-17284697
]
Julian Sedding commented on SLING-9874:
---
Thanks [~radu]!
> Allow adapting SlingHttpServletRequest and ResourceResolver to XSSAPI
> -
>
> Key: SLING-9874
> URL: https://issues.apache.org/jira/browse/SLING-9874
> Project: Sling
> Issue Type: New Feature
> Components: XSS Protection API
>Affects Versions: XSS Protection API 2.2.6
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
> Fix For: XSS Protection API 2.2.8
>
>
> Most commonly an {{XSSAPI}} instance is needed when rendering a response
> body. In such circumstances, it can be cumbersome to retrieve the {{XSSAPI}}
> service. To add some convenience, it would be nice to be able to adapt a
> {{SlingHttpServletRequest}} or a {{ResourceResolver}} to an {{XSSAPI}}
> instance.
> *15.02.2021: This has been reverted in [commit
> dd7ff4b|https://github.com/apache/sling-org-apache-sling-xss/commit/dd7ff4b]*
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SLING-10012) Lookup of precompiled template files does not work
[
https://issues.apache.org/jira/browse/SLING-10012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17284688#comment-17284688
]
Olena edited comment on SLING-10012 at 2/15/21, 12:14 PM:
--
[~radu] Yes, you are right. It's in fact the same scenario. I'm removing the
comment since it doesn't bring any new details.
was (Author: slyshkova):
[Radu
Cotescu|applewebdata://DF5E1D29-D59A-4084-A920-ADC191C70F43/jira/secure/ViewProfile.jspa?name=radu]
Yes, you are right. It's in fact the same scenario. I'm removing the comment
since it doesn't bring any new details.
> Lookup of precompiled template files does not work
> --
>
> Key: SLING-10012
> URL: https://issues.apache.org/jira/browse/SLING-10012
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting HTL Engine 1.4.6-1.4.0
>Reporter: Konrad Windszus
>Assignee: Radu Cotescu
>Priority: Major
>
> I have a resource type {{a}} with a bundled script {{a.html}} which contains
> {code}
> data-sly-call="${simpleTemplate.simple}">
> {code}
> I have an extended resource type {{myA}} which has {{a}} as
> resourceSuperType. That one contains {{simple.html}} as precompiled script
> file. Still the lookup when trying to render a resource based on {{myA}}
> fails with
> {code}
> Caused by: org.apache.sling.scripting.sightly.SightlyException: No use
> provider could resolve identifier simple.html
> at
> org.apache.sling.scripting.sightly.impl.engine.extension.use.UseRuntimeExtension.call(UseRuntimeExtension.java:79)
> [org.apache.sling.scripting.sightly:1.4.6.140]
> at
> org.apache.sling.scripting.sightly.impl.engine.runtime.RenderContextImpl.call(RenderContextImpl.java:72)
> [org.apache.sling.scripting.sightly:1.4.6.140]
> at
> org.apache.sling.scripting.sightly.__002e__html.render(container__002e__html.java:62)
> {code}
> It works fine when trying to render a resource directly leveraging {{a}}, but
> in that case obviously the bundled {{a/simple.html}} is used
> Seems that the fix from SLING-9718 has not yet covered this use case.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-10012) Lookup of precompiled template files does not work
[
https://issues.apache.org/jira/browse/SLING-10012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17284688#comment-17284688
]
Olena commented on SLING-10012:
---
[Radu
Cotescu|applewebdata://DF5E1D29-D59A-4084-A920-ADC191C70F43/jira/secure/ViewProfile.jspa?name=radu]
Yes, you are right. It's in fact the same scenario. I'm removing the comment
since it doesn't bring any new details.
> Lookup of precompiled template files does not work
> --
>
> Key: SLING-10012
> URL: https://issues.apache.org/jira/browse/SLING-10012
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting HTL Engine 1.4.6-1.4.0
>Reporter: Konrad Windszus
>Assignee: Radu Cotescu
>Priority: Major
>
> I have a resource type {{a}} with a bundled script {{a.html}} which contains
> {code}
> data-sly-call="${simpleTemplate.simple}">
> {code}
> I have an extended resource type {{myA}} which has {{a}} as
> resourceSuperType. That one contains {{simple.html}} as precompiled script
> file. Still the lookup when trying to render a resource based on {{myA}}
> fails with
> {code}
> Caused by: org.apache.sling.scripting.sightly.SightlyException: No use
> provider could resolve identifier simple.html
> at
> org.apache.sling.scripting.sightly.impl.engine.extension.use.UseRuntimeExtension.call(UseRuntimeExtension.java:79)
> [org.apache.sling.scripting.sightly:1.4.6.140]
> at
> org.apache.sling.scripting.sightly.impl.engine.runtime.RenderContextImpl.call(RenderContextImpl.java:72)
> [org.apache.sling.scripting.sightly:1.4.6.140]
> at
> org.apache.sling.scripting.sightly.__002e__html.render(container__002e__html.java:62)
> {code}
> It works fine when trying to render a resource directly leveraging {{a}}, but
> in that case obviously the bundled {{a/simple.html}} is used
> Seems that the fix from SLING-9718 has not yet covered this use case.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [VOTE] Release Apache Sling XSS Protection API 2.2.10
+1 Carsten Am 15.02.2021 um 11:45 schrieb Radu Cotescu: Hi, We solved 2 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12349351 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2411/ You can use this UNIX script to download the release and verify the signatures: https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD Usage: sh check_staged_release.sh 2411 /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. Regards, Radu Cotescu -- -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Resolved] (SLING-10130) Allow to retrieve serverUri from MessagingProvider
[ https://issues.apache.org/jira/browse/SLING-10130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved SLING-10130. - Resolution: Fixed > Allow to retrieve serverUri from MessagingProvider > -- > > Key: SLING-10130 > URL: https://issues.apache.org/jira/browse/SLING-10130 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Affects Versions: Content Distribution Journal Messages 0.2.0 >Reporter: Christian Schneider >Assignee: Christian Schneider >Priority: Major > Fix For: Content Distribution Journal Messages 0.2.2 > > > Offsets are only valid in relation to a messaging system and topic name. As > we need to store offsets in relation to those two we need a way for a client > of MessagingProvider to get the server URI. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-10012) Lookup of precompiled template files does not work
[
https://issues.apache.org/jira/browse/SLING-10012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17284760#comment-17284760
]
Radu Cotescu commented on SLING-10012:
--
As soon as SLING- is addressed I'll proceed with a fix for this issue too.
They're unrelated, but I cannot release a new HTL engine version since the
engine consumes APIs under discussion.
> Lookup of precompiled template files does not work
> --
>
> Key: SLING-10012
> URL: https://issues.apache.org/jira/browse/SLING-10012
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting HTL Engine 1.4.6-1.4.0
>Reporter: Konrad Windszus
>Assignee: Radu Cotescu
>Priority: Major
>
> I have a resource type {{a}} with a bundled script {{a.html}} which contains
> {code}
> data-sly-call="${simpleTemplate.simple}">
> {code}
> I have an extended resource type {{myA}} which has {{a}} as
> resourceSuperType. That one contains {{simple.html}} as precompiled script
> file. Still the lookup when trying to render a resource based on {{myA}}
> fails with
> {code}
> Caused by: org.apache.sling.scripting.sightly.SightlyException: No use
> provider could resolve identifier simple.html
> at
> org.apache.sling.scripting.sightly.impl.engine.extension.use.UseRuntimeExtension.call(UseRuntimeExtension.java:79)
> [org.apache.sling.scripting.sightly:1.4.6.140]
> at
> org.apache.sling.scripting.sightly.impl.engine.runtime.RenderContextImpl.call(RenderContextImpl.java:72)
> [org.apache.sling.scripting.sightly:1.4.6.140]
> at
> org.apache.sling.scripting.sightly.__002e__html.render(container__002e__html.java:62)
> {code}
> It works fine when trying to render a resource directly leveraging {{a}}, but
> in that case obviously the bundled {{a/simple.html}} is used
> Seems that the fix from SLING-9718 has not yet covered this use case.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-10096) Allow the SlingHttpServletRequest in the IncludeGenerator or Sling dynamic includes
[ https://issues.apache.org/jira/browse/SLING-10096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17284796#comment-17284796 ] Santiago García Pimentel commented on SLING-10096: -- hi [~rombert] sorry for the delay. I had some busy time. you are a right about exported packages. I forgot about that. My need is to have SDIs where the used selector is dynamic based on certain conditions (mostly some user's group). So far I have a work around using two SDIs in a row, but that seems combersome. My idea would be to export the API so to allow to implement additional include generators for more complex scenarios. I think besides what has been done in my PR I would need to export the package with the API. WDYT?, I understand this might be too niche to implement (and as said, I got a workaround) but I think it would be nice to have that option. > Allow the SlingHttpServletRequest in the IncludeGenerator or Sling dynamic > includes > --- > > Key: SLING-10096 > URL: https://issues.apache.org/jira/browse/SLING-10096 > Project: Sling > Issue Type: Improvement >Reporter: Santiago García Pimentel >Priority: Major > > The current interface of the IncludeGenerator of Sling Dynamic Includes only > pass the String with the original URL. > It would be great to allow to pass it also the Request to allow clients to > implement more robust/complex implementations. > For example, allow to create SDI that use the information of the user making > the request -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-10096) Allow the SlingHttpServletRequest in the IncludeGenerator or Sling dynamic includes
[ https://issues.apache.org/jira/browse/SLING-10096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17284821#comment-17284821 ] Robert Munteanu commented on SLING-10096: - Thanks for the context [~santiagozky]. I think exporting an API is fine for this scenario. Could this be done as a separate, new, package, so we avoid any conflicts with the old exports and start with a minimal API surface? > Allow the SlingHttpServletRequest in the IncludeGenerator or Sling dynamic > includes > --- > > Key: SLING-10096 > URL: https://issues.apache.org/jira/browse/SLING-10096 > Project: Sling > Issue Type: Improvement >Reporter: Santiago García Pimentel >Priority: Major > > The current interface of the IncludeGenerator of Sling Dynamic Includes only > pass the String with the original URL. > It would be great to allow to pass it also the Request to allow clients to > implement more robust/complex implementations. > For example, allow to create SDI that use the information of the user making > the request -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-10144) Support OR and NOT logic in run modes
[ https://issues.apache.org/jira/browse/SLING-10144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated SLING-10144: Description: The patterns introduced in SLING-9031 and SLING-8548 should be supported when extracting OSGi configuration in the cp2fm converter. This code needs to be adjusted accordingly: https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/master/src/main/java/org/apache/sling/feature/cpconverter/handlers/AbstractConfigurationEntryHandler.java#L87 Most probably this requires to initially specify the target run modes to figure out to which ones to add the according configuration. was:The patterns introduced in SLING-9031 and SLING-8548 should be supported when extracting OSGi configuration in the cp2fm converter. This code needs to be adjusted accordingly: https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/master/src/main/java/org/apache/sling/feature/cpconverter/handlers/AbstractConfigurationEntryHandler.java#L87 > Support OR and NOT logic in run modes > - > > Key: SLING-10144 > URL: https://issues.apache.org/jira/browse/SLING-10144 > Project: Sling > Issue Type: Improvement > Components: Content-Package to Feature Model Converter >Affects Versions: Content-Package to Feature Model Converter 1.0.24 >Reporter: Konrad Windszus >Priority: Major > > The patterns introduced in SLING-9031 and SLING-8548 should be supported when > extracting OSGi configuration in the cp2fm converter. This code needs to be > adjusted accordingly: > https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/master/src/main/java/org/apache/sling/feature/cpconverter/handlers/AbstractConfigurationEntryHandler.java#L87 > Most probably this requires to initially specify the target run modes to > figure out to which ones to add the according configuration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-10096) Allow the SlingHttpServletRequest in the IncludeGenerator or Sling dynamic includes
[ https://issues.apache.org/jira/browse/SLING-10096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17284831#comment-17284831 ] Santiago García Pimentel commented on SLING-10096: -- yes. that seems reasonable. > Allow the SlingHttpServletRequest in the IncludeGenerator or Sling dynamic > includes > --- > > Key: SLING-10096 > URL: https://issues.apache.org/jira/browse/SLING-10096 > Project: Sling > Issue Type: Improvement >Reporter: Santiago García Pimentel >Priority: Major > > The current interface of the IncludeGenerator of Sling Dynamic Includes only > pass the String with the original URL. > It would be great to allow to pass it also the Request to allow clients to > implement more robust/complex implementations. > For example, allow to create SDI that use the information of the user making > the request -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SLING-10144) Support OR and NOT logic in run mode support
Konrad Windszus created SLING-10144: --- Summary: Support OR and NOT logic in run mode support Key: SLING-10144 URL: https://issues.apache.org/jira/browse/SLING-10144 Project: Sling Issue Type: Improvement Components: Content-Package to Feature Model Converter Affects Versions: Content-Package to Feature Model Converter 1.0.24 Reporter: Konrad Windszus The patterns introduced in SLING-9031 and SLING-8548 should be supported when extracting OSGi configuration in the cp2fm converter. This code needs to be adjusted accordingly: https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/master/src/main/java/org/apache/sling/feature/cpconverter/handlers/AbstractConfigurationEntryHandler.java#L87 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-10144) Support OR and NOT logic in run modes
[ https://issues.apache.org/jira/browse/SLING-10144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated SLING-10144: Summary: Support OR and NOT logic in run modes (was: Support OR and NOT logic in run mode support) > Support OR and NOT logic in run modes > - > > Key: SLING-10144 > URL: https://issues.apache.org/jira/browse/SLING-10144 > Project: Sling > Issue Type: Improvement > Components: Content-Package to Feature Model Converter >Affects Versions: Content-Package to Feature Model Converter 1.0.24 >Reporter: Konrad Windszus >Priority: Major > > The patterns introduced in SLING-9031 and SLING-8548 should be supported when > extracting OSGi configuration in the cp2fm converter. This code needs to be > adjusted accordingly: > https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/master/src/main/java/org/apache/sling/feature/cpconverter/handlers/AbstractConfigurationEntryHandler.java#L87 -- This message was sent by Atlassian Jira (v8.3.4#803005)
