[jira] [Created] (SLING-12309) Upgrade dependencies (remove security vulnerabilities)
Andrei Dulvac created SLING-12309: - Summary: Upgrade dependencies (remove security vulnerabilities) Key: SLING-12309 URL: https://issues.apache.org/jira/browse/SLING-12309 Project: Sling Issue Type: Improvement Components: HApi Client Affects Versions: HApi Client 1.0.0 Reporter: Andrei Dulvac Assignee: Andrei Dulvac Fix For: HApi Client 1.0.2 Update all maven deps with known vulnerabilities -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12241) Anonymous sling testing client throws NPE
[ https://issues.apache.org/jira/browse/SLING-12241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-12241. --- Resolution: Fixed > Anonymous sling testing client throws NPE > - > > Key: SLING-12241 > URL: https://issues.apache.org/jira/browse/SLING-12241 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 3.0.22 >Reporter: Evgeny Tugarev >Assignee: Andrei Dulvac >Priority: Major > Fix For: Apache Sling Testing Clients 3.0.24 > > > When _null_ is passed as a user name to sling testing client, to mimic the > anonymous user, an NPE is thrown in FormBasedAuthInterceptor. > to reproduce: > {code:java} > FormBasedAuthInterceptor interceptor = new > FormBasedAuthInterceptor(LOGIN_COOKIE_NAME); > SlingClient anonymousClient = SlingClient.Builder.create(httpServer.getURI(), > null, "pass") > .addInterceptorLast(interceptor).build(); > annonnymousClient.doGet(LOGIN_OK_PATH, 200); // NPE > {code} > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12241) Anonymous sling testing client throws NPE
[ https://issues.apache.org/jira/browse/SLING-12241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac updated SLING-12241: -- Fix Version/s: Apache Sling Testing Clients 3.0.24 > Anonymous sling testing client throws NPE > - > > Key: SLING-12241 > URL: https://issues.apache.org/jira/browse/SLING-12241 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 3.0.22 >Reporter: Evgeny Tugarev >Assignee: Andrei Dulvac >Priority: Major > Fix For: Apache Sling Testing Clients 3.0.24 > > > When _null_ is passed as a user name to sling testing client, to mimic the > anonymous user, an NPE is thrown in FormBasedAuthInterceptor. > to reproduce: > {code:java} > FormBasedAuthInterceptor interceptor = new > FormBasedAuthInterceptor(LOGIN_COOKIE_NAME); > SlingClient anonymousClient = SlingClient.Builder.create(httpServer.getURI(), > null, "pass") > .addInterceptorLast(interceptor).build(); > annonnymousClient.doGet(LOGIN_OK_PATH, 200); // NPE > {code} > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12241) Anonymous sling testing client throws NPE
[ https://issues.apache.org/jira/browse/SLING-12241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac updated SLING-12241: -- Affects Version/s: Apache Sling Testing Clients 3.0.24 (was: Apache Sling Testing Clients 3.0.22) > Anonymous sling testing client throws NPE > - > > Key: SLING-12241 > URL: https://issues.apache.org/jira/browse/SLING-12241 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 3.0.24 >Reporter: Evgeny Tugarev >Assignee: Andrei Dulvac >Priority: Major > > When _null_ is passed as a user name to sling testing client, to mimic the > anonymous user, an NPE is thrown in FormBasedAuthInterceptor. > to reproduce: > {code:java} > FormBasedAuthInterceptor interceptor = new > FormBasedAuthInterceptor(LOGIN_COOKIE_NAME); > SlingClient anonymousClient = SlingClient.Builder.create(httpServer.getURI(), > null, "pass") > .addInterceptorLast(interceptor).build(); > annonnymousClient.doGet(LOGIN_OK_PATH, 200); // NPE > {code} > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12241) Anonymous sling testing client throws NPE
[ https://issues.apache.org/jira/browse/SLING-12241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac updated SLING-12241: -- Affects Version/s: Apache Sling Testing Clients 3.0.22 (was: Apache Sling Testing Clients 3.0.24) > Anonymous sling testing client throws NPE > - > > Key: SLING-12241 > URL: https://issues.apache.org/jira/browse/SLING-12241 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 3.0.22 >Reporter: Evgeny Tugarev >Assignee: Andrei Dulvac >Priority: Major > > When _null_ is passed as a user name to sling testing client, to mimic the > anonymous user, an NPE is thrown in FormBasedAuthInterceptor. > to reproduce: > {code:java} > FormBasedAuthInterceptor interceptor = new > FormBasedAuthInterceptor(LOGIN_COOKIE_NAME); > SlingClient anonymousClient = SlingClient.Builder.create(httpServer.getURI(), > null, "pass") > .addInterceptorLast(interceptor).build(); > annonnymousClient.doGet(LOGIN_OK_PATH, 200); // NPE > {code} > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (SLING-12241) Anonymous testing client throws NPE
[ https://issues.apache.org/jira/browse/SLING-12241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac reassigned SLING-12241: - Assignee: Andrei Dulvac > Anonymous testing client throws NPE > --- > > Key: SLING-12241 > URL: https://issues.apache.org/jira/browse/SLING-12241 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 3.0.22 >Reporter: Evgeny Tugarev >Assignee: Andrei Dulvac >Priority: Major > > When using the AEM testing Clients: anonymous client to access content on a > publish instance ( AEMCS) the client throws an NPE > to reproduce: > {code:java} > anonymousPublish = cqBaseClassRule.publishRule.getClient(CQClient.class, > null, null); > anonymousPublish.doGet("/graphql/execute.json", 204); > {code} > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12229) Update jackson and jsoup dependencies
[ https://issues.apache.org/jira/browse/SLING-12229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-12229. --- Resolution: Fixed > Update jackson and jsoup dependencies > - > > Key: SLING-12229 > URL: https://issues.apache.org/jira/browse/SLING-12229 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 3.0.20 >Reporter: Andrei Dulvac >Assignee: Andrei Dulvac >Priority: Major > Fix For: Apache Sling Testing Clients 3.0.22 > > > jackson-core - 2.13.0, jackson-databind-2.13.2.1, jsoup-1.14.3 need to be > updated because they cause: > CVE-2022-42003 > CVE-2022-42004 > CVE-2022-36033 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (SLING-10868) Search pattern in getSlingLocation method only works if id is the last attribute
[ https://issues.apache.org/jira/browse/SLING-10868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac reassigned SLING-10868: - Assignee: Andrei Dulvac > Search pattern in getSlingLocation method only works if id is the last > attribute > > > Key: SLING-10868 > URL: https://issues.apache.org/jira/browse/SLING-10868 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Clients >Reporter: Michael Kitanovski >Assignee: Andrei Dulvac >Priority: Major > Labels: sling-IT > Attachments: response_content.txt > > > The method getSlingLocation in class SlingHttpResponse uses a search pattern > which only works if the "id" attribute is the last one. We have implemented a > link rewriter transformer in our project which adds a class="internal" to > each internal link. In our case now the class attribute is the last one and > the method extractFromHTMLResponse(String searchPattern) will return null > because it won't find the the searched string in the content (see attached > response_content.txt). > > [https://github.com/apache/sling-org-apache-sling-testing-clients/blob/c8a6d4bd9c3e92a2c00920d86f3d27d58478050e/src/main/java/org/apache/sling/testing/clients/SlingHttpResponse.java#L201] > > The same issue exists for other methods like > - getSlingParentLocation() > - getSlingReferer() > > It seems AEMaaCs uses the aem-test-samples > ([https://github.com/adobe/aem-test-samples)] for integration tests during > the production pipeline run. One of the tests is using the getSlingLocation > method which causes termination of the deployment process. > > [https://github.com/adobe/aem-test-samples/blob/4f7653db344c3f31f4a1a6440bf0f01db75ea382/smoke/src/main/java/com/adobe/cq/cloud/testing/it/smoke/CreatePageAsAuthorUserIT.java#L78] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-6072) The testing rules do not call CloseableHttpClient.close()
[ https://issues.apache.org/jira/browse/SLING-6072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-6072. -- Resolution: Fixed > The testing rules do not call CloseableHttpClient.close() > - > > Key: SLING-6072 > URL: https://issues.apache.org/jira/browse/SLING-6072 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 1.0.0, Apache Sling Testing > Rules 1.0.0 >Reporter: Konrad Windszus >Assignee: Andrei Dulvac >Priority: Major > Fix For: Apache Sling Testing Rules 1.0.1, Apache Sling Testing > Clients 1.0.1 > > > The rules being provided by the sling testing rules do not automatically call > close on the underlying {{ClosableHttpClient}} which is necessary to close > the dangling http connections being managed by the underlying connection > manager (see > https://hc.apache.org/httpcomponents-client-ga/tutorial/html/fundamentals.html#d5e217). > Even custom code cannot call close, because the underlying > {{ClosableHttpClient}} is not really exposed. > I guess there is also a change necessary in testing/http/client to expose > such a close method as well, and also clarify under which circumstances a new > HttpClient is created or when an existing one is reused. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-6072) The testing rules do not call CloseableHttpClient.close()
[ https://issues.apache.org/jira/browse/SLING-6072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac updated SLING-6072: - Fix Version/s: Apache Sling Testing Rules 1.0.1 Apache Sling Testing Clients 1.0.1 > The testing rules do not call CloseableHttpClient.close() > - > > Key: SLING-6072 > URL: https://issues.apache.org/jira/browse/SLING-6072 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 1.0.0, Apache Sling Testing > Rules 1.0.0 >Reporter: Konrad Windszus >Assignee: Andrei Dulvac >Priority: Major > Fix For: Apache Sling Testing Clients 1.0.1, Apache Sling Testing > Rules 1.0.1 > > > The rules being provided by the sling testing rules do not automatically call > close on the underlying {{ClosableHttpClient}} which is necessary to close > the dangling http connections being managed by the underlying connection > manager (see > https://hc.apache.org/httpcomponents-client-ga/tutorial/html/fundamentals.html#d5e217). > Even custom code cannot call close, because the underlying > {{ClosableHttpClient}} is not really exposed. > I guess there is also a change necessary in testing/http/client to expose > such a close method as well, and also clarify under which circumstances a new > HttpClient is created or when an existing one is reused. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-7035) [http.testing.clients] OsgiConsoleClient#editConfigurationWithWait does not wait for bundle to be restarted
[ https://issues.apache.org/jira/browse/SLING-7035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-7035. -- Resolution: Cannot Reproduce > [http.testing.clients] OsgiConsoleClient#editConfigurationWithWait does not > wait for bundle to be restarted > --- > > Key: SLING-7035 > URL: https://issues.apache.org/jira/browse/SLING-7035 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 1.1.4 >Reporter: Andrei Dulvac >Assignee: Andrei Dulvac >Priority: Major > > https://github.com/apache/sling/blob/trunk/testing/http/clients/src/main/java/org/apache/sling/testing/clients/osgi/OsgiConsoleClient.java#L342 > doesn't wait for the affected bundle to be restarted. > We need a mechanism to wait for the bundle that's restarted after the config > change. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-8114) Allow to do polling of code failing on asserts
[ https://issues.apache.org/jira/browse/SLING-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-8114. -- Resolution: Won't Do > Allow to do polling of code failing on asserts > -- > > Key: SLING-8114 > URL: https://issues.apache.org/jira/browse/SLING-8114 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 1.2.0 >Reporter: Thierry Ygé >Priority: Major > > Currently if you polling check uses assertions , it will not be retried, this > is due to this line > [https://github.com/apache/sling-org-apache-sling-testing-clients/blob/master/src/main/java/org/apache/sling/testing/clients/util/poller/Polling.java#L118] > Which is only catching Exceptions while failing Assertions are an error kind > (AssertionError). > It would be nice to handle it so that code wouldn't have to "transform" it to > exception. > To reproduce simply use assertion in your polling check and let it fail if a > counter is lower than a value. make the polling retries so that at the next > retry counter it should pass. > > {quote}int count = 0; > new Polling(() -> { count++; Assert.assertTrue(count == 2); return true; > } > ).poll(2000, 500); > {quote} > Observation: it exist the poll directly as the assert fail already. > Expected: It should have polled until the check pass here. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-9188) Sling Testing Clients does not work on GET with parameters
[ https://issues.apache.org/jira/browse/SLING-9188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-9188. -- Resolution: Cannot Reproduce > Sling Testing Clients does not work on GET with parameters > -- > > Key: SLING-9188 > URL: https://issues.apache.org/jira/browse/SLING-9188 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 2.0.0 > Environment: Sling 12 >Reporter: Andreas Schaefer >Priority: Major > > There is an issue with Sling Client's doGet() as parameters (?a=b) will cause > an error. The question mark is encoded %3F which makes the call fail. > > I created a test project: [https://github.com/schaefa/sling-testing-client-it] > > Run it with: mvn clean install -P it -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-11611) Provide method to retrieve Pid for OSGI Configurations in Sling Testing Clients
[ https://issues.apache.org/jira/browse/SLING-11611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-11611. --- Fix Version/s: Apache Sling Testing Clients 3.0.22 Resolution: Fixed > Provide method to retrieve Pid for OSGI Configurations in Sling Testing > Clients > --- > > Key: SLING-11611 > URL: https://issues.apache.org/jira/browse/SLING-11611 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 3.0.16 >Reporter: Nicola Scendoni >Assignee: Andrei Dulvac >Priority: Minor > Fix For: Apache Sling Testing Clients 3.0.22 > > > During development of IT Tests it may be needed to search the pid for some > OSGI Configuration not created by the test itself. > I will provide an implementation to search the pid of configurations from > serviceType and the value of a property. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-11125) SlingClient.exists(...) should use expected status in order to support http retries parameters
[ https://issues.apache.org/jira/browse/SLING-11125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-11125. --- Resolution: Not A Bug > SlingClient.exists(...) should use expected status in order to support http > retries parameters > -- > > Key: SLING-11125 > URL: https://issues.apache.org/jira/browse/SLING-11125 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 3.0.10 >Reporter: Thierry Ygé >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > Currently if tests need to retries on some errors which are likely to happen > in clustered setup (AEM in Cloud for example). > usually the use of > "-Dsling.it.http.retriesErrorCodes=401,404,405,429,500,501,503" would include > 404 cases. > The issue is then SlingClient.exists(...) would always fail in case we try to > check for "not existing path" as the test would expect also 404 to be > returned. > The current implementation of ServerErrorRetryStrategy support that if the > expected values are passed , this would bypass the retriesErrorCodes. > Thus it would make sense to pass the possible returned code for the request > done by SlingClient.exists(...) call. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12229) Update jackson-core dependencies
Andrei Dulvac created SLING-12229: - Summary: Update jackson-core dependencies Key: SLING-12229 URL: https://issues.apache.org/jira/browse/SLING-12229 Project: Sling Issue Type: Bug Components: Apache Sling Testing Clients Affects Versions: Apache Sling Testing Clients 3.0.20 Reporter: Andrei Dulvac Assignee: Andrei Dulvac Fix For: Apache Sling Testing Clients 3.0.22 jackson-core - 2.13.0, jackson-databind-2.13.2.1, jsoup-1.14.3 need to be updated because they cause: CVE-2022-42003 CVE-2022-42004 CVE-2022-36033 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12229) Update jackson and jsoup dependencies
[ https://issues.apache.org/jira/browse/SLING-12229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac updated SLING-12229: -- Summary: Update jackson and jsoup dependencies (was: Update jackson-core dependencies) > Update jackson and jsoup dependencies > - > > Key: SLING-12229 > URL: https://issues.apache.org/jira/browse/SLING-12229 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 3.0.20 >Reporter: Andrei Dulvac >Assignee: Andrei Dulvac >Priority: Major > Fix For: Apache Sling Testing Clients 3.0.22 > > > jackson-core - 2.13.0, jackson-databind-2.13.2.1, jsoup-1.14.3 need to be > updated because they cause: > CVE-2022-42003 > CVE-2022-42004 > CVE-2022-36033 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12096) Testing clients - don't log request headers
[ https://issues.apache.org/jira/browse/SLING-12096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-12096. --- Fix Version/s: Apache Sling Testing Clients 3.0.22 Resolution: Fixed > Testing clients - don't log request headers > --- > > Key: SLING-12096 > URL: https://issues.apache.org/jira/browse/SLING-12096 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 3.0.16 >Reporter: Marc Pfaff >Assignee: Andrei Dulvac >Priority: Minor > Fix For: Apache Sling Testing Clients 3.0.22 > > > The ServerErrorRetryStrategy used in the testing clients logs when a retry > condition is met. > I propose to improve this output with more request/response details and retry > condition details, in order to help troubleshooting test failures. > Current output (example from the unit test): > {code:java} > Request retry needed due to service unavailable response > Response headers contained: > Header Date:Wed, 11 Jan 2023 08:36:43 GMT > Header Server:TEST/1.1 > Header Content-Length:8 > Header Content-Type:text/plain; charset=ISO-8859-1 > Header Connection:Keep-Alive > Response content: TEST_NOK > {code} > Proposed improvement (example from the unit test): > {code:java} > Request retry condition met: [count=1/4], [expected-codes=[200]], > [retry-codes=[500, 503]] > Request: GET /test/internalerror/resource HTTP/1.1 [Host: 127.0.0.1:32953, > Connection: Keep-Alive, User-Agent: Java, Accept-Encoding: gzip,deflate, > Authorization: Basic dXNlcjpwYXNz] > Response: HTTP/1.1 500 Internal Server Error [Date: Wed, 11 Jan 2023 08:39:59 > GMT, Server: TEST/1.1, Content-Length: 8, Content-Type: text/plain; > charset=ISO-8859-1, Connection: Keep-Alive, ] > {code} > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-11279) Make SlingClient.exists() more resilient with http retries codes
[ https://issues.apache.org/jira/browse/SLING-11279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-11279. --- Fix Version/s: Apache Sling Testing Clients 3.0.22 Resolution: Fixed > Make SlingClient.exists() more resilient with http retries codes > - > > Key: SLING-11279 > URL: https://issues.apache.org/jira/browse/SLING-11279 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 3.0.12 >Reporter: Thierry Ygé >Assignee: Andrei Dulvac >Priority: Major > Fix For: Apache Sling Testing Clients 3.0.22 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently if we are in cluster with affinity cookie and use httpRetries code > to retries on 404 to avoid sync problems, the exists() method can be confused > for 404 responses. > In order to fix it, it need to explicitely list generally expected code that > might not need retries in that context. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-11609) Provide doGetWithRetry methods in Sling Testing Clients
[ https://issues.apache.org/jira/browse/SLING-11609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-11609. --- Fix Version/s: Apache Sling Testing Clients 3.0.22 Assignee: Andrei Dulvac (was: Nicola Scendoni) Resolution: Fixed > Provide doGetWithRetry methods in Sling Testing Clients > --- > > Key: SLING-11609 > URL: https://issues.apache.org/jira/browse/SLING-11609 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 3.0.16 >Reporter: Nicola Scendoni >Assignee: Andrei Dulvac >Priority: Minor > Fix For: Apache Sling Testing Clients 3.0.22 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > In several situations during IT Tests development we need to retry doGet > method until some assertion are verified. > I propose in the attached pull request an implementation and test for new > methods doGetWithRetry -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (SLING-11279) Make SlingClient.exists() more resilient with http retries codes
[ https://issues.apache.org/jira/browse/SLING-11279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac reassigned SLING-11279: - Assignee: Andrei Dulvac > Make SlingClient.exists() more resilient with http retries codes > - > > Key: SLING-11279 > URL: https://issues.apache.org/jira/browse/SLING-11279 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 3.0.12 >Reporter: Thierry Ygé >Assignee: Andrei Dulvac >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently if we are in cluster with affinity cookie and use httpRetries code > to retries on 404 to avoid sync problems, the exists() method can be confused > for 404 responses. > In order to fix it, it need to explicitely list generally expected code that > might not need retries in that context. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (SLING-11611) Provide method to retrieve Pid for OSGI Configurations in Sling Testing Clients
[ https://issues.apache.org/jira/browse/SLING-11611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac reassigned SLING-11611: - Assignee: Andrei Dulvac (was: Nicola Scendoni) > Provide method to retrieve Pid for OSGI Configurations in Sling Testing > Clients > --- > > Key: SLING-11611 > URL: https://issues.apache.org/jira/browse/SLING-11611 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 3.0.16 >Reporter: Nicola Scendoni >Assignee: Andrei Dulvac >Priority: Minor > > During development of IT Tests it may be needed to search the pid for some > OSGI Configuration not created by the test itself. > I will provide an implementation to search the pid of configurations from > serviceType and the value of a property. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12096) Testing clients - don't log request headers
[ https://issues.apache.org/jira/browse/SLING-12096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac updated SLING-12096: -- Fix Version/s: (was: Apache Sling Testing Clients 3.0.20) > Testing clients - don't log request headers > --- > > Key: SLING-12096 > URL: https://issues.apache.org/jira/browse/SLING-12096 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 3.0.16 >Reporter: Marc Pfaff >Assignee: Andrei Dulvac >Priority: Minor > > The ServerErrorRetryStrategy used in the testing clients logs when a retry > condition is met. > I propose to improve this output with more request/response details and retry > condition details, in order to help troubleshooting test failures. > Current output (example from the unit test): > {code:java} > Request retry needed due to service unavailable response > Response headers contained: > Header Date:Wed, 11 Jan 2023 08:36:43 GMT > Header Server:TEST/1.1 > Header Content-Length:8 > Header Content-Type:text/plain; charset=ISO-8859-1 > Header Connection:Keep-Alive > Response content: TEST_NOK > {code} > Proposed improvement (example from the unit test): > {code:java} > Request retry condition met: [count=1/4], [expected-codes=[200]], > [retry-codes=[500, 503]] > Request: GET /test/internalerror/resource HTTP/1.1 [Host: 127.0.0.1:32953, > Connection: Keep-Alive, User-Agent: Java, Accept-Encoding: gzip,deflate, > Authorization: Basic dXNlcjpwYXNz] > Response: HTTP/1.1 500 Internal Server Error [Date: Wed, 11 Jan 2023 08:39:59 > GMT, Server: TEST/1.1, Content-Length: 8, Content-Type: text/plain; > charset=ISO-8859-1, Connection: Keep-Alive, ] > {code} > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12096) Testing clients - don't log request headers
[ https://issues.apache.org/jira/browse/SLING-12096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac updated SLING-12096: -- Affects Version/s: Apache Sling Testing Clients 3.0.16 (was: Apache Sling Testing Clients 3.0.20) > Testing clients - don't log request headers > --- > > Key: SLING-12096 > URL: https://issues.apache.org/jira/browse/SLING-12096 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 3.0.16 >Reporter: Marc Pfaff >Assignee: Andrei Dulvac >Priority: Minor > Fix For: Apache Sling Testing Clients 3.0.20 > > > The ServerErrorRetryStrategy used in the testing clients logs when a retry > condition is met. > I propose to improve this output with more request/response details and retry > condition details, in order to help troubleshooting test failures. > Current output (example from the unit test): > {code:java} > Request retry needed due to service unavailable response > Response headers contained: > Header Date:Wed, 11 Jan 2023 08:36:43 GMT > Header Server:TEST/1.1 > Header Content-Length:8 > Header Content-Type:text/plain; charset=ISO-8859-1 > Header Connection:Keep-Alive > Response content: TEST_NOK > {code} > Proposed improvement (example from the unit test): > {code:java} > Request retry condition met: [count=1/4], [expected-codes=[200]], > [retry-codes=[500, 503]] > Request: GET /test/internalerror/resource HTTP/1.1 [Host: 127.0.0.1:32953, > Connection: Keep-Alive, User-Agent: Java, Accept-Encoding: gzip,deflate, > Authorization: Basic dXNlcjpwYXNz] > Response: HTTP/1.1 500 Internal Server Error [Date: Wed, 11 Jan 2023 08:39:59 > GMT, Server: TEST/1.1, Content-Length: 8, Content-Type: text/plain; > charset=ISO-8859-1, Connection: Keep-Alive, ] > {code} > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12096) Testing clients - don't log request headers
[ https://issues.apache.org/jira/browse/SLING-12096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac updated SLING-12096: -- Affects Version/s: Apache Sling Testing Clients 3.0.20 (was: Apache Sling Testing Clients 3.0.16) > Testing clients - don't log request headers > --- > > Key: SLING-12096 > URL: https://issues.apache.org/jira/browse/SLING-12096 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 3.0.20 >Reporter: Marc Pfaff >Assignee: Andrei Dulvac >Priority: Minor > Fix For: Apache Sling Testing Clients 3.0.20 > > > The ServerErrorRetryStrategy used in the testing clients logs when a retry > condition is met. > I propose to improve this output with more request/response details and retry > condition details, in order to help troubleshooting test failures. > Current output (example from the unit test): > {code:java} > Request retry needed due to service unavailable response > Response headers contained: > Header Date:Wed, 11 Jan 2023 08:36:43 GMT > Header Server:TEST/1.1 > Header Content-Length:8 > Header Content-Type:text/plain; charset=ISO-8859-1 > Header Connection:Keep-Alive > Response content: TEST_NOK > {code} > Proposed improvement (example from the unit test): > {code:java} > Request retry condition met: [count=1/4], [expected-codes=[200]], > [retry-codes=[500, 503]] > Request: GET /test/internalerror/resource HTTP/1.1 [Host: 127.0.0.1:32953, > Connection: Keep-Alive, User-Agent: Java, Accept-Encoding: gzip,deflate, > Authorization: Basic dXNlcjpwYXNz] > Response: HTTP/1.1 500 Internal Server Error [Date: Wed, 11 Jan 2023 08:39:59 > GMT, Server: TEST/1.1, Content-Length: 8, Content-Type: text/plain; > charset=ISO-8859-1, Connection: Keep-Alive, ] > {code} > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12096) Testing clients - don't log request headers
Andrei Dulvac created SLING-12096: - Summary: Testing clients - don't log request headers Key: SLING-12096 URL: https://issues.apache.org/jira/browse/SLING-12096 Project: Sling Issue Type: Improvement Components: Apache Sling Testing Clients Affects Versions: Apache Sling Testing Clients 3.0.16 Reporter: Marc Pfaff Assignee: Andrei Dulvac Fix For: Apache Sling Testing Clients 3.0.20 The ServerErrorRetryStrategy used in the testing clients logs when a retry condition is met. I propose to improve this output with more request/response details and retry condition details, in order to help troubleshooting test failures. Current output (example from the unit test): {code:java} Request retry needed due to service unavailable response Response headers contained: Header Date:Wed, 11 Jan 2023 08:36:43 GMT Header Server:TEST/1.1 Header Content-Length:8 Header Content-Type:text/plain; charset=ISO-8859-1 Header Connection:Keep-Alive Response content: TEST_NOK {code} Proposed improvement (example from the unit test): {code:java} Request retry condition met: [count=1/4], [expected-codes=[200]], [retry-codes=[500, 503]] Request: GET /test/internalerror/resource HTTP/1.1 [Host: 127.0.0.1:32953, Connection: Keep-Alive, User-Agent: Java, Accept-Encoding: gzip,deflate, Authorization: Basic dXNlcjpwYXNz] Response: HTTP/1.1 500 Internal Server Error [Date: Wed, 11 Jan 2023 08:39:59 GMT, Server: TEST/1.1, Content-Length: 8, Content-Type: text/plain; charset=ISO-8859-1, Connection: Keep-Alive, ] {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-11748) Improve logging output of HTTP retries in testing clients
[ https://issues.apache.org/jira/browse/SLING-11748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-11748. --- Fix Version/s: Apache Sling Testing Clients 3.0.20 Assignee: Andrei Dulvac Resolution: Fixed > Improve logging output of HTTP retries in testing clients > - > > Key: SLING-11748 > URL: https://issues.apache.org/jira/browse/SLING-11748 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 3.0.16 >Reporter: Marc Pfaff >Assignee: Andrei Dulvac >Priority: Minor > Fix For: Apache Sling Testing Clients 3.0.20 > > Time Spent: 2.5h > Remaining Estimate: 0h > > The ServerErrorRetryStrategy used in the testing clients logs when a retry > condition is met. > I propose to improve this output with more request/response details and retry > condition details, in order to help troubleshooting test failures. > Current output (example from the unit test): > {code:java} > Request retry needed due to service unavailable response > Response headers contained: > Header Date:Wed, 11 Jan 2023 08:36:43 GMT > Header Server:TEST/1.1 > Header Content-Length:8 > Header Content-Type:text/plain; charset=ISO-8859-1 > Header Connection:Keep-Alive > Response content: TEST_NOK > {code} > Proposed improvement (example from the unit test): > {code:java} > Request retry condition met: [count=1/4], [expected-codes=[200]], > [retry-codes=[500, 503]] > Request: GET /test/internalerror/resource HTTP/1.1 [Host: 127.0.0.1:32953, > Connection: Keep-Alive, User-Agent: Java, Accept-Encoding: gzip,deflate, > Authorization: Basic dXNlcjpwYXNz] > Response: HTTP/1.1 500 Internal Server Error [Date: Wed, 11 Jan 2023 08:39:59 > GMT, Server: TEST/1.1, Content-Length: 8, Content-Type: text/plain; > charset=ISO-8859-1, Connection: Keep-Alive, ] > {code} > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12086) apache sling testing clients: HttpClientBuilder does not honor useSystemProperties
[ https://issues.apache.org/jira/browse/SLING-12086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-12086. --- Resolution: Fixed > apache sling testing clients: HttpClientBuilder does not honor > useSystemProperties > -- > > Key: SLING-12086 > URL: https://issues.apache.org/jira/browse/SLING-12086 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 3.0.18 >Reporter: Andres Bott >Assignee: Andrei Dulvac >Priority: Minor > Fix For: Apache Sling Testing Clients 3.0.20 > > > When trying to use system properties to configure a proxy, the Apache sling > testing clients httpclient do not always honor the system properties read > proxy configuration. > e.g. > https://github.com/apache/sling-org-apache-sling-testing-clients/blob/master/src/main/java/org/apache/sling/testing/clients/interceptors/FormBasedAuthInterceptor.java#L135 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (SLING-12086) apache sling testing clients: HttpClientBuilder does not honor useSystemProperties
[ https://issues.apache.org/jira/browse/SLING-12086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac reassigned SLING-12086: - Assignee: Andrei Dulvac > apache sling testing clients: HttpClientBuilder does not honor > useSystemProperties > -- > > Key: SLING-12086 > URL: https://issues.apache.org/jira/browse/SLING-12086 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 3.0.18 >Reporter: Andres Bott >Assignee: Andrei Dulvac >Priority: Minor > Fix For: Apache Sling Testing Clients 3.0.20 > > > When trying to use system properties to configure a proxy, the Apache sling > testing clients httpclient do not always honor the system properties read > proxy configuration. > e.g. > https://github.com/apache/sling-org-apache-sling-testing-clients/blob/master/src/main/java/org/apache/sling/testing/clients/interceptors/FormBasedAuthInterceptor.java#L135 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12086) apache sling testing clients: HttpClientBuilder does not honor useSystemProperties
[ https://issues.apache.org/jira/browse/SLING-12086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac updated SLING-12086: -- Fix Version/s: Apache Sling Testing Clients 3.0.20 > apache sling testing clients: HttpClientBuilder does not honor > useSystemProperties > -- > > Key: SLING-12086 > URL: https://issues.apache.org/jira/browse/SLING-12086 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 3.0.18 >Reporter: Andres Bott >Priority: Minor > Fix For: Apache Sling Testing Clients 3.0.20 > > > When trying to use system properties to configure a proxy, the Apache sling > testing clients httpclient do not always honor the system properties read > proxy configuration. > e.g. > https://github.com/apache/sling-org-apache-sling-testing-clients/blob/master/src/main/java/org/apache/sling/testing/clients/interceptors/FormBasedAuthInterceptor.java#L135 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-11679) Set more descriptive User-Agent for SlingClients
[ https://issues.apache.org/jira/browse/SLING-11679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-11679. --- Resolution: Fixed > Set more descriptive User-Agent for SlingClients > > > Key: SLING-11679 > URL: https://issues.apache.org/jira/browse/SLING-11679 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 3.0.16 >Reporter: Andrei Dulvac >Assignee: Andrei Dulvac >Priority: Major > Fix For: Apache Sling Testing Clients 3.0.18 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Customize and change the User-Agent header used by the http clients. The > default User-Agent may be changed or it may be replaced or appended per test. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-11679) Set more descriptive User-Agent for SlingClients
Andrei Dulvac created SLING-11679: - Summary: Set more descriptive User-Agent for SlingClients Key: SLING-11679 URL: https://issues.apache.org/jira/browse/SLING-11679 Project: Sling Issue Type: Improvement Components: Apache Sling Testing Clients Affects Versions: Apache Sling Testing Clients 3.0.16 Reporter: Andrei Dulvac Assignee: Andrei Dulvac Fix For: Apache Sling Testing Clients 3.0.18 Customize and change the User-Agent header used by the http clients. The default User-Agent may be changed or it may be replaced or appended per test. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-11131) Update Apache HTTP Client Dependency for CVE-2020-13956
[ https://issues.apache.org/jira/browse/SLING-11131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-11131. --- Resolution: Fixed Fixed by https://github.com/apache/sling-org-apache-sling-testing-clients/commit/3e677d306d0ee7e807bcb3dc4c4b8634681f28ac > Update Apache HTTP Client Dependency for CVE-2020-13956 > --- > > Key: SLING-11131 > URL: https://issues.apache.org/jira/browse/SLING-11131 > Project: Sling > Issue Type: Task > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 3.0.10 >Reporter: Andrei Tuicu >Assignee: Andrei Dulvac >Priority: Major > Fix For: Apache Sling Testing Clients 3.0.12 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > org.apache.httpcomponents.httpclient 4.4.1 is vulnerable to > CVE-2020-13956(MEDIUM)[0]. > We need to update to the latest version of the Apache HTP Client 4.5.13. > [0] https://www.cvedetails.com/cve/CVE-2020-13956/ -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SLING-11131) Update Apache HTTP Client Dependency for CVE-2020-13956
[ https://issues.apache.org/jira/browse/SLING-11131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac updated SLING-11131: -- Fix Version/s: Apache Sling Testing Clients 3.0.12 > Update Apache HTTP Client Dependency for CVE-2020-13956 > --- > > Key: SLING-11131 > URL: https://issues.apache.org/jira/browse/SLING-11131 > Project: Sling > Issue Type: Task > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 3.0.10 >Reporter: Andrei Tuicu >Assignee: Andrei Dulvac >Priority: Major > Fix For: Apache Sling Testing Clients 3.0.12 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > org.apache.httpcomponents.httpclient 4.4.1 is vulnerable to > CVE-2020-13956(MEDIUM)[0]. > We need to update to the latest version of the Apache HTP Client 4.5.13. > [0] https://www.cvedetails.com/cve/CVE-2020-13956/ -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (SLING-11131) Update Apache HTTP Client Dependency for CVE-2020-13956
[ https://issues.apache.org/jira/browse/SLING-11131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac reassigned SLING-11131: - Assignee: Andrei Dulvac > Update Apache HTTP Client Dependency for CVE-2020-13956 > --- > > Key: SLING-11131 > URL: https://issues.apache.org/jira/browse/SLING-11131 > Project: Sling > Issue Type: Task > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 3.0.10 >Reporter: Andrei Tuicu >Assignee: Andrei Dulvac >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > org.apache.httpcomponents.httpclient 4.4.1 is vulnerable to > CVE-2020-13956(MEDIUM)[0]. > We need to update to the latest version of the Apache HTP Client 4.5.13. > [0] https://www.cvedetails.com/cve/CVE-2020-13956/ -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (SLING-11124) Update Guava Dependency for CVE CVE-2018-10237 and CVE-2020-8908
[ https://issues.apache.org/jira/browse/SLING-11124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17488087#comment-17488087 ] Andrei Dulvac commented on SLING-11124: --- bq. I prefer to rather remove that guava dependency alltogether That actually makes sense in this particular case, I agree > Update Guava Dependency for CVE CVE-2018-10237 and CVE-2020-8908 > > > Key: SLING-11124 > URL: https://issues.apache.org/jira/browse/SLING-11124 > Project: Sling > Issue Type: Task > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 3.0.8 >Reporter: Andrei Tuicu >Assignee: Andrei Dulvac >Priority: Major > Fix For: Apache Sling Testing Clients 3.0.8 > > Time Spent: 40m > Remaining Estimate: 0h > > Sling testing clients are using com.google.guava guava 14.0.1 which is > vulnerable to CVE-2018-10237(MEDIUM) [1] and CVE-2020-8908(LOW) [2]. > Mitigation: update to latest guava 31.0.1-android > [1] https://www.cvedetails.com/cve/CVE-2018-10237/ > [2] https://www.cvedetails.com/cve/CVE-2020-8908/ -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (SLING-11124) Update Guava Dependency for CVE CVE-2018-10237 and CVE-2020-8908
[ https://issues.apache.org/jira/browse/SLING-11124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17487995#comment-17487995 ] Andrei Dulvac commented on SLING-11124: --- [~enorman], Thanks for pointing that out. I haven't tested it either with oak, but the reality is this is almost exclusively (I don't know of a use-case where it isn't) used as a client-side library in automated tests, even though we package it as an osgi bundle. Also, I think that shouldn't matter anyway, as dependencies in the testing clients bundle are embedded. > Update Guava Dependency for CVE CVE-2018-10237 and CVE-2020-8908 > > > Key: SLING-11124 > URL: https://issues.apache.org/jira/browse/SLING-11124 > Project: Sling > Issue Type: Task > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 3.0.8 >Reporter: Andrei Tuicu >Assignee: Andrei Dulvac >Priority: Major > Fix For: Apache Sling Testing Clients 3.0.8 > > Time Spent: 40m > Remaining Estimate: 0h > > Sling testing clients are using com.google.guava guava 14.0.1 which is > vulnerable to CVE-2018-10237(MEDIUM) [1] and CVE-2020-8908(LOW) [2]. > Mitigation: update to latest guava 31.0.1-android > [1] https://www.cvedetails.com/cve/CVE-2018-10237/ > [2] https://www.cvedetails.com/cve/CVE-2020-8908/ -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SLING-11124) Update Guava Dependency for CVE CVE-2018-10237 and CVE-2020-8908
[ https://issues.apache.org/jira/browse/SLING-11124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac updated SLING-11124: -- Affects Version/s: Apache Sling Testing Clients 3.0.8 (was: Apache Sling Testing Clients 3.0.6) > Update Guava Dependency for CVE CVE-2018-10237 and CVE-2020-8908 > > > Key: SLING-11124 > URL: https://issues.apache.org/jira/browse/SLING-11124 > Project: Sling > Issue Type: Task > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 3.0.8 >Reporter: Andrei Tuicu >Assignee: Andrei Dulvac >Priority: Major > Fix For: Apache Sling Testing Clients 3.0.6 > > Time Spent: 40m > Remaining Estimate: 0h > > Sling testing clients are using com.google.guava guava 14.0.1 which is > vulnerable to CVE-2018-10237(MEDIUM) [1] and CVE-2020-8908(LOW) [2]. > Mitigation: update to latest guava 31.0.1-android > [1] https://www.cvedetails.com/cve/CVE-2018-10237/ > [2] https://www.cvedetails.com/cve/CVE-2020-8908/ -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SLING-11124) Update Guava Dependency for CVE CVE-2018-10237 and CVE-2020-8908
[ https://issues.apache.org/jira/browse/SLING-11124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac updated SLING-11124: -- Fix Version/s: Apache Sling Testing Clients 3.0.8 (was: Apache Sling Testing Clients 3.0.6) > Update Guava Dependency for CVE CVE-2018-10237 and CVE-2020-8908 > > > Key: SLING-11124 > URL: https://issues.apache.org/jira/browse/SLING-11124 > Project: Sling > Issue Type: Task > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 3.0.8 >Reporter: Andrei Tuicu >Assignee: Andrei Dulvac >Priority: Major > Fix For: Apache Sling Testing Clients 3.0.8 > > Time Spent: 40m > Remaining Estimate: 0h > > Sling testing clients are using com.google.guava guava 14.0.1 which is > vulnerable to CVE-2018-10237(MEDIUM) [1] and CVE-2020-8908(LOW) [2]. > Mitigation: update to latest guava 31.0.1-android > [1] https://www.cvedetails.com/cve/CVE-2018-10237/ > [2] https://www.cvedetails.com/cve/CVE-2020-8908/ -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (SLING-11124) Update Guava Dependency for CVE CVE-2018-10237 and CVE-2020-8908
[ https://issues.apache.org/jira/browse/SLING-11124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-11124. --- Fix Version/s: Apache Sling Testing Clients 3.0.6 Resolution: Fixed > Update Guava Dependency for CVE CVE-2018-10237 and CVE-2020-8908 > > > Key: SLING-11124 > URL: https://issues.apache.org/jira/browse/SLING-11124 > Project: Sling > Issue Type: Task > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 3.0.6 >Reporter: Andrei Tuicu >Assignee: Andrei Dulvac >Priority: Major > Fix For: Apache Sling Testing Clients 3.0.6 > > Time Spent: 40m > Remaining Estimate: 0h > > Sling testing clients are using com.google.guava guava 14.0.1 which is > vulnerable to CVE-2018-10237(MEDIUM) [1] and CVE-2020-8908(LOW) [2]. > Mitigation: update to latest guava 31.0.1-android > [1] https://www.cvedetails.com/cve/CVE-2018-10237/ > [2] https://www.cvedetails.com/cve/CVE-2020-8908/ -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (SLING-11124) Update Guava Dependency for CVE CVE-2018-10237 and CVE-2020-8908
[ https://issues.apache.org/jira/browse/SLING-11124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17487166#comment-17487166 ] Andrei Dulvac commented on SLING-11124: --- Merged in https://github.com/apache/sling-org-apache-sling-testing-clients/pull/25 > Update Guava Dependency for CVE CVE-2018-10237 and CVE-2020-8908 > > > Key: SLING-11124 > URL: https://issues.apache.org/jira/browse/SLING-11124 > Project: Sling > Issue Type: Task > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 3.0.6 >Reporter: Andrei Tuicu >Assignee: Andrei Dulvac >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Sling testing clients are using com.google.guava guava 14.0.1 which is > vulnerable to CVE-2018-10237(MEDIUM) [1] and CVE-2020-8908(LOW) [2]. > Mitigation: update to latest guava 31.0.1-android > [1] https://www.cvedetails.com/cve/CVE-2018-10237/ > [2] https://www.cvedetails.com/cve/CVE-2020-8908/ -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (SLING-11124) Update Guava Dependency for CVE CVE-2018-10237 and CVE-2020-8908
[ https://issues.apache.org/jira/browse/SLING-11124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac reassigned SLING-11124: - Assignee: Andrei Dulvac > Update Guava Dependency for CVE CVE-2018-10237 and CVE-2020-8908 > > > Key: SLING-11124 > URL: https://issues.apache.org/jira/browse/SLING-11124 > Project: Sling > Issue Type: Task > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 3.0.6 >Reporter: Andrei Tuicu >Assignee: Andrei Dulvac >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Sling testing clients are using com.google.guava guava 14.0.1 which is > vulnerable to CVE-2018-10237(MEDIUM) [1] and CVE-2020-8908(LOW) [2]. > Mitigation: update to latest guava 31.0.1-android > [1] https://www.cvedetails.com/cve/CVE-2018-10237/ > [2] https://www.cvedetails.com/cve/CVE-2020-8908/ -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (SLING-10974) testing clients - replace org.codehaus.jackson with com.fasterxml.jackson.core
[ https://issues.apache.org/jira/browse/SLING-10974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17456265#comment-17456265 ] Andrei Dulvac commented on SLING-10974: --- [~kwin], hence the major version bump. These jackson packages have a long history of security vulnerabilities. Plus, we've been putting this change out long enough. See https://github.com/apache/sling-org-apache-sling-testing-clients/commit/2988bbe2456c2cfd6beb62cdb94faa984ac4b8c8#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R186-R192 > testing clients - replace org.codehaus.jackson with com.fasterxml.jackson.core > -- > > Key: SLING-10974 > URL: https://issues.apache.org/jira/browse/SLING-10974 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 2.0.12 >Reporter: Andrei Dulvac >Assignee: Andrei Dulvac >Priority: Major > Fix For: Apache Sling Testing Clients 3.0.0 > > > Replace {{org.codehaus.jackson}} with the latest > {{com.fasterxml.jackson.core}} in the sling testing clients. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (SLING-10974) testing clients - replace org.codehaus.jackson with com.fasterxml.jackson.core
[ https://issues.apache.org/jira/browse/SLING-10974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-10974. --- Resolution: Fixed > testing clients - replace org.codehaus.jackson with com.fasterxml.jackson.core > -- > > Key: SLING-10974 > URL: https://issues.apache.org/jira/browse/SLING-10974 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 2.0.12 >Reporter: Andrei Dulvac >Assignee: Andrei Dulvac >Priority: Major > Fix For: Apache Sling Testing Clients 2.0.14 > > > Replace {{org.codehaus.jackson}} with the latest > {{com.fasterxml.jackson.core}} in the sling testing clients. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (SLING-10974) testing clients - replace org.codehaus.jackson with com.fasterxml.jackson.core
Andrei Dulvac created SLING-10974: - Summary: testing clients - replace org.codehaus.jackson with com.fasterxml.jackson.core Key: SLING-10974 URL: https://issues.apache.org/jira/browse/SLING-10974 Project: Sling Issue Type: Improvement Components: Apache Sling Testing Clients Affects Versions: Apache Sling Testing Clients 2.0.12 Reporter: Andrei Dulvac Assignee: Andrei Dulvac Fix For: Apache Sling Testing Clients 2.0.14 Replace {{org.codehaus.jackson}} with the latest {{com.fasterxml.jackson.core}} in the sling testing clients. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (SLING-9855) Invalidate login token when receiving 401
[ https://issues.apache.org/jira/browse/SLING-9855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-9855. -- Resolution: Fixed > Invalidate login token when receiving 401 > - > > Key: SLING-9855 > URL: https://issues.apache.org/jira/browse/SLING-9855 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 2.0.6 >Reporter: Andrei Tuicu >Assignee: Andrei Dulvac >Priority: Major > Fix For: Apache Sling Testing Clients 2.0.8 > > > h3. Story > The Sling testing clients should invalidate login token when receiving 401, > so that subsequent requests get a fresh token. Retrying requests with a token > for which we already got a 401 response are very likely to continue to fail. > h3. Acceptance Criteria > * The login token is invalidated in the client when Sling responds with 401 > cc [~andrei.dulvac] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (SLING-9855) Invalidate login token when receiving 401
[ https://issues.apache.org/jira/browse/SLING-9855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac reassigned SLING-9855: Assignee: Andrei Dulvac > Invalidate login token when receiving 401 > - > > Key: SLING-9855 > URL: https://issues.apache.org/jira/browse/SLING-9855 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 2.0.6 >Reporter: Andrei Tuicu >Assignee: Andrei Dulvac >Priority: Major > > h3. Story > The Sling testing clients should invalidate login token when receiving 401, > so that subsequent requests get a fresh token. Retrying requests with a token > for which we already got a 401 response are very likely to continue to fail. > h3. Acceptance Criteria > * The login token is invalidated in the client when Sling responds with 401 > cc [~andrei.dulvac] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-9855) Invalidate login token when receiving 401
[ https://issues.apache.org/jira/browse/SLING-9855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac updated SLING-9855: - Fix Version/s: Apache Sling Testing Clients 2.0.8 > Invalidate login token when receiving 401 > - > > Key: SLING-9855 > URL: https://issues.apache.org/jira/browse/SLING-9855 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 2.0.6 >Reporter: Andrei Tuicu >Assignee: Andrei Dulvac >Priority: Major > Fix For: Apache Sling Testing Clients 2.0.8 > > > h3. Story > The Sling testing clients should invalidate login token when receiving 401, > so that subsequent requests get a fresh token. Retrying requests with a token > for which we already got a 401 response are very likely to continue to fail. > h3. Acceptance Criteria > * The login token is invalidated in the client when Sling responds with 401 > cc [~andrei.dulvac] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-9647) [Testing Clients] Store request and response on a ClientException
[ https://issues.apache.org/jira/browse/SLING-9647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-9647. -- Resolution: Fixed > [Testing Clients] Store request and response on a ClientException > --- > > Key: SLING-9647 > URL: https://issues.apache.org/jira/browse/SLING-9647 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 2.0.0 >Reporter: Andrei Dulvac >Assignee: Andrei Dulvac >Priority: Minor > Fix For: Apache Sling Testing Clients 2.0.2 > > > Allow for ClientException to optionally store the request and response. This > would be useful for logging them as part of exception handling -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SLING-9647) [Testing Clients] Store request and response on a ClientException
Andrei Dulvac created SLING-9647: Summary: [Testing Clients] Store request and response on a ClientException Key: SLING-9647 URL: https://issues.apache.org/jira/browse/SLING-9647 Project: Sling Issue Type: Improvement Components: Apache Sling Testing Clients Affects Versions: Apache Sling Testing Clients 2.0.0 Reporter: Andrei Dulvac Assignee: Andrei Dulvac Fix For: Apache Sling Testing Clients 2.0.2 Allow for ClientException to optionally store the request and response. This would be useful for logging them as part of exception handling -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-9633) Testing Clients Polling does not return all exceptions encountered while polling
[ https://issues.apache.org/jira/browse/SLING-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-9633. -- Resolution: Fixed > Testing Clients Polling does not return all exceptions encountered while > polling > > > Key: SLING-9633 > URL: https://issues.apache.org/jira/browse/SLING-9633 > Project: Sling > Issue Type: Bug >Affects Versions: Apache Sling Testing Clients 2.0.0 >Reporter: Andrei Dulvac >Assignee: Andrei Dulvac >Priority: Minor > Fix For: Apache Sling Testing Clients 2.0.2 > > > It can happen with {{Polling}} that the last exception thrown is not the same > as the subsequent ones, for example in case of an operation with side effects > that might have thrown a particular exception, after which it throws some > sort of "conflict" exception. That first exception is thus lost. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SLING-9633) Testing Clients Polling does not return all exceptions encountered while polling
Andrei Dulvac created SLING-9633: Summary: Testing Clients Polling does not return all exceptions encountered while polling Key: SLING-9633 URL: https://issues.apache.org/jira/browse/SLING-9633 Project: Sling Issue Type: Bug Affects Versions: Apache Sling Testing Clients 2.0.0 Reporter: Andrei Dulvac Assignee: Andrei Dulvac Fix For: Apache Sling Testing Clients 2.0.2 It can happen with {{Polling}} that the last exception thrown is not the same as the subsequent ones, for example in case of an operation with side effects that might have thrown a particular exception, after which it throws some sort of "conflict" exception. That first exception is thus lost. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-9449) Repoinit AclUtil#setPrincipalAcl throws exception if no path-based entry exists for principal
[ https://issues.apache.org/jira/browse/SLING-9449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-9449. -- Fix Version/s: Repoinit JCR 1.1.28 Resolution: Fixed > Repoinit AclUtil#setPrincipalAcl throws exception if no path-based entry > exists for principal > - > > Key: SLING-9449 > URL: https://issues.apache.org/jira/browse/SLING-9449 > Project: Sling > Issue Type: Bug > Components: Repoinit >Affects Versions: Repoinit JCR 1.1.26 >Reporter: Andrei Dulvac >Assignee: Andrei Dulvac >Priority: Critical > Fix For: Repoinit JCR 1.1.28 > > > The check at > https://github.com/apache/sling-org-apache-sling-jcr-repoinit/blob/master/src/main/java/org/apache/sling/jcr/repoinit/impl/AclUtil.java#L191 > is very aggressive and results in an error getting thrown, which potentially > causes the repository service to not start up. > It should be replaced with a log message. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-9449) Repoinit AclUtil#setPrincipalAcl throws exception if no path-based entry exists for principal
[ https://issues.apache.org/jira/browse/SLING-9449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17106383#comment-17106383 ] Andrei Dulvac commented on SLING-9449: -- resolved in https://github.com/apache/sling-org-apache-sling-jcr-repoinit/commit/55aa500da6805482d6972330e37125eacedaca8f > Repoinit AclUtil#setPrincipalAcl throws exception if no path-based entry > exists for principal > - > > Key: SLING-9449 > URL: https://issues.apache.org/jira/browse/SLING-9449 > Project: Sling > Issue Type: Bug > Components: Repoinit >Affects Versions: Repoinit JCR 1.1.26 >Reporter: Andrei Dulvac >Assignee: Andrei Dulvac >Priority: Critical > > The check at > https://github.com/apache/sling-org-apache-sling-jcr-repoinit/blob/master/src/main/java/org/apache/sling/jcr/repoinit/impl/AclUtil.java#L191 > is very aggressive and results in an error getting thrown, which potentially > causes the repository service to not start up. > It should be replaced with a log message. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SLING-9449) Repoinit AclUtil#setPrincipalAcl throws exception if no path-based entry exists for principal
Andrei Dulvac created SLING-9449: Summary: Repoinit AclUtil#setPrincipalAcl throws exception if no path-based entry exists for principal Key: SLING-9449 URL: https://issues.apache.org/jira/browse/SLING-9449 Project: Sling Issue Type: Bug Components: Repoinit Affects Versions: Repoinit JCR 1.1.26 Reporter: Andrei Dulvac Assignee: Andrei Dulvac The check at https://github.com/apache/sling-org-apache-sling-jcr-repoinit/blob/master/src/main/java/org/apache/sling/jcr/repoinit/impl/AclUtil.java#L191 is very aggressive and results in an error getting thrown, which potentially causes the repository service to not start up. It should be replaced with a log message. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-9334) Refactor configurable retries mechanism to make them consistent
[ https://issues.apache.org/jira/browse/SLING-9334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-9334. -- Resolution: Fixed > Refactor configurable retries mechanism to make them consistent > --- > > Key: SLING-9334 > URL: https://issues.apache.org/jira/browse/SLING-9334 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 1.2.4 >Reporter: Andrei Dulvac >Assignee: Andrei Dulvac >Priority: Critical > Fix For: Apache Sling Testing Clients 2.0.0 > > > The {{o.a.s.testing.util.Constants}} class has some static fields that are > not constants at all. Those values should be moved into methods. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-9334) Refactor configurable retries mechanism to make them consistent
[ https://issues.apache.org/jira/browse/SLING-9334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076306#comment-17076306 ] Andrei Dulvac commented on SLING-9334: -- This took care of https://builds.apache.org/blue/organizations/jenkins/Sling%2Fsling-org-apache-sling-testing-clients/detail/master/92/pipeline > Refactor configurable retries mechanism to make them consistent > --- > > Key: SLING-9334 > URL: https://issues.apache.org/jira/browse/SLING-9334 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 1.2.4 >Reporter: Andrei Dulvac >Assignee: Andrei Dulvac >Priority: Critical > Fix For: Apache Sling Testing Clients 2.0.0 > > > The {{o.a.s.testing.util.Constants}} class has some static fields that are > not constants at all. Those values should be moved into methods. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-9334) Refactor configurable retries mechanism to make them consistent
[ https://issues.apache.org/jira/browse/SLING-9334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac updated SLING-9334: - Description: The {{o.a.s.testing.util.Constants}} class has some static fields that are not constants at all. Those values should be moved into methods. (was: Make http retry mechanism configurable. More specifically, configure the error codes for which to retry the test http calls.) > Refactor configurable retries mechanism to make them consistent > --- > > Key: SLING-9334 > URL: https://issues.apache.org/jira/browse/SLING-9334 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 1.2.4 >Reporter: Andrei Dulvac >Assignee: Andrei Dulvac >Priority: Critical > Fix For: Apache Sling Testing Clients 2.0.0 > > > The {{o.a.s.testing.util.Constants}} class has some static fields that are > not constants at all. Those values should be moved into methods. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SLING-9334) Refactor configurable retries mechanism to make them consistent
Andrei Dulvac created SLING-9334: Summary: Refactor configurable retries mechanism to make them consistent Key: SLING-9334 URL: https://issues.apache.org/jira/browse/SLING-9334 Project: Sling Issue Type: Improvement Components: Apache Sling Testing Clients Affects Versions: Apache Sling Testing Clients 1.2.4 Reporter: Andrei Dulvac Assignee: Andrei Dulvac Fix For: Apache Sling Testing Clients 2.0.0 Make http retry mechanism configurable. More specifically, configure the error codes for which to retry the test http calls. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-8196) [Sling testing rules] RemoteLogDumperRule hides original test failure if /system/sling/testlog is unavailable
[ https://issues.apache.org/jira/browse/SLING-8196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-8196. -- Resolution: Fixed > [Sling testing rules] RemoteLogDumperRule hides original test failure if > /system/sling/testlog is unavailable > - > > Key: SLING-8196 > URL: https://issues.apache.org/jira/browse/SLING-8196 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Rules >Affects Versions: Apache Sling Testing Rules 1.0.8 >Reporter: Andrei Dulvac >Assignee: Andrei Dulvac >Priority: Major > Fix For: Apache Sling Testing Rules 1.0.10 > > > RemoteLogDumperRule hides original test failure if /system/sling/testlog is > unavailable on the instance under test. > Logging that with WARN and throwing the original test failure is a more > useful behaviour. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-9329) Implement configurable retries mechanism for http 5XX response codes
[ https://issues.apache.org/jira/browse/SLING-9329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac updated SLING-9329: - Description: Make http retry mechanism configurable. More specifically, configure the error codes for which to retry the test http calls. was: In cloud environment, it is likely to have 503 or broken connection at a very low rate <1% of requests. This add unwanted flakiness to tests. Generally 503 or broken connection should be retried (at least that is recommended), thus it would be nice to introduce it on the AbstractSlingClient.doRequest(...) which seems to be the best place as common code (doGet, doPost etc..). > Implement configurable retries mechanism for http 5XX response codes > > > Key: SLING-9329 > URL: https://issues.apache.org/jira/browse/SLING-9329 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 1.2.4 >Reporter: Andrei Dulvac >Assignee: Andrei Dulvac >Priority: Critical > Fix For: Apache Sling Testing Clients 1.2.8 > > > Make http retry mechanism configurable. > More specifically, configure the error codes for which to retry the test http > calls. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-9329) Implement configurable retries mechanism for http 5XX response codes
[ https://issues.apache.org/jira/browse/SLING-9329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-9329. -- Resolution: Fixed > Implement configurable retries mechanism for http 5XX response codes > > > Key: SLING-9329 > URL: https://issues.apache.org/jira/browse/SLING-9329 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 1.2.4 >Reporter: Andrei Dulvac >Assignee: Andrei Dulvac >Priority: Critical > Fix For: Apache Sling Testing Clients 1.2.8 > > > Make http retry mechanism configurable. > More specifically, configure the error codes for which to retry the test http > calls. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-9329) Implement configurable retries mechanism for http 5XX response codes
[ https://issues.apache.org/jira/browse/SLING-9329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac updated SLING-9329: - Fix Version/s: (was: Apache Sling Testing Clients 1.2.6) Apache Sling Testing Clients 1.2.8 > Implement configurable retries mechanism for http 5XX response codes > > > Key: SLING-9329 > URL: https://issues.apache.org/jira/browse/SLING-9329 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 1.2.4 >Reporter: Thierry Ygé >Assignee: Andrei Dulvac >Priority: Critical > Fix For: Apache Sling Testing Clients 1.2.8 > > > In cloud environment, it is likely to have 503 or broken connection at a very > low rate <1% of requests. This add unwanted flakiness to tests. > Generally 503 or broken connection should be retried (at least that is > recommended), thus it would be nice to introduce it on the > AbstractSlingClient.doRequest(...) which seems to be the best place as common > code (doGet, doPost etc..). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SLING-9329) Implement configurable retries mechanism for http 5XX response codes
Andrei Dulvac created SLING-9329: Summary: Implement configurable retries mechanism for http 5XX response codes Key: SLING-9329 URL: https://issues.apache.org/jira/browse/SLING-9329 Project: Sling Issue Type: Improvement Components: Apache Sling Testing Clients Affects Versions: Apache Sling Testing Clients 1.2.4 Reporter: Thierry Ygé Assignee: Andrei Dulvac Fix For: Apache Sling Testing Clients 1.2.6 In cloud environment, it is likely to have 503 or broken connection at a very low rate <1% of requests. This add unwanted flakiness to tests. Generally 503 or broken connection should be retried (at least that is recommended), thus it would be nice to introduce it on the AbstractSlingClient.doRequest(...) which seems to be the best place as common code (doGet, doPost etc..). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-9329) Implement configurable retries mechanism for http 5XX response codes
[ https://issues.apache.org/jira/browse/SLING-9329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac updated SLING-9329: - Reporter: Andrei Dulvac (was: Thierry Ygé) > Implement configurable retries mechanism for http 5XX response codes > > > Key: SLING-9329 > URL: https://issues.apache.org/jira/browse/SLING-9329 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 1.2.4 >Reporter: Andrei Dulvac >Assignee: Andrei Dulvac >Priority: Critical > Fix For: Apache Sling Testing Clients 1.2.8 > > > In cloud environment, it is likely to have 503 or broken connection at a very > low rate <1% of requests. This add unwanted flakiness to tests. > Generally 503 or broken connection should be retried (at least that is > recommended), thus it would be nice to introduce it on the > AbstractSlingClient.doRequest(...) which seems to be the best place as common > code (doGet, doPost etc..). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-9129) ResourceUtils add extra line break at the end of the file
[ https://issues.apache.org/jira/browse/SLING-9129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-9129. -- Fix Version/s: Apache Sling Testing Clients 1.2.8 Resolution: Fixed > ResourceUtils add extra line break at the end of the file > - > > Key: SLING-9129 > URL: https://issues.apache.org/jira/browse/SLING-9129 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 1.2.6 >Reporter: Thierry Ygé >Assignee: Andrei Dulvac >Priority: Major > Fix For: Apache Sling Testing Clients 1.2.8 > > Time Spent: 1h > Remaining Estimate: 0h > > This method > [https://github.com/apache/sling-org-apache-sling-testing-clients/blob/master/src/main/java/org/apache/sling/testing/clients/util/ResourceUtil.java#L49-L65] > is adding extra line break at the end of the file it read which is not > expected. > Best would be that it doesn't read line by line but using > IOUtils.toString(InputStream.class, "utf-8"), that would make sure it > preserve the original file characters (including line breaks style if that > would be required in a test). > > Mainly the cultprit code is at line > [https://github.com/apache/sling-org-apache-sling-testing-clients/blob/master/src/main/java/org/apache/sling/testing/clients/util/ResourceUtil.java#L57] > The line break append all the time even at last line, which is why it add > this extra line. quickfix would be as suggested above or adding a condition > so that it does only add line break before it append the next line (so if the > StringBuffer is not empty) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-9089) RemoteLogDumperRule is too verbose if the logs cannot be retrieved
[ https://issues.apache.org/jira/browse/SLING-9089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac updated SLING-9089: - Fix Version/s: Apache Sling Testing Rules 1.0.10 > RemoteLogDumperRule is too verbose if the logs cannot be retrieved > -- > > Key: SLING-9089 > URL: https://issues.apache.org/jira/browse/SLING-9089 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Rules >Reporter: Valentin Olteanu >Assignee: Andrei Dulvac >Priority: Minor > Fix For: Apache Sling Testing Rules 1.0.10 > > > In case of a test failure, if the testlog servlet is not installed or cannot > be accessed, RemoteLogDumperRule prints a very verbose message to stderr, > confusing the user which thinks this is the root error: > {code} > Error occurred while fetching test logs from server [https://example.com/] > org.apache.sling.testing.clients.ClientException: Expected HTTP Status: 200 . > Instead 404 was returned! > Response Content: > > > 404 Resource at '/system/sling/testlog' not found: No > resource found > ... > {code} > I think we can move this to debug level. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (SLING-9129) ResourceUtils add extra line break at the end of the file
[ https://issues.apache.org/jira/browse/SLING-9129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac reassigned SLING-9129: Assignee: Andrei Dulvac > ResourceUtils add extra line break at the end of the file > - > > Key: SLING-9129 > URL: https://issues.apache.org/jira/browse/SLING-9129 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 1.2.6 >Reporter: Thierry Ygé >Assignee: Andrei Dulvac >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > This method > [https://github.com/apache/sling-org-apache-sling-testing-clients/blob/master/src/main/java/org/apache/sling/testing/clients/util/ResourceUtil.java#L49-L65] > is adding extra line break at the end of the file it read which is not > expected. > Best would be that it doesn't read line by line but using > IOUtils.toString(InputStream.class, "utf-8"), that would make sure it > preserve the original file characters (including line breaks style if that > would be required in a test). > > Mainly the cultprit code is at line > [https://github.com/apache/sling-org-apache-sling-testing-clients/blob/master/src/main/java/org/apache/sling/testing/clients/util/ResourceUtil.java#L57] > The line break append all the time even at last line, which is why it add > this extra line. quickfix would be as suggested above or adding a condition > so that it does only add line break before it append the next line (so if the > StringBuffer is not empty) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-9089) RemoteLogDumperRule is too verbose if the logs cannot be retrieved
[ https://issues.apache.org/jira/browse/SLING-9089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-9089. -- Resolution: Fixed > RemoteLogDumperRule is too verbose if the logs cannot be retrieved > -- > > Key: SLING-9089 > URL: https://issues.apache.org/jira/browse/SLING-9089 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Rules >Reporter: Valentin Olteanu >Assignee: Andrei Dulvac >Priority: Minor > > In case of a test failure, if the testlog servlet is not installed or cannot > be accessed, RemoteLogDumperRule prints a very verbose message to stderr, > confusing the user which thinks this is the root error: > {code} > Error occurred while fetching test logs from server [https://example.com/] > org.apache.sling.testing.clients.ClientException: Expected HTTP Status: 200 . > Instead 404 was returned! > Response Content: > > > 404 Resource at '/system/sling/testlog' not found: No > resource found > ... > {code} > I think we can move this to debug level. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (SLING-9089) RemoteLogDumperRule is too verbose if the logs cannot be retrieved
[ https://issues.apache.org/jira/browse/SLING-9089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac reassigned SLING-9089: Assignee: Andrei Dulvac > RemoteLogDumperRule is too verbose if the logs cannot be retrieved > -- > > Key: SLING-9089 > URL: https://issues.apache.org/jira/browse/SLING-9089 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Rules >Reporter: Valentin Olteanu >Assignee: Andrei Dulvac >Priority: Minor > > In case of a test failure, if the testlog servlet is not installed or cannot > be accessed, RemoteLogDumperRule prints a very verbose message to stderr, > confusing the user which thinks this is the root error: > {code} > Error occurred while fetching test logs from server [https://example.com/] > org.apache.sling.testing.clients.ClientException: Expected HTTP Status: 200 . > Instead 404 was returned! > Response Content: > > > 404 Resource at '/system/sling/testlog' not found: No > resource found > ... > {code} > I think we can move this to debug level. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-9069) Polling format exception in case of TimeoutException
[ https://issues.apache.org/jira/browse/SLING-9069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac updated SLING-9069: - Issue Type: Bug (was: Improvement) > Polling format exception in case of TimeoutException > > > Key: SLING-9069 > URL: https://issues.apache.org/jira/browse/SLING-9069 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 1.2.4 >Reporter: Andrei Dulvac >Assignee: Andrei Dulvac >Priority: Critical > Fix For: Apache Sling Testing Clients 1.2.6 > > > The {{Polling}} class has a line that can throw a format exception in case > the message of lastException contains a "%": > {{throw new TimeoutException(String.format(message(), effectiveTimeout, > delay));}} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-8921) requestPath must to be encoded in SlingClient#doGet()
[ https://issues.apache.org/jira/browse/SLING-8921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac updated SLING-8921: - Fix Version/s: Apache Sling Testing Clients 1.2.6 > requestPath must to be encoded in SlingClient#doGet() > - > > Key: SLING-8921 > URL: https://issues.apache.org/jira/browse/SLING-8921 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Clients >Reporter: Valentin Olteanu >Assignee: Andrei Dulvac >Priority: Minor > Fix For: Apache Sling Testing Clients 1.2.6 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > [SlingClient#doGet()|https://github.com/apache/sling-org-apache-sling-testing-clients/blob/609cb61fd2dec08657556b9adc91e889911a230e/src/main/java/org/apache/sling/testing/clients/AbstractSlingClient.java#L492] > requires `requestPath` to be encoded (because it's passed to multiple URI > constructors). > The contract should be uniform: all the parameters are passed decoded and the > method takes care to encode them properly before creating the request. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-9069) Polling format exception in case of TimeoutException
[ https://issues.apache.org/jira/browse/SLING-9069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-9069. -- Resolution: Fixed > Polling format exception in case of TimeoutException > > > Key: SLING-9069 > URL: https://issues.apache.org/jira/browse/SLING-9069 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 1.2.4 >Reporter: Andrei Dulvac >Assignee: Andrei Dulvac >Priority: Critical > Fix For: Apache Sling Testing Clients 1.2.6 > > > The {{Polling}} class has a line that can throw a format exception in case > the message of lastException contains a "%": > {{throw new TimeoutException(String.format(message(), effectiveTimeout, > delay));}} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-8921) requestPath must to be encoded in SlingClient#doGet()
[ https://issues.apache.org/jira/browse/SLING-8921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-8921. -- Resolution: Fixed > requestPath must to be encoded in SlingClient#doGet() > - > > Key: SLING-8921 > URL: https://issues.apache.org/jira/browse/SLING-8921 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Clients >Reporter: Valentin Olteanu >Priority: Minor > Time Spent: 1h 10m > Remaining Estimate: 0h > > [SlingClient#doGet()|https://github.com/apache/sling-org-apache-sling-testing-clients/blob/609cb61fd2dec08657556b9adc91e889911a230e/src/main/java/org/apache/sling/testing/clients/AbstractSlingClient.java#L492] > requires `requestPath` to be encoded (because it's passed to multiple URI > constructors). > The contract should be uniform: all the parameters are passed decoded and the > method takes care to encode them properly before creating the request. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (SLING-8921) requestPath must to be encoded in SlingClient#doGet()
[ https://issues.apache.org/jira/browse/SLING-8921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac reassigned SLING-8921: Assignee: Andrei Dulvac > requestPath must to be encoded in SlingClient#doGet() > - > > Key: SLING-8921 > URL: https://issues.apache.org/jira/browse/SLING-8921 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Clients >Reporter: Valentin Olteanu >Assignee: Andrei Dulvac >Priority: Minor > Time Spent: 1h 10m > Remaining Estimate: 0h > > [SlingClient#doGet()|https://github.com/apache/sling-org-apache-sling-testing-clients/blob/609cb61fd2dec08657556b9adc91e889911a230e/src/main/java/org/apache/sling/testing/clients/AbstractSlingClient.java#L492] > requires `requestPath` to be encoded (because it's passed to multiple URI > constructors). > The contract should be uniform: all the parameters are passed decoded and the > method takes care to encode them properly before creating the request. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-9053) Implement retries mechanism for http 5XX response codes
[ https://issues.apache.org/jira/browse/SLING-9053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-9053. -- Resolution: Fixed > Implement retries mechanism for http 5XX response codes > --- > > Key: SLING-9053 > URL: https://issues.apache.org/jira/browse/SLING-9053 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 1.2.4 >Reporter: Thierry Ygé >Assignee: Andrei Dulvac >Priority: Critical > Fix For: Apache Sling Testing Clients 1.2.6 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > In cloud environment, it is likely to have 503 or broken connection at a very > low rate <1% of requests. This add unwanted flakiness to tests. > Generally 503 or broken connection should be retried (at least that is > recommended), thus it would be nice to introduce it on the > AbstractSlingClient.doRequest(...) which seems to be the best place as common > code (doGet, doPost etc..). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (SLING-8710) IndexingClient should have configurable lanes
[ https://issues.apache.org/jira/browse/SLING-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac reassigned SLING-8710: Assignee: Andrei Dulvac > IndexingClient should have configurable lanes > - > > Key: SLING-8710 > URL: https://issues.apache.org/jira/browse/SLING-8710 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Reporter: Vikas Saurabh >Assignee: Andrei Dulvac >Priority: Major > Labels: sling-IT > Fix For: Apache Sling Testing Clients 1.2.4 > > Time Spent: 4h 10m > Remaining Estimate: 0h > > {{IndexingClient}} currently relies on {{OsgiConsoleCient}} to peek into > system's lane configuration. That, in turn, requires access to > /system/console which might be blocked on the system which is being tested. > As indexing lanes in a setup isn't a very dynamic property, a quick work > around could be for {{IndexingClient}} to allow setting up "expected index > lanes in target setup". > This issue would be an improvement over what was implemented in SLING-7169. > [~rombert] and [~volteanu], since most of the comments over there are from > you guys, wdyt about this improvement? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-9069) Polling format exception in case of TimeoutException
[ https://issues.apache.org/jira/browse/SLING-9069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac updated SLING-9069: - Description: The {{Polling}} class has a line that can throw a format exception in case the message of lastException contains a "%": {{throw new TimeoutException(String.format(message(), effectiveTimeout, delay));}} was: In cloud environment, it is likely to have 503 or broken connection at a very low rate <1% of requests. This add unwanted flakiness to tests. Generally 503 or broken connection should be retried (at least that is recommended), thus it would be nice to introduce it on the AbstractSlingClient.doRequest(...) which seems to be the best place as common code (doGet, doPost etc..). > Polling format exception in case of TimeoutException > > > Key: SLING-9069 > URL: https://issues.apache.org/jira/browse/SLING-9069 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 1.2.4 >Reporter: Andrei Dulvac >Assignee: Andrei Dulvac >Priority: Critical > Fix For: Apache Sling Testing Clients 1.2.6 > > > The {{Polling}} class has a line that can throw a format exception in case > the message of lastException contains a "%": > {{throw new TimeoutException(String.format(message(), effectiveTimeout, > delay));}} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-9069) Polling format exception in case of TimeoutException
[ https://issues.apache.org/jira/browse/SLING-9069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac updated SLING-9069: - Reporter: Andrei Dulvac (was: Thierry Ygé) > Polling format exception in case of TimeoutException > > > Key: SLING-9069 > URL: https://issues.apache.org/jira/browse/SLING-9069 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 1.2.4 >Reporter: Andrei Dulvac >Assignee: Andrei Dulvac >Priority: Critical > Fix For: Apache Sling Testing Clients 1.2.6 > > > In cloud environment, it is likely to have 503 or broken connection at a very > low rate <1% of requests. This add unwanted flakiness to tests. > Generally 503 or broken connection should be retried (at least that is > recommended), thus it would be nice to introduce it on the > AbstractSlingClient.doRequest(...) which seems to be the best place as common > code (doGet, doPost etc..). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SLING-9069) Polling format exception in case of TimeoutException
Andrei Dulvac created SLING-9069: Summary: Polling format exception in case of TimeoutException Key: SLING-9069 URL: https://issues.apache.org/jira/browse/SLING-9069 Project: Sling Issue Type: Improvement Components: Apache Sling Testing Clients Affects Versions: Apache Sling Testing Clients 1.2.4 Reporter: Thierry Ygé Assignee: Andrei Dulvac Fix For: Apache Sling Testing Clients 1.2.6 In cloud environment, it is likely to have 503 or broken connection at a very low rate <1% of requests. This add unwanted flakiness to tests. Generally 503 or broken connection should be retried (at least that is recommended), thus it would be nice to introduce it on the AbstractSlingClient.doRequest(...) which seems to be the best place as common code (doGet, doPost etc..). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-9053) Implement retries mechanism for http 5XX response codes
[ https://issues.apache.org/jira/browse/SLING-9053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac updated SLING-9053: - Summary: Implement retries mechanism for http 5XX response codes (was: Implement retries mechanism for AbstractSlingClient.doRequest(...)) > Implement retries mechanism for http 5XX response codes > --- > > Key: SLING-9053 > URL: https://issues.apache.org/jira/browse/SLING-9053 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 1.2.4 >Reporter: Thierry Ygé >Assignee: Andrei Dulvac >Priority: Critical > Fix For: Apache Sling Testing Clients 1.2.6 > > Time Spent: 2h > Remaining Estimate: 0h > > In cloud environment, it is likely to have 503 or broken connection at a very > low rate <1% of requests. This add unwanted flakiness to tests. > Generally 503 or broken connection should be retried (at least that is > recommended), thus it would be nice to introduce it on the > AbstractSlingClient.doRequest(...) which seems to be the best place as common > code (doGet, doPost etc..). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (SLING-9053) Implement retries mechanism for AbstractSlingClient.doRequest(...)
[ https://issues.apache.org/jira/browse/SLING-9053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac reassigned SLING-9053: Assignee: Andrei Dulvac > Implement retries mechanism for AbstractSlingClient.doRequest(...) > -- > > Key: SLING-9053 > URL: https://issues.apache.org/jira/browse/SLING-9053 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 1.2.4 >Reporter: Thierry Ygé >Assignee: Andrei Dulvac >Priority: Critical > Fix For: Apache Sling Testing Clients 1.2.6 > > Time Spent: 2h > Remaining Estimate: 0h > > In cloud environment, it is likely to have 503 or broken connection at a very > low rate <1% of requests. This add unwanted flakiness to tests. > Generally 503 or broken connection should be retried (at least that is > recommended), thus it would be nice to introduce it on the > AbstractSlingClient.doRequest(...) which seems to be the best place as common > code (doGet, doPost etc..). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-8710) IndexingClient should have configurable lanes
[ https://issues.apache.org/jira/browse/SLING-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16932390#comment-16932390 ] Andrei Dulvac commented on SLING-8710: -- Merged the PRs and added https://github.com/apache/sling-org-apache-sling-testing-clients/commit/09b429d7e4b1f69cccba9de1e7a1a25d0358a0dd Will trigger a release later today. > IndexingClient should have configurable lanes > - > > Key: SLING-8710 > URL: https://issues.apache.org/jira/browse/SLING-8710 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Reporter: Vikas Saurabh >Priority: Major > Labels: sling-IT > Time Spent: 3h 10m > Remaining Estimate: 0h > > {{IndexingClient}} currently relies on {{OsgiConsoleCient}} to peek into > system's lane configuration. That, in turn, requires access to > /system/console which might be blocked on the system which is being tested. > As indexing lanes in a setup isn't a very dynamic property, a quick work > around could be for {{IndexingClient}} to allow setting up "expected index > lanes in target setup". > This issue would be an improvement over what was implemented in SLING-7169. > [~rombert] and [~volteanu], since most of the comments over there are from > you guys, wdyt about this improvement? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-8710) IndexingClient should have configurable lanes
[ https://issues.apache.org/jira/browse/SLING-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-8710. -- Fix Version/s: Apache Sling Testing Clients 1.2.4 Resolution: Fixed > IndexingClient should have configurable lanes > - > > Key: SLING-8710 > URL: https://issues.apache.org/jira/browse/SLING-8710 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Reporter: Vikas Saurabh >Priority: Major > Labels: sling-IT > Fix For: Apache Sling Testing Clients 1.2.4 > > Time Spent: 3h 10m > Remaining Estimate: 0h > > {{IndexingClient}} currently relies on {{OsgiConsoleCient}} to peek into > system's lane configuration. That, in turn, requires access to > /system/console which might be blocked on the system which is being tested. > As indexing lanes in a setup isn't a very dynamic property, a quick work > around could be for {{IndexingClient}} to allow setting up "expected index > lanes in target setup". > This issue would be an improvement over what was implemented in SLING-7169. > [~rombert] and [~volteanu], since most of the comments over there are from > you guys, wdyt about this improvement? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-8710) IndexingClient should have configurable lanes
[ https://issues.apache.org/jira/browse/SLING-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac updated SLING-8710: - Component/s: (was: Launchpad) Apache Sling Testing Clients > IndexingClient should have configurable lanes > - > > Key: SLING-8710 > URL: https://issues.apache.org/jira/browse/SLING-8710 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients >Reporter: Vikas Saurabh >Priority: Major > Labels: sling-IT > Time Spent: 3h 10m > Remaining Estimate: 0h > > {{IndexingClient}} currently relies on {{OsgiConsoleCient}} to peek into > system's lane configuration. That, in turn, requires access to > /system/console which might be blocked on the system which is being tested. > As indexing lanes in a setup isn't a very dynamic property, a quick work > around could be for {{IndexingClient}} to allow setting up "expected index > lanes in target setup". > This issue would be an improvement over what was implemented in SLING-7169. > [~rombert] and [~volteanu], since most of the comments over there are from > you guys, wdyt about this improvement? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-8227) [http testing clients] ResourceUtil#getResourceAsStream doesn't work on jdk 11
[ https://issues.apache.org/jira/browse/SLING-8227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-8227. -- Resolution: Fixed > [http testing clients] ResourceUtil#getResourceAsStream doesn't work on jdk 11 > -- > > Key: SLING-8227 > URL: https://issues.apache.org/jira/browse/SLING-8227 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 1.2.0 >Reporter: Andrei Dulvac >Assignee: Andrei Dulvac >Priority: Major > Fix For: Apache Sling Testing Clients 1.2.2 > > > {{ResourceUtil#getResourceAsStream}} returns null on java 11 (probably since > java 9). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-8227) [http testing clients] ResourceUtil#getResourceAsStream doesn't work on jdk 11
[ https://issues.apache.org/jira/browse/SLING-8227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16748114#comment-16748114 ] Andrei Dulvac commented on SLING-8227: -- Solved [here|https://github.com/apache/sling-org-apache-sling-testing-clients/commit/2f54ff2c5c9fbfaec77c10b7afd205d40c432a65] > [http testing clients] ResourceUtil#getResourceAsStream doesn't work on jdk 11 > -- > > Key: SLING-8227 > URL: https://issues.apache.org/jira/browse/SLING-8227 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 1.2.0 >Reporter: Andrei Dulvac >Assignee: Andrei Dulvac >Priority: Major > Fix For: Apache Sling Testing Clients 1.2.2 > > > {{ResourceUtil#getResourceAsStream}} returns null on java 11 (probably since > java 9). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-8227) [http testing clients] ResourceUtil#getResourceAsStream doesn't work on jdk 11
Andrei Dulvac created SLING-8227: Summary: [http testing clients] ResourceUtil#getResourceAsStream doesn't work on jdk 11 Key: SLING-8227 URL: https://issues.apache.org/jira/browse/SLING-8227 Project: Sling Issue Type: Bug Components: Apache Sling Testing Clients Affects Versions: Apache Sling Testing Clients 1.2.0 Reporter: Andrei Dulvac Assignee: Andrei Dulvac Fix For: Apache Sling Testing Clients 1.2.2 {{ResourceUtil#getResourceAsStream}} returns null on java 11 (probably since java 9). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-8196) [Sling testing rules] RemoteLogDumperRule hides original test failure if /system/sling/testlog is unavailable
[ https://issues.apache.org/jira/browse/SLING-8196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac updated SLING-8196: - Fix Version/s: Apache Sling Testing Rules 1.0.10 > [Sling testing rules] RemoteLogDumperRule hides original test failure if > /system/sling/testlog is unavailable > - > > Key: SLING-8196 > URL: https://issues.apache.org/jira/browse/SLING-8196 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Rules >Affects Versions: Apache Sling Testing Rules 1.0.8 >Reporter: Andrei Dulvac >Assignee: Andrei Dulvac >Priority: Major > Fix For: Apache Sling Testing Rules 1.0.10 > > > RemoteLogDumperRule hides original test failure if /system/sling/testlog is > unavailable on the instance under test. > Logging that with WARN and throwing the original test failure is a more > useful behaviour. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-6994) [Mocks] Sling JCR Mocks do not resolve vanity resources properly
[ https://issues.apache.org/jira/browse/SLING-6994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac updated SLING-6994: - Component/s: (was: Apache Sling Testing Rules) > [Mocks] Sling JCR Mocks do not resolve vanity resources properly > > > Key: SLING-6994 > URL: https://issues.apache.org/jira/browse/SLING-6994 > Project: Sling > Issue Type: Improvement >Reporter: David Gonzalez >Priority: Major > > I would like to use Sling Mocks to test code that relies on > sling:vanityPaths. Sling Mocks resolve vanity pathed resources to > sling:nonexisting rather than sling:redirect (which is the actual behavior) > which isn't allowing me to write tests for my code unless i change my code to > match mock behavior and not be driven by actual behavior/contracts. > {noformat} > @Rule > public SlingContext context = new > SlingContextBuilder(ResourceResolverType.JCR_MOCK) >.resourceResolverFactoryActivatorProps(ImmutableMap.of( >"resource.resolver.mapping", new String[] {"/:/", > "/content/test/)) >.build(); > @Before > public void setUp() throws Exception { >request = new MockSlingHttpServletRequest(context.resourceResolver(), > context.bundleContext()); >response = new MockSlingHttpServletResponse(); >context.build().resource("/content") >.resource("test") >.resource("vanity", "sling:vanityPath", "/my-vanity"); > } > ... > @Test > public void dispatch_path1() throws Exception { > request.setServletPath("/content/test/my-vanity"); > ... calls code that preforms ... > > rr.resolve(rr.map("/content/test/my-vanity")).isResourceType("sling:redirect") > > // This should return true; however in mocks the resource type is > "sling:nonexisting" > } > } > {noformat} > /cc [~sseif...@pro-vision.de] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-7295) Readme should outline the differences between SlingRule and SlingInstanceRule
[ https://issues.apache.org/jira/browse/SLING-7295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16731933#comment-16731933 ] Andrei Dulvac commented on SLING-7295: -- [~kwin], should I add more detail to what's already there? bq. The SlingRule (for methods) or SlingClassRule are base rules, chaining other rules like TestTimeoutRule, TestDescriptionRule, FilterRule. > Readme should outline the differences between SlingRule and SlingInstanceRule > - > > Key: SLING-7295 > URL: https://issues.apache.org/jira/browse/SLING-7295 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Rules >Affects Versions: Apache Sling Testing Rules 1.0.6 >Reporter: Konrad Windszus >Priority: Major > > The readme at > https://github.com/apache/sling-org-apache-sling-testing-rules/blob/master/README.md > contains two examples which declare both > # {{SlingRule}} (as {{@Rule}}) and > # {{SlingInstanceRule}} (as {{@ClassRule}}) > Only the latter instance is actually used in the code then, so I am wondering > what the reason is for that other rule. It would be good to clarify that in > the readme. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (SLING-8196) [Sling testing rules] RemoteLogDumperRule hides original test failure if /system/sling/testlog is unavailable
[ https://issues.apache.org/jira/browse/SLING-8196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac reassigned SLING-8196: Assignee: Andrei Dulvac > [Sling testing rules] RemoteLogDumperRule hides original test failure if > /system/sling/testlog is unavailable > - > > Key: SLING-8196 > URL: https://issues.apache.org/jira/browse/SLING-8196 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Rules >Affects Versions: Apache Sling Testing Rules 1.0.8 >Reporter: Andrei Dulvac >Assignee: Andrei Dulvac >Priority: Major > > RemoteLogDumperRule hides original test failure if /system/sling/testlog is > unavailable on the instance under test. > Logging that with WARN and throwing the original test failure is a more > useful behaviour. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-8196) [Sling testing rules] RemoteLogDumperRule hides original test failure if /system/sling/testlog is unavailable
[ https://issues.apache.org/jira/browse/SLING-8196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac updated SLING-8196: - Description: RemoteLogDumperRule hides original test failure if /system/sling/testlog is unavailable on the instance under test. Logging that with WARN and throwing the original test failure is a more useful behaviour. > [Sling testing rules] RemoteLogDumperRule hides original test failure if > /system/sling/testlog is unavailable > - > > Key: SLING-8196 > URL: https://issues.apache.org/jira/browse/SLING-8196 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Rules >Affects Versions: Apache Sling Testing Rules 1.0.8 >Reporter: Andrei Dulvac >Priority: Major > > RemoteLogDumperRule hides original test failure if /system/sling/testlog is > unavailable on the instance under test. > Logging that with WARN and throwing the original test failure is a more > useful behaviour. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-8196) [Sling testing rules] RemoteLogDumperRule hides original test failure if /system/sling/testlog is unavailable
[ https://issues.apache.org/jira/browse/SLING-8196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac updated SLING-8196: - Component/s: Apache Sling Testing Rules > [Sling testing rules] RemoteLogDumperRule hides original test failure if > /system/sling/testlog is unavailable > - > > Key: SLING-8196 > URL: https://issues.apache.org/jira/browse/SLING-8196 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Rules >Affects Versions: Apache Sling Testing Rules 1.0.8 >Reporter: Andrei Dulvac >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-8196) [Sling testing rules] RemoteLogDumperRule hides original test failure if /system/sling/testlog is unavailable
Andrei Dulvac created SLING-8196: Summary: [Sling testing rules] RemoteLogDumperRule hides original test failure if /system/sling/testlog is unavailable Key: SLING-8196 URL: https://issues.apache.org/jira/browse/SLING-8196 Project: Sling Issue Type: Bug Affects Versions: Apache Sling Testing Rules 1.0.8 Reporter: Andrei Dulvac -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SLING-8160) Polling inhibits InterruptedException
[ https://issues.apache.org/jira/browse/SLING-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-8160. -- Resolution: Fixed Assignee: Andrei Dulvac Fix Version/s: Apache Sling Testing Clients 1.2.2 Fixed by https://github.com/apache/sling-org-apache-sling-testing-clients/pull/9 > Polling inhibits InterruptedException > - > > Key: SLING-8160 > URL: https://issues.apache.org/jira/browse/SLING-8160 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 1.2.0 >Reporter: Valentin Olteanu >Assignee: Andrei Dulvac >Priority: Major > Fix For: Apache Sling Testing Clients 1.2.2 > > > [Polling|https://github.com/apache/sling-org-apache-sling-testing-clients/blob/master/src/main/java/org/apache/sling/testing/clients/util/poller/Polling.java#L118] > catches all the exceptions thrown by {{call()}}, included > {{InterruptedException}}. This should be re-thrown instead of inhibiting it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-7724) Change scope to QueryServlet dependencies
[ https://issues.apache.org/jira/browse/SLING-7724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510690#comment-16510690 ] Andrei Dulvac commented on SLING-7724: -- Thanks for the PR! > Change scope to QueryServlet dependencies > - > > Key: SLING-7724 > URL: https://issues.apache.org/jira/browse/SLING-7724 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 1.2.0 >Reporter: Valentin Olteanu >Assignee: Andrei Dulvac >Priority: Major > Fix For: Apache Sling Testing Clients 1.2.2 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently, all the server-side dependencies for {{QueryServlet}} are listed > with {{provided}} in the pom. > These dependencies get lost in test bundles that have a dependency to > sling.testing.clients, so {{TinyBundles}} fails to create a bundle with > {{QueryServlet}}. > The dependencies need to be compile-scoped to keep them in the resulting jar. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SLING-7724) Change scope to QueryServlet dependencies
[ https://issues.apache.org/jira/browse/SLING-7724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-7724. -- Resolution: Fixed Assignee: Andrei Dulvac > Change scope to QueryServlet dependencies > - > > Key: SLING-7724 > URL: https://issues.apache.org/jira/browse/SLING-7724 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Clients >Affects Versions: Apache Sling Testing Clients 1.2.0 >Reporter: Valentin Olteanu >Assignee: Andrei Dulvac >Priority: Major > Fix For: Apache Sling Testing Clients 1.2.2 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently, all the server-side dependencies for {{QueryServlet}} are listed > with {{provided}} in the pom. > These dependencies get lost in test bundles that have a dependency to > sling.testing.clients, so {{TinyBundles}} fails to create a bundle with > {{QueryServlet}}. > The dependencies need to be compile-scoped to keep them in the resulting jar. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SLING-7669) StartupManager overwrites the frameworkstartlevel property and there is no way to retrieve the intended target start level
[ https://issues.apache.org/jira/browse/SLING-7669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulvac resolved SLING-7669. -- Resolution: Fixed Fix Version/s: Launchpad Base 2.6.26 > StartupManager overwrites the frameworkstartlevel property and there is no > way to retrieve the intended target start level > -- > > Key: SLING-7669 > URL: https://issues.apache.org/jira/browse/SLING-7669 > Project: Sling > Issue Type: Bug > Components: Launchpad >Reporter: Andrei Dulvac >Assignee: Andrei Dulvac >Priority: Major > Fix For: Launchpad Base 2.6.26 > > Time Spent: 50m > Remaining Estimate: 0h > > In incremental mode, the {{StartupManager}} keeps the target startlevel in a > private field, but overwrites "org.osgi.framework.startlevel.beginning" (for > a reason), but leaves no other way to retrieve the "target start level" of > the application. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-7669) StartupManager overwrites the frameworkstartlevel property and there is no way to retrieve the intended target start level
Andrei Dulvac created SLING-7669: Summary: StartupManager overwrites the frameworkstartlevel property and there is no way to retrieve the intended target start level Key: SLING-7669 URL: https://issues.apache.org/jira/browse/SLING-7669 Project: Sling Issue Type: Bug Components: Launchpad Reporter: Andrei Dulvac Assignee: Andrei Dulvac In incremental mode, the {{StartupManager}} keeps the target startlevel in a private field, but overwrites "org.osgi.framework.startlevel.beginning" (for a reason), but leaves no other way to retrieve the "target start level" of the application. -- This message was sent by Atlassian JIRA (v7.6.3#76005)