[Jenkins] Sling » Modules » sling-org-apache-sling-launchpad-testing » master #629 is BROKEN
kins-event-spy] Generated
/home/jenkins/workspace/e-sling-launchpad-testing_master@tmp/withMavenbf0fb3c6/maven-spy-20210818-112445-513113042944903761145.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/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] }
[DevOpticsMavenPublisher] dependencies consumed: 0, artifacts produced: 0
[withMaven] Publishers: Pipeline Graph Publisher: 1 ms, CloudBees DevOptics
Gate Artifact Publisher: 34832 ms
[Pipeline] // withMaven
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // timeout
[Pipeline] stage
[Pipeline] { (Notifications)
[Pipeline] echo
Status change is BROKEN, notifications will be sent.
[Pipeline] emailext
[Jenkins] Sling » Modules » sling-org-apache-sling-launchpad-testing » master #630 is FIXED
Please see https://ci-builds.apache.org/job/Sling/job/modules/job/sling-org-apache-sling-launchpad-testing/job/master/630/ for details. No further emails will be sent until the status of the build is changed.
[jira] [Created] (SLING-10741) ['one','two'] should not be considered a script in a pipe expression
Nicolas Peltier created SLING-10741:
---
Summary: ['one','two'] should not be considered a script in a pipe
expression
Key: SLING-10741
URL: https://issues.apache.org/jira/browse/SLING-10741
Project: Sling
Issue Type: Bug
Components: Extensions
Affects Versions: Pipes 4.1.2
Reporter: Nicolas Peltier
for whatever reason ['one','two'] get transformed in ${['one','two']} as if it
was a script which it's not. this prevents adding mixin types (when more than
one) as values of that property can't be something random (in the configuration
pipe)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [sling-org-apache-sling-feature-launcher] sonarcloud[bot] commented on pull request #29: SLING-10723: Update to Apache Johnzon 1.2.14
sonarcloud[bot] commented on pull request #29: URL: https://github.com/apache/sling-org-apache-sling-feature-launcher/pull/29#issuecomment-901108379 Kudos, SonarCloud Quality Gate passed!  [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-launcher&pullRequest=29&resolved=false&types=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-launcher&pullRequest=29&resolved=false&types=BUG) [0 Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-launcher&pullRequest=29&resolved=false&types=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-launcher&pullRequest=29&resolved=false&types=VULNERABILITY) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-launcher&pullRequest=29&resolved=false&types=VULNERABILITY) [0 Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-launcher&pullRequest=29&resolved=false&types=VULNERABILITY) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-feature-launcher&pullRequest=29&resolved=false&types=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-feature-launcher&pullRequest=29&resolved=false&types=SECURITY_HOTSPOT) [0 Security Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-feature-launcher&pullRequest=29&resolved=false&types=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-launcher&pullRequest=29&resolved=false&types=CODE_SMELL) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-launcher&pullRequest=29&resolved=false&types=CODE_SMELL) [0 Code Smells](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-launcher&pullRequest=29&resolved=false&types=CODE_SMELL) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-launcher&pullRequest=29&metric=coverage&view=list) No Coverage information [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-launcher&pullRequest=29&metric=new_duplicated_lines_density&view=list) [0.0% Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-launcher&pullRequest=29&metric=new_duplicated_lines_density&view=list) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Resolved] (SLING-10741) ['one','two'] should not be considered a script in a pipe expression
[
https://issues.apache.org/jira/browse/SLING-10741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Peltier resolved SLING-10741.
-
Fix Version/s: Pipes 4.2.0
Resolution: Fixed
> ['one','two'] should not be considered a script in a pipe expression
>
>
> Key: SLING-10741
> URL: https://issues.apache.org/jira/browse/SLING-10741
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Pipes 4.1.2
>Reporter: Nicolas Peltier
>Priority: Major
> Fix For: Pipes 4.2.0
>
>
> for whatever reason ['one','two'] get transformed in ${['one','two']} as if
> it was a script which it's not. this prevents adding mixin types (when more
> than one) as values of that property can't be something random (in the
> configuration pipe)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [sling-org-apache-sling-feature-launcher] karlpauls merged pull request #29: SLING-10723: Update to Apache Johnzon 1.2.14
karlpauls merged pull request #29: URL: https://github.com/apache/sling-org-apache-sling-feature-launcher/pull/29 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (SLING-10742) Create integration tests for ResourceResolver
Henry Kuijpers created SLING-10742: -- Summary: Create integration tests for ResourceResolver Key: SLING-10742 URL: https://issues.apache.org/jira/browse/SLING-10742 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.7.10 Reporter: Henry Kuijpers Now that the logic in Resource Resolver becomes more and more complex, it would be a good idea to create some integration tests for this module. This came up in SLING-10447, where we decided that verifying the correct execution of the querys would be valuable to have. Right now, only the string (that contains the query) is checked, but we're not checking if there are any syntax issues and we're also not checking if the query executes correctly, i.e. returns the expected results. We will probably come up with some more complex logic in SLING-10466, which could also benefit from these integration tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [sling-org-apache-sling-resourceresolver] henrykuijpers commented on a change in pull request #46: SLING-10447 Improve the querys that are used to load vanity paths, by specifying path restri
henrykuijpers commented on a change in pull request #46:
URL:
https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/46#discussion_r691306477
##
File path:
src/test/java/org/apache/sling/resourceresolver/impl/mapping/MapEntriesTest.java
##
@@ -370,26 +381,31 @@ public void test_vanity_path_updates() throws Exception {
@Test
public void test_vanity_path_registration_include_exclude() throws
IOException {
final String[] validPaths = {"/libs/somewhere", "/libs/a/b", "/foo/a",
"/baa/a"};
-final String[] invalidPaths = {"/libs/denied/a", "/libs/denied/b/c",
"/nowhere"};
final List resources = new ArrayList<>();
for(final String val : validPaths) {
resources.add(getVanityPathResource(val));
}
-for(final String val : invalidPaths) {
-resources.add(getVanityPathResource(val));
-}
-
-
-when(resourceResolver.findResources(anyString(),
eq("sql"))).thenAnswer(new Answer>() {
-
-@Override
-public Iterator answer(InvocationOnMock invocation)
throws Throwable {
-if
(invocation.getArguments()[0].toString().contains("sling:vanityPath")) {
-return resources.iterator();
-} else {
-return Collections. emptySet().iterator();
-}
+when(resourceResolver.findResources(anyString(),
eq("sql"))).thenAnswer((Answer>) invocation -> {
Review comment:
Indeed, it looks like `ResourceResolverType.JCR_OAK` is a solution that
can actually parse and execute a query. Very cool! I've been using it in the
project I'm working on and that's really nice. It's also nice that I was able
to get com.day.cq.search working in the unit test, to test the predicate search
that we're executing. But that's something outside Sling, of course.
I've created https://issues.apache.org/jira/browse/SLING-10742 to tackle
this.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (SLING-10136) Sling Repo Init: Add option to delete paths
[ https://issues.apache.org/jira/browse/SLING-10136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1740#comment-1740 ] Angela Schreiber commented on SLING-10136: -- [~karlpauls], it seems a bit arbitrary to avoid adding a delete path statement, if there is a corresponding remove/delete operation for almost all other adding/creation statement (users, groups, policies, individual access control entries). and removing a node that doesn't exist can equally be a noop as the create counter part. > Sling Repo Init: Add option to delete paths > --- > > Key: SLING-10136 > URL: https://issues.apache.org/jira/browse/SLING-10136 > Project: Sling > Issue Type: New Feature > Components: Repoinit >Affects Versions: Repoinit Parser 1.6.4, Repoinit JCR 1.1.30 >Reporter: Henry Kuijpers >Priority: Major > Time Spent: 2h > Remaining Estimate: 0h > > Given that we are able to create paths, it would also be beneficial to be > able to delete paths as well. > In our case, we're migrating a legacy setup to Sling Repo Init, where there > are some "leftover" nodes in the instances. Given that Sling Repo Init is an > "admin" way to initialize a repo, it would be very nice if delete statements > could be supported. > In our case, we would want to delete /apps/foundation, for example, because > historically there seem to have been modifications made there. > This mandates for a simple syntax like "delete path /apps/foundation" being > supported. > Another case is that we would like to cleanup /apps/cq, however, there are > some nodes that are maintained by the product (in our case AEM), such as > /apps/cq/xssprotection and also /apps/cq/core/content/nav/tools. > This mandates for a slightly more complicated syntax such as "delete path > /apps/cq (!/xssprotection,!/core/content/nav/tools,*)", however, I would be > fine with multiple delete path statements as well, for that usecase. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-10447) sling:vanityPath are being searched during startup in the entire repository, including version storage
[ https://issues.apache.org/jira/browse/SLING-10447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401112#comment-17401112 ] Henry Kuijpers commented on SLING-10447: Any idea how we can make some progress on this one, [~cziegeler], [~jsedding], [~bdelacretaz]? I just made https://issues.apache.org/jira/browse/SLING-10742 to tackle the integration tests for the ResourceResolver-module. > sling:vanityPath are being searched during startup in the entire repository, > including version storage > -- > > Key: SLING-10447 > URL: https://issues.apache.org/jira/browse/SLING-10447 > Project: Sling > Issue Type: Bug > Components: ResourceResolver >Affects Versions: Resource Resolver 1.7.6 >Reporter: Henry Kuijpers >Priority: Major > Attachments: with-path-restrictions.json, > without-path-restrictions.json > > Time Spent: 5.5h > Remaining Estimate: 0h > > We have a lot of pages on our production author instance. We also have a lot > of pages that use sling:vanityPath. Everytime a page is replicated, a new > version is created. > We have roughly 168.000 pages in our instance. In the /content node, there > are approx. 4500 pages with vanity URLs. In the version storage, however, > there are 120.000+ entries that have a sling:vanityPath defined. > When starting up Apache Sling, the Resource Resolver fetches all the existing > sling:vanityPath entries, which it fails to do, because of the large amount > of sling:vanityPath in the version storage. > In the code, I specifically see checks (when processing the query results) > about the version storage. However, this should have been put inside the > query as a filter, in order to avoid fetching such a large amount of query > result nodes: > https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/4406b8fed0fedb48202fc6472fb552c36aa06e35/src/main/java/org/apache/sling/resourceresolver/impl/mapping/MapEntries.java#L1158 > I propose to update the query with a "not isdescendantnode"-check, to make > sure we do not return any content from the version storage and thus make the > default query limits of 100.000 nodes work again. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-10742) Create integration tests for ResourceResolver
[ https://issues.apache.org/jira/browse/SLING-10742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henry Kuijpers updated SLING-10742: --- Description: Now that the logic in Resource Resolver becomes more and more complex, for example with regards to executing querys, it would be a good idea to create some integration tests for this module. Mocking frameworks only go so far, many assumptions are made. In particular, query execution is not done in our mocking frameworks. Instead of executing them, we're basically saying "If we receive query 'x', we return results [y, z]", without validating the query, without parsing it, without executing it. This came up in SLING-10447, where we decided that verifying the correct execution of the querys would be valuable to have. Right now, only the string (that contains the query) is checked, but we're not checking if there are any syntax issues and we're also not checking if the query executes correctly, i.e. returns the expected results. We will probably come up with some more complex logic in SLING-10466, which could also benefit from these integration tests. was: Now that the logic in Resource Resolver becomes more and more complex, it would be a good idea to create some integration tests for this module. This came up in SLING-10447, where we decided that verifying the correct execution of the querys would be valuable to have. Right now, only the string (that contains the query) is checked, but we're not checking if there are any syntax issues and we're also not checking if the query executes correctly, i.e. returns the expected results. We will probably come up with some more complex logic in SLING-10466, which could also benefit from these integration tests. > Create integration tests for ResourceResolver > - > > Key: SLING-10742 > URL: https://issues.apache.org/jira/browse/SLING-10742 > Project: Sling > Issue Type: Improvement > Components: ResourceResolver >Affects Versions: Resource Resolver 1.7.10 >Reporter: Henry Kuijpers >Priority: Minor > > Now that the logic in Resource Resolver becomes more and more complex, for > example with regards to executing querys, it would be a good idea to create > some integration tests for this module. > Mocking frameworks only go so far, many assumptions are made. In particular, > query execution is not done in our mocking frameworks. Instead of executing > them, we're basically saying "If we receive query 'x', we return results [y, > z]", without validating the query, without parsing it, without executing it. > This came up in SLING-10447, where we decided that verifying the correct > execution of the querys would be valuable to have. Right now, only the string > (that contains the query) is checked, but we're not checking if there are any > syntax issues and we're also not checking if the query executes correctly, > i.e. returns the expected results. > We will probably come up with some more complex logic in SLING-10466, which > could also benefit from these integration tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-10136) Sling Repo Init: Add option to delete paths
[ https://issues.apache.org/jira/browse/SLING-10136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401120#comment-17401120 ] Henry Kuijpers commented on SLING-10136: My vote: Please support it. I very much agree with [~enorman] and [~angela] here. > Sling Repo Init: Add option to delete paths > --- > > Key: SLING-10136 > URL: https://issues.apache.org/jira/browse/SLING-10136 > Project: Sling > Issue Type: New Feature > Components: Repoinit >Affects Versions: Repoinit Parser 1.6.4, Repoinit JCR 1.1.30 >Reporter: Henry Kuijpers >Priority: Major > Time Spent: 2h > Remaining Estimate: 0h > > Given that we are able to create paths, it would also be beneficial to be > able to delete paths as well. > In our case, we're migrating a legacy setup to Sling Repo Init, where there > are some "leftover" nodes in the instances. Given that Sling Repo Init is an > "admin" way to initialize a repo, it would be very nice if delete statements > could be supported. > In our case, we would want to delete /apps/foundation, for example, because > historically there seem to have been modifications made there. > This mandates for a simple syntax like "delete path /apps/foundation" being > supported. > Another case is that we would like to cleanup /apps/cq, however, there are > some nodes that are maintained by the product (in our case AEM), such as > /apps/cq/xssprotection and also /apps/cq/core/content/nav/tools. > This mandates for a slightly more complicated syntax such as "delete path > /apps/cq (!/xssprotection,!/core/content/nav/tools,*)", however, I would be > fine with multiple delete path statements as well, for that usecase. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-10136) Sling Repo Init: Add option to delete paths
[ https://issues.apache.org/jira/browse/SLING-10136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401131#comment-17401131 ] Karl Pauls commented on SLING-10136: [~angela], I don't disagree - as I said, we already have these unfortunately. The question is where do we take it from here. From my POV, we have two options - namely, 1. keep enhancing repoinit until it grows into a "repomanage" DSLs (which may or may not have certain features togglable via configuration) 2. provide a second DSL for the more upgrade/managment related tasks (which may or may not be a superset of repoinit) and [~enorman], I don't think it is about limiting somebody - it is a question of what users can expect to be able todo with it. Thats why I personally don't know about enabling/disabling part of the DSL via configuration - that would make it hard for people to know if a given repoinit would work or not. Overall, I'd be in favor of just providing a second DSL that is a superset of repoinit if we where to support more upgrade tasks. We could even keep it in the same bundle(s) - just effectively have it come from different sources like a different configuration or something so that it is clear they are different things. > Sling Repo Init: Add option to delete paths > --- > > Key: SLING-10136 > URL: https://issues.apache.org/jira/browse/SLING-10136 > Project: Sling > Issue Type: New Feature > Components: Repoinit >Affects Versions: Repoinit Parser 1.6.4, Repoinit JCR 1.1.30 >Reporter: Henry Kuijpers >Priority: Major > Time Spent: 2h > Remaining Estimate: 0h > > Given that we are able to create paths, it would also be beneficial to be > able to delete paths as well. > In our case, we're migrating a legacy setup to Sling Repo Init, where there > are some "leftover" nodes in the instances. Given that Sling Repo Init is an > "admin" way to initialize a repo, it would be very nice if delete statements > could be supported. > In our case, we would want to delete /apps/foundation, for example, because > historically there seem to have been modifications made there. > This mandates for a simple syntax like "delete path /apps/foundation" being > supported. > Another case is that we would like to cleanup /apps/cq, however, there are > some nodes that are maintained by the product (in our case AEM), such as > /apps/cq/xssprotection and also /apps/cq/core/content/nav/tools. > This mandates for a slightly more complicated syntax such as "delete path > /apps/cq (!/xssprotection,!/core/content/nav/tools,*)", however, I would be > fine with multiple delete path statements as well, for that usecase. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-10741) make mixinTypes working in write pipe
[
https://issues.apache.org/jira/browse/SLING-10741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Peltier updated SLING-10741:
Summary: make mixinTypes working in write pipe (was: ['one','two'] should
not be considered a script in a pipe expression)
> make mixinTypes working in write pipe
> -
>
> Key: SLING-10741
> URL: https://issues.apache.org/jira/browse/SLING-10741
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Pipes 4.1.2
>Reporter: Nicolas Peltier
>Priority: Major
> Fix For: Pipes 4.2.0
>
>
> for whatever reason ['one','two'] get transformed in ${['one','two']} as if
> it was a script which it's not. this prevents adding mixin types (when more
> than one) as values of that property can't be something random (in the
> configuration pipe)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Reopened] (SLING-10741) make mixinTypes working in write pipe
[
https://issues.apache.org/jira/browse/SLING-10741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Peltier reopened SLING-10741:
-
Assignee: Nicolas Peltier
> make mixinTypes working in write pipe
> -
>
> Key: SLING-10741
> URL: https://issues.apache.org/jira/browse/SLING-10741
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Pipes 4.1.2
>Reporter: Nicolas Peltier
>Assignee: Nicolas Peltier
>Priority: Major
> Fix For: Pipes 4.2.0
>
>
> for whatever reason ['one','two'] get transformed in ${['one','two']} as if
> it was a script which it's not. this prevents adding mixin types (when more
> than one) as values of that property can't be something random (in the
> configuration pipe)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-10741) make mixinTypes working in write pipe
[
https://issues.apache.org/jira/browse/SLING-10741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Peltier updated SLING-10741:
Description: actually current is good enough, and just does not work with
protected values, will rather add exception for mixin types, and explicitaly
make sure that works down to the writing bits (was: for whatever reason
['one','two'] get transformed in ${['one','two']} as if it was a script which
it's not. this prevents adding mixin types (when more than one) as values of
that property can't be something random (in the configuration pipe))
> make mixinTypes working in write pipe
> -
>
> Key: SLING-10741
> URL: https://issues.apache.org/jira/browse/SLING-10741
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Pipes 4.1.2
>Reporter: Nicolas Peltier
>Assignee: Nicolas Peltier
>Priority: Major
> Fix For: Pipes 4.2.0
>
>
> actually current is good enough, and just does not work with protected
> values, will rather add exception for mixin types, and explicitaly make sure
> that works down to the writing bits
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [sling-org-apache-sling-resourceresolver] cziegeler commented on a change in pull request #46: SLING-10447 Improve the querys that are used to load vanity paths, by specifying path restrictio
cziegeler commented on a change in pull request #46:
URL:
https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/46#discussion_r691402791
##
File path:
src/main/java/org/apache/sling/resourceresolver/impl/mapping/MapEntries.java
##
@@ -707,7 +748,7 @@ public void onChange(final List changes) {
log.debug("onChange, type={}, path={}", rc.getType(), path);
// don't care for system area
-if (path.startsWith(JCR_SYSTEM_PREFIX)) {
+if (path.startsWith(JCR_SYSTEM_PATH + '/')) {
Review comment:
while this is not a big deal, why did you change this from a constant to
an expression that is executed each time?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [sling-org-apache-sling-resourceresolver] cziegeler commented on a change in pull request #46: SLING-10447 Improve the querys that are used to load vanity paths, by specifying path restrictio
cziegeler commented on a change in pull request #46:
URL:
https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/46#discussion_r691402791
##
File path:
src/main/java/org/apache/sling/resourceresolver/impl/mapping/MapEntries.java
##
@@ -707,7 +748,7 @@ public void onChange(final List changes) {
log.debug("onChange, type={}, path={}", rc.getType(), path);
// don't care for system area
-if (path.startsWith(JCR_SYSTEM_PREFIX)) {
+if (path.startsWith(JCR_SYSTEM_PATH + '/')) {
Review comment:
while this is not a big deal, why did you change this from a constant to
an expression that is executed each time?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [sling-org-apache-sling-resourceresolver] henrykuijpers commented on a change in pull request #46: SLING-10447 Improve the querys that are used to load vanity paths, by specifying path restri
henrykuijpers commented on a change in pull request #46:
URL:
https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/46#discussion_r691306477
##
File path:
src/test/java/org/apache/sling/resourceresolver/impl/mapping/MapEntriesTest.java
##
@@ -370,26 +381,31 @@ public void test_vanity_path_updates() throws Exception {
@Test
public void test_vanity_path_registration_include_exclude() throws
IOException {
final String[] validPaths = {"/libs/somewhere", "/libs/a/b", "/foo/a",
"/baa/a"};
-final String[] invalidPaths = {"/libs/denied/a", "/libs/denied/b/c",
"/nowhere"};
final List resources = new ArrayList<>();
for(final String val : validPaths) {
resources.add(getVanityPathResource(val));
}
-for(final String val : invalidPaths) {
-resources.add(getVanityPathResource(val));
-}
-
-
-when(resourceResolver.findResources(anyString(),
eq("sql"))).thenAnswer(new Answer>() {
-
-@Override
-public Iterator answer(InvocationOnMock invocation)
throws Throwable {
-if
(invocation.getArguments()[0].toString().contains("sling:vanityPath")) {
-return resources.iterator();
-} else {
-return Collections. emptySet().iterator();
-}
+when(resourceResolver.findResources(anyString(),
eq("sql"))).thenAnswer((Answer>) invocation -> {
Review comment:
Indeed, it looks like `ResourceResolverType.JCR_OAK` is a solution that
can actually parse and execute a query. Very cool! I've been using it in the
project I'm working on and that's really nice. It's also nice that I was able
to get com.day.cq.search working in the unit test, to test the predicate search
that we're executing. But that's something outside Sling, of course.
I've created https://issues.apache.org/jira/browse/SLING-10742 to tackle
this.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (SLING-10447) sling:vanityPath are being searched during startup in the entire repository, including version storage
[ https://issues.apache.org/jira/browse/SLING-10447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401202#comment-17401202 ] Carsten Ziegeler commented on SLING-10447: -- To be honest, the PR is too large for me to grasp in total, there are changes to the configuration, how that configuration is evaluated alongside all the other changes around the querying - while in the end I expected just a change to construct the query . maybe others are able to eval the PR as-is > sling:vanityPath are being searched during startup in the entire repository, > including version storage > -- > > Key: SLING-10447 > URL: https://issues.apache.org/jira/browse/SLING-10447 > Project: Sling > Issue Type: Bug > Components: ResourceResolver >Affects Versions: Resource Resolver 1.7.6 >Reporter: Henry Kuijpers >Priority: Major > Attachments: with-path-restrictions.json, > without-path-restrictions.json > > Time Spent: 6h > Remaining Estimate: 0h > > We have a lot of pages on our production author instance. We also have a lot > of pages that use sling:vanityPath. Everytime a page is replicated, a new > version is created. > We have roughly 168.000 pages in our instance. In the /content node, there > are approx. 4500 pages with vanity URLs. In the version storage, however, > there are 120.000+ entries that have a sling:vanityPath defined. > When starting up Apache Sling, the Resource Resolver fetches all the existing > sling:vanityPath entries, which it fails to do, because of the large amount > of sling:vanityPath in the version storage. > In the code, I specifically see checks (when processing the query results) > about the version storage. However, this should have been put inside the > query as a filter, in order to avoid fetching such a large amount of query > result nodes: > https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/4406b8fed0fedb48202fc6472fb552c36aa06e35/src/main/java/org/apache/sling/resourceresolver/impl/mapping/MapEntries.java#L1158 > I propose to update the query with a "not isdescendantnode"-check, to make > sure we do not return any content from the version storage and thus make the > default query limits of 100.000 nodes work again. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-10136) Sling Repo Init: Add option to delete paths
[ https://issues.apache.org/jira/browse/SLING-10136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401213#comment-17401213 ] Carsten Ziegeler commented on SLING-10136: -- The past is not always a good indicator for the future - maybe it was a mistake to have all the other delete/remove operations in repoinit in the first place? Not sure But as Tim pointed out, Sling Pipes already exists - isn't that a good and sufficient solution? Do we need to make repoinit more and more bloated just to reimplement something that is already there? > Sling Repo Init: Add option to delete paths > --- > > Key: SLING-10136 > URL: https://issues.apache.org/jira/browse/SLING-10136 > Project: Sling > Issue Type: New Feature > Components: Repoinit >Affects Versions: Repoinit Parser 1.6.4, Repoinit JCR 1.1.30 >Reporter: Henry Kuijpers >Priority: Major > Time Spent: 2h > Remaining Estimate: 0h > > Given that we are able to create paths, it would also be beneficial to be > able to delete paths as well. > In our case, we're migrating a legacy setup to Sling Repo Init, where there > are some "leftover" nodes in the instances. Given that Sling Repo Init is an > "admin" way to initialize a repo, it would be very nice if delete statements > could be supported. > In our case, we would want to delete /apps/foundation, for example, because > historically there seem to have been modifications made there. > This mandates for a simple syntax like "delete path /apps/foundation" being > supported. > Another case is that we would like to cleanup /apps/cq, however, there are > some nodes that are maintained by the product (in our case AEM), such as > /apps/cq/xssprotection and also /apps/cq/core/content/nav/tools. > This mandates for a slightly more complicated syntax such as "delete path > /apps/cq (!/xssprotection,!/core/content/nav/tools,*)", however, I would be > fine with multiple delete path statements as well, for that usecase. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [sling-org-apache-sling-feature-launcher] sonarcloud[bot] commented on pull request #29: SLING-10723: Update to Apache Johnzon 1.2.14
sonarcloud[bot] commented on pull request #29: URL: https://github.com/apache/sling-org-apache-sling-feature-launcher/pull/29#issuecomment-901108379 Kudos, SonarCloud Quality Gate passed!  [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-launcher&pullRequest=29&resolved=false&types=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-launcher&pullRequest=29&resolved=false&types=BUG) [0 Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-launcher&pullRequest=29&resolved=false&types=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-launcher&pullRequest=29&resolved=false&types=VULNERABILITY) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-launcher&pullRequest=29&resolved=false&types=VULNERABILITY) [0 Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-launcher&pullRequest=29&resolved=false&types=VULNERABILITY) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-feature-launcher&pullRequest=29&resolved=false&types=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-feature-launcher&pullRequest=29&resolved=false&types=SECURITY_HOTSPOT) [0 Security Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-feature-launcher&pullRequest=29&resolved=false&types=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-launcher&pullRequest=29&resolved=false&types=CODE_SMELL) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-launcher&pullRequest=29&resolved=false&types=CODE_SMELL) [0 Code Smells](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-launcher&pullRequest=29&resolved=false&types=CODE_SMELL) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-launcher&pullRequest=29&metric=coverage&view=list) No Coverage information [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-launcher&pullRequest=29&metric=new_duplicated_lines_density&view=list) [0.0% Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-launcher&pullRequest=29&metric=new_duplicated_lines_density&view=list) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [sling-org-apache-sling-feature-launcher] karlpauls merged pull request #29: SLING-10723: Update to Apache Johnzon 1.2.14
karlpauls merged pull request #29: URL: https://github.com/apache/sling-org-apache-sling-feature-launcher/pull/29 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SLING-10136) Sling Repo Init: Add option to delete paths
[ https://issues.apache.org/jira/browse/SLING-10136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401285#comment-17401285 ] Eric Norman commented on SLING-10136: - Come on, [~karlpauls]. Lets not pretend that "I don't think it is about limiting somebody" and "it is a question of what users can expect to be able todo with it" in the same sentence do not directly contradict each other... [~cziegeler] Are you ultimately suggesting that repoinit should be marked as deprecated and everything should be migrated (automatically? or manually?) to sling pipes instead? If so that is a lot more work than what is proposed here. Also, I haven't looked that closely but I don't think pipes currently provides 100% feature parity. > Sling Repo Init: Add option to delete paths > --- > > Key: SLING-10136 > URL: https://issues.apache.org/jira/browse/SLING-10136 > Project: Sling > Issue Type: New Feature > Components: Repoinit >Affects Versions: Repoinit Parser 1.6.4, Repoinit JCR 1.1.30 >Reporter: Henry Kuijpers >Priority: Major > Time Spent: 2h > Remaining Estimate: 0h > > Given that we are able to create paths, it would also be beneficial to be > able to delete paths as well. > In our case, we're migrating a legacy setup to Sling Repo Init, where there > are some "leftover" nodes in the instances. Given that Sling Repo Init is an > "admin" way to initialize a repo, it would be very nice if delete statements > could be supported. > In our case, we would want to delete /apps/foundation, for example, because > historically there seem to have been modifications made there. > This mandates for a simple syntax like "delete path /apps/foundation" being > supported. > Another case is that we would like to cleanup /apps/cq, however, there are > some nodes that are maintained by the product (in our case AEM), such as > /apps/cq/xssprotection and also /apps/cq/core/content/nav/tools. > This mandates for a slightly more complicated syntax such as "delete path > /apps/cq (!/xssprotection,!/core/content/nav/tools,*)", however, I would be > fine with multiple delete path statements as well, for that usecase. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (SLING-10136) Sling Repo Init: Add option to delete paths
[ https://issues.apache.org/jira/browse/SLING-10136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401285#comment-17401285 ] Eric Norman edited comment on SLING-10136 at 8/18/21, 6:11 PM: --- Come on, [~karlpauls]. Lets not pretend that "I don't think it is about limiting somebody" and "it is a question of what users can expect to be able todo with it" in the same sentence do not directly contradict each other... [~cziegeler] Are you ultimately suggesting that repoinit should be marked as deprecated and everything should be migrated (automatically? or manually?) to sling pipes instead? If so that is a lot more work than what is proposed here. Also, I haven't looked that closely but I don't think pipes currently provides 100% feature parity or the hooks to run automatically during the repository initialization. was (Author: enorman): Come on, [~karlpauls]. Lets not pretend that "I don't think it is about limiting somebody" and "it is a question of what users can expect to be able todo with it" in the same sentence do not directly contradict each other... [~cziegeler] Are you ultimately suggesting that repoinit should be marked as deprecated and everything should be migrated (automatically? or manually?) to sling pipes instead? If so that is a lot more work than what is proposed here. Also, I haven't looked that closely but I don't think pipes currently provides 100% feature parity. > Sling Repo Init: Add option to delete paths > --- > > Key: SLING-10136 > URL: https://issues.apache.org/jira/browse/SLING-10136 > Project: Sling > Issue Type: New Feature > Components: Repoinit >Affects Versions: Repoinit Parser 1.6.4, Repoinit JCR 1.1.30 >Reporter: Henry Kuijpers >Priority: Major > Time Spent: 2h > Remaining Estimate: 0h > > Given that we are able to create paths, it would also be beneficial to be > able to delete paths as well. > In our case, we're migrating a legacy setup to Sling Repo Init, where there > are some "leftover" nodes in the instances. Given that Sling Repo Init is an > "admin" way to initialize a repo, it would be very nice if delete statements > could be supported. > In our case, we would want to delete /apps/foundation, for example, because > historically there seem to have been modifications made there. > This mandates for a simple syntax like "delete path /apps/foundation" being > supported. > Another case is that we would like to cleanup /apps/cq, however, there are > some nodes that are maintained by the product (in our case AEM), such as > /apps/cq/xssprotection and also /apps/cq/core/content/nav/tools. > This mandates for a slightly more complicated syntax such as "delete path > /apps/cq (!/xssprotection,!/core/content/nav/tools,*)", however, I would be > fine with multiple delete path statements as well, for that usecase. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SLING-10743) Multiple instances cleaning up distribution queue at the same time and causing commit failures
Alexei Krainiouk created SLING-10743:
Summary: Multiple instances cleaning up distribution queue at the
same time and causing commit failures
Key: SLING-10743
URL: https://issues.apache.org/jira/browse/SLING-10743
Project: Sling
Issue Type: Improvement
Components: Content Distribution
Reporter: Alexei Krainiouk
There doesn't seem to be an arbitration between different server instances when
distribution queue cleanup is concerned. This occasionally causes commit
failures inside
org.apache.sling.distribution.packaging.impl.ResourceDistributionPackageCleanup
class with the folllowing exception thrown:
{noformat}
org.apache.sling.distribution.packaging.impl.ResourceDistributionPackageCleanup
Failed to delete disposable packages
org.apache.sling.api.resource.PersistenceException: Unable to commit changes to
session.
at
org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.commit(JcrResourceProvider.java:516)
[org.apache.sling.jcr.resource:3.0.22]
at
org.apache.sling.resourceresolver.impl.providers.stateful.AuthenticatedResourceProvider.commit(AuthenticatedResourceProvider.java:215)
[org.apache.sling.resourceresolver:1.7.4]
at
org.apache.sling.resourceresolver.impl.helper.ResourceResolverControl.commit(ResourceResolverControl.java:425)
[org.apache.sling.resourceresolver:1.7.4]
at
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.commit(ResourceResolverImpl.java:1005)
[org.apache.sling.resourceresolver:1.7.4]
at
org.apache.sling.distribution.packaging.impl.ResourceDistributionPackageCleanup.run(ResourceDistributionPackageCleanup.java:71)
[org.apache.sling.distribution.core:0.4.5.T202105062218-732
6f21]
at
org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:349)
[org.apache.sling.commons.scheduler:2.7.12]
at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
[org.apache.sling.commons.scheduler:2.7.12]
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
Source)
at java.base/java.lang.Thread.run(Unknown Source)
Caused by: javax.jcr.InvalidItemStateException: OakState0001: Unresolved
conflicts in /var/sling/distribution/packages/signed-url/data
at
org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:238)
[org.apache.jackrabbit.oak-api:1.39.0.R1889746]
at
org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:213)
[org.apache.jackrabbit.oak-api:1.39.0.R1889746]
at
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.newRepositoryException(SessionDelegate.java:684)
[org.apache.jackrabbit.oak-jcr:1.39.0.R1889746]
at
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:505)
[org.apache.jackrabbit.oak-jcr:1.39.0.R1889746]
at
org.apache.jackrabbit.oak.jcr.session.SessionImpl$8.performVoid(SessionImpl.java:429)
[org.apache.jackrabbit.oak-jcr:1.39.0.R1889746]
at
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:275)
[org.apache.jackrabbit.oak-jcr:1.39.0.R1889746]
at
org.apache.jackrabbit.oak.jcr.session.SessionImpl.save(SessionImpl.java:426)
[org.apache.jackrabbit.oak-jcr:1.39.0.R1889746]
at
com.adobe.granite.repository.impl.CRX3SessionImpl.save(CRX3SessionImpl.java:207)
[com.adobe.granite.repository:1.6.128]
at
org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.commit(JcrResourceProvider.java:514)
[org.apache.sling.jcr.resource:3.0.22]
... 9 common frames omitted
Caused by: org.apache.jackrabbit.oak.api.CommitFailedException: OakState0001:
Unresolved conflicts in /var/sling/distribution/packages/signed-url/data
at
org.apache.jackrabbit.oak.plugins.commit.ConflictValidator.failOnMergeConflict(ConflictValidator.java:115)
[org.apache.jackrabbit.oak-core:1.39.0.R1889746]
at
org.apache.jackrabbit.oak.plugins.commit.ConflictValidator.propertyAdded(ConflictValidator.java:84)
[org.apache.jackrabbit.oak-core:1.39.0.R1889746]
at
org.apache.jackrabbit.oak.spi.commit.CompositeEditor.propertyAdded(CompositeEditor.java:82)
[org.apache.jackrabbit.oak-store-spi:1.39.0.R1889746]
at
org.apache.jackrabbit.oak.spi.commit.EditorDiff.propertyAdded(EditorDiff.java:81)
[org.apache.jackrabbit.oak-store-spi:1.39.0.R1889746]
at
org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAgainstBaseState(ModifiedNodeState.java:394)
[org.apache.jackrabbit.oak-store-spi:1.39.0.R1889746]
at
org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:147)
[org.apache.jackrabbit.oak-store-spi:1.39.0.
[jira] [Commented] (SLING-10136) Sling Repo Init: Add option to delete paths
[ https://issues.apache.org/jira/browse/SLING-10136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401479#comment-17401479 ] Carsten Ziegeler commented on SLING-10136: -- [~enorman] I wouldn't go that far, repoinit has its purpose - setting up initial repository structures; it's nice and easy for such a use case Sling Pipes is a tool for various things including handling changes in content structure, migrations etc. So I think that it is a much better fit for the use cases mentioned here. So we have three options: - Enhance repoinit with more and more features until it becomes a complete DSL and is a direct competitor with Sling Pipes - Create an extension of repoinit which will become the complete DSL, but keep the core small and lean - See if Sling Pipes can be used instead for complex use case and if there is anything missing; the hooks are most likely missing, but that sounds fixable. > Sling Repo Init: Add option to delete paths > --- > > Key: SLING-10136 > URL: https://issues.apache.org/jira/browse/SLING-10136 > Project: Sling > Issue Type: New Feature > Components: Repoinit >Affects Versions: Repoinit Parser 1.6.4, Repoinit JCR 1.1.30 >Reporter: Henry Kuijpers >Priority: Major > Time Spent: 2h > Remaining Estimate: 0h > > Given that we are able to create paths, it would also be beneficial to be > able to delete paths as well. > In our case, we're migrating a legacy setup to Sling Repo Init, where there > are some "leftover" nodes in the instances. Given that Sling Repo Init is an > "admin" way to initialize a repo, it would be very nice if delete statements > could be supported. > In our case, we would want to delete /apps/foundation, for example, because > historically there seem to have been modifications made there. > This mandates for a simple syntax like "delete path /apps/foundation" being > supported. > Another case is that we would like to cleanup /apps/cq, however, there are > some nodes that are maintained by the product (in our case AEM), such as > /apps/cq/xssprotection and also /apps/cq/core/content/nav/tools. > This mandates for a slightly more complicated syntax such as "delete path > /apps/cq (!/xssprotection,!/core/content/nav/tools,*)", however, I would be > fine with multiple delete path statements as well, for that usecase. -- This message was sent by Atlassian Jira (v8.3.4#803005)
