[jira] [Assigned] (SLING-9948) Jenkins: Parallelize steps of pipeline

[Konrad Windszus (Jira)]

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

Konrad Windszus reassigned SLING-9948:
--

Assignee: Konrad Windszus

> Jenkins: Parallelize steps of pipeline
> --
>
> Key: SLING-9948
> URL: https://issues.apache.org/jira/browse/SLING-9948
> Project: Sling
>  Issue Type: Improvement
>  Components: Build and Source Control
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> We should improve the speed of Jenkins pipelines by executing multiple Maven 
> builds in parallel.
> Also the Sonarqube step executes the Maven build again, instead it should 
> reuse the workspace of a previous build instead.
> Parallelizing Maven probably requires MRESOLVER-123 or we have to use 
> completely separate Maven repositories



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[GitHub] [sling-org-apache-sling-jcr-jackrabbit-accessmanager] enapps-enorman merged pull request #15: SLING-11243 handle conflict between aggregate and leaf

[GitBox]

enapps-enorman merged PR #15:
URL: 
https://github.com/apache/sling-org-apache-sling-jcr-jackrabbit-accessmanager/pull/15


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [sling-org-apache-sling-event] joerghoh merged pull request #23: SLING-8413 escape topic root in xpath query

[GitBox]

joerghoh merged PR #23:
URL: https://github.com/apache/sling-org-apache-sling-event/pull/23


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: Sling's RequestDispatcher tries to flush a closed buffer (Was: Re: SlingRequestDispatcher and nested forwards)

[Carsten Ziegeler]

Hi Radu,

there is a difference between flush and close. If some downstream code 
is flushing then the dispatcher can still call flushBuffer. But if some 
downstream code is closing, then flushing will of course not work. To be 
it sounds like there is some code illegally closing the response. I 
think that should be fixed instead. I remember that we needed to fix 
this in other servlets using johnzon as well and avoid that the json 
writer closes the output stream/writer.


flushBuffer is called to commit the response, which I think was required 
to be complient with how forward works. We can of course as a sanity 
check call response.isCommitted() but does this help here?


Regards
Carsten

Am 14.06.2022 um 16:39 schrieb Radu Cotescu:

Hi Carsten,

our own RequestDispatcher calls response.flushBuffer() at the end of the 
forward method [1] without checking first if the response has already been 
committed. By this time, the response can be already committed, since dispatch 
is called before this flushBufer() call [2]. The 
SlingHttpServletResponseImpl#flushBuffer can end up calling PrintWriter#flush 
[3], which in case the writer was already closed (happens for example if you 
wrap the writer with the JsonWriter from Johnzon, which is auto-closable), will 
end up throwing the exception with the message provided by Bertrand if the 
initial request was forwarded.

Is there any reason to call flushBuffer in the RequestDispatcher#forward? If 
yes, can’t we first check if the response was committed first 
(response.isComitted())?

Thanks,
Radu

[2] - 
https://github.com/apache/sling-org-apache-sling-engine/blob/8580cf1d5862f2a3b2cbe01c929c4c43cb93d773/src/main/java/org/apache/sling/engine/impl/request/SlingRequestDispatcher.java#L146
 

[3] - 
https://github.com/apache/sling-org-apache-sling-engine/blob/4c7e4149e15567015b1e586b6df617a9af16a6de/src/main/java/org/apache/sling/engine/impl/SlingHttpServletResponseImpl.java#L227
 




On 5 Jun 2022, at 11:53, Carsten Ziegeler  wrote:

In general, I think several calls to flushBuffer are totally valid, so even if 
anyone else called this already in a inner call from forward, this shouldn't be 
a problem. A rather suspect that the problem is more with duplicate tries to 
set the headers or something along those lines.

So I think we should figure out what really is going on before making any 
changes. It seems there is a scenario which is causing this, so it would be 
good to convert that into a test.

Regards
Carsten

Am 03.06.2022 um 18:18 schrieb Bertrand Delacretaz:

Hi,
A colleague mentioned getting "SlingRequestProcessorImpl Writer has
already been closed" error messages when using
SlingRequestDispatcher.forward(...), and looking at the code [1] I
wonder if we should change the request flushing behavior.
Unfortunately, unless I missed something that code is not covered by
units tests, but I suppose nested calls to
SlingRequestDispatcher.forward(...) would cause the problem:
SlingRequestDispatcher blindly calls response.flushBuffer(), which
causes logged errors if the response Writer is already closed. So if a
Servlet that's been forwarded to calls
SlingRequestDispatcher.forward(...) I suppose we get this problem.
I could write a test to verify all that of course, but maybe someone
already has a clear idea on this.
Shall we modify that code to check the request status before calling
flushBuffer() ? I don't think there's a direct way to check if the
Writer is closed already, but maybe there's another call on the
request that would check that?
-Bertrand
[1] 
https://github.com/apache/sling-org-apache-sling-engine/blob/631a54f45abf5fd6d7c56dac43fd499db543bcd7/src/main/java/org/apache/sling/engine/impl/request/SlingRequestDispatcher.java#L151


--
Carsten Ziegeler
Adobe
cziege...@apache.org





--
Carsten Ziegeler
Adobe
cziege...@apache.org

Sling's RequestDispatcher tries to flush a closed buffer (Was: Re: SlingRequestDispatcher and nested forwards)

[Radu Cotescu]

Hi Carsten,

our own RequestDispatcher calls response.flushBuffer() at the end of the 
forward method [1] without checking first if the response has already been 
committed. By this time, the response can be already committed, since dispatch 
is called before this flushBufer() call [2]. The 
SlingHttpServletResponseImpl#flushBuffer can end up calling PrintWriter#flush 
[3], which in case the writer was already closed (happens for example if you 
wrap the writer with the JsonWriter from Johnzon, which is auto-closable), will 
end up throwing the exception with the message provided by Bertrand if the 
initial request was forwarded.

Is there any reason to call flushBuffer in the RequestDispatcher#forward? If 
yes, can’t we first check if the response was committed first 
(response.isComitted())?

Thanks,
Radu

[2] - 
https://github.com/apache/sling-org-apache-sling-engine/blob/8580cf1d5862f2a3b2cbe01c929c4c43cb93d773/src/main/java/org/apache/sling/engine/impl/request/SlingRequestDispatcher.java#L146
 

[3] - 
https://github.com/apache/sling-org-apache-sling-engine/blob/4c7e4149e15567015b1e586b6df617a9af16a6de/src/main/java/org/apache/sling/engine/impl/SlingHttpServletResponseImpl.java#L227
 



> On 5 Jun 2022, at 11:53, Carsten Ziegeler  wrote:
> 
> In general, I think several calls to flushBuffer are totally valid, so even 
> if anyone else called this already in a inner call from forward, this 
> shouldn't be a problem. A rather suspect that the problem is more with 
> duplicate tries to set the headers or something along those lines.
> 
> So I think we should figure out what really is going on before making any 
> changes. It seems there is a scenario which is causing this, so it would be 
> good to convert that into a test.
> 
> Regards
> Carsten
> 
> Am 03.06.2022 um 18:18 schrieb Bertrand Delacretaz:
>> Hi,
>> A colleague mentioned getting "SlingRequestProcessorImpl Writer has
>> already been closed" error messages when using
>> SlingRequestDispatcher.forward(...), and looking at the code [1] I
>> wonder if we should change the request flushing behavior.
>> Unfortunately, unless I missed something that code is not covered by
>> units tests, but I suppose nested calls to
>> SlingRequestDispatcher.forward(...) would cause the problem:
>> SlingRequestDispatcher blindly calls response.flushBuffer(), which
>> causes logged errors if the response Writer is already closed. So if a
>> Servlet that's been forwarded to calls
>> SlingRequestDispatcher.forward(...) I suppose we get this problem.
>> I could write a test to verify all that of course, but maybe someone
>> already has a clear idea on this.
>> Shall we modify that code to check the request status before calling
>> flushBuffer() ? I don't think there's a direct way to check if the
>> Writer is closed already, but maybe there's another call on the
>> request that would check that?
>> -Bertrand
>> [1] 
>> https://github.com/apache/sling-org-apache-sling-engine/blob/631a54f45abf5fd6d7c56dac43fd499db543bcd7/src/main/java/org/apache/sling/engine/impl/request/SlingRequestDispatcher.java#L151
> 
> -- 
> Carsten Ziegeler
> Adobe
> cziege...@apache.org

[jira] [Closed] (SLING-11377) Onboard sling-maven-enforcer-rules to SonarCloud

[Konrad Windszus (Jira)]

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

Konrad Windszus closed SLING-11377.
---

> Onboard sling-maven-enforcer-rules to SonarCloud
> 
>
> Key: SLING-11377
> URL: https://issues.apache.org/jira/browse/SLING-11377
> Project: Sling
>  Issue Type: Task
>  Components: Build and Source Control
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently the SonarQube step fails with
> {code}
> [ERROR] Failed to execute goal 
> org.sonarsource.scanner.maven:sonar-maven-plugin:3.9.1.2184:sonar 
> (default-cli) on project maven-enforcer-rules: Project not found. Please 
> check the 'sonar.projectKey' and 'sonar.organization' properties, the 
> 'SONAR_TOKEN' environment variable, or contact the project administrator -> 
> [Help 1]
> [ERROR] 
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] 
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> {code}



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Resolved] (SLING-11377) Onboard sling-maven-enforcer-rules to SonarCloud

[Konrad Windszus (Jira)]

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

Konrad Windszus resolved SLING-11377.
-
Resolution: Fixed

> Onboard sling-maven-enforcer-rules to SonarCloud
> 
>
> Key: SLING-11377
> URL: https://issues.apache.org/jira/browse/SLING-11377
> Project: Sling
>  Issue Type: Task
>  Components: Build and Source Control
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently the SonarQube step fails with
> {code}
> [ERROR] Failed to execute goal 
> org.sonarsource.scanner.maven:sonar-maven-plugin:3.9.1.2184:sonar 
> (default-cli) on project maven-enforcer-rules: Project not found. Please 
> check the 'sonar.projectKey' and 'sonar.organization' properties, the 
> 'SONAR_TOKEN' environment variable, or contact the project administrator -> 
> [Help 1]
> [ERROR] 
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] 
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> {code}



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (SLING-11377) Onboard sling-maven-enforcer-rules to SonarCloud

[Konrad Windszus (Jira)]

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

Konrad Windszus commented on SLING-11377:
-

[~bellingard] Thank a lot.

> Onboard sling-maven-enforcer-rules to SonarCloud
> 
>
> Key: SLING-11377
> URL: https://issues.apache.org/jira/browse/SLING-11377
> Project: Sling
>  Issue Type: Task
>  Components: Build and Source Control
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently the SonarQube step fails with
> {code}
> [ERROR] Failed to execute goal 
> org.sonarsource.scanner.maven:sonar-maven-plugin:3.9.1.2184:sonar 
> (default-cli) on project maven-enforcer-rules: Project not found. Please 
> check the 'sonar.projectKey' and 'sonar.organization' properties, the 
> 'SONAR_TOKEN' environment variable, or contact the project administrator -> 
> [Help 1]
> [ERROR] 
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] 
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> {code}



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[GitHub] [sling-org-apache-sling-starter] rombert merged pull request #69: Bundle updates

[GitBox]

rombert merged PR #69:
URL: https://github.com/apache/sling-org-apache-sling-starter/pull/69


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [DISCUSS] Running Starter ITs with module builds

[Robert Munteanu]

Hi Eric,

On Mon, 2022-06-13 at 15:05 -0700, Eric Norman wrote:
> Hi Robert,
> 
> For your reference, I stashed a quick demonstration of what I was
> talking
> about in my last reply at9d9b7d5
> <
> https://github.com/enapps-enorman/sling-org-apache-sling-jcr-maintenan
> ce/commit/9d9b7d5d683dc51236e311a0f4641177f6cd7cc2>
> that
> will run the starter-its while using the SNAPSHOT versions of
> the o.a.sling.jcr.maintenance features in the runtime.


Nice, that looks like an improvement over the current PoC.

One thing which I would like to do is avoid the need to have an
additional feature model file which includes the current artifact being
built, since I think that most of the bundles don't need it. We can do
that by adding the 'additionalBundles' configuration to the
slingfeature-maven-plugin

By my count we have 98 Sling bundles included in the Starter and it
looks like a lot of work and duplication to include that file in each
of them.

What we can to support the scenario you mention for org-apache-sling-
jcr-maintenance is to include feature model files from well-known
directories, e.g. src/test/features/starter-its/*.json. That should not
conflict with automatically including the latest version of the bundle,
and would support both scenarios.

Thanks,
Robert

> 
> Regards,
> Eric
> 
> On Mon, Jun 13, 2022 at 12:56 PM Eric Norman 
> wrote:
> 
> > Hi Robert,
> > 
> > Here are my quick thoughts about this.
> > 
> > It seems like this approach would lose the benefits of running the
> > analyse-features goal to find any conflicts that the new SNAPSHOT
> > may have
> > introduced.  The errors from the feature analyzer are more
> > descriptive (and
> > fail faster) than just getting an error that the server timed out
> > after
> > failing to start due to some bundle failing to resolve.
> > 
> > How would you feel about using the slingfeature-maven-plugin to
> > generate a
> > new testing_oak_tar aggregate that includes the starter's oak_tar
> > feature +
> > adds the new SNAPSHOT with an artifactsOverrides configuration to
> > prefer
> > the SNAPSHOT version?  I believe that this approach would not
> > require any
> > changes to the sling-feature-launcher-maven-plugin at all.  Plus
> > this
> > approach should make it possible to override features and
> > configurations as
> > well if any are defined in the project you are testing (for
> > example,
> > the org-apache-sling-jcr-maintenance project)
> > 
> > Regards,
> > -Eric
> > 
> > On Mon, Jun 13, 2022 at 7:41 AM Robert Munteanu
> > 
> > wrote:
> > 
> > > Hi,
> > > 
> > > I think it would be useful to be able to optionally run the
> > > Starter ITs
> > > when building a module that is part of the Sling Starter. This
> > > way we
> > > catch various errors sooner and we can get this feedback as part
> > > of PR
> > > checks.
> > > 
> > > I have written down some notes about how this could work at [0].
> > > I have
> > > also worked on a proof of concept that has two parts:
> > > 
> > > 1. The ability to override the version of an artifact when using
> > > the
> > > feature-launcher-maven-plugin - [1], [2]
> > > 2. A parent pom profile that sets up the Maven executions needed
> > > to run
> > > the ITs with the overridden version of the bundle - [3], [4]
> > > 
> > > With this solution, all that is going to be needed in the end is
> > > to run
> > > 
> > > $ mvn clean verify -Dit.starter.version=13-SNAPSHOT
> > > 
> > > My plan is to merge the needed changes on Friday so I can work on
> > > the
> > > Jenkins part next week and enable it in a couple of sensitive
> > > modules.
> > > 
> > > I don't plan to enable it unconditionally on all modules from the
> > > Starter until:
> > > 
> > > - we have a good understanding of how well this works
> > > - have a solution that does not require touching every module
> > > definition to enable the tests
> > > 
> > > Thoughts?
> > > 
> > > Thanks,
> > > Robert
> > > 
> > > 
> > > [0]:
> > > 
> > > https://cwiki.apache.org/confluence/display/SLING/Running+Sling+Starter+integration+tests+with+module+builds
> > > [1]: https://issues.apache.org/jira/browse/SLING-11387
> > > [2]:
> > > https://github.com/apache/sling-feature-launcher-maven-plugin/pull/8
> > > [3]: https://issues.apache.org/jira/browse/SLING-11395
> > > [4]:
> > > https://github.com/apache/sling-feature-launcher-maven-plugin/pull/8
> > > 
> > 

[jira] [Commented] (SLING-11377) Onboard sling-maven-enforcer-rules to SonarCloud

[Fabrice Bellingard (Jira)]

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

Fabrice Bellingard commented on SLING-11377:


Hi [~kwin], this is done! => 
https://sonarcloud.io/project/overview?id=apache_sling-maven-enforcer-rules

> Onboard sling-maven-enforcer-rules to SonarCloud
> 
>
> Key: SLING-11377
> URL: https://issues.apache.org/jira/browse/SLING-11377
> Project: Sling
>  Issue Type: Task
>  Components: Build and Source Control
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently the SonarQube step fails with
> {code}
> [ERROR] Failed to execute goal 
> org.sonarsource.scanner.maven:sonar-maven-plugin:3.9.1.2184:sonar 
> (default-cli) on project maven-enforcer-rules: Project not found. Please 
> check the 'sonar.projectKey' and 'sonar.organization' properties, the 
> 'SONAR_TOKEN' environment variable, or contact the project administrator -> 
> [Help 1]
> [ERROR] 
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] 
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> {code}



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Resolved] (SLING-11380) Update parent bundle (48) to sling-jmx-provider

[Ashok Pelluru (Jira)]

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

Ashok Pelluru resolved SLING-11380.
---
Resolution: Fixed

> Update parent bundle (48) to sling-jmx-provider
> ---
>
> Key: SLING-11380
> URL: https://issues.apache.org/jira/browse/SLING-11380
> Project: Sling
>  Issue Type: Sub-task
>Reporter: Ashok Pelluru
>Assignee: Ashok Pelluru
>Priority: Major
> Fix For: JMX Resource Provider 1.0.4
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (SLING-11384) Repoinitparserservice - create path on root level doesn't parse node type

[Angela Schreiber (Jira)]

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

Angela Schreiber commented on SLING-11384:
--

hi [~cziegeler], [~Sc0rpic0m], [~rombert], would it be possible to adjust the 
test case a bit as it is quite confusing.

- repoinit "create path xyz" _does not_ allow you to set the sling:resourceType 
property as was implied by the original summary
- sling:resourceType property would need to be modified through 'set properties'
- afaik _sling:redirect_ is not a valid primary type but rather a resource type 
and an attempt to use it in create path will fail with NoSuchNodeTypeException
- since repoinit tests are used to generate the documentation i would prefer if 
there no misleading examples in there.

wdyt?

> Repoinitparserservice - create path on root level doesn't parse node type
> -
>
> Key: SLING-11384
> URL: https://issues.apache.org/jira/browse/SLING-11384
> Project: Sling
>  Issue Type: Bug
>  Components: Repoinit
>Reporter: Niek Raaijmakers
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: Repoinit Parser 1.6.16
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> When calling the repoinitparserservice as follows:
> {code:java}
> repoInitParserService.parse(new StringReader("create path 
> /(sling:redirect)\n")).get(0).asRepoInitString()  {code}
> The result is:
> {code:java}
> create path \n {code}
> What we expect is:
> {code:java}
> create path /(sling:redirect)\n {code}
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[GitHub] [sling-org-apache-sling-jmx-provider] ashokmca07 merged pull request #1: SLING-11380: Upgrade to sling 47

[GitBox]

ashokmca07 merged PR #1:
URL: https://github.com/apache/sling-org-apache-sling-jmx-provider/pull/1


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org