Re: [VOTE] Release Apache Sling Scripting HTL Engine 1.4.6-1.4.0, Apache Sling Scripting HTL Compiler 1.2.12-1.4.0, Apache Sling Scripting HTL Testing Content 1.0.26-1.4.0, Apache Sling Scripting HTL
+1 On Fri, Oct 23, 2020 at 3:39 PM Radu Cotescu wrote: > Hi, > > We solved 3 issues in these releases: > https://issues.apache.org/jira/browse/SLING/fixforversion/12349307 > https://issues.apache.org/jira/browse/SLING/fixforversion/12349277 > https://issues.apache.org/jira/browse/SLING/fixforversion/12349303 > https://issues.apache.org/jira/browse/SLING/fixforversion/12349302 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-2363/ > > You can use this UNIX script to download the release and verify the > signatures: > > https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD > > Usage: > sh check_staged_release.sh 2363 /tmp/sling-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > This majority vote is open for at least 72 hours. > > Regards, > Radu Cotescu >
[jira] [Closed] (SLING-9834) [Sling Models] Caching bug with reused Servlet requests
[ https://issues.apache.org/jira/browse/SLING-9834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu closed SLING-9834. --- > [Sling Models] Caching bug with reused Servlet requests > --- > > Key: SLING-9834 > URL: https://issues.apache.org/jira/browse/SLING-9834 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: Sling Models Impl 1.4.14 >Reporter: Christophe Jelger >Assignee: Radu Cotescu >Priority: Major > Fix For: Models Implementation 1.4.16 > > Time Spent: 3h > Remaining Estimate: 0h > > The fix from https://issues.apache.org/jira/browse/SLING-9781 introduces > another unexpected issue because a container like Jetty may reuse > ServletRequest objects, so this means that Sling models might be cached > across different HTTP requests because of the unwrapping introduced by > SLING-9781. > After a quick discussion with [~cziegeler] and [~justin], it is actually best > to use the ServletRequest attributes to store the cached models and avoid any > unwrapping. > I'll provide a PR with a fix. > cc: [~radu] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SLING-9842) Upgrade to parent pom 40
[ https://issues.apache.org/jira/browse/SLING-9842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu closed SLING-9842. --- > Upgrade to parent pom 40 > > > Key: SLING-9842 > URL: https://issues.apache.org/jira/browse/SLING-9842 > Project: Sling > Issue Type: Improvement > Components: Sling Models >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: Models Implementation 1.4.16 > > > Sling Models Impl still uses version 35 of the parent pom. We should update > to version 40 to reduce migration efforts in the future. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[RESULT] [VOTE] Release Apache Sling Models Implementation 1.4.16
Hi, The vote has passed with the following result: +1 (binding): Dan Klco, Carsten Ziegeler, Robert Munteanu, Karl Pauls +1 (non-binding): none I will copy this release to the Sling dist directory and promote the artifacts to the central Maven repository. Regards, Radu Cotescu
[VOTE] Release Apache Sling Scripting HTL Engine 1.4.6-1.4.0, Apache Sling Scripting HTL Compiler 1.2.12-1.4.0, Apache Sling Scripting HTL Testing Content 1.0.26-1.4.0, Apache Sling Scripting HTL Test
Hi, We solved 3 issues in these releases: https://issues.apache.org/jira/browse/SLING/fixforversion/12349307 https://issues.apache.org/jira/browse/SLING/fixforversion/12349277 https://issues.apache.org/jira/browse/SLING/fixforversion/12349303 https://issues.apache.org/jira/browse/SLING/fixforversion/12349302 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2363/ You can use this UNIX script to download the release and verify the signatures: https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD Usage: sh check_staged_release.sh 2363 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Regards, Radu Cotescu
[jira] [Resolved] (SLING-9854) Formatting string is removed when no formatting type is provided
[
https://issues.apache.org/jira/browse/SLING-9854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-9854.
-
Resolution: Fixed
Fixed in:
# [commit
fb383bd|https://github.com/apache/sling-org-apache-sling-scripting-sightly/commit/fb383bd]
# [commit
3ad77d6|https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content/commit/3ad77d6]
# [commit
2ab44e3|https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing/commit/2ab44e3]
> Formatting string is removed when no formatting type is provided
>
>
> Key: SLING-9854
> URL: https://issues.apache.org/jira/browse/SLING-9854
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting HTL Engine 1.0.34, Scripting HTL Engine
> 1.1.0-1.4.0, Scripting HTL Engine 1.2.0-1.4.0, Scripting HTL Engine
> 1.3.0-1.4.0, Scripting HTL Engine 1.4.0-1.4.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting HTL Engine 1.4.6-1.4.0
>
>
> The HTL expression
> {code}
> ${'hello, world' @ format=''}
> {code}
> renders nothing, despite the fact that the specification mentions the
> following \[0\]:
> {quote}
> Type of formatting will be decided based on:
> * the type option, if present (accepted values are string, date and number)
> * placeholders (eg: \{0\}) in the pattern, triggers string formatting
> * type of format option object, when the type is a Date or a Number
> * default, fallback to string formatting
> {quote}
> \[0\] - https://github.com/adobe/htl-spec/blob/1.4/SPECIFICATION.md#122-format
--
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] [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 Tuicu updated SLING-9855: Description: 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] was: 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 > 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 >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] [Created] (SLING-9855) Invalidate login token when receiving 401
Andrei Tuicu created SLING-9855: --- Summary: 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 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 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-9848) The ArtifactManager should handle SNAPSHOT dependencies exactly like Maven
[
https://issues.apache.org/jira/browse/SLING-9848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219724#comment-17219724
]
Karl Pauls commented on SLING-9848:
---
The problem is that we use "SNAPSHOT" as the key to start looking for a
snapshot. Apparently, maven does look at the meta-data first to see if the
given version is a snapshot by chance. If it is, it changes the directory it is
in from the version to "SNAPSHOT". Strange, yes, but that is apparently what
maven is doing...
> The ArtifactManager should handle SNAPSHOT dependencies exactly like Maven
> --
>
> Key: SLING-9848
> URL: https://issues.apache.org/jira/browse/SLING-9848
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model
>Affects Versions: Feature Model 1.2.10
>Reporter: Radu Cotescu
>Priority: Major
>
> When a feature provides a SNAPSHOT dependency by using the artifact's
> specific version generated by Nexus (e.g. 1.0.0-SNAPSHOT ->
> 1.0.0-20201021.121222-1), then the {{ArtifactManager}} fails to correctly
> find the dependency.
> Assuming a definition like:
> {code}
> {
> "id":"org.myorg:mybundle:1.0.0-20201021.121222-1",
> "start-order":"20"
> }
> {code}
> Maven would download / solve
> {{org/myorg/mybundle/1.0.0-SNAPSHOT/mybundle-1.0.0-20201021.121222-1.jar}},
> whereas the {{ArtifactManager}} would try to download / solve
> {{org/myorg/mybundle/1.0.0-20201021.121222-1/mybundle-1.0.0-20201021.121222-1.jar}}.
> IMO, when working with Maven Repositories / Artifacts, the
> {{ArtifactManager}} should use Maven components for correctly resolving the
> artifacts the same way Maven would.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-9848) The ArtifactManager should handle SNAPSHOT dependencies exactly like Maven
[
https://issues.apache.org/jira/browse/SLING-9848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219716#comment-17219716
]
Carsten Ziegeler commented on SLING-9848:
-
I think having a dependency to a maven artifact which then drags in more
dependencies is something we must avoid. ArtifactManager already executes the
"mvn" command for downloading dependencies. I'm wondering why this one does not
work
> The ArtifactManager should handle SNAPSHOT dependencies exactly like Maven
> --
>
> Key: SLING-9848
> URL: https://issues.apache.org/jira/browse/SLING-9848
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model
>Affects Versions: Feature Model 1.2.10
>Reporter: Radu Cotescu
>Priority: Major
>
> When a feature provides a SNAPSHOT dependency by using the artifact's
> specific version generated by Nexus (e.g. 1.0.0-SNAPSHOT ->
> 1.0.0-20201021.121222-1), then the {{ArtifactManager}} fails to correctly
> find the dependency.
> Assuming a definition like:
> {code}
> {
> "id":"org.myorg:mybundle:1.0.0-20201021.121222-1",
> "start-order":"20"
> }
> {code}
> Maven would download / solve
> {{org/myorg/mybundle/1.0.0-SNAPSHOT/mybundle-1.0.0-20201021.121222-1.jar}},
> whereas the {{ArtifactManager}} would try to download / solve
> {{org/myorg/mybundle/1.0.0-20201021.121222-1/mybundle-1.0.0-20201021.121222-1.jar}}.
> IMO, when working with Maven Repositories / Artifacts, the
> {{ArtifactManager}} should use Maven components for correctly resolving the
> artifacts the same way Maven would.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-9850) Clarify null return values for ResourceResolver.map(...)
[
https://issues.apache.org/jira/browse/SLING-9850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219694#comment-17219694
]
Konrad Windszus commented on SLING-9850:
I think we should mark both as {{@NotNull}} and clarify that in the javadocs as
well. As fallback you always get back the original passed String (no matter if
it starts with "/" or even a scheme). The implementation seems to be in line
with this. WDYT?
> Clarify null return values for ResourceResolver.map(...)
>
>
> Key: SLING-9850
> URL: https://issues.apache.org/jira/browse/SLING-9850
> Project: Sling
> Issue Type: Improvement
> Components: API
>Affects Versions: API 2.23.0
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently the two signatures of {{map}} differ by their null return
> annotation:
> -
> https://github.com/apache/sling-org-apache-sling-api/blob/3e9cf187eff999235ee161e0543f1d8a68c4285c/src/main/java/org/apache/sling/api/resource/ResourceResolver.java#L294
> (must not return null)
> and
> -
> https://github.com/apache/sling-org-apache-sling-api/blob/3e9cf187eff999235ee161e0543f1d8a68c4285c/src/main/java/org/apache/sling/api/resource/ResourceResolver.java#L332
> (may return null)
> The implementation of both may return null though in fact, IIU
> https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/657055bcb31059dc7b71cde55941fb2050cbaddb/src/main/java/org/apache/sling/resourceresolver/impl/ResourceResolverImpl.java#L40,
>
> https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/657055bcb31059dc7b71cde55941fb2050cbaddb/src/main/java/org/apache/sling/resourceresolver/impl/ResourceResolverImpl.java#L420
> and
> https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/657055bcb31059dc7b71cde55941fb2050cbaddb/src/main/java/org/apache/sling/resourceresolver/impl/mapping/ResourceMapperImpl.java#L75
> correctly.
> The javadoc for both methods should be clarified with regards to when to
> expect a null value and most probably the null annotations need to be fixed
> as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [sling-org-apache-sling-testing-clients] andreituicu opened a new pull request #19: In case the logintoken cookie is no longer valid, try obtaining a new one.
andreituicu opened a new pull request #19: URL: https://github.com/apache/sling-org-apache-sling-testing-clients/pull/19 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (SLING-9854) Formatting string is removed when no formatting type is provided
Radu Cotescu created SLING-9854:
---
Summary: Formatting string is removed when no formatting type is
provided
Key: SLING-9854
URL: https://issues.apache.org/jira/browse/SLING-9854
Project: Sling
Issue Type: Bug
Components: Scripting
Affects Versions: Scripting HTL Engine 1.4.0-1.4.0, Scripting HTL Engine
1.3.0-1.4.0, Scripting HTL Engine 1.2.0-1.4.0, Scripting HTL Engine
1.1.0-1.4.0, Scripting HTL Engine 1.0.34
Reporter: Radu Cotescu
Assignee: Radu Cotescu
Fix For: Scripting HTL Engine 1.4.6-1.4.0
The HTL expression
{code}
${'hello, world' @ format=''}
{code}
renders nothing, despite the fact that the specification mentions the following
\[0\]:
{quote}
Type of formatting will be decided based on:
* the type option, if present (accepted values are string, date and number)
* placeholders (eg: \{0\}) in the pattern, triggers string formatting
* type of format option object, when the type is a Date or a Number
* default, fallback to string formatting
{quote}
\[0\] - https://github.com/adobe/htl-spec/blob/1.4/SPECIFICATION.md#122-format
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [VOTE] Release of Apache Sling Kickstart Project 0.0.12
On Thu, 2020-10-22 at 18:16 -0700, Andreas Schaefer wrote: > Please vote to approve this release: +1 Note that the CI checks are still failing due to SonarQube problems [0]. It would be good to look into that, after the release. Thanks, Robert [0]: https://ci-builds.apache.org/blue/organizations/jenkins/Sling%2Fmodules%2Fsling-org-apache-sling-kickstart/detail/master/29/pipeline/33 signature.asc Description: This is a digitally signed message part
[jira] [Commented] (SLING-9850) Clarify null return values for ResourceResolver.map(...)
[
https://issues.apache.org/jira/browse/SLING-9850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219639#comment-17219639
]
Robert Munteanu commented on SLING-9850:
[~kwin] - I agree, both should be {{@Nullable}} by looking at the code. That
being said, I'm not sure how we can not have at least one mapping, looking at
https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/657055bcb31059dc7b71cde55941fb2050cbaddb/src/main/java/org/apache/sling/resourceresolver/impl/mapping/ResourceMapperImpl.java#L125-L143
.
> Clarify null return values for ResourceResolver.map(...)
>
>
> Key: SLING-9850
> URL: https://issues.apache.org/jira/browse/SLING-9850
> Project: Sling
> Issue Type: Improvement
> Components: API
>Affects Versions: API 2.23.0
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently the two signatures of {{map}} differ by their null return
> annotation:
> -
> https://github.com/apache/sling-org-apache-sling-api/blob/3e9cf187eff999235ee161e0543f1d8a68c4285c/src/main/java/org/apache/sling/api/resource/ResourceResolver.java#L294
> (must not return null)
> and
> -
> https://github.com/apache/sling-org-apache-sling-api/blob/3e9cf187eff999235ee161e0543f1d8a68c4285c/src/main/java/org/apache/sling/api/resource/ResourceResolver.java#L332
> (may return null)
> The implementation of both may return null though in fact, IIU
> https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/657055bcb31059dc7b71cde55941fb2050cbaddb/src/main/java/org/apache/sling/resourceresolver/impl/ResourceResolverImpl.java#L40,
>
> https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/657055bcb31059dc7b71cde55941fb2050cbaddb/src/main/java/org/apache/sling/resourceresolver/impl/ResourceResolverImpl.java#L420
> and
> https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/657055bcb31059dc7b71cde55941fb2050cbaddb/src/main/java/org/apache/sling/resourceresolver/impl/mapping/ResourceMapperImpl.java#L75
> correctly.
> The javadoc for both methods should be clarified with regards to when to
> expect a null value and most probably the null annotations need to be fixed
> as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-9848) The ArtifactManager should handle SNAPSHOT dependencies exactly like Maven
[
https://issues.apache.org/jira/browse/SLING-9848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219629#comment-17219629
]
Radu Cotescu commented on SLING-9848:
-
I didn't debug the code, so I'm not sure if the issue is in the
{{ArtifactManager}} or in the {{ArtifactId#toMvnPath}} implementation, though
somehow I suspect the former. The question is, couldn't we delegate to Eclipse
Aether for any Maven repository call? I know we'd add a dependency to the Sling
Feature code, but we'd rely on the exact same code Maven is using.
> The ArtifactManager should handle SNAPSHOT dependencies exactly like Maven
> --
>
> Key: SLING-9848
> URL: https://issues.apache.org/jira/browse/SLING-9848
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model
>Affects Versions: Feature Model 1.2.10
>Reporter: Radu Cotescu
>Priority: Major
>
> When a feature provides a SNAPSHOT dependency by using the artifact's
> specific version generated by Nexus (e.g. 1.0.0-SNAPSHOT ->
> 1.0.0-20201021.121222-1), then the {{ArtifactManager}} fails to correctly
> find the dependency.
> Assuming a definition like:
> {code}
> {
> "id":"org.myorg:mybundle:1.0.0-20201021.121222-1",
> "start-order":"20"
> }
> {code}
> Maven would download / solve
> {{org/myorg/mybundle/1.0.0-SNAPSHOT/mybundle-1.0.0-20201021.121222-1.jar}},
> whereas the {{ArtifactManager}} would try to download / solve
> {{org/myorg/mybundle/1.0.0-20201021.121222-1/mybundle-1.0.0-20201021.121222-1.jar}}.
> IMO, when working with Maven Repositories / Artifacts, the
> {{ArtifactManager}} should use Maven components for correctly resolving the
> artifacts the same way Maven would.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SLING-9853) JcrInstaller - running watch cycle message to trace level
Rafał Cabaj created SLING-9853:
--
Summary: JcrInstaller - running watch cycle message to trace level
Key: SLING-9853
URL: https://issues.apache.org/jira/browse/SLING-9853
Project: Sling
Issue Type: Improvement
Affects Versions: JCR Installer 3.1.26
Reporter: Rafał Cabaj
During listening JcrInstaller class the log files are filling up quickly. It's
because it put the entry every 500 ms
{noformat}
23.10.2020 12:02:56.913 *DEBUG* [JcrInstaller.1]
org.apache.sling.installer.provider.jcr.impl.JcrInstaller Running watch cycle.
{noformat}
To avoid that and still be able to track what's happening there it'd be nice
to change it to TRACE.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
