[jira] [Assigned] (SLING-12341) Update sling-scriptingbundle-maven-plugin to maven 3.8.x
[ https://issues.apache.org/jira/browse/SLING-12341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dirk Rudolph reassigned SLING-12341: Assignee: Dirk Rudolph > Update sling-scriptingbundle-maven-plugin to maven 3.8.x > > > Key: SLING-12341 > URL: https://issues.apache.org/jira/browse/SLING-12341 > Project: Sling > Issue Type: Sub-task > Components: Maven Plugins and Archetypes >Reporter: Dirk Rudolph >Assignee: Dirk Rudolph >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12341) Update sling-scriptingbundle-maven-plugin to maven 3.8.x
Dirk Rudolph created SLING-12341: Summary: Update sling-scriptingbundle-maven-plugin to maven 3.8.x Key: SLING-12341 URL: https://issues.apache.org/jira/browse/SLING-12341 Project: Sling Issue Type: Sub-task Components: Maven Plugins and Archetypes Reporter: Dirk Rudolph -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12340) Update sling-maven-plugin to maven 3.8.x
Dirk Rudolph created SLING-12340: Summary: Update sling-maven-plugin to maven 3.8.x Key: SLING-12340 URL: https://issues.apache.org/jira/browse/SLING-12340 Project: Sling Issue Type: Sub-task Components: Maven Plugins and Archetypes Reporter: Dirk Rudolph -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12338) Update sling-htl-maven-plugin to maven 3.8.x
Dirk Rudolph created SLING-12338: Summary: Update sling-htl-maven-plugin to maven 3.8.x Key: SLING-12338 URL: https://issues.apache.org/jira/browse/SLING-12338 Project: Sling Issue Type: Sub-task Components: Maven Plugins and Archetypes Reporter: Dirk Rudolph -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12335) Update sling-kickstart-maven-plugin to maven 3.8.x
Dirk Rudolph created SLING-12335: Summary: Update sling-kickstart-maven-plugin to maven 3.8.x Key: SLING-12335 URL: https://issues.apache.org/jira/browse/SLING-12335 Project: Sling Issue Type: Sub-task Components: Maven Plugins and Archetypes Reporter: Dirk Rudolph -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12334) Update sling-maven-launchpad-plugin to maven 3.8.x
Dirk Rudolph created SLING-12334: Summary: Update sling-maven-launchpad-plugin to maven 3.8.x Key: SLING-12334 URL: https://issues.apache.org/jira/browse/SLING-12334 Project: Sling Issue Type: Sub-task Components: Maven Plugins and Archetypes Reporter: Dirk Rudolph -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12339) Update sling-feature-launcher-maven-plugin to maven 3.8.x
Dirk Rudolph created SLING-12339: Summary: Update sling-feature-launcher-maven-plugin to maven 3.8.x Key: SLING-12339 URL: https://issues.apache.org/jira/browse/SLING-12339 Project: Sling Issue Type: Sub-task Components: Maven Plugins and Archetypes Reporter: Dirk Rudolph -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12331) Update sling maven plugins to maven 3.8.x
[ https://issues.apache.org/jira/browse/SLING-12331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dirk Rudolph updated SLING-12331: - Component/s: Maven Plugins and Archetypes > Update sling maven plugins to maven 3.8.x > - > > Key: SLING-12331 > URL: https://issues.apache.org/jira/browse/SLING-12331 > Project: Sling > Issue Type: Improvement > Components: Maven Plugins and Archetypes >Reporter: Dirk Rudolph >Priority: Major > > We recently got some security vulnerability reported related to maven-core, > which is a transitive dependency used in many / some of the sling maven > plugins. > While maven-core is always take from the maven installation in the current > version, the vulnerable jars are downloaded when using the plugins, and hence > found and reported by security scanners. > We should update our maven plugins to use the 3.8.x version of maven at least. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12337) Update sling-feature-converter-maven-plugin to maven 3.8.x
Dirk Rudolph created SLING-12337: Summary: Update sling-feature-converter-maven-plugin to maven 3.8.x Key: SLING-12337 URL: https://issues.apache.org/jira/browse/SLING-12337 Project: Sling Issue Type: Sub-task Components: Maven Plugins and Archetypes Reporter: Dirk Rudolph -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12336) Update sling-jspc-maven-plugin to maven 3.8.x
Dirk Rudolph created SLING-12336: Summary: Update sling-jspc-maven-plugin to maven 3.8.x Key: SLING-12336 URL: https://issues.apache.org/jira/browse/SLING-12336 Project: Sling Issue Type: Sub-task Components: Maven Plugins and Archetypes Reporter: Dirk Rudolph -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12332) Update sling-slingfeature-maven-plugin to maven 3.8.1
Dirk Rudolph created SLING-12332: Summary: Update sling-slingfeature-maven-plugin to maven 3.8.1 Key: SLING-12332 URL: https://issues.apache.org/jira/browse/SLING-12332 Project: Sling Issue Type: Sub-task Components: Maven Plugins and Archetypes Reporter: Dirk Rudolph -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12333) Update sling-slingstart-maven-plugin to maven 3.8.x
Dirk Rudolph created SLING-12333: Summary: Update sling-slingstart-maven-plugin to maven 3.8.x Key: SLING-12333 URL: https://issues.apache.org/jira/browse/SLING-12333 Project: Sling Issue Type: Sub-task Components: Maven Plugins and Archetypes Reporter: Dirk Rudolph -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12331) Update sling maven plugins to maven 3.8.x
Dirk Rudolph created SLING-12331: Summary: Update sling maven plugins to maven 3.8.x Key: SLING-12331 URL: https://issues.apache.org/jira/browse/SLING-12331 Project: Sling Issue Type: Improvement Reporter: Dirk Rudolph We recently got some security vulnerability reported related to maven-core, which is a transitive dependency used in many / some of the sling maven plugins. While maven-core is always take from the maven installation in the current version, the vulnerable jars are downloaded when using the plugins, and hence found and reported by security scanners. We should update our maven plugins to use the 3.8.x version of maven at least. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12085) Add a RequestPreprocessor SPI to support path mappings in distribution messages
Dirk Rudolph created SLING-12085: Summary: Add a RequestPreprocessor SPI to support path mappings in distribution messages Key: SLING-12085 URL: https://issues.apache.org/jira/browse/SLING-12085 Project: Sling Issue Type: Improvement Components: Content Distribution Reporter: Dirk Rudolph We have a use case where the target system of Sling Content Distribution has a different content structure / path names than the origin system. To support this we would like to propose the addition of a RequestPreprocessor SPI that allows us to apply a path mapping to the objects contained in a distribution messages. This SPI should be used in the journal based distribution implementation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-11507) Field injection should not inject static and final fields and methods
[
https://issues.apache.org/jira/browse/SLING-11507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph resolved SLING-11507.
--
Fix Version/s: Models API 1.4.4
Resolution: Fixed
> Field injection should not inject static and final fields and methods
> -
>
> Key: SLING-11507
> URL: https://issues.apache.org/jira/browse/SLING-11507
> Project: Sling
> Issue Type: Bug
> Components: Sling Models
>Affects Versions: Models Impl 1.4.14
>Reporter: Joerg Hoh
>Assignee: Dirk Rudolph
>Priority: Critical
> Fix For: Models API 1.4.4
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Currently this injection works:
> {noformat}
> @SlingObject
> private static ResourceResolver resourceResolver;
> {noformat}
> but it should not. Sling Models are Pojos and injection must never inject
> into static fields. Instead it should throw an exception and an error message
> indicating the problem (another option would be to refuse the injection with
> a proper error message).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-11507) Field injection should not inject static and final fields and methods
[
https://issues.apache.org/jira/browse/SLING-11507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated SLING-11507:
-
Summary: Field injection should not inject static and final fields and
methods (was: Field injection should not inject static/final fields and
methods)
> Field injection should not inject static and final fields and methods
> -
>
> Key: SLING-11507
> URL: https://issues.apache.org/jira/browse/SLING-11507
> Project: Sling
> Issue Type: Bug
> Components: Sling Models
>Affects Versions: Models Impl 1.4.14
>Reporter: Joerg Hoh
>Assignee: Dirk Rudolph
>Priority: Critical
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Currently this injection works:
> {noformat}
> @SlingObject
> private static ResourceResolver resourceResolver;
> {noformat}
> but it should not. Sling Models are Pojos and injection must never inject
> into static fields. Instead it should throw an exception and an error message
> indicating the problem (another option would be to refuse the injection with
> a proper error message).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-11507) Field injection should not inject static/final fields and methods
[
https://issues.apache.org/jira/browse/SLING-11507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated SLING-11507:
-
Summary: Field injection should not inject static/final fields and methods
(was: Field injection should not inject static fields)
> Field injection should not inject static/final fields and methods
> -
>
> Key: SLING-11507
> URL: https://issues.apache.org/jira/browse/SLING-11507
> Project: Sling
> Issue Type: Bug
> Components: Sling Models
>Affects Versions: Models Impl 1.4.14
>Reporter: Joerg Hoh
>Assignee: Dirk Rudolph
>Priority: Critical
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Currently this injection works:
> {noformat}
> @SlingObject
> private static ResourceResolver resourceResolver;
> {noformat}
> but it should not. Sling Models are Pojos and injection must never inject
> into static fields. Instead it should throw an exception and an error message
> indicating the problem (another option would be to refuse the injection with
> a proper error message).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-11507) Field injection should not inject static fields
[
https://issues.apache.org/jira/browse/SLING-11507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated SLING-11507:
-
Fix Version/s: (was: Sling Models Implementation 1.5)
> Field injection should not inject static fields
> ---
>
> Key: SLING-11507
> URL: https://issues.apache.org/jira/browse/SLING-11507
> Project: Sling
> Issue Type: Bug
> Components: Sling Models
>Affects Versions: Models Impl 1.4.14
>Reporter: Joerg Hoh
>Assignee: Dirk Rudolph
>Priority: Critical
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Currently this injection works:
> {noformat}
> @SlingObject
> private static ResourceResolver resourceResolver;
> {noformat}
> but it should not. Sling Models are Pojos and injection must never inject
> into static fields. Instead it should throw an exception and an error message
> indicating the problem (another option would be to refuse the injection with
> a proper error message).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (SLING-11507) Field injection should not inject static fields
[
https://issues.apache.org/jira/browse/SLING-11507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph reassigned SLING-11507:
Assignee: Dirk Rudolph
> Field injection should not inject static fields
> ---
>
> Key: SLING-11507
> URL: https://issues.apache.org/jira/browse/SLING-11507
> Project: Sling
> Issue Type: Bug
> Components: Sling Models
>Affects Versions: Models Impl 1.4.14
>Reporter: Joerg Hoh
>Assignee: Dirk Rudolph
>Priority: Critical
> Fix For: Sling Models Implementation 1.5
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Currently this injection works:
> {noformat}
> @SlingObject
> private static ResourceResolver resourceResolver;
> {noformat}
> but it should not. Sling Models are Pojos and injection must never inject
> into static fields. Instead it should throw an exception and an error message
> indicating the problem (another option would be to refuse the injection with
> a proper error message).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11507) Field injection should not inject static fields
[
https://issues.apache.org/jira/browse/SLING-11507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630380#comment-17630380
]
Dirk Rudolph commented on SLING-11507:
--
I am wondering, if we also should fail for injections of final fields. I know
that this caused issues with injections done by the OSGI declarative service
runtime in the past.
Thoughts?
> Field injection should not inject static fields
> ---
>
> Key: SLING-11507
> URL: https://issues.apache.org/jira/browse/SLING-11507
> Project: Sling
> Issue Type: Bug
> Components: Sling Models
>Affects Versions: Models Impl 1.4.14
>Reporter: Joerg Hoh
>Priority: Critical
> Fix For: Sling Models Implementation 1.5
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently this injection works:
> {noformat}
> @SlingObject
> private static ResourceResolver resourceResolver;
> {noformat}
> but it should not. Sling Models are Pojos and injection must never inject
> into static fields. Instead it should throw an exception and an error message
> indicating the problem (another option would be to refuse the injection with
> a proper error message).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11507) Field injection should not inject static fields
[
https://issues.apache.org/jira/browse/SLING-11507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630312#comment-17630312
]
Dirk Rudolph commented on SLING-11507:
--
I don't know the full history of this either, but agree that this may have been
overlooked in the past.
I can take this up and continue on what [~rombert] already started, first
adding some ITs using the maven-invoker-plugin and adapting the annotation
processor to handle all cases.
I already added a first IT for reference in
https://github.com/apache/sling-org-apache-sling-models-api/pull/8/commits/8f1f05f69b4de2ad510c335a2e939de2c2fbb133
> Field injection should not inject static fields
> ---
>
> Key: SLING-11507
> URL: https://issues.apache.org/jira/browse/SLING-11507
> Project: Sling
> Issue Type: Bug
> Components: Sling Models
>Affects Versions: Models Impl 1.4.14
>Reporter: Joerg Hoh
>Priority: Critical
> Fix For: Sling Models Implementation 1.5
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently this injection works:
> {noformat}
> @SlingObject
> private static ResourceResolver resourceResolver;
> {noformat}
> but it should not. Sling Models are Pojos and injection must never inject
> into static fields. Instead it should throw an exception and an error message
> indicating the problem (another option would be to refuse the injection with
> a proper error message).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-10654) HTL optionally support ICU4j MessageFormat for string formatting
[
https://issues.apache.org/jira/browse/SLING-10654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph resolved SLING-10654.
--
Resolution: Fixed
> HTL optionally support ICU4j MessageFormat for string formatting
>
>
> Key: SLING-10654
> URL: https://issues.apache.org/jira/browse/SLING-10654
> Project: Sling
> Issue Type: New Feature
> Components: Scripting
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Major
> Fix For: Scripting HTL Engine 1.4.22-1.4.0
>
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> The [ICU
> MessageFormat|https://unicode-org.github.io/icu-docs/apidoc/dev/icu4j/com/ibm/icu/text/MessageFormat.html]
> provides a rich set of features compared to the currently implemented,
> simple placeholder replacement. In particular I am referring to the support
> for plural rules. Plural forms for words in combination with numbers are not
> as simple in all language as they are in English (or German), for example
> consider the following format {{\{0} result(s)}}
> ||Language||One||Few||Many||
> |English|1 result|3 results|15 results|
> |German|1 Ergebnis|3 Ergebnisse|15 Ergebnisse|
> |Czech|1 výsledek|3 výsledky|15 výsledků|
> With the ICU Message Format the above format could be modified according to a
> locale to support this
> ||Locale||Format||
> |en|{{\{0,plural, one \{# result} other \{# results|
> |de|{{\{0,plural, one \{# Ergebnis} other \{# Ergebnisse|
> |cs|{{\{0,plural, one \{# výsledek} few \{# výsledky} other \{# výsledků|
> According to the HTL specification the format option allows [to replace
> placeholders|https://github.com/adobe/htl-spec/blob/1.4/SPECIFICATION.md#122-format]
> in {{Strings}}.
> {quote}placeholders (eg: \{0}) in the pattern, triggers string formatting
> {quote}
> It does not define a specific definition of a placeholder and simply refers
> to {{\{0}}} as an example. The support of complex placeholders as described
> above should be a valid implementation detail.
> However, with only regular placeholders the overhead of parsing the format as
> ICU MessageFormat comes with a performance penalty. So it must only be used
> if the format contains at least one complex placeholder, for example
> identified by {{\{\d+,[^}]+}}}. The support can be implemented completely
> optional, depending on the existence of icu4j at runtime.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-10654) HTL optionally support ICU4j MessageFormat for string formatting
[
https://issues.apache.org/jira/browse/SLING-10654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated SLING-10654:
-
Fix Version/s: Scripting HTL Engine 1.4.22-1.4.0
> HTL optionally support ICU4j MessageFormat for string formatting
>
>
> Key: SLING-10654
> URL: https://issues.apache.org/jira/browse/SLING-10654
> Project: Sling
> Issue Type: New Feature
> Components: Scripting
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Major
> Fix For: Scripting HTL Engine 1.4.22-1.4.0
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> The [ICU
> MessageFormat|https://unicode-org.github.io/icu-docs/apidoc/dev/icu4j/com/ibm/icu/text/MessageFormat.html]
> provides a rich set of features compared to the currently implemented,
> simple placeholder replacement. In particular I am referring to the support
> for plural rules. Plural forms for words in combination with numbers are not
> as simple in all language as they are in English (or German), for example
> consider the following format {{\{0} result(s)}}
> ||Language||One||Few||Many||
> |English|1 result|3 results|15 results|
> |German|1 Ergebnis|3 Ergebnisse|15 Ergebnisse|
> |Czech|1 výsledek|3 výsledky|15 výsledků|
> With the ICU Message Format the above format could be modified according to a
> locale to support this
> ||Locale||Format||
> |en|{{\{0,plural, one \{# result} other \{# results|
> |de|{{\{0,plural, one \{# Ergebnis} other \{# Ergebnisse|
> |cs|{{\{0,plural, one \{# výsledek} few \{# výsledky} other \{# výsledků|
> According to the HTL specification the format option allows [to replace
> placeholders|https://github.com/adobe/htl-spec/blob/1.4/SPECIFICATION.md#122-format]
> in {{Strings}}.
> {quote}placeholders (eg: \{0}) in the pattern, triggers string formatting
> {quote}
> It does not define a specific definition of a placeholder and simply refers
> to {{\{0}}} as an example. The support of complex placeholders as described
> above should be a valid implementation detail.
> However, with only regular placeholders the overhead of parsing the format as
> ICU MessageFormat comes with a performance penalty. So it must only be used
> if the format contains at least one complex placeholder, for example
> identified by {{\{\d+,[^}]+}}}. The support can be implemented completely
> optional, depending on the existence of icu4j at runtime.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-11589) Processing pipeline with resourceType to check jcr:content as well
[ https://issues.apache.org/jira/browse/SLING-11589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dirk Rudolph updated SLING-11589: - Description: The ProcessorConfigurationImpl#match method currently checks the configured resourceType only on the requested resource [1]. This works as designed, however there are cases where a jcr:content child resource has a meaningful resourcetype for the rewriter and the requested resource does not. This is for example the case for AEM's cq:Pages. Requests usually are made for the cq:Page resource (resourceType being cq:Page) and not for the jcr:content. A configuration should be made available to check the jcr:content as well (similar to unwrapResource). [1] [https://github.com/apache/sling-org-apache-sling-rewriter/blob/7eb50dcd38e2e35ee597fa2e0b1fbfca0fe8b526/src/main/java/org/apache/sling/rewriter/impl/ProcessorConfigurationImpl.java#L435-L456] was: The ProcessorConfigurationImpl#match method currently checks the configured resourceType only on the requested resource [1]. This works as designed, however there are cases where a jcr:content child resource has a meaningful resourcetype for the rewriter and requested resource does not. This is for example the case for AEM's cq:Pages. Requests usually are made for the cq:Page resource (resourceType being cq:Page) and not for the jcr:content. A configuration should be made available to check the jcr:content as well (similar to unwrapResource). [1] https://github.com/apache/sling-org-apache-sling-rewriter/blob/7eb50dcd38e2e35ee597fa2e0b1fbfca0fe8b526/src/main/java/org/apache/sling/rewriter/impl/ProcessorConfigurationImpl.java#L435-L456 > Processing pipeline with resourceType to check jcr:content as well > -- > > Key: SLING-11589 > URL: https://issues.apache.org/jira/browse/SLING-11589 > Project: Sling > Issue Type: Improvement > Components: Extensions >Reporter: Dirk Rudolph >Priority: Major > Fix For: Rewriter 1.3.4 > > > The ProcessorConfigurationImpl#match method currently checks the configured > resourceType only on the requested resource [1]. This works as designed, > however there are cases where a jcr:content child resource has a meaningful > resourcetype for the rewriter and the requested resource does not. > This is for example the case for AEM's cq:Pages. Requests usually are made > for the cq:Page resource (resourceType being cq:Page) and not for the > jcr:content. > A configuration should be made available to check the jcr:content as well > (similar to unwrapResource). > > [1] > [https://github.com/apache/sling-org-apache-sling-rewriter/blob/7eb50dcd38e2e35ee597fa2e0b1fbfca0fe8b526/src/main/java/org/apache/sling/rewriter/impl/ProcessorConfigurationImpl.java#L435-L456] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (SLING-11589) Processing pipeline with resourceType to check jcr:content as well
[
https://issues.apache.org/jira/browse/SLING-11589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17608187#comment-17608187
]
Dirk Rudolph edited comment on SLING-11589 at 9/22/22 11:01 AM:
{quote}standard JCR have any special notion of {{jcr:content}} child nodes
{quote}
The jcr:content child node is an established, builtin concept of jackraabit's
nt:file.
[https://github.com/nabils/jackrabbit/blob/master/jackrabbit-core/src/main/resources/org/apache/jackrabbit/core/nodetype/builtin_nodetypes.cnd#L60-L62]
But you are right, limiting this to only "jcr:content" may infer application
specific knowledge.
On the other hand implementing this logic is not very extensible yet.
We could instead (a) define a property on the configuration which sets the sub
path the resourceType should be checked on (defaults to the requested resource
itself), or (a) we provide an extension point where applications can plug in
custom matching logic.
was (Author: diru):
{quote}standard JCR have any special notion of {{jcr:content}} child nodes
{quote}
The jcr:content child node is an established, builtin concept of jackraabit's
nt:file.
[https://github.com/nabils/jackrabbit/blob/master/jackrabbit-core/src/main/resources/org/apache/jackrabbit/core/nodetype/builtin_nodetypes.cnd#L60-L62]
But you are right, limiting this to only "jcr:content" may infer application
specific knowledge.
On the other hand implementing this logic is not very well extensible yet.
We could instead (a) define a property on the configuration which sets the sub
path the resourceType should be checked on (defaults to the requested resource
itself), or (a) we provide an extension point where applications can plug in
custom matching logic.
> Processing pipeline with resourceType to check jcr:content as well
> --
>
> Key: SLING-11589
> URL: https://issues.apache.org/jira/browse/SLING-11589
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Reporter: Dirk Rudolph
>Priority: Major
> Fix For: Rewriter 1.3.4
>
>
> The ProcessorConfigurationImpl#match method currently checks the configured
> resourceType only on the requested resource [1]. This works as designed,
> however there are cases where a jcr:content child resource has a meaningful
> resourcetype for the rewriter and requested resource does not.
> This is for example the case for AEM's cq:Pages. Requests usually are made
> for the cq:Page resource (resourceType being cq:Page) and not for the
> jcr:content.
> A configuration should be made available to check the jcr:content as well
> (similar to unwrapResource).
>
> [1]
> https://github.com/apache/sling-org-apache-sling-rewriter/blob/7eb50dcd38e2e35ee597fa2e0b1fbfca0fe8b526/src/main/java/org/apache/sling/rewriter/impl/ProcessorConfigurationImpl.java#L435-L456
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (SLING-11589) Processing pipeline with resourceType to check jcr:content as well
[
https://issues.apache.org/jira/browse/SLING-11589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17608187#comment-17608187
]
Dirk Rudolph edited comment on SLING-11589 at 9/22/22 11:01 AM:
{quote}standard JCR have any special notion of {{jcr:content}} child nodes
{quote}
The jcr:content child node is an established, builtin concept of jackraabit's
nt:file.
[https://github.com/nabils/jackrabbit/blob/master/jackrabbit-core/src/main/resources/org/apache/jackrabbit/core/nodetype/builtin_nodetypes.cnd#L60-L62]
But you are right, limiting this to only "jcr:content" may infer application
specific knowledge.
On the other hand implementing this logic is not very well extensible yet.
We could instead (a) define a property on the configuration which sets the sub
path the resourceType should be checked on (defaults to the requested resource
itself), or (a) we provide an extension point where applications can plug in
custom matching logic.
was (Author: diru):
{quote}standard JCR have any special notion of {{jcr:content}} child nodes
{quote}
The jcr:content child node is an established, builtin concept of jackraabits
nt:file.
[https://github.com/nabils/jackrabbit/blob/master/jackrabbit-core/src/main/resources/org/apache/jackrabbit/core/nodetype/builtin_nodetypes.cnd#L60-L62]
But you are right, limiting this to only "jcr:content" may infer application
specific knowledge.
On the other hand implementing this logic is not very well extensible yet.
We could instead (a) define a property on the configuration which sets the sub
path the resourceType should be checked on (defaults to the requested resource
itself), or (a) we provide an extension point where applications can plug in
custom matching logic.
> Processing pipeline with resourceType to check jcr:content as well
> --
>
> Key: SLING-11589
> URL: https://issues.apache.org/jira/browse/SLING-11589
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Reporter: Dirk Rudolph
>Priority: Major
> Fix For: Rewriter 1.3.4
>
>
> The ProcessorConfigurationImpl#match method currently checks the configured
> resourceType only on the requested resource [1]. This works as designed,
> however there are cases where a jcr:content child resource has a meaningful
> resourcetype for the rewriter and requested resource does not.
> This is for example the case for AEM's cq:Pages. Requests usually are made
> for the cq:Page resource (resourceType being cq:Page) and not for the
> jcr:content.
> A configuration should be made available to check the jcr:content as well
> (similar to unwrapResource).
>
> [1]
> https://github.com/apache/sling-org-apache-sling-rewriter/blob/7eb50dcd38e2e35ee597fa2e0b1fbfca0fe8b526/src/main/java/org/apache/sling/rewriter/impl/ProcessorConfigurationImpl.java#L435-L456
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (SLING-11589) Processing pipeline with resourceType to check jcr:content as well
[
https://issues.apache.org/jira/browse/SLING-11589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17608187#comment-17608187
]
Dirk Rudolph edited comment on SLING-11589 at 9/22/22 11:00 AM:
{quote}standard JCR have any special notion of {{jcr:content}} child nodes
{quote}
The jcr:content child node is an established, builtin concept of jackraabits
nt:file.
[https://github.com/nabils/jackrabbit/blob/master/jackrabbit-core/src/main/resources/org/apache/jackrabbit/core/nodetype/builtin_nodetypes.cnd#L60-L62]
But you are right, limiting this to only "jcr:content" may infer application
specific knowledge.
On the other hand implementing this logic is not very well extensible yet.
We could instead (a) define a property on the configuration which sets the sub
path the resourceType should be checked on (defaults to the requested resource
itself), or (a) we provide an extension point where applications can plug in
custom matching logic.
was (Author: diru):
{quote}standard JCR have any special notion of {{jcr:content}} child nodes
{quote}
The jcr:content child node is an established, builtin concept of jackraabits
nt:file.
[https://github.com/nabils/jackrabbit/blob/master/jackrabbit-core/src/main/resources/org/apache/jackrabbit/core/nodetype/builtin_nodetypes.cnd#L60-L62]
But you are right, limiting this to only "jcr:content" may infer application
specific knowledge.
On the other hand implementing this logic is not very well extensible yet.
We could instead (a) define a property on the configuration which sets the sub
path the resourceType should be checked on (defaults to the requested resource
itself), or (a) we provide an extension point where applications can plugin
custom matching logic.
> Processing pipeline with resourceType to check jcr:content as well
> --
>
> Key: SLING-11589
> URL: https://issues.apache.org/jira/browse/SLING-11589
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Reporter: Dirk Rudolph
>Priority: Major
> Fix For: Rewriter 1.3.4
>
>
> The ProcessorConfigurationImpl#match method currently checks the configured
> resourceType only on the requested resource [1]. This works as designed,
> however there are cases where a jcr:content child resource has a meaningful
> resourcetype for the rewriter and requested resource does not.
> This is for example the case for AEM's cq:Pages. Requests usually are made
> for the cq:Page resource (resourceType being cq:Page) and not for the
> jcr:content.
> A configuration should be made available to check the jcr:content as well
> (similar to unwrapResource).
>
> [1]
> https://github.com/apache/sling-org-apache-sling-rewriter/blob/7eb50dcd38e2e35ee597fa2e0b1fbfca0fe8b526/src/main/java/org/apache/sling/rewriter/impl/ProcessorConfigurationImpl.java#L435-L456
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11589) Processing pipeline with resourceType to check jcr:content as well
[
https://issues.apache.org/jira/browse/SLING-11589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17608187#comment-17608187
]
Dirk Rudolph commented on SLING-11589:
--
{quote}standard JCR have any special notion of {{jcr:content}} child nodes
{quote}
The jcr:content child node is an established, builtin concept of jackraabits
nt:file.
[https://github.com/nabils/jackrabbit/blob/master/jackrabbit-core/src/main/resources/org/apache/jackrabbit/core/nodetype/builtin_nodetypes.cnd#L60-L62]
But you are right, limiting this to only "jcr:content" may infer application
specific knowledge.
On the other hand implementing this logic is not very well extensible yet.
We could instead (a) define a property on the configuration which sets the sub
path the resourceType should be checked on (defaults to the requested resource
itself), or (a) we provide an extension point where applications can plugin
custom matching logic.
> Processing pipeline with resourceType to check jcr:content as well
> --
>
> Key: SLING-11589
> URL: https://issues.apache.org/jira/browse/SLING-11589
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Reporter: Dirk Rudolph
>Priority: Major
> Fix For: Rewriter 1.3.4
>
>
> The ProcessorConfigurationImpl#match method currently checks the configured
> resourceType only on the requested resource [1]. This works as designed,
> however there are cases where a jcr:content child resource has a meaningful
> resourcetype for the rewriter and requested resource does not.
> This is for example the case for AEM's cq:Pages. Requests usually are made
> for the cq:Page resource (resourceType being cq:Page) and not for the
> jcr:content.
> A configuration should be made available to check the jcr:content as well
> (similar to unwrapResource).
>
> [1]
> https://github.com/apache/sling-org-apache-sling-rewriter/blob/7eb50dcd38e2e35ee597fa2e0b1fbfca0fe8b526/src/main/java/org/apache/sling/rewriter/impl/ProcessorConfigurationImpl.java#L435-L456
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-11589) Processing pipeline with resourceType to check jcr:content as well
Dirk Rudolph created SLING-11589: Summary: Processing pipeline with resourceType to check jcr:content as well Key: SLING-11589 URL: https://issues.apache.org/jira/browse/SLING-11589 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Dirk Rudolph Fix For: Rewriter 1.3.4 The ProcessorConfigurationImpl#match method currently checks the configured resourceType only on the requested resource [1]. This works as designed, however there are cases where a jcr:content child resource has a meaningful resourcetype for the rewriter and requested resource does not. This is for example the case for AEM's cq:Pages. Requests usually are made for the cq:Page resource (resourceType being cq:Page) and not for the jcr:content. A configuration should be made available to check the jcr:content as well (similar to unwrapResource). [1] https://github.com/apache/sling-org-apache-sling-rewriter/blob/7eb50dcd38e2e35ee597fa2e0b1fbfca0fe8b526/src/main/java/org/apache/sling/rewriter/impl/ProcessorConfigurationImpl.java#L435-L456 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-11094) Sitemap: Move all dependencies to provided scope
[ https://issues.apache.org/jira/browse/SLING-11094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dirk Rudolph updated SLING-11094: - Component/s: Extensions > Sitemap: Move all dependencies to provided scope > > > Key: SLING-11094 > URL: https://issues.apache.org/jira/browse/SLING-11094 > Project: Sling > Issue Type: Improvement > Components: Extensions >Affects Versions: Sitemap 1.0.4, Sitemap 1.0.6 >Reporter: Konrad Windszus >Assignee: Dirk Rudolph >Priority: Minor > Labels: good-first-issue, sitemaps > Fix For: Sitemap 1.0.8 > > > All dependencies should have provided scope, as they are not relevant as > transitive dependencies. > Also the scope should mentioned explicitly in the pom.xml (and not only > inherited from parent). > Currently the following dependencies have compile scope: > # jackrabbit-jcr-commons > # org.apache.sling.commons.metrics (not sure if this is used in SPI/API) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-11094) Sitemap: Move all dependencies to provided scope
[ https://issues.apache.org/jira/browse/SLING-11094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dirk Rudolph updated SLING-11094: - Labels: good-first-issue sitemaps (was: sitemaps) > Sitemap: Move all dependencies to provided scope > > > Key: SLING-11094 > URL: https://issues.apache.org/jira/browse/SLING-11094 > Project: Sling > Issue Type: Improvement >Affects Versions: Sitemap 1.0.4, Sitemap 1.0.6 >Reporter: Konrad Windszus >Assignee: Dirk Rudolph >Priority: Minor > Labels: good-first-issue, sitemaps > Fix For: Sitemap 1.0.8 > > > All dependencies should have provided scope, as they are not relevant as > transitive dependencies. > Also the scope should mentioned explicitly in the pom.xml (and not only > inherited from parent). > Currently the following dependencies have compile scope: > # jackrabbit-jcr-commons > # org.apache.sling.commons.metrics (not sure if this is used in SPI/API) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-11451) SitemapScheduler does not schedule sitemap generation for excludePaths with empty entry
[ https://issues.apache.org/jira/browse/SLING-11451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dirk Rudolph updated SLING-11451: - Labels: good-first-issue sitemaps (was: sitemaps) > SitemapScheduler does not schedule sitemap generation for excludePaths with > empty entry > --- > > Key: SLING-11451 > URL: https://issues.apache.org/jira/browse/SLING-11451 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: Sitemap 1.0.6 >Reporter: Dirk Rudolph >Priority: Major > Labels: good-first-issue, sitemaps > > When a SitemapScheduler configuration is created using the felix web console > the excludePaths configuration property gets stored with a single empty > entry. > This causes the exclude path set to match all paths and prevents the > SitemapScheduler to schedule any sitemap generation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-11451) SitemapScheduler does not schedule sitemap generation for excludePaths with empty entry
Dirk Rudolph created SLING-11451: Summary: SitemapScheduler does not schedule sitemap generation for excludePaths with empty entry Key: SLING-11451 URL: https://issues.apache.org/jira/browse/SLING-11451 Project: Sling Issue Type: Bug Reporter: Dirk Rudolph When a SitemapScheduler configuration is created using the felix web console the excludePaths configuration property gets stored with a single empty entry. This causes the exclude path set to match all paths and prevents the SitemapScheduler to schedule any sitemap generation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-11451) SitemapScheduler does not schedule sitemap generation for excludePaths with empty entry
[ https://issues.apache.org/jira/browse/SLING-11451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dirk Rudolph updated SLING-11451: - Component/s: Extensions > SitemapScheduler does not schedule sitemap generation for excludePaths with > empty entry > --- > > Key: SLING-11451 > URL: https://issues.apache.org/jira/browse/SLING-11451 > Project: Sling > Issue Type: Bug > Components: Extensions >Reporter: Dirk Rudolph >Priority: Major > Labels: sitemaps > > When a SitemapScheduler configuration is created using the felix web console > the excludePaths configuration property gets stored with a single empty > entry. > This causes the exclude path set to match all paths and prevents the > SitemapScheduler to schedule any sitemap generation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-11451) SitemapScheduler does not schedule sitemap generation for excludePaths with empty entry
[ https://issues.apache.org/jira/browse/SLING-11451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dirk Rudolph updated SLING-11451: - Labels: sitemaps (was: ) > SitemapScheduler does not schedule sitemap generation for excludePaths with > empty entry > --- > > Key: SLING-11451 > URL: https://issues.apache.org/jira/browse/SLING-11451 > Project: Sling > Issue Type: Bug >Reporter: Dirk Rudolph >Priority: Major > Labels: sitemaps > > When a SitemapScheduler configuration is created using the felix web console > the excludePaths configuration property gets stored with a single empty > entry. > This causes the exclude path set to match all paths and prevents the > SitemapScheduler to schedule any sitemap generation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-11451) SitemapScheduler does not schedule sitemap generation for excludePaths with empty entry
[ https://issues.apache.org/jira/browse/SLING-11451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dirk Rudolph updated SLING-11451: - Affects Version/s: Sitemap 1.0.6 > SitemapScheduler does not schedule sitemap generation for excludePaths with > empty entry > --- > > Key: SLING-11451 > URL: https://issues.apache.org/jira/browse/SLING-11451 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: Sitemap 1.0.6 >Reporter: Dirk Rudolph >Priority: Major > Labels: sitemaps > > When a SitemapScheduler configuration is created using the felix web console > the excludePaths configuration property gets stored with a single empty > entry. > This causes the exclude path set to match all paths and prevents the > SitemapScheduler to schedule any sitemap generation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-11383) Configuration API validation fails for internal names with LENIENT mode
[
https://issues.apache.org/jira/browse/SLING-11383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph resolved SLING-11383.
--
Resolution: Fixed
> Configuration API validation fails for internal names with LENIENT mode
> ---
>
> Key: SLING-11383
> URL: https://issues.apache.org/jira/browse/SLING-11383
> Project: Sling
> Issue Type: Bug
> Components: Feature Model Analyser
>Affects Versions: Feature Model API Regions Extension 1.6.0
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Major
> Fix For: Feature Model API Regions Extension 1.6.2
>
>
> Consider the following configuration-api
> {code}
> "configuration-api:JSON": {
> "factory-configurations": {
> "my.service.pid": {
> "mode": "LENIENT",
> "region": "GLOBAL",
> "internal-names": [
> "default"
> ]
> }
> }
> {code}
> As a user I would expect to get a warning when I have a configuration
> {{my.service.pid~default}} in my project, but the actual result is an error.
> {code}
> Configuration my.service.pid~default: Factory configuration with name is not
> allowed
> {code}
> The reason for that is that the
> [FeatureValidator|https://github.com/apache/sling-org-apache-sling-feature-extension-apiregions/blob/org.apache.sling.feature.extension.apiregions-1.6.0/src/main/java/org/apache/sling/feature/extension/apiregions/api/config/validation/FeatureValidator.java#L156]
> does not use the configuration description's validation mode but the one of
> the ConfigurationApi.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (SLING-11383) Configuration API validation fails for internal names with LENIENT mode
[
https://issues.apache.org/jira/browse/SLING-11383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated SLING-11383:
-
Fix Version/s: Feature Model API Regions Extension 1.6.2
> Configuration API validation fails for internal names with LENIENT mode
> ---
>
> Key: SLING-11383
> URL: https://issues.apache.org/jira/browse/SLING-11383
> Project: Sling
> Issue Type: Bug
> Components: Feature Model Analyser
>Affects Versions: Feature Model API Regions Extension 1.6.0
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Major
> Fix For: Feature Model API Regions Extension 1.6.2
>
>
> Consider the following configuration-api
> {code}
> "configuration-api:JSON": {
> "factory-configurations": {
> "my.service.pid": {
> "mode": "LENIENT",
> "region": "GLOBAL",
> "internal-names": [
> "default"
> ]
> }
> }
> {code}
> As a user I would expect to get a warning when I have a configuration
> {{my.service.pid~default}} in my project, but the actual result is an error.
> {code}
> Configuration my.service.pid~default: Factory configuration with name is not
> allowed
> {code}
> The reason for that is that the
> [FeatureValidator|https://github.com/apache/sling-org-apache-sling-feature-extension-apiregions/blob/org.apache.sling.feature.extension.apiregions-1.6.0/src/main/java/org/apache/sling/feature/extension/apiregions/api/config/validation/FeatureValidator.java#L156]
> does not use the configuration description's validation mode but the one of
> the ConfigurationApi.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (SLING-11383) Configuration API validation fails for internal names with LENIENT mode
[
https://issues.apache.org/jira/browse/SLING-11383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph reassigned SLING-11383:
Assignee: Dirk Rudolph
> Configuration API validation fails for internal names with LENIENT mode
> ---
>
> Key: SLING-11383
> URL: https://issues.apache.org/jira/browse/SLING-11383
> Project: Sling
> Issue Type: Bug
> Components: Feature Model Analyser
>Affects Versions: Feature Model API Regions Extension 1.6.0
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Major
>
> Consider the following configuration-api
> {code}
> "configuration-api:JSON": {
> "factory-configurations": {
> "my.service.pid": {
> "mode": "LENIENT",
> "region": "GLOBAL",
> "internal-names": [
> "default"
> ]
> }
> }
> {code}
> As a user I would expect to get a warning when I have a configuration
> {{my.service.pid~default}} in my project, but the actual result is an error.
> {code}
> Configuration my.service.pid~default: Factory configuration with name is not
> allowed
> {code}
> The reason for that is that the
> [FeatureValidator|https://github.com/apache/sling-org-apache-sling-feature-extension-apiregions/blob/org.apache.sling.feature.extension.apiregions-1.6.0/src/main/java/org/apache/sling/feature/extension/apiregions/api/config/validation/FeatureValidator.java#L156]
> does not use the configuration description's validation mode but the one of
> the ConfigurationApi.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (SLING-11383) Configuration API validation fails for internal names with LENIENT mode
[
https://issues.apache.org/jira/browse/SLING-11383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17551517#comment-17551517
]
Dirk Rudolph edited comment on SLING-11383 at 6/8/22 10:29 AM:
---
Wouldn't it be as simple as taking the validation mode from the
FactoryConfigurationDescription and if not set falling back to the one defined
for the ConfigurationApi? This would be the same pattern that I see in the
[ConfigurationValidator|https://github.com/apache/sling-org-apache-sling-feature-extension-apiregions/blob/4f871d436dd3f8b500f0f690342d8e3b7e7c5897/src/main/java/org/apache/sling/feature/extension/apiregions/api/config/validation/ConfigurationValidator.java#L103],
or am I missing something here?
was (Author: diru):
Wouldn't it be simple as taking the validation mode from the
FactoryConfigurationDescription and if not set falling back to the one defined
for the ConfigurationApi? This would be the same pattern that I see in the
[ConfigurationValidator|https://github.com/apache/sling-org-apache-sling-feature-extension-apiregions/blob/4f871d436dd3f8b500f0f690342d8e3b7e7c5897/src/main/java/org/apache/sling/feature/extension/apiregions/api/config/validation/ConfigurationValidator.java#L103],
or am I missing something here?
> Configuration API validation fails for internal names with LENIENT mode
> ---
>
> Key: SLING-11383
> URL: https://issues.apache.org/jira/browse/SLING-11383
> Project: Sling
> Issue Type: Bug
> Components: Feature Model Analyser
>Affects Versions: Feature Model API Regions Extension 1.6.0
>Reporter: Dirk Rudolph
>Priority: Major
>
> Consider the following configuration-api
> {code}
> "configuration-api:JSON": {
> "factory-configurations": {
> "my.service.pid": {
> "mode": "LENIENT",
> "region": "GLOBAL",
> "internal-names": [
> "default"
> ]
> }
> }
> {code}
> As a user I would expect to get a warning when I have a configuration
> {{my.service.pid~default}} in my project, but the actual result is an error.
> {code}
> Configuration my.service.pid~default: Factory configuration with name is not
> allowed
> {code}
> The reason for that is that the
> [FeatureValidator|https://github.com/apache/sling-org-apache-sling-feature-extension-apiregions/blob/org.apache.sling.feature.extension.apiregions-1.6.0/src/main/java/org/apache/sling/feature/extension/apiregions/api/config/validation/FeatureValidator.java#L156]
> does not use the configuration description's validation mode but the one of
> the ConfigurationApi.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (SLING-11383) Configuration API validation fails for internal names with LENIENT mode
[
https://issues.apache.org/jira/browse/SLING-11383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17551517#comment-17551517
]
Dirk Rudolph commented on SLING-11383:
--
Wouldn't it be simple as taking the validation mode from the
FactoryConfigurationDescription and if not set falling back to the one defined
for the ConfigurationApi? This would be the same pattern that I see in the
[ConfigurationValidator|https://github.com/apache/sling-org-apache-sling-feature-extension-apiregions/blob/4f871d436dd3f8b500f0f690342d8e3b7e7c5897/src/main/java/org/apache/sling/feature/extension/apiregions/api/config/validation/ConfigurationValidator.java#L103],
or am I missing something here?
> Configuration API validation fails for internal names with LENIENT mode
> ---
>
> Key: SLING-11383
> URL: https://issues.apache.org/jira/browse/SLING-11383
> Project: Sling
> Issue Type: Bug
> Components: Feature Model Analyser
>Affects Versions: Feature Model API Regions Extension 1.6.0
>Reporter: Dirk Rudolph
>Priority: Major
>
> Consider the following configuration-api
> {code}
> "configuration-api:JSON": {
> "factory-configurations": {
> "my.service.pid": {
> "mode": "LENIENT",
> "region": "GLOBAL",
> "internal-names": [
> "default"
> ]
> }
> }
> {code}
> As a user I would expect to get a warning when I have a configuration
> {{my.service.pid~default}} in my project, but the actual result is an error.
> {code}
> Configuration my.service.pid~default: Factory configuration with name is not
> allowed
> {code}
> The reason for that is that the
> [FeatureValidator|https://github.com/apache/sling-org-apache-sling-feature-extension-apiregions/blob/org.apache.sling.feature.extension.apiregions-1.6.0/src/main/java/org/apache/sling/feature/extension/apiregions/api/config/validation/FeatureValidator.java#L156]
> does not use the configuration description's validation mode but the one of
> the ConfigurationApi.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (SLING-11383) Configuration API validation fails for internal names with LENIENT mode
[
https://issues.apache.org/jira/browse/SLING-11383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated SLING-11383:
-
Summary: Configuration API validation fails for internal names with LENIENT
mode (was: Configuration API fails validation of internal names with LENIENT
mode)
> Configuration API validation fails for internal names with LENIENT mode
> ---
>
> Key: SLING-11383
> URL: https://issues.apache.org/jira/browse/SLING-11383
> Project: Sling
> Issue Type: Bug
> Components: Feature Model Analyser
>Affects Versions: Feature Model API Regions Extension 1.6.0
>Reporter: Dirk Rudolph
>Priority: Major
>
> Consider the following configuration-api
> {code}
> "configuration-api:JSON": {
> "factory-configurations": {
> "my.service.pid": {
> "mode": "LENIENT",
> "region": "GLOBAL",
> "internal-names": [
> "default"
> ]
> }
> }
> {code}
> As a user I would expect to get a warning when I have a configuration
> {{my.service.pid~default}} in my project, but the actual result is an error.
> {code}
> Configuration my.service.pid~default: Factory configuration with name is not
> allowed
> {code}
> The reason for that is that the
> [FeatureValidator|https://github.com/apache/sling-org-apache-sling-feature-extension-apiregions/blob/org.apache.sling.feature.extension.apiregions-1.6.0/src/main/java/org/apache/sling/feature/extension/apiregions/api/config/validation/FeatureValidator.java#L156]
> does not use the configuration description's validation mode but the one of
> the ConfigurationApi.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (SLING-11383) Configuration API fails validation of internal names with LENIENT mode
Dirk Rudolph created SLING-11383:
Summary: Configuration API fails validation of internal names with
LENIENT mode
Key: SLING-11383
URL: https://issues.apache.org/jira/browse/SLING-11383
Project: Sling
Issue Type: Bug
Components: Feature Model Analyser
Affects Versions: Feature Model API Regions Extension 1.6.0
Reporter: Dirk Rudolph
Consider the following configuration-api
{code}
"configuration-api:JSON": {
"factory-configurations": {
"my.service.pid": {
"mode": "LENIENT",
"region": "GLOBAL",
"internal-names": [
"default"
]
}
}
{code}
As a user I would expect to get a warning when I have a configuration
{{my.service.pid~default}} in my project, but the actual result is an error.
{code}
Configuration my.service.pid~default: Factory configuration with name is not
allowed
{code}
The reason for that is that the
[FeatureValidator|https://github.com/apache/sling-org-apache-sling-feature-extension-apiregions/blob/org.apache.sling.feature.extension.apiregions-1.6.0/src/main/java/org/apache/sling/feature/extension/apiregions/api/config/validation/FeatureValidator.java#L156]
does not use the configuration description's validation mode but the one of
the ConfigurationApi.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (SLING-9036) Sling Models: SlingHttpServletRequestWrapper.adaptTo() unwraps before adapting
[
https://issues.apache.org/jira/browse/SLING-9036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated SLING-9036:
Fix Version/s: Models Implementation 1.5.4
(was: Models Implementation 1.5.2)
> Sling Models: SlingHttpServletRequestWrapper.adaptTo() unwraps before adapting
> --
>
> Key: SLING-9036
> URL: https://issues.apache.org/jira/browse/SLING-9036
> Project: Sling
> Issue Type: New Feature
> Components: Sling Models
>Reporter: Henry Kuijpers
>Priority: Major
> Fix For: Models Implementation 1.5.4
>
>
> Sling Model:
> {code:java}
> @Model(adaptables = SlingHttpServletRequest.class, adapters =
> MySlingModel.class)
> class MySlingModel {
> @Inject
> public MySlingModel(@Self SlingHttpServletRequest req) {
> logger.log(req.getResourceBundle().getClass().getName());
> }
> }
> {code}
> Calling code:
> {code:java}
> // req obtained via JSP/HTL
> final SlingHttpServletRequest myWrappedReq = new
> SlingHttpServletRequestWrapper(req) {
> @Override
> public ResourceBundle getResourceBundle() {
> return new MyCustomResourceBundle();
> }
> };
>
> final MySlingModel myModel = myWrappedReq.adaptTo(MySlingModel.class);
> {code}
> I would expect the log file to contain "MyCustomResourceBundle". Instead it
> contains "NullResourceBundle".
> This is because the request is being "unwrapped" when doing the adaptTo()
> call: It keeps on delegating to the wrapped request. This should not have
> happened, i.e. how can we otherwise overwrite (parts of) requests and
> resources?
> See also:
> [https://github.com/apache/sling-org-apache-sling-api/blob/master/src/main/java/org/apache/sling/api/wrappers/SlingHttpServletRequestWrapper.java#L147]
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (SLING-11029) OSGiServiceInjector.getService() should rely on framework
[ https://issues.apache.org/jira/browse/SLING-11029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dirk Rudolph updated SLING-11029: - Fix Version/s: Models Implementation 1.5.4 (was: Models Implementation 1.5.2) > OSGiServiceInjector.getService() should rely on framework > - > > Key: SLING-11029 > URL: https://issues.apache.org/jira/browse/SLING-11029 > Project: Sling > Issue Type: Improvement > Components: Sling Models >Affects Versions: Models Implementation 1.5.0 >Reporter: Carsten Ziegeler >Priority: Major > Fix For: Models Implementation 1.5.4 > > > Looking at > https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/injectors/OSGiServiceInjector.java#L102 > it seems to get all service references, sort them and then uses the one with > the highest ranking. > However BundleContext#getServiceReference() does exactly that, so it can be > directly used -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (SLING-9674) Allow SlingHttpServletRequest based adaptations for ChildResourceInjector
[
https://issues.apache.org/jira/browse/SLING-9674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated SLING-9674:
Fix Version/s: Models Implementation 1.5.4
(was: Models Implementation 1.5.2)
> Allow SlingHttpServletRequest based adaptations for ChildResourceInjector
> -
>
> Key: SLING-9674
> URL: https://issues.apache.org/jira/browse/SLING-9674
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: Models Implementation 1.5.4
>
>
> The {{ChildResourceInjector}} always returns one/multiple Resource objects
> which makes it impossible to use those return values with another Sling Model
> requiring the adaptable {{SlingHttpServletRequest}}.
> A solution from ACS Commons introduced
> https://adobe-consulting-services.github.io/acs-aem-commons/features/sling-model-injectors/child-resource-from-request/index.html
> in https://github.com/Adobe-Consulting-Services/acs-aem-commons/pull/1920.
> There should be a solution built into Sling which allows for easier Sling
> Model aggregation.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (SLING-11258) SitemapScheduler does not schedule execution if the searchPath is the sitemap root
Dirk Rudolph created SLING-11258: Summary: SitemapScheduler does not schedule execution if the searchPath is the sitemap root Key: SLING-11258 URL: https://issues.apache.org/jira/browse/SLING-11258 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Sitemap 1.0.6 Reporter: Dirk Rudolph When configuring a SitemapScheduler's searchPath to point to a sitemap root the sitemap generation is not scheduled for that root but only it's nested roots. This is mainly due to the [SitemapUtil#findSitemapRoots()|https://github.com/apache/sling-org-apache-sling-sitemap/blob/master/src/main/java/org/apache/sling/sitemap/SitemapUtil.java#L225-L234] filtering out the given searchPath. While this was done intentionally it is hard to understand for the user. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (SLING-11248) Post empty body should fail gracefully
[
https://issues.apache.org/jira/browse/SLING-11248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph reassigned SLING-11248:
Assignee: (was: Dirk Rudolph)
> Post empty body should fail gracefully
> --
>
> Key: SLING-11248
> URL: https://issues.apache.org/jira/browse/SLING-11248
> Project: Sling
> Issue Type: Bug
> Components: GraphQL
>Affects Versions: GraphQL Core 0.0.12
>Reporter: Thierry Ygé
>Priority: Major
>
> We observed following stacktrace, while this is apparently produced by some
> bot YandexBot, it seems that if an empty body is sent, it fails with 500,
> while it should gracefully fail with 400 instead.
> {code:java}
> 02.04.2022 15:43:06.848 *ERROR* [77.88.5.82 [1648914186845] POST
> /content/some_endpoint.json HTTP/1.1]
> org.apache.sling.engine.impl.SlingRequestProcessorImpl service: Uncaught
> Throwable
> at
> org.apache.sling.graphql.core.servlet.QueryParser.fromRequest(QueryParser.java:85)
> [org.apache.sling.graphql.core:0.0.12]
> at
> org.apache.sling.graphql.core.servlet.GraphQLServlet.execute(GraphQLServlet.java:304)
> [org.apache.sling.graphql.core:0.0.12]
> at
> org.apache.sling.graphql.core.servlet.GraphQLServlet.doPost(GraphQLServlet.java:273)
> [org.apache.sling.graphql.core:0.0.12]
> {code}
> cc [~radu]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (SLING-11197) GraphQLServlet cache hit rate metric produces invalid json
[
https://issues.apache.org/jira/browse/SLING-11197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph resolved SLING-11197.
--
Resolution: Fixed
> GraphQLServlet cache hit rate metric produces invalid json
> --
>
> Key: SLING-11197
> URL: https://issues.apache.org/jira/browse/SLING-11197
> Project: Sling
> Issue Type: Bug
> Components: GraphQL
>Affects Versions: GraphQL Core 0.0.12
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Major
> Fix For: GraphQL Core 0.0.14
>
>
> The GraphQLServlet may produce a NaN for the cache hit rate metric resulting
> in a hard to parse json.
>
> {code:java}
> "sling:org.apache.sling.graphql.core.servlet.GraphQLServlet.rt:my/rt.m:GET_POST.e:json.cache_hit_rate":
> {
> "value": NaN
> }{code}
> NaN is not an allowed value according to https://www.json.org/json-en.html
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SLING-11197) GraphQLServlet cache hit rate metric produces invalid json
[
https://issues.apache.org/jira/browse/SLING-11197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated SLING-11197:
-
Fix Version/s: GraphQL Core 0.0.14
> GraphQLServlet cache hit rate metric produces invalid json
> --
>
> Key: SLING-11197
> URL: https://issues.apache.org/jira/browse/SLING-11197
> Project: Sling
> Issue Type: Bug
> Components: GraphQL
>Affects Versions: GraphQL Core 0.0.12
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Major
> Fix For: GraphQL Core 0.0.14
>
>
> The GraphQLServlet may produce a NaN for the cache hit rate metric resulting
> in a hard to parse json.
>
> {code:java}
> "sling:org.apache.sling.graphql.core.servlet.GraphQLServlet.rt:my/rt.m:GET_POST.e:json.cache_hit_rate":
> {
> "value": NaN
> }{code}
> NaN is not an allowed value according to https://www.json.org/json-en.html
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (SLING-11197) GraphQLServlet cache hit rate metric produces invalid json
Dirk Rudolph created SLING-11197:
Summary: GraphQLServlet cache hit rate metric produces invalid json
Key: SLING-11197
URL: https://issues.apache.org/jira/browse/SLING-11197
Project: Sling
Issue Type: Bug
Components: GraphQL
Affects Versions: GraphQL Core 0.0.12
Reporter: Dirk Rudolph
The GraphQLServlet may produce a NaN for the cache hit rate metric resulting in
a hard to parse json.
{code:java}
"sling:org.apache.sling.graphql.core.servlet.GraphQLServlet.rt:my/rt.m:GET_POST.e:json.cache_hit_rate":
{
"value": NaN
}{code}
NaN is not an allowed value according to https://www.json.org/json-en.html
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (SLING-11197) GraphQLServlet cache hit rate metric produces invalid json
[
https://issues.apache.org/jira/browse/SLING-11197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph reassigned SLING-11197:
Assignee: Dirk Rudolph
> GraphQLServlet cache hit rate metric produces invalid json
> --
>
> Key: SLING-11197
> URL: https://issues.apache.org/jira/browse/SLING-11197
> Project: Sling
> Issue Type: Bug
> Components: GraphQL
>Affects Versions: GraphQL Core 0.0.12
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Major
>
> The GraphQLServlet may produce a NaN for the cache hit rate metric resulting
> in a hard to parse json.
>
> {code:java}
> "sling:org.apache.sling.graphql.core.servlet.GraphQLServlet.rt:my/rt.m:GET_POST.e:json.cache_hit_rate":
> {
> "value": NaN
> }{code}
> NaN is not an allowed value according to https://www.json.org/json-en.html
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (SLING-11132) Exception handling while clearing OSGiServiceReferences
[
https://issues.apache.org/jira/browse/SLING-11132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph resolved SLING-11132.
--
Resolution: Fixed
> Exception handling while clearing OSGiServiceReferences
> ---
>
> Key: SLING-11132
> URL: https://issues.apache.org/jira/browse/SLING-11132
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Affects Versions: Models Implementation 1.5.0
>Reporter: Sagar Miglani
>Assignee: Dirk Rudolph
>Priority: Major
> Fix For: Models Implementation 1.5.2
>
> Time Spent: 5h 50m
> Remaining Estimate: 0h
>
> *"Sling Models OSGi Service Disposal Job"* to clean the OSGi service
> references does not do any error handling.
> If a ungetting of a reference [0] is failed due to some exception (like
> java.lang.IllegalStateException: Invalid BundleContext) no more references
> present in queue are cleaned up in same job trigger. The next reference in
> queue will be tried after 30 seconds (default) in next job trigger.
> Therefore, it may take an hour to clean up 120 references with an error.
> To reproduce this:
> # Create a model consisting of OSGiService Injection
> # Use this model in a page
> # Open the created page and refresh it couple of time (10-15)
> # Restart the bundle with model created in step 1
> # One may see the following exceptions in the logs (after every ~30 seconds
> to clear up the OSGi service references)
> {code:xml}
> 01.02.2021 14:31:03.639 *ERROR* [sling-default-1-Sling Models OSGi Service
> Disposal Job] org.apache.sling.commons.scheduler.impl.QuartzScheduler
> Exception during job execution of job
> 'org.apache.sling.models.impl.ModelAdapterFactory@1b834b3c' with name 'Sling
> Models OSGi Service Disposal Job' : Invalid BundleContext.
> java.lang.IllegalStateException: Invalid BundleContext.
> at
> org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:491)
> at
> org.apache.felix.framework.BundleContextImpl.ungetService(BundleContextImpl.java:455)
> at
> org.apache.sling.models.impl.injectors.OSGiServiceInjector$Callback.onDisposed(OSGiServiceInjector.java:203)
> [org.apache.sling.models.impl:1.4.16]
> at
> org.apache.sling.models.impl.ModelAdapterFactory$DisposalCallbackRegistryImpl.onDisposed(ModelAdapterFactory.java:143)
> [org.apache.sling.models.impl:1.4.16]
> at
> org.apache.sling.models.impl.ModelAdapterFactory.clearDisposalCallbackRegistryQueue(ModelAdapterFactory.java:214)
> [org.apache.sling.models.impl:1.4.16]
> at
> org.apache.sling.models.impl.ModelAdapterFactory.run(ModelAdapterFactory.java:206)
> [org.apache.sling.models.impl:1.4.16]
> at
> org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:349)
> [org.apache.sling.commons.scheduler:2.7.12]
> at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
> [org.apache.sling.commons.scheduler:2.7.12]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> {code}
> [0]:
> https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/injectors/OSGiServiceInjector.java#L207
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (SLING-11196) Update Sling Bundle Parent to latest version
[ https://issues.apache.org/jira/browse/SLING-11196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dirk Rudolph resolved SLING-11196. -- Resolution: Fixed > Update Sling Bundle Parent to latest version > > > Key: SLING-11196 > URL: https://issues.apache.org/jira/browse/SLING-11196 > Project: Sling > Issue Type: Task > Components: Sling Models >Reporter: Dirk Rudolph >Assignee: Dirk Rudolph >Priority: Major > Fix For: Models API 1.4.2, Models Implementation 1.5.2 > > Time Spent: 40m > Remaining Estimate: 0h > > We should update the bundle parent of models impl and models api to the > latest version (47). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SLING-11132) Exception handling while clearing OSGiServiceReferences
[
https://issues.apache.org/jira/browse/SLING-11132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated SLING-11132:
-
Fix Version/s: Models Implementation 1.5.2
> Exception handling while clearing OSGiServiceReferences
> ---
>
> Key: SLING-11132
> URL: https://issues.apache.org/jira/browse/SLING-11132
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Affects Versions: Models Implementation 1.5.0
>Reporter: Sagar Miglani
>Assignee: Dirk Rudolph
>Priority: Major
> Fix For: Models Implementation 1.5.2
>
> Time Spent: 5h 20m
> Remaining Estimate: 0h
>
> *"Sling Models OSGi Service Disposal Job"* to clean the OSGi service
> references does not do any error handling.
> If a ungetting of a reference [0] is failed due to some exception (like
> java.lang.IllegalStateException: Invalid BundleContext) no more references
> present in queue are cleaned up in same job trigger. The next reference in
> queue will be tried after 30 seconds (default) in next job trigger.
> Therefore, it may take an hour to clean up 120 references with an error.
> To reproduce this:
> # Create a model consisting of OSGiService Injection
> # Use this model in a page
> # Open the created page and refresh it couple of time (10-15)
> # Restart the bundle with model created in step 1
> # One may see the following exceptions in the logs (after every ~30 seconds
> to clear up the OSGi service references)
> {code:xml}
> 01.02.2021 14:31:03.639 *ERROR* [sling-default-1-Sling Models OSGi Service
> Disposal Job] org.apache.sling.commons.scheduler.impl.QuartzScheduler
> Exception during job execution of job
> 'org.apache.sling.models.impl.ModelAdapterFactory@1b834b3c' with name 'Sling
> Models OSGi Service Disposal Job' : Invalid BundleContext.
> java.lang.IllegalStateException: Invalid BundleContext.
> at
> org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:491)
> at
> org.apache.felix.framework.BundleContextImpl.ungetService(BundleContextImpl.java:455)
> at
> org.apache.sling.models.impl.injectors.OSGiServiceInjector$Callback.onDisposed(OSGiServiceInjector.java:203)
> [org.apache.sling.models.impl:1.4.16]
> at
> org.apache.sling.models.impl.ModelAdapterFactory$DisposalCallbackRegistryImpl.onDisposed(ModelAdapterFactory.java:143)
> [org.apache.sling.models.impl:1.4.16]
> at
> org.apache.sling.models.impl.ModelAdapterFactory.clearDisposalCallbackRegistryQueue(ModelAdapterFactory.java:214)
> [org.apache.sling.models.impl:1.4.16]
> at
> org.apache.sling.models.impl.ModelAdapterFactory.run(ModelAdapterFactory.java:206)
> [org.apache.sling.models.impl:1.4.16]
> at
> org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:349)
> [org.apache.sling.commons.scheduler:2.7.12]
> at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
> [org.apache.sling.commons.scheduler:2.7.12]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> {code}
> [0]:
> https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/injectors/OSGiServiceInjector.java#L207
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (SLING-11132) Exception handling while clearing OSGiServiceReferences
[
https://issues.apache.org/jira/browse/SLING-11132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph reassigned SLING-11132:
Assignee: Dirk Rudolph
> Exception handling while clearing OSGiServiceReferences
> ---
>
> Key: SLING-11132
> URL: https://issues.apache.org/jira/browse/SLING-11132
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Affects Versions: Models Implementation 1.5.0
>Reporter: Sagar Miglani
>Assignee: Dirk Rudolph
>Priority: Major
> Time Spent: 5h 20m
> Remaining Estimate: 0h
>
> *"Sling Models OSGi Service Disposal Job"* to clean the OSGi service
> references does not do any error handling.
> If a ungetting of a reference [0] is failed due to some exception (like
> java.lang.IllegalStateException: Invalid BundleContext) no more references
> present in queue are cleaned up in same job trigger. The next reference in
> queue will be tried after 30 seconds (default) in next job trigger.
> Therefore, it may take an hour to clean up 120 references with an error.
> To reproduce this:
> # Create a model consisting of OSGiService Injection
> # Use this model in a page
> # Open the created page and refresh it couple of time (10-15)
> # Restart the bundle with model created in step 1
> # One may see the following exceptions in the logs (after every ~30 seconds
> to clear up the OSGi service references)
> {code:xml}
> 01.02.2021 14:31:03.639 *ERROR* [sling-default-1-Sling Models OSGi Service
> Disposal Job] org.apache.sling.commons.scheduler.impl.QuartzScheduler
> Exception during job execution of job
> 'org.apache.sling.models.impl.ModelAdapterFactory@1b834b3c' with name 'Sling
> Models OSGi Service Disposal Job' : Invalid BundleContext.
> java.lang.IllegalStateException: Invalid BundleContext.
> at
> org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:491)
> at
> org.apache.felix.framework.BundleContextImpl.ungetService(BundleContextImpl.java:455)
> at
> org.apache.sling.models.impl.injectors.OSGiServiceInjector$Callback.onDisposed(OSGiServiceInjector.java:203)
> [org.apache.sling.models.impl:1.4.16]
> at
> org.apache.sling.models.impl.ModelAdapterFactory$DisposalCallbackRegistryImpl.onDisposed(ModelAdapterFactory.java:143)
> [org.apache.sling.models.impl:1.4.16]
> at
> org.apache.sling.models.impl.ModelAdapterFactory.clearDisposalCallbackRegistryQueue(ModelAdapterFactory.java:214)
> [org.apache.sling.models.impl:1.4.16]
> at
> org.apache.sling.models.impl.ModelAdapterFactory.run(ModelAdapterFactory.java:206)
> [org.apache.sling.models.impl:1.4.16]
> at
> org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:349)
> [org.apache.sling.commons.scheduler:2.7.12]
> at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
> [org.apache.sling.commons.scheduler:2.7.12]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> {code}
> [0]:
> https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/injectors/OSGiServiceInjector.java#L207
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (SLING-11196) Update Sling Bundle Parent to latest version
[ https://issues.apache.org/jira/browse/SLING-11196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dirk Rudolph reassigned SLING-11196: Assignee: Dirk Rudolph > Update Sling Bundle Parent to latest version > > > Key: SLING-11196 > URL: https://issues.apache.org/jira/browse/SLING-11196 > Project: Sling > Issue Type: Task > Components: Sling Models >Reporter: Dirk Rudolph >Assignee: Dirk Rudolph >Priority: Major > Fix For: Models API 1.4.2, Models Implementation 1.5.2 > > > We should update the bundle parent of models impl and models api to the > latest version (47). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (SLING-11196) Update Sling Bundle Parent to latest version
Dirk Rudolph created SLING-11196: Summary: Update Sling Bundle Parent to latest version Key: SLING-11196 URL: https://issues.apache.org/jira/browse/SLING-11196 Project: Sling Issue Type: Task Components: Sling Models Reporter: Dirk Rudolph Fix For: Models API 1.4.2, Models Implementation 1.5.2 We should update the bundle parent of models impl and models api to the latest version (47). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SLING-8706) Injections for java.util.Optional<> should be automatic optional
[
https://issues.apache.org/jira/browse/SLING-8706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated SLING-8706:
Fix Version/s: Models Implementation 1.5.2
> Injections for java.util.Optional<> should be automatic optional
> -
>
> Key: SLING-8706
> URL: https://issues.apache.org/jira/browse/SLING-8706
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: Models Implementation 1.5.2
>
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> The current approach to support optional injections requires to annotate the
> field with {{@Optional}} plus proper handling within the javacode (null
> checks etc), which can be forgotten.
> So instead of
> {code}
> @Inject @Optional
> String fieldname;
> {code}
> it should also be possible to use this
> {code}
> @Inject
> Optional fieldname;
> {code}
> with the very same semantic. But the developer is forced to deal with the
> case that the value is not present.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (SLING-11133) Cache model for its implementation type
[
https://issues.apache.org/jira/browse/SLING-11133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph resolved SLING-11133.
--
Resolution: Fixed
> Cache model for its implementation type
> ---
>
> Key: SLING-11133
> URL: https://issues.apache.org/jira/browse/SLING-11133
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Major
> Fix For: Models Implementation 1.5.2
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Currently the ModelAdapterFactory caches a cacheable model for the requested
> type only
> [https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L430-L432]
> {code:java}
> if (result.wasSuccessful() && modelAnnotation.cache() && adaptableCache !=
> null) {
> adaptableCache.put(requestedType, new
> SoftReference(result.getValue()));
> }
> {code}
> However, if a model is an adapter of multiple types an instance of it can
> also be returned for more than just the requested type.
> {code:java}
> interface AdapterType1 {}
> interface AdapterType2 {}
> @Model(adaptables = Resource.class, adapterType={AdapterType1.class,
> AdapterType2.class}, cache = true)
> class Model implements AdapterType1, AdapterType2 {}
> assertSame(resource.adaptTo(Model.class),
> resouce.adaptTo(AdapterType1.class));
> assertSame(resource.adaptTo(AdapterType1.class),
> resouce.adaptTo(AdapterType2.class));
> {code}
> While it is not save to cache the model for all of its adapter types (see
> SLING-11074), it is certainly save to cache the Model for its implementation
> type.
> In fact, when caching the Model for the implementation type, caching it for
> the requested type is redundant. This is based on the assumption that the
> {{org.apache.sling.models.impl.AdapterImplementations#lookup()}} always
> returns the same implementation for given adapterType and adaptable.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (SLING-11138) Fix MockedResourceResolverImplTest#testMapping tests
[
https://issues.apache.org/jira/browse/SLING-11138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph resolved SLING-11138.
--
Resolution: Fixed
> Fix MockedResourceResolverImplTest#testMapping tests
>
>
> Key: SLING-11138
> URL: https://issues.apache.org/jira/browse/SLING-11138
> Project: Sling
> Issue Type: Improvement
> Components: ResourceResolver
>Affects Versions: Resource Resolver 1.8.2
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Major
> Fix For: Resource Resolver 1.8.6
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Currently the MockedResourceResolverImplTest tests do not initialise the
> MapEntries correctly because this fails due to a missing service user mapping.
> With this the {{testMapping()}} results may be wrong.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SLING-11138) Fix MockedResourceResolverImplTest#testMapping tests
[
https://issues.apache.org/jira/browse/SLING-11138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated SLING-11138:
-
Fix Version/s: Resource Resolver 1.8.6
> Fix MockedResourceResolverImplTest#testMapping tests
>
>
> Key: SLING-11138
> URL: https://issues.apache.org/jira/browse/SLING-11138
> Project: Sling
> Issue Type: Improvement
> Components: ResourceResolver
>Affects Versions: Resource Resolver 1.8.2
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Major
> Fix For: Resource Resolver 1.8.6
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Currently the MockedResourceResolverImplTest tests do not initialise the
> MapEntries correctly because this fails due to a missing service user mapping.
> With this the {{testMapping()}} results may be wrong.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (SLING-11138) Fix MockedResourceResolverImplTest#testMapping tests
[
https://issues.apache.org/jira/browse/SLING-11138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph reassigned SLING-11138:
Assignee: Dirk Rudolph
> Fix MockedResourceResolverImplTest#testMapping tests
>
>
> Key: SLING-11138
> URL: https://issues.apache.org/jira/browse/SLING-11138
> Project: Sling
> Issue Type: Improvement
> Components: ResourceResolver
>Affects Versions: Resource Resolver 1.8.2
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Major
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Currently the MockedResourceResolverImplTest tests do not initialise the
> MapEntries correctly because this fails due to a missing service user mapping.
> With this the {{testMapping()}} results may be wrong.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (SLING-4856) Resource resolution fails when mapped path is not normalised
[
https://issues.apache.org/jira/browse/SLING-4856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph resolved SLING-4856.
-
Resolution: Cannot Reproduce
I cannot reproduce that anymore, it seems to work now.
I tried this with the following mapping entry instead
{code}
/etc/map/http/my-site
sling:math="domaing.\\d+"
sling:internalRedirect="[/,/content/domain]"
{code}
If I try to resolve an existing resource everything works as expected.
If I try to resolve a non-existing resource with that I get
{{//non-existing-resource.selector1.selector2.html}}, which is properly parsed
into
{code}
selectors = [selector1, selector2]
extension = html
{code}
The resourcePath however remains
{{//non-existing-resource.selector1.selector2.html}}
> Resource resolution fails when mapped path is not normalised
>
>
> Key: SLING-4856
> URL: https://issues.apache.org/jira/browse/SLING-4856
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Affects Versions: Resource Resolver 1.1.14
>Reporter: Dirk Rudolph
>Priority: Major
>
> *Description*
> During resource resolution the resource metadata are populated with values
> used for the initialisation of the {{SlingHttpServletRequest}} in the
> {{{}SlingRequestProcessorImpl{}}}. The problem is that those metadata may be
> broken when there is a misconfigured mapping applied to the request path info.
> *How to reproduce*
> 1. Configure the {{ResourceResolverFactory}} to have a mapping
> {{{}/>/prefix{}}}.
> 2. Create a {{Resource}} /content/path/to/resource
> 3. Access the {{Resource}}
> 3 a) using /content/path/to/resource.selector1.selector2.html/suffix.html
> 3 b) using
> /prefix/content/path/to/resource.selector1.selector2.html/suffix.html
> _Expected result_
> - The path can be resolved to the {{Resource}} (/)
> - The selector string is selector1.selector2 (x)
> - The suffix is /suffix.html (/)
> _Actual result_
> In the second case (b) the selector string has a leading ".". Which causes
> the {{RequestPathInfo}} to return a {{{}String[3]{}}}, where the first entry
> is an empty {{{}String{}}}.
> *Details*
> This is caused by the following code in {{resolveInternal}}
> {code:java}
> final String path = resolutionPath.toString();
> final String pathInfo = absPath.substring(path.length());
> resource.getResourceMetadata().setResolutionPath(path);
> resource.getResourceMetadata().setResolutionPathInfo(pathInfo);
> {code}
> The problem is that in this special case the resolved path starts with a "//"
> and is therefor not properly normalised. As the resolution is working
> properly and the returned resource has its path normalised the length of
> resource path part in the absPath and resoultionPath differ by one. This
> causes resoultion path info to contain the last char of the resource path
> part of the absPath, which then causes wrong interpretation and extraction of
> the selector string from the resolution path info in the {{ResourceMetaData}}
> *Use case*
> In our current project based on AEM6 we use such a path prefix to use
> separated dispatcher farms for caching. We were able to fix the internal
> issue by properly configuring the prefix but as a user i would expect Sling
> to handle this misconfigured scenario either properly or at least log a
> warning that the mapped path is not normalised because debugging it was a
> little bit tricky.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] (SLING-4856) Resource resolution fails when mapped path is not normalised
[ https://issues.apache.org/jira/browse/SLING-4856 ]
Dirk Rudolph deleted comment on SLING-4856:
-
was (Author: diru):
Another area where this happens is with /etc/map entries that use
{{sling:match}}, for example:
{code}
/etc/map/http/my-site
+ sling:math = "domain.\\d.+"
+ sling:internalRedirect="[/,/content/domain]"
{code}
In this case the map entry is "partially" correct, meaning it resolves well for
paths in /content/domain but not for paths in /, for example:
{code}
http://domain/us/en.html => /content/domain/us/en.html (if
/content/domain/us/en exists)
http://domain/etc.ext/suffix.js => //etc.ext/suffix.js (if neither /etc nor
/contnet/domain/etc exist)
{code}
> Resource resolution fails when mapped path is not normalised
>
>
> Key: SLING-4856
> URL: https://issues.apache.org/jira/browse/SLING-4856
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Affects Versions: Resource Resolver 1.1.14
>Reporter: Dirk Rudolph
>Priority: Major
>
> *Description*
> During resource resolution the resource metadata are populated with values
> used for the initialisation of the {{SlingHttpServletRequest}} in the
> {{{}SlingRequestProcessorImpl{}}}. The problem is that those metadata may be
> broken when there is a misconfigured mapping applied to the request path info.
> *How to reproduce*
> 1. Configure the {{ResourceResolverFactory}} to have a mapping
> {{{}/>/prefix{}}}.
> 2. Create a {{Resource}} /content/path/to/resource
> 3. Access the {{Resource}}
> 3 a) using /content/path/to/resource.selector1.selector2.html/suffix.html
> 3 b) using
> /prefix/content/path/to/resource.selector1.selector2.html/suffix.html
> _Expected result_
> - The path can be resolved to the {{Resource}} (/)
> - The selector string is selector1.selector2 (x)
> - The suffix is /suffix.html (/)
> _Actual result_
> In the second case (b) the selector string has a leading ".". Which causes
> the {{RequestPathInfo}} to return a {{{}String[3]{}}}, where the first entry
> is an empty {{{}String{}}}.
> *Details*
> This is caused by the following code in {{resolveInternal}}
> {code:java}
> final String path = resolutionPath.toString();
> final String pathInfo = absPath.substring(path.length());
> resource.getResourceMetadata().setResolutionPath(path);
> resource.getResourceMetadata().setResolutionPathInfo(pathInfo);
> {code}
> The problem is that in this special case the resolved path starts with a "//"
> and is therefor not properly normalised. As the resolution is working
> properly and the returned resource has its path normalised the length of
> resource path part in the absPath and resoultionPath differ by one. This
> causes resoultion path info to contain the last char of the resource path
> part of the absPath, which then causes wrong interpretation and extraction of
> the selector string from the resolution path info in the {{ResourceMetaData}}
> *Use case*
> In our current project based on AEM6 we use such a path prefix to use
> separated dispatcher farms for caching. We were able to fix the internal
> issue by properly configuring the prefix but as a user i would expect Sling
> to handle this misconfigured scenario either properly or at least log a
> warning that the mapped path is not normalised because debugging it was a
> little bit tricky.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SLING-4856) Resource resolution fails when mapped path is not normalised
[
https://issues.apache.org/jira/browse/SLING-4856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491060#comment-17491060
]
Dirk Rudolph commented on SLING-4856:
-
Another area where this happens is with /etc/map entries that use
{{sling:match}}, for example:
{code}
/etc/map/http/my-site
+ sling:math = "domain.\\d.+"
+ sling:internalRedirect="[/,/content/domain]"
{code}
In this case the map entry is "partially" correct, meaning it resolves well for
paths in /content/domain but not for paths in /, for example:
{code}
http://domain/us/en.html => /content/domain/us/en.html (if
/content/domain/us/en exists)
http://domain/etc.ext/suffix.js => //etc.ext/suffix.js (if neither /etc nor
/contnet/domain/etc exist)
{code}
> Resource resolution fails when mapped path is not normalised
>
>
> Key: SLING-4856
> URL: https://issues.apache.org/jira/browse/SLING-4856
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Affects Versions: Resource Resolver 1.1.14
>Reporter: Dirk Rudolph
>Priority: Major
>
> *Description*
> During resource resolution the resource metadata are populated with values
> used for the initialisation of the {{SlingHttpServletRequest}} in the
> {{{}SlingRequestProcessorImpl{}}}. The problem is that those metadata may be
> broken when there is a misconfigured mapping applied to the request path info.
> *How to reproduce*
> 1. Configure the {{ResourceResolverFactory}} to have a mapping
> {{{}/>/prefix{}}}.
> 2. Create a {{Resource}} /content/path/to/resource
> 3. Access the {{Resource}}
> 3 a) using /content/path/to/resource.selector1.selector2.html/suffix.html
> 3 b) using
> /prefix/content/path/to/resource.selector1.selector2.html/suffix.html
> _Expected result_
> - The path can be resolved to the {{Resource}} (/)
> - The selector string is selector1.selector2 (x)
> - The suffix is /suffix.html (/)
> _Actual result_
> In the second case (b) the selector string has a leading ".". Which causes
> the {{RequestPathInfo}} to return a {{{}String[3]{}}}, where the first entry
> is an empty {{{}String{}}}.
> *Details*
> This is caused by the following code in {{resolveInternal}}
> {code:java}
> final String path = resolutionPath.toString();
> final String pathInfo = absPath.substring(path.length());
> resource.getResourceMetadata().setResolutionPath(path);
> resource.getResourceMetadata().setResolutionPathInfo(pathInfo);
> {code}
> The problem is that in this special case the resolved path starts with a "//"
> and is therefor not properly normalised. As the resolution is working
> properly and the returned resource has its path normalised the length of
> resource path part in the absPath and resoultionPath differ by one. This
> causes resoultion path info to contain the last char of the resource path
> part of the absPath, which then causes wrong interpretation and extraction of
> the selector string from the resolution path info in the {{ResourceMetaData}}
> *Use case*
> In our current project based on AEM6 we use such a path prefix to use
> separated dispatcher farms for caching. We were able to fix the internal
> issue by properly configuring the prefix but as a user i would expect Sling
> to handle this misconfigured scenario either properly or at least log a
> warning that the mapped path is not normalised because debugging it was a
> little bit tricky.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SLING-4856) Resource resolution fails when mapped path is not normalised
[
https://issues.apache.org/jira/browse/SLING-4856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated SLING-4856:
Description:
*Description*
During resource resolution the resource metadata are populated with values used
for the initialisation of the {{SlingHttpServletRequest}} in the
{{{}SlingRequestProcessorImpl{}}}. The problem is that those metadata may be
broken when there is a misconfigured mapping applied to the request path info.
*How to reproduce*
1. Configure the {{ResourceResolverFactory}} to have a mapping
{{{}/>/prefix{}}}.
2. Create a {{Resource}} /content/path/to/resource
3. Access the {{Resource}}
3 a) using /content/path/to/resource.selector1.selector2.html/suffix.html
3 b) using /prefix/content/path/to/resource.selector1.selector2.html/suffix.html
_Expected result_
- The path can be resolved to the {{Resource}} (/)
- The selector string is selector1.selector2 (x)
- The suffix is /suffix.html (/)
_Actual result_
In the second case (b) the selector string has a leading ".". Which causes the
{{RequestPathInfo}} to return a {{{}String[3]{}}}, where the first entry is an
empty {{{}String{}}}.
*Details*
This is caused by the following code in {{resolveInternal}}
{code:java}
final String path = resolutionPath.toString();
final String pathInfo = absPath.substring(path.length());
resource.getResourceMetadata().setResolutionPath(path);
resource.getResourceMetadata().setResolutionPathInfo(pathInfo);
{code}
The problem is that in this special case the resolved path starts with a "//"
and is therefor not properly normalised. As the resolution is working properly
and the returned resource has its path normalised the length of resource path
part in the absPath and resoultionPath differ by one. This causes resoultion
path info to contain the last char of the resource path part of the absPath,
which then causes wrong interpretation and extraction of the selector string
from the resolution path info in the {{ResourceMetaData}}
*Use case*
In our current project based on AEM6 we use such a path prefix to use separated
dispatcher farms for caching. We were able to fix the internal issue by
properly configuring the prefix but as a user i would expect Sling to handle
this misconfigured scenario either properly or at least log a warning that the
mapped path is not normalised because debugging it was a little bit tricky.
was:
*Description*
During resource resolution the resource metadata are populated with values used
for the initialisation of the {{SlingHttpServletRequest}} in the
{{SlingRequestProcessorImpl}}. The problem is that those metadata may be broken
when there is a misconfigured mapping applied to the request path info.
*How to reproduce*
1. Configure the {{ResourceResolverFactory}} to have a mapping {{/>/prefix}}.
2. Create a {{Resource}} /content/path/to/resource
3. Access the {{Resource}}
3 a) using /content/path/to/resource.selector1.selector2.html/suffix.html
3 b) using /prefix/content/path/to/resource.selector1.selector2.html/suffix.html
_Expected result_
- The path can be resolved to the {{Resource}} (/)
- The selector string is selector1.selector2 (x)
- The suffix is /suffix.html (/)
_Actual result_
In the second case (b) the selector string has a leading ".". Which causes the
{{RequestPathInfo}} to return a {{String\[3\]}}, where the first entry is an
empty {{String}}.
*Details*
This is caused by the following code in {{resolveInternal}}
{code}
final String path = resolutionPath.toString();
final String pathInfo = absPath.substring(path.length());
resource.getResourceMetadata().setResolutionPath(path);
resource.getResourceMetadata().setResolutionPathInfo(pathInfo);
{code}
The problem is that in this special case the resolved path starts with a "//"
and is therefor not properly normalised. As the resolution is working properly
and returned resource has its path normalised the length of resource path part
in the absPath and resoultionPath differ by one. This causes resoultion path
info to contain the last char of the resource path part of the absPath, which
then causes wrong interpretation and extraction of the selector string from the
resolution path info in the {{ResourceMetaData}}
*Use case*
In our current project based on AEM6 we use such a path prefix to use separated
dispatcher farms for caching. We were able to fix the internal issue by
properly configuring the prefix but as a user i would expect Sling to handle
this misconfigured scenario either properly or at least log a warning that the
mapped path is not normalised because debugging it was a little bit tricky.
> Resource resolution fails when mapped path is not normalised
>
>
> Key: SLING-4856
> URL: https://issues.apache.org/jira/browse/SLING-4856
> Project: Sling
> Issue
[jira] [Updated] (SLING-4856) Resource resolution fails when mapped path is not normalised
[
https://issues.apache.org/jira/browse/SLING-4856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated SLING-4856:
Summary: Resource resolution fails when mapped path is not normalised
(was: Resource resolution breaks selector string when mapped path is not
normalised)
> Resource resolution fails when mapped path is not normalised
>
>
> Key: SLING-4856
> URL: https://issues.apache.org/jira/browse/SLING-4856
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Affects Versions: Resource Resolver 1.1.14
>Reporter: Dirk Rudolph
>Priority: Major
>
> *Description*
> During resource resolution the resource metadata are populated with values
> used for the initialisation of the {{SlingHttpServletRequest}} in the
> {{SlingRequestProcessorImpl}}. The problem is that those metadata may be
> broken when there is a misconfigured mapping applied to the request path info.
> *How to reproduce*
> 1. Configure the {{ResourceResolverFactory}} to have a mapping {{/>/prefix}}.
> 2. Create a {{Resource}} /content/path/to/resource
> 3. Access the {{Resource}}
> 3 a) using /content/path/to/resource.selector1.selector2.html/suffix.html
> 3 b) using
> /prefix/content/path/to/resource.selector1.selector2.html/suffix.html
> _Expected result_
> - The path can be resolved to the {{Resource}} (/)
> - The selector string is selector1.selector2 (x)
> - The suffix is /suffix.html (/)
> _Actual result_
> In the second case (b) the selector string has a leading ".". Which causes
> the {{RequestPathInfo}} to return a {{String\[3\]}}, where the first entry is
> an empty {{String}}.
> *Details*
> This is caused by the following code in {{resolveInternal}}
> {code}
> final String path = resolutionPath.toString();
> final String pathInfo = absPath.substring(path.length());
> resource.getResourceMetadata().setResolutionPath(path);
> resource.getResourceMetadata().setResolutionPathInfo(pathInfo);
> {code}
> The problem is that in this special case the resolved path starts with a "//"
> and is therefor not properly normalised. As the resolution is working
> properly and returned resource has its path normalised the length of resource
> path part in the absPath and resoultionPath differ by one. This causes
> resoultion path info to contain the last char of the resource path part of
> the absPath, which then causes wrong interpretation and extraction of the
> selector string from the resolution path info in the {{ResourceMetaData}}
> *Use case*
> In our current project based on AEM6 we use such a path prefix to use
> separated dispatcher farms for caching. We were able to fix the internal
> issue by properly configuring the prefix but as a user i would expect Sling
> to handle this misconfigured scenario either properly or at least log a
> warning that the mapped path is not normalised because debugging it was a
> little bit tricky.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (SLING-11138) Fix MockedResourceResolverImplTest#testMapping tests
Dirk Rudolph created SLING-11138:
Summary: Fix MockedResourceResolverImplTest#testMapping tests
Key: SLING-11138
URL: https://issues.apache.org/jira/browse/SLING-11138
Project: Sling
Issue Type: Improvement
Components: ResourceResolver
Affects Versions: Resource Resolver 1.8.2
Reporter: Dirk Rudolph
Currently the MockedResourceResolverImplTest tests do not initialise the
MapEntries correctly because this fails due to a missing service user mapping.
With this the {{testMapping()}} results may be wrong.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SLING-4856) Resource resolution breaks selector string when mapped path is not normalised
[
https://issues.apache.org/jira/browse/SLING-4856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated SLING-4856:
Priority: Major (was: Minor)
> Resource resolution breaks selector string when mapped path is not normalised
> -
>
> Key: SLING-4856
> URL: https://issues.apache.org/jira/browse/SLING-4856
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Affects Versions: Resource Resolver 1.1.14
>Reporter: Dirk Rudolph
>Priority: Major
>
> *Description*
> During resource resolution the resource metadata are populated with values
> used for the initialisation of the {{SlingHttpServletRequest}} in the
> {{SlingRequestProcessorImpl}}. The problem is that those metadata may be
> broken when there is a misconfigured mapping applied to the request path info.
> *How to reproduce*
> 1. Configure the {{ResourceResolverFactory}} to have a mapping {{/>/prefix}}.
> 2. Create a {{Resource}} /content/path/to/resource
> 3. Access the {{Resource}}
> 3 a) using /content/path/to/resource.selector1.selector2.html/suffix.html
> 3 b) using
> /prefix/content/path/to/resource.selector1.selector2.html/suffix.html
> _Expected result_
> - The path can be resolved to the {{Resource}} (/)
> - The selector string is selector1.selector2 (x)
> - The suffix is /suffix.html (/)
> _Actual result_
> In the second case (b) the selector string has a leading ".". Which causes
> the {{RequestPathInfo}} to return a {{String\[3\]}}, where the first entry is
> an empty {{String}}.
> *Details*
> This is caused by the following code in {{resolveInternal}}
> {code}
> final String path = resolutionPath.toString();
> final String pathInfo = absPath.substring(path.length());
> resource.getResourceMetadata().setResolutionPath(path);
> resource.getResourceMetadata().setResolutionPathInfo(pathInfo);
> {code}
> The problem is that in this special case the resolved path starts with a "//"
> and is therefor not properly normalised. As the resolution is working
> properly and returned resource has its path normalised the length of resource
> path part in the absPath and resoultionPath differ by one. This causes
> resoultion path info to contain the last char of the resource path part of
> the absPath, which then causes wrong interpretation and extraction of the
> selector string from the resolution path info in the {{ResourceMetaData}}
> *Use case*
> In our current project based on AEM6 we use such a path prefix to use
> separated dispatcher farms for caching. We were able to fix the internal
> issue by properly configuring the prefix but as a user i would expect Sling
> to handle this misconfigured scenario either properly or at least log a
> warning that the mapped path is not normalised because debugging it was a
> little bit tricky.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SLING-11133) Cache model for its implementation type
[
https://issues.apache.org/jira/browse/SLING-11133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated SLING-11133:
-
Description:
Currently the ModelAdapterFactory caches a cacheable model for the requested
type only
[https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L430-L432]
{code:java}
if (result.wasSuccessful() && modelAnnotation.cache() && adaptableCache !=
null) {
adaptableCache.put(requestedType, new
SoftReference(result.getValue()));
}
{code}
However, if a model is an adapter of multiple types an instance of it can also
be returned for more than just the requested type.
{code:java}
interface AdapterType1 {}
interface AdapterType2 {}
@Model(adaptables = Resource.class, adapterType={AdapterType1.class,
AdapterType2.class}, cache = true)
class Model implements AdapterType1, AdapterType2 {}
assertSame(resource.adaptTo(Model.class), resouce.adaptTo(AdapterType1.class));
assertSame(resource.adaptTo(AdapterType1.class),
resouce.adaptTo(AdapterType2.class));
{code}
While it is not save to cache the model for all of its adapter types (see
SLING-11074), it is certainly save to cache the Model for its implementation
type.
In fact, when caching the Model for the implementation type, caching it for the
requested type is redundant. This is based on the assumption that the
{{org.apache.sling.models.impl.AdapterImplementations#lookup()}} always returns
the same implementation for given adapterType and adaptable.
was:
Currently the ModelAdapterFactory caches a cacheable model for the requested
type only
https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L430-L432
{code}
if (result.wasSuccessful() && modelAnnotation.cache() && adaptableCache !=
null) {
adaptableCache.put(requestedType, new
SoftReference(result.getValue()));
}
{code}
However, if a model is an adapter of multiple types an instance of it can also
be returned for more than just the requested type.
While it is not save to cache the model for all of its adapter types (see
SLING-11074), it is certainly save to cache the Model for its implementation
type additionally to the requested type.
In fact, when caching the Model for the implementation type, caching it for the
requested type is redundant. This is based on the assumption that the
{{org.apache.sling.models.impl.AdapterImplementations#lookup()}} always returns
the same implementation for given adapterType and adaptable (considering no
newly registered ImplementationPickers interfere with it)
> Cache model for its implementation type
> ---
>
> Key: SLING-11133
> URL: https://issues.apache.org/jira/browse/SLING-11133
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Major
> Fix For: Models Implementation 1.5.2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently the ModelAdapterFactory caches a cacheable model for the requested
> type only
> [https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L430-L432]
> {code:java}
> if (result.wasSuccessful() && modelAnnotation.cache() && adaptableCache !=
> null) {
> adaptableCache.put(requestedType, new
> SoftReference(result.getValue()));
> }
> {code}
> However, if a model is an adapter of multiple types an instance of it can
> also be returned for more than just the requested type.
> {code:java}
> interface AdapterType1 {}
> interface AdapterType2 {}
> @Model(adaptables = Resource.class, adapterType={AdapterType1.class,
> AdapterType2.class}, cache = true)
> class Model implements AdapterType1, AdapterType2 {}
> assertSame(resource.adaptTo(Model.class),
> resouce.adaptTo(AdapterType1.class));
> assertSame(resource.adaptTo(AdapterType1.class),
> resouce.adaptTo(AdapterType2.class));
> {code}
> While it is not save to cache the model for all of its adapter types (see
> SLING-11074), it is certainly save to cache the Model for its implementation
> type.
> In fact, when caching the Model for the implementation type, caching it for
> the requested type is redundant. This is based on the assumption that the
> {{org.apache.sling.models.impl.AdapterImplementations#lookup()}} always
> returns the same implementation for given adapterType and adaptable.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SLING-11133) Cache model for its implementation type
[
https://issues.apache.org/jira/browse/SLING-11133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated SLING-11133:
-
Description:
Currently the ModelAdapterFactory caches a cacheable model for the requested
type only
https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L430-L432
{code}
if (result.wasSuccessful() && modelAnnotation.cache() && adaptableCache !=
null) {
adaptableCache.put(requestedType, new
SoftReference(result.getValue()));
}
{code}
However, if a model is an adapter of multiple types an instance of it can also
be returned for more than just the requested type.
While it is not save to cache the model for all of its adapter types (see
SLING-11074), it is certainly save to cache the Model for its implementation
type additionally to the requested type.
In fact, when caching the Model for the implementation type, caching it for the
requested type is redundant. This is based on the assumption that the
{{org.apache.sling.models.impl.AdapterImplementations#lookup()}} always returns
the same implementation for given adapterType and adaptable (considering no
newly registered ImplementationPickers interfere with it)
was:
Currently the ModelAdapterFactory caches a cacheable model for the requested
type only
https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L430-L432
{code}
if (result.wasSuccessful() && modelAnnotation.cache() && adaptableCache !=
null) {
adaptableCache.put(requestedType, new
SoftReference(result.getValue()));
}
{code}
However, if a model is an adapter of multiple types an instance of it can also
be returned for more than just the requested type.
While it is not save to cache the model for all of its adapter types (see
SLING-11074), it is certainly save to cache the Model for its implementation
type additionally to the requested type.
In fact, when caching the Model for the implementation type, caching it for the
requested type is redundant. This is based on the assumption that the
{{org.apache.sling.models.impl.AdapterImplementations#lookup()}} return always
returns the same implementation for given adapterType and adaptable
(considering no newly registered ImplementationPickers interfere with it)
> Cache model for its implementation type
> ---
>
> Key: SLING-11133
> URL: https://issues.apache.org/jira/browse/SLING-11133
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Major
> Fix For: Models Implementation 1.5.2
>
>
> Currently the ModelAdapterFactory caches a cacheable model for the requested
> type only
> https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L430-L432
> {code}
> if (result.wasSuccessful() && modelAnnotation.cache() && adaptableCache !=
> null) {
> adaptableCache.put(requestedType, new
> SoftReference(result.getValue()));
> }
> {code}
> However, if a model is an adapter of multiple types an instance of it can
> also be returned for more than just the requested type.
> While it is not save to cache the model for all of its adapter types (see
> SLING-11074), it is certainly save to cache the Model for its implementation
> type additionally to the requested type.
> In fact, when caching the Model for the implementation type, caching it for
> the requested type is redundant. This is based on the assumption that the
> {{org.apache.sling.models.impl.AdapterImplementations#lookup()}} always
> returns the same implementation for given adapterType and adaptable
> (considering no newly registered ImplementationPickers interfere with it)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SLING-11133) Cache model for its implementation type
[
https://issues.apache.org/jira/browse/SLING-11133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated SLING-11133:
-
Description:
Currently the ModelAdapterFactory caches a cacheable model for the requested
type only
https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L430-L432
{code}
if (result.wasSuccessful() && modelAnnotation.cache() && adaptableCache !=
null) {
adaptableCache.put(requestedType, new
SoftReference(result.getValue()));
}
{code}
However, if a model is an adapter of multiple types an instance of it can also
be returned for more than just the requested type.
While it is not save to cache the model for all of its adapter types (see
SLING-11074), it is certainly save to cache the Model for its implementation
type additionally to the requested type.
In fact, when caching the Model for the implementation type, caching it for the
requested type is redundant. This is based on the assumption that the
{{org.apache.sling.models.impl.AdapterImplementations#lookup()}} return always
returns the same implementation for given adapterType and adaptable
(considering no newly registered ImplementationPickers interfere with it)
was:
Currently the ModelAdapterFactory caches a cacheable model for the requested
type only
https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L430-L432
{code}
if (result.wasSuccessful() && modelAnnotation.cache() && adaptableCache !=
null) {
adaptableCache.put(requestedType, new
SoftReference(result.getValue()));
}
{code}
However, if a model is an adapter of multiple types an instance of it can also
be returned for more than just the requested type.
While it is not save to cache the model for all of its adapter types (see
SLING-11074), it is certainly save to cache the Model for its implementation
type additionally to the requested type.
In fact, when caching the Model for the implementation type caching it for the
requested type is redundant. This is based on the assumption that the
{{org.apache.sling.models.impl.AdapterImplementations#lookup()}} return always
returns the same implementation for given adapterType and adaptable
(considering no newly registered ImplementationPickers interfere with it)
> Cache model for its implementation type
> ---
>
> Key: SLING-11133
> URL: https://issues.apache.org/jira/browse/SLING-11133
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Major
> Fix For: Models Implementation 1.5.2
>
>
> Currently the ModelAdapterFactory caches a cacheable model for the requested
> type only
> https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L430-L432
> {code}
> if (result.wasSuccessful() && modelAnnotation.cache() && adaptableCache !=
> null) {
> adaptableCache.put(requestedType, new
> SoftReference(result.getValue()));
> }
> {code}
> However, if a model is an adapter of multiple types an instance of it can
> also be returned for more than just the requested type.
> While it is not save to cache the model for all of its adapter types (see
> SLING-11074), it is certainly save to cache the Model for its implementation
> type additionally to the requested type.
> In fact, when caching the Model for the implementation type, caching it for
> the requested type is redundant. This is based on the assumption that the
> {{org.apache.sling.models.impl.AdapterImplementations#lookup()}} return
> always returns the same implementation for given adapterType and adaptable
> (considering no newly registered ImplementationPickers interfere with it)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SLING-11133) Cache model for its implementation type
[
https://issues.apache.org/jira/browse/SLING-11133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated SLING-11133:
-
Description:
Currently the ModelAdapterFactory caches a cacheable model for the requested
type only
https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L430-L432
{code}
if (result.wasSuccessful() && modelAnnotation.cache() && adaptableCache !=
null) {
adaptableCache.put(requestedType, new
SoftReference(result.getValue()));
}
{code}
However, if a model is an adapter of multiple types an instance of it can also
be returned for more than just the requested type.
While it is not save to cache the model for all of its adapter types (see
SLING-11074), it is certainly save to cache the Model for its implementation
type additionally to the requested type.
In fact, when caching the Model for the implementation type caching it for the
requested type is redundant. This is based on the assumption that the
{{org.apache.sling.models.impl.AdapterImplementations#lookup()}} return always
returns the same implementation for given adapterType and adaptable
(considering no newly registered ImplementationPickers interfere with it)
was:
Currently the ModelAdapterFactory caches a cacheable model for the requested
type only
https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L430-L432
{code}
if (result.wasSuccessful() && modelAnnotation.cache() && adaptableCache !=
null) {
adaptableCache.put(requestedType, new
SoftReference(result.getValue()));
}
{code}
However, if a model is an adapter of multiple types an instance of it can also
be returned for more than just the requested type.
While it is not save to cache the model for all of its adapter types (see
SLING-11074), it is certainly save to cache the Model for its implementation
type additionally to the requested type. In fact, when caching the Model for
the implementation type caching it for the requested type is redundant.
> Cache model for its implementation type
> ---
>
> Key: SLING-11133
> URL: https://issues.apache.org/jira/browse/SLING-11133
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Major
> Fix For: Models Implementation 1.5.2
>
>
> Currently the ModelAdapterFactory caches a cacheable model for the requested
> type only
> https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L430-L432
> {code}
> if (result.wasSuccessful() && modelAnnotation.cache() && adaptableCache !=
> null) {
> adaptableCache.put(requestedType, new
> SoftReference(result.getValue()));
> }
> {code}
> However, if a model is an adapter of multiple types an instance of it can
> also be returned for more than just the requested type.
> While it is not save to cache the model for all of its adapter types (see
> SLING-11074), it is certainly save to cache the Model for its implementation
> type additionally to the requested type.
> In fact, when caching the Model for the implementation type caching it for
> the requested type is redundant. This is based on the assumption that the
> {{org.apache.sling.models.impl.AdapterImplementations#lookup()}} return
> always returns the same implementation for given adapterType and adaptable
> (considering no newly registered ImplementationPickers interfere with it)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SLING-11133) Cache model for its implementation type
[
https://issues.apache.org/jira/browse/SLING-11133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated SLING-11133:
-
Description:
Currently the ModelAdapterFactory caches a cacheable model for the requested
type only
https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L430-L432
{code}
if (result.wasSuccessful() && modelAnnotation.cache() && adaptableCache !=
null) {
adaptableCache.put(requestedType, new
SoftReference(result.getValue()));
}
{code}
However, if a model is an adapter of multiple types an instance of it can also
be returned for more than just the requested type.
While it is not save to cache the model for all of its adapter types (see
SLING-11074), it is certainly save to cache the Model for its implementation
type additionally to the requested type. In fact, when caching the Model for
the implementation type caching it for the requested type is redundant.
was:
Currently the ModelAdapterFactory caches a cacheable model for the requested
type only
https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L430-L432
{code}
if (result.wasSuccessful() && modelAnnotation.cache() && adaptableCache !=
null) {
adaptableCache.put(requestedType, new
SoftReference(result.getValue()));
}
{code}
However, if a model is an adapter of multiple types an instance of it can also
be returned for more than just the requested type.
While it is not save to cache the model for all of its adapter types (see
SLING-11074), it is certainly save to cache the model for its implementation
type additionally to the requested type.
> Cache model for its implementation type
> ---
>
> Key: SLING-11133
> URL: https://issues.apache.org/jira/browse/SLING-11133
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Reporter: Dirk Rudolph
>Priority: Major
> Fix For: Models Implementation 1.5.2
>
>
> Currently the ModelAdapterFactory caches a cacheable model for the requested
> type only
> https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L430-L432
> {code}
> if (result.wasSuccessful() && modelAnnotation.cache() && adaptableCache !=
> null) {
> adaptableCache.put(requestedType, new
> SoftReference(result.getValue()));
> }
> {code}
> However, if a model is an adapter of multiple types an instance of it can
> also be returned for more than just the requested type.
> While it is not save to cache the model for all of its adapter types (see
> SLING-11074), it is certainly save to cache the Model for its implementation
> type additionally to the requested type. In fact, when caching the Model for
> the implementation type caching it for the requested type is redundant.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (SLING-11133) Cache model for its implementation type
[
https://issues.apache.org/jira/browse/SLING-11133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph reassigned SLING-11133:
Assignee: Dirk Rudolph
> Cache model for its implementation type
> ---
>
> Key: SLING-11133
> URL: https://issues.apache.org/jira/browse/SLING-11133
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Major
> Fix For: Models Implementation 1.5.2
>
>
> Currently the ModelAdapterFactory caches a cacheable model for the requested
> type only
> https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L430-L432
> {code}
> if (result.wasSuccessful() && modelAnnotation.cache() && adaptableCache !=
> null) {
> adaptableCache.put(requestedType, new
> SoftReference(result.getValue()));
> }
> {code}
> However, if a model is an adapter of multiple types an instance of it can
> also be returned for more than just the requested type.
> While it is not save to cache the model for all of its adapter types (see
> SLING-11074), it is certainly save to cache the Model for its implementation
> type additionally to the requested type. In fact, when caching the Model for
> the implementation type caching it for the requested type is redundant.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SLING-11074) Cache model for all of its adapter types
[
https://issues.apache.org/jira/browse/SLING-11074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17490116#comment-17490116
]
Dirk Rudolph commented on SLING-11074:
--
After some consideration this may not be the desired behaviour. For example,
consider an {{ImplementationPicker}} that selects a different implementation
based on the given adapter type. In this case a {{ModelA}} may be returned for
{{Type1}} and be cached for {{Type1}} and {{Type2}}. In a subsequent call the
picker may be supposed to return {{ModelB}} for {{Type2}} but as the instance
of {{ModelA}} is already cached for {{Type2}} it would be returned instead.
This may not be desired and become a breaking change for implementations that
rely on the current behaviour.
{code}
interface Type1 {}
interface Type2 {}
@Model class ModelA implements Type1, Type2 {}
@Model class ModelB implements Type1, Type2 {}
class CustomImplementationPicker implements ImplementationPicker { }
{code}
On the other hand it should be save to cache the model for the implementation
type returned by the implementation picker.
This will be done in SLING-11133 and this ticket be closed as "won't fix". If
we see need we could reopen it in the future.
> Cache model for all of its adapter types
>
>
> Key: SLING-11074
> URL: https://issues.apache.org/jira/browse/SLING-11074
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently the ModelAdapterFactory caches a cacheable model for the requested
> type only
> https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L430-L432
> {code}
> if (result.wasSuccessful() && modelAnnotation.cache() && adaptableCache !=
> null) {
> adaptableCache.put(requestedType, new
> SoftReference(result.getValue()));
> }
> {code}
> However, if a model is an adapter of multiple types an instance of it can
> also be returned for more than just the requested type.
> Caching the model for each of its adapter types may improve the cache hit
> ratio.
> {code}
> interface A {}
> interface B {}
> @Model(cache=true, adaptables=Resource.class, adapters={A.class, B.class})
> class Model implements A, B {}
> assertSame(givenResource.adaptTo(A.class), givenResource.adaptTo(B.class))
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (SLING-11074) Cache model for all of its adapter types
[
https://issues.apache.org/jira/browse/SLING-11074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph resolved SLING-11074.
--
Resolution: Won't Fix
> Cache model for all of its adapter types
>
>
> Key: SLING-11074
> URL: https://issues.apache.org/jira/browse/SLING-11074
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently the ModelAdapterFactory caches a cacheable model for the requested
> type only
> https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L430-L432
> {code}
> if (result.wasSuccessful() && modelAnnotation.cache() && adaptableCache !=
> null) {
> adaptableCache.put(requestedType, new
> SoftReference(result.getValue()));
> }
> {code}
> However, if a model is an adapter of multiple types an instance of it can
> also be returned for more than just the requested type.
> Caching the model for each of its adapter types may improve the cache hit
> ratio.
> {code}
> interface A {}
> interface B {}
> @Model(cache=true, adaptables=Resource.class, adapters={A.class, B.class})
> class Model implements A, B {}
> assertSame(givenResource.adaptTo(A.class), givenResource.adaptTo(B.class))
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (SLING-11133) Cache model for its implementation type
Dirk Rudolph created SLING-11133:
Summary: Cache model for its implementation type
Key: SLING-11133
URL: https://issues.apache.org/jira/browse/SLING-11133
Project: Sling
Issue Type: Improvement
Components: Sling Models
Reporter: Dirk Rudolph
Fix For: Models Implementation 1.5.2
Currently the ModelAdapterFactory caches a cacheable model for the requested
type only
https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L430-L432
{code}
if (result.wasSuccessful() && modelAnnotation.cache() && adaptableCache !=
null) {
adaptableCache.put(requestedType, new
SoftReference(result.getValue()));
}
{code}
However, if a model is an adapter of multiple types an instance of it can also
be returned for more than just the requested type.
While it is not save to cache the model for all of its adapter types (see
SLING-11074), it is certainly save to cache the model for its implementation
type additionally to the requested type.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SLING-11073) Support for Via "Original Resource Type"
[
https://issues.apache.org/jira/browse/SLING-11073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated SLING-11073:
-
Description:
Consider the following Models
{code}
interface A { }
interface B { }
@Model(adaptables=SlingHttpServletRequest.class, resourceType="generic")
class AImpl implements A { @Self private B other; }
@Model(adaptables=SlingHttpServletRequest.class, resourceType="generic")
class BImpl implements B { }
{code}
If we want to extend this using the delegation pattern we could do
{code}
interface A1 extends A { }
@Model(adaptables=SlingHttpServletRequest.class, resourceType="specific")
class A1Impl implements A1 { @Self @Via(type=ResourceSuperType.class) private A
delegate; }
{code}
and additionally for B
{code}
interface B1 extends B { }
@Model(adaptables=SlingHttpServletRequest.class, resourceType="specific")
class B1Impl implements B1 { @Self @Via(type=ResourceSuperType.class) private B
delegate; }
{code}
This will still inject {{BImpl}} into the instance of {{AImpl}} (the delegate
in {{A1Impl}}) when adapting a request on a resource with
resourceType="specific" even though there is a more specific implementation of
it that would match the original resourceType (would be {{B1Impl}}). The reason
is that the ResourceTypeBasedResourcePicker picks {{BImpl}} based on the
resourceType forced by the ResourceSuperTypeViaProvider.
This behaviour may be desired in some cases but not in others. That's why I
propose to introduce a OriginalResourceViaProvider which unwraps the changes
made by the AbstractResourceTypeViaProvider. This can explicitly be specified
to enable it.
{code}
class AImpl implements A {
@Self
@Via(type = OriginalResourceType.class) // undo any forced resourceTypes
private B other;
}
{code}
Which then would inject {{B1Impl}}, the one for the original "specific"
resoruceType.
was:
Consider the following Models
{code}
interface A { }
interface B { }
@Model(adaptables=SlingHttpServletRequest.class, resourceType="generic")
class AImpl implements A { @Self private B other; }
@Model(adaptables=SlingHttpServletRequest.class, resourceType="generic")
class BImpl implements B { }
{code}
If we want to extend this using the delegation pattern we could do
{code}
interface A1 extends A { }
@Model(adaptables=SlingHttpServletRequest.class, resourceType="specific")
class A1Impl implements A1 { @Self @Via(type=ResourceSuperType.class) private A
delegate; }
{code}
and additionally for B
{code}
interface B1 extends B { }
@Model(adaptables=SlingHttpServletRequest.class, resourceType="specific")
class B1Impl implements B1 { @Self @Via(type=ResourceSuperType.class) private B
delegate; }
{code}
This will still inject {{BImpl}} into the instance of {{AImpl}} (the delegate
in {{A1Impl}}) when adapting a request on a resource with
resourceType="specific" even though there is a more specific implementation of
it that would match the original resourceType (would be {{B1Impl}}). The reason
is that the ResourceTypeBasedResourcePicker picks {{BImpl}} based on the
resourceType forced by the ResourceSuperTypeViaProvider.
This behaviour may be desired in some cases but not in others. That's why I
propose to introduce a OriginalResourceViaProvider which unwraps the changes
made by the AbstractResourceTypeViaProvider. This can explicitly be specified
to enable it.
{code}
class AImpl implements A {
@Self
@Via(type = OriginalResource.class) // undo any forced resourceTypes
private B other;
}
{code}
Which then would inject {{B1Impl}}, the one for the original "specific"
resoruceType.
> Support for Via "Original Resource Type"
>
>
> Key: SLING-11073
> URL: https://issues.apache.org/jira/browse/SLING-11073
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Major
> Fix For: Models API 1.4.2, Models Implementation 1.5.2
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> Consider the following Models
> {code}
> interface A { }
> interface B { }
> @Model(adaptables=SlingHttpServletRequest.class, resourceType="generic")
> class AImpl implements A { @Self private B other; }
> @Model(adaptables=SlingHttpServletRequest.class, resourceType="generic")
> class BImpl implements B { }
> {code}
> If we want to extend this using the delegation pattern we could do
> {code}
> interface A1 extends A { }
> @Model(adaptables=SlingHttpServletRequest.class, resourceType="specific")
> class A1Impl implements A1 { @Self @Via(type=ResourceSuperType.class) private
> A delegate; }
> {code}
> and additionally for B
> {code}
> interface B1 extends B { }
> @Model(adaptables=SlingHttpServletRequest.class, resourceType="specific")
> class B1Impl implements B1 { @Self
[jira] [Updated] (SLING-11073) Support for Via "Original Resource Type"
[
https://issues.apache.org/jira/browse/SLING-11073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated SLING-11073:
-
Summary: Support for Via "Original Resource Type" (was: Support for Via
"Original Resource")
> Support for Via "Original Resource Type"
>
>
> Key: SLING-11073
> URL: https://issues.apache.org/jira/browse/SLING-11073
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Major
> Fix For: Models API 1.4.2, Models Implementation 1.5.2
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Consider the following Models
> {code}
> interface A { }
> interface B { }
> @Model(adaptables=SlingHttpServletRequest.class, resourceType="generic")
> class AImpl implements A { @Self private B other; }
> @Model(adaptables=SlingHttpServletRequest.class, resourceType="generic")
> class BImpl implements B { }
> {code}
> If we want to extend this using the delegation pattern we could do
> {code}
> interface A1 extends A { }
> @Model(adaptables=SlingHttpServletRequest.class, resourceType="specific")
> class A1Impl implements A1 { @Self @Via(type=ResourceSuperType.class) private
> A delegate; }
> {code}
> and additionally for B
> {code}
> interface B1 extends B { }
> @Model(adaptables=SlingHttpServletRequest.class, resourceType="specific")
> class B1Impl implements B1 { @Self @Via(type=ResourceSuperType.class) private
> B delegate; }
> {code}
> This will still inject {{BImpl}} into the instance of {{AImpl}} (the delegate
> in {{A1Impl}}) when adapting a request on a resource with
> resourceType="specific" even though there is a more specific implementation
> of it that would match the original resourceType (would be {{B1Impl}}). The
> reason is that the ResourceTypeBasedResourcePicker picks {{BImpl}} based on
> the resourceType forced by the ResourceSuperTypeViaProvider.
> This behaviour may be desired in some cases but not in others. That's why I
> propose to introduce a OriginalResourceViaProvider which unwraps the changes
> made by the AbstractResourceTypeViaProvider. This can explicitly be specified
> to enable it.
> {code}
> class AImpl implements A {
> @Self
> @Via(type = OriginalResource.class) // undo any forced resourceTypes
> private B other;
> }
> {code}
> Which then would inject {{B1Impl}}, the one for the original "specific"
> resoruceType.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (SLING-11073) Support for Via "Original Resource"
[
https://issues.apache.org/jira/browse/SLING-11073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph resolved SLING-11073.
--
Resolution: Fixed
> Support for Via "Original Resource"
> ---
>
> Key: SLING-11073
> URL: https://issues.apache.org/jira/browse/SLING-11073
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Major
> Fix For: Models API 1.4.2, Models Implementation 1.5.2
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Consider the following Models
> {code}
> interface A { }
> interface B { }
> @Model(adaptables=SlingHttpServletRequest.class, resourceType="generic")
> class AImpl implements A { @Self private B other; }
> @Model(adaptables=SlingHttpServletRequest.class, resourceType="generic")
> class BImpl implements B { }
> {code}
> If we want to extend this using the delegation pattern we could do
> {code}
> interface A1 extends A { }
> @Model(adaptables=SlingHttpServletRequest.class, resourceType="specific")
> class A1Impl implements A1 { @Self @Via(type=ResourceSuperType.class) private
> A delegate; }
> {code}
> and additionally for B
> {code}
> interface B1 extends B { }
> @Model(adaptables=SlingHttpServletRequest.class, resourceType="specific")
> class B1Impl implements B1 { @Self @Via(type=ResourceSuperType.class) private
> B delegate; }
> {code}
> This will still inject {{BImpl}} into the instance of {{AImpl}} (the delegate
> in {{A1Impl}}) when adapting a request on a resource with
> resourceType="specific" even though there is a more specific implementation
> of it that would match the original resourceType (would be {{B1Impl}}). The
> reason is that the ResourceTypeBasedResourcePicker picks {{BImpl}} based on
> the resourceType forced by the ResourceSuperTypeViaProvider.
> This behaviour may be desired in some cases but not in others. That's why I
> propose to introduce a OriginalResourceViaProvider which unwraps the changes
> made by the AbstractResourceTypeViaProvider. This can explicitly be specified
> to enable it.
> {code}
> class AImpl implements A {
> @Self
> @Via(type = OriginalResource.class) // undo any forced resourceTypes
> private B other;
> }
> {code}
> Which then would inject {{B1Impl}}, the one for the original "specific"
> resoruceType.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SLING-11073) Support for Via "Original Resource"
[
https://issues.apache.org/jira/browse/SLING-11073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated SLING-11073:
-
Description:
Consider the following Models
{code}
interface A { }
interface B { }
@Model(adaptables=SlingHttpServletRequest.class, resourceType="generic")
class AImpl implements A { @Self private B other; }
@Model(adaptables=SlingHttpServletRequest.class, resourceType="generic")
class BImpl implements B { }
{code}
If we want to extend this using the delegation pattern we could do
{code}
interface A1 extends A { }
@Model(adaptables=SlingHttpServletRequest.class, resourceType="specific")
class A1Impl implements A1 { @Self @Via(type=ResourceSuperType.class) private A
delegate; }
{code}
and additionally for B
{code}
interface B1 extends B { }
@Model(adaptables=SlingHttpServletRequest.class, resourceType="specific")
class B1Impl implements B1 { @Self @Via(type=ResourceSuperType.class) private B
delegate; }
{code}
This will still inject {{BImpl}} into the instance of {{AImpl}} (the delegate
in {{A1Impl}}) when adapting a request on a resource with
resourceType="specific" even though there is a more specific implementation of
it that would match the original resourceType (would be {{B1Impl}}). The reason
is that the ResourceTypeBasedResourcePicker picks {{BImpl}} based on the
resourceType forced by the ResourceSuperTypeViaProvider.
This behaviour may be desired in some cases but not in others. That's why I
propose to introduce a OriginalResourceViaProvider which unwraps the changes
made by the AbstractResourceTypeViaProvider. This can explicitly be specified
to enable it.
{code}
class AImpl implements A {
@Self
@Via(type = OriginalResource.class) // undo any forced resourceTypes
private B other;
}
{code}
Which then would inject {{B1Impl}}, the one for the original "specific"
resoruceType.
was:
Consider the following Models
{code}
interface A { }
interface B { }
@Model(adaptables=SlingHttpServletRequest.class, resourceType="generic")
class AImpl implements A { @Self private B other; }
@Model(adaptables=SlingHttpServletRequest.class, resourceType="generic")
class BImpl implements B { }
{code}
If we want to extend this using the delegation pattern we could do
{code}
interface A1 extends A { }
@Model(adaptables=SlingHttpServletRequest.class, resourceType="specific")
class A1Impl implements A1 { @Self @Via(type=ResourceSuperType.class) private A
delegate; }
{code}
and additionally for B
{code}
interface B1 extends B { }
@Model(adaptables=SlingHttpServletRequest.class, resourceType="specific")
class B1Impl implements B1 { @Self @Via(type=ResourceSuperType.class) private B
delegate; }
{code}
This will however still inject {{BImpl}} into the instance of {{AImpl}} (the
delegate in {{A1Impl}}) when adapting a request on a resource with
resourceType="specific" even though there is a more specific implementation of
it that would match the original resourceType (would be {{B1Impl}}). The reason
is that the ResourceTypeBasedResourcePicker picks {{BImpl}} based on the
resourceType forced by the ResourceSuperTypeViaProvider.
This behaviour may be desired in some cases but not in others. That's why I
propose to introduce a OriginalResourceViaProvider which unwraps the changes
made by the AbstractResourceTypeViaProvider. This can explicitly be specified
to enable it.
{code}
class AImpl implements A {
@Self
@Via(type = OriginalResource.class) // undo any forced resourceTypes
private B other;
}
{code}
Which then would inject {{B1Impl}}, the one for the original "specific"
resoruceType.
> Support for Via "Original Resource"
> ---
>
> Key: SLING-11073
> URL: https://issues.apache.org/jira/browse/SLING-11073
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Major
> Fix For: Models API 1.4.2, Models Implementation 1.5.2
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Consider the following Models
> {code}
> interface A { }
> interface B { }
> @Model(adaptables=SlingHttpServletRequest.class, resourceType="generic")
> class AImpl implements A { @Self private B other; }
> @Model(adaptables=SlingHttpServletRequest.class, resourceType="generic")
> class BImpl implements B { }
> {code}
> If we want to extend this using the delegation pattern we could do
> {code}
> interface A1 extends A { }
> @Model(adaptables=SlingHttpServletRequest.class, resourceType="specific")
> class A1Impl implements A1 { @Self @Via(type=ResourceSuperType.class) private
> A delegate; }
> {code}
> and additionally for B
> {code}
> interface B1 extends B { }
> @Model(adaptables=SlingHttpServletRequest.class, resourceType="specific")
> class B1Impl implements B1 { @Self
[jira] [Updated] (SLING-11073) Support for Via "Original Resource"
[
https://issues.apache.org/jira/browse/SLING-11073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated SLING-11073:
-
Fix Version/s: Models API 1.4.2
Models Implementation 1.5.2
> Support for Via "Original Resource"
> ---
>
> Key: SLING-11073
> URL: https://issues.apache.org/jira/browse/SLING-11073
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Major
> Fix For: Models API 1.4.2, Models Implementation 1.5.2
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Consider the following Models
> {code}
> interface A { }
> interface B { }
> @Model(adaptables=SlingHttpServletRequest.class, resourceType="generic")
> class AImpl implements A { @Self private B other; }
> @Model(adaptables=SlingHttpServletRequest.class, resourceType="generic")
> class BImpl implements B { }
> {code}
> If we want to extend this using the delegation pattern we could do
> {code}
> interface A1 extends A { }
> @Model(adaptables=SlingHttpServletRequest.class, resourceType="specific")
> class A1Impl implements A1 { @Self @Via(type=ResourceSuperType.class) private
> A delegate; }
> {code}
> and additionally for B
> {code}
> interface B1 extends B { }
> @Model(adaptables=SlingHttpServletRequest.class, resourceType="specific")
> class B1Impl implements B1 { @Self @Via(type=ResourceSuperType.class) private
> B delegate; }
> {code}
> This will however still inject {{BImpl}} into the instance of {{AImpl}} (the
> delegate in {{A1Impl}}) when adapting a request on a resource with
> resourceType="specific" even though there is a more specific implementation
> of it that would match the original resourceType (would be {{B1Impl}}). The
> reason is that the ResourceTypeBasedResourcePicker picks {{BImpl}} based on
> the resourceType forced by the ResourceSuperTypeViaProvider.
> This behaviour may be desired in some cases but not in others. That's why I
> propose to introduce a OriginalResourceViaProvider which unwraps the changes
> made by the AbstractResourceTypeViaProvider. This can explicitly be specified
> to enable it.
> {code}
> class AImpl implements A {
> @Self
> @Via(type = OriginalResource.class) // undo any forced resourceTypes
> private B other;
> }
> {code}
> Which then would inject {{B1Impl}}, the one for the original "specific"
> resoruceType.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SLING-11094) Sitemap: Move all dependencies to provided scope
[ https://issues.apache.org/jira/browse/SLING-11094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dirk Rudolph updated SLING-11094: - Fix Version/s: Sitemap 1.0.8 > Sitemap: Move all dependencies to provided scope > > > Key: SLING-11094 > URL: https://issues.apache.org/jira/browse/SLING-11094 > Project: Sling > Issue Type: Improvement >Affects Versions: Sitemap 1.0.4, Sitemap 1.0.6 >Reporter: Konrad Windszus >Assignee: Dirk Rudolph >Priority: Minor > Labels: sitemaps > Fix For: Sitemap 1.0.8 > > > All dependencies should have provided scope, as they are not relevant as > transitive dependencies. > Also the scope should mentioned explicitly in the pom.xml (and not only > inherited from parent). > Currently the following dependencies have compile scope: > # jackrabbit-jcr-commons > # org.apache.sling.commons.metrics (not sure if this is used in SPI/API) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (SLING-11094) Sitemap: Move all dependencies to provided scope
[ https://issues.apache.org/jira/browse/SLING-11094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dirk Rudolph resolved SLING-11094. -- Resolution: Fixed Thanks Konrad. Fixed in https://github.com/apache/sling-org-apache-sling-sitemap/commit/0065e123f4042755126b963e6d3bb415c8a9b161 > Sitemap: Move all dependencies to provided scope > > > Key: SLING-11094 > URL: https://issues.apache.org/jira/browse/SLING-11094 > Project: Sling > Issue Type: Improvement >Affects Versions: Sitemap 1.0.4, Sitemap 1.0.6 >Reporter: Konrad Windszus >Assignee: Dirk Rudolph >Priority: Minor > Labels: sitemaps > Fix For: Sitemap 1.0.8 > > > All dependencies should have provided scope, as they are not relevant as > transitive dependencies. > Also the scope should mentioned explicitly in the pom.xml (and not only > inherited from parent). > Currently the following dependencies have compile scope: > # jackrabbit-jcr-commons > # org.apache.sling.commons.metrics (not sure if this is used in SPI/API) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SLING-11094) Sitemap: Move all dependencies to provided scope
[ https://issues.apache.org/jira/browse/SLING-11094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dirk Rudolph updated SLING-11094: - Affects Version/s: Sitemap 1.0.6 > Sitemap: Move all dependencies to provided scope > > > Key: SLING-11094 > URL: https://issues.apache.org/jira/browse/SLING-11094 > Project: Sling > Issue Type: Improvement >Affects Versions: Sitemap 1.0.4, Sitemap 1.0.6 >Reporter: Konrad Windszus >Assignee: Dirk Rudolph >Priority: Minor > Labels: sitemaps > > All dependencies should have provided scope, as they are not relevant as > transitive dependencies. > Also the scope should mentioned explicitly in the pom.xml (and not only > inherited from parent). > Currently the following dependencies have compile scope: > # jackrabbit-jcr-commons > # org.apache.sling.commons.metrics (not sure if this is used in SPI/API) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SLING-11094) Sitemap: Move all dependencies to provided scope
[ https://issues.apache.org/jira/browse/SLING-11094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dirk Rudolph updated SLING-11094: - Labels: sitemaps (was: ) > Sitemap: Move all dependencies to provided scope > > > Key: SLING-11094 > URL: https://issues.apache.org/jira/browse/SLING-11094 > Project: Sling > Issue Type: Improvement >Affects Versions: Sitemap 1.0.4 >Reporter: Konrad Windszus >Assignee: Dirk Rudolph >Priority: Minor > Labels: sitemaps > > All dependencies should have provided scope, as they are not relevant as > transitive dependencies. > Also the scope should mentioned explicitly in the pom.xml (and not only > inherited from parent). > Currently the following dependencies have compile scope: > # jackrabbit-jcr-commons > # org.apache.sling.commons.metrics (not sure if this is used in SPI/API) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (SLING-11094) Sitemap: Move all dependencies to provided scope
[ https://issues.apache.org/jira/browse/SLING-11094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dirk Rudolph reassigned SLING-11094: Assignee: Dirk Rudolph > Sitemap: Move all dependencies to provided scope > > > Key: SLING-11094 > URL: https://issues.apache.org/jira/browse/SLING-11094 > Project: Sling > Issue Type: Improvement >Affects Versions: Sitemap 1.0.4 >Reporter: Konrad Windszus >Assignee: Dirk Rudolph >Priority: Minor > > All dependencies should have provided scope, as they are not relevant as > transitive dependencies. > Also the scope should mentioned explicitly in the pom.xml (and not only > inherited from parent). > Currently the following dependencies have compile scope: > # jackrabbit-jcr-commons > # org.apache.sling.commons.metrics (not sure if this is used in SPI/API) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (SLING-11090) Update to parent 47
[ https://issues.apache.org/jira/browse/SLING-11090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dirk Rudolph resolved SLING-11090. -- Resolution: Fixed Fixed in [c5c7fcd|https://github.com/apache/sling-org-apache-sling-sitemap/commit/c5c7fcd4ce9eebfeaff6c470366a84d8ce63763a] > Update to parent 47 > --- > > Key: SLING-11090 > URL: https://issues.apache.org/jira/browse/SLING-11090 > Project: Sling > Issue Type: Task > Components: Extensions >Reporter: Dirk Rudolph >Assignee: Dirk Rudolph >Priority: Minor > Labels: sitemaps > Fix For: Sitemap 1.0.6 > > > Update parent pom to version 46 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SLING-11090) Update to parent 47
[ https://issues.apache.org/jira/browse/SLING-11090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dirk Rudolph updated SLING-11090: - Description: Update parent pom to version 47 (was: Update parent pom to version 46 ) > Update to parent 47 > --- > > Key: SLING-11090 > URL: https://issues.apache.org/jira/browse/SLING-11090 > Project: Sling > Issue Type: Task > Components: Extensions >Reporter: Dirk Rudolph >Assignee: Dirk Rudolph >Priority: Minor > Labels: sitemaps > Fix For: Sitemap 1.0.6 > > > Update parent pom to version 47 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SLING-11090) Update to parent 47
[ https://issues.apache.org/jira/browse/SLING-11090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dirk Rudolph updated SLING-11090: - Fix Version/s: Sitemap 1.0.6 (was: Sitemap 1.0.4) > Update to parent 47 > --- > > Key: SLING-11090 > URL: https://issues.apache.org/jira/browse/SLING-11090 > Project: Sling > Issue Type: Task > Components: Extensions >Reporter: Dirk Rudolph >Assignee: Dirk Rudolph >Priority: Minor > Labels: sitemaps > Fix For: Sitemap 1.0.6 > > > Update parent pom to version 46 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (SLING-11090) Update to parent 47
Dirk Rudolph created SLING-11090: Summary: Update to parent 47 Key: SLING-11090 URL: https://issues.apache.org/jira/browse/SLING-11090 Project: Sling Issue Type: Task Components: Extensions Reporter: Dirk Rudolph Assignee: Dirk Rudolph Fix For: Sitemap 1.0.4 Update parent pom to version 46 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (SLING-11088) ExtensionProviderManager should bind multiple SitemapExtensionProviders
[ https://issues.apache.org/jira/browse/SLING-11088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dirk Rudolph resolved SLING-11088. -- Resolution: Fixed > ExtensionProviderManager should bind multiple SitemapExtensionProviders > --- > > Key: SLING-11088 > URL: https://issues.apache.org/jira/browse/SLING-11088 > Project: Sling > Issue Type: Bug > Components: Extensions >Reporter: Dirk Rudolph >Assignee: Dirk Rudolph >Priority: Major > Labels: sitemaps > Fix For: Sitemap 1.0.6 > > > Currently the reference cardinality is set to optional 0..1 but it should be > 0..n > https://github.com/apache/sling-org-apache-sling-sitemap/blob/master/src/main/java/org/apache/sling/sitemap/impl/builder/extensions/ExtensionProviderManager.java#L37-L42 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (SLING-11088) ExtensionProviderManager should bind multiple SitemapExtensionProviders
Dirk Rudolph created SLING-11088: Summary: ExtensionProviderManager should bind multiple SitemapExtensionProviders Key: SLING-11088 URL: https://issues.apache.org/jira/browse/SLING-11088 Project: Sling Issue Type: Bug Components: Extensions Reporter: Dirk Rudolph Fix For: Sitemap 1.0.6 Currently the reference cardinality is set to optional 0..1 but it should be 0..n https://github.com/apache/sling-org-apache-sling-sitemap/blob/master/src/main/java/org/apache/sling/sitemap/impl/builder/extensions/ExtensionProviderManager.java#L37-L42 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (SLING-11088) ExtensionProviderManager should bind multiple SitemapExtensionProviders
[ https://issues.apache.org/jira/browse/SLING-11088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dirk Rudolph reassigned SLING-11088: Assignee: Dirk Rudolph > ExtensionProviderManager should bind multiple SitemapExtensionProviders > --- > > Key: SLING-11088 > URL: https://issues.apache.org/jira/browse/SLING-11088 > Project: Sling > Issue Type: Bug > Components: Extensions >Reporter: Dirk Rudolph >Assignee: Dirk Rudolph >Priority: Major > Labels: sitemaps > Fix For: Sitemap 1.0.6 > > > Currently the reference cardinality is set to optional 0..1 but it should be > 0..n > https://github.com/apache/sling-org-apache-sling-sitemap/blob/master/src/main/java/org/apache/sling/sitemap/impl/builder/extensions/ExtensionProviderManager.java#L37-L42 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SLING-11074) Cache model for all of its adapter types
[
https://issues.apache.org/jira/browse/SLING-11074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated SLING-11074:
-
Description:
Currently the ModelAdapterFactory caches a cacheable model for the requested
type only
https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L430-L432
{code}
if (result.wasSuccessful() && modelAnnotation.cache() && adaptableCache !=
null) {
adaptableCache.put(requestedType, new
SoftReference(result.getValue()));
}
{code}
However, if a model is an adapter of multiple types an instance of it can also
be returned for more than just the requested type.
Caching the model for each of its adapter types may improve the cache hit
ratio.
{code}
interface A {}
interface B {}
@Model(cache=true, adaptables=Resource.class, adapters={A.class, B.class})
class Model implements A, B {}
assertSame(givenResource.adaptTo(A.class), givenResource.adaptTo(B.class))
{code}
was:
Currently the ModelAdapterFactory caches a cacheable model for the requested
type only
https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L430-L432
{code}
if (result.wasSuccessful() && modelAnnotation.cache() && adaptableCache !=
null) {
adaptableCache.put(requestedType, new
SoftReference(result.getValue()));
}
{code}
However, if a model is an adapter of multiple types an instance of it can also
be returned for more than just the requested type.
Caching the model for each of its adapter types may improve the cache hit
ratio.
{code}
interface A {}
interface B {}
@Model(cache=true, adaptables=Resource.class, adapters={A.class, B.class})
class Model implements A, B {}
assertSame(givenResource.adaptTo(A.class), givenResource.adaptTo(B.class))
{code}
> Cache model for all of its adapter types
>
>
> Key: SLING-11074
> URL: https://issues.apache.org/jira/browse/SLING-11074
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently the ModelAdapterFactory caches a cacheable model for the requested
> type only
> https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L430-L432
> {code}
> if (result.wasSuccessful() && modelAnnotation.cache() && adaptableCache !=
> null) {
> adaptableCache.put(requestedType, new
> SoftReference(result.getValue()));
> }
> {code}
> However, if a model is an adapter of multiple types an instance of it can
> also be returned for more than just the requested type.
> Caching the model for each of its adapter types may improve the cache hit
> ratio.
> {code}
> interface A {}
> interface B {}
> @Model(cache=true, adaptables=Resource.class, adapters={A.class, B.class})
> class Model implements A, B {}
> assertSame(givenResource.adaptTo(A.class), givenResource.adaptTo(B.class))
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (SLING-11074) Cache model for all of its adapter types
[
https://issues.apache.org/jira/browse/SLING-11074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph reassigned SLING-11074:
Assignee: Dirk Rudolph
> Cache model for all of its adapter types
>
>
> Key: SLING-11074
> URL: https://issues.apache.org/jira/browse/SLING-11074
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Major
>
> Currently the ModelAdapterFactory caches a cacheable model for the requested
> type only
> https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L430-L432
> {code}
> if (result.wasSuccessful() && modelAnnotation.cache() && adaptableCache !=
> null) {
> adaptableCache.put(requestedType, new
> SoftReference(result.getValue()));
> }
> {code}
> However, if a model is an adapter of multiple types an instance of it can
> also be returned for more than just the requested type.
> Caching the model for each of its adapter types may improve the cache hit
> ratio.
> {code}
> interface A {}
> interface B {}
> @Model(cache=true, adaptables=Resource.class, adapters={A.class, B.class})
> class Model implements A, B {}
> assertSame(givenResource.adaptTo(A.class), givenResource.adaptTo(B.class))
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SLING-11074) Cache model for all of its adapter types
[
https://issues.apache.org/jira/browse/SLING-11074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated SLING-11074:
-
Description:
Currently the ModelAdapterFactory caches a cacheable model for the requested
type only
https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L430-L432
{code}
if (result.wasSuccessful() && modelAnnotation.cache() && adaptableCache !=
null) {
adaptableCache.put(requestedType, new
SoftReference(result.getValue()));
}
{code}
However, if a model is an adapter of multiple types an instance of it can also
be returned for more than just the requested type.
Caching the model for each of its adapter types may improve the cache hit
ratio.
{code}
interface A {}
interface B {}
@Model(cache=true, adaptables=Resource.class, adapters={A.class, B.class})
class Model implements A, B {}
assertSame(givenResource.adaptTo(A.class), givenResource.adaptTo(B.class))
{code}
was:
Currently the ModelAdapterFactory caches a cacheable model for the requested
type only
https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L430-L432
{code}
if (result.wasSuccessful() && modelAnnotation.cache() && adaptableCache !=
null) {
adaptableCache.put(requestedType, new
SoftReference(result.getValue()));
}
{code}
However, if a model is an adapter of multiple types it can also be returned for
more than just the requested type. Caching the model for each of the adapter
types may improve the cache hit ratio.
{code}
interface A {}
interface B {}
@Model(cache=true, adaptables=Resource.class, adapters={A.class, B.class})
class Model implements A, B {}
assertSame(givenResource.adaptTo(A.class), givenResource.adaptTo(B.class))
{code}
> Cache model for all of its adapter types
>
>
> Key: SLING-11074
> URL: https://issues.apache.org/jira/browse/SLING-11074
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Reporter: Dirk Rudolph
>Priority: Major
>
> Currently the ModelAdapterFactory caches a cacheable model for the requested
> type only
> https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L430-L432
> {code}
> if (result.wasSuccessful() && modelAnnotation.cache() && adaptableCache !=
> null) {
> adaptableCache.put(requestedType, new
> SoftReference(result.getValue()));
> }
> {code}
> However, if a model is an adapter of multiple types an instance of it can
> also be returned for more than just the requested type.
> Caching the model for each of its adapter types may improve the cache hit
> ratio.
> {code}
> interface A {}
> interface B {}
> @Model(cache=true, adaptables=Resource.class, adapters={A.class, B.class})
> class Model implements A, B {}
> assertSame(givenResource.adaptTo(A.class), givenResource.adaptTo(B.class))
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (SLING-11074) Cache model for all of its adapter types
Dirk Rudolph created SLING-11074:
Summary: Cache model for all of its adapter types
Key: SLING-11074
URL: https://issues.apache.org/jira/browse/SLING-11074
Project: Sling
Issue Type: Improvement
Components: Sling Models
Reporter: Dirk Rudolph
Currently the ModelAdapterFactory caches a cacheable model for the requested
type only
https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L430-L432
{code}
if (result.wasSuccessful() && modelAnnotation.cache() && adaptableCache !=
null) {
adaptableCache.put(requestedType, new
SoftReference(result.getValue()));
}
{code}
However, if a model is an adapter of multiple types it can also be returned for
more than just the requested type. Caching the model for each of the adapter
types may improve the cache hit ratio.
{code}
interface A {}
interface B {}
@Model(cache=true, adaptables=Resource.class, adapters={A.class, B.class})
class Model implements A, B {}
assertSame(givenResource.adaptTo(A.class), givenResource.adaptTo(B.class))
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
