[jira] [Created] (SLING-12323) [RepoInit] Avoid java.nio.file.Path for parsing repository paths
Julian Sedding created SLING-12323:
--
Summary: [RepoInit] Avoid java.nio.file.Path for parsing
repository paths
Key: SLING-12323
URL: https://issues.apache.org/jira/browse/SLING-12323
Project: Sling
Issue Type: Bug
Components: Repoinit
Affects Versions: Repoinit JCR 1.1.46
Reporter: Julian Sedding
Assignee: Julian Sedding
RepoInit uses {{java.nio.file.Path}} to determine the "parent path" and "name"
of a relative repository path. This fails on Windows when the relative
repository path contains a colon ":".
The implementation should not be platform dependent.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-12323) [RepoInit] Avoid java.nio.file.Path for parsing repository paths
[
https://issues.apache.org/jira/browse/SLING-12323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding resolved SLING-12323.
Fix Version/s: Repoinit JCR 1.1.48
Resolution: Fixed
> [RepoInit] Avoid java.nio.file.Path for parsing repository paths
>
>
> Key: SLING-12323
> URL: https://issues.apache.org/jira/browse/SLING-12323
> Project: Sling
> Issue Type: Bug
> Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.46
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Major
> Fix For: Repoinit JCR 1.1.48
>
>
> RepoInit uses {{java.nio.file.Path}} to determine the "parent path" and
> "name" of a relative repository path. This fails on Windows when the relative
> repository path contains a colon ":".
> The implementation should not be platform dependent.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-12329) Backwards compatibility for legacy repoinit statement reordering
Julian Sedding created SLING-12329: -- Summary: Backwards compatibility for legacy repoinit statement reordering Key: SLING-12329 URL: https://issues.apache.org/jira/browse/SLING-12329 Project: Sling Issue Type: Improvement Components: Repoinit Affects Versions: Repoinit JCR 1.1.46 Reporter: Julian Sedding Assignee: Julian Sedding Fix For: Repoinit JCR 1.1.50 The fix for repoinit statement reordering can cause issues for users relying on the legacy ordering. We should support a fallback to the legacy ordering and log a deprecation message, warning users that their repoinit script relies on the legacy ordering, support for which may be removed in the future. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12243) Standalone execution of Repoinit statements is not clearly documented
[ https://issues.apache.org/jira/browse/SLING-12243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding closed SLING-12243. -- > Standalone execution of Repoinit statements is not clearly documented > - > > Key: SLING-12243 > URL: https://issues.apache.org/jira/browse/SLING-12243 > Project: Sling > Issue Type: Bug > Components: Repoinit >Affects Versions: Repoinit JCR 1.1.46 >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz >Priority: Minor > Fix For: Repoinit JCR 1.1.48 > > > The repoinit documentation at > [https://sling.apache.org/documentation/bundles/repository-initialization.html] > does not clearly indicate how to execute repoinit statements outside of the > repository initialization cycle. The information is present but not obvious. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12323) [RepoInit] Avoid java.nio.file.Path for parsing repository paths
[
https://issues.apache.org/jira/browse/SLING-12323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding closed SLING-12323.
--
> [RepoInit] Avoid java.nio.file.Path for parsing repository paths
>
>
> Key: SLING-12323
> URL: https://issues.apache.org/jira/browse/SLING-12323
> Project: Sling
> Issue Type: Bug
> Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.46
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Major
> Fix For: Repoinit JCR 1.1.48
>
>
> RepoInit uses {{java.nio.file.Path}} to determine the "parent path" and
> "name" of a relative repository path. This fails on Windows when the relative
> repository path contains a colon ":".
> The implementation should not be platform dependent.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SLING-12237) Extend exception message for RepositoryInitializerFactory with config PID and affected script/reference
[
https://issues.apache.org/jira/browse/SLING-12237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding closed SLING-12237.
--
> Extend exception message for RepositoryInitializerFactory with config PID and
> affected script/reference
> ---
>
> Key: SLING-12237
> URL: https://issues.apache.org/jira/browse/SLING-12237
> Project: Sling
> Issue Type: Improvement
> Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.46
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: Repoinit JCR 1.1.48
>
>
> Currently an error in any of the repoinit scripts or reference just lead to
> an exception which does not expose the configuration PID triggering the
> exception, e.g.
> {code}
> javax.jcr.RepositoryException: Applying repoinit operation failed despite
> retry; set loglevel to DEBUG to see all exceptions. Last exception message
> was: Session.save failed: javax.jcr.nodetype.ConstraintViolationException:
> OakConstraint0001: /var/groovyconsole[[nt:folder]]: No matching definition
> found for child node audit with effective type [nt:unstructured]
> at
> org.apache.sling.jcr.repoinit.impl.RepositoryInitializerFactory.applyOperations(RepositoryInitializerFactory.java:176)
> [org.apache.sling.jcr.repoinit:1.1.38]
> {code}
> As repo init scripts are contributed from many different source locations the
> underlying configuration PID should be contained in the exception message as
> well. In addition the index of the according script or the according
> reference URL should be included.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-12329) Backwards compatibility for legacy repoinit statement reordering
[ https://issues.apache.org/jira/browse/SLING-12329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding resolved SLING-12329. Resolution: Fixed > Backwards compatibility for legacy repoinit statement reordering > > > Key: SLING-12329 > URL: https://issues.apache.org/jira/browse/SLING-12329 > Project: Sling > Issue Type: Improvement > Components: Repoinit >Affects Versions: Repoinit JCR 1.1.46 >Reporter: Julian Sedding >Assignee: Julian Sedding >Priority: Minor > Fix For: Repoinit JCR 1.1.50 > > > The fix for repoinit statement reordering can cause issues for users relying > on the legacy ordering. > We should support a fallback to the legacy ordering and log a deprecation > message, warning users that their repoinit script relies on the legacy > ordering, support for which may be removed in the future. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12122) Add unit-test creating group with rep:externalId property
[
https://issues.apache.org/jira/browse/SLING-12122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated SLING-12122:
---
Fix Version/s: (was: Repoinit JCR 1.1.50)
> Add unit-test creating group with rep:externalId property
> -
>
> Key: SLING-12122
> URL: https://issues.apache.org/jira/browse/SLING-12122
> Project: Sling
> Issue Type: Test
> Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.44
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
>
> Add a unit-test validating that repoinit can successfully create a new group
> with the {{rep:externalId}} property, that can only be set on creation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-11621) Outdated JCR dependencies
[
https://issues.apache.org/jira/browse/SLING-11621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated SLING-11621:
---
Fix Version/s: (was: Repoinit JCR 1.1.50)
> Outdated JCR dependencies
> -
>
> Key: SLING-11621
> URL: https://issues.apache.org/jira/browse/SLING-11621
> Project: Sling
> Issue Type: Task
> Components: Repoinit
>Reporter: Julian Reschke
>Priority: Major
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> https://github.com/apache/sling-org-apache-sling-jcr-repoinit/blob/9913b787574186a7a31d184480cec3862816438f/pom.xml#L39:
> {noformat}
> 2.18.2
> 1.22.1
> {noformat}
> Jackrabbit 2.18 has been EOLd quite some time ago...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SLING-12329) Backwards compatibility for legacy repoinit statement reordering
[ https://issues.apache.org/jira/browse/SLING-12329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding closed SLING-12329. -- > Backwards compatibility for legacy repoinit statement reordering > > > Key: SLING-12329 > URL: https://issues.apache.org/jira/browse/SLING-12329 > Project: Sling > Issue Type: Improvement > Components: Repoinit >Affects Versions: Repoinit JCR 1.1.46 >Reporter: Julian Sedding >Assignee: Julian Sedding >Priority: Minor > Fix For: Repoinit JCR 1.1.50 > > > The fix for repoinit statement reordering can cause issues for users relying > on the legacy ordering. > We should support a fallback to the legacy ordering and log a deprecation > message, warning users that their repoinit script relies on the legacy > ordering, support for which may be removed in the future. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12283) Configuration in Cluster mode are not in sync
[
https://issues.apache.org/jira/browse/SLING-12283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding resolved SLING-12283.
Assignee: Julian Sedding
Resolution: Fixed
> Configuration in Cluster mode are not in sync
> -
>
> Key: SLING-12283
> URL: https://issues.apache.org/jira/browse/SLING-12283
> Project: Sling
> Issue Type: Bug
>Reporter: Rishabh Daim
>Assignee: Julian Sedding
>Priority: Major
>
> {color:#172b4d}Configuration in Cluster mode is not in sync. When instances
> are in shared mode, and a new configuration is created under 1st instance, it
> is not reflected correctly in 2nd instance. {color}
> {color:#172b4d}The factory PID and hence properties are altered in the 2nd
> instance.{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12283) Configuration in Cluster mode are not in sync
[
https://issues.apache.org/jira/browse/SLING-12283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17861063#comment-17861063
]
Julian Sedding commented on SLING-12283:
Further analysis showed that this issue occurs when a factory configuration is
manually created using the Felix webconsole. The webconsole uses the API
{{ConfigurationAdmin#createFactoryConfiguration(...)}} to create such a
configuration. In contrast to the
{{ConfigurationAdmin#getFactoryConfiguration(...)}} methods, which create a
{{service.pid}} by concatenating the {{factoryPid}}, a tilde character ('~')
and the "name" part (an arbitrary string passed by the caller), the
{{ConfigurationAdmin#createFactoryConfiguration(...)}} methods, as implemented
by Felix' implementation of the Configuration Admin specification, create a
{{service.pid}} by concatenating the {{factoryPid}}, a dot character ('.') and
a randomly generated UUID. The UUID part cannot be controlled by the caller of
the message, and thus it is impossible to re-create a factory configuration
with the exact same {{service.pid}} on a second cluster node.
The strategy implemented in PR #15 works as follows:
(1) The {{ConfigTaskCreator}} class, which implements the
{{ResourceTransformer}} interface, already extracts the {{service.pid}}, and in
the case of a factory configuration the {{factoryPid}}, from the filename of a
{{RegisteredResource}} representing a configuration. In this extraction logic,
the {{service.pid}} extracted from the filename is first matched against the
format of configurations created using Felix'
{{ConfigurationAdmin#createFactoryConfiguration(...)}} implementation, and the
{{factoryPid}} and {{name}} are extracted. If it doesn't match, the previous
logic, looking for a '~' separator etc is used.
(2) In the {{ConfigUtil#getConfiguration(...)}} method, which is used to check
if a given configuration already exists, a check for a configuration using a
"legacy naming convention" is used if no configuration was found with a name
following the expected '~' separated format.
With these two changes the behaviour is as follows:
# a factory configuration is created on cluster node A using the webconsole
# via {{org.apache.sling.installer.provider.jcr}}, the configuration is
persisted in the JCR repository using the format {{.}}
# cluster node A sees the new RegisteredResource for the configuration, but
finds a "live" configuration via the legacy support from point (2) above
# cluster node B sees the new RegisteredResource for the configuration, doesn't
find a matching "live" configuration, and adds the configuration in the format
{{~}}, where {{}} is the same uuid used on cluster node
A
> Configuration in Cluster mode are not in sync
> -
>
> Key: SLING-12283
> URL: https://issues.apache.org/jira/browse/SLING-12283
> Project: Sling
> Issue Type: Bug
>Reporter: Rishabh Daim
>Priority: Major
>
> {color:#172b4d}Configuration in Cluster mode is not in sync. When instances
> are in shared mode, and a new configuration is created under 1st instance, it
> is not reflected correctly in 2nd instance. {color}
> {color:#172b4d}The factory PID and hence properties are altered in the 2nd
> instance.{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-12283) Configuration in Cluster mode are not in sync
[
https://issues.apache.org/jira/browse/SLING-12283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated SLING-12283:
---
Fix Version/s: Installer Configuration Factory 1.4.6
> Configuration in Cluster mode are not in sync
> -
>
> Key: SLING-12283
> URL: https://issues.apache.org/jira/browse/SLING-12283
> Project: Sling
> Issue Type: Bug
>Reporter: Rishabh Daim
>Assignee: Julian Sedding
>Priority: Major
> Fix For: Installer Configuration Factory 1.4.6
>
>
> {color:#172b4d}Configuration in Cluster mode is not in sync. When instances
> are in shared mode, and a new configuration is created under 1st instance, it
> is not reflected correctly in 2nd instance. {color}
> {color:#172b4d}The factory PID and hence properties are altered in the 2nd
> instance.{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-12366) Failure to read from InputStream backed by closed session
Julian Sedding created SLING-12366:
--
Summary: Failure to read from InputStream backed by closed session
Key: SLING-12366
URL: https://issues.apache.org/jira/browse/SLING-12366
Project: Sling
Issue Type: Improvement
Components: XSS Protection API
Affects Versions: XSS Protection API 2.4.0
Reporter: Julian Sedding
Assignee: Julian Sedding
The method {{org.apache.sling.xss.impl.XSSFilterImpl.AntiSamyPolicy#read()}}
opens a {{ResourceResolver}}, finds a {{Resource}}, adapts it to an
{{InputStream}}, returns the {{InputStream}} and closes the
{{ResourceResolver}} via try-with-resource.
This works fine, as long as the {{InputStream}} is not a
{{JcrExternalizableInputStream}}, which is only available when the blob resides
in an external blob store, e.g. azure.
The reason is that the {{JcrExternalizableInputStream}} takes a reference to
the JCR {{Property}} and only reads it lazily. In this scenario, when it reads
the property, the session is already closed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-12366) Failure to read from InputStream backed by closed session
[
https://issues.apache.org/jira/browse/SLING-12366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated SLING-12366:
---
Description:
The method {{org.apache.sling.xss.impl.XSSFilterImpl.AntiSamyPolicy#read()}}
opens a {{ResourceResolver}}, finds a {{Resource}}, adapts it to an
{{InputStream}}, returns the {{InputStream}} and closes the
{{ResourceResolver}} via try-with-resource.
This works fine, as long as the {{InputStream}} is not a
{{JcrExternalizableInputStream}}, which is only available when the blob resides
in an external blob store, e.g. azure.
The reason is that the {{JcrExternalizableInputStream}} takes a reference to
the JCR {{Property}} and only reads it lazily. In this scenario, when it reads
the property, the session is already closed.
A typical stack-trace looks like the one below:
{noformat}
[main] ERROR org.apache.sling.xss.impl.XSSFilterImpl - Unable to load policy
from /libs/sling/xss/config.xml
java.io.IOException: This session has been closed.
at
org.apache.sling.jcr.resource.internal.helper.jcr.JcrExternalizableInputStream.getInputStream(JcrExternalizableInputStream.java:70)
at
org.apache.sling.jcr.resource.internal.helper.jcr.JcrExternalizableInputStream.read(JcrExternalizableInputStream.java:57)
at java.base/java.io.InputStream.read(InputStream.java:271)
at java.base/java.io.InputStream.read(InputStream.java:205)
at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1485)
at org.apache.commons.io.IOUtils.copy(IOUtils.java:1105)
at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1458)
at org.apache.commons.io.IOUtils.copy(IOUtils.java:1083)
at org.apache.sling.xss.impl.PolicyHandler.(PolicyHandler.java:43)
at
org.apache.sling.xss.impl.XSSFilterImpl.setActivePolicy(XSSFilterImpl.java:331)
at
org.apache.sling.xss.impl.XSSFilterImpl.updatePolicy(XSSFilterImpl.java:293)
at
org.apache.sling.xss.impl.XSSFilterImpl.activate(XSSFilterImpl.java:269)
[... snipped the caller ...]
Caused by: javax.jcr.RepositoryException: This session has been closed.
at
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.checkAlive(SessionDelegate.java:323)
at
org.apache.jackrabbit.oak.jcr.delegate.ItemDelegate.checkAlive(ItemDelegate.java:83)
at
org.apache.jackrabbit.oak.jcr.session.operation.ItemOperation.checkPreconditions(ItemOperation.java:34)
at
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.prePerform(SessionDelegate.java:614)
at
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:204)
at
org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
at
org.apache.jackrabbit.oak.jcr.session.PropertyImpl.getValue(PropertyImpl.java:248)
at
org.apache.jackrabbit.oak.jcr.session.PropertyImpl.getBinary(PropertyImpl.java:287)
at
org.apache.sling.jcr.resource.internal.helper.jcr.JcrExternalizableInputStream.getInputStream(JcrExternalizableInputStream.java:68)
... 93 more
{noformat}
was:
The method {{org.apache.sling.xss.impl.XSSFilterImpl.AntiSamyPolicy#read()}}
opens a {{ResourceResolver}}, finds a {{Resource}}, adapts it to an
{{InputStream}}, returns the {{InputStream}} and closes the
{{ResourceResolver}} via try-with-resource.
This works fine, as long as the {{InputStream}} is not a
{{JcrExternalizableInputStream}}, which is only available when the blob resides
in an external blob store, e.g. azure.
The reason is that the {{JcrExternalizableInputStream}} takes a reference to
the JCR {{Property}} and only reads it lazily. In this scenario, when it reads
the property, the session is already closed.
> Failure to read from InputStream backed by closed session
> -
>
> Key: SLING-12366
> URL: https://issues.apache.org/jira/browse/SLING-12366
> Project: Sling
> Issue Type: Improvement
> Components: XSS Protection API
>Affects Versions: XSS Protection API 2.4.0
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Major
>
> The method {{org.apache.sling.xss.impl.XSSFilterImpl.AntiSamyPolicy#read()}}
> opens a {{ResourceResolver}}, finds a {{Resource}}, adapts it to an
> {{InputStream}}, returns the {{InputStream}} and closes the
> {{ResourceResolver}} via try-with-resource.
> This works fine, as long as the {{InputStream}} is not a
> {{JcrExternalizableInputStream}}, which is only available when the blob
> resides in an external blob store, e.g. azure.
> The reason is that the {{JcrExternalizableInputStream}} takes a reference to
> the JCR {{Property}} and only reads it lazily. In this scenario, when it
> reads the property, the session is already closed.
> A typical stack-trace l
[jira] [Created] (SLING-12368) regression: rule for "ol" tag fails on java 9+ after SLING-12276
Julian Sedding created SLING-12368:
--
Summary: regression: rule for "ol" tag fails on java 9+ after
SLING-12276
Key: SLING-12368
URL: https://issues.apache.org/jira/browse/SLING-12368
Project: Sling
Issue Type: Improvement
Components: XSS Protection API
Reporter: Julian Sedding
Assignee: Julian Sedding
Fix For: XSS Protection API 2.4.2
The dependency update in SLING-12276 brings a change, where
{{java.lang.Set.of()}} methods are used _if_ the runtime is java 9+.
{{Set.of()}} throws an exception if any two arguments are equal.
The configuration for the "ol" tag is as follows:
{code:xml}
{code}
The literals "a", "A", "i", "I", "1" are all converted to lower case and result
in the following call {{{}Set.of("a", "a", "i", "i", "1"){}}}. On Java 9+, this
results in the following exception:
{noformat}
java.lang.IllegalArgumentException: duplicate element: a
at
java.base/java.util.ImmutableCollections$SetN.(ImmutableCollections.java:587)
at java.base/java.util.Set.of(Set.java:701)
at org.owasp.shim.ForJava9AndLater.setOf(ForJava9AndLater.java:61)
at
org.owasp.html.HtmlPolicyBuilder$AttributeBuilder.matching(HtmlPolicyBuilder.java:933)
at
org.apache.sling.xss.impl.AntiSamyPolicyAdapter.(AntiSamyPolicyAdapter.java:146)
at org.apache.sling.xss.impl.HtmlSanitizer.(HtmlSanitizer.java:40)
...
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-12408) simplify logic in AntiSamyPolicyAdapter
Julian Sedding created SLING-12408:
--
Summary: simplify logic in AntiSamyPolicyAdapter
Key: SLING-12408
URL: https://issues.apache.org/jira/browse/SLING-12408
Project: Sling
Issue Type: Improvement
Components: XSS Protection API
Affects Versions: XSS Protection API 2.4.0
Reporter: Julian Sedding
Assignee: Julian Sedding
Fix For: XSS Protection API 2.4.2
The logic in {{AntiSamyPolicyAdapter}} has quite a lot of unnecessary case
distinctions and can be simplified by removing code.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-12368) regression: rule for "ol" tag fails on java 9+ after SLING-12276
[
https://issues.apache.org/jira/browse/SLING-12368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding resolved SLING-12368.
Resolution: Duplicate
Yes [~joerghoh], this is a duplicate of SLING-12388.
> regression: rule for "ol" tag fails on java 9+ after SLING-12276
>
>
> Key: SLING-12368
> URL: https://issues.apache.org/jira/browse/SLING-12368
> Project: Sling
> Issue Type: Improvement
> Components: XSS Protection API
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Major
> Fix For: XSS Protection API 2.4.2
>
>
> The dependency update in SLING-12276 brings a change, where
> {{java.lang.Set.of()}} methods are used _if_ the runtime is java 9+.
> {{Set.of()}} throws an exception if any two arguments are equal.
> The configuration for the "ol" tag is as follows:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> The literals "a", "A", "i", "I", "1" are all converted to lower case and
> result in the following call {{{}Set.of("a", "a", "i", "i", "1"){}}}. On Java
> 9+, this results in the following exception:
> {noformat}
> java.lang.IllegalArgumentException: duplicate element: a
> at
> java.base/java.util.ImmutableCollections$SetN.(ImmutableCollections.java:587)
> at java.base/java.util.Set.of(Set.java:701)
> at org.owasp.shim.ForJava9AndLater.setOf(ForJava9AndLater.java:61)
> at
> org.owasp.html.HtmlPolicyBuilder$AttributeBuilder.matching(HtmlPolicyBuilder.java:933)
> at
> org.apache.sling.xss.impl.AntiSamyPolicyAdapter.(AntiSamyPolicyAdapter.java:146)
> at org.apache.sling.xss.impl.HtmlSanitizer.(HtmlSanitizer.java:40)
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-12368) regression: rule for "ol" tag fails on java 9+ after SLING-12276
[
https://issues.apache.org/jira/browse/SLING-12368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated SLING-12368:
---
Fix Version/s: (was: XSS Protection API 2.4.2)
> regression: rule for "ol" tag fails on java 9+ after SLING-12276
>
>
> Key: SLING-12368
> URL: https://issues.apache.org/jira/browse/SLING-12368
> Project: Sling
> Issue Type: Improvement
> Components: XSS Protection API
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Major
>
> The dependency update in SLING-12276 brings a change, where
> {{java.lang.Set.of()}} methods are used _if_ the runtime is java 9+.
> {{Set.of()}} throws an exception if any two arguments are equal.
> The configuration for the "ol" tag is as follows:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> The literals "a", "A", "i", "I", "1" are all converted to lower case and
> result in the following call {{{}Set.of("a", "a", "i", "i", "1"){}}}. On Java
> 9+, this results in the following exception:
> {noformat}
> java.lang.IllegalArgumentException: duplicate element: a
> at
> java.base/java.util.ImmutableCollections$SetN.(ImmutableCollections.java:587)
> at java.base/java.util.Set.of(Set.java:701)
> at org.owasp.shim.ForJava9AndLater.setOf(ForJava9AndLater.java:61)
> at
> org.owasp.html.HtmlPolicyBuilder$AttributeBuilder.matching(HtmlPolicyBuilder.java:933)
> at
> org.apache.sling.xss.impl.AntiSamyPolicyAdapter.(AntiSamyPolicyAdapter.java:146)
> at org.apache.sling.xss.impl.HtmlSanitizer.(HtmlSanitizer.java:40)
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-12408) simplify logic in AntiSamyPolicyAdapter
[
https://issues.apache.org/jira/browse/SLING-12408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated SLING-12408:
---
Description:
The logic in {{AntiSamyPolicyAdapter}} has quite a lot of unnecessary case
distinctions and can be simplified by removing code.
was:The logic in {{AntiSamyPolicyAdapter}} has quite a lot of unnecessary
case distinctions and can be simplified by removing code.
> simplify logic in AntiSamyPolicyAdapter
> ---
>
> Key: SLING-12408
> URL: https://issues.apache.org/jira/browse/SLING-12408
> Project: Sling
> Issue Type: Improvement
> Components: XSS Protection API
>Affects Versions: XSS Protection API 2.4.0
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
> Fix For: XSS Protection API 2.4.2
>
>
> The logic in {{AntiSamyPolicyAdapter}} has quite a lot of unnecessary case
> distinctions and can be simplified by removing code.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-12408) simplify logic in AntiSamyPolicyAdapter
[
https://issues.apache.org/jira/browse/SLING-12408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding resolved SLING-12408.
Resolution: Fixed
> simplify logic in AntiSamyPolicyAdapter
> ---
>
> Key: SLING-12408
> URL: https://issues.apache.org/jira/browse/SLING-12408
> Project: Sling
> Issue Type: Improvement
> Components: XSS Protection API
>Affects Versions: XSS Protection API 2.4.0
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
> Fix For: XSS Protection API 2.4.2
>
>
> The logic in {{AntiSamyPolicyAdapter}} has quite a lot of unnecessary case
> distinctions and can be simplified by removing code.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-12366) Failure to read from InputStream backed by closed session
[
https://issues.apache.org/jira/browse/SLING-12366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding resolved SLING-12366.
Resolution: Fixed
> Failure to read from InputStream backed by closed session
> -
>
> Key: SLING-12366
> URL: https://issues.apache.org/jira/browse/SLING-12366
> Project: Sling
> Issue Type: Improvement
> Components: XSS Protection API
>Affects Versions: XSS Protection API 2.4.0
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Major
>
> The method {{org.apache.sling.xss.impl.XSSFilterImpl.AntiSamyPolicy#read()}}
> opens a {{ResourceResolver}}, finds a {{Resource}}, adapts it to an
> {{InputStream}}, returns the {{InputStream}} and closes the
> {{ResourceResolver}} via try-with-resource.
> This works fine, as long as the {{InputStream}} is not a
> {{JcrExternalizableInputStream}}, which is only available when the blob
> resides in an external blob store, e.g. azure.
> The reason is that the {{JcrExternalizableInputStream}} takes a reference to
> the JCR {{Property}} and only reads it lazily. In this scenario, when it
> reads the property, the session is already closed.
> A typical stack-trace looks like the one below:
> {noformat}
> [main] ERROR org.apache.sling.xss.impl.XSSFilterImpl - Unable to load policy
> from /libs/sling/xss/config.xml
> java.io.IOException: This session has been closed.
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrExternalizableInputStream.getInputStream(JcrExternalizableInputStream.java:70)
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrExternalizableInputStream.read(JcrExternalizableInputStream.java:57)
> at java.base/java.io.InputStream.read(InputStream.java:271)
> at java.base/java.io.InputStream.read(InputStream.java:205)
> at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1485)
> at org.apache.commons.io.IOUtils.copy(IOUtils.java:1105)
> at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1458)
> at org.apache.commons.io.IOUtils.copy(IOUtils.java:1083)
> at org.apache.sling.xss.impl.PolicyHandler.(PolicyHandler.java:43)
> at
> org.apache.sling.xss.impl.XSSFilterImpl.setActivePolicy(XSSFilterImpl.java:331)
> at
> org.apache.sling.xss.impl.XSSFilterImpl.updatePolicy(XSSFilterImpl.java:293)
> at
> org.apache.sling.xss.impl.XSSFilterImpl.activate(XSSFilterImpl.java:269)
> [... snipped the caller ...]
> Caused by: javax.jcr.RepositoryException: This session has been closed.
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.checkAlive(SessionDelegate.java:323)
> at
> org.apache.jackrabbit.oak.jcr.delegate.ItemDelegate.checkAlive(ItemDelegate.java:83)
> at
> org.apache.jackrabbit.oak.jcr.session.operation.ItemOperation.checkPreconditions(ItemOperation.java:34)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.prePerform(SessionDelegate.java:614)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:204)
> at
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
> at
> org.apache.jackrabbit.oak.jcr.session.PropertyImpl.getValue(PropertyImpl.java:248)
> at
> org.apache.jackrabbit.oak.jcr.session.PropertyImpl.getBinary(PropertyImpl.java:287)
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrExternalizableInputStream.getInputStream(JcrExternalizableInputStream.java:68)
> ... 93 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-12366) Failure to read from InputStream backed by closed session
[
https://issues.apache.org/jira/browse/SLING-12366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated SLING-12366:
---
Fix Version/s: XSS Protection API 2.4.2
> Failure to read from InputStream backed by closed session
> -
>
> Key: SLING-12366
> URL: https://issues.apache.org/jira/browse/SLING-12366
> Project: Sling
> Issue Type: Improvement
> Components: XSS Protection API
>Affects Versions: XSS Protection API 2.4.0
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Major
> Fix For: XSS Protection API 2.4.2
>
>
> The method {{org.apache.sling.xss.impl.XSSFilterImpl.AntiSamyPolicy#read()}}
> opens a {{ResourceResolver}}, finds a {{Resource}}, adapts it to an
> {{InputStream}}, returns the {{InputStream}} and closes the
> {{ResourceResolver}} via try-with-resource.
> This works fine, as long as the {{InputStream}} is not a
> {{JcrExternalizableInputStream}}, which is only available when the blob
> resides in an external blob store, e.g. azure.
> The reason is that the {{JcrExternalizableInputStream}} takes a reference to
> the JCR {{Property}} and only reads it lazily. In this scenario, when it
> reads the property, the session is already closed.
> A typical stack-trace looks like the one below:
> {noformat}
> [main] ERROR org.apache.sling.xss.impl.XSSFilterImpl - Unable to load policy
> from /libs/sling/xss/config.xml
> java.io.IOException: This session has been closed.
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrExternalizableInputStream.getInputStream(JcrExternalizableInputStream.java:70)
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrExternalizableInputStream.read(JcrExternalizableInputStream.java:57)
> at java.base/java.io.InputStream.read(InputStream.java:271)
> at java.base/java.io.InputStream.read(InputStream.java:205)
> at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1485)
> at org.apache.commons.io.IOUtils.copy(IOUtils.java:1105)
> at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1458)
> at org.apache.commons.io.IOUtils.copy(IOUtils.java:1083)
> at org.apache.sling.xss.impl.PolicyHandler.(PolicyHandler.java:43)
> at
> org.apache.sling.xss.impl.XSSFilterImpl.setActivePolicy(XSSFilterImpl.java:331)
> at
> org.apache.sling.xss.impl.XSSFilterImpl.updatePolicy(XSSFilterImpl.java:293)
> at
> org.apache.sling.xss.impl.XSSFilterImpl.activate(XSSFilterImpl.java:269)
> [... snipped the caller ...]
> Caused by: javax.jcr.RepositoryException: This session has been closed.
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.checkAlive(SessionDelegate.java:323)
> at
> org.apache.jackrabbit.oak.jcr.delegate.ItemDelegate.checkAlive(ItemDelegate.java:83)
> at
> org.apache.jackrabbit.oak.jcr.session.operation.ItemOperation.checkPreconditions(ItemOperation.java:34)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.prePerform(SessionDelegate.java:614)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:204)
> at
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
> at
> org.apache.jackrabbit.oak.jcr.session.PropertyImpl.getValue(PropertyImpl.java:248)
> at
> org.apache.jackrabbit.oak.jcr.session.PropertyImpl.getBinary(PropertyImpl.java:287)
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrExternalizableInputStream.getInputStream(JcrExternalizableInputStream.java:68)
> ... 93 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12388) Handle duplicate literals
[
https://issues.apache.org/jira/browse/SLING-12388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17873519#comment-17873519
]
Julian Sedding commented on SLING-12388:
I added a test in https://github.com/apache/sling-org-apache-sling-xss/pull/44
> Handle duplicate literals
> -
>
> Key: SLING-12388
> URL: https://issues.apache.org/jira/browse/SLING-12388
> Project: Sling
> Issue Type: Improvement
> Components: XSS Protection API
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: XSS Protection API 2.4.2
>
>
> When testing the most recent SNAPSHOT version of the bundle against a recent
> AEM as Cloud Service instance, I got this exception:
> {noformat}
> 13.06.2024 10:04:54.106 *ERROR* [FelixStartLevel]
> org.apache.sling.xss.impl.XSSFilterImpl Unable to load policy from
> /libs/cq/xssprotection/config.xml
> java.lang.IllegalArgumentException: duplicate element: a
> at
> java.base/java.util.ImmutableCollections$SetN.(ImmutableCollections.java:604)
> at java.base/java.util.Set.of(Set.java:701)
> at org.owasp.shim.ForJava9AndLater.setOf(ForJava9AndLater.java:61)
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at
> org.owasp.html.HtmlPolicyBuilder$AttributeBuilder.matching(HtmlPolicyBuilder.java:933)
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at
> org.apache.sling.xss.impl.AntiSamyPolicyAdapter.(AntiSamyPolicyAdapter.java:145)
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at
> org.apache.sling.xss.impl.HtmlSanitizer.(HtmlSanitizer.java:40)
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at
> org.apache.sling.xss.impl.PolicyHandler.(PolicyHandler.java:47)
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at
> org.apache.sling.xss.impl.XSSFilterImpl.setActivePolicy(XSSFilterImpl.java:331)
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at
> org.apache.sling.xss.impl.XSSFilterImpl.updatePolicy(XSSFilterImpl.java:293)
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at
> org.apache.sling.xss.impl.XSSFilterImpl.activate(XSSFilterImpl.java:269)
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [...]
> 13.06.2024 10:04:54.109 *INFO* [FelixStartLevel]
> org.apache.sling.xss.impl.XSSFilterImpl Could not find a policy file at the
> configured location cq/xssprotection/config.xml. Attempting to use the
> default resource embedded in the bundle.
> 13.06.2024 10:04:54.282 *INFO* [FelixStartLevel]
> org.apache.sling.xss.impl.XSSFilterImpl Installed policy from the embedded
> SLING-INF/content/config.xml file from the bundle.
> {noformat}
> Analyzing this I found this snippet of the configuration is responsible for
> it:
> {noformat}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {noformat}
> This configuration works with the previous version 2.4.0 of the XSS bundle.
> When I remove the uppercase variants of the literals from the configuration,
> I don't get the exception anymore with the latest SNAPSHOT.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12385) OSGi mock context seems to not take service ranking into account
[
https://issues.apache.org/jira/browse/SLING-12385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17874200#comment-17874200
]
Julian Sedding commented on SLING-12385:
[~bartthierens] further to Henry's comments, your assumption that a lower
service ranking is ordered before a higher one is wrong.
{quote}
The _ranking order_ is defined as follows:
* Sorted on descending ranking number (highest first)
* If the ranking numbers are equal, sorted on ascending {{service.id}}
property (oldest first).
{quote}
Source:
https://docs.osgi.org/specification/osgi.core/8.0.0/framework.service.html#framework.service.servicerankingorder
> OSGi mock context seems to not take service ranking into account
>
>
> Key: SLING-12385
> URL: https://issues.apache.org/jira/browse/SLING-12385
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Affects Versions: Testing OSGi Mock 3.4.2
>Reporter: Bart Thierens
>Priority: Major
>
> Logging this issue here as I can't log it in github. I assume this is the
> correct approach.
> I am unable to make my registered services in a test case mimick the same
> ordering behaviour than in an actual OSGi environment. The
> AemContext/AemContextImpl/SlingContextImpl/OsgiContextImpl does not respect
> the `@ServiceRanking` annotation, nor the component property
> "service.ranking".
> It seems vital to be able to test that a certain part of application logic
> executes certain services in order, and that seems impossible now - unless
> the developer registers the services exactly in the order he expects them,
> which beats the purpose of the test.
> If this is documented behaviour, I can't find it anywhere... (And it's still
> not correct imho)
> Personal use case: A certain component that has "processors" (which are
> components implementing a single service) that are ordered by service ranking
> (low = first, high = later). When a service is disabled/unregistered,
> registered or even re-registered, the order must stay consistent (low =>
> high). This actually works perfectly, but not in test-cases.
> I created a demo (AEM) project that showcases this problem:
> [https://github.com/senn/aemcontext-no-serviceranking-ordering]
> It contains tests for the various context implementations and also a separate
> branch that has the same issue without `@ServiceRanking` and with the
> "service.ranking" properties.
> I don't have a fix ready, but might look into it in a few weeks when I have
> time.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-12310) Fix test compatibility with java 17
[ https://issues.apache.org/jira/browse/SLING-12310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding updated SLING-12310: --- Affects Version/s: i18n 2.6.2 > Fix test compatibility with java 17 > --- > > Key: SLING-12310 > URL: https://issues.apache.org/jira/browse/SLING-12310 > Project: Sling > Issue Type: Improvement > Components: i18n >Affects Versions: i18n 2.6.2 >Reporter: Eric Norman >Assignee: Eric Norman >Priority: Major > Fix For: i18n 2.6.4 > > > Some of the tests are failing when building with java 17. > * bump oak/jackrabbit dependencies to the oldest still supported and > compatible version > * replace powermock usage with mockito > * replace dependency on org.apache.sling.commons.testing with sling mocks > equivalent > * update various dependency versions to compatible versions > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12310) Fix test compatibility with java 17
[ https://issues.apache.org/jira/browse/SLING-12310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding updated SLING-12310: --- Component/s: i18n > Fix test compatibility with java 17 > --- > > Key: SLING-12310 > URL: https://issues.apache.org/jira/browse/SLING-12310 > Project: Sling > Issue Type: Improvement > Components: i18n >Reporter: Eric Norman >Assignee: Eric Norman >Priority: Major > Fix For: i18n 2.6.4 > > > Some of the tests are failing when building with java 17. > * bump oak/jackrabbit dependencies to the oldest still supported and > compatible version > * replace powermock usage with mockito > * replace dependency on org.apache.sling.commons.testing with sling mocks > equivalent > * update various dependency versions to compatible versions > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12315) A race condition leads to failing resource-bundle registration during deactivation
[
https://issues.apache.org/jira/browse/SLING-12315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding resolved SLING-12315.
Resolution: Fixed
> A race condition leads to failing resource-bundle registration during
> deactivation
> --
>
> Key: SLING-12315
> URL: https://issues.apache.org/jira/browse/SLING-12315
> Project: Sling
> Issue Type: Bug
> Components: i18n
>Affects Versions: i18n 2.6.2
>Reporter: Elia Colombo
>Assignee: Elia Colombo
>Priority: Major
> Fix For: i18n 2.6.4
>
>
> The following exception was observed:
> {code:java}
> [sling-default-5-ResourceBundleProvider: reload all resource bundles]
> org.apache.sling.commons.scheduler.impl.QuartzScheduler Exception during job
> execution of job
> 'org.apache.sling.i18n.impl.JcrResourceBundleProvider$1@688bc8e' with name
> 'ResourceBundleProvider: reload all resource bundles' : Cannot invoke
> "org.osgi.framework.BundleContext.registerService(java.lang.Class, Object,
> java.util.Dictionary)" because "this.bundleContext" is
> nulljava.lang.NullPointerException: Cannot invoke
> "org.osgi.framework.BundleContext.registerService(java.lang.Class, Object,
> java.util.Dictionary)" because "this.bundleContext" is null at
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.registerResourceBundle(JcrResourceBundleProvider.java:532)
> [org.apache.sling.i18n:2.6.2]{code}
> During the deactivation of JcrResourceBundleProvider, ReloadBundle jobs that
> are still running can try to register new resourceBundles. This fails, if
> deactivate already set bundleContext to null.
> Proposed solution:
> * Simplify and improve the thread-safety model by encapsulating bundle
> service registration/deregistration and bookkeeping in the new class
> ResourceBundleRegistry.
> * The thread-safety concerns related to registration, deregistration,
> bookkeeping of the resource bundles and of their associated service
> registrations are encapsulated in the new class.
> * The object is created in the activate method and closed in the deactivated
> method.
> * The new class receives bundleContext in the constructor, removing the need
> for a field in JcrResourceBundleProvider.
> * The isClosed state of the new class is used as a cancel flag during
> deactivation to prevent new registrations, processing of new onChange events
> and scheduling new bundle reloading jobs during deactivation.
> * Add unit tests for interleaved registration, clearing, deactivation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-12315) A race condition leads to failing resource-bundle registration during deactivation
[
https://issues.apache.org/jira/browse/SLING-12315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated SLING-12315:
---
Affects Version/s: i18n 2.6.2
> A race condition leads to failing resource-bundle registration during
> deactivation
> --
>
> Key: SLING-12315
> URL: https://issues.apache.org/jira/browse/SLING-12315
> Project: Sling
> Issue Type: Bug
> Components: i18n
>Affects Versions: i18n 2.6.2
>Reporter: Elia Colombo
>Assignee: Elia Colombo
>Priority: Major
> Fix For: i18n 2.6.4
>
>
> The following exception was observed:
> {code:java}
> [sling-default-5-ResourceBundleProvider: reload all resource bundles]
> org.apache.sling.commons.scheduler.impl.QuartzScheduler Exception during job
> execution of job
> 'org.apache.sling.i18n.impl.JcrResourceBundleProvider$1@688bc8e' with name
> 'ResourceBundleProvider: reload all resource bundles' : Cannot invoke
> "org.osgi.framework.BundleContext.registerService(java.lang.Class, Object,
> java.util.Dictionary)" because "this.bundleContext" is
> nulljava.lang.NullPointerException: Cannot invoke
> "org.osgi.framework.BundleContext.registerService(java.lang.Class, Object,
> java.util.Dictionary)" because "this.bundleContext" is null at
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.registerResourceBundle(JcrResourceBundleProvider.java:532)
> [org.apache.sling.i18n:2.6.2]{code}
> During the deactivation of JcrResourceBundleProvider, ReloadBundle jobs that
> are still running can try to register new resourceBundles. This fails, if
> deactivate already set bundleContext to null.
> Proposed solution:
> * Simplify and improve the thread-safety model by encapsulating bundle
> service registration/deregistration and bookkeeping in the new class
> ResourceBundleRegistry.
> * The thread-safety concerns related to registration, deregistration,
> bookkeeping of the resource bundles and of their associated service
> registrations are encapsulated in the new class.
> * The object is created in the activate method and closed in the deactivated
> method.
> * The new class receives bundleContext in the constructor, removing the need
> for a field in JcrResourceBundleProvider.
> * The isClosed state of the new class is used as a cancel flag during
> deactivation to prevent new registrations, processing of new onChange events
> and scheduling new bundle reloading jobs during deactivation.
> * Add unit tests for interleaved registration, clearing, deactivation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-12312) add jakarta.servlet support in RequestLocaleResolver
[ https://issues.apache.org/jira/browse/SLING-12312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding updated SLING-12312: --- Fix Version/s: (was: i18n 2.6.4) > add jakarta.servlet support in RequestLocaleResolver > > > Key: SLING-12312 > URL: https://issues.apache.org/jira/browse/SLING-12312 > Project: Sling > Issue Type: Improvement >Reporter: Eric Norman >Assignee: Eric Norman >Priority: Major > > provide a variant of the RequestLocaleResolver#resolveLocale call that > accepts a jakarta.servlet.http.HttpServletRequest for use cases that have > migrated to EE9 or later. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12315) A race condition leads to failing resource-bundle registration during deactivation
[
https://issues.apache.org/jira/browse/SLING-12315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding closed SLING-12315.
--
> A race condition leads to failing resource-bundle registration during
> deactivation
> --
>
> Key: SLING-12315
> URL: https://issues.apache.org/jira/browse/SLING-12315
> Project: Sling
> Issue Type: Bug
> Components: i18n
>Affects Versions: i18n 2.6.2
>Reporter: Elia Colombo
>Assignee: Elia Colombo
>Priority: Major
> Fix For: I18N Support 2.6.4
>
>
> The following exception was observed:
> {code:java}
> [sling-default-5-ResourceBundleProvider: reload all resource bundles]
> org.apache.sling.commons.scheduler.impl.QuartzScheduler Exception during job
> execution of job
> 'org.apache.sling.i18n.impl.JcrResourceBundleProvider$1@688bc8e' with name
> 'ResourceBundleProvider: reload all resource bundles' : Cannot invoke
> "org.osgi.framework.BundleContext.registerService(java.lang.Class, Object,
> java.util.Dictionary)" because "this.bundleContext" is
> nulljava.lang.NullPointerException: Cannot invoke
> "org.osgi.framework.BundleContext.registerService(java.lang.Class, Object,
> java.util.Dictionary)" because "this.bundleContext" is null at
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.registerResourceBundle(JcrResourceBundleProvider.java:532)
> [org.apache.sling.i18n:2.6.2]{code}
> During the deactivation of JcrResourceBundleProvider, ReloadBundle jobs that
> are still running can try to register new resourceBundles. This fails, if
> deactivate already set bundleContext to null.
> Proposed solution:
> * Simplify and improve the thread-safety model by encapsulating bundle
> service registration/deregistration and bookkeeping in the new class
> ResourceBundleRegistry.
> * The thread-safety concerns related to registration, deregistration,
> bookkeeping of the resource bundles and of their associated service
> registrations are encapsulated in the new class.
> * The object is created in the activate method and closed in the deactivated
> method.
> * The new class receives bundleContext in the constructor, removing the need
> for a field in JcrResourceBundleProvider.
> * The isClosed state of the new class is used as a cancel flag during
> deactivation to prevent new registrations, processing of new onChange events
> and scheduling new bundle reloading jobs during deactivation.
> * Add unit tests for interleaved registration, clearing, deactivation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SLING-12310) Fix test compatibility with java 17
[ https://issues.apache.org/jira/browse/SLING-12310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding closed SLING-12310. -- > Fix test compatibility with java 17 > --- > > Key: SLING-12310 > URL: https://issues.apache.org/jira/browse/SLING-12310 > Project: Sling > Issue Type: Improvement > Components: i18n >Affects Versions: i18n 2.6.2 >Reporter: Eric Norman >Assignee: Eric Norman >Priority: Major > Fix For: I18N Support 2.6.4 > > > Some of the tests are failing when building with java 17. > * bump oak/jackrabbit dependencies to the oldest still supported and > compatible version > * replace powermock usage with mockito > * replace dependency on org.apache.sling.commons.testing with sling mocks > equivalent > * update various dependency versions to compatible versions > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12420) JSP scripts are falsely re-compiled on events from HTL engine
Julian Sedding created SLING-12420:
--
Summary: JSP scripts are falsely re-compiled on events from HTL
engine
Key: SLING-12420
URL: https://issues.apache.org/jira/browse/SLING-12420
Project: Sling
Issue Type: Improvement
Components: Scripting
Affects Versions: Scripting JSP 2.6.2
Reporter: Julian Sedding
Assignee: Julian Sedding
Fix For: Scripting JSP 2.6.4
The JSP scripting engine renews its {{{color:#00}JspRuntimeContext{color}}}
on every change, even from other scripting engines. This can lead to JSP
scripts being unnecessarily re-compiled.
The events should be filtered and only relevant events should lead to the
renewal of the {{
{color:#00}JspRuntimeContext{color}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-12420) JSP scripts are falsely re-compiled on events from HTL engine
[
https://issues.apache.org/jira/browse/SLING-12420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated SLING-12420:
---
Description:
The JSP scripting engine renews its {{JspRuntimeContext}} on every change, even
from other scripting engines. This can lead to JSP scripts being unnecessarily
re-compiled.
The events should be filtered and only relevant events should lead to the
renewal of the {{JspRuntimeContext}}.
was:
The JSP scripting engine renews its {{{color:#00}JspRuntimeContext{color}}}
on every change, even from other scripting engines. This can lead to JSP
scripts being unnecessarily re-compiled.
The events should be filtered and only relevant events should lead to the
renewal of the {{
{color:#00}JspRuntimeContext{color}}}.
> JSP scripts are falsely re-compiled on events from HTL engine
> -
>
> Key: SLING-12420
> URL: https://issues.apache.org/jira/browse/SLING-12420
> Project: Sling
> Issue Type: Improvement
> Components: Scripting
>Affects Versions: Scripting JSP 2.6.2
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
> Fix For: Scripting JSP 2.6.4
>
>
> The JSP scripting engine renews its {{JspRuntimeContext}} on every change,
> even from other scripting engines. This can lead to JSP scripts being
> unnecessarily re-compiled.
> The events should be filtered and only relevant events should lead to the
> renewal of the {{JspRuntimeContext}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] Created: (SLING-1288) OSGi Installer does not cleanup RegisteredResourceImpl temp files
OSGi Installer does not cleanup RegisteredResourceImpl temp files - Key: SLING-1288 URL: https://issues.apache.org/jira/browse/SLING-1288 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: OSGi Installer 3.0.2 Reporter: Julian Sedding The OSGi Installer service writes RegisteredResourceImpl.[timestamp] files into its felix bundle directory (bundlexx/data) and never cleans them up. From my tests it seems that the disc space taken increases linearly with each bunlde restart (and thus also with every server restart). In the scenario I tested 63MB of data was written to the directory on each bundle start. I.e after 17 restarts more than 1GB disc space is lost. The RegisteredResourceImpl files should be removed when they are no longer needed in order to reclaim disc space. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1289) Additional ScriptSelectionTest case
[ https://issues.apache.org/jira/browse/SLING-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding updated SLING-1289: -- Attachment: SLING-1289-ScriptSelectionTest.patch > Additional ScriptSelectionTest case > --- > > Key: SLING-1289 > URL: https://issues.apache.org/jira/browse/SLING-1289 > Project: Sling > Issue Type: Test > Components: Servlets >Affects Versions: Servlets Resolver 2.0.8 >Reporter: Julian Sedding >Priority: Trivial > Attachments: SLING-1289-ScriptSelectionTest.patch > > > The ScriptSelectionTest covers only one way to specify scripts for POST > requests with a selector. Imagine resource /a with resource type foo/bar. A > POST request to /a.print.html will be handled by the following two scripts: > /apps/foo/bar/print/POST.esp > /apps/foo/bar/print.POST.esp > So far only the first case is tested. The attached patch adds a test for the > second (IMHO more concise) syntax. > I stumbled across this, because I was looking for documentation on the topic. > There is a wiki page[1] with some (outdated?) information on the topic, but I > couldn't find much more. Maybe I just missed it. If not, it would be nice to > get this documented on the sling website, with the examples section extended > to cover POST requests with selectors. > [1] http://cwiki.apache.org/SLING/url-to-script-resolution.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1289) Additional ScriptSelectionTest case
Additional ScriptSelectionTest case --- Key: SLING-1289 URL: https://issues.apache.org/jira/browse/SLING-1289 Project: Sling Issue Type: Test Components: Servlets Affects Versions: Servlets Resolver 2.0.8 Reporter: Julian Sedding Priority: Trivial Attachments: SLING-1289-ScriptSelectionTest.patch The ScriptSelectionTest covers only one way to specify scripts for POST requests with a selector. Imagine resource /a with resource type foo/bar. A POST request to /a.print.html will be handled by the following two scripts: /apps/foo/bar/print/POST.esp /apps/foo/bar/print.POST.esp So far only the first case is tested. The attached patch adds a test for the second (IMHO more concise) syntax. I stumbled across this, because I was looking for documentation on the topic. There is a wiki page[1] with some (outdated?) information on the topic, but I couldn't find much more. Maybe I just missed it. If not, it would be nice to get this documented on the sling website, with the examples section extended to cover POST requests with selectors. [1] http://cwiki.apache.org/SLING/url-to-script-resolution.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1760) Sling Explorer "add property" doesn't respect encoding
Sling Explorer "add property" doesn't respect encoding -- Key: SLING-1760 URL: https://issues.apache.org/jira/browse/SLING-1760 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Sling Explorer 1.0.0 Reporter: Julian Sedding Setting a string property with non-ascii characters garbles the value (e.g. strüng) due to missing UTF-8 encoding. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1760) Sling Explorer "add property" doesn't respect encoding
[ https://issues.apache.org/jira/browse/SLING-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding updated SLING-1760: -- Attachment: explorer.js.patch Attached patch fixes the issue. > Sling Explorer "add property" doesn't respect encoding > -- > > Key: SLING-1760 > URL: https://issues.apache.org/jira/browse/SLING-1760 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: Sling Explorer 1.0.0 >Reporter: Julian Sedding > Attachments: explorer.js.patch > > > Setting a string property with non-ascii characters garbles the value (e.g. > strüng) due to missing UTF-8 encoding. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1761) JcrPropertyResource sets incorrect content length for strings containing non-ascii character
JcrPropertyResource sets incorrect content length for strings containing non-ascii character Key: SLING-1761 URL: https://issues.apache.org/jira/browse/SLING-1761 Project: Sling Issue Type: Bug Components: JCR Affects Versions: JCR Resource 2.0.6 Reporter: Julian Sedding JcrPropertyResource sets the content length of the property in its metadata. To do so, it uses javax.jcr.Property#getLength() to determine the content length. The documentation for javax.jcr.Property#getLength() states "[...] Returns the length in bytes if the value is a PropertyType.BINARY, otherwise it returns the number of characters needed to display the value in its string form. [...]". The documentation in ResourceMetadata is not explicit, but from its usage in StreamRendererServlet I conclude that ResourceMetadata.getContentLength() is intended for use in the Content-Length HTTP header. If my assumptions are correct, the content length indicates the number of bytes in the string, while javax.jcr.Property#getLength() returns the number of characters. The effect of this can be observed by the following steps: * create a string property "/utf8string" with value "Bär" * access this property using a browser (e.g. http://localhost:/utf8string), so that the property gets rendered by the StreamRendererServlet => the string is rendered incorrectly (due to a missing Content-Type header) => the string is cut off (due to the incorrectly set Content-Length header) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1761) JcrPropertyResource sets incorrect content length for strings containing non-ascii character
[ https://issues.apache.org/jira/browse/SLING-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding updated SLING-1761: -- Attachment: SLING-1761-tests.patch Some test cases and a minor fix to JcrItemResourceTestBase. > JcrPropertyResource sets incorrect content length for strings containing > non-ascii character > > > Key: SLING-1761 > URL: https://issues.apache.org/jira/browse/SLING-1761 > Project: Sling > Issue Type: Bug > Components: JCR >Affects Versions: JCR Resource 2.0.6 >Reporter: Julian Sedding > Attachments: SLING-1761-tests.patch > > > JcrPropertyResource sets the content length of the property in its metadata. > To do so, it uses javax.jcr.Property#getLength() to determine the content > length. > The documentation for javax.jcr.Property#getLength() states "[...] Returns > the length in bytes if the value is a PropertyType.BINARY, otherwise it > returns the number of characters needed to display the value in its string > form. [...]". > The documentation in ResourceMetadata is not explicit, but from its usage in > StreamRendererServlet I conclude that ResourceMetadata.getContentLength() is > intended for use in the Content-Length HTTP header. If my assumptions are > correct, the content length indicates the number of bytes in the string, > while javax.jcr.Property#getLength() returns the number of characters. > The effect of this can be observed by the following steps: > * create a string property "/utf8string" with value "Bär" > * access this property using a browser (e.g. > http://localhost:/utf8string), so that the property gets rendered by the > StreamRendererServlet > => the string is rendered incorrectly (due to a missing Content-Type header) > => the string is cut off (due to the incorrectly set Content-Length header) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1761) JcrPropertyResource sets incorrect content length for strings containing non-ascii character
[ https://issues.apache.org/jira/browse/SLING-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding updated SLING-1761: -- Attachment: SLING-1761.patch A patch for the content-length issue, which also sets content type to "text/plain" and character encoding to "UTF-8" for non-binary properties. I am not 100% certain that it is correct to set all of these in the ResourceMetadata, as the issue I observed was with the StreamRendererServlet. So I would be grateful if you could carefully review the patch before applying. > JcrPropertyResource sets incorrect content length for strings containing > non-ascii character > > > Key: SLING-1761 > URL: https://issues.apache.org/jira/browse/SLING-1761 > Project: Sling > Issue Type: Bug > Components: JCR >Affects Versions: JCR Resource 2.0.6 >Reporter: Julian Sedding > Attachments: SLING-1761-tests.patch, SLING-1761.patch > > > JcrPropertyResource sets the content length of the property in its metadata. > To do so, it uses javax.jcr.Property#getLength() to determine the content > length. > The documentation for javax.jcr.Property#getLength() states "[...] Returns > the length in bytes if the value is a PropertyType.BINARY, otherwise it > returns the number of characters needed to display the value in its string > form. [...]". > The documentation in ResourceMetadata is not explicit, but from its usage in > StreamRendererServlet I conclude that ResourceMetadata.getContentLength() is > intended for use in the Content-Length HTTP header. If my assumptions are > correct, the content length indicates the number of bytes in the string, > while javax.jcr.Property#getLength() returns the number of characters. > The effect of this can be observed by the following steps: > * create a string property "/utf8string" with value "Bär" > * access this property using a browser (e.g. > http://localhost:/utf8string), so that the property gets rendered by the > StreamRendererServlet > => the string is rendered incorrectly (due to a missing Content-Type header) > => the string is cut off (due to the incorrectly set Content-Length header) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1761) JcrPropertyResource sets incorrect content length for strings containing non-ascii character
[ https://issues.apache.org/jira/browse/SLING-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding updated SLING-1761: -- Attachment: (was: SLING-1761-tests.patch) > JcrPropertyResource sets incorrect content length for strings containing > non-ascii character > > > Key: SLING-1761 > URL: https://issues.apache.org/jira/browse/SLING-1761 > Project: Sling > Issue Type: Bug > Components: JCR >Affects Versions: JCR Resource 2.0.6 >Reporter: Julian Sedding > Attachments: SLING-1761-tests.patch, SLING-1761.patch > > > JcrPropertyResource sets the content length of the property in its metadata. > To do so, it uses javax.jcr.Property#getLength() to determine the content > length. > The documentation for javax.jcr.Property#getLength() states "[...] Returns > the length in bytes if the value is a PropertyType.BINARY, otherwise it > returns the number of characters needed to display the value in its string > form. [...]". > The documentation in ResourceMetadata is not explicit, but from its usage in > StreamRendererServlet I conclude that ResourceMetadata.getContentLength() is > intended for use in the Content-Length HTTP header. If my assumptions are > correct, the content length indicates the number of bytes in the string, > while javax.jcr.Property#getLength() returns the number of characters. > The effect of this can be observed by the following steps: > * create a string property "/utf8string" with value "Bär" > * access this property using a browser (e.g. > http://localhost:/utf8string), so that the property gets rendered by the > StreamRendererServlet > => the string is rendered incorrectly (due to a missing Content-Type header) > => the string is cut off (due to the incorrectly set Content-Length header) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1761) JcrPropertyResource sets incorrect content length for strings containing non-ascii character
[ https://issues.apache.org/jira/browse/SLING-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding updated SLING-1761: -- Attachment: SLING-1761-tests.patch Irony has it that the encoding of the attached tests was incorrect. Trying again ... > JcrPropertyResource sets incorrect content length for strings containing > non-ascii character > > > Key: SLING-1761 > URL: https://issues.apache.org/jira/browse/SLING-1761 > Project: Sling > Issue Type: Bug > Components: JCR >Affects Versions: JCR Resource 2.0.6 >Reporter: Julian Sedding > Attachments: SLING-1761-tests.patch, SLING-1761.patch > > > JcrPropertyResource sets the content length of the property in its metadata. > To do so, it uses javax.jcr.Property#getLength() to determine the content > length. > The documentation for javax.jcr.Property#getLength() states "[...] Returns > the length in bytes if the value is a PropertyType.BINARY, otherwise it > returns the number of characters needed to display the value in its string > form. [...]". > The documentation in ResourceMetadata is not explicit, but from its usage in > StreamRendererServlet I conclude that ResourceMetadata.getContentLength() is > intended for use in the Content-Length HTTP header. If my assumptions are > correct, the content length indicates the number of bytes in the string, > while javax.jcr.Property#getLength() returns the number of characters. > The effect of this can be observed by the following steps: > * create a string property "/utf8string" with value "Bär" > * access this property using a browser (e.g. > http://localhost:/utf8string), so that the property gets rendered by the > StreamRendererServlet > => the string is rendered incorrectly (due to a missing Content-Type header) > => the string is cut off (due to the incorrectly set Content-Length header) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1767) Update JCR Resource Import-Package to require o.a.s.c.osgi version 2.0.6
Update JCR Resource Import-Package to require o.a.s.c.osgi version 2.0.6 Key: SLING-1767 URL: https://issues.apache.org/jira/browse/SLING-1767 Project: Sling Issue Type: Bug Components: JCR Reporter: Julian Sedding Fix For: JCR Resource 2.0.8 For JCR Resource 2.0.8 the Import-Package statement in pom.xml needs to be updated to require o.a.s.c.osgi version 2.0.6. RootResourceProviderEntry makes use of OsgiUtil#getComparableForServiceRanking(), which only exists since 2.0.6 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding updated SLING-1778: -- Attachment: symlinks.patch > Symlinks > > > Key: SLING-1778 > URL: https://issues.apache.org/jira/browse/SLING-1778 > Project: Sling > Issue Type: New Feature >Reporter: Julian Sedding > Attachments: symlinks.patch > > > I have implemented a ResourceProvider, which allows to create symlink nodes > in the JCR repository. A symlink node has a sling:symlinkTarget property, > which should contain a valid JCR path. JCR content from the > sling:symlinkTarget path is then exposed below the symlink node. > There is a mixin node type, sling:Symlink with a mandatory property > sling:symlinkTarget and an optional property sling:overlayable. Additionally, > there is a convenience node type, sling:SymlinkResource, which extends from > sling:symlinkTarget and nt:unstructured. > ResourceProvider instances are registered for existing symlinks when the > bundle is started. Modifications are taken care of via JCR observation. > To get started: > * apply the attached patch to a trunk checkout > * build and install the bundle > * create a symlink node, pointing to some existing content > * access the symlink node e.g. via a browser -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1778) Symlinks
Symlinks Key: SLING-1778 URL: https://issues.apache.org/jira/browse/SLING-1778 Project: Sling Issue Type: New Feature Reporter: Julian Sedding Attachments: symlinks.patch I have implemented a ResourceProvider, which allows to create symlink nodes in the JCR repository. A symlink node has a sling:symlinkTarget property, which should contain a valid JCR path. JCR content from the sling:symlinkTarget path is then exposed below the symlink node. There is a mixin node type, sling:Symlink with a mandatory property sling:symlinkTarget and an optional property sling:overlayable. Additionally, there is a convenience node type, sling:SymlinkResource, which extends from sling:symlinkTarget and nt:unstructured. ResourceProvider instances are registered for existing symlinks when the bundle is started. Modifications are taken care of via JCR observation. To get started: * apply the attached patch to a trunk checkout * build and install the bundle * create a symlink node, pointing to some existing content * access the symlink node e.g. via a browser -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910117#action_12910117 ] Julian Sedding commented on SLING-1778: --- @Carsten I didn't look into the ResourceDecorator mechanism, so I don't know if the same use-case could be implemented that way. But if you have input I'm certainly very interested. @Bertrand The example you gave is precisely what I had in mind and what the patch achieves. Additionally, extending your example, assume /a/foo/4 has property text="four" Then if /a/foo has property sling:overlayable=true (in addition to sling:symlinkTarget = /b/bar) /a/foo/text is "one" /a/foo/4/text is "four" /a/foo/4/2/text is "three" > Symlinks > > > Key: SLING-1778 > URL: https://issues.apache.org/jira/browse/SLING-1778 > Project: Sling > Issue Type: New Feature > Components: JCR >Reporter: Julian Sedding > Attachments: symlinks.patch > > > I have implemented a ResourceProvider, which allows to create symlink nodes > in the JCR repository. A symlink node has a sling:symlinkTarget property, > which should contain a valid JCR path. JCR content from the > sling:symlinkTarget path is then exposed below the symlink node. > There is a mixin node type, sling:Symlink with a mandatory property > sling:symlinkTarget and an optional property sling:overlayable. Additionally, > there is a convenience node type, sling:SymlinkResource, which extends from > sling:symlinkTarget and nt:unstructured. > ResourceProvider instances are registered for existing symlinks when the > bundle is started. Modifications are taken care of via JCR observation. > To get started: > * apply the attached patch to a trunk checkout > * build and install the bundle > * create a symlink node, pointing to some existing content > * access the symlink node e.g. via a browser -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910179#action_12910179 ] Julian Sedding commented on SLING-1778: --- Thanks for the feedback so far! @Bertrand > Seems like this could be very confusing...if you really need it, I'd suggest > making it configurable and turned off by default. It is configurable via the sling:overlayable boolean property and the default, i.e. if the property is missing, is off. @Felix > * As for the symlink query: I would look for sling:symlinkTarget properties agreed > * sling:overlayable: I understand the concept, but: can we come up with a > nicer name ? ;-) Please feel free to suggest something more intuitive ;) > * The ResourceResolver field of the SymlinkManager should be private. Access > to the field for the SymlinkResourceProvider > should be possible using a getter method Yes, that should be private. I think it is not used by SymlinkResourceProvider at all. > * SymlinkResourceProvider.listChildren should probably support non-Symlink > resources, particularly if the symlink overlay is > enabled Yes, I was thinking about this. I don't think it's trivial, as the ResourceResolver might go into a recursion. That's the reason I'm using the JCR API in places. An option might be to directly query other ResourceProviders. > * As a convenience it would be usefull to add the rootPath to the > service.description property of the provider service registration Purely for information? Yes, makes sense. A web console plugin might also be useful. I was also playing with the thought of exposing SymlinkManager as a service and provide an API to e.g. list registered symlinks. > * Not sure here: Would it make sense to have the sling:SymlinkResource type > also extend sling:Resource ? Not sure either, probably won't hurt. What's the use of slingResource btw? > * How is the symlink resource accessible ? I used CRXDE lite for testing, which works via the Jackrabbit davx servlet. Therefore I don't know. Is the POST servlet purely JCR based? If that's the case, at least modifications would be possible. It seems, however, that a solution is needed to also view the symlink definition. Ideas welcome :) > ... one more thing: for us to be able to use this contribution you should > upload it with the "Grant license to ASF for inclusion in ASF works" button > checked. Thanks. That's a mistake, I meant to check this of course. @Justin I agree that shareable nodes could be an alternative way to explore this. However, the use-case I need to cover is creating a language tree in a WCM scenario, which can be gradually overlayed with translated pages. So the "with exception of overlayable" would have hurt. > Symlinks > > > Key: SLING-1778 > URL: https://issues.apache.org/jira/browse/SLING-1778 > Project: Sling > Issue Type: New Feature > Components: JCR >Reporter: Julian Sedding > Attachments: symlinks.patch > > > I have implemented a ResourceProvider, which allows to create symlink nodes > in the JCR repository. A symlink node has a sling:symlinkTarget property, > which should contain a valid JCR path. JCR content from the > sling:symlinkTarget path is then exposed below the symlink node. > There is a mixin node type, sling:Symlink with a mandatory property > sling:symlinkTarget and an optional property sling:overlayable. Additionally, > there is a convenience node type, sling:SymlinkResource, which extends from > sling:symlinkTarget and nt:unstructured. > ResourceProvider instances are registered for existing symlinks when the > bundle is started. Modifications are taken care of via JCR observation. > To get started: > * apply the attached patch to a trunk checkout > * build and install the bundle > * create a symlink node, pointing to some existing content > * access the symlink node e.g. via a browser -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding updated SLING-1778: -- Attachment: (was: symlinks.patch) > Symlinks > > > Key: SLING-1778 > URL: https://issues.apache.org/jira/browse/SLING-1778 > Project: Sling > Issue Type: New Feature > Components: JCR >Reporter: Julian Sedding > Attachments: symlinks.patch > > > I have implemented a ResourceProvider, which allows to create symlink nodes > in the JCR repository. A symlink node has a sling:symlinkTarget property, > which should contain a valid JCR path. JCR content from the > sling:symlinkTarget path is then exposed below the symlink node. > There is a mixin node type, sling:Symlink with a mandatory property > sling:symlinkTarget and an optional property sling:overlayable. Additionally, > there is a convenience node type, sling:SymlinkResource, which extends from > sling:symlinkTarget and nt:unstructured. > ResourceProvider instances are registered for existing symlinks when the > bundle is started. Modifications are taken care of via JCR observation. > To get started: > * apply the attached patch to a trunk checkout > * build and install the bundle > * create a symlink node, pointing to some existing content > * access the symlink node e.g. via a browser -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding updated SLING-1778: -- Attachment: symlinks.patch Re-attached and granted license to ASF. > Symlinks > > > Key: SLING-1778 > URL: https://issues.apache.org/jira/browse/SLING-1778 > Project: Sling > Issue Type: New Feature > Components: JCR >Reporter: Julian Sedding > Attachments: symlinks.patch > > > I have implemented a ResourceProvider, which allows to create symlink nodes > in the JCR repository. A symlink node has a sling:symlinkTarget property, > which should contain a valid JCR path. JCR content from the > sling:symlinkTarget path is then exposed below the symlink node. > There is a mixin node type, sling:Symlink with a mandatory property > sling:symlinkTarget and an optional property sling:overlayable. Additionally, > there is a convenience node type, sling:SymlinkResource, which extends from > sling:symlinkTarget and nt:unstructured. > ResourceProvider instances are registered for existing symlinks when the > bundle is started. Modifications are taken care of via JCR observation. > To get started: > * apply the attached patch to a trunk checkout > * build and install the bundle > * create a symlink node, pointing to some existing content > * access the symlink node e.g. via a browser -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910194#action_12910194 ] Julian Sedding commented on SLING-1778: --- > Just thinking out loud here, but how about *only* supporting overlays. I can > see how > overlays and symlinks are related, but they actually seems like different use > cases. Ok, that could be easily done. What about the following: if we think of the tree we want to overlay as the "shadow"-tree (again, I'm open for better names), we could define a property "sling:shadow" (or sling:shadowPath, sling:shadowRoot?). "sling:shadow" would contain a string value, the root path of the "shadow"-tree. You suggest *only* supporting overlays. Would you drop the symlink use-case entirely, implement it using shareable nodes or support it via a sling:symlink (aka sling:symlinkTarget, playing the names-game again) property? Supporting the last use-case would be trivial, however, it might be confusing. > Symlinks > > > Key: SLING-1778 > URL: https://issues.apache.org/jira/browse/SLING-1778 > Project: Sling > Issue Type: New Feature > Components: JCR >Reporter: Julian Sedding > Attachments: symlinks.patch > > > I have implemented a ResourceProvider, which allows to create symlink nodes > in the JCR repository. A symlink node has a sling:symlinkTarget property, > which should contain a valid JCR path. JCR content from the > sling:symlinkTarget path is then exposed below the symlink node. > There is a mixin node type, sling:Symlink with a mandatory property > sling:symlinkTarget and an optional property sling:overlayable. Additionally, > there is a convenience node type, sling:SymlinkResource, which extends from > sling:symlinkTarget and nt:unstructured. > ResourceProvider instances are registered for existing symlinks when the > bundle is started. Modifications are taken care of via JCR observation. > To get started: > * apply the attached patch to a trunk checkout > * build and install the bundle > * create a symlink node, pointing to some existing content > * access the symlink node e.g. via a browser -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910564#action_12910564 ] Julian Sedding commented on SLING-1778: --- @Justin > Any reason you couldn't have this be a multivalued property? I cannot imagine how that would work. Could you elaborate? Ok, thank you very much for the plentiful feedback! I'll take this through another iteration to incorporate your feedback. I'll drop the symlink idea in favor of the overlay mechanism. This should simplify the code a little and does make sense for me, since I don't have the symlink use-case at the moment. Unfortunately I don't have much time on my hands to work on this during my day job, so it may take a little while. > Symlinks > > > Key: SLING-1778 > URL: https://issues.apache.org/jira/browse/SLING-1778 > Project: Sling > Issue Type: New Feature > Components: JCR >Reporter: Julian Sedding > Attachments: symlinks.patch > > > I have implemented a ResourceProvider, which allows to create symlink nodes > in the JCR repository. A symlink node has a sling:symlinkTarget property, > which should contain a valid JCR path. JCR content from the > sling:symlinkTarget path is then exposed below the symlink node. > There is a mixin node type, sling:Symlink with a mandatory property > sling:symlinkTarget and an optional property sling:overlayable. Additionally, > there is a convenience node type, sling:SymlinkResource, which extends from > sling:symlinkTarget and nt:unstructured. > ResourceProvider instances are registered for existing symlinks when the > bundle is started. Modifications are taken care of via JCR observation. > To get started: > * apply the attached patch to a trunk checkout > * build and install the bundle > * create a symlink node, pointing to some existing content > * access the symlink node e.g. via a browser -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1859) Multi-value string properties are not displayed correctly
[ https://issues.apache.org/jira/browse/SLING-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12931658#action_12931658 ] Julian Sedding commented on SLING-1859: --- I don't know if this is a bug or not, but maybe you can work around your issue like this (I'm writing java, but it should be possible to convert to esp): ValueMap properties = ResourceUtil,getValueMap(resource); // guards against NPE in this and in the next line String[] property = properties.get(id, new String[0]); // not sure you want strings, I guess you could also ask for Long[0] etc. > Multi-value string properties are not displayed correctly > - > > Key: SLING-1859 > URL: https://issues.apache.org/jira/browse/SLING-1859 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: Sling Explorer 1.0.0 >Reporter: Carsten Ziegeler >Assignee: Mike Müller > > I have a node with a multi value string property, and the explorer displays > the value as "[Ljava.lang.Object;@1a6b7e", together with the hint "[not a > property!] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1761) JcrPropertyResource sets incorrect content length for strings containing non-ascii character
[ https://issues.apache.org/jira/browse/SLING-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976535#action_12976535 ] Julian Sedding commented on SLING-1761: --- Thanks for checking and applying the path, Carsten. I've double-checked the changes you applied and confirm that my patch wasn't actually setting the content length, yours does. > JcrPropertyResource sets incorrect content length for strings containing > non-ascii character > > > Key: SLING-1761 > URL: https://issues.apache.org/jira/browse/SLING-1761 > Project: Sling > Issue Type: Bug > Components: JCR >Affects Versions: JCR Resource 2.0.6 >Reporter: Julian Sedding >Assignee: Carsten Ziegeler > Fix For: JCR Resource 2.0.8 > > Attachments: SLING-1761-tests.patch, SLING-1761.patch > > > JcrPropertyResource sets the content length of the property in its metadata. > To do so, it uses javax.jcr.Property#getLength() to determine the content > length. > The documentation for javax.jcr.Property#getLength() states "[...] Returns > the length in bytes if the value is a PropertyType.BINARY, otherwise it > returns the number of characters needed to display the value in its string > form. [...]". > The documentation in ResourceMetadata is not explicit, but from its usage in > StreamRendererServlet I conclude that ResourceMetadata.getContentLength() is > intended for use in the Content-Length HTTP header. If my assumptions are > correct, the content length indicates the number of bytes in the string, > while javax.jcr.Property#getLength() returns the number of characters. > The effect of this can be observed by the following steps: > * create a string property "/utf8string" with value "Bär" > * access this property using a browser (e.g. > http://localhost:/utf8string), so that the property gets rendered by the > StreamRendererServlet > => the string is rendered incorrectly (due to a missing Content-Type header) > => the string is cut off (due to the incorrectly set Content-Length header) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1939) wrong character encoding for compiled JSP scripts
[ https://issues.apache.org/jira/browse/SLING-1939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12995403#comment-12995403 ] Julian Sedding commented on SLING-1939: --- As a workaround you can include <%@page pageEncoding="utf-8" %> in every JSP file containing static strings with accented characters. > wrong character encoding for compiled JSP scripts > - > > Key: SLING-1939 > URL: https://issues.apache.org/jira/browse/SLING-1939 > Project: Sling > Issue Type: Bug > Components: Scripting >Affects Versions: Scripting JSP 2.0.12 >Reporter: Victor Saar >Priority: Minor > > I have a JSP that contains some static text with special chars (e.g. > umlauts). Though the JSP itself seems to be correctly encoded as UTF-8, the > compiled .java class under /var/classes/... shows these characters wrongly > encoded. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-1793) JSP Java Standard Tag Library support
[ https://issues.apache.org/jira/browse/SLING-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13039679#comment-13039679 ] Julian Sedding commented on SLING-1793: --- It seems like Tomcat Taglibs are now provided as OSGi bundles. See https://issues.apache.org/bugzilla/show_bug.cgi?id=50064 > JSP Java Standard Tag Library support > - > > Key: SLING-1793 > URL: https://issues.apache.org/jira/browse/SLING-1793 > Project: Sling > Issue Type: New Feature > Components: Scripting >Reporter: Róbert Csákány > Attachments: jsp-taglib-jstl.zip > > > Support JSTL in JSP scripts. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-1476) provide number of processed requests
[ https://issues.apache.org/jira/browse/SLING-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13052612#comment-13052612 ] Julian Sedding commented on SLING-1476: --- I agree with Bertrand rgd. having a simpler example and not necessarily a filter. If the counter makes it into SVN, IMHO the counter variable needs to be at least volatile (with the possibility of lost updates), better an AtomicInteger/AtomicLong. > provide number of processed requests > > > Key: SLING-1476 > URL: https://issues.apache.org/jira/browse/SLING-1476 > Project: Sling > Issue Type: New Feature > Components: Engine >Affects Versions: Engine 2.0.6 >Reporter: Jörg Hoh >Priority: Minor > Attachments: org.apache.sling.jmx.zip > > > For status monitoring it would be useful to have the number of total > processed requests since restart of the JVM. Is it possible to have a > "statistics" component which could provide such numbers? > (The "manual" way to do it would be writing a very simple RequestFilter which > just increments a counter and expose this object as OSGI component.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SLING-2218) JSP tag files are not invalidated on modification
JSP tag files are not invalidated on modification - Key: SLING-2218 URL: https://issues.apache.org/jira/browse/SLING-2218 Project: Sling Issue Type: Bug Components: Scripting Affects Versions: Scripting JSP 2.0.18 Reporter: Julian Sedding When .tag files are modified in the repository, they are not invalidated and thus not recompiled during the next request. This is due to the fact that their path, internal to the underlying jasper implementation is prefixed with "/WEB-INF/tags", while their repository path isn't. The modification event of the script only contains the repository path and thus doesn't match the internal, prefixed, representation. Thus the .tag file and any dependants are not invalidated. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-2218) JSP tag files are not invalidated on modification
[ https://issues.apache.org/jira/browse/SLING-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding updated SLING-2218: -- Description: When .tag files (as introduced in SLING-2138) are modified in the repository, they are not invalidated and thus not recompiled during the next request. This is due to the fact that their path, internal to the underlying jasper implementation is prefixed with "/WEB-INF/tags", while their repository path isn't. The modification event of the script only contains the repository path and thus doesn't match the internal, prefixed, representation. Thus the .tag file and any dependants are not invalidated. was: When .tag files are modified in the repository, they are not invalidated and thus not recompiled during the next request. This is due to the fact that their path, internal to the underlying jasper implementation is prefixed with "/WEB-INF/tags", while their repository path isn't. The modification event of the script only contains the repository path and thus doesn't match the internal, prefixed, representation. Thus the .tag file and any dependants are not invalidated. > JSP tag files are not invalidated on modification > - > > Key: SLING-2218 > URL: https://issues.apache.org/jira/browse/SLING-2218 > Project: Sling > Issue Type: Bug > Components: Scripting >Affects Versions: Scripting JSP 2.0.18 >Reporter: Julian Sedding > > When .tag files (as introduced in SLING-2138) are modified in the repository, > they are not invalidated and thus not recompiled during the next request. > This is due to the fact that their path, internal to the underlying jasper > implementation is prefixed with "/WEB-INF/tags", while their repository path > isn't. The modification event of the script only contains the repository path > and thus doesn't match the internal, prefixed, representation. Thus the .tag > file and any dependants are not invalidated. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-2218) JSP tag files are not invalidated on modification
[ https://issues.apache.org/jira/browse/SLING-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding updated SLING-2218: -- Attachment: SLING-2218.patch proposed patch > JSP tag files are not invalidated on modification > - > > Key: SLING-2218 > URL: https://issues.apache.org/jira/browse/SLING-2218 > Project: Sling > Issue Type: Bug > Components: Scripting >Affects Versions: Scripting JSP 2.0.18 >Reporter: Julian Sedding > Attachments: SLING-2218.patch > > > When .tag files (as introduced in SLING-2138) are modified in the repository, > they are not invalidated and thus not recompiled during the next request. > This is due to the fact that their path, internal to the underlying jasper > implementation is prefixed with "/WEB-INF/tags", while their repository path > isn't. The modification event of the script only contains the repository path > and thus doesn't match the internal, prefixed, representation. Thus the .tag > file and any dependants are not invalidated. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2533) ResourceCollector fails to resolve selector scripts when no extension is used
[ https://issues.apache.org/jira/browse/SLING-2533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13415399#comment-13415399 ] Julian Sedding commented on SLING-2533: --- IMHO the described issue is actually consistent behaviour. The SlingServletResolver has the concept of default extensions (html by default), which allow the extension name to be omitted in the script name. That's why your example works with the "html" extension, but not with a "txt" extension. I.e. selector.html.jsp is equivalent to selector.jsp, but selector.txt.jsp is not. Consider the above example to be the "empty extension". The "empty extension" is not in the set of default extensions and therefore is treated like the "txt" extension. I.e. selector..jsp is not equivalent to selector.jsp. Since writing the empty extension is a bit difficult the method name becomes necessary, which leads to say that selector.GET.jsp is only equivalent to selector.jsp if a default extension is used, but not in the case of the "empty extension". FWIW, you can work around this issue quite easily by specifying a default extension in your sling:include. E.g. should do the trick. Beware of unforeseen consequences further down the inlcude stack. Sling was designed for use *with* extensions, therefore your mileage *without* may vary. (I'm actually surprised that it works so well.) > ResourceCollector fails to resolve selector scripts when no extension is used > - > > Key: SLING-2533 > URL: https://issues.apache.org/jira/browse/SLING-2533 > Project: Sling > Issue Type: Bug > Components: Servlets >Affects Versions: Servlets Resolver 2.1.2 > Environment: this applies to version 2.1.3-SNAPSHOT >Reporter: Tyson Norris > Attachments: sling-2533.patch > > > A specific use case where this comes up is: > request: http://localhost:4502/content/test/include > In JCR repo: > - node at content/test/include has sling:resourceType=test/main > - script to render this resource is /apps/test/main/GET.jsp > - script to render different type with selector referneced via: > > - script to render the different type is /apps/test/sometype/special.jsp > in this case, special.jsp script is only resoved if renamed to special.GET.jsp > Note that: > - no extension on requested URL > - using a replaced selector in sling:include should behave similar to > specifying an exentsion when the extension is null, I think. > See attached patch to ResourceCollector and ScriptSelectionTest -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2641) Make listChildren() Iterable
[ https://issues.apache.org/jira/browse/SLING-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491392#comment-13491392 ] Julian Sedding commented on SLING-2641: --- The patch looks good, except some minor nitpicks: * the patch includes changes to the QueriableResourceProvider interface * javadoc for Resource#getChildren states "Returns an iterator ...", it should be "Returns an iterable ..." * javadoc for ResourceResolver#getChildren states "Returns an Iterator ...", it should be "Returns an Iterable ..." > Make listChildren() Iterable > > > Key: SLING-2641 > URL: https://issues.apache.org/jira/browse/SLING-2641 > Project: Sling > Issue Type: Improvement > Components: API, General, ResourceResolver, Testing >Affects Versions: API 2.2.4 >Reporter: Dan Klco >Assignee: Carsten Ziegeler > Labels: features, noob, patch > Attachments: iterable-patch.txt, SLING-2641-Resource-Iterator.diff > > > When you call Resource.listChildren() or resourceResolver.listChildren() it > returns a Iterator, this is fine if you want to just iterate > through the results using old-style while loops, but if you want to use > enhanced loops, you are out of luck. > I'm proposing adding an interface to return from these methods which extends > both Iterator and Iterable. This will allow for using > enhanced loops with the results of listChildren(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-2708) ResourceUtil.isA() fails for adapted Resources unless user is admin
[
https://issues.apache.org/jira/browse/SLING-2708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated SLING-2708:
--
Attachment: SLING-2708-using-adaptTo.patch
I have implemented a possible solution based on the adapter functionality, see
attached patch. In a nutshell, the resource can be adapted to an immutable
EffectiveResourceType object, which internally holds a list of all
resource-types in the inheritance chain of the resource.
As Carsten suggested, this functionality is used in AbstractResource via
adaptTo(EffectiveResourceType.class).
This moves the implementation to a dedicated service, like Alex said, namely
the AdapterFactory.
Furthermore, I decided that resource-types are mostly related to script
resolution and it would probably be sensible to (re)use the script-user
configured for the SlingServletResolver. I believe that having a consistent
view on the resource-types and scripts is beneficial. Also, the
ResourceDecorator approach seems to follow the same rationale. In order not to
overload the SlingServletResolver, this functionality mostly resides in the
EffectiveResourceTypeFactory, which is created by the SlingServletResolver.
I'm not sure if the addition of the EffectiveResourceType interface to
o.a.sling.api is desirable, however, adding it to another package would create
a dependency. Maybe the EffectiveResourceType could also be made more useful.
At the moment it is very simple and only solves the "isA" use-case.
> ResourceUtil.isA() fails for adapted Resources unless user is admin
> ---
>
> Key: SLING-2708
> URL: https://issues.apache.org/jira/browse/SLING-2708
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Reporter: Tyson Norris
> Attachments: SLING-2708-using-adaptTo.patch
>
>
> Summary - adapting a Resource to a specified type, loses the ability to test
> the Resources super types using ResourceUtil.isA(), UNLESS user is admin
> 1. TypeA is defined as:
> class TypeA {
> private Resource res;
> public boolean isTypeB(){
> return ResourceUtil.isA(res, "some/type");
> }
> }
> 2. TypeA adapter is an AdapterFactory to adapt Resource -> TypeA
> 3. /some/res/path is a resource whose sling:resourceSuperType 2 levels up is
> "/apps/some/type"
> 4. In a JSP, we use code like:
> TypeA typeA = resource.adaptTo(TypeA)
> if (!typeA.isTypeB()){
> //FAIL: typeA.isTypeB() is actually true
> }
> Note that:
> ResourceUtil.isA(resource, "some/type") == true
> but
> ResourceUtil.isA(typeA.resource, "some/type") == false
> (unless user is admin)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-2708) ResourceUtil.isA() fails for adapted Resources unless user is admin
[
https://issues.apache.org/jira/browse/SLING-2708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated SLING-2708:
--
Attachment: (was: SLING-2708-using-adaptTo.patch)
> ResourceUtil.isA() fails for adapted Resources unless user is admin
> ---
>
> Key: SLING-2708
> URL: https://issues.apache.org/jira/browse/SLING-2708
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Reporter: Tyson Norris
>
> Summary - adapting a Resource to a specified type, loses the ability to test
> the Resources super types using ResourceUtil.isA(), UNLESS user is admin
> 1. TypeA is defined as:
> class TypeA {
> private Resource res;
> public boolean isTypeB(){
> return ResourceUtil.isA(res, "some/type");
> }
> }
> 2. TypeA adapter is an AdapterFactory to adapt Resource -> TypeA
> 3. /some/res/path is a resource whose sling:resourceSuperType 2 levels up is
> "/apps/some/type"
> 4. In a JSP, we use code like:
> TypeA typeA = resource.adaptTo(TypeA)
> if (!typeA.isTypeB()){
> //FAIL: typeA.isTypeB() is actually true
> }
> Note that:
> ResourceUtil.isA(resource, "some/type") == true
> but
> ResourceUtil.isA(typeA.resource, "some/type") == false
> (unless user is admin)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-2708) ResourceUtil.isA() fails for adapted Resources unless user is admin
[
https://issues.apache.org/jira/browse/SLING-2708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated SLING-2708:
--
Attachment: SLING-2708-using-adaptTo.patch
I just realized there was a bug in my previous patch. A new version of the
patch is attached, which should fix the issue.
> ResourceUtil.isA() fails for adapted Resources unless user is admin
> ---
>
> Key: SLING-2708
> URL: https://issues.apache.org/jira/browse/SLING-2708
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Reporter: Tyson Norris
> Attachments: SLING-2708-using-adaptTo.patch
>
>
> Summary - adapting a Resource to a specified type, loses the ability to test
> the Resources super types using ResourceUtil.isA(), UNLESS user is admin
> 1. TypeA is defined as:
> class TypeA {
> private Resource res;
> public boolean isTypeB(){
> return ResourceUtil.isA(res, "some/type");
> }
> }
> 2. TypeA adapter is an AdapterFactory to adapt Resource -> TypeA
> 3. /some/res/path is a resource whose sling:resourceSuperType 2 levels up is
> "/apps/some/type"
> 4. In a JSP, we use code like:
> TypeA typeA = resource.adaptTo(TypeA)
> if (!typeA.isTypeB()){
> //FAIL: typeA.isTypeB() is actually true
> }
> Note that:
> ResourceUtil.isA(resource, "some/type") == true
> but
> ResourceUtil.isA(typeA.resource, "some/type") == false
> (unless user is admin)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-2708) ResourceUtil.isA() fails for adapted Resources unless user is admin
[
https://issues.apache.org/jira/browse/SLING-2708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated SLING-2708:
--
Attachment: (was: SLING-2708-using-adaptTo.patch)
> ResourceUtil.isA() fails for adapted Resources unless user is admin
> ---
>
> Key: SLING-2708
> URL: https://issues.apache.org/jira/browse/SLING-2708
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Reporter: Tyson Norris
>
> Summary - adapting a Resource to a specified type, loses the ability to test
> the Resources super types using ResourceUtil.isA(), UNLESS user is admin
> 1. TypeA is defined as:
> class TypeA {
> private Resource res;
> public boolean isTypeB(){
> return ResourceUtil.isA(res, "some/type");
> }
> }
> 2. TypeA adapter is an AdapterFactory to adapt Resource -> TypeA
> 3. /some/res/path is a resource whose sling:resourceSuperType 2 levels up is
> "/apps/some/type"
> 4. In a JSP, we use code like:
> TypeA typeA = resource.adaptTo(TypeA)
> if (!typeA.isTypeB()){
> //FAIL: typeA.isTypeB() is actually true
> }
> Note that:
> ResourceUtil.isA(resource, "some/type") == true
> but
> ResourceUtil.isA(typeA.resource, "some/type") == false
> (unless user is admin)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Deleted] (SLING-2708) ResourceUtil.isA() fails for adapted Resources unless user is admin
[
https://issues.apache.org/jira/browse/SLING-2708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated SLING-2708:
--
Comment: was deleted
(was: I just realized there was a bug in my previous patch. A new version of
the patch is attached, which should fix the issue.)
> ResourceUtil.isA() fails for adapted Resources unless user is admin
> ---
>
> Key: SLING-2708
> URL: https://issues.apache.org/jira/browse/SLING-2708
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Reporter: Tyson Norris
>
> Summary - adapting a Resource to a specified type, loses the ability to test
> the Resources super types using ResourceUtil.isA(), UNLESS user is admin
> 1. TypeA is defined as:
> class TypeA {
> private Resource res;
> public boolean isTypeB(){
> return ResourceUtil.isA(res, "some/type");
> }
> }
> 2. TypeA adapter is an AdapterFactory to adapt Resource -> TypeA
> 3. /some/res/path is a resource whose sling:resourceSuperType 2 levels up is
> "/apps/some/type"
> 4. In a JSP, we use code like:
> TypeA typeA = resource.adaptTo(TypeA)
> if (!typeA.isTypeB()){
> //FAIL: typeA.isTypeB() is actually true
> }
> Note that:
> ResourceUtil.isA(resource, "some/type") == true
> but
> ResourceUtil.isA(typeA.resource, "some/type") == false
> (unless user is admin)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-2708) ResourceUtil.isA() fails for adapted Resources unless user is admin
[
https://issues.apache.org/jira/browse/SLING-2708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated SLING-2708:
--
Attachment: SLING-2708-using-adaptTo.patch
I just realized there was a bug in my previous patch. A new version of the
patch is attached, which should fix the issue.
> ResourceUtil.isA() fails for adapted Resources unless user is admin
> ---
>
> Key: SLING-2708
> URL: https://issues.apache.org/jira/browse/SLING-2708
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Reporter: Tyson Norris
> Attachments: SLING-2708-using-adaptTo.patch
>
>
> Summary - adapting a Resource to a specified type, loses the ability to test
> the Resources super types using ResourceUtil.isA(), UNLESS user is admin
> 1. TypeA is defined as:
> class TypeA {
> private Resource res;
> public boolean isTypeB(){
> return ResourceUtil.isA(res, "some/type");
> }
> }
> 2. TypeA adapter is an AdapterFactory to adapt Resource -> TypeA
> 3. /some/res/path is a resource whose sling:resourceSuperType 2 levels up is
> "/apps/some/type"
> 4. In a JSP, we use code like:
> TypeA typeA = resource.adaptTo(TypeA)
> if (!typeA.isTypeB()){
> //FAIL: typeA.isTypeB() is actually true
> }
> Note that:
> ResourceUtil.isA(resource, "some/type") == true
> but
> ResourceUtil.isA(typeA.resource, "some/type") == false
> (unless user is admin)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2698) Add a minimal resource access gate
[ https://issues.apache.org/jira/browse/SLING-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592242#comment-13592242 ] Julian Sedding commented on SLING-2698: --- I had a quick look at the implementation and there are three things that worry me: * The implementation is in the resourceresolver bundle and therefore not optional * Checking permissions using regular expressions seems troublesome to me for performance considerations. While rendering a moderately complex website, a lot of RR#getResource() calls are made, each of which would trigger a regexp evaluation. Would a String#startsWith() call be enough? This should definitely be backed by performance tests. * Implementing AccessGates using a ResourceDecorator seems pretty insecure, because the resource can easily be unwrapped (intentionally or by accident). We had this issue recently in the context of the Resource#isResourceType() checks (see SLING-2739). > Add a minimal resource access gate > -- > > Key: SLING-2698 > URL: https://issues.apache.org/jira/browse/SLING-2698 > Project: Sling > Issue Type: New Feature > Components: ResourceResolver >Reporter: Mike Müller >Assignee: Mike Müller > Fix For: Resource Resolver 1.1.0 > > > Adding a minmal resource access gate as discussed in [1]. > First step is to define the API interface and a minimal implementation which > allows to define READ access (rest of CRUD can follow later) > [1] http://markmail.org/thread/4ctczoiy533tquyl -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-2698) Add a minimal resource access gate
[
https://issues.apache.org/jira/browse/SLING-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated SLING-2698:
--
Attachment: resource-resolver-wrapper.patch
I like Carsten's idea of wrapping the ResourceResolver. This should allow to
fully control the resources provided by this resolver. I presume this could be
as simple as adding a ResourceResolverCustomizer interface, that can be
implemented by client-code. In
ResourceResolverFactoryImpl#getResourceResolverInternal() all
ResourceResolverCustomizers will get given a chance to customize the
ResourceResolver in service.ranking order (by decorating it, exchanging it all
together, or anything else that people could come up with).
The interface could look like this:
'''
/**
* Hook that can be implemented to intercept a ResourceResolver just after its
* creation in order to do any modifications on it, e.g. decorating it with
additional
* behavior.
*/
public interface ResourceResolverCustomizer {
/**
* This method allows modifying, decorating or exchanging a
resource-resolver
* immediately after its creation. It is guaranteed that the {@code
ResourceResolver}
* provided as an argument has not been used yet.
*/
public ResourceResolver customize(ResourceResolver resolver);
}
'''
Given such a hook, the ResourceAccessGate could implement this hook and live in
its own bundle, thus decoupling it from the resourceresolver bundle and its
release-cycle.
In addition, a decorator-based approach probably allows for relatively easy
mocking and unit-testing.
I implemented a generic ResourceResolverWrapper a while ago, which makes sure
all its Resources are also wrapped. The implementation lacks some new methods,
but might help to implement such an approach. I'll attach it in case it's
useful.
Regarding the regexps, my concerns stem from a recent negative experience
(different software, similar scenario). I agree that regexps may be useful and
should be allowed in implementations of ResourceAccessGate. I would try,
however, to avoid using regexps in the ResourceAccessGateHandler. This should
allow efficient preselection of relevant ResourceAccessGates and still allows
for arbitrary flexibility.
Regarding unwrapping the Resource intentionally, I agree that that's a
non-issue. A developer may just as well retrieve an administrative
ResourceResolver, if so inclined. With the current ResourceDecorator approach,
we might run into situations like SLING-2739, however, if we can decorate the
ResourceResolver, we should have better control.
> Add a minimal resource access gate
> --
>
> Key: SLING-2698
> URL: https://issues.apache.org/jira/browse/SLING-2698
> Project: Sling
> Issue Type: New Feature
> Components: ResourceResolver
>Reporter: Mike Müller
>Assignee: Mike Müller
> Fix For: Resource Resolver 1.1.0
>
> Attachments: resource-resolver-wrapper.patch
>
>
> Adding a minmal resource access gate as discussed in [1].
> First step is to define the API interface and a minimal implementation which
> allows to define READ access (rest of CRUD can follow later)
> [1] http://markmail.org/thread/4ctczoiy533tquyl
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (SLING-2698) Add a minimal resource access gate
[
https://issues.apache.org/jira/browse/SLING-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13593256#comment-13593256
]
Julian Sedding edited comment on SLING-2698 at 3/5/13 9:28 AM:
---
I like Carsten's idea of wrapping the ResourceResolver. This should allow to
fully control the resources provided by this resolver. I presume this could be
as simple as adding a ResourceResolverCustomizer interface, that can be
implemented by client-code. In
ResourceResolverFactoryImpl#getResourceResolverInternal() all
ResourceResolverCustomizers will get given a chance to customize the
ResourceResolver in service.ranking order (by decorating it, exchanging it all
together, or anything else that people could come up with).
The interface could look like this:
{code:java}
/**
* Hook that can be implemented to intercept a ResourceResolver just after its
* creation in order to do any modifications on it, e.g. decorating it with
additional
* behavior.
*/
public interface ResourceResolverCustomizer {
/**
* This method allows modifying, decorating or exchanging a
resource-resolver
* immediately after its creation. It is guaranteed that the {@code
ResourceResolver}
* provided as an argument has not been used yet.
*/
public ResourceResolver customize(ResourceResolver resolver);
}
{code}
Given such a hook, the ResourceAccessGate could implement this hook and live in
its own bundle, thus decoupling it from the resourceresolver bundle and its
release-cycle.
In addition, a decorator-based approach probably allows for relatively easy
mocking and unit-testing.
I implemented a generic ResourceResolverWrapper a while ago, which makes sure
all its Resources are also wrapped. The implementation lacks some new methods,
but might help to implement such an approach. I'll attach it in case it's
useful.
Regarding the regexps, my concerns stem from a recent negative experience
(different software, similar scenario). I agree that regexps may be useful and
should be allowed in implementations of ResourceAccessGate. I would try,
however, to avoid using regexps in the ResourceAccessGateHandler. This should
allow efficient preselection of relevant ResourceAccessGates and still allows
for arbitrary flexibility.
Regarding unwrapping the Resource intentionally, I agree that that's a
non-issue. A developer may just as well retrieve an administrative
ResourceResolver, if so inclined. With the current ResourceDecorator approach,
we might run into situations like SLING-2739, however, if we can decorate the
ResourceResolver, we should have better control.
was (Author: jsedding):
I like Carsten's idea of wrapping the ResourceResolver. This should allow
to fully control the resources provided by this resolver. I presume this could
be as simple as adding a ResourceResolverCustomizer interface, that can be
implemented by client-code. In
ResourceResolverFactoryImpl#getResourceResolverInternal() all
ResourceResolverCustomizers will get given a chance to customize the
ResourceResolver in service.ranking order (by decorating it, exchanging it all
together, or anything else that people could come up with).
The interface could look like this:
'''
/**
* Hook that can be implemented to intercept a ResourceResolver just after its
* creation in order to do any modifications on it, e.g. decorating it with
additional
* behavior.
*/
public interface ResourceResolverCustomizer {
/**
* This method allows modifying, decorating or exchanging a
resource-resolver
* immediately after its creation. It is guaranteed that the {@code
ResourceResolver}
* provided as an argument has not been used yet.
*/
public ResourceResolver customize(ResourceResolver resolver);
}
'''
Given such a hook, the ResourceAccessGate could implement this hook and live in
its own bundle, thus decoupling it from the resourceresolver bundle and its
release-cycle.
In addition, a decorator-based approach probably allows for relatively easy
mocking and unit-testing.
I implemented a generic ResourceResolverWrapper a while ago, which makes sure
all its Resources are also wrapped. The implementation lacks some new methods,
but might help to implement such an approach. I'll attach it in case it's
useful.
Regarding the regexps, my concerns stem from a recent negative experience
(different software, similar scenario). I agree that regexps may be useful and
should be allowed in implementations of ResourceAccessGate. I would try,
however, to avoid using regexps in the ResourceAccessGateHandler. This should
allow efficient preselection of relevant ResourceAccessGates and still allows
for arbitrary flexibility.
Regarding unwrapping the Resource intentionally, I agree that that's a
non-issue. A developer may just as well retrieve an administrative
ResourceResolver,
[jira] [Comment Edited] (SLING-2698) Add a minimal resource access gate
[
https://issues.apache.org/jira/browse/SLING-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13593256#comment-13593256
]
Julian Sedding edited comment on SLING-2698 at 3/5/13 9:29 AM:
---
I like Carsten's idea of wrapping the ResourceResolver. This should allow to
fully control the resources provided by this resolver. I presume this could be
as simple as adding a ResourceResolverCustomizer interface, that can be
implemented by client-code. In
ResourceResolverFactoryImpl#getResourceResolverInternal() all
ResourceResolverCustomizers will get given a chance to customize the
ResourceResolver in service.ranking order (by decorating it, exchanging it all
together, or anything else that people could come up with).
The interface could look like this:
/**
* Hook that can be implemented to intercept a ResourceResolver just after its
* creation in order to do any modifications on it, e.g. decorating it with
additional
* behavior.
*/
public interface ResourceResolverCustomizer {
/**
* This method allows modifying, decorating or exchanging a
resource-resolver
* immediately after its creation. It is guaranteed that the {@code
ResourceResolver}
* provided as an argument has not been used yet.
*/
public ResourceResolver customize(ResourceResolver resolver);
}
Given such a hook, the ResourceAccessGate could implement this hook and live in
its own bundle, thus decoupling it from the resourceresolver bundle and its
release-cycle.
In addition, a decorator-based approach probably allows for relatively easy
mocking and unit-testing.
I implemented a generic ResourceResolverWrapper a while ago, which makes sure
all its Resources are also wrapped. The implementation lacks some new methods,
but might help to implement such an approach. I'll attach it in case it's
useful.
Regarding the regexps, my concerns stem from a recent negative experience
(different software, similar scenario). I agree that regexps may be useful and
should be allowed in implementations of ResourceAccessGate. I would try,
however, to avoid using regexps in the ResourceAccessGateHandler. This should
allow efficient preselection of relevant ResourceAccessGates and still allows
for arbitrary flexibility.
Regarding unwrapping the Resource intentionally, I agree that that's a
non-issue. A developer may just as well retrieve an administrative
ResourceResolver, if so inclined. With the current ResourceDecorator approach,
we might run into situations like SLING-2739, however, if we can decorate the
ResourceResolver, we should have better control.
was (Author: jsedding):
I like Carsten's idea of wrapping the ResourceResolver. This should allow
to fully control the resources provided by this resolver. I presume this could
be as simple as adding a ResourceResolverCustomizer interface, that can be
implemented by client-code. In
ResourceResolverFactoryImpl#getResourceResolverInternal() all
ResourceResolverCustomizers will get given a chance to customize the
ResourceResolver in service.ranking order (by decorating it, exchanging it all
together, or anything else that people could come up with).
The interface could look like this:
{code:java}
/**
* Hook that can be implemented to intercept a ResourceResolver just after its
* creation in order to do any modifications on it, e.g. decorating it with
additional
* behavior.
*/
public interface ResourceResolverCustomizer {
/**
* This method allows modifying, decorating or exchanging a
resource-resolver
* immediately after its creation. It is guaranteed that the {@code
ResourceResolver}
* provided as an argument has not been used yet.
*/
public ResourceResolver customize(ResourceResolver resolver);
}
{code}
Given such a hook, the ResourceAccessGate could implement this hook and live in
its own bundle, thus decoupling it from the resourceresolver bundle and its
release-cycle.
In addition, a decorator-based approach probably allows for relatively easy
mocking and unit-testing.
I implemented a generic ResourceResolverWrapper a while ago, which makes sure
all its Resources are also wrapped. The implementation lacks some new methods,
but might help to implement such an approach. I'll attach it in case it's
useful.
Regarding the regexps, my concerns stem from a recent negative experience
(different software, similar scenario). I agree that regexps may be useful and
should be allowed in implementations of ResourceAccessGate. I would try,
however, to avoid using regexps in the ResourceAccessGateHandler. This should
allow efficient preselection of relevant ResourceAccessGates and still allows
for arbitrary flexibility.
Regarding unwrapping the Resource intentionally, I agree that that's a
non-issue. A developer may just as well retrieve an administrative
ResourceResolver, if so
[jira] Commented: (SLING-1126) Support serializable objects
[ https://issues.apache.org/jira/browse/SLING-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760221#action_12760221 ] Julian Sedding commented on SLING-1126: --- To add a bit of flexibility, it should probably be ValueMap.get(String, Class), returning T. This would cater for both: Serializable s = valueMap.get(key, Serializable.class); and if Foo implements Serializable: Foo f = valueMap.get(key, Foo.class); thus avoiding unnecessary casts, when the expected type is known. > Support serializable objects > > > Key: SLING-1126 > URL: https://issues.apache.org/jira/browse/SLING-1126 > Project: Sling > Issue Type: Improvement > Components: JCR >Affects Versions: JCR Resource 2.0.4 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: JCR Resource 2.0.6 > > > The JcrPropertyMap and JcrModifiablePropertyMap only support reading and > writing the object types supported by JCR. It is currently not possible to > store any serializable objects. > Supporting the writing of serializable objects is easy, we just have to > enhance the JcrModifiablePropertyMap to write the serialized object into the > repository (through an ObjectOutputStream). > Reading a serialized object is more tricky as the implementation does not > know in advance, if the input stream contains a serialized object or some > arbitrary data. > The check for this is a little bit expensive as it would require to first try > to read the data through an ObjectInputStream and if that success we have the > serialized object. If this is not successful, a new input stream has to be > used. > As I think that this is a very valuable feature (for example the Sling > eventing has a use case for this), we should do this special check only under > certain circumstances, for example > a) if ValueMap.get(KEY) is invoked and the property is an input stream > or > b) if ValueMap.get(KEY, Object.class) is used > Any other ideas, suggestions? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] [Commented] (SLING-9076) CA config resolver API is not returning any resources when invoked on instance start
[ https://issues.apache.org/jira/browse/SLING-9076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044457#comment-17044457 ] Julian Sedding commented on SLING-9076: --- [~nischgup] Stefan's concern that your suggested "solution" is incomplete is valid regardless of whether AEM implements this interface. Imagine that tomorrow AEM ships with an extra implementation, then your code would break again. BTW, you can already fix this yourself. OSGi DS allows you to specify the [minimum cardinality of a service via configuration|https://osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#service.component-minimum.cardinality.property]. In addition you could even specify a custom target filter in your configuration to control which implementations are used. > CA config resolver API is not returning any resources when invoked on > instance start > > > Key: SLING-9076 > URL: https://issues.apache.org/jira/browse/SLING-9076 > Project: Sling > Issue Type: Bug >Reporter: Nischay Gupta >Priority: Major > > Ca config resolver API is not returning any resources when invoked on bundle > activate when AEM instance starts – this is because of late binding config > resolution strategy service. > In *ConfigurationResourceResolvingStrategyMultiplexerImpl* the cardinality is > set to atleast one *cardinality=ReferenceCardinality.MULTIPLE* but it should > be *cardinality=ReferenceCardinality.ATLEAST_ONE* -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-9076) CA config resolver API is not returning any resources when invoked on instance start
[
https://issues.apache.org/jira/browse/SLING-9076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17046767#comment-17046767
]
Julian Sedding commented on SLING-9076:
---
[~nischgup] the scenario sounds basically like I had understood before.
However, it's not entirely correct. Let me explain:
# your service depends on {{ConfigurationResourceResolver}}, which is
implemented by {{ConfigurationResourceResolverImpl}} (I assume cardinality is
MANDATORY)
# {{ConfigurationResourceResolverImpl}} depends on
{{ConfigurationResourceResolvingStrategyMultiplexer}} with cardinality
MANDATORY, which is implemented by
{{ConfigurationResourceResolvingStrategyMultiplexerImpl}}
# {{ConfigurationResourceResolvingStrategyMultiplexerImpl}} depends on
{{ConfigurationResourceResolvingStrategy}} with cardinality MULTIPLE.
Only the last point is problematic for you, so you can configure
ConfigurationResourceResolvingStrategyMultiplexerImpl to change the cardinality
to AT_LEAST_ONE (exactly as you request in this issue, just via configadmin).
It may be confusing that I suggest configuring
{{ConfigurationResourceResolvingStrategyMultiplexerImpl}}, when it doesn't have
a metatype (i.e. it doesn't show up in the web console). However, all DS
components can be configured, regardless of whether they have a metatype or
not. (I only reached this insight after a few years.)
Something like the following should work (I didnt' test). You can place the
config file in the filesystem install folder or in the repository install
folder of your choice. On the first startup the configuration _may_ be
installed too late, but I expect everything to be fine on second startup.
{code:none|title=org.apache.sling.caconfig.resource.impl.ConfigurationResourceResolvingStrategyMultiplexerImpl.config}
configurationResourceResolvingStrategy.cardinality.minimum=I"1"
configurationResourceResolvingStrategy.target="(objectClass=org.apache.sling.caconfig.resource.impl.def.DefaultConfigurationResourceResolvingStrategy)"
{code}
> CA config resolver API is not returning any resources when invoked on
> instance start
>
>
> Key: SLING-9076
> URL: https://issues.apache.org/jira/browse/SLING-9076
> Project: Sling
> Issue Type: Bug
>Reporter: Nischay Gupta
>Priority: Major
>
> Ca config resolver API is not returning any resources when invoked on bundle
> activate when AEM instance starts – this is because of late binding config
> resolution strategy service.
> In *ConfigurationResourceResolvingStrategyMultiplexerImpl* the cardinality is
> set to atleast one *cardinality=ReferenceCardinality.MULTIPLE* but it should
> be *cardinality=ReferenceCardinality.ATLEAST_ONE*
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SLING-9076) CA config resolver API is not returning any resources when invoked on instance start
[
https://issues.apache.org/jira/browse/SLING-9076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17046767#comment-17046767
]
Julian Sedding edited comment on SLING-9076 at 2/27/20 4:31 PM:
[~nischgup] the scenario sounds basically like I had understood before.
However, it's not entirely correct. Let me explain:
# your service depends on {{ConfigurationResourceResolver}}, which is
implemented by {{ConfigurationResourceResolverImpl}} (I assume cardinality is
MANDATORY)
# {{ConfigurationResourceResolverImpl}} depends on
{{ConfigurationResourceResolvingStrategyMultiplexer}} with cardinality
MANDATORY, which is implemented by
{{ConfigurationResourceResolvingStrategyMultiplexerImpl}}
# {{ConfigurationResourceResolvingStrategyMultiplexerImpl}} depends on
{{ConfigurationResourceResolvingStrategy}} with cardinality MULTIPLE.
Only the last point is problematic for you, so you can configure
ConfigurationResourceResolvingStrategyMultiplexerImpl to change the cardinality
to AT_LEAST_ONE (exactly as you request in this issue, just via configadmin).
It may be confusing that I suggest configuring
{{ConfigurationResourceResolvingStrategyMultiplexerImpl}}, when it doesn't have
a metatype (i.e. it doesn't show up in the web console). However, all DS
components can be configured, regardless of whether they have a metatype or
not. (I only reached this insight after a few years.)
Something like the following should work (-I didnt' test-). You can place the
config file in the filesystem install folder or in the repository install
folder of your choice. On the first startup the configuration _may_ be
installed too late, but I expect everything to be fine on second startup.
{code:none|title=org.apache.sling.caconfig.resource.impl.ConfigurationResourceResolvingStrategyMultiplexerImpl.config}
configurationResourceResolvingStrategy.cardinality.minimum=I"1"
configurationResourceResolvingStrategy.target="(component.name\=org.apache.sling.caconfig.resource.impl.def.DefaultConfigurationResourceResolvingStrategy)"
{code}
was (Author: jsedding):
[~nischgup] the scenario sounds basically like I had understood before.
However, it's not entirely correct. Let me explain:
# your service depends on {{ConfigurationResourceResolver}}, which is
implemented by {{ConfigurationResourceResolverImpl}} (I assume cardinality is
MANDATORY)
# {{ConfigurationResourceResolverImpl}} depends on
{{ConfigurationResourceResolvingStrategyMultiplexer}} with cardinality
MANDATORY, which is implemented by
{{ConfigurationResourceResolvingStrategyMultiplexerImpl}}
# {{ConfigurationResourceResolvingStrategyMultiplexerImpl}} depends on
{{ConfigurationResourceResolvingStrategy}} with cardinality MULTIPLE.
Only the last point is problematic for you, so you can configure
ConfigurationResourceResolvingStrategyMultiplexerImpl to change the cardinality
to AT_LEAST_ONE (exactly as you request in this issue, just via configadmin).
It may be confusing that I suggest configuring
{{ConfigurationResourceResolvingStrategyMultiplexerImpl}}, when it doesn't have
a metatype (i.e. it doesn't show up in the web console). However, all DS
components can be configured, regardless of whether they have a metatype or
not. (I only reached this insight after a few years.)
Something like the following should work (I didnt' test). You can place the
config file in the filesystem install folder or in the repository install
folder of your choice. On the first startup the configuration _may_ be
installed too late, but I expect everything to be fine on second startup.
{code:none|title=org.apache.sling.caconfig.resource.impl.ConfigurationResourceResolvingStrategyMultiplexerImpl.config}
configurationResourceResolvingStrategy.cardinality.minimum=I"1"
configurationResourceResolvingStrategy.target="(objectClass=org.apache.sling.caconfig.resource.impl.def.DefaultConfigurationResourceResolvingStrategy)"
{code}
> CA config resolver API is not returning any resources when invoked on
> instance start
>
>
> Key: SLING-9076
> URL: https://issues.apache.org/jira/browse/SLING-9076
> Project: Sling
> Issue Type: Bug
>Reporter: Nischay Gupta
>Priority: Major
>
> Ca config resolver API is not returning any resources when invoked on bundle
> activate when AEM instance starts – this is because of late binding config
> resolution strategy service.
> In *ConfigurationResourceResolvingStrategyMultiplexerImpl* the cardinality is
> set to atleast one *cardinality=ReferenceCardinality.MULTIPLE* but it should
> be *cardinality=ReferenceCardinality.ATLEAST_ONE*
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SLING-9076) CA config resolver API is not returning any resources when invoked on instance start
[
https://issues.apache.org/jira/browse/SLING-9076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17046767#comment-17046767
]
Julian Sedding edited comment on SLING-9076 at 2/27/20 4:34 PM:
[~nischgup] the scenario sounds basically like I had understood before.
However, it's not entirely correct. Let me explain:
# your service depends on {{ConfigurationResourceResolver}}, which is
implemented by {{ConfigurationResourceResolverImpl}} (I assume cardinality is
MANDATORY)
# {{ConfigurationResourceResolverImpl}} depends on
{{ConfigurationResourceResolvingStrategyMultiplexer}} with cardinality
MANDATORY, which is implemented by
{{ConfigurationResourceResolvingStrategyMultiplexerImpl}}
# {{ConfigurationResourceResolvingStrategyMultiplexerImpl}} depends on
{{ConfigurationResourceResolvingStrategy}} with cardinality MULTIPLE.
Only the last point is problematic for you, so you can configure
ConfigurationResourceResolvingStrategyMultiplexerImpl to change the cardinality
to AT_LEAST_ONE (exactly as you request in this issue, just via configadmin).
It may be confusing that I suggest configuring
{{ConfigurationResourceResolvingStrategyMultiplexerImpl}}, when it doesn't have
a metatype (i.e. it doesn't show up in the web console). However, all DS
components can be configured, regardless of whether they have a metatype or
not. (I only reached this insight after a few years.)
Something like the following should work (-I didnt' test-). You can place the
config file in the filesystem install folder or in the repository install
folder of your choice. On the first startup the configuration _may_ be
installed too late, but I expect everything to be fine on second startup.
{code:none|title=org.apache.sling.caconfig.resource.impl.ConfigurationResourceResolvingStrategyMultiplexerImpl.config}
configurationResourceResolvingStrategy.cardinality.minimum=I"1"
configurationResourceResolvingStrategy.target="(component.name\=org.apache.sling.caconfig.resource.impl.def.DefaultConfigurationResourceResolvingStrategy)"
{code}
Note: the example assumes the latest caconfig-impl bundle is used. There were
some changes to the implementation e.g. {{
So if you're running an older version, you may need to adjust the class names.
was (Author: jsedding):
[~nischgup] the scenario sounds basically like I had understood before.
However, it's not entirely correct. Let me explain:
# your service depends on {{ConfigurationResourceResolver}}, which is
implemented by {{ConfigurationResourceResolverImpl}} (I assume cardinality is
MANDATORY)
# {{ConfigurationResourceResolverImpl}} depends on
{{ConfigurationResourceResolvingStrategyMultiplexer}} with cardinality
MANDATORY, which is implemented by
{{ConfigurationResourceResolvingStrategyMultiplexerImpl}}
# {{ConfigurationResourceResolvingStrategyMultiplexerImpl}} depends on
{{ConfigurationResourceResolvingStrategy}} with cardinality MULTIPLE.
Only the last point is problematic for you, so you can configure
ConfigurationResourceResolvingStrategyMultiplexerImpl to change the cardinality
to AT_LEAST_ONE (exactly as you request in this issue, just via configadmin).
It may be confusing that I suggest configuring
{{ConfigurationResourceResolvingStrategyMultiplexerImpl}}, when it doesn't have
a metatype (i.e. it doesn't show up in the web console). However, all DS
components can be configured, regardless of whether they have a metatype or
not. (I only reached this insight after a few years.)
Something like the following should work (-I didnt' test-). You can place the
config file in the filesystem install folder or in the repository install
folder of your choice. On the first startup the configuration _may_ be
installed too late, but I expect everything to be fine on second startup.
{code:none|title=org.apache.sling.caconfig.resource.impl.ConfigurationResourceResolvingStrategyMultiplexerImpl.config}
configurationResourceResolvingStrategy.cardinality.minimum=I"1"
configurationResourceResolvingStrategy.target="(component.name\=org.apache.sling.caconfig.resource.impl.def.DefaultConfigurationResourceResolvingStrategy)"
{code}
> CA config resolver API is not returning any resources when invoked on
> instance start
>
>
> Key: SLING-9076
> URL: https://issues.apache.org/jira/browse/SLING-9076
> Project: Sling
> Issue Type: Bug
>Reporter: Nischay Gupta
>Priority: Major
>
> Ca config resolver API is not returning any resources when invoked on bundle
> activate when AEM instance starts – this is because of late binding config
> resolution strategy service.
> In *ConfigurationResourceResolvingStrategyMultiplexerImpl* the cardinality is
> set to atleast one *cardinality=ReferenceCardinality.MULTIPLE* but it
[jira] [Commented] (SLING-8995) Code coverage no longer picked up by SonarCloud
[
https://issues.apache.org/jira/browse/SLING-8995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17047763#comment-17047763
]
Julian Sedding commented on SLING-8995:
---
[~rombert] I read up about this a little and got the impression that we need to
replace {{sonar.jacoco.reportPaths=target/jacoco-merged.exec}} with
{{sonar.coverage.jacoco.xmlReportPaths=target/site/jacoco-merged/jacoco.xml}}.
However, I have no idea where to do that and if I have the permissions to do so.
> Code coverage no longer picked up by SonarCloud
> ---
>
> Key: SLING-8995
> URL: https://issues.apache.org/jira/browse/SLING-8995
> Project: Sling
> Issue Type: Improvement
> Components: Build and Source Control
>Reporter: Robert Munteanu
>Priority: Major
>
> The following warnings is issued during analysis: {{Property
> 'sonar.jacoco.reportPaths' is no longer supported. Use JaCoCo's xml report
> and sonar-jacoco plugin.}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-8995) Code coverage no longer picked up by SonarCloud
[
https://issues.apache.org/jira/browse/SLING-8995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17047776#comment-17047776
]
Julian Sedding commented on SLING-8995:
---
Ok, I found it. Thanks for the docs! I've [created a
PR|https://github.com/apache/sling-tooling-jenkins/pull/3].
> Code coverage no longer picked up by SonarCloud
> ---
>
> Key: SLING-8995
> URL: https://issues.apache.org/jira/browse/SLING-8995
> Project: Sling
> Issue Type: Improvement
> Components: Build and Source Control
>Reporter: Robert Munteanu
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The following warnings is issued during analysis: {{Property
> 'sonar.jacoco.reportPaths' is no longer supported. Use JaCoCo's xml report
> and sonar-jacoco plugin.}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-9140) utility to merge multiple value maps
[ https://issues.apache.org/jira/browse/SLING-9140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding updated SLING-9140: -- Summary: utility to merge multiple value maps (was: FIFO valuemap) > utility to merge multiple value maps > - > > Key: SLING-9140 > URL: https://issues.apache.org/jira/browse/SLING-9140 > Project: Sling > Issue Type: Improvement > Components: API >Reporter: Nicolas Peltier >Assignee: Nicolas Peltier >Priority: Major > Time Spent: 8h 40m > Remaining Estimate: 0h > > utility class to provide a simple way to have a fallback valuemap > discussed here > [https://lists.apache.org/thread.html/r0afe5f5d7c9537c25e7aedf466239047eedf4e88143376e10ae87b95%40%3Cdev.sling.apache.org%3E] > and in the PR too https://github.com/apache/sling-org-apache-sling-api/pull/19 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-8995) Code coverage no longer picked up by SonarCloud
[
https://issues.apache.org/jira/browse/SLING-8995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding resolved SLING-8995.
---
Assignee: Julian Sedding
Resolution: Fixed
Fixed with [commit
383e7bc|https://gitbox.apache.org/repos/asf?p=sling-tooling-jenkins.git;a=commitdiff;h=383e7bc].
> Code coverage no longer picked up by SonarCloud
> ---
>
> Key: SLING-8995
> URL: https://issues.apache.org/jira/browse/SLING-8995
> Project: Sling
> Issue Type: Improvement
> Components: Build and Source Control
>Reporter: Robert Munteanu
>Assignee: Julian Sedding
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The following warnings is issued during analysis: {{Property
> 'sonar.jacoco.reportPaths' is no longer supported. Use JaCoCo's xml report
> and sonar-jacoco plugin.}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SLING-9140) utility to merge multiple value maps
[ https://issues.apache.org/jira/browse/SLING-9140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding resolved SLING-9140. --- Fix Version/s: API 2.22.2 Assignee: Julian Sedding (was: Nicolas Peltier) Resolution: Fixed Fixed in sling-org-apache-sling-api with [commit e6321c5|https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-api.git;a=commitdiff;h=e6321c5]. > utility to merge multiple value maps > - > > Key: SLING-9140 > URL: https://issues.apache.org/jira/browse/SLING-9140 > Project: Sling > Issue Type: Improvement > Components: API >Reporter: Nicolas Peltier >Assignee: Julian Sedding >Priority: Major > Fix For: API 2.22.2 > > Time Spent: 10h 10m > Remaining Estimate: 0h > > utility class to provide a simple way to have a fallback valuemap > discussed here > [https://lists.apache.org/thread.html/r0afe5f5d7c9537c25e7aedf466239047eedf4e88143376e10ae87b95%40%3Cdev.sling.apache.org%3E] > and in the PR too https://github.com/apache/sling-org-apache-sling-api/pull/19 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-9171) Support for settings properties on paths created via repoinit create path
[
https://issues.apache.org/jira/browse/SLING-9171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17064684#comment-17064684
]
Julian Sedding commented on SLING-9171:
---
Another alternative ;)
{noformat}
set properties on /pathA, /path/B
init sling:ResourceType to /x/y/z
force someInteger{Integer} to 42
end {noformat}
> Support for settings properties on paths created via repoinit create path
> -
>
> Key: SLING-9171
> URL: https://issues.apache.org/jira/browse/SLING-9171
> Project: Sling
> Issue Type: Improvement
> Components: Repoinit
>Reporter: Nitin Gupta
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Apart from jcr:primaryType and mixin, there is a requirement to add custom
> properties to the nodes valuemap via repoinit. This is a gap currently.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-9365) Optimize servlet to resource provider servlet mounter
[ https://issues.apache.org/jira/browse/SLING-9365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17084691#comment-17084691 ] Julian Sedding commented on SLING-9365: --- A solution somewhere in between having a ResourceProvider for every servlet and having none at all might be a single RP for all servlets. It could bind servlets dynamically and thus wouldn't need to be restarted. I'm not sure if/how that could be done. But handling the addition/removal of servlets inside a specialised implementation might allow for some shortcuts to make it performant. Another way we have to inject Resources into a tree is the ResourceDecorator interface, which I have used in projects to "mount" read-only resource trees onto arbitrary resources. This would alow for a similar implementation as above, but might be simpler? The only thing that's a little tricky is that in order to decorate a hierarchy, the ResourceResolver needs to be (properly) decorated as well. I'm not sure that this approach allows sending resource added/removed events, but I suppose it should be possible. > Optimize servlet to resource provider servlet mounter > - > > Key: SLING-9365 > URL: https://issues.apache.org/jira/browse/SLING-9365 > Project: Sling > Issue Type: Improvement > Components: Scripting >Affects Versions: Servlets Resolver 2.6.4 >Reporter: Karl Pauls >Assignee: Karl Pauls >Priority: Major > Fix For: Servlets Resolver 2.6.6 > > > The current ServletMounter creates a resource provider for each registered > servlet. That works fine for a given amount of servlets but can become > problematic for a high number of servlets as it means that on the one hand, > the number of services is doubled and on the other hand, a lot of > notifications are send out as well as a lot of computation has to be done by > the resource resolver. > As an optional remedy for these kinds of scenarios, we should allow to > configure the mounter to instead provide a single resource provider that has > manages the servlets internally. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-9365) Optimize servlet to resource provider servlet mounter
[ https://issues.apache.org/jira/browse/SLING-9365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17084711#comment-17084711 ] Julian Sedding commented on SLING-9365: --- [~karlpauls] oh sorry for the noise. Obviously I didn't read the ticket carefully enough. Glad that the ResourceDecorator idea may be of help! > Optimize servlet to resource provider servlet mounter > - > > Key: SLING-9365 > URL: https://issues.apache.org/jira/browse/SLING-9365 > Project: Sling > Issue Type: Improvement > Components: Scripting >Affects Versions: Servlets Resolver 2.6.4 >Reporter: Karl Pauls >Assignee: Karl Pauls >Priority: Major > Fix For: Servlets Resolver 2.6.6 > > > The current ServletMounter creates a resource provider for each registered > servlet. That works fine for a given amount of servlets but can become > problematic for a high number of servlets as it means that on the one hand, > the number of services is doubled and on the other hand, a lot of > notifications are send out as well as a lot of computation has to be done by > the resource resolver. > As an optional remedy for these kinds of scenarios, we should allow to > configure the mounter to instead provide a single resource provider that has > manages the servlets internally. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-9365) Optimize servlet to resource provider servlet mounter
[ https://issues.apache.org/jira/browse/SLING-9365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17084749#comment-17084749 ] Julian Sedding commented on SLING-9365: --- I've pushed some code I had to the whiteboard, maybe it's helpful: [https://github.com/apache/sling-whiteboard/tree/feature/sling-resource-graft] On second thought, I'm not sure if ResourceDecorator will work for you. I have a feeling that they are only called during request processing. But that could be fixed, I guess. > Optimize servlet to resource provider servlet mounter > - > > Key: SLING-9365 > URL: https://issues.apache.org/jira/browse/SLING-9365 > Project: Sling > Issue Type: Improvement > Components: Scripting >Affects Versions: Servlets Resolver 2.6.4 >Reporter: Karl Pauls >Assignee: Karl Pauls >Priority: Major > Fix For: Servlets Resolver 2.6.6 > > > The current ServletMounter creates a resource provider for each registered > servlet. That works fine for a given amount of servlets but can become > problematic for a high number of servlets as it means that on the one hand, > the number of services is doubled and on the other hand, a lot of > notifications are send out as well as a lot of computation has to be done by > the resource resolver. > As an optional remedy for these kinds of scenarios, we should allow to > configure the mounter to instead provide a single resource provider that has > manages the servlets internally. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (SLING-9365) Optimize servlet to resource provider servlet mounter
[ https://issues.apache.org/jira/browse/SLING-9365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17084749#comment-17084749 ] Julian Sedding edited comment on SLING-9365 at 4/16/20, 10:47 AM: -- I've pushed some code I had to the whiteboard, maybe it's helpful: [https://github.com/apache/sling-whiteboard/tree/feature/sling-resource-graft] On second thought, I'm not sure if ResourceDecorator will work for you. I have a feeling that they are only called during request processing. But that could be fixed, I guess. was (Author: jsedding): I've pushed some code I had to the whiteboard, maybe it's helpful: [https://github.com/apache/sling-whiteboard/tree/feature/sling-resource-graft] On second thought, I'm not sure if ResourceDecorator will work for you. I have a feeling that they are only called during request processing. But that could be fixed, I guess. > Optimize servlet to resource provider servlet mounter > - > > Key: SLING-9365 > URL: https://issues.apache.org/jira/browse/SLING-9365 > Project: Sling > Issue Type: Improvement > Components: Scripting >Affects Versions: Servlets Resolver 2.6.4 >Reporter: Karl Pauls >Assignee: Karl Pauls >Priority: Major > Fix For: Servlets Resolver 2.6.6 > > > The current ServletMounter creates a resource provider for each registered > servlet. That works fine for a given amount of servlets but can become > problematic for a high number of servlets as it means that on the one hand, > the number of services is doubled and on the other hand, a lot of > notifications are send out as well as a lot of computation has to be done by > the resource resolver. > As an optional remedy for these kinds of scenarios, we should allow to > configure the mounter to instead provide a single resource provider that has > manages the servlets internally. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (SLING-9365) Optimize servlet to resource provider servlet mounter
[ https://issues.apache.org/jira/browse/SLING-9365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17084749#comment-17084749 ] Julian Sedding edited comment on SLING-9365 at 4/16/20, 10:47 AM: -- [~karlpauls] I've pushed some code I had to the whiteboard, maybe it's helpful: [https://github.com/apache/sling-whiteboard/tree/feature/sling-resource-graft] On second thought, I'm not sure if ResourceDecorator will work for you. I have a feeling that they are only called during request processing. But that could be fixed, I guess. was (Author: jsedding): I've pushed some code I had to the whiteboard, maybe it's helpful: [https://github.com/apache/sling-whiteboard/tree/feature/sling-resource-graft] On second thought, I'm not sure if ResourceDecorator will work for you. I have a feeling that they are only called during request processing. But that could be fixed, I guess. > Optimize servlet to resource provider servlet mounter > - > > Key: SLING-9365 > URL: https://issues.apache.org/jira/browse/SLING-9365 > Project: Sling > Issue Type: Improvement > Components: Scripting >Affects Versions: Servlets Resolver 2.6.4 >Reporter: Karl Pauls >Assignee: Karl Pauls >Priority: Major > Fix For: Servlets Resolver 2.6.6 > > > The current ServletMounter creates a resource provider for each registered > servlet. That works fine for a given amount of servlets but can become > problematic for a high number of servlets as it means that on the one hand, > the number of services is doubled and on the other hand, a lot of > notifications are send out as well as a lot of computation has to be done by > the resource resolver. > As an optional remedy for these kinds of scenarios, we should allow to > configure the mounter to instead provide a single resource provider that has > manages the servlets internally. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-9378) When internalRedirect and sling:match maps are added, filterPattern doesn't work
[
https://issues.apache.org/jira/browse/SLING-9378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17085283#comment-17085283
]
Julian Sedding commented on SLING-9378:
---
I agree that the change from {{request.getPathInfo()}} to
{{request.getRequestPathInfo().getResourcePath()}} was incorrect and introduced
a bug. IMHO the fix should be to change it back rather than match the pattern
against both.
> When internalRedirect and sling:match maps are added, filterPattern doesn't
> work
>
>
> Key: SLING-9378
> URL: https://issues.apache.org/jira/browse/SLING-9378
> Project: Sling
> Issue Type: Bug
>Affects Versions: Engine 2.6.16, Engine 2.6.18
>Reporter: Ankita Agarwal
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> ***sling.filter.pattern=/abcd/.** doesn't work after a map is added with
> internalRedirect and sling:match. This is a issue due to
> [SLING-7759|https://issues.apache.org/jira/browse/SLING-7759]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-9378) When internalRedirect and sling:match maps are added, filterPattern doesn't work
[ https://issues.apache.org/jira/browse/SLING-9378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17088978#comment-17088978 ] Julian Sedding commented on SLING-9378: --- [~cziegeler] sorry for the late reply. I think d) is a very good compromise and I favour it. However, as you suggest, we can go with c) and enhance to d). Thanks! > When internalRedirect and sling:match maps are added, filterPattern doesn't > work > > > Key: SLING-9378 > URL: https://issues.apache.org/jira/browse/SLING-9378 > Project: Sling > Issue Type: Bug >Affects Versions: Engine 2.6.16, Engine 2.6.18 >Reporter: Ankita Agarwal >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > ***sling.filter.pattern=/abcd/.** doesn't work after a map is added with > internalRedirect and sling:match. This is a issue due to > [SLING-7759|https://issues.apache.org/jira/browse/SLING-7759] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-9378) When internalRedirect and sling:match maps are added, filterPattern doesn't work
[ https://issues.apache.org/jira/browse/SLING-9378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089466#comment-17089466 ] Julian Sedding commented on SLING-9378: --- Thanks [~ankitaagar] and [~cziegeler]! > When internalRedirect and sling:match maps are added, filterPattern doesn't > work > > > Key: SLING-9378 > URL: https://issues.apache.org/jira/browse/SLING-9378 > Project: Sling > Issue Type: Bug >Affects Versions: Engine 2.6.16, Engine 2.6.18 >Reporter: Ankita Agarwal >Assignee: Carsten Ziegeler >Priority: Major > Fix For: Engine 2.7.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > ***sling.filter.pattern=/abcd/.** doesn't work after a map is added with > internalRedirect and sling:match. This is a issue due to > [SLING-7759|https://issues.apache.org/jira/browse/SLING-7759] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-9118) Sling fails to start when database exists but 'sling' directory is missing
[ https://issues.apache.org/jira/browse/SLING-9118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17094241#comment-17094241 ] Julian Sedding commented on SLING-9118: --- bq. Karaf stores the configurations in the etc directory. In order to get to the root of this issue, I would assume a fair comparison between the launchpad and the karaf setup would require deleting the config directory as well. Or am I missing something? In a container landscape the config directory in a new container would not be initialized as far as I understand (and my understanding is currently very limited). Sorry for the noise in case this doesn't make any sense. > Sling fails to start when database exists but 'sling' directory is missing > -- > > Key: SLING-9118 > URL: https://issues.apache.org/jira/browse/SLING-9118 > Project: Sling > Issue Type: Bug >Reporter: Ben Radey >Assignee: Robert Munteanu >Priority: Major > Attachments: drop-mongo.sh, error.log, karaf.log, > recreateSlingReplicaSet.sh, run-mongo.sh, run-sling-initial.sh, > run-sling-second.sh, sling-startup-error.log.txt > > > # Create a persistent mongodb to use with Sling. > # Start sling using the mongodb. > # Stop sling. > # Remove 'sling' directory. > # Attempt to restart sling. Ultimately, sling fails to start. > > Steps to reproduce with attached scripts: > # Run [^run-mongo.sh] . This creates a MongoDB 3.6 container named > _mongo-sling_ > # Run [^run-sling-initial.sh]. This starts up Sling in the oak_mongo runmode, > shuts it down after it's (probably) started up > # Run [^run-sling-second.sh]. This moves away the sling directory and starts > up a new instance. This always fails > For cleanup, the [^drop-mongo.sh] script stops and removes the _mongo-sling_ > container. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-9365) Optionally don't create resource providers for servlets
[ https://issues.apache.org/jira/browse/SLING-9365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17095265#comment-17095265 ] Julian Sedding commented on SLING-9365: --- Glad that worked out. Cool! [~karlpauls] Do you have any performance data on this? > Optionally don't create resource providers for servlets > --- > > Key: SLING-9365 > URL: https://issues.apache.org/jira/browse/SLING-9365 > Project: Sling > Issue Type: Improvement > Components: Scripting >Affects Versions: Servlets Resolver 2.6.4 >Reporter: Karl Pauls >Assignee: Karl Pauls >Priority: Major > Fix For: Servlets Resolver 2.6.6 > > Time Spent: 1h > Remaining Estimate: 0h > > The current ServletMounter creates a resource provider for each registered > servlet. That works fine for a given amount of servlets but can become > problematic for a high number of servlets as it means that on the one hand, > the number of services is doubled and on the other hand, a lot of > notifications are send out as well as a lot of computation has to be done by > the resource resolver. > As an optional remedy for these kinds of scenarios, we should allow to > configure the mounter to not provide resource providers for servlets but only > decorate resources into the content tree. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-9588) The FSClassLoaderProvider activate/deactivate is racing to unregister the MBean
[
https://issues.apache.org/jira/browse/SLING-9588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17157673#comment-17157673
]
Julian Sedding commented on SLING-9588:
---
Not sure if the {{activate}} method can be called in a different thread than
{{deactivate}}. If that can happen, making {{mbeanRegistration}} "volatile"
might help.
> The FSClassLoaderProvider activate/deactivate is racing to unregister the
> MBean
> ---
>
> Key: SLING-9588
> URL: https://issues.apache.org/jira/browse/SLING-9588
> Project: Sling
> Issue Type: Bug
> Components: Commons
>Affects Versions: File System ClassLoader 1.0.12
>Reporter: Karl Pauls
>Priority: Major
> Fix For: File System ClassLoader 1.0.14
>
>
> It looks like the activate/deactivate method of the FSClassLoaderProvider is
> racing to unregister the mbean service reference. That is problematic as if
> it is unregistered twice, it will throw an exception - potentially killing
> the activate.
> Not sure what the right thing todo is here - but it seems very strange that
> the service ref would be static and clearly, there is a check-then-act cases
> in the below:
> https://github.com/apache/sling-org-apache-sling-commons-fsclassloader/blob/97d73c116d296b290e4484ca842bbbf185a8d36e/src/main/java/org/apache/sling/commons/fsclassloader/impl/FSClassLoaderProvider.java#L142
> https://github.com/apache/sling-org-apache-sling-commons-fsclassloader/blob/97d73c116d296b290e4484ca842bbbf185a8d36e/src/main/java/org/apache/sling/commons/fsclassloader/impl/FSClassLoaderProvider.java#L169
> [~cziegeler], any ideas why the code would be like it is right now?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SLING-9769) Minor memory leak in MapEntries class
Julian Sedding created SLING-9769:
-
Summary: Minor memory leak in MapEntries class
Key: SLING-9769
URL: https://issues.apache.org/jira/browse/SLING-9769
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Resolver 1.1.10
Reporter: Julian Sedding
Assignee: Julian Sedding
SLING-4216 introduced a limit to the number of cached vanity paths. If the
cache size is exceeded, it falls back to a repository search, which is
relatively costly. So in order to avoid most of the costly calls, a bloom
filter was introduced to answer the question whether a search is likely to
yield a result.
The bloom filter is by default nearly 1MB in size (without Java overhead) and
it is persisted in a file and a {{java.util.Timer}} was introduced "for
persisting the bloom filter every minute".
The memory leak is that the {{Timer}} is not cancelled when
{{MapEntries#dispose}} is called, and thus the timer's thread holds on to a
reference of the {{MapEntries}} instance. Now the severity of this issue is low
for two reasons:
1. MapEntries is a singleton in a normal Sling deployment.
2. A bug causes the {{TimerTask}} to be executed only once after 60 seconds and
not repeatedly. I.e. the thread disappeared after ~1 minute.
I discovered the memory leak when running unit tests that use Sling-Mock.
During testing a new {{ResourceResolverFactory}} instance, together with its
associated {{MapEntries}} is created for every test method. In a module with
~700 test methods that lead to an OutOfMemoryError}} with 1GB max heap size.
Fixing the memory leak allowed the same module to run with only 96MB max heap.
cc [~asanso]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-9769) Minor memory leak in MapEntries class
[
https://issues.apache.org/jira/browse/SLING-9769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated SLING-9769:
--
Description:
SLING-4216 introduced a limit to the number of cached vanity paths. If the
cache size is exceeded, it falls back to a repository search, which is
relatively costly. So in order to avoid most of the costly calls, a bloom
filter was introduced to answer the question whether a search is likely to
yield a result.
The bloom filter is by default nearly 1MB in size (without Java overhead) and
it is persisted in a file and a {{java.util.Timer}} was introduced "for
persisting the bloom filter every minute".
The memory leak is that the {{Timer}} is not cancelled when
{{MapEntries#dispose}} is called, and thus the timer's thread holds on to a
reference of the {{MapEntries}} instance. Now the severity of this issue is low
for two reasons:
1. MapEntries is a singleton in a normal Sling deployment.
2. A bug causes the {{TimerTask}} to be executed only once after 60 seconds and
not repeatedly. I.e. the thread disappeared after ~1 minute.
I discovered the memory leak when running unit tests that use Sling-Mock.
During testing a new {{ResourceResolverFactory}} instance, together with its
associated {{MapEntries}} is created for every test method. In a module with
~700 test methods that lead to an OutOfMemoryError}} with 1GB max heap size.
Fixing the memory leak allowed the same module to run with only 96MB max heap.
I intend to also fix the {{Timer}} to be scheduled to run once every minute.
This intention is indicated by a comment in the code.
The use of a non-volatile boolean field also looks like it might be prone to
concurrency/visibility issues and may be better replaced by an
{{AtomicBoolean}}.
cc [~asanso]
was:
SLING-4216 introduced a limit to the number of cached vanity paths. If the
cache size is exceeded, it falls back to a repository search, which is
relatively costly. So in order to avoid most of the costly calls, a bloom
filter was introduced to answer the question whether a search is likely to
yield a result.
The bloom filter is by default nearly 1MB in size (without Java overhead) and
it is persisted in a file and a {{java.util.Timer}} was introduced "for
persisting the bloom filter every minute".
The memory leak is that the {{Timer}} is not cancelled when
{{MapEntries#dispose}} is called, and thus the timer's thread holds on to a
reference of the {{MapEntries}} instance. Now the severity of this issue is low
for two reasons:
1. MapEntries is a singleton in a normal Sling deployment.
2. A bug causes the {{TimerTask}} to be executed only once after 60 seconds and
not repeatedly. I.e. the thread disappeared after ~1 minute.
I discovered the memory leak when running unit tests that use Sling-Mock.
During testing a new {{ResourceResolverFactory}} instance, together with its
associated {{MapEntries}} is created for every test method. In a module with
~700 test methods that lead to an OutOfMemoryError}} with 1GB max heap size.
Fixing the memory leak allowed the same module to run with only 96MB max heap.
cc [~asanso]
> Minor memory leak in MapEntries class
> -
>
> Key: SLING-9769
> URL: https://issues.apache.org/jira/browse/SLING-9769
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Affects Versions: Resource Resolver 1.1.10
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> SLING-4216 introduced a limit to the number of cached vanity paths. If the
> cache size is exceeded, it falls back to a repository search, which is
> relatively costly. So in order to avoid most of the costly calls, a bloom
> filter was introduced to answer the question whether a search is likely to
> yield a result.
> The bloom filter is by default nearly 1MB in size (without Java overhead) and
> it is persisted in a file and a {{java.util.Timer}} was introduced "for
> persisting the bloom filter every minute".
> The memory leak is that the {{Timer}} is not cancelled when
> {{MapEntries#dispose}} is called, and thus the timer's thread holds on to a
> reference of the {{MapEntries}} instance. Now the severity of this issue is
> low for two reasons:
> 1. MapEntries is a singleton in a normal Sling deployment.
> 2. A bug causes the {{TimerTask}} to be executed only once after 60 seconds
> and not repeatedly. I.e. the thread disappeared after ~1 minute.
> I discovered the memory leak when running unit tests that use Sling-Mock.
> During testing a new {{ResourceResolverFactory}} instance, together with its
> associated {{MapEntries}} is created for every test method. In a module with
> ~700 test methods that lead to an OutOfMemoryError}} with 1GB m
[jira] [Updated] (SLING-9769) Minor memory leak in MapEntries class
[
https://issues.apache.org/jira/browse/SLING-9769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated SLING-9769:
--
Description:
SLING-4216 introduced a limit to the number of cached vanity paths. If the
cache size is exceeded, it falls back to a repository search, which is
relatively costly. So in order to avoid most of the costly calls, a bloom
filter was introduced to answer the question whether a search is likely to
yield a result.
The bloom filter is by default nearly 1MB in size (without Java overhead) and
it is persisted in a file and a {{java.util.Timer}} was introduced "for
persisting the bloom filter every minute".
The memory leak is that the {{Timer}} is not cancelled when
{{MapEntries#dispose}} is called, and thus the timer's thread holds on to a
reference of the {{MapEntries}} instance. Now the severity of this issue is low
for two reasons:
1. MapEntries is a singleton in a normal Sling deployment.
2. A bug causes the {{TimerTask}} to be executed only once after 60 seconds and
not repeatedly. I.e. the thread disappeared after ~1 minute.
I discovered the memory leak when running unit tests that use Sling-Mock.
During testing a new {{ResourceResolverFactory}} instance, together with its
associated {{MapEntries}} is created for every test method. In a module with
~700 test methods that lead to an {{OutOfMemoryError}} with 1GB max heap size.
Fixing the memory leak allowed the same module to run with only 96MB max heap.
I intend to also fix the {{Timer}} to be scheduled to run once every minute.
This intention is indicated by a comment in the code.
The use of a non-volatile boolean field also looks like it might be prone to
concurrency/visibility issues and may be better replaced by an
{{AtomicBoolean}}.
cc [~asanso]
[~sseifert] do you think it would make sense for Sling Mock to set
{{resource.resolver.vanitypath.bloomfilter.maxBytes = 0}} by default?
was:
SLING-4216 introduced a limit to the number of cached vanity paths. If the
cache size is exceeded, it falls back to a repository search, which is
relatively costly. So in order to avoid most of the costly calls, a bloom
filter was introduced to answer the question whether a search is likely to
yield a result.
The bloom filter is by default nearly 1MB in size (without Java overhead) and
it is persisted in a file and a {{java.util.Timer}} was introduced "for
persisting the bloom filter every minute".
The memory leak is that the {{Timer}} is not cancelled when
{{MapEntries#dispose}} is called, and thus the timer's thread holds on to a
reference of the {{MapEntries}} instance. Now the severity of this issue is low
for two reasons:
1. MapEntries is a singleton in a normal Sling deployment.
2. A bug causes the {{TimerTask}} to be executed only once after 60 seconds and
not repeatedly. I.e. the thread disappeared after ~1 minute.
I discovered the memory leak when running unit tests that use Sling-Mock.
During testing a new {{ResourceResolverFactory}} instance, together with its
associated {{MapEntries}} is created for every test method. In a module with
~700 test methods that lead to an OutOfMemoryError}} with 1GB max heap size.
Fixing the memory leak allowed the same module to run with only 96MB max heap.
I intend to also fix the {{Timer}} to be scheduled to run once every minute.
This intention is indicated by a comment in the code.
The use of a non-volatile boolean field also looks like it might be prone to
concurrency/visibility issues and may be better replaced by an
{{AtomicBoolean}}.
cc [~asanso]
[~sseifert] do you think it would make sense for Sling Mock to set
{{resource.resolver.vanitypath.bloomfilter.maxBytes = 0}} by default?
> Minor memory leak in MapEntries class
> -
>
> Key: SLING-9769
> URL: https://issues.apache.org/jira/browse/SLING-9769
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Affects Versions: Resource Resolver 1.1.10
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> SLING-4216 introduced a limit to the number of cached vanity paths. If the
> cache size is exceeded, it falls back to a repository search, which is
> relatively costly. So in order to avoid most of the costly calls, a bloom
> filter was introduced to answer the question whether a search is likely to
> yield a result.
> The bloom filter is by default nearly 1MB in size (without Java overhead) and
> it is persisted in a file and a {{java.util.Timer}} was introduced "for
> persisting the bloom filter every minute".
> The memory leak is that the {{Timer}} is not cancelled when
> {{MapEntries#dispose}} is called, and thus the timer's thread holds on to a
> reference of the {{MapEntries}}
[jira] [Updated] (SLING-9769) Minor memory leak in MapEntries class
[
https://issues.apache.org/jira/browse/SLING-9769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated SLING-9769:
--
Description:
SLING-4216 introduced a limit to the number of cached vanity paths. If the
cache size is exceeded, it falls back to a repository search, which is
relatively costly. So in order to avoid most of the costly calls, a bloom
filter was introduced to answer the question whether a search is likely to
yield a result.
The bloom filter is by default nearly 1MB in size (without Java overhead) and
it is persisted in a file and a {{java.util.Timer}} was introduced "for
persisting the bloom filter every minute".
The memory leak is that the {{Timer}} is not cancelled when
{{MapEntries#dispose}} is called, and thus the timer's thread holds on to a
reference of the {{MapEntries}} instance. Now the severity of this issue is low
for two reasons:
1. MapEntries is a singleton in a normal Sling deployment.
2. A bug causes the {{TimerTask}} to be executed only once after 60 seconds and
not repeatedly. I.e. the thread disappeared after ~1 minute.
I discovered the memory leak when running unit tests that use Sling-Mock.
During testing a new {{ResourceResolverFactory}} instance, together with its
associated {{MapEntries}} is created for every test method. In a module with
~700 test methods that lead to an OutOfMemoryError}} with 1GB max heap size.
Fixing the memory leak allowed the same module to run with only 96MB max heap.
I intend to also fix the {{Timer}} to be scheduled to run once every minute.
This intention is indicated by a comment in the code.
The use of a non-volatile boolean field also looks like it might be prone to
concurrency/visibility issues and may be better replaced by an
{{AtomicBoolean}}.
cc [~asanso]
[~sseifert] do you think it would make sense for Sling Mock to set
{{resource.resolver.vanitypath.bloomfilter.maxBytes = 0}} by default?
was:
SLING-4216 introduced a limit to the number of cached vanity paths. If the
cache size is exceeded, it falls back to a repository search, which is
relatively costly. So in order to avoid most of the costly calls, a bloom
filter was introduced to answer the question whether a search is likely to
yield a result.
The bloom filter is by default nearly 1MB in size (without Java overhead) and
it is persisted in a file and a {{java.util.Timer}} was introduced "for
persisting the bloom filter every minute".
The memory leak is that the {{Timer}} is not cancelled when
{{MapEntries#dispose}} is called, and thus the timer's thread holds on to a
reference of the {{MapEntries}} instance. Now the severity of this issue is low
for two reasons:
1. MapEntries is a singleton in a normal Sling deployment.
2. A bug causes the {{TimerTask}} to be executed only once after 60 seconds and
not repeatedly. I.e. the thread disappeared after ~1 minute.
I discovered the memory leak when running unit tests that use Sling-Mock.
During testing a new {{ResourceResolverFactory}} instance, together with its
associated {{MapEntries}} is created for every test method. In a module with
~700 test methods that lead to an OutOfMemoryError}} with 1GB max heap size.
Fixing the memory leak allowed the same module to run with only 96MB max heap.
I intend to also fix the {{Timer}} to be scheduled to run once every minute.
This intention is indicated by a comment in the code.
The use of a non-volatile boolean field also looks like it might be prone to
concurrency/visibility issues and may be better replaced by an
{{AtomicBoolean}}.
cc [~asanso]
> Minor memory leak in MapEntries class
> -
>
> Key: SLING-9769
> URL: https://issues.apache.org/jira/browse/SLING-9769
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Affects Versions: Resource Resolver 1.1.10
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> SLING-4216 introduced a limit to the number of cached vanity paths. If the
> cache size is exceeded, it falls back to a repository search, which is
> relatively costly. So in order to avoid most of the costly calls, a bloom
> filter was introduced to answer the question whether a search is likely to
> yield a result.
> The bloom filter is by default nearly 1MB in size (without Java overhead) and
> it is persisted in a file and a {{java.util.Timer}} was introduced "for
> persisting the bloom filter every minute".
> The memory leak is that the {{Timer}} is not cancelled when
> {{MapEntries#dispose}} is called, and thus the timer's thread holds on to a
> reference of the {{MapEntries}} instance. Now the severity of this issue is
> low for two reasons:
> 1. MapEntries is a singleton in a normal Sling deployment.
> 2. A bug ca
[jira] [Commented] (SLING-9769) Minor memory leak in MapEntries class
[
https://issues.apache.org/jira/browse/SLING-9769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202210#comment-17202210
]
Julian Sedding commented on SLING-9769:
---
[PR
#21|https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/21]
is available.
> Minor memory leak in MapEntries class
> -
>
> Key: SLING-9769
> URL: https://issues.apache.org/jira/browse/SLING-9769
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Affects Versions: Resource Resolver 1.1.10
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> SLING-4216 introduced a limit to the number of cached vanity paths. If the
> cache size is exceeded, it falls back to a repository search, which is
> relatively costly. So in order to avoid most of the costly calls, a bloom
> filter was introduced to answer the question whether a search is likely to
> yield a result.
> The bloom filter is by default nearly 1MB in size (without Java overhead) and
> it is persisted in a file and a {{java.util.Timer}} was introduced "for
> persisting the bloom filter every minute".
> The memory leak is that the {{Timer}} is not cancelled when
> {{MapEntries#dispose}} is called, and thus the timer's thread holds on to a
> reference of the {{MapEntries}} instance. Now the severity of this issue is
> low for two reasons:
> 1. MapEntries is a singleton in a normal Sling deployment.
> 2. A bug causes the {{TimerTask}} to be executed only once after 60 seconds
> and not repeatedly. I.e. the thread disappeared after ~1 minute.
> I discovered the memory leak when running unit tests that use Sling-Mock.
> During testing a new {{ResourceResolverFactory}} instance, together with its
> associated {{MapEntries}} is created for every test method. In a module with
> ~700 test methods that lead to an {{OutOfMemoryError}} with 1GB max heap size.
> Fixing the memory leak allowed the same module to run with only 96MB max heap.
> I intend to also fix the {{Timer}} to be scheduled to run once every minute.
> This intention is indicated by a comment in the code.
> The use of a non-volatile boolean field also looks like it might be prone to
> concurrency/visibility issues and may be better replaced by an
> {{AtomicBoolean}}.
> cc [~asanso]
> [~sseifert] do you think it would make sense for Sling Mock to set
> {{resource.resolver.vanitypath.bloomfilter.maxBytes = 0}} by default?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
