[jira] [Updated] (SLING-12365) Support for new servlet containers in Sling launchpad
[ https://issues.apache.org/jira/browse/SLING-12365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sagar Miglani updated SLING-12365: -- Description: Sling Launchpad Base currently does not support the latest servlet API containers (Jakarta Servlet API 5/6). Given that these are new standards, we should update its codebase to ensure compatibility with these new containers. (was: The Sling Launchpad currently does not support the latest servlet API containers (Jakarta Servlet API 5/6). Given that these are new standards, we should update its codebase to ensure compatibility with these new containers.) > Support for new servlet containers in Sling launchpad > - > > Key: SLING-12365 > URL: https://issues.apache.org/jira/browse/SLING-12365 > Project: Sling > Issue Type: Improvement > Components: Launchpad >Affects Versions: Launchpad Base 2.7.8 >Reporter: Sagar Miglani >Priority: Major > > Sling Launchpad Base currently does not support the latest servlet API > containers (Jakarta Servlet API 5/6). Given that these are new standards, we > should update its codebase to ensure compatibility with these new containers. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12365) Support for new servlet containers in Sling launchpad
Sagar Miglani created SLING-12365: - Summary: Support for new servlet containers in Sling launchpad Key: SLING-12365 URL: https://issues.apache.org/jira/browse/SLING-12365 Project: Sling Issue Type: Improvement Components: Launchpad Affects Versions: Launchpad Base 2.7.8 Reporter: Sagar Miglani The Sling Launchpad currently does not support the latest servlet API containers (Jakarta Servlet API 5/6). Given that these are new standards, we should update its codebase to ensure compatibility with these new containers. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12124) Inconsistent handling of empty selectors
[ https://issues.apache.org/jira/browse/SLING-12124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17781586#comment-17781586 ] Sagar Miglani commented on SLING-12124: --- Initial PR: [https://github.com/apache/sling-org-apache-sling-engine/pull/40] cc: [~cziegeler] > Inconsistent handling of empty selectors > > > Key: SLING-12124 > URL: https://issues.apache.org/jira/browse/SLING-12124 > Project: Sling > Issue Type: Bug > Components: Engine >Affects Versions: Engine 2.15.6 >Reporter: Sagar Miglani >Priority: Major > Attachments: inconsistent_empty_selectors.patch > > > In accordance with the code found > [here|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/RequestData.java#L563], > empty selectors are explicitly disallowed. However, the [parsing of > selectors|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/SlingRequestPathInfo.java#L93-L95] > is making request with all empty selector as valid. > i.e: > Requests will empty selectors like: "/test/resource/path..a...html" are > invalid > While requests with all empty selectos "/test/resource/path.html" are > valid > Which indicates an inconsistent behaviour. > Attached tests to demonstrate the same ([^inconsistent_empty_selectors.patch]) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12124) Inconsistent handling of empty selectors
[ https://issues.apache.org/jira/browse/SLING-12124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sagar Miglani updated SLING-12124: -- Summary: Inconsistent handling of empty selectors (was: Inconsistent handling of emtpy selectors) > Inconsistent handling of empty selectors > > > Key: SLING-12124 > URL: https://issues.apache.org/jira/browse/SLING-12124 > Project: Sling > Issue Type: Bug > Components: Engine >Affects Versions: Engine 2.15.6 >Reporter: Sagar Miglani >Priority: Major > Attachments: inconsistent_empty_selectors.patch > > > In accordance with the code found > [here|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/RequestData.java#L563], > empty selectors are explicitly disallowed. However, the [parsing of > selectors|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/SlingRequestPathInfo.java#L93-L95] > is making request with all empty selector as valid. > i.e: > Requests will empty selectors like: "/test/resource/path..a...html" are > invalid > While requests with all empty selectos "/test/resource/path.html" are > valid > Which indicates an inconsistent behaviour. > Attached tests to demonstrate the same ([^inconsistent_empty_selectors.patch]) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12124) Inconsistent handling of emtpy selectors
[ https://issues.apache.org/jira/browse/SLING-12124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sagar Miglani updated SLING-12124: -- Description: In accordance with the code found [here|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/RequestData.java#L563], empty selectors are explicitly disallowed. However, the [parsing of selectors|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/SlingRequestPathInfo.java#L93-L95] is making request with all empty selector as valid. i.e: Requests will empty selectors like: "/test/resource/path..a...html" are invalid While requests with all empty selectos "/test/resource/path.html" are valid Which indicates an inconsistent behaviour. Attached tests to demonstrate the same ([^inconsistent_empty_selectors.patch]) was: In accordance with the code found [here|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/RequestData.java#L563], empty selectors are explicitly disallowed. However, the [parsing of selectors|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/SlingRequestPathInfo.java#L93-L95] is making request with all empty selector as valid. i.e: Requests will empty selectors like: "/test/resource/path..a...html" are invalid While requests with all empty selectos "/test/resource/path.html" are valid Which indicates an inconsistent behaviour. Attached tests to demonstrate the same () > Inconsistent handling of emtpy selectors > > > Key: SLING-12124 > URL: https://issues.apache.org/jira/browse/SLING-12124 > Project: Sling > Issue Type: Bug > Components: Engine >Affects Versions: Engine 2.15.6 >Reporter: Sagar Miglani >Priority: Major > Attachments: inconsistent_empty_selectors.patch > > > In accordance with the code found > [here|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/RequestData.java#L563], > empty selectors are explicitly disallowed. However, the [parsing of > selectors|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/SlingRequestPathInfo.java#L93-L95] > is making request with all empty selector as valid. > i.e: > Requests will empty selectors like: "/test/resource/path..a...html" are > invalid > While requests with all empty selectos "/test/resource/path.html" are > valid > Which indicates an inconsistent behaviour. > Attached tests to demonstrate the same ([^inconsistent_empty_selectors.patch]) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12124) Inconsistent handling of emtpy selectors
[ https://issues.apache.org/jira/browse/SLING-12124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sagar Miglani updated SLING-12124: -- Attachment: inconsistent_empty_selectors.patch > Inconsistent handling of emtpy selectors > > > Key: SLING-12124 > URL: https://issues.apache.org/jira/browse/SLING-12124 > Project: Sling > Issue Type: Bug > Components: Engine >Affects Versions: Engine 2.15.6 >Reporter: Sagar Miglani >Priority: Major > Attachments: inconsistent_empty_selectors.patch > > > In accordance with the code found > [here|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/RequestData.java#L563], > empty selectors are explicitly disallowed. However, the [parsing of > selectors|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/SlingRequestPathInfo.java#L93-L95] > is making request with all empty selector as valid. > i.e: > Requests will empty selectors like: "/test/resource/path..a...html" are > invalid > While requests with all empty selectos "/test/resource/path.html" are > valid > Which indicates an inconsistent behaviour. > Attached tests to demonstrate the same () -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12124) Inconsistent handling of emtpy selectors
[ https://issues.apache.org/jira/browse/SLING-12124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sagar Miglani updated SLING-12124: -- Attachment: (was: inconsistent_emtpy_selectors.patch) > Inconsistent handling of emtpy selectors > > > Key: SLING-12124 > URL: https://issues.apache.org/jira/browse/SLING-12124 > Project: Sling > Issue Type: Bug > Components: Engine >Affects Versions: Engine 2.15.6 >Reporter: Sagar Miglani >Priority: Major > > In accordance with the code found > [here|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/RequestData.java#L563], > empty selectors are explicitly disallowed. However, the [parsing of > selectors|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/SlingRequestPathInfo.java#L93-L95] > is making request with all empty selector as valid. > i.e: > Requests will empty selectors like: "/test/resource/path..a...html" are > invalid > While requests with all empty selectos "/test/resource/path.html" are > valid > Which indicates an inconsistent behaviour. > Attached tests to demonstrate the same () -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12124) Inconsistent handling of emtpy selectors
[ https://issues.apache.org/jira/browse/SLING-12124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sagar Miglani updated SLING-12124: -- Description: In accordance with the code found [here|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/RequestData.java#L563], empty selectors are explicitly disallowed. However, the [parsing of selectors|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/SlingRequestPathInfo.java#L93-L95] is making request with all empty selector as valid. i.e: Requests will empty selectors like: "/test/resource/path..a...html" are invalid While requests with all empty selectos "/test/resource/path.html" are valid Which indicates an inconsistent behaviour. Attached tests to demonstrate the same () was: In accordance with the code found [here|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/RequestData.java#L563], empty selectors are explicitly disallowed. However, the [parsing of selectors|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/SlingRequestPathInfo.java#L93-L95] is making request with all empty selector as valid. i.e: Requests will emtpy selectors like: "/test/resource/path..a...html" are invalid While requests with all empty selectos "/test/resource/path.html" are valid Which indicates an inconsistent behaviour. Attached tests to demonstrate the same ([^inconsistent_emtpy_selectors.patch]) > Inconsistent handling of emtpy selectors > > > Key: SLING-12124 > URL: https://issues.apache.org/jira/browse/SLING-12124 > Project: Sling > Issue Type: Bug > Components: Engine >Affects Versions: Engine 2.15.6 >Reporter: Sagar Miglani >Priority: Major > > In accordance with the code found > [here|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/RequestData.java#L563], > empty selectors are explicitly disallowed. However, the [parsing of > selectors|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/SlingRequestPathInfo.java#L93-L95] > is making request with all empty selector as valid. > i.e: > Requests will empty selectors like: "/test/resource/path..a...html" are > invalid > While requests with all empty selectos "/test/resource/path.html" are > valid > Which indicates an inconsistent behaviour. > Attached tests to demonstrate the same () -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12124) Inconsistent handling of emtpy selectors
Sagar Miglani created SLING-12124: - Summary: Inconsistent handling of emtpy selectors Key: SLING-12124 URL: https://issues.apache.org/jira/browse/SLING-12124 Project: Sling Issue Type: Bug Components: Engine Affects Versions: Engine 2.15.6 Reporter: Sagar Miglani Attachments: inconsistent_emtpy_selectors.patch In accordance with the code found [here|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/RequestData.java#L563], empty selectors are explicitly disallowed. However, the [parsing of selectors|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/SlingRequestPathInfo.java#L93-L95] is making request with all empty selector as valid. i.e: Requests will emtpy selectors like: "/test/resource/path..a...html" are invalid While requests with all empty selectos "/test/resource/path.html" are valid Which indicates an inconsistent behaviour. Attached tests to demonstrate the same ([^inconsistent_emtpy_selectors.patch]) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-11912) Empty configuration in ServiceUserMapperImpl's Required Principal/User validators results in 503
Sagar Miglani created SLING-11912:
-
Summary: Empty configuration in ServiceUserMapperImpl's Required
Principal/User validators results in 503
Key: SLING-11912
URL: https://issues.apache.org/jira/browse/SLING-11912
Project: Sling
Issue Type: Bug
Components: Service User Mapper
Affects Versions: Service User Mapper 1.5.6
Reporter: Sagar Miglani
1) In webconsole configuration manager, open {{Apache Sling Service User Mapper
Serviceorg.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl}}
2) Before making any change the configuration is:
{code:xml}
:org.apache.felix.configadmin.revision:=L"1"
require.validation=B"true"
service.pid="org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl"
user.enable.default.mapping=B"false"
{code}
3) Without changing the configuration click on {{save}}, the configuration
becomes:
{code:xml}
:org.apache.felix.configadmin.revision:=L"8"
require.validation=B"true"
required.principal.validators=[ \
"", \
]
required.user.validators=[ \
"", \
]
service.pid="org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl"
user.default=""
user.enable.default.mapping=B"false"
{code}
i.e {{required.principal.validators}} and {{required.user.validators}} have an
empty value and due to this all sling requests return
{code:xml}
"HTTP ERROR 503 ServletResolver service missing, cannot service requests".
{code}
This persistence of empty configuration seems to be behaviour of
{{felix.webconsole}}. But IMO sling requests should not fail due to empty
values.
(The above scenario was reproduced in an AEM instance)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-11861) ResourceMapper.getAllMappings returns empty mapping "" when a vanity paths is pathless url
[
https://issues.apache.org/jira/browse/SLING-11861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sagar Miglani resolved SLING-11861.
---
Resolution: Won't Fix
Marking this as won't fix, as suggestion here and in PR is to handle it at
caller's side instead of changing the ResouceMapper's behaviour which might
have unknown outcomes and is risky to change.
Created SLING-11867 to handle this on Sling auth core side
cc: [~reschke] [~cziegeler]
> ResourceMapper.getAllMappings returns empty mapping "" when a vanity paths
> is pathless url
> ---
>
> Key: SLING-11861
> URL: https://issues.apache.org/jira/browse/SLING-11861
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Affects Versions: Resource Resolver 1.10.0
>Reporter: Sagar Miglani
>Priority: Major
>
> When a resource has a path less url as vanity path (eg:
> "http://www.example.com";) ResourceMapper.getAllMappings returns mappings
> consisting of an empty path "".
> This "" mapping can make {{AuthenticationRequirementsManager}} stop listening
> to further authentication requirements [0]:
> {code:xml}
> Exception in thread "pool-14-thread-1" java.lang.IllegalArgumentException:
> Configuration must not be null or empty
> at
> org.apache.sling.auth.core.impl.AuthenticationRequirementHolder.fromConfig(AuthenticationRequirementHolder.java:30)
> at
> org.apache.sling.auth.core.impl.AuthenticationRequirementsManager.addService(AuthenticationRequirementsManager.java:374)
> at
> org.apache.sling.auth.core.impl.AuthenticationRequirementsManager.process(AuthenticationRequirementsManager.java:300)
> at
> org.apache.sling.auth.core.impl.AuthenticationRequirementsManager.processQueue(AuthenticationRequirementsManager.java:281)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
> Clarification required:
> - Is "" mapping/path a valid path? Should we store and return vanity path as
> "/" in case of pathless url as vanity path?
> cc: [~cziegeler] [~rombert] [~reschke]
> [0]:
> https://github.com/apache/sling-org-apache-sling-auth-core/blob/org.apache.sling.auth.core-1.5.0/src/main/java/org/apache/sling/auth/core/impl/SlingAuthenticatorServiceListener.java#L345-L351
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-11867) Empty mapping from ResourceMapper breaks authentication requirement updates
Sagar Miglani created SLING-11867:
-
Summary: Empty mapping from ResourceMapper breaks authentication
requirement updates
Key: SLING-11867
URL: https://issues.apache.org/jira/browse/SLING-11867
Project: Sling
Issue Type: Bug
Components: Authentication
Affects Versions: Auth Core 1.6.0
Reporter: Sagar Miglani
When a resource has a path less url as vanity path (eg:
"http://www.example.com";) ResourceMapper.getAllMappings returns mappings
consisting of an empty path "".
This "" mapping can make {{AuthenticationRequirementsManager}} stop listening
to further authentication requirements [0]:
{code:xml}
Exception in thread "pool-14-thread-1" java.lang.IllegalArgumentException:
Configuration must not be null or empty
at
org.apache.sling.auth.core.impl.AuthenticationRequirementHolder.fromConfig(AuthenticationRequirementHolder.java:30)
at
org.apache.sling.auth.core.impl.AuthenticationRequirementsManager.addService(AuthenticationRequirementsManager.java:374)
at
org.apache.sling.auth.core.impl.AuthenticationRequirementsManager.process(AuthenticationRequirementsManager.java:300)
at
org.apache.sling.auth.core.impl.AuthenticationRequirementsManager.processQueue(AuthenticationRequirementsManager.java:281)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
{code}
In SLING-11861 and [0], it was suggested to make changes in caller's code
instead of changing the behaviour of ResoucreMapper.
[0]: https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/96
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-11861) ResourceMapper.getAllMappings returns empty mapping "" when a vanity paths is pathless url
[
https://issues.apache.org/jira/browse/SLING-11861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sagar Miglani updated SLING-11861:
--
Description:
When a resource has a path less url as vanity path (eg:
"http://www.example.com";) ResourceMapper.getAllMappings returns mappings
consisting of an empty path "".
This "" mapping can make {{AuthenticationRequirementsManager}} stop listening
to further authentication requirements [0]:
{code:xml}
Exception in thread "pool-14-thread-1" java.lang.IllegalArgumentException:
Configuration must not be null or empty
at
org.apache.sling.auth.core.impl.AuthenticationRequirementHolder.fromConfig(AuthenticationRequirementHolder.java:30)
at
org.apache.sling.auth.core.impl.AuthenticationRequirementsManager.addService(AuthenticationRequirementsManager.java:374)
at
org.apache.sling.auth.core.impl.AuthenticationRequirementsManager.process(AuthenticationRequirementsManager.java:300)
at
org.apache.sling.auth.core.impl.AuthenticationRequirementsManager.processQueue(AuthenticationRequirementsManager.java:281)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
{code}
Clarification required:
- Is "" mapping/path a valid path? Should we store and return vanity path as
"/" in case of pathless url as vanity path?
cc: [~cziegeler] [~rombert] [~reschke]
[0]:
https://github.com/apache/sling-org-apache-sling-auth-core/blob/org.apache.sling.auth.core-1.5.0/src/main/java/org/apache/sling/auth/core/impl/SlingAuthenticatorServiceListener.java#L345-L351
was:
When a resource has a path less url as vanity path (eg:
"http://www.example.com";) ResourceMapper.getAllMappings returns mappings
consisting of an empty path "".
This "" mapping can make {{SlingAuthenticatorServiceListener}} stop listening
to further authentication requirements [0]:
{code:xml}
Exception in thread "pool-14-thread-1" java.lang.IllegalArgumentException:
Configuration must not be null or empty
at
org.apache.sling.auth.core.impl.AuthenticationRequirementHolder.fromConfig(AuthenticationRequirementHolder.java:30)
at
org.apache.sling.auth.core.impl.AuthenticationRequirementsManager.addService(AuthenticationRequirementsManager.java:374)
at
org.apache.sling.auth.core.impl.AuthenticationRequirementsManager.process(AuthenticationRequirementsManager.java:300)
at
org.apache.sling.auth.core.impl.AuthenticationRequirementsManager.processQueue(AuthenticationRequirementsManager.java:281)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
{code}
Clarification required:
- Is "" mapping/path a valid path? Should we store and return vanity path as
"/" in case of pathless url as vanity path?
cc: [~cziegeler] [~rombert] [~reschke]
[0]:
https://github.com/apache/sling-org-apache-sling-auth-core/blob/org.apache.sling.auth.core-1.5.0/src/main/java/org/apache/sling/auth/core/impl/SlingAuthenticatorServiceListener.java#L345-L351
> ResourceMapper.getAllMappings returns empty mapping "" when a vanity paths
> is pathless url
> ---
>
> Key: SLING-11861
> URL: https://issues.apache.org/jira/browse/SLING-11861
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Affects Versions: Resource Resolver 1.10.0
>Reporter: Sagar Miglani
>Priority: Major
>
> When a resource has a path less url as vanity path (eg:
> "http://www.example.com";) ResourceMapper.getAllMappings returns mappings
> consisting of an empty path "".
> This "" mapping can make {{AuthenticationRequirementsManager}} stop listening
> to further authentication requirements [0]:
> {code:xml}
> Exception in thread "pool-14-thread-1" java.lang.IllegalArgumentException:
> Configuration must not be null or empty
> at
> org.apache.sling.auth.core.impl.AuthenticationRequirementHolder.fromConfig(AuthenticationRequirementHolder.java:30)
> at
> org.apache.sling.auth.core.impl.AuthenticationRequirementsManager.addService(AuthenticationRequirementsManager.java:374)
> at
> org.apache.sling.auth.core.impl.AuthenticationRequirementsManager.process(AuthenticationRequirementsManager.java:300)
> at
> org.apache.sling.auth.core.impl.AuthenticationRequirementsManager.processQueue(AuthenticationRequirementsManager.java:281)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java
[jira] [Commented] (SLING-11861) ResourceMapper.getAllMappings returns empty mapping "" when a vanity paths is pathless url
[
https://issues.apache.org/jira/browse/SLING-11861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17719734#comment-17719734
]
Sagar Miglani commented on SLING-11861:
---
[~reschke] I believe it is a missed edge case at resourceresolver side, in case
of URL based vanity paths.
IMO empty path/mapping "" does not make any sense. I'm not sure if we are
allowed to add "" vanity path, but if API doesn't allow to add why it returns
an ""?
But if you think this is incorrect please feel free to close the PR as well as
this ticket, Thanks!
BTW, [~cziegeler] and [~rombert] what is you opinion on this?
> ResourceMapper.getAllMappings returns empty mapping "" when a vanity paths
> is pathless url
> ---
>
> Key: SLING-11861
> URL: https://issues.apache.org/jira/browse/SLING-11861
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Affects Versions: Resource Resolver 1.10.0
>Reporter: Sagar Miglani
>Priority: Major
>
> When a resource has a path less url as vanity path (eg:
> "http://www.example.com";) ResourceMapper.getAllMappings returns mappings
> consisting of an empty path "".
> This "" mapping can make {{SlingAuthenticatorServiceListener}} stop listening
> to further authentication requirements [0]:
> {code:xml}
> Exception in thread "pool-14-thread-1" java.lang.IllegalArgumentException:
> Configuration must not be null or empty
> at
> org.apache.sling.auth.core.impl.AuthenticationRequirementHolder.fromConfig(AuthenticationRequirementHolder.java:30)
> at
> org.apache.sling.auth.core.impl.AuthenticationRequirementsManager.addService(AuthenticationRequirementsManager.java:374)
> at
> org.apache.sling.auth.core.impl.AuthenticationRequirementsManager.process(AuthenticationRequirementsManager.java:300)
> at
> org.apache.sling.auth.core.impl.AuthenticationRequirementsManager.processQueue(AuthenticationRequirementsManager.java:281)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
> Clarification required:
> - Is "" mapping/path a valid path? Should we store and return vanity path as
> "/" in case of pathless url as vanity path?
> cc: [~cziegeler] [~rombert] [~reschke]
> [0]:
> https://github.com/apache/sling-org-apache-sling-auth-core/blob/org.apache.sling.auth.core-1.5.0/src/main/java/org/apache/sling/auth/core/impl/SlingAuthenticatorServiceListener.java#L345-L351
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11861) ResourceMapper.getAllMappings returns empty mapping "" when a vanity paths is pathless url
[
https://issues.apache.org/jira/browse/SLING-11861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17719702#comment-17719702
]
Sagar Miglani commented on SLING-11861:
---
Potential changes:
[https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/96]
> ResourceMapper.getAllMappings returns empty mapping "" when a vanity paths
> is pathless url
> ---
>
> Key: SLING-11861
> URL: https://issues.apache.org/jira/browse/SLING-11861
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Affects Versions: Resource Resolver 1.10.0
>Reporter: Sagar Miglani
>Priority: Major
>
> When a resource has a path less url as vanity path (eg:
> "http://www.example.com";) ResourceMapper.getAllMappings returns mappings
> consisting of an empty path "".
> This "" mapping can make {{SlingAuthenticatorServiceListener}} stop listening
> to further authentication requirements [0]:
> {code:xml}
> Exception in thread "pool-14-thread-1" java.lang.IllegalArgumentException:
> Configuration must not be null or empty
> at
> org.apache.sling.auth.core.impl.AuthenticationRequirementHolder.fromConfig(AuthenticationRequirementHolder.java:30)
> at
> org.apache.sling.auth.core.impl.AuthenticationRequirementsManager.addService(AuthenticationRequirementsManager.java:374)
> at
> org.apache.sling.auth.core.impl.AuthenticationRequirementsManager.process(AuthenticationRequirementsManager.java:300)
> at
> org.apache.sling.auth.core.impl.AuthenticationRequirementsManager.processQueue(AuthenticationRequirementsManager.java:281)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
> Clarification required:
> - Is "" mapping/path a valid path? Should we store and return vanity path as
> "/" in case of pathless url as vanity path?
> cc: [~cziegeler] [~rombert] [~reschke]
> [0]:
> https://github.com/apache/sling-org-apache-sling-auth-core/blob/org.apache.sling.auth.core-1.5.0/src/main/java/org/apache/sling/auth/core/impl/SlingAuthenticatorServiceListener.java#L345-L351
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-11861) ResourceMapper.getAllMappings returns empty mapping "" when a vanity paths is pathless url
Sagar Miglani created SLING-11861:
-
Summary: ResourceMapper.getAllMappings returns empty mapping ""
when a vanity paths is pathless url
Key: SLING-11861
URL: https://issues.apache.org/jira/browse/SLING-11861
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Resolver 1.10.0
Reporter: Sagar Miglani
When a resource has a path less url as vanity path (eg:
"http://www.example.com";) ResourceMapper.getAllMappings returns mappings
consisting of an empty path "".
This "" mapping can make {{SlingAuthenticatorServiceListener}} stop listening
to further authentication requirements [0]:
{code:xml}
Exception in thread "pool-14-thread-1" java.lang.IllegalArgumentException:
Configuration must not be null or empty
at
org.apache.sling.auth.core.impl.AuthenticationRequirementHolder.fromConfig(AuthenticationRequirementHolder.java:30)
at
org.apache.sling.auth.core.impl.AuthenticationRequirementsManager.addService(AuthenticationRequirementsManager.java:374)
at
org.apache.sling.auth.core.impl.AuthenticationRequirementsManager.process(AuthenticationRequirementsManager.java:300)
at
org.apache.sling.auth.core.impl.AuthenticationRequirementsManager.processQueue(AuthenticationRequirementsManager.java:281)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
{code}
Clarification required:
- Is "" mapping/path a valid path? Should we store and return vanity path as
"/" in case of pathless url as vanity path?
cc: [~cziegeler] [~rombert] [~reschke]
[0]:
https://github.com/apache/sling-org-apache-sling-auth-core/blob/org.apache.sling.auth.core-1.5.0/src/main/java/org/apache/sling/auth/core/impl/SlingAuthenticatorServiceListener.java#L345-L351
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11776) Sling ResourceMerger may cause high cpu utilization
[
https://issues.apache.org/jira/browse/SLING-11776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17689790#comment-17689790
]
Sagar Miglani commented on SLING-11776:
---
[~cziegeler] [^SLING-11776_test.patch] shows that if merged root was n-times in
path, then n-1 times there were calls to {{resolver.getResource()}} each time
removing one merge root path from start.
If test looks good, I can raise a PR with test based on new changes.
> Sling ResourceMerger may cause high cpu utilization
> ---
>
> Key: SLING-11776
> URL: https://issues.apache.org/jira/browse/SLING-11776
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Resource Merger 1.4.0
>Reporter: Sagar Miglani
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: Resource Merger 1.4.2
>
> Attachments: SLING-11776.patch, SLING-11776_test.patch,
> SLING-11776_with_logs.patch
>
>
> If a bogus path like the following is used, resource merger can consume high
> amount of CPU and may lead to Denial of Service:
> {code:xml}
> /mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override
> {code}
> *Steps to reproduce*
> # Spawn an AEM author instance and login
> # Open
> [http://localhost:4502/aem/start.html//mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override]
> OR use
> curl -u :
> [http://localhost:4502/aem/start.html//mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override]
> In
> [MergingResourceProvider|https://github.com/apache/sling-org-apache-sling-resourcemerger/blob/master/src/main/java/org/apache/sling/resourcemerger/impl/MergingResourceProvider.java#L164-L174],
> we are calculating the relative path, which is just removing the merge root
> path from from the actual path.
> And this relative path is used for finding the resources under it.
> eg: if path is {{/mnt/override/mnt/override/mnt/override/bin}} then relative
> path will be {{/mnt/override/mnt/override}}
> And because this relative path again starts with {{/mnt/override}} again
> [MergingResourceProvider|https://github.com/apache/sling-org-apache-sling-resourcemerger/blob/master/src/main/java/org/apache/sling/resourcemerger/impl/MergingResourceProvider.java]
> will be picked and same calls will be executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-11776) Sling ResourceMerger may cause high cpu utilization
[
https://issues.apache.org/jira/browse/SLING-11776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sagar Miglani updated SLING-11776:
--
Attachment: SLING-11776_test.patch
> Sling ResourceMerger may cause high cpu utilization
> ---
>
> Key: SLING-11776
> URL: https://issues.apache.org/jira/browse/SLING-11776
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Resource Merger 1.4.0
>Reporter: Sagar Miglani
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: Resource Merger 1.4.2
>
> Attachments: SLING-11776.patch, SLING-11776_test.patch,
> SLING-11776_with_logs.patch
>
>
> If a bogus path like the following is used, resource merger can consume high
> amount of CPU and may lead to Denial of Service:
> {code:xml}
> /mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override
> {code}
> *Steps to reproduce*
> # Spawn an AEM author instance and login
> # Open
> [http://localhost:4502/aem/start.html//mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override]
> OR use
> curl -u :
> [http://localhost:4502/aem/start.html//mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override]
> In
> [MergingResourceProvider|https://github.com/apache/sling-org-apache-sling-resourcemerger/blob/master/src/main/java/org/apache/sling/resourcemerger/impl/MergingResourceProvider.java#L164-L174],
> we are calculating the relative path, which is just removing the merge root
> path from from the actual path.
> And this relative path is used for finding the resources under it.
> eg: if path is {{/mnt/override/mnt/override/mnt/override/bin}} then relative
> path will be {{/mnt/override/mnt/override}}
> And because this relative path again starts with {{/mnt/override}} again
> [MergingResourceProvider|https://github.com/apache/sling-org-apache-sling-resourcemerger/blob/master/src/main/java/org/apache/sling/resourcemerger/impl/MergingResourceProvider.java]
> will be picked and same calls will be executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-11776) Sling ResourceMerger may cause high cpu utilization
[
https://issues.apache.org/jira/browse/SLING-11776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sagar Miglani updated SLING-11776:
--
Attachment: SLING-11776_with_logs.patch
> Sling ResourceMerger may cause high cpu utilization
> ---
>
> Key: SLING-11776
> URL: https://issues.apache.org/jira/browse/SLING-11776
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Resource Merger 1.4.0
>Reporter: Sagar Miglani
>Priority: Major
> Attachments: SLING-11776.patch, SLING-11776_with_logs.patch
>
>
> If a bogus path like the following is used, resource merger can consume high
> amount of CPU and may lead to Denial of Service:
> {code:xml}
> /mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override
> {code}
> *Steps to reproduce*
> # Spawn an AEM author instance and login
> # Open
> [http://localhost:4502/aem/start.html//mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override]
> OR use
> curl -u :
> [http://localhost:4502/aem/start.html//mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override]
> In
> [MergingResourceProvider|https://github.com/apache/sling-org-apache-sling-resourcemerger/blob/master/src/main/java/org/apache/sling/resourcemerger/impl/MergingResourceProvider.java#L164-L174],
> we are calculating the relative path, which is just removing the merge root
> path from from the actual path.
> And this relative path is used for finding the resources under it.
> eg: if path is {{/mnt/override/mnt/override/mnt/override/bin}} then relative
> path will be {{/mnt/override/mnt/override}}
> And because this relative path again starts with {{/mnt/override}} again
> [MergingResourceProvider|https://github.com/apache/sling-org-apache-sling-resourcemerger/blob/master/src/main/java/org/apache/sling/resourcemerger/impl/MergingResourceProvider.java]
> will be picked and same calls will be executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11776) Sling ResourceMerger may cause high cpu utilization
[
https://issues.apache.org/jira/browse/SLING-11776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17689629#comment-17689629
]
Sagar Miglani commented on SLING-11776:
---
Potential patch: [^SLING-11776.patch]
> Sling ResourceMerger may cause high cpu utilization
> ---
>
> Key: SLING-11776
> URL: https://issues.apache.org/jira/browse/SLING-11776
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Resource Merger 1.4.0
>Reporter: Sagar Miglani
>Priority: Major
> Attachments: SLING-11776.patch
>
>
> If a bogus path like the following is used, resource merger can consume high
> amount of CPU and may lead to Denial of Service:
> {code:xml}
> /mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override
> {code}
> *Steps to reproduce*
> # Spawn an AEM author instance and login
> # Open
> [http://localhost:4502/aem/start.html//mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override]
> OR use
> curl -u :
> [http://localhost:4502/aem/start.html//mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override]
> In
> [MergingResourceProvider|https://github.com/apache/sling-org-apache-sling-resourcemerger/blob/master/src/main/java/org/apache/sling/resourcemerger/impl/MergingResourceProvider.java#L164-L174],
> we are calculating the relative path, which is just removing the merge root
> path from from the actual path.
> And this relative path is used for finding the resources under it.
> eg: if path is {{/mnt/override/mnt/override/mnt/override/bin}} then relative
> path will be {{/mnt/override/mnt/override}}
> And because this relative path again starts with {{/mnt/override}} again
> [MergingResourceProvider|https://github.com/apache/sling-org-apache-sling-resourcemerger/blob/master/src/main/java/org/apache/sling/resourcemerger/impl/MergingResourceProvider.java]
> will be picked and same calls will be executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-11776) Sling ResourceMerger may cause high cpu utilization
[
https://issues.apache.org/jira/browse/SLING-11776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sagar Miglani updated SLING-11776:
--
Attachment: SLING-11776.patch
> Sling ResourceMerger may cause high cpu utilization
> ---
>
> Key: SLING-11776
> URL: https://issues.apache.org/jira/browse/SLING-11776
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Resource Merger 1.4.0
>Reporter: Sagar Miglani
>Priority: Major
> Attachments: SLING-11776.patch
>
>
> If a bogus path like the following is used, resource merger can consume high
> amount of CPU and may lead to Denial of Service:
> {code:xml}
> /mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override
> {code}
> *Steps to reproduce*
> # Spawn an AEM author instance and login
> # Open
> [http://localhost:4502/aem/start.html//mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override]
> OR use
> curl -u :
> [http://localhost:4502/aem/start.html//mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override]
> In
> [MergingResourceProvider|https://github.com/apache/sling-org-apache-sling-resourcemerger/blob/master/src/main/java/org/apache/sling/resourcemerger/impl/MergingResourceProvider.java#L164-L174],
> we are calculating the relative path, which is just removing the merge root
> path from from the actual path.
> And this relative path is used for finding the resources under it.
> eg: if path is {{/mnt/override/mnt/override/mnt/override/bin}} then relative
> path will be {{/mnt/override/mnt/override}}
> And because this relative path again starts with {{/mnt/override}} again
> [MergingResourceProvider|https://github.com/apache/sling-org-apache-sling-resourcemerger/blob/master/src/main/java/org/apache/sling/resourcemerger/impl/MergingResourceProvider.java]
> will be picked and same calls will be executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-11776) Sling ResourceMerger may cause high cpu utilization
Sagar Miglani created SLING-11776:
-
Summary: Sling ResourceMerger may cause high cpu utilization
Key: SLING-11776
URL: https://issues.apache.org/jira/browse/SLING-11776
Project: Sling
Issue Type: Bug
Components: Extensions
Affects Versions: Resource Merger 1.4.0
Reporter: Sagar Miglani
If a bogus path like the following is used, resource merger can consume high
amount of CPU and may lead to Denial of Service:
{code:xml}
/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override
{code}
*Steps to reproduce*
# Spawn an AEM author instance and login
# Open
[http://localhost:4502/aem/start.html//mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override]
OR use
curl -u :
[http://localhost:4502/aem/start.html//mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override]
In
[MergingResourceProvider|https://github.com/apache/sling-org-apache-sling-resourcemerger/blob/master/src/main/java/org/apache/sling/resourcemerger/impl/MergingResourceProvider.java#L164-L174],
we are calculating the relative path, which is just removing the merge root
path from from the actual path.
And this relative path is used for finding the resources under it.
eg: if path is {{/mnt/override/mnt/override/mnt/override/bin}} then relative
path will be {{/mnt/override/mnt/override}}
And because this relative path again starts with {{/mnt/override}} again
[MergingResourceProvider|https://github.com/apache/sling-org-apache-sling-resourcemerger/blob/master/src/main/java/org/apache/sling/resourcemerger/impl/MergingResourceProvider.java]
will be picked and same calls will be executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11774) Fix the registration of the MergedResourcePicker2 implementations
[ https://issues.apache.org/jira/browse/SLING-11774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17688272#comment-17688272 ] Sagar Miglani commented on SLING-11774: --- [~radu] Does it look similar to SLING-11773 ? > Fix the registration of the MergedResourcePicker2 implementations > - > > Key: SLING-11774 > URL: https://issues.apache.org/jira/browse/SLING-11774 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: Resource Merger 1.4.0 >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: Resource Merger 1.4.2 > > > It seems the improvement from SLING-10168 introduced a subtle bug, where the > components are registered only based on configuration properties, completely > ignoring their default configuration (where applicable). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-11773) ResourceTypeHierarchyBasedResourcePicker not working anymore
Sagar Miglani created SLING-11773:
-
Summary: ResourceTypeHierarchyBasedResourcePicker not working
anymore
Key: SLING-11773
URL: https://issues.apache.org/jira/browse/SLING-11773
Project: Sling
Issue Type: Bug
Components: Extensions
Affects Versions: Resource Merger 1.4.0
Reporter: Sagar Miglani
In SLING-10168, SCR annotations were replaced by OSGi and configurations of
{{ResourceTypeHierarchyBasedResourcePicker}} have been designated to an inner
Configuration class, which are not getting bind properly without {{@Activate}}
Method.
And hence {{ResourceTypeHierarchyBasedResourcePicker}} does not seem to be
registered by
{{MergedResourcePickerWhiteboard}} [0].
Compared generated XMLs:
*With {{Activate}} Method injection:*
{code:xml}
http://www.osgi.org/xmlns/scr/v1.3.0";
name="org.apache.sling.resourcemerger.picker.overriding"
configuration-policy="require" activate="activate">
{code}
*Without {{@Activate}} method injection:*
{code:xml}
http://www.osgi.org/xmlns/scr/v1.3.0";
name="org.apache.sling.resourcemerger.picker.overriding"
configuration-policy="require">
{code}
[0]:
https://github.com/apache/sling-org-apache-sling-resourcemerger/blob/master/src/main/java/org/apache/sling/resourcemerger/impl/MergedResourcePickerWhiteboard.java#L87
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11749) resource resolver: document URL patterns in vanity paths and add test coverage
[
https://issues.apache.org/jira/browse/SLING-11749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17678162#comment-17678162
]
Sagar Miglani commented on SLING-11749:
---
[~reschke] I also checked the map entries generated in different scenarios of
url base vanity paths.
Not sure map entries are generated correctly in all scenarios (like port -1
when no port in a url or in case example.com/vanityPath) but adding here
thinking it might help :)
||sling:vanityPath||Map entries||Vanity Path target||
|http://example.com|^http/example.com.-1(\..*) and ^http/example.com.-1$|""|
|http://example.com/|^http/example.com.-1/(\..*) and ^http/example.com.-1/$|"/"|
|http://example.com:4502|^http/example.com.4502(\..*) and
^http/example.com.4502$|""|
|http://example.com:4502/|^http/example.com.4502/(\..*) and
^http/example.com.4502/$|"/"|
|://example.com:4502/vanityPath|None|None|
|http://example.com/mock/vanityPath|^http/example.com.-1/mock/vanityPath(\..*)
and ^http/example.com.-1/mock/vanityPath$|"/mock/vanityPath"|
|http://example.com/mock/vanityPath/|^http/example.com.-1/mock/vanityPath/(\..*)
and ^http/example.com.-1/mock/vanityPath/$|"/mock/vanityPath/"|
|http://example.com:4502/vanityPath|^http/example.com.4502/vanityPath(\..*) and
^http/example.com.4502/vanityPath$|"/vanityPath"|
|http://:4502/vanityPath|^http/.4502/vanityPath(\..*) and
^http/.4502/vanityPath$|"/vanityPath"|
|example.com/vanityPath|^[^/]{+}/[^/]{+}/example.com/vanityPath(\..*) and
^[^/]{+}/[^/]{+}/example.com/vanityPath$|"/example.com/vanityPath"|
|example.com:4502/vanityPath|^[^/]{+}/[^/]{+}/example.com:4502/vanityPath(\..*)
and
^[^/]{+}/[^/]{+}/example.com:4502/vanityPath$|"/example.com:4502/vanityPath"|
> resource resolver: document URL patterns in vanity paths and add test coverage
> --
>
> Key: SLING-11749
> URL: https://issues.apache.org/jira/browse/SLING-11749
> Project: Sling
> Issue Type: Task
> Components: ResourceResolver
>Reporter: Julian Reschke
>Priority: Major
>
> MapEntries (in "private String[] getVanityPathDefinition(final String
> pVanityPath)") currently attempts to detect URL-shaped paths, and rewrite
> them to a prefix.
> There are several issues here:
> 1. there doesn't seem to be any concrete documentation about this
> 2. apparently there is no test coverage - removing that code causes no test
> failures
> 3. it's unclear whether not replacing an empty string by "/" is intentional
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11620) Synchronization issue in Webconsole Security Provider
[
https://issues.apache.org/jira/browse/SLING-11620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17618729#comment-17618729
]
Sagar Miglani commented on SLING-11620:
---
Thanks [~cziegeler] , I should have created a PR directly to avoid confusion.
Can we please merge and release with the PR [0]?
[0]:
[https://github.com/apache/sling-org-apache-sling-extensions-webconsolesecurityprovider/pull/3]
> Synchronization issue in Webconsole Security Provider
> -
>
> Key: SLING-11620
> URL: https://issues.apache.org/jira/browse/SLING-11620
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Web Console Security Provider 1.2.6
>Reporter: Sagar Miglani
>Priority: Major
> Attachments: BlockedThreads.png, SLING-11620_fix.patch,
> WebconsoleServiceListeners.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> WebconsoleSecurityProvider's
> [ServiceListeners|https://github.com/apache/sling-org-apache-sling-extensions-webconsolesecurityprovider/blob/master/src/main/java/org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener.java]
> class has three fields of Listener (an inner class of {{ServiceListeners}}
> implementing {{{}ServiceListener{}}}) {{{}repositoryListener{}}},
> {{{}authSupportListener{}}}, {{{}authListener{}}}.
> Each of listener uses synchronized methods and on any {{ServiceChanged}}
> event it may call {{notifyChange}} method of {{ServiceListeners}} outer class
> which is also a synchronized method and in this method we are again calling
> all of the listener fields' {{getService}} sychronized methods
> If two service events for these listeneres fields occur simulatenously a
> deadlock situation may arise.
> eg:
> Thread1:
> - repositoryListener -> serviceChanged
> - synchronized retainSerivce - (self lock acquired)
> - synchronized notifyChange - (outer class' lock acquired)
> Thread2:
> - authSupportListener -> serviceChanged
> - synchronized retainService - (self lock aquired)
> - synchronized notifyChange - (wait for thread 1 to release outer class'
> lock)
> Thread1:
> - synchronized (authSupportListener) getService - (wait for thread 2 to
> release the lock)
> Tried to replicate the scenario [^WebconsoleServiceListeners.patch]. The test
> in this patch file fails due to timeout.
> On taking thread snapshot you may see the thread blocked and waiting for each
> other. [^BlockedThreads.png]
> Shouldn't these all listener fields and outer class be using the shared lock
> instead of sychronized methods?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11620) Synchronization issue in Webconsole Security Provider
[
https://issues.apache.org/jira/browse/SLING-11620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17618694#comment-17618694
]
Sagar Miglani commented on SLING-11620:
---
[~cziegeler] I think now we have a shared lock object between outer and inner
class, so it does makes a difference.
I believe it is the {{synchronized notifyChange}} method of outer class
accessing {{synchronized getService}} invoked via inner class's {{synchronized
retainService/releaseService}} methods from different threads on
{{serviceChanged}} event of different {{ServiceListener}} field objects. (same
can be confirmed from the logs I attached in my older comment).
I could be wrong but I request you to kindly have a look at code. Thanks :)
Also created this PR for better understanding:
[https://github.com/apache/sling-org-apache-sling-extensions-webconsolesecurityprovider/pull/3]
> Synchronization issue in Webconsole Security Provider
> -
>
> Key: SLING-11620
> URL: https://issues.apache.org/jira/browse/SLING-11620
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Web Console Security Provider 1.2.6
>Reporter: Sagar Miglani
>Priority: Major
> Attachments: BlockedThreads.png, SLING-11620_fix.patch,
> WebconsoleServiceListeners.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> WebconsoleSecurityProvider's
> [ServiceListeners|https://github.com/apache/sling-org-apache-sling-extensions-webconsolesecurityprovider/blob/master/src/main/java/org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener.java]
> class has three fields of Listener (an inner class of {{ServiceListeners}}
> implementing {{{}ServiceListener{}}}) {{{}repositoryListener{}}},
> {{{}authSupportListener{}}}, {{{}authListener{}}}.
> Each of listener uses synchronized methods and on any {{ServiceChanged}}
> event it may call {{notifyChange}} method of {{ServiceListeners}} outer class
> which is also a synchronized method and in this method we are again calling
> all of the listener fields' {{getService}} sychronized methods
> If two service events for these listeneres fields occur simulatenously a
> deadlock situation may arise.
> eg:
> Thread1:
> - repositoryListener -> serviceChanged
> - synchronized retainSerivce - (self lock acquired)
> - synchronized notifyChange - (outer class' lock acquired)
> Thread2:
> - authSupportListener -> serviceChanged
> - synchronized retainService - (self lock aquired)
> - synchronized notifyChange - (wait for thread 1 to release outer class'
> lock)
> Thread1:
> - synchronized (authSupportListener) getService - (wait for thread 2 to
> release the lock)
> Tried to replicate the scenario [^WebconsoleServiceListeners.patch]. The test
> in this patch file fails due to timeout.
> On taking thread snapshot you may see the thread blocked and waiting for each
> other. [^BlockedThreads.png]
> Shouldn't these all listener fields and outer class be using the shared lock
> instead of sychronized methods?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-11620) Synchronization issue in Webconsole Security Provider
[
https://issues.apache.org/jira/browse/SLING-11620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sagar Miglani updated SLING-11620:
--
Description:
WebconsoleSecurityProvider's
[ServiceListeners|https://github.com/apache/sling-org-apache-sling-extensions-webconsolesecurityprovider/blob/master/src/main/java/org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener.java]
class has three fields of Listener (an inner class of {{ServiceListeners}}
implementing {{{}ServiceListener{}}}) {{{}repositoryListener{}}},
{{{}authSupportListener{}}}, {{{}authListener{}}}.
Each of listener uses synchronized methods and on any {{ServiceChanged}} event
it may call {{notifyChange}} method of {{ServiceListeners}} outer class which
is also a synchronized method and in this method we are again calling all of
the listener fields' {{getService}} sychronized methods
If two service events for these listeneres fields occur simulatenously a
deadlock situation may arise.
eg:
Thread1:
- repositoryListener -> serviceChanged
- synchronized retainSerivce - (self lock acquired)
- synchronized notifyChange - (outer class' lock acquired)
Thread2:
- authSupportListener -> serviceChanged
- synchronized retainService - (self lock aquired)
- synchronized notifyChange - (wait for thread 1 to release outer class' lock)
Thread1:
- synchronized (authSupportListener) getService - (wait for thread 2 to
release the lock)
Tried to replicate the scenario [^WebconsoleServiceListeners.patch]. The test
in this patch file fails due to timeout.
On taking thread snapshot you may see the thread blocked and waiting for each
other. [^BlockedThreads.png]
Shouldn't these all listener fields and outer class be using the shared lock
instead of sychronized methods?
was:
WebconsoleSecurityProvider's
[ServiceListeners|https://github.com/apache/sling-org-apache-sling-extensions-webconsolesecurityprovider/blob/master/src/main/java/org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener.java]
class has three fields of Listener (an inner class of {{ServiceListeners}}
implementing {{{}ServiceListener{}}}) {{{}repositoryListener{}}},
{{{}authSupportListener{}}}, {{{}authListener{}}}.
Each of listener uses synchronized methods and on any {{ServiceChanged}} event
it may call {{notifyChange}} method of {{ServiceListeners}} parent class which
is also a synchronized method and in this method we are again calling all of
the listener fields' {{getService}} sychronized methods
If two service events for these listeneres fields occur simulatenously a
deadlock situation may arise.
eg:
Thread1:
- repositoryListener -> serviceChanged
- synchronized retainSerivce - (self lock acquired)
- synchronized notifyChange - (parent's lock acquired)
Thread2:
- authSupportListener -> serviceChanged
- synchronized retainService - (self lock aquired)
- synchronized notifyChange - (wait for thread 1 to release parent's lock)
Thread1:
- synchronized (authSupportListener) getService - (wait for thread 2 to
release the lock)
Tried to replicate the scenario [^WebconsoleServiceListeners.patch]. The test
in this patch file fails due to timeout.
On taking thread snapshot you may see the thread blocked and waiting for each
other. [^BlockedThreads.png]
Shouldn't these all listener fields and parent class be using the shared lock
instead of sychronized methods?
> Synchronization issue in Webconsole Security Provider
> -
>
> Key: SLING-11620
> URL: https://issues.apache.org/jira/browse/SLING-11620
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Web Console Security Provider 1.2.6
>Reporter: Sagar Miglani
>Priority: Major
> Attachments: BlockedThreads.png, SLING-11620_fix.patch,
> WebconsoleServiceListeners.patch
>
>
> WebconsoleSecurityProvider's
> [ServiceListeners|https://github.com/apache/sling-org-apache-sling-extensions-webconsolesecurityprovider/blob/master/src/main/java/org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener.java]
> class has three fields of Listener (an inner class of {{ServiceListeners}}
> implementing {{{}ServiceListener{}}}) {{{}repositoryListener{}}},
> {{{}authSupportListener{}}}, {{{}authListener{}}}.
> Each of listener uses synchronized methods and on any {{ServiceChanged}}
> event it may call {{notifyChange}} method of {{ServiceListeners}} outer class
> which is also a synchronized method and in this method we are again calling
> all of the listener fields' {{getService}} sychronized methods
> If two service events for these listeneres fields occur simulatenously a
> deadlock situation may arise.
> eg:
> Thread1:
> - repositoryListener -> serviceChanged
> - synchronized retainSerivce - (self lock
[jira] [Commented] (SLING-11620) Synchronization issue in Webconsole Security Provider
[
https://issues.apache.org/jira/browse/SLING-11620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17618206#comment-17618206
]
Sagar Miglani commented on SLING-11620:
---
[~cziegeler] [~joerghoh] Can you please have a look and guide?
Also tried a fix ([^SLING-11620_fix.patch]), changed synchronized methods with
a shared lock synchronization block.
> Synchronization issue in Webconsole Security Provider
> -
>
> Key: SLING-11620
> URL: https://issues.apache.org/jira/browse/SLING-11620
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Web Console Security Provider 1.2.6
>Reporter: Sagar Miglani
>Priority: Major
> Attachments: BlockedThreads.png, SLING-11620_fix.patch,
> WebconsoleServiceListeners.patch
>
>
> WebconsoleSecurityProvider's
> [ServiceListeners|https://github.com/apache/sling-org-apache-sling-extensions-webconsolesecurityprovider/blob/master/src/main/java/org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener.java]
> class has three fields of Listener (an inner class of {{ServiceListeners}}
> implementing {{{}ServiceListener{}}}) {{{}repositoryListener{}}},
> {{{}authSupportListener{}}}, {{{}authListener{}}}.
> Each of listener uses synchronized methods and on any {{ServiceChanged}}
> event it may call {{notifyChange}} method of {{ServiceListeners}} parent
> class which is also a synchronized method and in this method we are again
> calling all of the listener fields' {{getService}} sychronized methods
> If two service events for these listeneres fields occur simulatenously a
> deadlock situation may arise.
> eg:
> Thread1:
> - repositoryListener -> serviceChanged
> - synchronized retainSerivce - (self lock acquired)
> - synchronized notifyChange - (parent's lock acquired)
> Thread2:
> - authSupportListener -> serviceChanged
> - synchronized retainService - (self lock aquired)
> - synchronized notifyChange - (wait for thread 1 to release parent's lock)
> Thread1:
> - synchronized (authSupportListener) getService - (wait for thread 2 to
> release the lock)
> Tried to replicate the scenario [^WebconsoleServiceListeners.patch]. The test
> in this patch file fails due to timeout.
> On taking thread snapshot you may see the thread blocked and waiting for each
> other. [^BlockedThreads.png]
> Shouldn't these all listener fields and parent class be using the shared lock
> instead of sychronized methods?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-11620) Synchronization issue in Webconsole Security Provider
[
https://issues.apache.org/jira/browse/SLING-11620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sagar Miglani updated SLING-11620:
--
Attachment: SLING-11620_fix.patch
> Synchronization issue in Webconsole Security Provider
> -
>
> Key: SLING-11620
> URL: https://issues.apache.org/jira/browse/SLING-11620
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Web Console Security Provider 1.2.6
>Reporter: Sagar Miglani
>Priority: Major
> Attachments: BlockedThreads.png, SLING-11620_fix.patch,
> WebconsoleServiceListeners.patch
>
>
> WebconsoleSecurityProvider's
> [ServiceListeners|https://github.com/apache/sling-org-apache-sling-extensions-webconsolesecurityprovider/blob/master/src/main/java/org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener.java]
> class has three fields of Listener (an inner class of {{ServiceListeners}}
> implementing {{{}ServiceListener{}}}) {{{}repositoryListener{}}},
> {{{}authSupportListener{}}}, {{{}authListener{}}}.
> Each of listener uses synchronized methods and on any {{ServiceChanged}}
> event it may call {{notifyChange}} method of {{ServiceListeners}} parent
> class which is also a synchronized method and in this method we are again
> calling all of the listener fields' {{getService}} sychronized methods
> If two service events for these listeneres fields occur simulatenously a
> deadlock situation may arise.
> eg:
> Thread1:
> - repositoryListener -> serviceChanged
> - synchronized retainSerivce - (self lock acquired)
> - synchronized notifyChange - (parent's lock acquired)
> Thread2:
> - authSupportListener -> serviceChanged
> - synchronized retainService - (self lock aquired)
> - synchronized notifyChange - (wait for thread 1 to release parent's lock)
> Thread1:
> - synchronized (authSupportListener) getService - (wait for thread 2 to
> release the lock)
> Tried to replicate the scenario [^WebconsoleServiceListeners.patch]. The test
> in this patch file fails due to timeout.
> On taking thread snapshot you may see the thread blocked and waiting for each
> other. [^BlockedThreads.png]
> Shouldn't these all listener fields and parent class be using the shared lock
> instead of sychronized methods?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-11620) Synchronization issue in Webconsole Security Provider
[
https://issues.apache.org/jira/browse/SLING-11620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sagar Miglani updated SLING-11620:
--
Description:
WebconsoleSecurityProvider's
[ServiceListeners|https://github.com/apache/sling-org-apache-sling-extensions-webconsolesecurityprovider/blob/master/src/main/java/org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener.java]
class has three fields of Listener (an inner class of {{ServiceListeners}}
implementing {{{}ServiceListener{}}}) {{{}repositoryListener{}}},
{{{}authSupportListener{}}}, {{{}authListener{}}}.
Each of listener uses synchronized methods and on any {{ServiceChanged}} event
it may call {{notifyChange}} method of {{ServiceListeners}} parent class which
is also a synchronized method and in this method we are again calling all of
the listener fields' {{getService}} sychronized methods
If two service events for these listeneres fields occur simulatenously a
deadlock situation may arise.
eg:
Thread1:
- repositoryListener -> serviceChanged
- synchronized retainSerivce - (self lock acquired)
- synchronized notifyChange - (parent's lock acquired)
Thread2:
- authSupportListener -> serviceChanged
- synchronized retainService - (self lock aquired)
- synchronized notifyChange - (wait for thread 1 to release parent's lock)
Thread1:
- synchronized (authSupportListener) getService - (wait for thread 2 to
release the lock)
Tried to replicate the scenario [^WebconsoleServiceListeners.patch]. The test
in this patch file fails due to timeout.
On taking thread snapshot you may see the thread blocked and waiting for each
other. [^BlockedThreads.png]
Shouldn't these all listener fields and parent class be using the shared lock
instead of sychronized methods?
was:
WebconsoleSecurityProvider's
[ServiceListeners|https://github.com/apache/sling-org-apache-sling-extensions-webconsolesecurityprovider/blob/master/src/main/java/org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener.java]
class has three fields of Listener (an inner class of {{ServiceListeners}}
implementing {{{}ServiceListener{}}}) {{{}repositoryListener{}}},
{{{}authSupportListener{}}}, {{{}authListener{}}}.
Each of listener uses synchronized methods and on any {{ServiceChanged}} event
it may call {{notifyChange}} method of {{ServiceListeners}} parent class which
is also a synchronized method and in this method we are again calling all of
the listener fields' {{getService}} sychronized methods
If two service events for these listeneres fields occur simulatenously a
deadlock situation may arise.
eg:
Thread1:
- repositoryListener -> serviceChanged
- synchronized retainSerivce - (self lock acquired)
- synchronized notifyChange - (parent's lock acquired)
Thread2:
- authSupportListener -> serviceChanged
- synchronized retainService - (self lock aquired)
- synchronized notifyChange - (wait for thread 1 to release parent's lock)
Thread1:
- synchronized (authSupportListener) getService - (wait for thread 2 to
release the lock)
Tried to replicate the scenario [^WebconsoleServiceListeners.patch]. The test
in this patch file fails due to timeout.
On taking thread snapshot you may see the thread blocked and waiting for each
other. [^BlockedThreads.png]
Shouldn't these all listener fields and parent class be using the shared lock
instead of sychronized methods?
> Synchronization issue in Webconsole Security Provider
> -
>
> Key: SLING-11620
> URL: https://issues.apache.org/jira/browse/SLING-11620
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Web Console Security Provider 1.2.6
>Reporter: Sagar Miglani
>Priority: Major
> Attachments: BlockedThreads.png, WebconsoleServiceListeners.patch
>
>
> WebconsoleSecurityProvider's
> [ServiceListeners|https://github.com/apache/sling-org-apache-sling-extensions-webconsolesecurityprovider/blob/master/src/main/java/org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener.java]
> class has three fields of Listener (an inner class of {{ServiceListeners}}
> implementing {{{}ServiceListener{}}}) {{{}repositoryListener{}}},
> {{{}authSupportListener{}}}, {{{}authListener{}}}.
> Each of listener uses synchronized methods and on any {{ServiceChanged}}
> event it may call {{notifyChange}} method of {{ServiceListeners}} parent
> class which is also a synchronized method and in this method we are again
> calling all of the listener fields' {{getService}} sychronized methods
> If two service events for these listeneres fields occur simulatenously a
> deadlock situation may arise.
> eg:
> Thread1:
> - repositoryListener -> serviceChanged
> - synchronized retainSerivce - (self lock acquired)
> - synchronized notif
[jira] [Updated] (SLING-11620) Synchronization issue in Webconsole Security Provider
[
https://issues.apache.org/jira/browse/SLING-11620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sagar Miglani updated SLING-11620:
--
Description:
WebconsoleSecurityProvider's
[ServiceListeners|https://github.com/apache/sling-org-apache-sling-extensions-webconsolesecurityprovider/blob/master/src/main/java/org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener.java]
class has three fields of Listener (an inner class of {{ServiceListeners}}
implementing {{{}ServiceListener{}}}) {{{}repositoryListener{}}},
{{{}authSupportListener{}}}, {{{}authListener{}}}.
Each of listener uses synchronized methods and on any {{ServiceChanged}} event
it may call {{notifyChange}} method of {{ServiceListeners}} parent class which
is also a synchronized method and in this method we are again calling all of
the listener fields' {{getService}} sychronized methods
If two service events for these listeneres fields occur simulatenously a
deadlock situation may arise.
eg:
Thread1:
- repositoryListener -> serviceChanged
- synchronized retainSerivce - (self lock acquired)
- synchronized notifyChange - (parent's lock acquired)
Thread2:
- authSupportListener -> serviceChanged
- synchronized retainService - (self lock aquired)
- synchronized notifyChange - (wait for thread 1 to release parent's lock)
Thread1:
- synchronized (authSupportListener) getService - (wait for thread 2 to
release the lock)
Tried to replicate the scenario [^WebconsoleServiceListeners.patch]. The test
in this patch file fails due to timeout.
On taking thread snapshot you may see the thread blocked and waiting for each
other. [^BlockedThreads.png]
Shouldn't these all listener fields and parent class be using the shared lock
instead of sychronized methods?
was:
WebconsoleSecurityProvider's
[ServiceListeners|https://github.com/apache/sling-org-apache-sling-extensions-webconsolesecurityprovider/blob/master/src/main/java/org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener.java]
class has three fields of Listener (an inner class of {{ServiceListeners}}
implementing {{ServiceListener}}) {{repositoryListener}},
{{authSupportListener}}, {{authListener}}.
Each of listener uses synchronized methods and on any {{ServiceChanged}} event
it may call {{notifyChange}} method of {{ServiceListeners}} parent class which
is also a synchronized method and in this method we are again calling all of
the listener fields' {{getService}} sychronized methods
If two service events for these listeneres fields occur simulatenously a
deadlock situation may arise.
eg:
Thread1:
- repositoryListener -> serviceChanged
- synchronized retainSerivce - (self lock acquired)
- synchronized notifyChange - (parent's lock acquired)
Thread2:
- authSupportListener -> serviceChanged
- synchronized retainService - (self lock aquired)
- synchronized notifyChange - (wait for thread 1 to release parent's lock)
Thread1:
- synchronized (authSupportListener) getService - (wait for thread 2 to
release the lock)
Tried to replicate the scenario [^WebconsoleServiceListeners.patch]. The test
in this patch file fails due to timeout.
On taking thread snapshot you may see the thread blocked and waiting for each
other. [^BlockedThreads.png]
Shouldn't these all listener fields and parent class be using the shared lock
instead of sychronized methods
> Synchronization issue in Webconsole Security Provider
> -
>
> Key: SLING-11620
> URL: https://issues.apache.org/jira/browse/SLING-11620
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Web Console Security Provider 1.2.6
>Reporter: Sagar Miglani
>Priority: Major
> Attachments: BlockedThreads.png, WebconsoleServiceListeners.patch
>
>
> WebconsoleSecurityProvider's
> [ServiceListeners|https://github.com/apache/sling-org-apache-sling-extensions-webconsolesecurityprovider/blob/master/src/main/java/org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener.java]
> class has three fields of Listener (an inner class of {{ServiceListeners}}
> implementing {{{}ServiceListener{}}}) {{{}repositoryListener{}}},
> {{{}authSupportListener{}}}, {{{}authListener{}}}.
> Each of listener uses synchronized methods and on any {{ServiceChanged}}
> event it may call {{notifyChange}} method of {{ServiceListeners}} parent
> class which is also a synchronized method and in this method we are again
> calling all of the listener fields' {{getService}} sychronized methods
> If two service events for these listeneres fields occur simulatenously a
> deadlock situation may arise.
> eg:
> Thread1:
> - repositoryListener -> serviceChanged
> - synchronized retainSerivce - (self lock acquired)
>
[jira] [Commented] (SLING-11620) Synchronization issue in Webconsole Security Provider
[
https://issues.apache.org/jira/browse/SLING-11620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17617527#comment-17617527
]
Sagar Miglani commented on SLING-11620:
---
An instance where it happened.
{code:xml}
1LKDEADLOCKDeadlock detected !!!
NULL -
NULL
2LKDEADLOCKTHR Thread "OsgiInstallerImpl" (0x013DDA00)
3LKDEADLOCKWTRis waiting for:
4LKDEADLOCKMON sys_mon_t:0x7FF767F71FF8 infl_mon_t: 0x7FF767F72078:
4LKDEADLOCKOBJ
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener$Listener@0x00010AE74D28
3LKDEADLOCKOWNwhich is owned by:
2LKDEADLOCKTHR Thread "FelixStartLevel" (0x010D7D00)
3LKDEADLOCKWTRwhich is waiting for:
4LKDEADLOCKMON sys_mon_t:0x7FF767F720A8 infl_mon_t: 0x7FF767F72128:
4LKDEADLOCKOBJ
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener@0x00010AE74CE8
3LKDEADLOCKOWNwhich is owned by:
2LKDEADLOCKTHR Thread "OsgiInstallerImpl" (0x013DDA00)
{code}
OsgiInstallerImpl thread:
{code:xml}
State: Deadlock/Blocked
Monitor: Owns Monitor Lock on
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener$Listener@0x00010AE74D28
,
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener@0x00010AE74CE8
Waiting for Monitor Lock on
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener$Listener@0x00010AE74D28
,
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener@0x00010AE74CE8
Java Stack:
at
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener$Listener.getService(ServicesListener.java:218)
at
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener.notifyChange(ServicesListener.java:90)
at
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener$Listener.releaseService(ServicesListener.java:257)
at
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener$Listener.serviceChanged(ServicesListener.java:269)
at
org/apache/felix/framework/EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990(Compiled
Code))
at
org/apache/felix/framework/EventDispatcher.fireEventImmediately(EventDispatcher.java:838(Compiled
Code))
at
org/apache/felix/framework/EventDispatcher.fireServiceEvent(EventDispatcher.java:545(Compiled
Code))
at org/apache/felix/framework/Felix.fireServiceEvent(Felix.java:4833(Compiled
Code))
at org/apache/felix/framework/Felix.access$000(Felix.java:112(Compiled Code))
at org/apache/felix/framework/Felix$1.serviceChanged(Felix.java:434(Compiled
Code))
at
org/apache/felix/framework/ServiceRegistry.unregisterService(ServiceRegistry.java:170(Compiled
Code))
at
org/apache/felix/framework/ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:145)
at
org/apache/sling/jcr/base/AbstractSlingRepositoryManager.unregisterService(AbstractSlingRepositoryManager.java:289)
at
org/apache/sling/jcr/base/AbstractSlingRepositoryManager.stop(AbstractSlingRepositoryManager.java:560)
at
com/adobe/granite/repository/impl/SlingRepositoryManager.deactivate(SlingRepositoryManager.java:259)
at sun/reflect/NativeMethodAccessorImpl.invoke0(Native Method)
{code}
FelixStartLevel thread
{code:xml}
State: Deadlock/Blocked
Monitor: Owns Monitor Lock on
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener$Listener@0x00010AE74D28
,
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener@0x00010AE74CE8
Waiting for Monitor Lock on
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener$Listener@0x00010AE74D28
,
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener@0x00010AE74CE8
Java Stack:
at
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener.notifyChange(ServicesListener.java:90)
at
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener$Listener.retainService(ServicesListener.java:241)
at
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener$Listener.serviceChanged(ServicesListener.java:267)
at
org/apache/felix/framework/EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990(Compiled
Code))
at
org/apache/felix/framework/EventDispatcher.fireEventImmediately(EventDispatcher.java:838(Compiled
Code))
at
org/apache/felix/framework/EventDispatcher.fireServiceEvent(EventDispatcher.java:545)
at org/apache/felix/framework/Felix.fireServiceEvent(Felix.java:4833)
at org/apache/felix/framework/Felix.registerService(Felix.java:3804)
at
org/apache/felix/framework/BundleContextImpl.registerService(BundleContextImpl.java:328)
at
org/apache/felix/scr/impl/mana
[jira] [Comment Edited] (SLING-11620) Synchronization issue in Webconsole Security Provider
[
https://issues.apache.org/jira/browse/SLING-11620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17617527#comment-17617527
]
Sagar Miglani edited comment on SLING-11620 at 10/14/22 7:16 AM:
-
Some logs when it happened.
{code:xml}
1LKDEADLOCKDeadlock detected !!!
NULL -
NULL
2LKDEADLOCKTHR Thread "OsgiInstallerImpl" (0x013DDA00)
3LKDEADLOCKWTRis waiting for:
4LKDEADLOCKMON sys_mon_t:0x7FF767F71FF8 infl_mon_t: 0x7FF767F72078:
4LKDEADLOCKOBJ
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener$Listener@0x00010AE74D28
3LKDEADLOCKOWNwhich is owned by:
2LKDEADLOCKTHR Thread "FelixStartLevel" (0x010D7D00)
3LKDEADLOCKWTRwhich is waiting for:
4LKDEADLOCKMON sys_mon_t:0x7FF767F720A8 infl_mon_t: 0x7FF767F72128:
4LKDEADLOCKOBJ
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener@0x00010AE74CE8
3LKDEADLOCKOWNwhich is owned by:
2LKDEADLOCKTHR Thread "OsgiInstallerImpl" (0x013DDA00)
{code}
OsgiInstallerImpl thread:
{code:xml}
State: Deadlock/Blocked
Monitor: Owns Monitor Lock on
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener$Listener@0x00010AE74D28
,
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener@0x00010AE74CE8
Waiting for Monitor Lock on
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener$Listener@0x00010AE74D28
,
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener@0x00010AE74CE8
Java Stack:
at
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener$Listener.getService(ServicesListener.java:218)
at
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener.notifyChange(ServicesListener.java:90)
at
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener$Listener.releaseService(ServicesListener.java:257)
at
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener$Listener.serviceChanged(ServicesListener.java:269)
at
org/apache/felix/framework/EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990(Compiled
Code))
at
org/apache/felix/framework/EventDispatcher.fireEventImmediately(EventDispatcher.java:838(Compiled
Code))
at
org/apache/felix/framework/EventDispatcher.fireServiceEvent(EventDispatcher.java:545(Compiled
Code))
at org/apache/felix/framework/Felix.fireServiceEvent(Felix.java:4833(Compiled
Code))
at org/apache/felix/framework/Felix.access$000(Felix.java:112(Compiled Code))
at org/apache/felix/framework/Felix$1.serviceChanged(Felix.java:434(Compiled
Code))
at
org/apache/felix/framework/ServiceRegistry.unregisterService(ServiceRegistry.java:170(Compiled
Code))
at
org/apache/felix/framework/ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:145)
at
org/apache/sling/jcr/base/AbstractSlingRepositoryManager.unregisterService(AbstractSlingRepositoryManager.java:289)
at
org/apache/sling/jcr/base/AbstractSlingRepositoryManager.stop(AbstractSlingRepositoryManager.java:560)
at
com/adobe/granite/repository/impl/SlingRepositoryManager.deactivate(SlingRepositoryManager.java:259)
at sun/reflect/NativeMethodAccessorImpl.invoke0(Native Method)
{code}
FelixStartLevel thread
{code:xml}
State: Deadlock/Blocked
Monitor: Owns Monitor Lock on
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener$Listener@0x00010AE74D28
,
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener@0x00010AE74CE8
Waiting for Monitor Lock on
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener$Listener@0x00010AE74D28
,
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener@0x00010AE74CE8
Java Stack:
at
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener.notifyChange(ServicesListener.java:90)
at
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener$Listener.retainService(ServicesListener.java:241)
at
org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener$Listener.serviceChanged(ServicesListener.java:267)
at
org/apache/felix/framework/EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990(Compiled
Code))
at
org/apache/felix/framework/EventDispatcher.fireEventImmediately(EventDispatcher.java:838(Compiled
Code))
at
org/apache/felix/framework/EventDispatcher.fireServiceEvent(EventDispatcher.java:545)
at org/apache/felix/framework/Felix.fireServiceEvent(Felix.java:4833)
at org/apache/felix/framework/Felix.registerService(Felix.java:3804)
at
org/apache/felix/framework/BundleContextImpl.registerService(BundleContextImpl.j
[jira] [Created] (SLING-11620) Synchronization issue in Webconsole Security Provider
Sagar Miglani created SLING-11620:
-
Summary: Synchronization issue in Webconsole Security Provider
Key: SLING-11620
URL: https://issues.apache.org/jira/browse/SLING-11620
Project: Sling
Issue Type: Bug
Components: Extensions
Affects Versions: Web Console Security Provider 1.2.6
Reporter: Sagar Miglani
Attachments: BlockedThreads.png, WebconsoleServiceListeners.patch
WebconsoleSecurityProvider's
[ServiceListeners|https://github.com/apache/sling-org-apache-sling-extensions-webconsolesecurityprovider/blob/master/src/main/java/org/apache/sling/extensions/webconsolesecurityprovider/internal/ServicesListener.java]
class has three fields of Listener (an inner class of {{ServiceListeners}}
implementing {{ServiceListener}}) {{repositoryListener}},
{{authSupportListener}}, {{authListener}}.
Each of listener uses synchronized methods and on any {{ServiceChanged}} event
it may call {{notifyChange}} method of {{ServiceListeners}} parent class which
is also a synchronized method and in this method we are again calling all of
the listener fields' {{getService}} sychronized methods
If two service events for these listeneres fields occur simulatenously a
deadlock situation may arise.
eg:
Thread1:
- repositoryListener -> serviceChanged
- synchronized retainSerivce - (self lock acquired)
- synchronized notifyChange - (parent's lock acquired)
Thread2:
- authSupportListener -> serviceChanged
- synchronized retainService - (self lock aquired)
- synchronized notifyChange - (wait for thread 1 to release parent's lock)
Thread1:
- synchronized (authSupportListener) getService - (wait for thread 2 to
release the lock)
Tried to replicate the scenario [^WebconsoleServiceListeners.patch]. The test
in this patch file fails due to timeout.
On taking thread snapshot you may see the thread blocked and waiting for each
other. [^BlockedThreads.png]
Shouldn't these all listener fields and parent class be using the shared lock
instead of sychronized methods
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11438) Resource path consisting of %7D with multiple dots leads to path traversal
[ https://issues.apache.org/jira/browse/SLING-11438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17563058#comment-17563058 ] Sagar Miglani commented on SLING-11438: --- Potential fix: [https://github.com/apache/sling-org-apache-sling-engine/pull/23] > Resource path consisting of %7D with multiple dots leads to path traversal > -- > > Key: SLING-11438 > URL: https://issues.apache.org/jira/browse/SLING-11438 > Project: Sling > Issue Type: Bug > Components: Engine >Affects Versions: Engine 2.9.0 >Reporter: Sagar Miglani >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > With changes of SLING-10225, sling-engine started considering requests > consisting of resource path with %5B ([) and multiple dots as "Invalid", as > it could lead to path traversal and exposure of repository content. > But same could happen with %7D (}) with multiple dots in the request resource > path. > e.g: > http://:/content/we-retail/us/en/experience.html/.%7D./.%7D./.1.json > would lead to exposure of repository content stored at /content/we-retail/us -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-11438) Resource path consisting of %7D with multiple dots leads to path traversal
[ https://issues.apache.org/jira/browse/SLING-11438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sagar Miglani updated SLING-11438: -- Summary: Resource path consisting of %7D with multiple dots leads to path traversal (was: Resource path consising of %7D with multiple dots leads to path traversal) > Resource path consisting of %7D with multiple dots leads to path traversal > -- > > Key: SLING-11438 > URL: https://issues.apache.org/jira/browse/SLING-11438 > Project: Sling > Issue Type: Bug > Components: Engine >Affects Versions: Engine 2.9.0 >Reporter: Sagar Miglani >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > With changes of SLING-10225, sling-engine started considering requests > consisting of resource path with %5B ([) and multiple dots as "Invalid", as > it could lead to path traversal and exposure of repository content. > But same could happen with %7D (}) with multiple dots in the request resource > path. > e.g: > http://:/content/we-retail/us/en/experience.html/.%7D./.%7D./.1.json > would lead to exposure of repository content stored at /content/we-retail/us -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-11438) Resource path consising of %7D with multiple dots leads to path traversal
Sagar Miglani created SLING-11438: - Summary: Resource path consising of %7D with multiple dots leads to path traversal Key: SLING-11438 URL: https://issues.apache.org/jira/browse/SLING-11438 Project: Sling Issue Type: Bug Components: Engine Affects Versions: Engine 2.9.0 Reporter: Sagar Miglani With changes of SLING-10225, sling-engine started considering requests consisting of resource path with %5B ([) and multiple dots as "Invalid", as it could lead to path traversal and exposure of repository content. But same could happen with %7D (}) with multiple dots in the request resource path. e.g: http://:/content/we-retail/us/en/experience.html/.%7D./.%7D./.1.json would lead to exposure of repository content stored at /content/we-retail/us -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-11261) Exception while starting CodehaleMetricsReporter component on Windows Machine
[
https://issues.apache.org/jira/browse/SLING-11261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17524249#comment-17524249
]
Sagar Miglani commented on SLING-11261:
---
Thanks [~rombert] !
> Exception while starting CodehaleMetricsReporter component on Windows Machine
> -
>
> Key: SLING-11261
> URL: https://issues.apache.org/jira/browse/SLING-11261
> Project: Sling
> Issue Type: Bug
> Components: Commons
> Environment: OS: Windows machine
>Reporter: Sagar Miglani
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Commons Metrics RRD4J 1.0.6
>
> Attachments: RRD4JReporterProblem.java
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> On windows machine, I am getting the following Exception for while starting
> the CodehaleMetricsReporter component
> {code:xml}
> java.nio.file.InvalidPathException: Illegal char <:> at index 2:
> /C:/playground/rrd4j/metrics/metrics.rrd
> at sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
> at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
> at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
> at sun.nio.fs.WindowsPath.parse(WindowsPath.java:94)
> at sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:255)
> at java.nio.file.Paths.get(Paths.java:84)
> at
> org.rrd4j.core.RrdFileBackendFactory.exists(RrdFileBackendFactory.java:26)
> at org.rrd4j.core.RrdBackendFactory.exists(RrdBackendFactory.java:543)
> at org.rrd4j.core.RrdDb.(RrdDb.java:624)
> at org.rrd4j.core.RrdDb.of(RrdDb.java:500)
> {code}
> This is because we are creating RrdDB by passing the path returned by
> RrdDef.getPath() method (see
> [here|https://github.com/apache/sling-org-apache-sling-commons-metrics-rrd4j/blob/master/src/main/java/org/apache/sling/commons/metrics/rrd4j/impl/RRD4JReporter.java#L374])
> which does not return the path correctly and is unreliable as discussed
> [here|https://github.com/rrd4j/rrd4j/issues/152] and It is suggested to use
> RrdDef.getUri() instead.
> Also, while creating the RrdDef with a path RRD4J lib creates an internal
> generic URI which again can not be use directly for creating the File or
> Paths api as this generic URI could be non-absolute in some cases.
> Attaching the test case which should fail on windows machine.
> [^RRD4JReporterProblem.java]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SLING-11261) Exception while starting CodehaleMetricsReporter component on Windows Machine
[
https://issues.apache.org/jira/browse/SLING-11261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sagar Miglani updated SLING-11261:
--
Description:
On windows machine, I am getting the following Exception for while starting the
CodehaleMetricsReporter component
{code:xml}
java.nio.file.InvalidPathException: Illegal char <:> at index 2:
/C:/playground/rrd4j/metrics/metrics.rrd
at sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
at sun.nio.fs.WindowsPath.parse(WindowsPath.java:94)
at sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:255)
at java.nio.file.Paths.get(Paths.java:84)
at
org.rrd4j.core.RrdFileBackendFactory.exists(RrdFileBackendFactory.java:26)
at org.rrd4j.core.RrdBackendFactory.exists(RrdBackendFactory.java:543)
at org.rrd4j.core.RrdDb.(RrdDb.java:624)
at org.rrd4j.core.RrdDb.of(RrdDb.java:500)
{code}
This is because we are creating RrdDB by passing the path returned by
RrdDef.getPath() method (see
[here|https://github.com/apache/sling-org-apache-sling-commons-metrics-rrd4j/blob/master/src/main/java/org/apache/sling/commons/metrics/rrd4j/impl/RRD4JReporter.java#L374])
which does not return the path correctly and is unreliable as discussed
[here|https://github.com/rrd4j/rrd4j/issues/152] and It is suggested to use
RrdDef.getUri() instead.
Also, while creating the RrdDef with a path RRD4J lib creates an internal
generic URI which again can not be use directly for creating the File or Paths
api as this generic URI could be non-absolute in some cases.
Attaching the test case which should fail on windows machine.
[^RRD4JReporterProblem.java]
was:
On windows machine, I am getting the following Exception for while starting the
CodehaleMetricsReporter component
{code:xml}
java.nio.file.InvalidPathException: Illegal char <:> at index 2:
/C:/playground/rrd4j/metrics/metrics.rrd
at sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
at sun.nio.fs.WindowsPath.parse(WindowsPath.java:94)
at sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:255)
at java.nio.file.Paths.get(Paths.java:84)
at
org.rrd4j.core.RrdFileBackendFactory.exists(RrdFileBackendFactory.java:26)
at org.rrd4j.core.RrdBackendFactory.exists(RrdBackendFactory.java:543)
at org.rrd4j.core.RrdDb.(RrdDb.java:624)
at org.rrd4j.core.RrdDb.of(RrdDb.java:500)
{code}
This is because the we creating RrdDB by passing the path returned by
RrdDef.getPath() method (see
[here|https://github.com/apache/sling-org-apache-sling-commons-metrics-rrd4j/blob/master/src/main/java/org/apache/sling/commons/metrics/rrd4j/impl/RRD4JReporter.java#L374])
which does not return the path correctly and is unreliable as discussed
[here|https://github.com/rrd4j/rrd4j/issues/152] and It is suggested to use
RrdDef.getUri() instead.
Also, while creating the RrdDef with a path RRD4J lib creates an internal
generic URI which again can not be use directly for creating the File or Paths
api as this generic URI could be non-absolute in some cases.
Attaching the test case which should fail on windows machine.
[^RRD4JReporterProblem.java]
> Exception while starting CodehaleMetricsReporter component on Windows Machine
> -
>
> Key: SLING-11261
> URL: https://issues.apache.org/jira/browse/SLING-11261
> Project: Sling
> Issue Type: Bug
> Components: Commons
> Environment: OS: Windows machine
>Reporter: Sagar Miglani
>Priority: Major
> Attachments: RRD4JReporterProblem.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> On windows machine, I am getting the following Exception for while starting
> the CodehaleMetricsReporter component
> {code:xml}
> java.nio.file.InvalidPathException: Illegal char <:> at index 2:
> /C:/playground/rrd4j/metrics/metrics.rrd
> at sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
> at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
> at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
> at sun.nio.fs.WindowsPath.parse(WindowsPath.java:94)
> at sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:255)
> at java.nio.file.Paths.get(Paths.java:84)
> at
> org.rrd4j.core.RrdFileBackendFactory.exists(RrdFileBackendFactory.java:26)
> at org.rrd4j.core.RrdBackendFactory.exists(RrdBackendFactory.java:543)
> at org.rrd
[jira] [Commented] (SLING-11261) Exception while starting CodehaleMetricsReporter component on Windows Machine
[
https://issues.apache.org/jira/browse/SLING-11261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17522117#comment-17522117
]
Sagar Miglani commented on SLING-11261:
---
PR:
[https://github.com/apache/sling-org-apache-sling-commons-metrics-rrd4j/pull/4]
> Exception while starting CodehaleMetricsReporter component on Windows Machine
> -
>
> Key: SLING-11261
> URL: https://issues.apache.org/jira/browse/SLING-11261
> Project: Sling
> Issue Type: Bug
> Components: Commons
> Environment: OS: Windows machine
>Reporter: Sagar Miglani
>Priority: Major
> Attachments: RRD4JReporterProblem.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> On windows machine, I am getting the following Exception for while starting
> the CodehaleMetricsReporter component
> {code:xml}
> java.nio.file.InvalidPathException: Illegal char <:> at index 2:
> /C:/playground/rrd4j/metrics/metrics.rrd
> at sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
> at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
> at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
> at sun.nio.fs.WindowsPath.parse(WindowsPath.java:94)
> at sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:255)
> at java.nio.file.Paths.get(Paths.java:84)
> at
> org.rrd4j.core.RrdFileBackendFactory.exists(RrdFileBackendFactory.java:26)
> at org.rrd4j.core.RrdBackendFactory.exists(RrdBackendFactory.java:543)
> at org.rrd4j.core.RrdDb.(RrdDb.java:624)
> at org.rrd4j.core.RrdDb.of(RrdDb.java:500)
> {code}
> This is because the we creating RrdDB by passing the path returned by
> RrdDef.getPath() method (see
> [here|https://github.com/apache/sling-org-apache-sling-commons-metrics-rrd4j/blob/master/src/main/java/org/apache/sling/commons/metrics/rrd4j/impl/RRD4JReporter.java#L374])
> which does not return the path correctly and is unreliable as discussed
> [here|https://github.com/rrd4j/rrd4j/issues/152] and It is suggested to use
> RrdDef.getUri() instead.
> Also, while creating the RrdDef with a path RRD4J lib creates an internal
> generic URI which again can not be use directly for creating the File or
> Paths api as this generic URI could be non-absolute in some cases.
> Attaching the test case which should fail on windows machine.
> [^RRD4JReporterProblem.java]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (SLING-11261) Exception while starting CodehaleMetricsReporter component on Windows Machine
Sagar Miglani created SLING-11261:
-
Summary: Exception while starting CodehaleMetricsReporter
component on Windows Machine
Key: SLING-11261
URL: https://issues.apache.org/jira/browse/SLING-11261
Project: Sling
Issue Type: Bug
Components: Commons
Environment: OS: Windows machine
Reporter: Sagar Miglani
Attachments: RRD4JReporterProblem.java
On windows machine, I am getting the following Exception for while starting the
CodehaleMetricsReporter component
{code:xml}
java.nio.file.InvalidPathException: Illegal char <:> at index 2:
/C:/playground/rrd4j/metrics/metrics.rrd
at sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
at sun.nio.fs.WindowsPath.parse(WindowsPath.java:94)
at sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:255)
at java.nio.file.Paths.get(Paths.java:84)
at
org.rrd4j.core.RrdFileBackendFactory.exists(RrdFileBackendFactory.java:26)
at org.rrd4j.core.RrdBackendFactory.exists(RrdBackendFactory.java:543)
at org.rrd4j.core.RrdDb.(RrdDb.java:624)
at org.rrd4j.core.RrdDb.of(RrdDb.java:500)
{code}
This is because the we creating RrdDB by passing the path returned by
RrdDef.getPath() method (see
[here|https://github.com/apache/sling-org-apache-sling-commons-metrics-rrd4j/blob/master/src/main/java/org/apache/sling/commons/metrics/rrd4j/impl/RRD4JReporter.java#L374])
which does not return the path correctly and is unreliable as discussed
[here|https://github.com/rrd4j/rrd4j/issues/152] and It is suggested to use
RrdDef.getUri() instead.
Also, while creating the RrdDef with a path RRD4J lib creates an internal
generic URI which again can not be use directly for creating the File or Paths
api as this generic URI could be non-absolute in some cases.
Attaching the test case which should fail on windows machine.
[^RRD4JReporterProblem.java]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SLING-7969) Memory leak in DiscoveryLiteDescriptor
[
https://issues.apache.org/jira/browse/SLING-7969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17503462#comment-17503462
]
Sagar Miglani commented on SLING-7969:
--
Thank you [~marett] [~stefanegli]
> Memory leak in DiscoveryLiteDescriptor
> --
>
> Key: SLING-7969
> URL: https://issues.apache.org/jira/browse/SLING-7969
> Project: Sling
> Issue Type: Bug
> Components: Discovery
>Affects Versions: Discovery Commons 1.0.20
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Labels: discovery
> Fix For: Discovery Commons 1.0.26
>
> Attachments: Screenshot 2022-03-07 at 1.05.33 PM.png, Screenshot
> 2022-03-07 at 1.14.57 PM-1.png, Screenshot 2022-03-07 at 1.14.57 PM.png,
> Screenshot 2022-03-07 at 1.18.07 PM.png, Screenshot 2022-03-07 at 1.18.16
> PM.png, Screenshot 2022-03-07 at 12.26.11 PM.png,
> org.apache.sling.commons.johnzon-1.1.11-SLING-7969.jar,
> org.apache.sling.discovery.commons-1.0.23-SLING-7969.jar
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As identified in [~volteanu]'s adaptTo
> [presentation|https://adapt.to/2018/en/schedule/sling-memory-deep-dive.html],
> it seems that Sling Discovery on Oak is consuming 42MB of RAM on a standard
> instance.
> Sling discovery deals with transient states (the views, leases, etc.) and is
> not caching significant amount of data. The 42MB figure for the discovery
> feature seems like a symptom of a memory leak.
> [~volteanu] shared in his presentation that the 42MB worth of RAM was mainly
> consumed by a Json Factory reference. There is one static JsonReaderFactory
> in the discovery commons module, in the
> [DiscoveryLiteDescriptor|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java].
> Looking at the code, it seems that each invocation of the
> [getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
> method creates a JSON reader but never close it. This may may leave
> resources behind as hinted by the description of the
> [close|https://docs.oracle.com/javaee/7/api/javax/json/JsonReader.html#close--]
> method in the API. AFAIK, the
> [getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
> is invoked periodically on a relatively high frequency (< seconds) which may
> be the trigger for the leak on all instances.
> This is only a supposition for now, it should be investigated further, simply
> by running a patched version of \{{org.apache.sling.discovery.commons}} that
> make sure each JSON reader is properly closed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (SLING-7969) Memory leak in DiscoveryLiteDescriptor
[ https://issues.apache.org/jira/browse/SLING-7969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502181#comment-17502181 ] Sagar Miglani edited comment on SLING-7969 at 3/8/22, 7:23 AM: --- Hi [~marett], I checked the memory dumps of few AEM instances, and here are the findings: *1)* In an instance having johnzon lib version < 1.1.4, I found that DiscoveryLiteDescriptor having retained memory size of ~40MBs, this big memory reference is stored when close method of the [JsonStreamParserImpl|https://github.com/apache/johnzon/blob/v1.1.0/johnzon-core/src/main/java/org/apache/johnzon/core/JsonStreamParserImpl.java#L921] is called. [Close method stores|https://github.com/apache/johnzon/blob/v1.1.0/johnzon-core/src/main/java/org/apache/johnzon/core/BufferStrategy.java#L241] the released buffer in a queue (which is default BufferStrategy in Johnzon) for [future re-use|https://github.com/apache/johnzon/blob/v1.1.0/johnzon-core/src/main/java/org/apache/johnzon/core/BufferStrategy.java#L232]. And because default buffer size(length) was 10MB before johnzon 1.1.4, each stored buffer will take ~20MB Also note that the close method was interally being called [after reading the json|https://github.com/apache/johnzon/blob/v1.1.0/johnzon-core/src/main/java/org/apache/johnzon/core/JsonReaderImpl.java#L65] in older versions of johnzon. So, DiscoveryLiteDescriptor whether called close or not, buffer was still getting released (stored in queue). !Screenshot 2022-03-07 at 12.26.11 PM.png! *2)* When I tried the same with johnzon lib version > 1.1.4 (used 1.2.8, sling-commons-johnzon is already available with this new version), I found that the memory footprint was much low. Also, In this version of johnzon close method was not being called by the JsonReader after reading, so buffer was never being released (stored in the queue) and while creating the new JsonReader, always [new buffer was created|https://github.com/apache/johnzon/blob/v1.1.0/johnzon-core/src/main/java/org/apache/johnzon/core/BufferStrategy.java#L234]. *But I believe we should close the JsonReader as you provided in this [patch|https://github.com/tmaret/sling-org-apache-sling-discovery-commons/commit/edba8e9d8a5ec21f6a95945440e9c9825f00e666] (to clear the resources), WDYT? Can you please provide the fix in new release of Discovery Commons?* Dump ss without the [patch|https://github.com/tmaret/sling-org-apache-sling-discovery-commons/commit/edba8e9d8a5ec21f6a95945440e9c9825f00e666]: !Screenshot 2022-03-07 at 1.05.33 PM.png! Dump ss with the [patch|https://github.com/tmaret/sling-org-apache-sling-discovery-commons/commit/edba8e9d8a5ec21f6a95945440e9c9825f00e666]: !Screenshot 2022-03-07 at 1.14.57 PM.png! *3)* Apart from the above, I found that an instance of older version of JsonProviderImpl was present which was causing the similar problem and I belive that should be coming from the sling-installer-core version 3.9.0 (present in my instance) which was [embedding|https://github.com/apache/sling-org-apache-sling-installer-core/blob/org.apache.sling.installer.core-3.9.0/pom.xml#L63] Johnzon core. Newer version (3.11.0+) of sling-installer-core should not have this issue. !Screenshot 2022-03-07 at 1.18.16 PM.png! !Screenshot 2022-03-07 at 1.18.07 PM.png! was (Author: sagarmiglani): Hi [~marett], I checked the memory dumps of few AEM instances, and here are the findings: *1)* In an instance having johnzon lib version < 1.1.4, I found that DiscoveryLiteDescriptor having retained memory size of ~40MBs, this big memory reference is stored when close method of the [JsonStreamParserImpl|https://github.com/apache/johnzon/blob/v1.1.0/johnzon-core/src/main/java/org/apache/johnzon/core/JsonStreamParserImpl.java#L921] is called. [Close method stores|https://github.com/apache/johnzon/blob/v1.1.0/johnzon-core/src/main/java/org/apache/johnzon/core/BufferStrategy.java#L241] the released buffer in a queue (which is default BufferStrategy in Johnzon) for [future re-use|https://github.com/apache/johnzon/blob/v1.1.0/johnzon-core/src/main/java/org/apache/johnzon/core/BufferStrategy.java#L232]. And because default buffer size(length) was 10MB before johnzon 1.1.4, each stored buffer will take ~20MB Also note that the close method was interally being called [after reading the json|https://github.com/apache/johnzon/blob/v1.1.0/johnzon-core/src/main/java/org/apache/johnzon/core/JsonReaderImpl.java#L65] in older versions of johnzon. So, DiscoveryLiteDescriptor whether called close or not, buffer was still getting released (stored in queue). !Screenshot 2022-03-07 at 12.26.11 PM.png! *2)* When I tried the same with johnzon lib version > 1.1.4 (used 1.2.8, sling-commons-johnzon is already available with this new version), I found that the memory footprint was much low. Also, In this version of johnzon close method was n
[jira] [Commented] (SLING-7969) Memory leak in DiscoveryLiteDescriptor
[ https://issues.apache.org/jira/browse/SLING-7969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502181#comment-17502181 ] Sagar Miglani commented on SLING-7969: -- Hi [~marett], I checked the memory dumps of few AEM instances, and here are the findings: *1)* In an instance having johnzon lib version < 1.1.4, I found that DiscoveryLiteDescriptor having retained memory size of ~40MBs, this big memory reference is stored when close method of the [JsonStreamParserImpl|https://github.com/apache/johnzon/blob/v1.1.0/johnzon-core/src/main/java/org/apache/johnzon/core/JsonStreamParserImpl.java#L921] is called. [Close method stores|https://github.com/apache/johnzon/blob/v1.1.0/johnzon-core/src/main/java/org/apache/johnzon/core/BufferStrategy.java#L241] the released buffer in a queue (which is default BufferStrategy in Johnzon) for [future re-use|https://github.com/apache/johnzon/blob/v1.1.0/johnzon-core/src/main/java/org/apache/johnzon/core/BufferStrategy.java#L232]. And because default buffer size(length) was 10MB before johnzon 1.1.4, each stored buffer will take ~20MB Also note that the close method was interally being called [after reading the json|https://github.com/apache/johnzon/blob/v1.1.0/johnzon-core/src/main/java/org/apache/johnzon/core/JsonReaderImpl.java#L65] in older versions of johnzon. So, DiscoveryLiteDescriptor whether called close or not, buffer was still getting released (stored in queue). !Screenshot 2022-03-07 at 12.26.11 PM.png! *2)* When I tried the same with johnzon lib version > 1.1.4 (used 1.2.8, sling-commons-johnzon is already available with this new version), I found that the memory footprint was much low. Also, In this version of johnzon close method was not being called by the JsonReader after reading, so buffer was never being released (stored in the queue) and while creating the new JsonReader, always [new buffer was created|https://github.com/apache/johnzon/blob/v1.1.0/johnzon-core/src/main/java/org/apache/johnzon/core/BufferStrategy.java#L234]. *But I believe we should close the JsonReader as you provided in this [patch|https://github.com/tmaret/sling-org-apache-sling-discovery-commons/commit/edba8e9d8a5ec21f6a95945440e9c9825f00e666], WDYT? Can you please provide the fix in new release of Discovery Commons?* Dump ss without the [patch|https://github.com/tmaret/sling-org-apache-sling-discovery-commons/commit/edba8e9d8a5ec21f6a95945440e9c9825f00e666]: !Screenshot 2022-03-07 at 1.05.33 PM.png! Dump ss with the [patch|https://github.com/tmaret/sling-org-apache-sling-discovery-commons/commit/edba8e9d8a5ec21f6a95945440e9c9825f00e666]: !Screenshot 2022-03-07 at 1.14.57 PM.png! *3)* Apart from the above, I found that an instance of older version of JsonProviderImpl was present which was causing the similar problem and I belive that should be coming from the sling-installer-core version 3.9.0 (present in my instance) which was [embedding|https://github.com/apache/sling-org-apache-sling-installer-core/blob/org.apache.sling.installer.core-3.9.0/pom.xml#L63] Johnzon core. Newer version of sling-installer-core should not have this issue. !Screenshot 2022-03-07 at 1.18.16 PM.png! !Screenshot 2022-03-07 at 1.18.07 PM.png! > Memory leak in DiscoveryLiteDescriptor > -- > > Key: SLING-7969 > URL: https://issues.apache.org/jira/browse/SLING-7969 > Project: Sling > Issue Type: Bug > Components: Discovery >Affects Versions: Discovery Commons 1.0.20 >Reporter: Timothee Maret >Assignee: Timothee Maret >Priority: Major > Labels: discovery > Attachments: Screenshot 2022-03-07 at 1.05.33 PM.png, Screenshot > 2022-03-07 at 1.14.57 PM-1.png, Screenshot 2022-03-07 at 1.14.57 PM.png, > Screenshot 2022-03-07 at 1.18.07 PM.png, Screenshot 2022-03-07 at 1.18.16 > PM.png, Screenshot 2022-03-07 at 12.26.11 PM.png, > org.apache.sling.commons.johnzon-1.1.11-SLING-7969.jar, > org.apache.sling.discovery.commons-1.0.23-SLING-7969.jar > > > As identified in [~volteanu]'s adaptTo > [presentation|https://adapt.to/2018/en/schedule/sling-memory-deep-dive.html], > it seems that Sling Discovery on Oak is consuming 42MB of RAM on a standard > instance. > Sling discovery deals with transient states (the views, leases, etc.) and is > not caching significant amount of data. The 42MB figure for the discovery > feature seems like a symptom of a memory leak. > [~volteanu] shared in his presentation that the 42MB worth of RAM was mainly > consumed by a Json Factory reference. There is one static JsonReaderFactory > in the discovery commons module, in the > [DiscoveryLiteDescriptor|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLit
[jira] [Updated] (SLING-7969) Memory leak in DiscoveryLiteDescriptor
[
https://issues.apache.org/jira/browse/SLING-7969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sagar Miglani updated SLING-7969:
-
Attachment: Screenshot 2022-03-07 at 1.18.07 PM.png
> Memory leak in DiscoveryLiteDescriptor
> --
>
> Key: SLING-7969
> URL: https://issues.apache.org/jira/browse/SLING-7969
> Project: Sling
> Issue Type: Bug
> Components: Discovery
>Affects Versions: Discovery Commons 1.0.20
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Labels: discovery
> Attachments: Screenshot 2022-03-07 at 1.05.33 PM.png, Screenshot
> 2022-03-07 at 1.14.57 PM-1.png, Screenshot 2022-03-07 at 1.14.57 PM.png,
> Screenshot 2022-03-07 at 1.18.07 PM.png, Screenshot 2022-03-07 at 1.18.16
> PM.png, Screenshot 2022-03-07 at 12.26.11 PM.png,
> org.apache.sling.commons.johnzon-1.1.11-SLING-7969.jar,
> org.apache.sling.discovery.commons-1.0.23-SLING-7969.jar
>
>
> As identified in [~volteanu]'s adaptTo
> [presentation|https://adapt.to/2018/en/schedule/sling-memory-deep-dive.html],
> it seems that Sling Discovery on Oak is consuming 42MB of RAM on a standard
> instance.
> Sling discovery deals with transient states (the views, leases, etc.) and is
> not caching significant amount of data. The 42MB figure for the discovery
> feature seems like a symptom of a memory leak.
> [~volteanu] shared in his presentation that the 42MB worth of RAM was mainly
> consumed by a Json Factory reference. There is one static JsonReaderFactory
> in the discovery commons module, in the
> [DiscoveryLiteDescriptor|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java].
> Looking at the code, it seems that each invocation of the
> [getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
> method creates a JSON reader but never close it. This may may leave
> resources behind as hinted by the description of the
> [close|https://docs.oracle.com/javaee/7/api/javax/json/JsonReader.html#close--]
> method in the API. AFAIK, the
> [getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
> is invoked periodically on a relatively high frequency (< seconds) which may
> be the trigger for the leak on all instances.
> This is only a supposition for now, it should be investigated further, simply
> by running a patched version of \{{org.apache.sling.discovery.commons}} that
> make sure each JSON reader is properly closed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SLING-7969) Memory leak in DiscoveryLiteDescriptor
[
https://issues.apache.org/jira/browse/SLING-7969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sagar Miglani updated SLING-7969:
-
Attachment: (was: Screenshot 2022-03-07 at 1.18.16 PM-1.png)
> Memory leak in DiscoveryLiteDescriptor
> --
>
> Key: SLING-7969
> URL: https://issues.apache.org/jira/browse/SLING-7969
> Project: Sling
> Issue Type: Bug
> Components: Discovery
>Affects Versions: Discovery Commons 1.0.20
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Labels: discovery
> Attachments: Screenshot 2022-03-07 at 1.05.33 PM.png, Screenshot
> 2022-03-07 at 1.14.57 PM-1.png, Screenshot 2022-03-07 at 1.14.57 PM.png,
> Screenshot 2022-03-07 at 1.18.16 PM.png, Screenshot 2022-03-07 at 12.26.11
> PM.png, org.apache.sling.commons.johnzon-1.1.11-SLING-7969.jar,
> org.apache.sling.discovery.commons-1.0.23-SLING-7969.jar
>
>
> As identified in [~volteanu]'s adaptTo
> [presentation|https://adapt.to/2018/en/schedule/sling-memory-deep-dive.html],
> it seems that Sling Discovery on Oak is consuming 42MB of RAM on a standard
> instance.
> Sling discovery deals with transient states (the views, leases, etc.) and is
> not caching significant amount of data. The 42MB figure for the discovery
> feature seems like a symptom of a memory leak.
> [~volteanu] shared in his presentation that the 42MB worth of RAM was mainly
> consumed by a Json Factory reference. There is one static JsonReaderFactory
> in the discovery commons module, in the
> [DiscoveryLiteDescriptor|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java].
> Looking at the code, it seems that each invocation of the
> [getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
> method creates a JSON reader but never close it. This may may leave
> resources behind as hinted by the description of the
> [close|https://docs.oracle.com/javaee/7/api/javax/json/JsonReader.html#close--]
> method in the API. AFAIK, the
> [getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
> is invoked periodically on a relatively high frequency (< seconds) which may
> be the trigger for the leak on all instances.
> This is only a supposition for now, it should be investigated further, simply
> by running a patched version of \{{org.apache.sling.discovery.commons}} that
> make sure each JSON reader is properly closed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SLING-7969) Memory leak in DiscoveryLiteDescriptor
[
https://issues.apache.org/jira/browse/SLING-7969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sagar Miglani updated SLING-7969:
-
Attachment: Screenshot 2022-03-07 at 1.18.16 PM-1.png
> Memory leak in DiscoveryLiteDescriptor
> --
>
> Key: SLING-7969
> URL: https://issues.apache.org/jira/browse/SLING-7969
> Project: Sling
> Issue Type: Bug
> Components: Discovery
>Affects Versions: Discovery Commons 1.0.20
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Labels: discovery
> Attachments: Screenshot 2022-03-07 at 1.05.33 PM.png, Screenshot
> 2022-03-07 at 1.14.57 PM-1.png, Screenshot 2022-03-07 at 1.14.57 PM.png,
> Screenshot 2022-03-07 at 1.18.16 PM.png, Screenshot 2022-03-07 at 12.26.11
> PM.png, org.apache.sling.commons.johnzon-1.1.11-SLING-7969.jar,
> org.apache.sling.discovery.commons-1.0.23-SLING-7969.jar
>
>
> As identified in [~volteanu]'s adaptTo
> [presentation|https://adapt.to/2018/en/schedule/sling-memory-deep-dive.html],
> it seems that Sling Discovery on Oak is consuming 42MB of RAM on a standard
> instance.
> Sling discovery deals with transient states (the views, leases, etc.) and is
> not caching significant amount of data. The 42MB figure for the discovery
> feature seems like a symptom of a memory leak.
> [~volteanu] shared in his presentation that the 42MB worth of RAM was mainly
> consumed by a Json Factory reference. There is one static JsonReaderFactory
> in the discovery commons module, in the
> [DiscoveryLiteDescriptor|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java].
> Looking at the code, it seems that each invocation of the
> [getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
> method creates a JSON reader but never close it. This may may leave
> resources behind as hinted by the description of the
> [close|https://docs.oracle.com/javaee/7/api/javax/json/JsonReader.html#close--]
> method in the API. AFAIK, the
> [getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
> is invoked periodically on a relatively high frequency (< seconds) which may
> be the trigger for the leak on all instances.
> This is only a supposition for now, it should be investigated further, simply
> by running a patched version of \{{org.apache.sling.discovery.commons}} that
> make sure each JSON reader is properly closed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SLING-7969) Memory leak in DiscoveryLiteDescriptor
[
https://issues.apache.org/jira/browse/SLING-7969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sagar Miglani updated SLING-7969:
-
Attachment: Screenshot 2022-03-07 at 1.18.16 PM.png
> Memory leak in DiscoveryLiteDescriptor
> --
>
> Key: SLING-7969
> URL: https://issues.apache.org/jira/browse/SLING-7969
> Project: Sling
> Issue Type: Bug
> Components: Discovery
>Affects Versions: Discovery Commons 1.0.20
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Labels: discovery
> Attachments: Screenshot 2022-03-07 at 1.05.33 PM.png, Screenshot
> 2022-03-07 at 1.14.57 PM-1.png, Screenshot 2022-03-07 at 1.14.57 PM.png,
> Screenshot 2022-03-07 at 1.18.16 PM.png, Screenshot 2022-03-07 at 12.26.11
> PM.png, org.apache.sling.commons.johnzon-1.1.11-SLING-7969.jar,
> org.apache.sling.discovery.commons-1.0.23-SLING-7969.jar
>
>
> As identified in [~volteanu]'s adaptTo
> [presentation|https://adapt.to/2018/en/schedule/sling-memory-deep-dive.html],
> it seems that Sling Discovery on Oak is consuming 42MB of RAM on a standard
> instance.
> Sling discovery deals with transient states (the views, leases, etc.) and is
> not caching significant amount of data. The 42MB figure for the discovery
> feature seems like a symptom of a memory leak.
> [~volteanu] shared in his presentation that the 42MB worth of RAM was mainly
> consumed by a Json Factory reference. There is one static JsonReaderFactory
> in the discovery commons module, in the
> [DiscoveryLiteDescriptor|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java].
> Looking at the code, it seems that each invocation of the
> [getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
> method creates a JSON reader but never close it. This may may leave
> resources behind as hinted by the description of the
> [close|https://docs.oracle.com/javaee/7/api/javax/json/JsonReader.html#close--]
> method in the API. AFAIK, the
> [getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
> is invoked periodically on a relatively high frequency (< seconds) which may
> be the trigger for the leak on all instances.
> This is only a supposition for now, it should be investigated further, simply
> by running a patched version of \{{org.apache.sling.discovery.commons}} that
> make sure each JSON reader is properly closed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SLING-7969) Memory leak in DiscoveryLiteDescriptor
[
https://issues.apache.org/jira/browse/SLING-7969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sagar Miglani updated SLING-7969:
-
Attachment: Screenshot 2022-03-07 at 1.14.57 PM-1.png
> Memory leak in DiscoveryLiteDescriptor
> --
>
> Key: SLING-7969
> URL: https://issues.apache.org/jira/browse/SLING-7969
> Project: Sling
> Issue Type: Bug
> Components: Discovery
>Affects Versions: Discovery Commons 1.0.20
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Labels: discovery
> Attachments: Screenshot 2022-03-07 at 1.05.33 PM.png, Screenshot
> 2022-03-07 at 1.14.57 PM-1.png, Screenshot 2022-03-07 at 1.14.57 PM.png,
> Screenshot 2022-03-07 at 12.26.11 PM.png,
> org.apache.sling.commons.johnzon-1.1.11-SLING-7969.jar,
> org.apache.sling.discovery.commons-1.0.23-SLING-7969.jar
>
>
> As identified in [~volteanu]'s adaptTo
> [presentation|https://adapt.to/2018/en/schedule/sling-memory-deep-dive.html],
> it seems that Sling Discovery on Oak is consuming 42MB of RAM on a standard
> instance.
> Sling discovery deals with transient states (the views, leases, etc.) and is
> not caching significant amount of data. The 42MB figure for the discovery
> feature seems like a symptom of a memory leak.
> [~volteanu] shared in his presentation that the 42MB worth of RAM was mainly
> consumed by a Json Factory reference. There is one static JsonReaderFactory
> in the discovery commons module, in the
> [DiscoveryLiteDescriptor|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java].
> Looking at the code, it seems that each invocation of the
> [getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
> method creates a JSON reader but never close it. This may may leave
> resources behind as hinted by the description of the
> [close|https://docs.oracle.com/javaee/7/api/javax/json/JsonReader.html#close--]
> method in the API. AFAIK, the
> [getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
> is invoked periodically on a relatively high frequency (< seconds) which may
> be the trigger for the leak on all instances.
> This is only a supposition for now, it should be investigated further, simply
> by running a patched version of \{{org.apache.sling.discovery.commons}} that
> make sure each JSON reader is properly closed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SLING-7969) Memory leak in DiscoveryLiteDescriptor
[
https://issues.apache.org/jira/browse/SLING-7969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sagar Miglani updated SLING-7969:
-
Attachment: Screenshot 2022-03-07 at 12.26.11 PM.png
> Memory leak in DiscoveryLiteDescriptor
> --
>
> Key: SLING-7969
> URL: https://issues.apache.org/jira/browse/SLING-7969
> Project: Sling
> Issue Type: Bug
> Components: Discovery
>Affects Versions: Discovery Commons 1.0.20
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Labels: discovery
> Attachments: Screenshot 2022-03-07 at 1.05.33 PM.png, Screenshot
> 2022-03-07 at 1.14.57 PM.png, Screenshot 2022-03-07 at 12.26.11 PM.png,
> org.apache.sling.commons.johnzon-1.1.11-SLING-7969.jar,
> org.apache.sling.discovery.commons-1.0.23-SLING-7969.jar
>
>
> As identified in [~volteanu]'s adaptTo
> [presentation|https://adapt.to/2018/en/schedule/sling-memory-deep-dive.html],
> it seems that Sling Discovery on Oak is consuming 42MB of RAM on a standard
> instance.
> Sling discovery deals with transient states (the views, leases, etc.) and is
> not caching significant amount of data. The 42MB figure for the discovery
> feature seems like a symptom of a memory leak.
> [~volteanu] shared in his presentation that the 42MB worth of RAM was mainly
> consumed by a Json Factory reference. There is one static JsonReaderFactory
> in the discovery commons module, in the
> [DiscoveryLiteDescriptor|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java].
> Looking at the code, it seems that each invocation of the
> [getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
> method creates a JSON reader but never close it. This may may leave
> resources behind as hinted by the description of the
> [close|https://docs.oracle.com/javaee/7/api/javax/json/JsonReader.html#close--]
> method in the API. AFAIK, the
> [getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
> is invoked periodically on a relatively high frequency (< seconds) which may
> be the trigger for the leak on all instances.
> This is only a supposition for now, it should be investigated further, simply
> by running a patched version of \{{org.apache.sling.discovery.commons}} that
> make sure each JSON reader is properly closed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SLING-7969) Memory leak in DiscoveryLiteDescriptor
[
https://issues.apache.org/jira/browse/SLING-7969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sagar Miglani updated SLING-7969:
-
Attachment: Screenshot 2022-03-07 at 1.14.57 PM.png
> Memory leak in DiscoveryLiteDescriptor
> --
>
> Key: SLING-7969
> URL: https://issues.apache.org/jira/browse/SLING-7969
> Project: Sling
> Issue Type: Bug
> Components: Discovery
>Affects Versions: Discovery Commons 1.0.20
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Labels: discovery
> Attachments: Screenshot 2022-03-07 at 1.05.33 PM.png, Screenshot
> 2022-03-07 at 1.14.57 PM.png, Screenshot 2022-03-07 at 12.26.11 PM.png,
> org.apache.sling.commons.johnzon-1.1.11-SLING-7969.jar,
> org.apache.sling.discovery.commons-1.0.23-SLING-7969.jar
>
>
> As identified in [~volteanu]'s adaptTo
> [presentation|https://adapt.to/2018/en/schedule/sling-memory-deep-dive.html],
> it seems that Sling Discovery on Oak is consuming 42MB of RAM on a standard
> instance.
> Sling discovery deals with transient states (the views, leases, etc.) and is
> not caching significant amount of data. The 42MB figure for the discovery
> feature seems like a symptom of a memory leak.
> [~volteanu] shared in his presentation that the 42MB worth of RAM was mainly
> consumed by a Json Factory reference. There is one static JsonReaderFactory
> in the discovery commons module, in the
> [DiscoveryLiteDescriptor|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java].
> Looking at the code, it seems that each invocation of the
> [getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
> method creates a JSON reader but never close it. This may may leave
> resources behind as hinted by the description of the
> [close|https://docs.oracle.com/javaee/7/api/javax/json/JsonReader.html#close--]
> method in the API. AFAIK, the
> [getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
> is invoked periodically on a relatively high frequency (< seconds) which may
> be the trigger for the leak on all instances.
> This is only a supposition for now, it should be investigated further, simply
> by running a patched version of \{{org.apache.sling.discovery.commons}} that
> make sure each JSON reader is properly closed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SLING-7969) Memory leak in DiscoveryLiteDescriptor
[
https://issues.apache.org/jira/browse/SLING-7969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sagar Miglani updated SLING-7969:
-
Attachment: Screenshot 2022-03-07 at 1.05.33 PM.png
> Memory leak in DiscoveryLiteDescriptor
> --
>
> Key: SLING-7969
> URL: https://issues.apache.org/jira/browse/SLING-7969
> Project: Sling
> Issue Type: Bug
> Components: Discovery
>Affects Versions: Discovery Commons 1.0.20
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Labels: discovery
> Attachments: Screenshot 2022-03-07 at 1.05.33 PM.png, Screenshot
> 2022-03-07 at 1.14.57 PM.png, Screenshot 2022-03-07 at 12.26.11 PM.png,
> org.apache.sling.commons.johnzon-1.1.11-SLING-7969.jar,
> org.apache.sling.discovery.commons-1.0.23-SLING-7969.jar
>
>
> As identified in [~volteanu]'s adaptTo
> [presentation|https://adapt.to/2018/en/schedule/sling-memory-deep-dive.html],
> it seems that Sling Discovery on Oak is consuming 42MB of RAM on a standard
> instance.
> Sling discovery deals with transient states (the views, leases, etc.) and is
> not caching significant amount of data. The 42MB figure for the discovery
> feature seems like a symptom of a memory leak.
> [~volteanu] shared in his presentation that the 42MB worth of RAM was mainly
> consumed by a Json Factory reference. There is one static JsonReaderFactory
> in the discovery commons module, in the
> [DiscoveryLiteDescriptor|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java].
> Looking at the code, it seems that each invocation of the
> [getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
> method creates a JSON reader but never close it. This may may leave
> resources behind as hinted by the description of the
> [close|https://docs.oracle.com/javaee/7/api/javax/json/JsonReader.html#close--]
> method in the API. AFAIK, the
> [getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
> is invoked periodically on a relatively high frequency (< seconds) which may
> be the trigger for the leak on all instances.
> This is only a supposition for now, it should be investigated further, simply
> by running a patched version of \{{org.apache.sling.discovery.commons}} that
> make sure each JSON reader is properly closed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SLING-11132) Exception handling while clearing OSGiServiceReferences
[
https://issues.apache.org/jira/browse/SLING-11132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489980#comment-17489980
]
Sagar Miglani commented on SLING-11132:
---
PR link: [https://github.com/apache/sling-org-apache-sling-models-impl/pull/34]
Added a try - catch block.
> Exception handling while clearing OSGiServiceReferences
> ---
>
> Key: SLING-11132
> URL: https://issues.apache.org/jira/browse/SLING-11132
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Affects Versions: Models Implementation 1.5.0
>Reporter: Sagar Miglani
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *"Sling Models OSGi Service Disposal Job"* to clean the OSGi service
> references does not do any error handling.
> If a ungetting of a reference [0] is failed due to some exception (like
> java.lang.IllegalStateException: Invalid BundleContext) no more references
> present in queue are cleaned up in same job trigger. The next reference in
> queue will be tried after 30 seconds (default) in next job trigger.
> Therefore, it may take an hour to clean up 120 references with an error.
> To reproduce this:
> # Create a model consisting of OSGiService Injection
> # Use this model in a page
> # Open the created page and refresh it couple of time (10-15)
> # Restart the bundle with model created in step 1
> # One may see the following exceptions in the logs (after every ~30 seconds
> to clear up the OSGi service references)
> {code:xml}
> 01.02.2021 14:31:03.639 *ERROR* [sling-default-1-Sling Models OSGi Service
> Disposal Job] org.apache.sling.commons.scheduler.impl.QuartzScheduler
> Exception during job execution of job
> 'org.apache.sling.models.impl.ModelAdapterFactory@1b834b3c' with name 'Sling
> Models OSGi Service Disposal Job' : Invalid BundleContext.
> java.lang.IllegalStateException: Invalid BundleContext.
> at
> org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:491)
> at
> org.apache.felix.framework.BundleContextImpl.ungetService(BundleContextImpl.java:455)
> at
> org.apache.sling.models.impl.injectors.OSGiServiceInjector$Callback.onDisposed(OSGiServiceInjector.java:203)
> [org.apache.sling.models.impl:1.4.16]
> at
> org.apache.sling.models.impl.ModelAdapterFactory$DisposalCallbackRegistryImpl.onDisposed(ModelAdapterFactory.java:143)
> [org.apache.sling.models.impl:1.4.16]
> at
> org.apache.sling.models.impl.ModelAdapterFactory.clearDisposalCallbackRegistryQueue(ModelAdapterFactory.java:214)
> [org.apache.sling.models.impl:1.4.16]
> at
> org.apache.sling.models.impl.ModelAdapterFactory.run(ModelAdapterFactory.java:206)
> [org.apache.sling.models.impl:1.4.16]
> at
> org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:349)
> [org.apache.sling.commons.scheduler:2.7.12]
> at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
> [org.apache.sling.commons.scheduler:2.7.12]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> {code}
> [0]:
> https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/injectors/OSGiServiceInjector.java#L207
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (SLING-11132) Exception handling while clearing OSGiServiceReferences
Sagar Miglani created SLING-11132:
-
Summary: Exception handling while clearing OSGiServiceReferences
Key: SLING-11132
URL: https://issues.apache.org/jira/browse/SLING-11132
Project: Sling
Issue Type: Improvement
Components: Sling Models
Affects Versions: Models Implementation 1.5.0
Reporter: Sagar Miglani
*"Sling Models OSGi Service Disposal Job"* to clean the OSGi service references
does not do any error handling.
If a ungetting of a reference [0] is failed due to some exception (like
java.lang.IllegalStateException: Invalid BundleContext) no more references
present in queue are cleaned up in same job trigger. The next reference in
queue will be tried after 30 seconds (default) in next job trigger. Therefore,
it may take an hour to clean up 120 references with an error.
To reproduce this:
# Create a model consisting of OSGiService Injection
# Use this model in a page
# Open the created page and refresh it couple of time (10-15)
# Restart the bundle with model created in step 1
# One may see the following exceptions in the logs (after every ~30 seconds to
clear up the OSGi service references)
{code:xml}
01.02.2021 14:31:03.639 *ERROR* [sling-default-1-Sling Models OSGi Service
Disposal Job] org.apache.sling.commons.scheduler.impl.QuartzScheduler Exception
during job execution of job
'org.apache.sling.models.impl.ModelAdapterFactory@1b834b3c' with name 'Sling
Models OSGi Service Disposal Job' : Invalid BundleContext.
java.lang.IllegalStateException: Invalid BundleContext.
at
org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:491)
at
org.apache.felix.framework.BundleContextImpl.ungetService(BundleContextImpl.java:455)
at
org.apache.sling.models.impl.injectors.OSGiServiceInjector$Callback.onDisposed(OSGiServiceInjector.java:203)
[org.apache.sling.models.impl:1.4.16]
at
org.apache.sling.models.impl.ModelAdapterFactory$DisposalCallbackRegistryImpl.onDisposed(ModelAdapterFactory.java:143)
[org.apache.sling.models.impl:1.4.16]
at
org.apache.sling.models.impl.ModelAdapterFactory.clearDisposalCallbackRegistryQueue(ModelAdapterFactory.java:214)
[org.apache.sling.models.impl:1.4.16]
at
org.apache.sling.models.impl.ModelAdapterFactory.run(ModelAdapterFactory.java:206)
[org.apache.sling.models.impl:1.4.16]
at
org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:349)
[org.apache.sling.commons.scheduler:2.7.12]
at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
[org.apache.sling.commons.scheduler:2.7.12]
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
{code}
[0]:
https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/injectors/OSGiServiceInjector.java#L207
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SLING-11103) Improvements in synchronization and additional logging for TransformerFactoryServiceTracker in sling rewriter
[ https://issues.apache.org/jira/browse/SLING-11103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17484543#comment-17484543 ] Sagar Miglani commented on SLING-11103: --- PR Link: https://github.com/apache/sling-org-apache-sling-rewriter/pull/5 > Improvements in synchronization and additional logging for > TransformerFactoryServiceTracker in sling rewriter > - > > Key: SLING-11103 > URL: https://issues.apache.org/jira/browse/SLING-11103 > Project: Sling > Issue Type: Improvement > Components: Extensions >Affects Versions: Rewriter 1.3.0 >Reporter: Sagar Miglani >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Variable "isCacheValid" at > [TransformerFactoryServiceTracker:49|https://github.com/apache/sling-org-apache-sling-rewriter/blob/master/src/main/java/org/apache/sling/rewriter/impl/TransformerFactoryServiceTracker.java#L49] > doesn't seem to be properly synchronized. Also additional logging is > required in TransformerFactoryServiceTracker for debugging purpose. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (SLING-11103) Improvements in synchronization and additional logging for TransformerFactoryServiceTracker in sling rewriter
Sagar Miglani created SLING-11103: - Summary: Improvements in synchronization and additional logging for TransformerFactoryServiceTracker in sling rewriter Key: SLING-11103 URL: https://issues.apache.org/jira/browse/SLING-11103 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Rewriter 1.3.0 Reporter: Sagar Miglani Variable "isCacheValid" at [TransformerFactoryServiceTracker:49|https://github.com/apache/sling-org-apache-sling-rewriter/blob/master/src/main/java/org/apache/sling/rewriter/impl/TransformerFactoryServiceTracker.java#L49] doesn't seem to be properly synchronized. Also additional logging is required in TransformerFactoryServiceTracker for debugging purpose. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (SLING-10798) RequestLoggerFilter does not log access/request logs for felix web console
[ https://issues.apache.org/jira/browse/SLING-10798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17425961#comment-17425961 ] Sagar Miglani commented on SLING-10798: --- [~akhoury], sorry for the late reply, I did not receive any mail regarding your comment. I believe enabling RequestLoggerFilter to select all contexts by default doesn't make sense as it is made to log the sling-httprequests, but one should be able to modify the property to enable it for the all contexts which I raised SLING-10807. > RequestLoggerFilter does not log access/request logs for felix web console > -- > > Key: SLING-10798 > URL: https://issues.apache.org/jira/browse/SLING-10798 > Project: Sling > Issue Type: Bug > Components: Engine >Affects Versions: Engine 2.7.8 >Reporter: Sagar Miglani >Priority: Major > > RequestLoggerFilter filter should select all Servlet Context Helpers (similar > to > [ReferrerFiler|https://github.com/apache/sling-org-apache-sling-security/blob/1b4caa787d334d90375ab8aeb8e29dc75fcf3519/src/main/java/org/apache/sling/security/impl/ReferrerFilter.java#L62]), > so that it can log access/request logs of felix webconsole also. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-10845) Update logback to 1.2.6 version
[ https://issues.apache.org/jira/browse/SLING-10845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17425440#comment-17425440 ] Sagar Miglani commented on SLING-10845: --- Thanks [~rombert]! > Update logback to 1.2.6 version > > > Key: SLING-10845 > URL: https://issues.apache.org/jira/browse/SLING-10845 > Project: Sling > Issue Type: Task > Components: Commons >Affects Versions: Commons Log 5.1.12 >Reporter: Ashok Kumar >Assignee: Robert Munteanu >Priority: Major > Fix For: Commons Log 5.1.14 > > Attachments: sonar-build-failure.png > > Time Spent: 20m > Remaining Estimate: 0h > > To address vulnerability [https://jira.qos.ch/browse/LOGBACK-1465] , we need > to upgrade to 1.2.6 of logback -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-10845) Update logback to 1.2.6 version
[ https://issues.apache.org/jira/browse/SLING-10845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17424817#comment-17424817 ] Sagar Miglani commented on SLING-10845: --- [~rombert]/[~radu], can you please help us with the PR merge? Thanks! > Update logback to 1.2.6 version > > > Key: SLING-10845 > URL: https://issues.apache.org/jira/browse/SLING-10845 > Project: Sling > Issue Type: Task > Components: Commons >Affects Versions: Commons Log 5.1.12 >Reporter: Ashok Kumar >Priority: Major > Fix For: Commons Log 5.1.14 > > Attachments: sonar-build-failure.png > > > To address vulnerability [https://jira.qos.ch/browse/LOGBACK-1465] , we need > to upgrade to 1.2.6 of logback -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-10845) Update logback to 1.2.6 version
[ https://issues.apache.org/jira/browse/SLING-10845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17422681#comment-17422681 ] Sagar Miglani commented on SLING-10845: --- [~ashokpanghal] raised a PR: https://github.com/apache/sling-org-apache-sling-commons-log/pull/7 One check is failing !sonar-build-failure.png! which is also failing for previous commits. > Update logback to 1.2.6 version > > > Key: SLING-10845 > URL: https://issues.apache.org/jira/browse/SLING-10845 > Project: Sling > Issue Type: Task > Components: Commons >Affects Versions: Commons Log 5.1.12 >Reporter: Ashok Kumar >Priority: Major > Fix For: Commons Log 5.1.14 > > Attachments: sonar-build-failure.png > > > To address vulnerability [https://jira.qos.ch/browse/LOGBACK-1465] , we need > to upgrade to 1.2.6 of logback -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-10845) Update logback to 1.2.6 version
[ https://issues.apache.org/jira/browse/SLING-10845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sagar Miglani updated SLING-10845: -- Attachment: sonar-build-failure.png > Update logback to 1.2.6 version > > > Key: SLING-10845 > URL: https://issues.apache.org/jira/browse/SLING-10845 > Project: Sling > Issue Type: Task > Components: Commons >Affects Versions: Commons Log 5.1.12 >Reporter: Ashok Kumar >Priority: Major > Fix For: Commons Log 5.1.14 > > Attachments: sonar-build-failure.png > > > To address vulnerability [https://jira.qos.ch/browse/LOGBACK-1465] , we need > to upgrade to 1.2.6 of logback -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-8777) Sling activation bundle overrides default CommandMap with wrong type
[ https://issues.apache.org/jira/browse/SLING-8777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17422531#comment-17422531 ] Sagar Miglani commented on SLING-8777: -- Thanks [~cziegeler]! > Sling activation bundle overrides default CommandMap with wrong type > > > Key: SLING-8777 > URL: https://issues.apache.org/jira/browse/SLING-8777 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: javax.activation 0.1.0 >Reporter: Ashok Kumar >Assignee: Carsten Ziegeler >Priority: Major > Fix For: javax.activation 0.2.2 > > Attachments: SLING-8777.patch > > Time Spent: 1h 10m > Remaining Estimate: 0h > > The root cause of the issue is that the bundle > org.apache.sling.javax.activation 0.1.0 overrides the Default > javax.activation.CommandMap extending directly from CommandMap instead of > MailcapCommandMap: > > [https://github.com/apache/sling-org-apache-sling-javax-activation/blob/master/src/main/java/org/apache/sling/javax/activation/internal/OsgiMailcapCommandMap.java#L50] > The call fails due to this, here: > > [https://github.com/samskivert/ikvm-openjdk/blob/master/build/linux-amd64/impsrc/com/sun/xml/internal/messaging/saaj/soap/AttachmentPartImpl.java#L112] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-8777) Sling activation bundle overrides default CommandMap with wrong type
[ https://issues.apache.org/jira/browse/SLING-8777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418524#comment-17418524 ] Sagar Miglani commented on SLING-8777: -- [~cziegeler], Any suggestions on how should we progress on this? I have raised a [PR|https://github.com/apache/sling-org-apache-sling-javax-activation/pull/5], can you please have a look? Thanks! > Sling activation bundle overrides default CommandMap with wrong type > > > Key: SLING-8777 > URL: https://issues.apache.org/jira/browse/SLING-8777 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: javax.activation 0.1.0 >Reporter: Ashok Kumar >Priority: Major > Fix For: javax.activation 0.2.2 > > Attachments: SLING-8777.patch > > Time Spent: 1h > Remaining Estimate: 0h > > The root cause of the issue is that the bundle > org.apache.sling.javax.activation 0.1.0 overrides the Default > javax.activation.CommandMap extending directly from CommandMap instead of > MailcapCommandMap: > > [https://github.com/apache/sling-org-apache-sling-javax-activation/blob/master/src/main/java/org/apache/sling/javax/activation/internal/OsgiMailcapCommandMap.java#L50] > The call fails due to this, here: > > [https://github.com/samskivert/ikvm-openjdk/blob/master/build/linux-amd64/impsrc/com/sun/xml/internal/messaging/saaj/soap/AttachmentPartImpl.java#L112] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-8777) Sling activation bundle overrides default CommandMap with wrong type
[ https://issues.apache.org/jira/browse/SLING-8777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17415939#comment-17415939 ] Sagar Miglani commented on SLING-8777: -- Hi [~karlpauls], Raised a PR: https://github.com/apache/sling-org-apache-sling-javax-activation/pull/5 please have a look. Sonar quality checks are failing but you can review and let me know if it goes in the right direction. Thanks > Sling activation bundle overrides default CommandMap with wrong type > > > Key: SLING-8777 > URL: https://issues.apache.org/jira/browse/SLING-8777 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: javax.activation 0.1.0 >Reporter: Ashok Kumar >Priority: Major > Fix For: javax.activation 0.2.2 > > Attachments: SLING-8777.patch > > Time Spent: 20m > Remaining Estimate: 0h > > The root cause of the issue is that the bundle > org.apache.sling.javax.activation 0.1.0 overrides the Default > javax.activation.CommandMap extending directly from CommandMap instead of > MailcapCommandMap: > > [https://github.com/apache/sling-org-apache-sling-javax-activation/blob/master/src/main/java/org/apache/sling/javax/activation/internal/OsgiMailcapCommandMap.java#L50] > The call fails due to this, here: > > [https://github.com/samskivert/ikvm-openjdk/blob/master/build/linux-amd64/impsrc/com/sun/xml/internal/messaging/saaj/soap/AttachmentPartImpl.java#L112] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-10807) Need to override osgi.http.whiteboard.context.name property of RequestLoggerFilter
[ https://issues.apache.org/jira/browse/SLING-10807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17414002#comment-17414002 ] Sagar Miglani commented on SLING-10807: --- Thanks [~cziegeler]! > Need to override osgi.http.whiteboard.context.name property of > RequestLoggerFilter > -- > > Key: SLING-10807 > URL: https://issues.apache.org/jira/browse/SLING-10807 > Project: Sling > Issue Type: Improvement > Components: Engine >Affects Versions: Engine 2.7.8 >Reporter: Sagar Miglani >Assignee: Carsten Ziegeler >Priority: Major > Fix For: Engine 2.7.10 > > Time Spent: 20m > Remaining Estimate: 0h > > RequestLoggerFilter is unable to log access/request logs for the endpoints > directly configured over the jetty server (like felix web console). > I believe, RequestLoggerFilter filter should select all Servlet Context > Helpers (similar to > [ReferrerFiler:62|https://github.com/apache/sling-org-apache-sling-security/blob/1b4caa787d334d90375ab8aeb8e29dc75fcf3519/src/main/java/org/apache/sling/security/impl/ReferrerFilter.java#L62]), > and to achieve that in our instance we need to override > "osgi.http.whiteboard.context.name" property of RequestLoggerFilter with a > corresponding object in the OSGi configuration admin service, but we can not > override it as the configuration policy is set to IGNORE > ([RequestLoggerFilter:46|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/log/RequestLoggerFilter.java#L46]) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-10807) Need to override osgi.http.whiteboard.context.name property of RequestLoggerFilter
[ https://issues.apache.org/jira/browse/SLING-10807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sagar Miglani updated SLING-10807: -- Summary: Need to override osgi.http.whiteboard.context.name property of RequestLoggerFilter (was: Need to override osgi.http.whiteboard.context.name propery of RequestLoggerFilter) > Need to override osgi.http.whiteboard.context.name property of > RequestLoggerFilter > -- > > Key: SLING-10807 > URL: https://issues.apache.org/jira/browse/SLING-10807 > Project: Sling > Issue Type: Improvement > Components: Engine >Affects Versions: Engine 2.7.8 >Reporter: Sagar Miglani >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > RequestLoggerFilter is unable to log access/request logs for the endpoints > directly configured over the jetty server (like felix web console). > I believe, RequestLoggerFilter filter should select all Servlet Context > Helpers (similar to > [ReferrerFiler:62|https://github.com/apache/sling-org-apache-sling-security/blob/1b4caa787d334d90375ab8aeb8e29dc75fcf3519/src/main/java/org/apache/sling/security/impl/ReferrerFilter.java#L62]), > and to achieve that in our instance we need to override > "osgi.http.whiteboard.context.name" property of RequestLoggerFilter with a > corresponding object in the OSGi configuration admin service, but we can not > override it as the configuration policy is set to IGNORE > ([RequestLoggerFilter:46|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/log/RequestLoggerFilter.java#L46]) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-10807) Need to override osgi.http.whiteboard.context.name propery of RequestLoggerFilter
[ https://issues.apache.org/jira/browse/SLING-10807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17413992#comment-17413992 ] Sagar Miglani commented on SLING-10807: --- PR Link: https://github.com/apache/sling-org-apache-sling-engine/pull/19 > Need to override osgi.http.whiteboard.context.name propery of > RequestLoggerFilter > - > > Key: SLING-10807 > URL: https://issues.apache.org/jira/browse/SLING-10807 > Project: Sling > Issue Type: Improvement > Components: Engine >Affects Versions: Engine 2.7.8 >Reporter: Sagar Miglani >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > RequestLoggerFilter is unable to log access/request logs for the endpoints > directly configured over the jetty server (like felix web console). > I believe, RequestLoggerFilter filter should select all Servlet Context > Helpers (similar to > [ReferrerFiler:62|https://github.com/apache/sling-org-apache-sling-security/blob/1b4caa787d334d90375ab8aeb8e29dc75fcf3519/src/main/java/org/apache/sling/security/impl/ReferrerFilter.java#L62]), > and to achieve that in our instance we need to override > "osgi.http.whiteboard.context.name" property of RequestLoggerFilter with a > corresponding object in the OSGi configuration admin service, but we can not > override it as the configuration policy is set to IGNORE > ([RequestLoggerFilter:46|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/log/RequestLoggerFilter.java#L46]) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-10807) Need to override osgi.http.whiteboard.context.name propery of RequestLoggerFilter
[ https://issues.apache.org/jira/browse/SLING-10807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sagar Miglani updated SLING-10807: -- Issue Type: Improvement (was: Bug) > Need to override osgi.http.whiteboard.context.name propery of > RequestLoggerFilter > - > > Key: SLING-10807 > URL: https://issues.apache.org/jira/browse/SLING-10807 > Project: Sling > Issue Type: Improvement > Components: Engine >Affects Versions: Engine 2.7.8 >Reporter: Sagar Miglani >Priority: Major > > RequestLoggerFilter is unable to log access/request logs for the endpoints > directly configured over the jetty server (like felix web console). > I believe, RequestLoggerFilter filter should select all Servlet Context > Helpers (similar to > [ReferrerFiler:62|https://github.com/apache/sling-org-apache-sling-security/blob/1b4caa787d334d90375ab8aeb8e29dc75fcf3519/src/main/java/org/apache/sling/security/impl/ReferrerFilter.java#L62]), > and to achieve that in our instance we need to override > "osgi.http.whiteboard.context.name" property of RequestLoggerFilter with a > corresponding object in the OSGi configuration admin service, but we can not > override it as the configuration policy is set to IGNORE > ([RequestLoggerFilter:46|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/log/RequestLoggerFilter.java#L46]) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SLING-10807) Need to override osgi.http.whiteboard.context.name propery of RequestLoggerFilter
Sagar Miglani created SLING-10807: - Summary: Need to override osgi.http.whiteboard.context.name propery of RequestLoggerFilter Key: SLING-10807 URL: https://issues.apache.org/jira/browse/SLING-10807 Project: Sling Issue Type: Bug Components: Engine Affects Versions: Engine 2.7.8 Reporter: Sagar Miglani RequestLoggerFilter is unable to log access/request logs for the endpoints directly configured over the jetty server (like felix web console). I believe, RequestLoggerFilter filter should select all Servlet Context Helpers (similar to [ReferrerFiler:62|https://github.com/apache/sling-org-apache-sling-security/blob/1b4caa787d334d90375ab8aeb8e29dc75fcf3519/src/main/java/org/apache/sling/security/impl/ReferrerFilter.java#L62]), and to achieve that in our instance we need to override "osgi.http.whiteboard.context.name" property of RequestLoggerFilter with a corresponding object in the OSGi configuration admin service, but we can not override it as the configuration policy is set to IGNORE ([RequestLoggerFilter:46|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/log/RequestLoggerFilter.java#L46]) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-10798) RequestLoggerFilter does not log access/request logs for felix web console
[ https://issues.apache.org/jira/browse/SLING-10798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sagar Miglani resolved SLING-10798. --- Resolution: Invalid > RequestLoggerFilter does not log access/request logs for felix web console > -- > > Key: SLING-10798 > URL: https://issues.apache.org/jira/browse/SLING-10798 > Project: Sling > Issue Type: Bug > Components: Engine >Affects Versions: Engine 2.7.8 >Reporter: Sagar Miglani >Priority: Major > > RequestLoggerFilter filter should select all Servlet Context Helpers (similar > to > [ReferrerFiler|https://github.com/apache/sling-org-apache-sling-security/blob/1b4caa787d334d90375ab8aeb8e29dc75fcf3519/src/main/java/org/apache/sling/security/impl/ReferrerFilter.java#L62]), > so that it can log access/request logs of felix webconsole also. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (SLING-10798) RequestLoggerFilter does not log access/request logs for felix web console
[ https://issues.apache.org/jira/browse/SLING-10798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sagar Miglani updated SLING-10798: -- Comment: was deleted (was: PR link: https://github.com/apache/sling-org-apache-sling-engine/pull/18) > RequestLoggerFilter does not log access/request logs for felix web console > -- > > Key: SLING-10798 > URL: https://issues.apache.org/jira/browse/SLING-10798 > Project: Sling > Issue Type: Bug > Components: Engine >Affects Versions: Engine 2.7.8 >Reporter: Sagar Miglani >Priority: Major > > RequestLoggerFilter filter should select all Servlet Context Helpers (similar > to > [ReferrerFiler|https://github.com/apache/sling-org-apache-sling-security/blob/1b4caa787d334d90375ab8aeb8e29dc75fcf3519/src/main/java/org/apache/sling/security/impl/ReferrerFilter.java#L62]), > so that it can log access/request logs of felix webconsole also. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-10798) RequestLoggerFilter does not log access/request logs for felix web console
[ https://issues.apache.org/jira/browse/SLING-10798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17413131#comment-17413131 ] Sagar Miglani commented on SLING-10798: --- PR link: https://github.com/apache/sling-org-apache-sling-engine/pull/18 > RequestLoggerFilter does not log access/request logs for felix web console > -- > > Key: SLING-10798 > URL: https://issues.apache.org/jira/browse/SLING-10798 > Project: Sling > Issue Type: Bug > Components: Engine >Affects Versions: Engine 2.7.8 >Reporter: Sagar Miglani >Priority: Major > > RequestLoggerFilter filter should select all Servlet Context Helpers (similar > to > [ReferrerFiler|https://github.com/apache/sling-org-apache-sling-security/blob/1b4caa787d334d90375ab8aeb8e29dc75fcf3519/src/main/java/org/apache/sling/security/impl/ReferrerFilter.java#L62]), > so that it can log access/request logs of felix webconsole also. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SLING-10798) RequestLoggerFilter does not log access/request logs for felix web console
Sagar Miglani created SLING-10798: - Summary: RequestLoggerFilter does not log access/request logs for felix web console Key: SLING-10798 URL: https://issues.apache.org/jira/browse/SLING-10798 Project: Sling Issue Type: Bug Components: Engine Affects Versions: Engine 2.7.8 Reporter: Sagar Miglani RequestLoggerFilter filter should select all Servlet Context Helpers (similar to [ReferrerFiler|https://github.com/apache/sling-org-apache-sling-security/blob/1b4caa787d334d90375ab8aeb8e29dc75fcf3519/src/main/java/org/apache/sling/security/impl/ReferrerFilter.java#L62]), so that it can log access/request logs of felix webconsole also. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-10476) Aliases in MapEntries are removed in delete event of jcr:content present in the parent directory
[
https://issues.apache.org/jira/browse/SLING-10476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17371033#comment-17371033
]
Sagar Miglani commented on SLING-10476:
---
Thanks [~rombert]!
> Aliases in MapEntries are removed in delete event of jcr:content present in
> the parent directory
>
>
> Key: SLING-10476
> URL: https://issues.apache.org/jira/browse/SLING-10476
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Affects Versions: Resource Resolver 1.7.0
>Reporter: Sagar Miglani
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Resource Resolver 1.7.10
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When a {{jcr:content}} node is deleted, it removes all the aliases present
> below that path
> For example:
> Let's say we have
> {code:xml}
> /
> - content
> - A
> - jcr:content
> - B
> - de_DE - has sling:alias de
> - en_GB - has sling:alias en
> - C
> - it_CH - has sling:alias it
> {code}
> If /{{content/A/jcr:content}} node is removed, It deletes all the aliases
> (in-memory in the MapEntries) which start with {{/content/A/}}
> See: {{sling-resourceresolver:MapEntries.java}}
> ([https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/org.apache.sling.resourceresolver-1.7.0/src/main/java/org/apache/sling/resourceresolver/impl/mapping/MapEntries.java#L330])
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-10483) Incorrect mapping is returned when a resourceResolver.map is called with all its aliases
[
https://issues.apache.org/jira/browse/SLING-10483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17369377#comment-17369377
]
Sagar Miglani commented on SLING-10483:
---
Hi [~rombert]/[~santiagozky],
Raised a PR for potential fix:
https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/48
[~rombert], Could you please have a look?
Thanks
> Incorrect mapping is returned when a resourceResolver.map is called with all
> its aliases
>
>
> Key: SLING-10483
> URL: https://issues.apache.org/jira/browse/SLING-10483
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Affects Versions: Resource Resolver 1.7.8
>Reporter: Santiago García Pimentel
>Priority: Critical
> Fix For: Resource Resolver 1.7.10
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I think this might be related to
> https://issues.apache.org/jira/browse/SLING-10432
> When you have a path in which several nodes have some alias,
> resourceResolver.map(path) will return the wrong result in some cases.
> before SLING-10432 was fixed this happen more often, now the problem is
> reduced, but persist.
> eg.
> I have a path _/content/uw/ecrm/germany/www/de/home/laundry_
> of those _de_, _home_ and _laundry_ have aliases (dealias,homealias &
> laundryalias, respectively).
> when calling :
> {quote}resourceResolver.map("/content/uw/ecrm/germany/www/*dealias/homealias/laundryalias*")
> {quote}
> I get
> {quote}/content/uw/ecrm/germany/www/*de*/homealias/laundryalias
> {quote}
>
> Note *de* instead of *dealias.*
> It only happens when all map receives only aliases, then the first segment
> with alias is not used. i.e. if I remove the alias from *de*, *homealias*
> would then not be used
>
> calling rr.map() with just some of the paths using aliases, it seems to work
> fine now
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SLING-10476) Aliases in MapEntries are removed in delete event of jcr:content present in the parent directory
[
https://issues.apache.org/jira/browse/SLING-10476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17364828#comment-17364828
]
Sagar Miglani edited comment on SLING-10476 at 6/17/21, 10:42 AM:
--
Hi [~rombert],
Here is the PR:
[https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/47]
Please let me know in case I've missed something. Looking forward to your
comments and suggestions :)
Thanks.
Sagar
PS: Apologies for the late PR, was stuck on something else
was (Author: sagarmiglani):
Hi [~rombert],
Here is the PR:
[https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/47]
Please let me know in case I've missed something. Looking forward to your
comments and suggestions :)
Thanks.
Sagar
PS: Apologies for the late PR, was stuck with something else
> Aliases in MapEntries are removed in delete event of jcr:content present in
> the parent directory
>
>
> Key: SLING-10476
> URL: https://issues.apache.org/jira/browse/SLING-10476
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Affects Versions: Resource Resolver 1.7.0
>Reporter: Sagar Miglani
>Priority: Major
> Fix For: Resource Resolver 1.7.10
>
>
> When a {{jcr:content}} node is deleted, it removes all the aliases present
> below that path
> For example:
> Let's say we have
> {code:xml}
> /
> - content
> - A
> - jcr:content
> - B
> - de_DE - has sling:alias de
> - en_GB - has sling:alias en
> - C
> - it_CH - has sling:alias it
> {code}
> If /{{content/A/jcr:content}} node is removed, It deletes all the aliases
> (in-memory in the MapEntries) which start with {{/content/A/}}
> See: {{sling-resourceresolver:MapEntries.java}}
> ([https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/org.apache.sling.resourceresolver-1.7.0/src/main/java/org/apache/sling/resourceresolver/impl/mapping/MapEntries.java#L330])
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-10476) Aliases in MapEntries are removed in delete event of jcr:content present in the parent directory
[
https://issues.apache.org/jira/browse/SLING-10476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17364828#comment-17364828
]
Sagar Miglani commented on SLING-10476:
---
Hi [~rombert],
Here is the PR:
[https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/47]
Please let me know in case I've missed something. Looking forward to your
comments and suggestions :)
Thanks.
Sagar
PS: Apologies for the late PR, was stuck with something else
> Aliases in MapEntries are removed in delete event of jcr:content present in
> the parent directory
>
>
> Key: SLING-10476
> URL: https://issues.apache.org/jira/browse/SLING-10476
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Affects Versions: Resource Resolver 1.7.0
>Reporter: Sagar Miglani
>Priority: Major
> Fix For: Resource Resolver 1.7.10
>
>
> When a {{jcr:content}} node is deleted, it removes all the aliases present
> below that path
> For example:
> Let's say we have
> {code:xml}
> /
> - content
> - A
> - jcr:content
> - B
> - de_DE - has sling:alias de
> - en_GB - has sling:alias en
> - C
> - it_CH - has sling:alias it
> {code}
> If /{{content/A/jcr:content}} node is removed, It deletes all the aliases
> (in-memory in the MapEntries) which start with {{/content/A/}}
> See: {{sling-resourceresolver:MapEntries.java}}
> ([https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/org.apache.sling.resourceresolver-1.7.0/src/main/java/org/apache/sling/resourceresolver/impl/mapping/MapEntries.java#L330])
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-10480) Password property in UserCredentialsDistributionTransportSecretProvider is visible as clear text in felix web console
[ https://issues.apache.org/jira/browse/SLING-10480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17360845#comment-17360845 ] Sagar Miglani commented on SLING-10480: --- Created the PR for the same: [https://github.com/apache/sling-org-apache-sling-distribution-core/pull/52] > Password property in UserCredentialsDistributionTransportSecretProvider is > visible as clear text in felix web console > - > > Key: SLING-10480 > URL: https://issues.apache.org/jira/browse/SLING-10480 > Project: Sling > Issue Type: Bug > Components: Content Distribution >Affects Versions: Content Distribution Core 0.4.0 >Reporter: Sagar Miglani >Priority: Major > Fix For: Content Distribution Core 0.4.6 > > Time Spent: 10m > Remaining Estimate: 0h > > Password property in UserCredentialsDistributionTransportSecretProvider is > visible as clear text in felix web console. > It should be annotated correctly to be treated as a password in web console. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-10480) Password property in UserCredentialsDistributionTransportSecretProvider is visible as clear text in felix web console
[ https://issues.apache.org/jira/browse/SLING-10480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sagar Miglani updated SLING-10480: -- Fix Version/s: Content Distribution Core 0.4.6 > Password property in UserCredentialsDistributionTransportSecretProvider is > visible as clear text in felix web console > - > > Key: SLING-10480 > URL: https://issues.apache.org/jira/browse/SLING-10480 > Project: Sling > Issue Type: Bug > Components: Content Distribution >Affects Versions: Content Distribution Core 0.4.0 >Reporter: Sagar Miglani >Priority: Major > Fix For: Content Distribution Core 0.4.6 > > > Password property in UserCredentialsDistributionTransportSecretProvider is > visible as clear text in felix web console. > It should be annotated correctly to be treated as a password in web console. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-10480) Password property in UserCredentialsDistributionTransportSecretProvider is visible as clear text in felix web console
[ https://issues.apache.org/jira/browse/SLING-10480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17360813#comment-17360813 ] Sagar Miglani commented on SLING-10480: --- I'm working on it > Password property in UserCredentialsDistributionTransportSecretProvider is > visible as clear text in felix web console > - > > Key: SLING-10480 > URL: https://issues.apache.org/jira/browse/SLING-10480 > Project: Sling > Issue Type: Bug > Components: Content Distribution >Affects Versions: Content Distribution Core 0.4.0 >Reporter: Sagar Miglani >Priority: Major > > Password property in UserCredentialsDistributionTransportSecretProvider is > visible as clear text in felix web console. > It should be annotated correctly to be treated as a password in web console. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SLING-10480) Password property in UserCredentialsDistributionTransportSecretProvider is visible as clear text in felix web console
Sagar Miglani created SLING-10480: - Summary: Password property in UserCredentialsDistributionTransportSecretProvider is visible as clear text in felix web console Key: SLING-10480 URL: https://issues.apache.org/jira/browse/SLING-10480 Project: Sling Issue Type: Bug Components: Content Distribution Affects Versions: Content Distribution Core 0.4.0 Reporter: Sagar Miglani Password property in UserCredentialsDistributionTransportSecretProvider is visible as clear text in felix web console. It should be annotated correctly to be treated as a password in web console. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-10476) Aliases in MapEntries are removed in delete event of jcr:content present in the parent directory
[
https://issues.apache.org/jira/browse/SLING-10476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17359952#comment-17359952
]
Sagar Miglani commented on SLING-10476:
---
Hi [~rombert],
Sure, I'll create a PR soon. Thank you.
> Aliases in MapEntries are removed in delete event of jcr:content present in
> the parent directory
>
>
> Key: SLING-10476
> URL: https://issues.apache.org/jira/browse/SLING-10476
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Affects Versions: Resource Resolver 1.7.0
>Reporter: Sagar Miglani
>Priority: Major
> Fix For: Resource Resolver 1.7.10
>
>
> When a {{jcr:content}} node is deleted, it removes all the aliases present
> below that path
> For example:
> Let's say we have
> {code:xml}
> /
> - content
> - A
> - jcr:content
> - B
> - de_DE - has sling:alias de
> - en_GB - has sling:alias en
> - C
> - it_CH - has sling:alias it
> {code}
> If /{{content/A/jcr:content}} node is removed, It deletes all the aliases
> (in-memory in the MapEntries) which start with {{/content/A/}}
> See: {{sling-resourceresolver:MapEntries.java}}
> ([https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/org.apache.sling.resourceresolver-1.7.0/src/main/java/org/apache/sling/resourceresolver/impl/mapping/MapEntries.java#L330])
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-10476) Aliases in MapEntries are removed in delete event of jcr:content present in the parent directory
[
https://issues.apache.org/jira/browse/SLING-10476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sagar Miglani updated SLING-10476:
--
Summary: Aliases in MapEntries are removed in delete event of jcr:content
present in the parent directory (was: Aliases in MapEntries are removed in
delete event on jcr:content present in the parent directory)
> Aliases in MapEntries are removed in delete event of jcr:content present in
> the parent directory
>
>
> Key: SLING-10476
> URL: https://issues.apache.org/jira/browse/SLING-10476
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Affects Versions: Resource Resolver 1.7.0
>Reporter: Sagar Miglani
>Priority: Major
>
> When a {{jcr:content}} node is deleted, it removes all the aliases present
> below that path
> For example:
> Let's say we have
> {code:xml}
> /
> - content
> - A
> - jcr:content
> - B
> - de_DE - has sling:alias de
> - en_GB - has sling:alias en
> - C
> - it_CH - has sling:alias it
> {code}
> If /{{content/A/jcr:content}} node is removed, It deletes all the aliases
> (in-memory in the MapEntries) which start with {{/content/A/}}
> See: {{sling-resourceresolver:MapEntries.java}}
> ([https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/org.apache.sling.resourceresolver-1.7.0/src/main/java/org/apache/sling/resourceresolver/impl/mapping/MapEntries.java#L330])
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-10476) Aliases in MapEntries are removed in delete event on jcr:content present in the parent directory
[
https://issues.apache.org/jira/browse/SLING-10476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sagar Miglani updated SLING-10476:
--
Summary: Aliases in MapEntries are removed in delete event on jcr:content
present in the parent directory (was: Aliases in MapEntries are removed on
delete event on jcr:content present in the parent directory)
> Aliases in MapEntries are removed in delete event on jcr:content present in
> the parent directory
>
>
> Key: SLING-10476
> URL: https://issues.apache.org/jira/browse/SLING-10476
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Affects Versions: Resource Resolver 1.7.0
>Reporter: Sagar Miglani
>Priority: Major
>
> When a {{jcr:content}} node is deleted, it removes all the aliases present
> below that path
> For example:
> Let's say we have
> {code:xml}
> /
> - content
> - A
> - jcr:content
> - B
> - de_DE - has sling:alias de
> - en_GB - has sling:alias en
> - C
> - it_CH - has sling:alias it
> {code}
> If /{{content/A/jcr:content}} node is removed, It deletes all the aliases
> (in-memory in the MapEntries) which start with {{/content/A/}}
> See: {{sling-resourceresolver:MapEntries.java}}
> ([https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/org.apache.sling.resourceresolver-1.7.0/src/main/java/org/apache/sling/resourceresolver/impl/mapping/MapEntries.java#L330])
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SLING-10476) Aliases in MapEntries are removed on delete event on jcr:content present in the parent directory
Sagar Miglani created SLING-10476:
-
Summary: Aliases in MapEntries are removed on delete event on
jcr:content present in the parent directory
Key: SLING-10476
URL: https://issues.apache.org/jira/browse/SLING-10476
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Resolver 1.7.0
Reporter: Sagar Miglani
When a {{jcr:content}} node is deleted, it removes all the aliases present
below that path
For example:
Let's say we have
{code:xml}
/
- content
- A
- jcr:content
- B
- de_DE - has sling:alias de
- en_GB - has sling:alias en
- C
- it_CH - has sling:alias it
{code}
If /{{content/A/jcr:content}} node is removed, It deletes all the aliases
(in-memory in the MapEntries) which start with {{/content/A/}}
See: {{sling-resourceresolver:MapEntries.java}}
([https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/org.apache.sling.resourceresolver-1.7.0/src/main/java/org/apache/sling/resourceresolver/impl/mapping/MapEntries.java#L330])
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
