[jira] [Commented] (SLING-12436) Change scheduler setup in distribution journal to be more resilient

2024-09-26 Thread Joerg Hoh (Jira)


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

Joerg Hoh commented on SLING-12436:
---

merged with 
https://github.com/apache/sling-org-apache-sling-distribution-journal/commit/688a11e06ab763c9fd1ae67c7895594b0a2f5ac4

> Change scheduler setup in distribution journal to be more resilient
> ---
>
> Key: SLING-12436
> URL: https://issues.apache.org/jira/browse/SLING-12436
> Project: Sling
>  Issue Type: Improvement
>Reporter: Christian Schneider
>Assignee: Christian Schneider
>Priority: Major
> Fix For: Content Distribution Journal Core 0.5.0
>
>
> org.apache.sling.distribution.journal.impl.discovery.DiscoveryService is 
> configured to be called by sling scheduler every 5 seconds.
>  
> {noformat}
> // Register periodic task to update the topology view
> Dictionary props = new Hashtable<>();
> props.put(PROPERTY_SCHEDULER_CONCURRENT, false);
> props.put(PROPERTY_SCHEDULER_PERIOD, 5L); // every 5 seconds 
> reg = context.registerService(Runnable.class.getName(), this, 
> props);{noformat}
>  
> This makes sling scheduler use the default thread pool. At a customer we had 
> some other job block all threads of default thread pool. This caused our code 
> here to not be called anymore and thus the UI of content distribution showed 
> no progress in replication queues. For customers this looked like replication 
> stopped working.
> We should set a specific thread pool for distribution to make sure we are not 
> affected by other code using sling scheduler.
>  
> Apart from this we should also setup the same for 
> ResourceDistributionPackageCleanup
> h3.  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Comment Edited] (SLING-11924) ModelExporter should not serialize a ResourceResolver

2024-09-21 Thread Joerg Hoh (Jira)


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

Joerg Hoh edited comment on SLING-11924 at 9/21/24 2:27 PM:


Some words to the implementation:
* By default this version just warns when a ResourceResolver is serialized into 
JSON. But you can also prevent a ResourceResolver from being serialized by 
setting the OSGI configuration for the PID 
{{org.apache.sling.models.jacksonexporter.impl.ConfigurableSerializationModuleProvider}}
 the property "disable.serialization" to the (multi-) value 
"org.apache.sling.api.resource.ResourceResolver".
* the interface of this functionality is designed to handle more than just 
ResourceResolvers, but the implementation is not able to do that yet.


was (Author: joerghoh):
Some words to the implementation:
* By default this version just warns when a ResourceResolver is serialized into 
JSON. But you can also prevent a ResourceResolver from being serialized by 
setting the OSGI configuration for the PID 
{{org.apache.sling.models.jacksonexporter.impl.ConfigurableSerializationModuleProvider}}
 the property "disable_serialization" to the (multi-) value 
"org.apache.sling.api.resource.ResourceResolver".
* the interface of this functionality is designed to handle more than just 
ResourceResolvers, but the implementation is not able to do that yet.

> ModelExporter should not serialize a ResourceResolver
> -
>
> Key: SLING-11924
> URL: https://issues.apache.org/jira/browse/SLING-11924
> Project: Sling
>  Issue Type: Task
>  Components: Sling Models
>Affects Versions: Sling Models Jackson Exporter 1.0.2
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: Models Jackson Exporter 1.1.4
>
>
> With the addition of {{ResourceResolver.getPropertyMap()}} (SLING-10895) I 
> found that the serialization of a ResourceResolver can fail like this:
> {noformat}
> org.apache.sling.models.factory.ExportException: 
> com.fasterxml.jackson.databind.exc.InvalidDefinitionException: No serializer 
> found for class com.day.cq.wcm.core.impl.policies.ContentPolicyManagerImpl 
> and no properties discovered to create BeanSerializer (to avoid exception, 
> disable SerializationFeature.FAIL_ON_EMPTY_BEANS) (through reference chain: 
> com.myapp.PageImpl[":items"]> [...] > com.myapp.MyModel["resolver"] 
> >org.apache.sling.resourceresolver.impl.ResourceResolverImpl["propertyMap"] 
> >java.util.HashMap["com.day.cq.wcm.core.impl.policies.ContentPolicyAdapterFactory.ContentPolicy"])
> at 
> org.apache.sling.models.jacksonexporter.impl.JacksonExporter.export(JacksonExporter.java:138)
>  [org.apache.sling.models.jacksonexporter:1.1.2]
> at 
> org.apache.sling.models.impl.ModelAdapterFactory.exportModel(ModelAdapterFactory.java:1333)
>  [org.apache.sling.models.impl:1.5.4]
> {noformat}
> This is caused by the fact, that a Sling Model class serializes a 
> ResourceResolver, which is problematic for these 2 reasons:
> * It can fail for the above mentioned reason in an unpredictable way (for 
> example, some code adds items via {{getPropertyMap().put(x,y)}} and the 
> serialization fails at a totally different place.
> * The serialization of the RR discloses implementation details (e.g. 
> searchpaths, or other things which might be stored in the propertyMap).
> I am not aware of any reason, why a ResourceResolver should be serialized, 
> instead more specialized types should be used instead.
> For these reasons we should have a way to disable the serialization of the 
> ResourceResolver. For backwards compatibility we can keep the existing 
> behavior as a default, but I also see reasons why it the serialization of the 
> RR should be turned off by default.
> See also the discussion on sling-dev: 
> https://lists.apache.org/thread/8xl4lgfl5omv3md4drgyqqz3vmfllsom



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (SLING-12431) [BundledScriptTracker] StackOverflow / endless recursion

2024-09-16 Thread Joerg Hoh (Jira)


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

Joerg Hoh updated SLING-12431:
--
Description: 
{noformat}
[FelixLogListener] Events.Framework.org.apache.sling.servlets.resolver 
FrameworkEvent ERROR (java.lang.StackOverflowError)
java.lang.StackOverflowError: null
at java.base/java.util.HashSet.iterator(HashSet.java:173)
at java.base/java.util.AbstractSet.hashCode(AbstractSet.java:120)
at java.base/java.util.Arrays.hashCode(Arrays.java:4685)
at java.base/java.util.Objects.hash(Objects.java:146)
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledRenderUnitCapabilityImpl.hashCode(BundledRenderUnitCapabilityImpl.java:115)
 [org.apache.sling.servlets.resolver:2.11.2]
at java.base/java.util.Arrays.hashCode(Arrays.java:4685)
at java.base/java.util.Objects.hash(Objects.java:146)
at 
org.apache.sling.servlets.resolver.internal.bundle.TypeProviderImpl.hashCode(TypeProviderImpl.java:53)
 [org.apache.sling.servlets.resolver:2.11.2]
at java.base/java.util.HashMap.hash(HashMap.java:340)
at java.base/java.util.HashMap.put(HashMap.java:608)
at java.base/java.util.HashSet.add(HashSet.java:220)
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:678)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
[...]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
{noformat}
Unfortunately I don't have the entire call trace here, but we should have a way 
to prevent that StackOverflow.

  was:
{noformat}
[FelixLogListener] Events.Framework.org.apache.sling.servlets.resolver 
FrameworkEvent ERROR (java.lang.StackOverflowError)
java.lang.StackOverflowError: null
at java.base/java.util.HashSet.iterator(HashSet.java:173)
at java.base/java.util.AbstractSet.hashCode(AbstractSet.java:120)
at java.base/java.util.Arrays.hashCode(Arrays.java:4685)
at java.base/java.util.Objects.hash(Objects.java:146)
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledRenderUnitCapabilityImpl.hashCode(BundledRenderUnitCapabilityImpl.java:115)
 [org.apache.sling.servlets.resolver:2.11.2]
at java.base/java.util.Arrays.hashCode(Arrays.java:4685)
at java.base/java.util.Objects.hash(Objects.java:146)
at 
org.apache.sling.servlets.resolver.internal.bundle.TypeProviderImpl.hashCode(TypeProviderImpl.java:53)
 [org.apache.sling.servlets.resolver:2.11.2]
at java.base/java.util.HashMap.hash(HashMap.java:340)
at java.base/java.util.HashMap.put(HashMap.java:608)
at java.base/java.util.HashSet.add(HashSet.java:220)
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:678)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
[...]
at 
 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.reso

[jira] [Updated] (SLING-12431) [BundledScriptTracker] StackOverflow / endless recursion

2024-09-16 Thread Joerg Hoh (Jira)


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

Joerg Hoh updated SLING-12431:
--
Description: 
{noformat}
[FelixLogListener] Events.Framework.org.apache.sling.servlets.resolver 
FrameworkEvent ERROR (java.lang.StackOverflowError)
java.lang.StackOverflowError: null
at java.base/java.util.HashSet.iterator(HashSet.java:173)
at java.base/java.util.AbstractSet.hashCode(AbstractSet.java:120)
at java.base/java.util.Arrays.hashCode(Arrays.java:4685)
at java.base/java.util.Objects.hash(Objects.java:146)
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledRenderUnitCapabilityImpl.hashCode(BundledRenderUnitCapabilityImpl.java:115)
 [org.apache.sling.servlets.resolver:2.11.2]
at java.base/java.util.Arrays.hashCode(Arrays.java:4685)
at java.base/java.util.Objects.hash(Objects.java:146)
at 
org.apache.sling.servlets.resolver.internal.bundle.TypeProviderImpl.hashCode(TypeProviderImpl.java:53)
 [org.apache.sling.servlets.resolver:2.11.2]
at java.base/java.util.HashMap.hash(HashMap.java:340)
at java.base/java.util.HashMap.put(HashMap.java:608)
at java.base/java.util.HashSet.add(HashSet.java:220)
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:678)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
[...]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
{noformat}
Unfortunately I don't have the entire call trace here, but we should have a way 
to prevent that StackOverflow.


  was:
{noformat}
[FelixLogListener] Events.Framework.org.apache.sling.servlets.resolver 
FrameworkEvent ERROR (java.lang.StackOverflowError)
java.lang.StackOverflowError: null
at java.base/java.util.HashSet.iterator(HashSet.java:173)
at java.base/java.util.AbstractSet.hashCode(AbstractSet.java:120)
at java.base/java.util.Arrays.hashCode(Arrays.java:4685)
at java.base/java.util.Objects.hash(Objects.java:146)
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledRenderUnitCapabilityImpl.hashCode(BundledRenderUnitCapabilityImpl.java:115)
 [org.apache.sling.servlets.resolver:2.11.2]
at java.base/java.util.Arrays.hashCode(Arrays.java:4685)
at java.base/java.util.Objects.hash(Objects.java:146)
at 
org.apache.sling.servlets.resolver.internal.bundle.TypeProviderImpl.hashCode(TypeProviderImpl.java:53)
 [org.apache.sling.servlets.resolver:2.11.2]
at java.base/java.util.HashMap.hash(HashMap.java:340)
at java.base/java.util.HashMap.put(HashMap.java:608)
at java.base/java.util.HashSet.add(HashSet.java:220)
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:678)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
[...]
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bun

[jira] [Updated] (SLING-12431) [BundledScriptTracker] StackOverflow / endless recursion

2024-09-16 Thread Joerg Hoh (Jira)


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

Joerg Hoh updated SLING-12431:
--
Description: 
{noformat}
[FelixLogListener] Events.Framework.org.apache.sling.servlets.resolver 
FrameworkEvent ERROR (java.lang.StackOverflowError)
java.lang.StackOverflowError: null
at java.base/java.util.HashSet.iterator(HashSet.java:173)
at java.base/java.util.AbstractSet.hashCode(AbstractSet.java:120)
at java.base/java.util.Arrays.hashCode(Arrays.java:4685)
at java.base/java.util.Objects.hash(Objects.java:146)
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledRenderUnitCapabilityImpl.hashCode(BundledRenderUnitCapabilityImpl.java:115)
 [org.apache.sling.servlets.resolver:2.11.2]
at java.base/java.util.Arrays.hashCode(Arrays.java:4685)
at java.base/java.util.Objects.hash(Objects.java:146)
at 
org.apache.sling.servlets.resolver.internal.bundle.TypeProviderImpl.hashCode(TypeProviderImpl.java:53)
 [org.apache.sling.servlets.resolver:2.11.2]
at java.base/java.util.HashMap.hash(HashMap.java:340)
at java.base/java.util.HashMap.put(HashMap.java:608)
at java.base/java.util.HashSet.add(HashSet.java:220)
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:678)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
[...]
at 
 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
{noformat}
Unfortunately I don't have the entire call trace here, but we should have a way 
to prevent that StackOverflow.

  was:
{noformat}
[FelixLogListener] Events.Framework.org.apache.sling.servlets.resolver 
FrameworkEvent ERROR (java.lang.StackOverflowError)
java.lang.StackOverflowError: null
at java.base/java.util.HashSet.iterator(HashSet.java:173)
at java.base/java.util.AbstractSet.hashCode(AbstractSet.java:120)
at java.base/java.util.Arrays.hashCode(Arrays.java:4685)
at java.base/java.util.Objects.hash(Objects.java:146)
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledRenderUnitCapabilityImpl.hashCode(BundledRenderUnitCapabilityImpl.java:115)
 [org.apache.sling.servlets.resolver:2.11.2]
at java.base/java.util.Arrays.hashCode(Arrays.java:4685)
at java.base/java.util.Objects.hash(Objects.java:146)
at 
org.apache.sling.servlets.resolver.internal.bundle.TypeProviderImpl.hashCode(TypeProviderImpl.java:53)
 [org.apache.sling.servlets.resolver:2.11.2]
at java.base/java.util.HashMap.hash(HashMap.java:340)
at java.base/java.util.HashMap.put(HashMap.java:608)
at java.base/java.util.HashSet.add(HashSet.java:220)
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:678)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
[...]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.reso

[jira] [Updated] (SLING-12417) [Compiled Scripts] Add healthcheck for loading capabilities

2024-09-16 Thread Joerg Hoh (Jira)


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

Joerg Hoh updated SLING-12417:
--
Affects Version/s: Servlets Resolver 2.11.2

> [Compiled Scripts] Add healthcheck for loading capabilities
> ---
>
> Key: SLING-12417
> URL: https://issues.apache.org/jira/browse/SLING-12417
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Affects Versions: Servlets Resolver 2.11.2
>Reporter: Joerg Hoh
>Priority: Major
>
> When using precompiled scripts, the information about the scriptlets are 
> exposed by the bundle using capabilities. These capabilities are loaded 
> async, and it's unclear when the loading process is completed (no log 
> statement indicating this).
> We should have a healthcheck which exposes the information, that processing 
> of capabilities is ongoing (or not). This combined with the information that 
> all bundles are active should give a good indication, if it's safe to start 
> request handling.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (SLING-12434) [BundledScriptTracker] Invalid BundleContext

2024-09-13 Thread Joerg Hoh (Jira)


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

Joerg Hoh updated SLING-12434:
--
Summary: [BundledScriptTracker] Invalid BundleContext  (was: 
[BundledScriptTracker] Invalid BundlelContext)

> [BundledScriptTracker] Invalid BundleContext
> 
>
> Key: SLING-12434
> URL: https://issues.apache.org/jira/browse/SLING-12434
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Servlets Resolver 2.11.2
>Reporter: Joerg Hoh
>Priority: Major
>
> {noformat}
> [FelixLogListener] 
> org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker 
> bundle org.apache.sling.servlets.resolver:2.11.2 
> (360)[org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker(1293)]
>  : The activate method has thrown an exception 
> (java.lang.IllegalStateException: Invalid BundleContext.)
> java.lang.IllegalStateException: Invalid BundleContext.
>   at 
> org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:491)
>   at 
> org.apache.felix.framework.BundleContextImpl.getBundle(BundleContextImpl.java:94)
>   at 
> org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker$1.invoke(BundledScriptTracker.java:354)
>  [org.apache.sling.servlets.resolver:2.11.2]
>   at com.sun.proxy.$Proxy327.getBundle(Unknown Source)
>   at 
> org.apache.sling.servlets.resolver.internal.resource.ServletMounter.createServlet(ServletMounter.java:230)
>  [org.apache.sling.servlets.resolver:2.11.2]
>   at 
> org.apache.sling.servlets.resolver.internal.resource.ServletMounter.bindServlet(ServletMounter.java:175)
>  [org.apache.sling.servlets.resolver:2.11.2]
>   at 
> org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.register(BundledScriptTracker.java:425)
>  [org.apache.sling.servlets.resolver:2.11.2]
>   at 
> org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.lambda$addingBundle$9(BundledScriptTracker.java:314)
>  [org.apache.sling.servlets.resolver:2.11.2]
>   at 
> java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:271)
>   at 
> java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1620)
>   at 
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>   at 
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
>   at 
> java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
>   at 
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
>   at 
> java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578)
>   at 
> org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.addingBundle(BundledScriptTracker.java:321)
>  [org.apache.sling.servlets.resolver:2.11.2]
>   at 
> org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.addingBundle(BundledScriptTracker.java:93)
>  [org.apache.sling.servlets.resolver:2.11.2]
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (SLING-12434) [BundledScriptTracker] Invalid BundlelContext

2024-09-13 Thread Joerg Hoh (Jira)
Joerg Hoh created SLING-12434:
-

 Summary: [BundledScriptTracker] Invalid BundlelContext
 Key: SLING-12434
 URL: https://issues.apache.org/jira/browse/SLING-12434
 Project: Sling
  Issue Type: Bug
  Components: Scripting
Affects Versions: Servlets Resolver 2.11.2
Reporter: Joerg Hoh



{noformat}
[FelixLogListener] 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker bundle 
org.apache.sling.servlets.resolver:2.11.2 
(360)[org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker(1293)]
 : The activate method has thrown an exception 
(java.lang.IllegalStateException: Invalid BundleContext.)
java.lang.IllegalStateException: Invalid BundleContext.
at 
org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:491)
at 
org.apache.felix.framework.BundleContextImpl.getBundle(BundleContextImpl.java:94)
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker$1.invoke(BundledScriptTracker.java:354)
 [org.apache.sling.servlets.resolver:2.11.2]
at com.sun.proxy.$Proxy327.getBundle(Unknown Source)
at 
org.apache.sling.servlets.resolver.internal.resource.ServletMounter.createServlet(ServletMounter.java:230)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.resource.ServletMounter.bindServlet(ServletMounter.java:175)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.register(BundledScriptTracker.java:425)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.lambda$addingBundle$9(BundledScriptTracker.java:314)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:271)
at 
java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1620)
at 
java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
at 
java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
at 
java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
at 
java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at 
java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578)
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.addingBundle(BundledScriptTracker.java:321)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.addingBundle(BundledScriptTracker.java:93)
 [org.apache.sling.servlets.resolver:2.11.2]
{noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (SLING-12433) [BundledScriptTracker] ConcurrentModificationException

2024-09-13 Thread Joerg Hoh (Jira)
Joerg Hoh created SLING-12433:
-

 Summary: [BundledScriptTracker] ConcurrentModificationException
 Key: SLING-12433
 URL: https://issues.apache.org/jira/browse/SLING-12433
 Project: Sling
  Issue Type: Bug
  Components: Scripting
Affects Versions: Servlets Resolver 2.11.2
Reporter: Joerg Hoh



{noformat}
[FelixLogListener] 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker bundle 
org.apache.sling.servlets.resolver:2.11.2 
(360)[org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker(1294)]
 : The activate method has thrown an exception 
(java.util.ConcurrentModificationException)
java.util.ConcurrentModificationException: null
at java.base/java.util.HashMap$HashIterator.nextNode(HashMap.java:1510)
at java.base/java.util.HashMap$KeyIterator.next(HashMap.java:1533)
at 
org.apache.sling.servlets.resolver.internal.resource.ServletMounter.createServlet(ServletMounter.java:241)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.resource.ServletMounter.bindServlet(ServletMounter.java:175)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.register(BundledScriptTracker.java:425)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.lambda$addingBundle$9(BundledScriptTracker.java:314)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:271)
at 
java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1620)
at 
java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
at 
java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
at 
java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
at 
java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at 
java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578)
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.addingBundle(BundledScriptTracker.java:321)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.addingBundle(BundledScriptTracker.java:93)
 [org.apache.sling.servlets.resolver:2.11.2]
[...]
{noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (SLING-12432) [BundledScriptTracker] NPE when stopping bundle

2024-09-13 Thread Joerg Hoh (Jira)
Joerg Hoh created SLING-12432:
-

 Summary: [BundledScriptTracker] NPE when stopping bundle
 Key: SLING-12432
 URL: https://issues.apache.org/jira/browse/SLING-12432
 Project: Sling
  Issue Type: Bug
  Components: Scripting
Affects Versions: Servlets Resolver 2.11.2
Reporter: Joerg Hoh


 

{noformat}
[FelixLogListener] Events.Framework.org.apache.sling.servlets.resolver 
FrameworkEvent ERROR (java.lang.NullPointerException)
java.lang.NullPointerException: null
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.refreshDispatcher(BundledScriptTracker.java:515)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.removedBundle(BundledScriptTracker.java:548)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.removedBundle(BundledScriptTracker.java:93)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.osgi.util.tracker.BundleTracker$Tracked.customizerRemoved(BundleTracker.java:501)
at 
org.osgi.util.tracker.BundleTracker$Tracked.customizerRemoved(BundleTracker.java:420)
at 
org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341)
at 
org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:456)
at 
org.apache.felix.framework.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:915)
at 
org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:834)
at 
org.apache.felix.framework.EventDispatcher.fireBundleEvent(EventDispatcher.java:516)
at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4847)
at org.apache.felix.framework.Felix.stopBundle(Felix.java:2812)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1584)
at 
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:297)
at java.base/java.lang.Thread.run(Thread.java:834)
{noformat}
 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (SLING-12431) [BundledScriptTracker] StackOverflow / endless recursion

2024-09-13 Thread Joerg Hoh (Jira)


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

Joerg Hoh updated SLING-12431:
--
Description: 
{noformat}
[FelixLogListener] Events.Framework.org.apache.sling.servlets.resolver 
FrameworkEvent ERROR (java.lang.StackOverflowError)
java.lang.StackOverflowError: null
at java.base/java.util.HashSet.iterator(HashSet.java:173)
at java.base/java.util.AbstractSet.hashCode(AbstractSet.java:120)
at java.base/java.util.Arrays.hashCode(Arrays.java:4685)
at java.base/java.util.Objects.hash(Objects.java:146)
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledRenderUnitCapabilityImpl.hashCode(BundledRenderUnitCapabilityImpl.java:115)
 [org.apache.sling.servlets.resolver:2.11.2]
at java.base/java.util.Arrays.hashCode(Arrays.java:4685)
at java.base/java.util.Objects.hash(Objects.java:146)
at 
org.apache.sling.servlets.resolver.internal.bundle.TypeProviderImpl.hashCode(TypeProviderImpl.java:53)
 [org.apache.sling.servlets.resolver:2.11.2]
at java.base/java.util.HashMap.hash(HashMap.java:340)
at java.base/java.util.HashMap.put(HashMap.java:608)
at java.base/java.util.HashSet.add(HashSet.java:220)
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:678)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
[...]
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
{noformat}
Unfortunately I don't have the entire call trace here, but we should have a way 
to prevent that StackOverflow.


  was:

{noformat}
[FelixLogListener] Events.Framework.org.apache.sling.servlets.resolver 
FrameworkEvent ERROR (java.lang.StackOverflowError)
java.lang.StackOverflowError: null
at java.base/java.util.HashSet.iterator(HashSet.java:173)
at java.base/java.util.AbstractSet.hashCode(AbstractSet.java:120)
at java.base/java.util.Arrays.hashCode(Arrays.java:4685)
at java.base/java.util.Objects.hash(Objects.java:146)
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledRenderUnitCapabilityImpl.hashCode(BundledRenderUnitCapabilityImpl.java:115)
 [org.apache.sling.servlets.resolver:2.11.2]
at java.base/java.util.Arrays.hashCode(Arrays.java:4685)
at java.base/java.util.Objects.hash(Objects.java:146)
at 
org.apache.sling.servlets.resolver.internal.bundle.TypeProviderImpl.hashCode(TypeProviderImpl.java:53)
 [org.apache.sling.servlets.resolver:2.11.2]
at java.base/java.util.HashMap.hash(HashMap.java:340)
at java.base/java.util.HashMap.put(HashMap.java:608)
at java.base/java.util.HashSet.add(HashSet.java:220)
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:678)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
[...]
{noformat}
Unfortunately I don't have the entire call trace here, but we should have a way 
to prevent that StackOverflow.



> [BundledScriptTracker] StackOverflow / endless recursion
> 
>
> Key: SLING-12431
> URL: https://issues.apache.org/jira/browse/SLING-12431
> Project: Sling
>  Issue Type: Bug
>  Component

[jira] [Created] (SLING-12431) [BundledScriptTracker] StackOverflow / endless recursion

2024-09-13 Thread Joerg Hoh (Jira)
Joerg Hoh created SLING-12431:
-

 Summary: [BundledScriptTracker] StackOverflow / endless recursion
 Key: SLING-12431
 URL: https://issues.apache.org/jira/browse/SLING-12431
 Project: Sling
  Issue Type: Bug
  Components: Scripting
Affects Versions: Servlets Resolver 2.11.2
Reporter: Joerg Hoh



{noformat}
[FelixLogListener] Events.Framework.org.apache.sling.servlets.resolver 
FrameworkEvent ERROR (java.lang.StackOverflowError)
java.lang.StackOverflowError: null
at java.base/java.util.HashSet.iterator(HashSet.java:173)
at java.base/java.util.AbstractSet.hashCode(AbstractSet.java:120)
at java.base/java.util.Arrays.hashCode(Arrays.java:4685)
at java.base/java.util.Objects.hash(Objects.java:146)
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledRenderUnitCapabilityImpl.hashCode(BundledRenderUnitCapabilityImpl.java:115)
 [org.apache.sling.servlets.resolver:2.11.2]
at java.base/java.util.Arrays.hashCode(Arrays.java:4685)
at java.base/java.util.Objects.hash(Objects.java:146)
at 
org.apache.sling.servlets.resolver.internal.bundle.TypeProviderImpl.hashCode(TypeProviderImpl.java:53)
 [org.apache.sling.servlets.resolver:2.11.2]
at java.base/java.util.HashMap.hash(HashMap.java:340)
at java.base/java.util.HashMap.put(HashMap.java:608)
at java.base/java.util.HashSet.add(HashSet.java:220)
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:678)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.collectInheritanceChain(BundledScriptTracker.java:681)
 [org.apache.sling.servlets.resolver:2.11.2]
[...]
{noformat}
Unfortunately I don't have the entire call trace here, but we should have a way 
to prevent that StackOverflow.




--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (SLING-12430) BundledScriptTracker: NPE when registering servlet

2024-09-13 Thread Joerg Hoh (Jira)


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

Joerg Hoh updated SLING-12430:
--
Description: 
{noformat}
 [FelixLogListener] 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker bundle 
org.apache.sling.servlets.resolver:2.11.2 
(360)[org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker(1313)]
 : The activate method has thrown an exception (java.lang.NullPointerException)
java.lang.NullPointerException: null
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker$1.invoke(BundledScriptTracker.java:354)
 [org.apache.sling.servlets.resolver:2.11.2]
at com.sun.proxy.$Proxy381.getBundle(Unknown Source)
at 
org.apache.sling.servlets.resolver.internal.resource.ServletMounter.createServlet(ServletMounter.java:230)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.resource.ServletMounter.bindServlet(ServletMounter.java:175)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.register(BundledScriptTracker.java:425)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.lambda$addingBundle$9(BundledScriptTracker.java:314)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:271)
at 
java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1620)
at 
java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
at 
java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
at 
java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
at 
java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at 
java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578)
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.addingBundle(BundledScriptTracker.java:321)
 [org.apache.sling.servlets.resolver:2.11.2]
[...]
{noformat}

This seems like a race condition because the BundleContext is null here.


  was:

{noformat}
 [FelixLogListener] 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker bundle 
org.apache.sling.servlets.resolver:2.11.2 
(360)[org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker(1313)]
 : The activate method has thrown an exception (java.lang.NullPointerException)
java.lang.NullPointerException: null
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker$1.invoke(BundledScriptTracker.java:354)
 [org.apache.sling.servlets.resolver:2.11.2]
at com.sun.proxy.$Proxy381.getBundle(Unknown Source)
at 
org.apache.sling.servlets.resolver.internal.resource.ServletMounter.createServlet(ServletMounter.java:230)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.resource.ServletMounter.bindServlet(ServletMounter.java:175)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.register(BundledScriptTracker.java:425)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.lambda$addingBundle$9(BundledScriptTracker.java:314)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:271)
at 
java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1620)
at 
java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
at 
java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
at 
java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
at 
java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at 
java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578)
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.addingBundle(BundledScriptTracker.java:321)
 [org.apache.sling.servlets.resolver:2.11.2]
[...]
{noformat}


> BundledScriptTracker: NPE when registering servlet
> --
>
> Key: SLING-12430
> URL: https://issues.apache.org/jira/browse/SLING-12430
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Affects Versions: Servlets Resolver 2.11.2
>Reporter: Joerg Hoh
>Priority: Major
>
> {noformat}
>  [FelixLogListener] 
> org.apache.s

[jira] [Created] (SLING-12430) BundledScriptTracker: NPE when registering servlet

2024-09-13 Thread Joerg Hoh (Jira)
Joerg Hoh created SLING-12430:
-

 Summary: BundledScriptTracker: NPE when registering servlet
 Key: SLING-12430
 URL: https://issues.apache.org/jira/browse/SLING-12430
 Project: Sling
  Issue Type: Improvement
  Components: Scripting
Affects Versions: Servlets Resolver 2.11.2
Reporter: Joerg Hoh



{noformat}
 [FelixLogListener] 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker bundle 
org.apache.sling.servlets.resolver:2.11.2 
(360)[org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker(1313)]
 : The activate method has thrown an exception (java.lang.NullPointerException)
java.lang.NullPointerException: null
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker$1.invoke(BundledScriptTracker.java:354)
 [org.apache.sling.servlets.resolver:2.11.2]
at com.sun.proxy.$Proxy381.getBundle(Unknown Source)
at 
org.apache.sling.servlets.resolver.internal.resource.ServletMounter.createServlet(ServletMounter.java:230)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.resource.ServletMounter.bindServlet(ServletMounter.java:175)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.register(BundledScriptTracker.java:425)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.lambda$addingBundle$9(BundledScriptTracker.java:314)
 [org.apache.sling.servlets.resolver:2.11.2]
at 
java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:271)
at 
java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1620)
at 
java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
at 
java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
at 
java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
at 
java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at 
java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578)
at 
org.apache.sling.servlets.resolver.internal.bundle.BundledScriptTracker.addingBundle(BundledScriptTracker.java:321)
 [org.apache.sling.servlets.resolver:2.11.2]
[...]
{noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (SLING-12429) Only use editable queues when computing max queue size

2024-09-13 Thread Joerg Hoh (Jira)


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

Joerg Hoh updated SLING-12429:
--
Description: 
We currently compute max queue size by looking at all queues. 
This can create issues when a consumer lags behind.

We should only look at the editable queues as these are processed first with 
staged replication.

  was:
We currently compute max queue size by looking at all queues. 
This can create issues when a pod lags behind.

We should only look at the editable queues as these are processed first with 
staged replication.


> Only use editable queues when computing max queue size
> --
>
> Key: SLING-12429
> URL: https://issues.apache.org/jira/browse/SLING-12429
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Christian Schneider
>Assignee: Christian Schneider
>Priority: Major
> Fix For: Content Distribution Journal Core 0.5.0
>
>
> We currently compute max queue size by looking at all queues. 
> This can create issues when a consumer lags behind.
> We should only look at the editable queues as these are processed first with 
> staged replication.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (SLING-11971) Log duration of each PostProcessor

2024-09-07 Thread Joerg Hoh (Jira)


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

Joerg Hoh resolved SLING-11971.
---
Resolution: Fixed

> Log duration of each PostProcessor
> --
>
> Key: SLING-11971
> URL: https://issues.apache.org/jira/browse/SLING-11971
> Project: Sling
>  Issue Type: Task
>  Components: Servlets
>Affects Versions: Servlets POST 2.5.0
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: Servlets POST 2.6.2
>
>
> The Sling Post Servlet should log the duration of each postprocessor into the 
> RequestProgressTracker, which allows to debug potential performance issues 
> easier.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Comment Edited] (SLING-11038) Change statuscode in SlingPostServlet for PersistenceException, take 2

2024-09-06 Thread Joerg Hoh (Jira)


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

Joerg Hoh edited comment on SLING-11038 at 9/6/24 5:24 PM:
---

Redundant, as in 2.4.4 more code has been converted not to throw a 
PersistenceException anymore (SLING-10087). Also including the {{doRun}} call 
into the {{try-catch}} clause does not change any behavior. 

Thus marking it as duplicate.


was (Author: joerghoh):
Mostly redundant, as in 2.4.4 more code has been converted not to throw a 
PersistenceException anymore (SLING-10087). Also including the {{doRun}} call 
into the {{try-catch}} clause does not change any behavior. 

Thus marking it as duplicate.

> Change statuscode in SlingPostServlet for PersistenceException, take 2
> --
>
> Key: SLING-11038
> URL: https://issues.apache.org/jira/browse/SLING-11038
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Affects Versions: Servlets Post 2.3.36
>Reporter: Thomas Mueller
>Assignee: Robert Munteanu
>Priority: Major
>
> When the SlingPostServlet receives a PersistenceExceptions (e.g. when trying 
> to POST to a read-only resource), Resource at '...' is not modifiable, then a 
> 500 is returned
> This is similar to SLING-9896, but has a different code path.
> Example stacktrace:
> {noformat}
> 03.01.2022 10:45:54.476 *ERROR* [179.60.150.135 [1641206754473] POST 
> /content/dpc/inpro-seal//it/search.html HTTP/1.1] 
> org.apache.sling.servlets.post.impl.operations.ModifyOperation Exception 
> during response processing.
> org.apache.sling.api.resource.PersistenceException: Resource at 
> '/content/dpc/inpro-seal/it/search' is not modifiable.
>   at 
> org.apache.sling.servlets.post.impl.helper.SlingPropertyValueHandler.setProperty(SlingPropertyValueHandler.java:114)
>  [org.apache.sling.servlets.post:2.4.2]
>   at 
> org.apache.sling.servlets.post.impl.operations.ModifyOperation.writeContent(ModifyOperation.java:372)
>  [org.apache.sling.servlets.post:2.4.2]
>   at 
> org.apache.sling.servlets.post.impl.operations.ModifyOperation.doRun(ModifyOperation.java:93)
>  [org.apache.sling.servlets.post:2.4.2]
>   at 
> org.apache.sling.servlets.post.impl.operations.AbstractPostOperation.run(AbstractPostOperation.java:105)
>  [org.apache.sling.servlets.post:2.4.2]
>   at 
> org.apache.sling.servlets.post.impl.SlingPostServlet.doPost(SlingPostServlet.java:243)
>  [org.apache.sling.servlets.post:2.4.2]
>   at 
> org.apache.sling.api.servlets.SlingAllMethodsServlet.mayService(SlingAllMethodsServlet.java:146)
>  [org.apache.sling.api:2.22.0]
>   at 
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:342)
>  [org.apache.sling.api:2.22.0]
>   at 
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:374)
>  [org.apache.sling.api:2.22.0]
>   at 
> org.apache.sling.engine.impl.request.RequestData.service(RequestData.java:552)
>  [org.apache.sling.engine:2.7.2]
>   at 
> org.apache.sling.engine.impl.filter.SlingComponentFilterChain.render(SlingComponentFilterChain.java:44)
>  [org.apache.sling.engine:2.7.2]
> {noformat}
> The problem is in
> https://github.com/apache/sling-org-apache-sling-servlets-post/blob/org.apache.sling.servlets.post-2.4.2/src/main/java/org/apache/sling/servlets/post/impl/operations/AbstractPostOperation.java#L105
> {noformat}
> public void run(final SlingHttpServletRequest request,
> final PostResponse response,
> final SlingPostProcessor[] processors) throws 
> PreconditionViolatedPersistenceException, TemporaryPersistenceException {
> final VersioningConfiguration versionableConfiguration = 
> getVersioningConfiguration(request);
> try {
> ...
> doRun(request, response, changes); <<== here
> ...
> } catch (Exception e) {
> log.error("Exception during response processing.", e);
> response.setError(e);
> } finally {
> ...
> }
> }
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (SLING-11971) Log duration of each PostProcessor

2024-09-06 Thread Joerg Hoh (Jira)


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

Joerg Hoh commented on SLING-11971:
---

Merged https://github.com/apache/sling-org-apache-sling-servlets-post/pull/27 
instead (much simpler).

> Log duration of each PostProcessor
> --
>
> Key: SLING-11971
> URL: https://issues.apache.org/jira/browse/SLING-11971
> Project: Sling
>  Issue Type: Task
>  Components: Servlets
>Affects Versions: Servlets POST 2.5.0
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
>
> The Sling Post Servlet should log the duration of each postprocessor into the 
> RequestProgressTracker, which allows to debug potential performance issues 
> easier.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (SLING-11971) Log duration of each PostProcessor

2024-09-06 Thread Joerg Hoh (Jira)


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

Joerg Hoh updated SLING-11971:
--
Fix Version/s: Servlets POST 2.6.2

> Log duration of each PostProcessor
> --
>
> Key: SLING-11971
> URL: https://issues.apache.org/jira/browse/SLING-11971
> Project: Sling
>  Issue Type: Task
>  Components: Servlets
>Affects Versions: Servlets POST 2.5.0
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: Servlets POST 2.6.2
>
>
> The Sling Post Servlet should log the duration of each postprocessor into the 
> RequestProgressTracker, which allows to debug potential performance issues 
> easier.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (SLING-12390) Mention IllegalStateException for order operation

2024-09-02 Thread Joerg Hoh (Jira)


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

Joerg Hoh closed SLING-12390.
-

> Mention IllegalStateException for order operation
> -
>
> Key: SLING-12390
> URL: https://issues.apache.org/jira/browse/SLING-12390
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Affects Versions: API 2.27.2
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: API 2.27.4
>
>
> The javadoc of the orderBefore operation is missing to mention that an 
> IllegalStateException is thrown if the resolver is already closed



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (SLING-11501) Commons-Metrics: Cleanup

2024-09-01 Thread Joerg Hoh (Jira)


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

Joerg Hoh resolved SLING-11501.
---
Resolution: Resolved

(indeed done)

> Commons-Metrics: Cleanup
> 
>
> Key: SLING-11501
> URL: https://issues.apache.org/jira/browse/SLING-11501
> Project: Sling
>  Issue Type: Task
>  Components: Commons
>Affects Versions: Commons Metrics 1.2.10
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: Commons Metrics 1.2.14
>
>
> Some cleanup should be made:
>  * Github PRs should trigger the Jenkins build with Java 11 and 17 (see 
> https://github.com/apache/sling-org-apache-sling-commons-threads/blob/master/.sling-module.json)
>  * Update to require Java 11 as build and runtime version
>  * Cleanup test suite and remove deprecations



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Reopened] (SLING-11501) Commons-Metrics: Cleanup

2024-08-30 Thread Joerg Hoh (Jira)


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

Joerg Hoh reopened SLING-11501:
---

not fixed yet, incorrect ticket status.

> Commons-Metrics: Cleanup
> 
>
> Key: SLING-11501
> URL: https://issues.apache.org/jira/browse/SLING-11501
> Project: Sling
>  Issue Type: Task
>  Components: Commons
>Affects Versions: Commons Metrics 1.2.10
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: Commons Metrics 1.2.14
>
>
> Some cleanup should be made:
>  * Github PRs should trigger the Jenkins build with Java 11 and 17 (see 
> https://github.com/apache/sling-org-apache-sling-commons-threads/blob/master/.sling-module.json)
>  * Update to require Java 11 as build and runtime version
>  * Cleanup test suite and remove deprecations



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (SLING-12264) check save() operations

2024-08-30 Thread Joerg Hoh (Jira)


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

Joerg Hoh closed SLING-12264.
-

> check save() operations
> ---
>
> Key: SLING-12264
> URL: https://issues.apache.org/jira/browse/SLING-12264
> Project: Sling
>  Issue Type: Task
>  Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.46
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: Repoinit JCR 1.1.52
>
>
> Before doing a session.save() operation, it should always be checked if there 
> is something to save at all. 
> This can speed up the execution of individual repoinit statements if the 
> repoinit statement does not need to be applied.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (SLING-12262) Repoinit: report failures via metrics

2024-08-30 Thread Joerg Hoh (Jira)


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

Joerg Hoh closed SLING-12262.
-

> Repoinit: report failures via metrics
> -
>
> Key: SLING-12262
> URL: https://issues.apache.org/jira/browse/SLING-12262
> Project: Sling
>  Issue Type: Task
>  Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.46
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: Repoinit JCR 1.1.52
>
>
> When a repoinit statement fails (and for that reason the SlingRepository 
> service cannot be started, repoinit should expose this as a metric.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (SLING-11147) Configure Maven Failsafe Plugin to run build successfully on Java 17 (JPMS)

2024-08-30 Thread Joerg Hoh (Jira)


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

Joerg Hoh closed SLING-11147.
-

> Configure Maven Failsafe Plugin to run build successfully on Java 17 (JPMS)
> ---
>
> Key: SLING-11147
> URL: https://issues.apache.org/jira/browse/SLING-11147
> Project: Sling
>  Issue Type: Task
>  Components: Commons
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>Priority: Major
> Fix For: Commons Threads 3.3.0
>
>
> * building with JDK 11 and 17 (JDK 8 does not support JPMS)
>  * opening java.base/java.lang to Commons Threads ({*}Surefire{*} NOT 
> Failsafe, keeping issue title to match commit)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (SLING-11993) Threadpool: number of tasks in the work queue should be available via metrics/JMX

2024-08-30 Thread Joerg Hoh (Jira)


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

Joerg Hoh closed SLING-11993.
-

> Threadpool: number of tasks in the work queue should be available via 
> metrics/JMX
> -
>
> Key: SLING-11993
> URL: https://issues.apache.org/jira/browse/SLING-11993
> Project: Sling
>  Issue Type: Task
>  Components: Commons
>Affects Versions: Commons Threads 3.2.22
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: Commons Threads 3.3.0
>
>
> There should be a metric/Mbean which tracks the number of tasks 
> (callables/runnables) to the threadpool, which are not yet processed, so the 
> number of entries in the work queue.
> getExectutorTaskCount() on the MBean lists the total number of processed task 
> plus the number of of tasks in the workqueue, so it's not usable here, so the 
> MBean interface must be extended by a new  
> {{getExcutorTasksInWorkQueueCount()}}, which returns the size of the work 
> queue.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (SLING-11994) update parent

2024-08-30 Thread Joerg Hoh (Jira)


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

Joerg Hoh closed SLING-11994.
-

> update parent
> -
>
> Key: SLING-11994
> URL: https://issues.apache.org/jira/browse/SLING-11994
> Project: Sling
>  Issue Type: Task
>  Components: Commons
>Affects Versions: Commons Threads 3.2.22
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: Commons Threads 3.3.0
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (SLING-11145) Update to Sling Bundle Parent 47

2024-08-30 Thread Joerg Hoh (Jira)


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

Joerg Hoh closed SLING-11145.
-

> Update to Sling Bundle Parent 47
> 
>
> Key: SLING-11145
> URL: https://issues.apache.org/jira/browse/SLING-11145
> Project: Sling
>  Issue Type: Task
>  Components: Commons
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>Priority: Major
> Fix For: Commons Threads 3.3.0
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (SLING-11146) Add initial JPMS support

2024-08-30 Thread Joerg Hoh (Jira)


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

Joerg Hoh closed SLING-11146.
-

> Add initial JPMS support
> 
>
> Key: SLING-11146
> URL: https://issues.apache.org/jira/browse/SLING-11146
> Project: Sling
>  Issue Type: New Feature
>  Components: Commons
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>Priority: Major
> Fix For: Commons Threads 3.3.0
>
>
> * adding module info
>  * narrowing dependency down to OSGi Configuration Admin
>  * updating slf4j to use new module name



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (SLING-10836) Update commons.threads to parent pom 45

2024-08-30 Thread Joerg Hoh (Jira)


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

Joerg Hoh closed SLING-10836.
-

> Update commons.threads to parent pom 45
> ---
>
> Key: SLING-10836
> URL: https://issues.apache.org/jira/browse/SLING-10836
> Project: Sling
>  Issue Type: Sub-task
>  Components: Commons
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Commons Threads 3.3.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (SLING-12212) Don't emit stacktrace when ThreadPoolExecutorCleaningThreadLocals cannot be initialized

2024-08-30 Thread Joerg Hoh (Jira)


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

Joerg Hoh closed SLING-12212.
-

> Don't emit stacktrace when ThreadPoolExecutorCleaningThreadLocals cannot be 
> initialized
> ---
>
> Key: SLING-12212
> URL: https://issues.apache.org/jira/browse/SLING-12212
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Affects Versions: Commons Threads 3.2.22
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: Commons Threads 3.3.0
>
>
> The mechanism introduced with SLING-6261 does no longer work with Java 9 and 
> above and always fails with
> {code}
> 27.12.2023 11:18:23 *WARN * [FelixStartLevel] o.a.s.c.t.i.DefaultThreadPool: 
> Unsupported JRE, cannot register ThreadPoolExecutorCleaningThreadLocals due 
> to 'null', fall back to regular ThreadPoolExecutor (DefaultThreadPool.java, 
> line 157)
> java.lang.ExceptionInInitializerError: null
>   at 
> org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocals.(ThreadPoolExecutorCleaningThreadLocals.java:52)
>   at 
> org.apache.sling.commons.threads.impl.DefaultThreadPool.(DefaultThreadPool.java:150)
>   at 
> org.apache.sling.commons.threads.impl.DefaultThreadPoolManager$Entry.incUsage(DefaultThreadPoolManager.java:371)
>   at 
> org.apache.sling.commons.threads.impl.DefaultThreadPoolManager.get(DefaultThreadPoolManager.java:143)
>   at 
> org.apache.sling.commons.scheduler.impl.SchedulerProxy.(SchedulerProxy.java:65)
>   at 
> org.apache.sling.commons.scheduler.impl.QuartzScheduler.scheduleJob(QuartzScheduler.java:588)
>   at 
> org.apache.sling.commons.scheduler.impl.QuartzScheduler.addPeriodicJob(QuartzScheduler.java:344)
>   at 
> org.apache.sling.commons.scheduler.impl.QuartzScheduler.addPeriodicJob(QuartzScheduler.java:329)
>   at 
> org.apache.sling.commons.scheduler.impl.GaugesSupport.activate(GaugesSupport.java:156)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.base/java.lang.reflect.Method.invoke(Method.java:568)
>   at 
> org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:245)
>   at 
> org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41)
>   at 
> org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:687)
>   at 
> org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:531)
>   at 
> org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:317)
>   at 
> org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:307)
>   at 
> org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:354)
>   at 
> org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:115)
>   at 
> org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:1002)
>   at 
> org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:975)
>   at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:785)
>   at 
> org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.addedService(DependencyManager.java:1274)
>   at 
> org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.addedService(DependencyManager.java:1225)
>   at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerAdded(ServiceTracker.java:1232)
>   at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerAdded(ServiceTracker.java:1152)
>   at 
> org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.trackAdding(ServiceTracker.java:959)
>   at 
> org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.track(ServiceTracker.java:895)
>   at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1184)
>   at 
> org.apache.felix.scr.impl.BundleComponentActivator$ListenerInfo.serviceChanged(BundleComponentActivator.java:116)
>   at 
> org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990)
>   at 
> org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838)
>   at 
> org.a

[jira] [Closed] (SLING-11161) Support testing with different JDKs

2024-08-30 Thread Joerg Hoh (Jira)


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

Joerg Hoh closed SLING-11161.
-

> Support testing with different JDKs
> ---
>
> Key: SLING-11161
> URL: https://issues.apache.org/jira/browse/SLING-11161
> Project: Sling
>  Issue Type: Task
>  Components: Commons
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>Priority: Major
> Fix For: Commons Threads 3.3.0
>
> Attachments: effective-pom.txt, toolchains.xml
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> -WIP:- 
> [https://github.com/apache/sling-org-apache-sling-commons-threads/tree/SLING-11161]
> Using 
> [toolchains|https://maven.apache.org/guides/mini/guide-using-toolchains.html] 
> in profile {{ci}} to support Java 8, 11 and 17 in tests with Surefire.
> See comments in SLING-11147.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (SLING-12417) [Compiled Scripts] Add healthcheck for loading capabilities

2024-08-30 Thread Joerg Hoh (Jira)
Joerg Hoh created SLING-12417:
-

 Summary: [Compiled Scripts] Add healthcheck for loading 
capabilities
 Key: SLING-12417
 URL: https://issues.apache.org/jira/browse/SLING-12417
 Project: Sling
  Issue Type: Improvement
  Components: Scripting
Reporter: Joerg Hoh


When using precompiled scripts, the information about the scriptlets are 
exposed by the bundle using capabilities. These capabilities are loaded async, 
and it's unclear when the loading process is completed (no log statement 
indicating this).

We should have a healthcheck which exposes the information, that processing of 
capabilities is ongoing (or not). This combined with the information that all 
bundles are active should give a good indication, if it's safe to start request 
handling.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (SLING-12348) update to parent 60

2024-08-27 Thread Joerg Hoh (Jira)


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

Joerg Hoh updated SLING-12348:
--
Fix Version/s: (was: Repoinit JCR 1.1.52)

> update to parent 60
> ---
>
> Key: SLING-12348
> URL: https://issues.apache.org/jira/browse/SLING-12348
> Project: Sling
>  Issue Type: Task
>  Components: Repoinit
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (SLING-5355) Create service users and ACLs from the provisioning model

2024-08-26 Thread Joerg Hoh (Jira)


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

Joerg Hoh closed SLING-5355.


> Create service users and ACLs from the provisioning model
> -
>
> Key: SLING-5355
> URL: https://issues.apache.org/jira/browse/SLING-5355
> Project: Sling
>  Issue Type: New Feature
>  Components: Repoinit
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Major
> Fix For: Slingstart Maven Plugin 1.4.2, Repoinit Parser 1.0.2, 
> Repoinit JCR 1.0.0
>
>
> As discussed in the "Removing loginAdministrative, how to test that, and 
> service username conventions" thread on our dev list [1] we need to be able 
> to create service users and set the corresponding ACLs from our provisioning 
> model.
> This should be implemented using distinct utility classes, one for the users 
> and one for the ACLs, that take simple mini-languages as input. This will 
> allow for reusing these utilities in test code for example.
> [1] http://markmail.org/message/kcvuhwfdald2dyuz
> *Edit: high-level requirements*
> As discussed in the "SLING-5355 - configs vs. content for ACLs and service 
> users" thread - http://markmail.org/message/tzno2via2wjckhuc
> * HR1 - Create service users and set their ACLs as defined in the Sling 
> instance's provisioning model.
> * HR2 - Create initial paths like /var/discovery, so that ACLs can be set on 
> them.
> * HR3 - Make the full text of the ACL definitions available at runtime for 
> auditing purposes (see Michael Marth's Dec.17 comment in SLING-5355). Also 
> useful for upgrades where merging with conflict detection is needed.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (SLING-10283) Defined dedicated RepoInit RuntimeException instead of throwing generic RuntimeException/IllegalStateException/IllegalArgumentException

2024-08-26 Thread Joerg Hoh (Jira)


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

Joerg Hoh closed SLING-10283.
-

> Defined dedicated RepoInit RuntimeException instead of throwing generic 
> RuntimeException/IllegalStateException/IllegalArgumentException
> ---
>
> Key: SLING-10283
> URL: https://issues.apache.org/jira/browse/SLING-10283
> Project: Sling
>  Issue Type: Improvement
>  Components: Repoinit
>Reporter: Angela Schreiber
>Priority: Major
> Fix For: Repoinit JCR 1.1.38
>
>
> Extracted from review finding for SLING-10281: 
> IMHO it would be better to throw dedicated repo-init-runtime-exceptions that 
> come with an error-code and a message instead of throwing RuntimeException, 
> IllegalStateException and IllegalArgumentException. 
> that would allow to document the various error codes along with explanations 
> of the root cause and instructions on how to fix the corresponding repo-init 
> statements.
> [~kwin], fyi.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (SLING-10283) Defined dedicated RepoInit RuntimeException instead of throwing generic RuntimeException/IllegalStateException/IllegalArgumentException

2024-08-26 Thread Joerg Hoh (Jira)


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

Joerg Hoh updated SLING-10283:
--
Fix Version/s: Repoinit JCR 1.1.38

> Defined dedicated RepoInit RuntimeException instead of throwing generic 
> RuntimeException/IllegalStateException/IllegalArgumentException
> ---
>
> Key: SLING-10283
> URL: https://issues.apache.org/jira/browse/SLING-10283
> Project: Sling
>  Issue Type: Improvement
>  Components: Repoinit
>Reporter: Angela Schreiber
>Priority: Major
> Fix For: Repoinit JCR 1.1.38
>
>
> Extracted from review finding for SLING-10281: 
> IMHO it would be better to throw dedicated repo-init-runtime-exceptions that 
> come with an error-code and a message instead of throwing RuntimeException, 
> IllegalStateException and IllegalArgumentException. 
> that would allow to document the various error codes along with explanations 
> of the root cause and instructions on how to fix the corresponding repo-init 
> statements.
> [~kwin], fyi.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (SLING-5778) o.a.s.repoinit.oak-jcr does not start due to missing org.apache.sling.provisioning.model package

2024-08-26 Thread Joerg Hoh (Jira)


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

Joerg Hoh closed SLING-5778.


> o.a.s.repoinit.oak-jcr does not start due to missing 
> org.apache.sling.provisioning.model package
> 
>
> Key: SLING-5778
> URL: https://issues.apache.org/jira/browse/SLING-5778
> Project: Sling
>  Issue Type: Bug
>  Components: Repoinit
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Launchpad Builder 9
>
>
> {noformat}10.06.2016 17:59:25.220 *INFO* [OsgiInstallerImpl] 
> org.apache.sling.installer.core.impl.tasks.BundleStartTask Could not start 
> bundle org.apache.sling.repoinit.oak-jcr [129]. Reason: {}. Will retry.
> org.osgi.framework.BundleException: Unable to resolve 
> org.apache.sling.repoinit.oak-jcr [129](R 129.0): missing requirement 
> [org.apache.sling.repoinit.oak-jcr [129](R 129.0)] osgi.wiring.package; 
> (&(osgi.wiring.package=org.apache.sling.provisioning.model)(version>=1.5.0)(!(version>=2.0.0)))
>  Unresolved requirements: [[org.apache.sling.repoinit.oak-jcr [129](R 129.0)] 
> osgi.wiring.package; 
> (&(osgi.wiring.package=org.apache.sling.provisioning.model)(version>=1.5.0)(!(version>=2.0.0)))]
> at 
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4111)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2117)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984)
> at 
> org.apache.sling.installer.core.impl.tasks.BundleStartTask.execute(BundleStartTask.java:93)
> at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.doExecuteTasks(OsgiInstallerImpl.java:847)
> at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.executeTasks(OsgiInstallerImpl.java:689)
> at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.run(OsgiInstallerImpl.java:265)
> at java.lang.Thread.run(Thread.java:745){noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Comment Edited] (SLING-11149) Expose information about cleaned up leftover ThreadLocal values

2024-08-26 Thread Joerg Hoh (Jira)


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

Joerg Hoh edited comment on SLING-11149 at 8/26/24 7:49 AM:


Scheduling to 3.3.2 because the PR has some open comments which should be 
addressed first.


was (Author: joerghoh):
Unscheduling because the PR has some open comments which should be addressed 
first.

> Expose information about cleaned up leftover ThreadLocal values 
> 
>
> Key: SLING-11149
> URL: https://issues.apache.org/jira/browse/SLING-11149
> Project: Sling
>  Issue Type: New Feature
>  Components: Commons
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: Commons Threads 3.3.2
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> As discussed in SLING-10831, the ThreadLocal cleanup feature is valuable as a 
> safeguard for code that might lead to hard-to-diagnose memory leaks.
> At the same time, it does not let developers know when a leak has been 
> prevented. We should improve this. The following improvements can be made:
> # log with a {{WARN}} level any cleanup operation. Care must be taken to not 
> overflow the logs, so maybe a way of only reporting a cleanup for a certain 
> key once can be used (memory-bound)
> # expose a counter that reports how many cleanup operations have been 
> performed by a given thread pool



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Comment Edited] (SLING-10831) o.a.s.commons.thread fails setting up ThreadLocal cleaner on Java 17

2024-08-26 Thread Joerg Hoh (Jira)


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

Joerg Hoh edited comment on SLING-10831 at 8/26/24 7:49 AM:


Checked with [~rombert] offline and according to him the starter is already 
fixed, and this ticket is rather about finding a better solution. So scheduling 
for 3.3.2.


was (Author: joerghoh):
Checked with [~rombert] offline and according to him the starter is already 
fixed, and this ticket is rather about finding a better solution. So 
unscheduling.

> o.a.s.commons.thread fails setting up ThreadLocal cleaner on Java 17
> 
>
> Key: SLING-10831
> URL: https://issues.apache.org/jira/browse/SLING-10831
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: Commons Threads 3.3.2
>
>
> When running the Sling Starter with Java 17, the following messages come up:
> {noformat}21.09.2021 11:13:54.247 *WARN* [sling-default-1] 
> org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocals 
> Could not set up thread local cleaner (most probably not a compliant JRE): {}
> java.lang.ExceptionInInitializerError: null
> at 
> org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocals.beforeExecute(ThreadPoolExecutorCleaningThreadLocals.java:58)
>  [org.apache.sling.commons.threads:3.2.20]
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
> field java.lang.ThreadLocal$ThreadLocalMap java.lang.Thread.threadLocals 
> accessible: module java.base does not "opens java.lang" to unnamed module 
> @6e04bc96
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at 
> java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
> at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
> at 
> org.apache.sling.commons.threads.impl.ThreadLocalCleaner.field(ThreadLocalCleaner.java:77)
>  [org.apache.sling.commons.threads:3.2.20]
> at 
> org.apache.sling.commons.threads.impl.ThreadLocalCleaner.(ThreadLocalCleaner.java:54)
>  [org.apache.sling.commons.threads:3.2.20]
> ... 4 common frames omitted
> 21.09.2021 11:13:54.248 *ERROR* [sling-default-1] 
> org.apache.sling.extensions.threaddump.internal.Activator Uncaught exception 
> in Thread Thread[sling-default-1,5,main]
> java.lang.ExceptionInInitializerError: null
> at 
> org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocals.beforeExecute(ThreadPoolExecutorCleaningThreadLocals.java:58)
>  [org.apache.sling.commons.threads:3.2.20]
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
> field java.lang.ThreadLocal$ThreadLocalMap java.lang.Thread.threadLocals 
> accessible: module java.base does not "opens java.lang" to unnamed module 
> @6e04bc96
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at 
> java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
> at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
> at 
> org.apache.sling.commons.threads.impl.ThreadLocalCleaner.field(ThreadLocalCleaner.java:77)
>  [org.apache.sling.commons.threads:3.2.20]
> at 
> org.apache.sling.commons.threads.impl.ThreadLocalCleaner.(ThreadLocalCleaner.java:54)
>  [org.apache.sling.commons.threads:3.2.20]
> ... 4 common frames omitted
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (SLING-10831) o.a.s.commons.thread fails setting up ThreadLocal cleaner on Java 17

2024-08-26 Thread Joerg Hoh (Jira)


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

Joerg Hoh updated SLING-10831:
--
Fix Version/s: Commons Threads 3.3.2

> o.a.s.commons.thread fails setting up ThreadLocal cleaner on Java 17
> 
>
> Key: SLING-10831
> URL: https://issues.apache.org/jira/browse/SLING-10831
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: Commons Threads 3.3.2
>
>
> When running the Sling Starter with Java 17, the following messages come up:
> {noformat}21.09.2021 11:13:54.247 *WARN* [sling-default-1] 
> org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocals 
> Could not set up thread local cleaner (most probably not a compliant JRE): {}
> java.lang.ExceptionInInitializerError: null
> at 
> org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocals.beforeExecute(ThreadPoolExecutorCleaningThreadLocals.java:58)
>  [org.apache.sling.commons.threads:3.2.20]
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
> field java.lang.ThreadLocal$ThreadLocalMap java.lang.Thread.threadLocals 
> accessible: module java.base does not "opens java.lang" to unnamed module 
> @6e04bc96
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at 
> java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
> at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
> at 
> org.apache.sling.commons.threads.impl.ThreadLocalCleaner.field(ThreadLocalCleaner.java:77)
>  [org.apache.sling.commons.threads:3.2.20]
> at 
> org.apache.sling.commons.threads.impl.ThreadLocalCleaner.(ThreadLocalCleaner.java:54)
>  [org.apache.sling.commons.threads:3.2.20]
> ... 4 common frames omitted
> 21.09.2021 11:13:54.248 *ERROR* [sling-default-1] 
> org.apache.sling.extensions.threaddump.internal.Activator Uncaught exception 
> in Thread Thread[sling-default-1,5,main]
> java.lang.ExceptionInInitializerError: null
> at 
> org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocals.beforeExecute(ThreadPoolExecutorCleaningThreadLocals.java:58)
>  [org.apache.sling.commons.threads:3.2.20]
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
> field java.lang.ThreadLocal$ThreadLocalMap java.lang.Thread.threadLocals 
> accessible: module java.base does not "opens java.lang" to unnamed module 
> @6e04bc96
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at 
> java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
> at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
> at 
> org.apache.sling.commons.threads.impl.ThreadLocalCleaner.field(ThreadLocalCleaner.java:77)
>  [org.apache.sling.commons.threads:3.2.20]
> at 
> org.apache.sling.commons.threads.impl.ThreadLocalCleaner.(ThreadLocalCleaner.java:54)
>  [org.apache.sling.commons.threads:3.2.20]
> ... 4 common frames omitted
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (SLING-11149) Expose information about cleaned up leftover ThreadLocal values

2024-08-26 Thread Joerg Hoh (Jira)


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

Joerg Hoh updated SLING-11149:
--
Fix Version/s: Commons Threads 3.3.2

> Expose information about cleaned up leftover ThreadLocal values 
> 
>
> Key: SLING-11149
> URL: https://issues.apache.org/jira/browse/SLING-11149
> Project: Sling
>  Issue Type: New Feature
>  Components: Commons
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: Commons Threads 3.3.2
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> As discussed in SLING-10831, the ThreadLocal cleanup feature is valuable as a 
> safeguard for code that might lead to hard-to-diagnose memory leaks.
> At the same time, it does not let developers know when a leak has been 
> prevented. We should improve this. The following improvements can be made:
> # log with a {{WARN}} level any cleanup operation. Care must be taken to not 
> overflow the logs, so maybe a way of only reporting a cleanup for a certain 
> key once can be used (memory-bound)
> # expose a counter that reports how many cleanup operations have been 
> performed by a given thread pool



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (SLING-11149) Expose information about cleaned up leftover ThreadLocal values

2024-08-26 Thread Joerg Hoh (Jira)


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

Joerg Hoh commented on SLING-11149:
---

Unscheduling because the PR has some open comments which should be addressed 
first.

> Expose information about cleaned up leftover ThreadLocal values 
> 
>
> Key: SLING-11149
> URL: https://issues.apache.org/jira/browse/SLING-11149
> Project: Sling
>  Issue Type: New Feature
>  Components: Commons
>Reporter: Robert Munteanu
>Priority: Major
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> As discussed in SLING-10831, the ThreadLocal cleanup feature is valuable as a 
> safeguard for code that might lead to hard-to-diagnose memory leaks.
> At the same time, it does not let developers know when a leak has been 
> prevented. We should improve this. The following improvements can be made:
> # log with a {{WARN}} level any cleanup operation. Care must be taken to not 
> overflow the logs, so maybe a way of only reporting a cleanup for a certain 
> key once can be used (memory-bound)
> # expose a counter that reports how many cleanup operations have been 
> performed by a given thread pool



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (SLING-10831) o.a.s.commons.thread fails setting up ThreadLocal cleaner on Java 17

2024-08-26 Thread Joerg Hoh (Jira)


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

Joerg Hoh commented on SLING-10831:
---

Checked with [~rombert] offline and according to him the starter is already 
fixed, and this ticket is rather about finding a better solution. So 
unscheduling.

> o.a.s.commons.thread fails setting up ThreadLocal cleaner on Java 17
> 
>
> Key: SLING-10831
> URL: https://issues.apache.org/jira/browse/SLING-10831
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Reporter: Robert Munteanu
>Priority: Major
>
> When running the Sling Starter with Java 17, the following messages come up:
> {noformat}21.09.2021 11:13:54.247 *WARN* [sling-default-1] 
> org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocals 
> Could not set up thread local cleaner (most probably not a compliant JRE): {}
> java.lang.ExceptionInInitializerError: null
> at 
> org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocals.beforeExecute(ThreadPoolExecutorCleaningThreadLocals.java:58)
>  [org.apache.sling.commons.threads:3.2.20]
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
> field java.lang.ThreadLocal$ThreadLocalMap java.lang.Thread.threadLocals 
> accessible: module java.base does not "opens java.lang" to unnamed module 
> @6e04bc96
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at 
> java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
> at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
> at 
> org.apache.sling.commons.threads.impl.ThreadLocalCleaner.field(ThreadLocalCleaner.java:77)
>  [org.apache.sling.commons.threads:3.2.20]
> at 
> org.apache.sling.commons.threads.impl.ThreadLocalCleaner.(ThreadLocalCleaner.java:54)
>  [org.apache.sling.commons.threads:3.2.20]
> ... 4 common frames omitted
> 21.09.2021 11:13:54.248 *ERROR* [sling-default-1] 
> org.apache.sling.extensions.threaddump.internal.Activator Uncaught exception 
> in Thread Thread[sling-default-1,5,main]
> java.lang.ExceptionInInitializerError: null
> at 
> org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocals.beforeExecute(ThreadPoolExecutorCleaningThreadLocals.java:58)
>  [org.apache.sling.commons.threads:3.2.20]
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
> field java.lang.ThreadLocal$ThreadLocalMap java.lang.Thread.threadLocals 
> accessible: module java.base does not "opens java.lang" to unnamed module 
> @6e04bc96
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at 
> java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
> at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
> at 
> org.apache.sling.commons.threads.impl.ThreadLocalCleaner.field(ThreadLocalCleaner.java:77)
>  [org.apache.sling.commons.threads:3.2.20]
> at 
> org.apache.sling.commons.threads.impl.ThreadLocalCleaner.(ThreadLocalCleaner.java:54)
>  [org.apache.sling.commons.threads:3.2.20]
> ... 4 common frames omitted
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (SLING-11149) Expose information about cleaned up leftover ThreadLocal values

2024-08-26 Thread Joerg Hoh (Jira)


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

Joerg Hoh updated SLING-11149:
--
Fix Version/s: (was: Commons Threads 3.3.0)

> Expose information about cleaned up leftover ThreadLocal values 
> 
>
> Key: SLING-11149
> URL: https://issues.apache.org/jira/browse/SLING-11149
> Project: Sling
>  Issue Type: New Feature
>  Components: Commons
>Reporter: Robert Munteanu
>Priority: Major
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> As discussed in SLING-10831, the ThreadLocal cleanup feature is valuable as a 
> safeguard for code that might lead to hard-to-diagnose memory leaks.
> At the same time, it does not let developers know when a leak has been 
> prevented. We should improve this. The following improvements can be made:
> # log with a {{WARN}} level any cleanup operation. Care must be taken to not 
> overflow the logs, so maybe a way of only reporting a cleanup for a certain 
> key once can be used (memory-bound)
> # expose a counter that reports how many cleanup operations have been 
> performed by a given thread pool



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (SLING-10831) o.a.s.commons.thread fails setting up ThreadLocal cleaner on Java 17

2024-08-26 Thread Joerg Hoh (Jira)


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

Joerg Hoh updated SLING-10831:
--
Fix Version/s: (was: Commons Threads 3.3.0)

> o.a.s.commons.thread fails setting up ThreadLocal cleaner on Java 17
> 
>
> Key: SLING-10831
> URL: https://issues.apache.org/jira/browse/SLING-10831
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Reporter: Robert Munteanu
>Priority: Major
>
> When running the Sling Starter with Java 17, the following messages come up:
> {noformat}21.09.2021 11:13:54.247 *WARN* [sling-default-1] 
> org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocals 
> Could not set up thread local cleaner (most probably not a compliant JRE): {}
> java.lang.ExceptionInInitializerError: null
> at 
> org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocals.beforeExecute(ThreadPoolExecutorCleaningThreadLocals.java:58)
>  [org.apache.sling.commons.threads:3.2.20]
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
> field java.lang.ThreadLocal$ThreadLocalMap java.lang.Thread.threadLocals 
> accessible: module java.base does not "opens java.lang" to unnamed module 
> @6e04bc96
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at 
> java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
> at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
> at 
> org.apache.sling.commons.threads.impl.ThreadLocalCleaner.field(ThreadLocalCleaner.java:77)
>  [org.apache.sling.commons.threads:3.2.20]
> at 
> org.apache.sling.commons.threads.impl.ThreadLocalCleaner.(ThreadLocalCleaner.java:54)
>  [org.apache.sling.commons.threads:3.2.20]
> ... 4 common frames omitted
> 21.09.2021 11:13:54.248 *ERROR* [sling-default-1] 
> org.apache.sling.extensions.threaddump.internal.Activator Uncaught exception 
> in Thread Thread[sling-default-1,5,main]
> java.lang.ExceptionInInitializerError: null
> at 
> org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocals.beforeExecute(ThreadPoolExecutorCleaningThreadLocals.java:58)
>  [org.apache.sling.commons.threads:3.2.20]
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
> field java.lang.ThreadLocal$ThreadLocalMap java.lang.Thread.threadLocals 
> accessible: module java.base does not "opens java.lang" to unnamed module 
> @6e04bc96
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at 
> java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
> at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
> at 
> org.apache.sling.commons.threads.impl.ThreadLocalCleaner.field(ThreadLocalCleaner.java:77)
>  [org.apache.sling.commons.threads:3.2.20]
> at 
> org.apache.sling.commons.threads.impl.ThreadLocalCleaner.(ThreadLocalCleaner.java:54)
>  [org.apache.sling.commons.threads:3.2.20]
> ... 4 common frames omitted
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Assigned] (SLING-12301) Improve error handling during registration of ServletContext

2024-08-24 Thread Joerg Hoh (Jira)


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

Joerg Hoh reassigned SLING-12301:
-

Assignee: Joerg Hoh

> Improve error handling during registration of ServletContext
> 
>
> Key: SLING-12301
> URL: https://issues.apache.org/jira/browse/SLING-12301
> Project: Sling
>  Issue Type: Task
>  Components: Engine
>Affects Versions: Engine 2.15.10
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
>
> With SLING-11824 the registration of the ServletContext objects was made 
> asynchronous using bare Threads.
> If this process fails with any exception, the thread just dies because there 
> is no explicit exception handling and not logging for that case.
> We should add some logging to have at least traces that such a problem 
> occurred.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Assigned] (SLING-12411) Make JmxExporterFactory more resilient

2024-08-22 Thread Joerg Hoh (Jira)


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

Joerg Hoh reassigned SLING-12411:
-

Assignee: Joerg Hoh

> Make JmxExporterFactory more resilient
> --
>
> Key: SLING-12411
> URL: https://issues.apache.org/jira/browse/SLING-12411
> Project: Sling
>  Issue Type: Improvement
>Affects Versions: Commons Metrics 1.2.12
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: Commons Metrics 1.2.14
>
>
> The JmxExporterFactory can be used to export Mbeans into Metrics. But right 
> now it only works if the MBean does already exist whenever the factory 
> configuration is bound.
> That means if the metrics bundle is started with a low startlevel (and with 
> it the JmxExporterFactory) it cannot export mbeans which are registered by 
> services/bundles which are started later.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (SLING-12411) Make JmxExporterFactory more resilient

2024-08-22 Thread Joerg Hoh (Jira)


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

Joerg Hoh resolved SLING-12411.
---
Resolution: Fixed

PR merged

> Make JmxExporterFactory more resilient
> --
>
> Key: SLING-12411
> URL: https://issues.apache.org/jira/browse/SLING-12411
> Project: Sling
>  Issue Type: Improvement
>Affects Versions: Commons Metrics 1.2.12
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: Commons Metrics 1.2.14
>
>
> The JmxExporterFactory can be used to export Mbeans into Metrics. But right 
> now it only works if the MBean does already exist whenever the factory 
> configuration is bound.
> That means if the metrics bundle is started with a low startlevel (and with 
> it the JmxExporterFactory) it cannot export mbeans which are registered by 
> services/bundles which are started later.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (SLING-12025) ResourceResolver: different mapping when optimizedAliasResolution enabled

2024-08-22 Thread Joerg Hoh (Jira)


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

Joerg Hoh commented on SLING-12025:
---

[~reschke] see also SLING-12054

In my opinion we should remove the non-optimized code path really soon, and 
publicly document the behavior we discovered here.

> ResourceResolver: different mapping when optimizedAliasResolution enabled
> -
>
> Key: SLING-12025
> URL: https://issues.apache.org/jira/browse/SLING-12025
> Project: Sling
>  Issue Type: Task
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.10.0
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: Resource Resolver 1.11.2
>
>
> I found that the there is a different behavior in case the "optimized alias 
> resolution is enabled.
> Setup:
> {noformat}
> * /content/jcr:content
>   + sling:alias=foobar
> {noformat}
> In my opinion the expected behavior is that the {{content}} resource is 
> aliased and can be resolved via both {{/content}} and {{/foobar}}. You cannot 
> alias the {{jcr:content}} node. Unfortunately there are no unit tests for 
> that, and I just came across that behavior when I tried to write one.
> This works with the "optimized alias resolution" feature turned on, but if 
> it's turned off, it does not work anymore, and you can resolve that resource 
> only via its name. (In that case I assume that the jcr:content resource is 
> aliased.)
> I created 
> https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/105 to 
> demonstrate this problem.
> Is my assumption about the behavior correct?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (SLING-12411) Make JmxExporterFactory more resilient

2024-08-20 Thread Joerg Hoh (Jira)
Joerg Hoh created SLING-12411:
-

 Summary: Make JmxExporterFactory more resilient
 Key: SLING-12411
 URL: https://issues.apache.org/jira/browse/SLING-12411
 Project: Sling
  Issue Type: Improvement
Affects Versions: Commons Metrics 1.2.12
Reporter: Joerg Hoh
 Fix For: Commons Metrics 1.2.14


The JmxExporterFactory can be used to export Mbeans into Metrics. But right now 
it only works if the MBean does already exist whenever the factory 
configuration is bound.

That means if the metrics bundle is started with a low startlevel (and with it 
the JmxExporterFactory) it cannot export mbeans which are registered by 
services/bundles which are started later.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (SLING-12178) Make commons metrics optional in xss bundle

2024-08-19 Thread Joerg Hoh (Jira)


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

Joerg Hoh closed SLING-12178.
-

> Make commons metrics optional in xss bundle
> ---
>
> Key: SLING-12178
> URL: https://issues.apache.org/jira/browse/SLING-12178
> Project: Sling
>  Issue Type: Improvement
>  Components: XSS Protection API
>Affects Versions: XSS Protection API 2.4.0
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>Priority: Major
> Fix For: XSS Protection API 2.4.2
>
>
> Following the pattern we use in the other bundles, it would be good if the 
> sling metrics would be optional for the xss bundle.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (SLING-12366) Failure to read from InputStream backed by closed session

2024-08-19 Thread Joerg Hoh (Jira)


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

Joerg Hoh closed SLING-12366.
-

> Failure to read from InputStream backed by closed session
> -
>
> Key: SLING-12366
> URL: https://issues.apache.org/jira/browse/SLING-12366
> Project: Sling
>  Issue Type: Improvement
>  Components: XSS Protection API
>Affects Versions: XSS Protection API 2.4.0
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Major
> Fix For: XSS Protection API 2.4.2
>
>
> The method {{org.apache.sling.xss.impl.XSSFilterImpl.AntiSamyPolicy#read()}} 
> opens a {{ResourceResolver}}, finds a {{Resource}}, adapts it to an 
> {{InputStream}}, returns the {{InputStream}} and closes the 
> {{ResourceResolver}} via try-with-resource.
> This works fine, as long as the {{InputStream}} is not a 
> {{JcrExternalizableInputStream}}, which is only available when the blob 
> resides in an external blob store, e.g. azure.
> The reason is that the {{JcrExternalizableInputStream}} takes a reference to 
> the JCR {{Property}} and only reads it lazily. In this scenario, when it 
> reads the property, the session is already closed.
> A typical stack-trace looks like the one below:
> {noformat}
> [main] ERROR org.apache.sling.xss.impl.XSSFilterImpl - Unable to load policy 
> from /libs/sling/xss/config.xml
> java.io.IOException: This session has been closed.
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrExternalizableInputStream.getInputStream(JcrExternalizableInputStream.java:70)
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrExternalizableInputStream.read(JcrExternalizableInputStream.java:57)
>   at java.base/java.io.InputStream.read(InputStream.java:271)
>   at java.base/java.io.InputStream.read(InputStream.java:205)
>   at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1485)
>   at org.apache.commons.io.IOUtils.copy(IOUtils.java:1105)
>   at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1458)
>   at org.apache.commons.io.IOUtils.copy(IOUtils.java:1083)
>   at org.apache.sling.xss.impl.PolicyHandler.(PolicyHandler.java:43)
>   at 
> org.apache.sling.xss.impl.XSSFilterImpl.setActivePolicy(XSSFilterImpl.java:331)
>   at 
> org.apache.sling.xss.impl.XSSFilterImpl.updatePolicy(XSSFilterImpl.java:293)
>   at 
> org.apache.sling.xss.impl.XSSFilterImpl.activate(XSSFilterImpl.java:269)
>   [... snipped the caller ...]
> Caused by: javax.jcr.RepositoryException: This session has been closed.
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.checkAlive(SessionDelegate.java:323)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.ItemDelegate.checkAlive(ItemDelegate.java:83)
>   at 
> org.apache.jackrabbit.oak.jcr.session.operation.ItemOperation.checkPreconditions(ItemOperation.java:34)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.prePerform(SessionDelegate.java:614)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:204)
>   at 
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
>   at 
> org.apache.jackrabbit.oak.jcr.session.PropertyImpl.getValue(PropertyImpl.java:248)
>   at 
> org.apache.jackrabbit.oak.jcr.session.PropertyImpl.getBinary(PropertyImpl.java:287)
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrExternalizableInputStream.getInputStream(JcrExternalizableInputStream.java:68)
>   ... 93 more
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (SLING-12408) simplify logic in AntiSamyPolicyAdapter

2024-08-19 Thread Joerg Hoh (Jira)


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

Joerg Hoh closed SLING-12408.
-

> simplify logic in AntiSamyPolicyAdapter
> ---
>
> Key: SLING-12408
> URL: https://issues.apache.org/jira/browse/SLING-12408
> Project: Sling
>  Issue Type: Improvement
>  Components: XSS Protection API
>Affects Versions: XSS Protection API 2.4.0
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
> Fix For: XSS Protection API 2.4.2
>
>
> The logic in {{AntiSamyPolicyAdapter}} has quite a lot of unnecessary case 
> distinctions and can be simplified by removing code.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (SLING-12276) Update to java-html-sanitizer 20240325.1

2024-08-19 Thread Joerg Hoh (Jira)


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

Joerg Hoh closed SLING-12276.
-

> Update to java-html-sanitizer 20240325.1
> 
>
> Key: SLING-12276
> URL: https://issues.apache.org/jira/browse/SLING-12276
> Project: Sling
>  Issue Type: Improvement
>  Components: XSS Protection API
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: XSS Protection API 2.4.2
>
>
> A new Java HTML Sanitizer version is out, notably removing the dependency on 
> Guava ( 
> https://github.com/OWASP/java-html-sanitizer/releases/tag/release-20240325.1 
> ).
> This will allow us to remove:
> - the embedding of Guava classes, cutting down on bundle size
> - the shading of the Guava classes, reducing the complexity of the pom



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (SLING-12388) Handle duplicate literals

2024-08-19 Thread Joerg Hoh (Jira)


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

Joerg Hoh closed SLING-12388.
-

> Handle duplicate literals
> -
>
> Key: SLING-12388
> URL: https://issues.apache.org/jira/browse/SLING-12388
> Project: Sling
>  Issue Type: Improvement
>  Components: XSS Protection API
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: XSS Protection API 2.4.2
>
>
> When testing the most recent SNAPSHOT version of the bundle against a recent 
> AEM as Cloud Service instance, I got this exception:
> {noformat}
> 13.06.2024 10:04:54.106 *ERROR* [FelixStartLevel] 
> org.apache.sling.xss.impl.XSSFilterImpl Unable to load policy from 
> /libs/cq/xssprotection/config.xml
> java.lang.IllegalArgumentException: duplicate element: a
> at 
> java.base/java.util.ImmutableCollections$SetN.(ImmutableCollections.java:604)
> at java.base/java.util.Set.of(Set.java:701)
> at org.owasp.shim.ForJava9AndLater.setOf(ForJava9AndLater.java:61) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.owasp.html.HtmlPolicyBuilder$AttributeBuilder.matching(HtmlPolicyBuilder.java:933)
>  [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.AntiSamyPolicyAdapter.(AntiSamyPolicyAdapter.java:145)
>  [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.HtmlSanitizer.(HtmlSanitizer.java:40) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.PolicyHandler.(PolicyHandler.java:47) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.XSSFilterImpl.setActivePolicy(XSSFilterImpl.java:331)
>  [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.XSSFilterImpl.updatePolicy(XSSFilterImpl.java:293) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.XSSFilterImpl.activate(XSSFilterImpl.java:269) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [...]
> 13.06.2024 10:04:54.109 *INFO* [FelixStartLevel] 
> org.apache.sling.xss.impl.XSSFilterImpl Could not find a policy file at the 
> configured location cq/xssprotection/config.xml. Attempting to use the 
> default resource embedded in the bundle.
> 13.06.2024 10:04:54.282 *INFO* [FelixStartLevel] 
> org.apache.sling.xss.impl.XSSFilterImpl Installed policy from the embedded 
> SLING-INF/content/config.xml file from the bundle.
> {noformat}
> Analyzing this I found this snippet of the configuration is responsible for 
> it:
> {noformat}
> 
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
> {noformat}
> This configuration works with the previous version 2.4.0 of the XSS bundle. 
> When I remove the uppercase variants of the literals from the configuration, 
> I don't get the exception anymore with the latest SNAPSHOT.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (SLING-12368) regression: rule for "ol" tag fails on java 9+ after SLING-12276

2024-08-14 Thread Joerg Hoh (Jira)


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

Joerg Hoh closed SLING-12368.
-

so let's close it.

> regression: rule for "ol" tag fails on java 9+ after SLING-12276
> 
>
> Key: SLING-12368
> URL: https://issues.apache.org/jira/browse/SLING-12368
> Project: Sling
>  Issue Type: Improvement
>  Components: XSS Protection API
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Major
>
> The dependency update in SLING-12276 brings a change, where 
> {{java.lang.Set.of()}} methods are used _if_ the runtime is java 9+. 
> {{Set.of()}} throws an exception if any two arguments are equal.
> The configuration for the "ol" tag is as follows:
> {code:xml}
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> {code}
> The literals "a", "A", "i", "I", "1" are all converted to lower case and 
> result in the following call {{{}Set.of("a", "a", "i", "i", "1"){}}}. On Java 
> 9+, this results in the following exception:
> {noformat}
> java.lang.IllegalArgumentException: duplicate element: a
>   at 
> java.base/java.util.ImmutableCollections$SetN.(ImmutableCollections.java:587)
>   at java.base/java.util.Set.of(Set.java:701)
>   at org.owasp.shim.ForJava9AndLater.setOf(ForJava9AndLater.java:61)
>   at 
> org.owasp.html.HtmlPolicyBuilder$AttributeBuilder.matching(HtmlPolicyBuilder.java:933)
>   at 
> org.apache.sling.xss.impl.AntiSamyPolicyAdapter.(AntiSamyPolicyAdapter.java:146)
>   at org.apache.sling.xss.impl.HtmlSanitizer.(HtmlSanitizer.java:40)
> ...
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (SLING-12394) Harmonize ResourceResolver handling

2024-07-26 Thread Joerg Hoh (Jira)
Joerg Hoh created SLING-12394:
-

 Summary: Harmonize ResourceResolver handling
 Key: SLING-12394
 URL: https://issues.apache.org/jira/browse/SLING-12394
 Project: Sling
  Issue Type: Improvement
  Components: Event
Reporter: Joerg Hoh


The handling of the creation of ResourceResolvers should be harmonized:

* consistent error handling & null checks
* use try-with-resource to to make the code more concise




--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (SLING-12393) Warn on excessive use of JobExecutionContext.log(...)

2024-07-26 Thread Joerg Hoh (Jira)


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

Joerg Hoh closed SLING-12393.
-

> Warn on excessive use of JobExecutionContext.log(...)
> -
>
> Key: SLING-12393
> URL: https://issues.apache.org/jira/browse/SLING-12393
> Project: Sling
>  Issue Type: Improvement
>  Components: Event
>Reporter: Joerg Hoh
>Priority: Major
>
> On every call of JobExecutionContext.log() a new array element is added to 
> the "slingevent:progressLog" property of a Job. This array is persisted as 
> multi-value propery in the underlying repository.
> In an Oak-based repository having large multi-value properties can cause 
> performance problems on various levels (indexing, read/write performance); 
> for that reason the Job implementation should log a warning when more than 
> 1000 statements are logged on the Job.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (SLING-12393) Warn on excessive use of JobExecutionContext.log(...)

2024-07-26 Thread Joerg Hoh (Jira)


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

Joerg Hoh resolved SLING-12393.
---
Resolution: Duplicate

> Warn on excessive use of JobExecutionContext.log(...)
> -
>
> Key: SLING-12393
> URL: https://issues.apache.org/jira/browse/SLING-12393
> Project: Sling
>  Issue Type: Improvement
>  Components: Event
>Reporter: Joerg Hoh
>Priority: Major
>
> On every call of JobExecutionContext.log() a new array element is added to 
> the "slingevent:progressLog" property of a Job. This array is persisted as 
> multi-value propery in the underlying repository.
> In an Oak-based repository having large multi-value properties can cause 
> performance problems on various levels (indexing, read/write performance); 
> for that reason the Job implementation should log a warning when more than 
> 1000 statements are logged on the Job.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (SLING-12393) Warn on excessive use of JobExecutionContext.log(...)

2024-07-26 Thread Joerg Hoh (Jira)
Joerg Hoh created SLING-12393:
-

 Summary: Warn on excessive use of JobExecutionContext.log(...)
 Key: SLING-12393
 URL: https://issues.apache.org/jira/browse/SLING-12393
 Project: Sling
  Issue Type: Improvement
  Components: Event
Reporter: Joerg Hoh



On every call of JobExecutionContext.log() a new array element is added to the 
"slingevent:progressLog" property of a Job. This array is persisted as 
multi-value propery in the underlying repository.

In an Oak-based repository having large multi-value properties can cause 
performance problems on various levels (indexing, read/write performance); for 
that reason the Job implementation should log a warning when more than 1000 
statements are logged on the Job.





--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (SLING-12368) regression: rule for "ol" tag fails on java 9+ after SLING-12276

2024-07-23 Thread Joerg Hoh (Jira)


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

Joerg Hoh commented on SLING-12368:
---

[~jsedding] this seems to be a duplicate of SLING-12388. Can you confirm?

> regression: rule for "ol" tag fails on java 9+ after SLING-12276
> 
>
> Key: SLING-12368
> URL: https://issues.apache.org/jira/browse/SLING-12368
> Project: Sling
>  Issue Type: Improvement
>  Components: XSS Protection API
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Major
> Fix For: XSS Protection API 2.4.2
>
>
> The dependency update in SLING-12276 brings a change, where 
> {{java.lang.Set.of()}} methods are used _if_ the runtime is java 9+. 
> {{Set.of()}} throws an exception if any two arguments are equal.
> The configuration for the "ol" tag is as follows:
> {code:xml}
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> {code}
> The literals "a", "A", "i", "I", "1" are all converted to lower case and 
> result in the following call {{{}Set.of("a", "a", "i", "i", "1"){}}}. On Java 
> 9+, this results in the following exception:
> {noformat}
> java.lang.IllegalArgumentException: duplicate element: a
>   at 
> java.base/java.util.ImmutableCollections$SetN.(ImmutableCollections.java:587)
>   at java.base/java.util.Set.of(Set.java:701)
>   at org.owasp.shim.ForJava9AndLater.setOf(ForJava9AndLater.java:61)
>   at 
> org.owasp.html.HtmlPolicyBuilder$AttributeBuilder.matching(HtmlPolicyBuilder.java:933)
>   at 
> org.apache.sling.xss.impl.AntiSamyPolicyAdapter.(AntiSamyPolicyAdapter.java:146)
>   at org.apache.sling.xss.impl.HtmlSanitizer.(HtmlSanitizer.java:40)
> ...
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Assigned] (SLING-12388) Handle duplicate literals

2024-07-23 Thread Joerg Hoh (Jira)


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

Joerg Hoh reassigned SLING-12388:
-

Assignee: Joerg Hoh

> Handle duplicate literals
> -
>
> Key: SLING-12388
> URL: https://issues.apache.org/jira/browse/SLING-12388
> Project: Sling
>  Issue Type: Improvement
>  Components: XSS Protection API
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
>
> When testing the most recent SNAPSHOT version of the bundle against a recent 
> AEM as Cloud Service instance, I got this exception:
> {noformat}
> 13.06.2024 10:04:54.106 *ERROR* [FelixStartLevel] 
> org.apache.sling.xss.impl.XSSFilterImpl Unable to load policy from 
> /libs/cq/xssprotection/config.xml
> java.lang.IllegalArgumentException: duplicate element: a
> at 
> java.base/java.util.ImmutableCollections$SetN.(ImmutableCollections.java:604)
> at java.base/java.util.Set.of(Set.java:701)
> at org.owasp.shim.ForJava9AndLater.setOf(ForJava9AndLater.java:61) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.owasp.html.HtmlPolicyBuilder$AttributeBuilder.matching(HtmlPolicyBuilder.java:933)
>  [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.AntiSamyPolicyAdapter.(AntiSamyPolicyAdapter.java:145)
>  [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.HtmlSanitizer.(HtmlSanitizer.java:40) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.PolicyHandler.(PolicyHandler.java:47) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.XSSFilterImpl.setActivePolicy(XSSFilterImpl.java:331)
>  [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.XSSFilterImpl.updatePolicy(XSSFilterImpl.java:293) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.XSSFilterImpl.activate(XSSFilterImpl.java:269) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [...]
> 13.06.2024 10:04:54.109 *INFO* [FelixStartLevel] 
> org.apache.sling.xss.impl.XSSFilterImpl Could not find a policy file at the 
> configured location cq/xssprotection/config.xml. Attempting to use the 
> default resource embedded in the bundle.
> 13.06.2024 10:04:54.282 *INFO* [FelixStartLevel] 
> org.apache.sling.xss.impl.XSSFilterImpl Installed policy from the embedded 
> SLING-INF/content/config.xml file from the bundle.
> {noformat}
> Analyzing this I found this snippet of the configuration is responsible for 
> it:
> {noformat}
> 
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
> {noformat}
> This configuration works with the previous version 2.4.0 of the XSS bundle. 
> When I remove the uppercase variants of the literals from the configuration, 
> I don't get the exception anymore with the latest SNAPSHOT.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (SLING-12388) Handle duplicate literals

2024-07-23 Thread Joerg Hoh (Jira)


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

Joerg Hoh resolved SLING-12388.
---
Resolution: Fixed

> Handle duplicate literals
> -
>
> Key: SLING-12388
> URL: https://issues.apache.org/jira/browse/SLING-12388
> Project: Sling
>  Issue Type: Improvement
>  Components: XSS Protection API
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
>
> When testing the most recent SNAPSHOT version of the bundle against a recent 
> AEM as Cloud Service instance, I got this exception:
> {noformat}
> 13.06.2024 10:04:54.106 *ERROR* [FelixStartLevel] 
> org.apache.sling.xss.impl.XSSFilterImpl Unable to load policy from 
> /libs/cq/xssprotection/config.xml
> java.lang.IllegalArgumentException: duplicate element: a
> at 
> java.base/java.util.ImmutableCollections$SetN.(ImmutableCollections.java:604)
> at java.base/java.util.Set.of(Set.java:701)
> at org.owasp.shim.ForJava9AndLater.setOf(ForJava9AndLater.java:61) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.owasp.html.HtmlPolicyBuilder$AttributeBuilder.matching(HtmlPolicyBuilder.java:933)
>  [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.AntiSamyPolicyAdapter.(AntiSamyPolicyAdapter.java:145)
>  [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.HtmlSanitizer.(HtmlSanitizer.java:40) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.PolicyHandler.(PolicyHandler.java:47) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.XSSFilterImpl.setActivePolicy(XSSFilterImpl.java:331)
>  [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.XSSFilterImpl.updatePolicy(XSSFilterImpl.java:293) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.XSSFilterImpl.activate(XSSFilterImpl.java:269) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [...]
> 13.06.2024 10:04:54.109 *INFO* [FelixStartLevel] 
> org.apache.sling.xss.impl.XSSFilterImpl Could not find a policy file at the 
> configured location cq/xssprotection/config.xml. Attempting to use the 
> default resource embedded in the bundle.
> 13.06.2024 10:04:54.282 *INFO* [FelixStartLevel] 
> org.apache.sling.xss.impl.XSSFilterImpl Installed policy from the embedded 
> SLING-INF/content/config.xml file from the bundle.
> {noformat}
> Analyzing this I found this snippet of the configuration is responsible for 
> it:
> {noformat}
> 
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
> {noformat}
> This configuration works with the previous version 2.4.0 of the XSS bundle. 
> When I remove the uppercase variants of the literals from the configuration, 
> I don't get the exception anymore with the latest SNAPSHOT.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (SLING-12388) Handle duplicate literals

2024-07-23 Thread Joerg Hoh (Jira)


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

Joerg Hoh updated SLING-12388:
--
Fix Version/s: XSS Protection API 2.4.2

> Handle duplicate literals
> -
>
> Key: SLING-12388
> URL: https://issues.apache.org/jira/browse/SLING-12388
> Project: Sling
>  Issue Type: Improvement
>  Components: XSS Protection API
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: XSS Protection API 2.4.2
>
>
> When testing the most recent SNAPSHOT version of the bundle against a recent 
> AEM as Cloud Service instance, I got this exception:
> {noformat}
> 13.06.2024 10:04:54.106 *ERROR* [FelixStartLevel] 
> org.apache.sling.xss.impl.XSSFilterImpl Unable to load policy from 
> /libs/cq/xssprotection/config.xml
> java.lang.IllegalArgumentException: duplicate element: a
> at 
> java.base/java.util.ImmutableCollections$SetN.(ImmutableCollections.java:604)
> at java.base/java.util.Set.of(Set.java:701)
> at org.owasp.shim.ForJava9AndLater.setOf(ForJava9AndLater.java:61) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.owasp.html.HtmlPolicyBuilder$AttributeBuilder.matching(HtmlPolicyBuilder.java:933)
>  [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.AntiSamyPolicyAdapter.(AntiSamyPolicyAdapter.java:145)
>  [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.HtmlSanitizer.(HtmlSanitizer.java:40) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.PolicyHandler.(PolicyHandler.java:47) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.XSSFilterImpl.setActivePolicy(XSSFilterImpl.java:331)
>  [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.XSSFilterImpl.updatePolicy(XSSFilterImpl.java:293) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.XSSFilterImpl.activate(XSSFilterImpl.java:269) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [...]
> 13.06.2024 10:04:54.109 *INFO* [FelixStartLevel] 
> org.apache.sling.xss.impl.XSSFilterImpl Could not find a policy file at the 
> configured location cq/xssprotection/config.xml. Attempting to use the 
> default resource embedded in the bundle.
> 13.06.2024 10:04:54.282 *INFO* [FelixStartLevel] 
> org.apache.sling.xss.impl.XSSFilterImpl Installed policy from the embedded 
> SLING-INF/content/config.xml file from the bundle.
> {noformat}
> Analyzing this I found this snippet of the configuration is responsible for 
> it:
> {noformat}
> 
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
> {noformat}
> This configuration works with the previous version 2.4.0 of the XSS bundle. 
> When I remove the uppercase variants of the literals from the configuration, 
> I don't get the exception anymore with the latest SNAPSHOT.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (SLING-12388) Handle duplicate literals

2024-07-23 Thread Joerg Hoh (Jira)


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

Joerg Hoh commented on SLING-12388:
---

The reason for the difference in semantic is that the updated owasp 
html-sanitizer  uses a native java.util.set with guaranteed uniqueness 
constraints, while in the previous version of the html-sanitizer [a 
UmmutableSet of 
Guava|https://github.com/OWASP/java-html-sanitizer/blob/e35ef4fec8a4021845204c5cedb952e1aaf679e4/src/main/java/org/owasp/html/HtmlPolicyBuilder.java#L943]
 is created using the static {{copyOf()}} method, which explicitly removes 
duplicates (which {{Set.of()}} does not).

For that reason the explicit deduplication as required as shown in 
https://github.com/apache/sling-org-apache-sling-xss/pull/43












> Handle duplicate literals
> -
>
> Key: SLING-12388
> URL: https://issues.apache.org/jira/browse/SLING-12388
> Project: Sling
>  Issue Type: Improvement
>  Components: XSS Protection API
>Reporter: Joerg Hoh
>Priority: Major
>
> When testing the most recent SNAPSHOT version of the bundle against a recent 
> AEM as Cloud Service instance, I got this exception:
> {noformat}
> 13.06.2024 10:04:54.106 *ERROR* [FelixStartLevel] 
> org.apache.sling.xss.impl.XSSFilterImpl Unable to load policy from 
> /libs/cq/xssprotection/config.xml
> java.lang.IllegalArgumentException: duplicate element: a
> at 
> java.base/java.util.ImmutableCollections$SetN.(ImmutableCollections.java:604)
> at java.base/java.util.Set.of(Set.java:701)
> at org.owasp.shim.ForJava9AndLater.setOf(ForJava9AndLater.java:61) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.owasp.html.HtmlPolicyBuilder$AttributeBuilder.matching(HtmlPolicyBuilder.java:933)
>  [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.AntiSamyPolicyAdapter.(AntiSamyPolicyAdapter.java:145)
>  [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.HtmlSanitizer.(HtmlSanitizer.java:40) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.PolicyHandler.(PolicyHandler.java:47) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.XSSFilterImpl.setActivePolicy(XSSFilterImpl.java:331)
>  [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.XSSFilterImpl.updatePolicy(XSSFilterImpl.java:293) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.XSSFilterImpl.activate(XSSFilterImpl.java:269) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [...]
> 13.06.2024 10:04:54.109 *INFO* [FelixStartLevel] 
> org.apache.sling.xss.impl.XSSFilterImpl Could not find a policy file at the 
> configured location cq/xssprotection/config.xml. Attempting to use the 
> default resource embedded in the bundle.
> 13.06.2024 10:04:54.282 *INFO* [FelixStartLevel] 
> org.apache.sling.xss.impl.XSSFilterImpl Installed policy from the embedded 
> SLING-INF/content/config.xml file from the bundle.
> {noformat}
> Analyzing this I found this snippet of the configuration is responsible for 
> it:
> {noformat}
> 
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
> {noformat}
> This configuration works with the previous version 2.4.0 of the XSS bundle. 
> When I remove the uppercase variants of the literals from the configuration, 
> I don't get the exception anymore with the latest SNAPSHOT.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Comment Edited] (SLING-12388) Handle duplicate literals

2024-07-22 Thread Joerg Hoh (Jira)


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

Joerg Hoh edited comment on SLING-12388 at 7/22/24 2:11 PM:


When applying https://github.com/apache/sling-org-apache-sling-xss/pull/43 to 
the codebase and using the existing configuration, I don't get this exception 
anymore.

Which would be my prefered option, as I prefer backwards compatibility to older 
version of the configuration (might be customized) 


was (Author: joerghoh):
When applying https://github.com/apache/sling-org-apache-sling-xss/pull/43 to 
the codebase, I don't get this exception anymore.

> Handle duplicate literals
> -
>
> Key: SLING-12388
> URL: https://issues.apache.org/jira/browse/SLING-12388
> Project: Sling
>  Issue Type: Improvement
>  Components: XSS Protection API
>Reporter: Joerg Hoh
>Priority: Major
>
> When testing the most recent SNAPSHOT version of the bundle against a recent 
> AEM as Cloud Service instance, I got this exception:
> {noformat}
> 13.06.2024 10:04:54.106 *ERROR* [FelixStartLevel] 
> org.apache.sling.xss.impl.XSSFilterImpl Unable to load policy from 
> /libs/cq/xssprotection/config.xml
> java.lang.IllegalArgumentException: duplicate element: a
> at 
> java.base/java.util.ImmutableCollections$SetN.(ImmutableCollections.java:604)
> at java.base/java.util.Set.of(Set.java:701)
> at org.owasp.shim.ForJava9AndLater.setOf(ForJava9AndLater.java:61) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.owasp.html.HtmlPolicyBuilder$AttributeBuilder.matching(HtmlPolicyBuilder.java:933)
>  [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.AntiSamyPolicyAdapter.(AntiSamyPolicyAdapter.java:145)
>  [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.HtmlSanitizer.(HtmlSanitizer.java:40) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.PolicyHandler.(PolicyHandler.java:47) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.XSSFilterImpl.setActivePolicy(XSSFilterImpl.java:331)
>  [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.XSSFilterImpl.updatePolicy(XSSFilterImpl.java:293) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.XSSFilterImpl.activate(XSSFilterImpl.java:269) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [...]
> 13.06.2024 10:04:54.109 *INFO* [FelixStartLevel] 
> org.apache.sling.xss.impl.XSSFilterImpl Could not find a policy file at the 
> configured location cq/xssprotection/config.xml. Attempting to use the 
> default resource embedded in the bundle.
> 13.06.2024 10:04:54.282 *INFO* [FelixStartLevel] 
> org.apache.sling.xss.impl.XSSFilterImpl Installed policy from the embedded 
> SLING-INF/content/config.xml file from the bundle.
> {noformat}
> Analyzing this I found this snippet of the configuration is responsible for 
> it:
> {noformat}
> 
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
> {noformat}
> This configuration works with the previous version 2.4.0 of the XSS bundle. 
> When I remove the uppercase variants of the literals from the configuration, 
> I don't get the exception anymore with the latest SNAPSHOT.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (SLING-12388) Handle duplicate literals

2024-07-22 Thread Joerg Hoh (Jira)


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

Joerg Hoh commented on SLING-12388:
---

When applying https://github.com/apache/sling-org-apache-sling-xss/pull/43 to 
the codebase, I don't get this exception anymore.

> Handle duplicate literals
> -
>
> Key: SLING-12388
> URL: https://issues.apache.org/jira/browse/SLING-12388
> Project: Sling
>  Issue Type: Improvement
>  Components: XSS Protection API
>Reporter: Joerg Hoh
>Priority: Major
>
> When testing the most recent SNAPSHOT version of the bundle against a recent 
> AEM as Cloud Service instance, I got this exception:
> {noformat}
> 13.06.2024 10:04:54.106 *ERROR* [FelixStartLevel] 
> org.apache.sling.xss.impl.XSSFilterImpl Unable to load policy from 
> /libs/cq/xssprotection/config.xml
> java.lang.IllegalArgumentException: duplicate element: a
> at 
> java.base/java.util.ImmutableCollections$SetN.(ImmutableCollections.java:604)
> at java.base/java.util.Set.of(Set.java:701)
> at org.owasp.shim.ForJava9AndLater.setOf(ForJava9AndLater.java:61) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.owasp.html.HtmlPolicyBuilder$AttributeBuilder.matching(HtmlPolicyBuilder.java:933)
>  [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.AntiSamyPolicyAdapter.(AntiSamyPolicyAdapter.java:145)
>  [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.HtmlSanitizer.(HtmlSanitizer.java:40) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.PolicyHandler.(PolicyHandler.java:47) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.XSSFilterImpl.setActivePolicy(XSSFilterImpl.java:331)
>  [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.XSSFilterImpl.updatePolicy(XSSFilterImpl.java:293) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.XSSFilterImpl.activate(XSSFilterImpl.java:269) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [...]
> 13.06.2024 10:04:54.109 *INFO* [FelixStartLevel] 
> org.apache.sling.xss.impl.XSSFilterImpl Could not find a policy file at the 
> configured location cq/xssprotection/config.xml. Attempting to use the 
> default resource embedded in the bundle.
> 13.06.2024 10:04:54.282 *INFO* [FelixStartLevel] 
> org.apache.sling.xss.impl.XSSFilterImpl Installed policy from the embedded 
> SLING-INF/content/config.xml file from the bundle.
> {noformat}
> Analyzing this I found this snippet of the configuration is responsible for 
> it:
> {noformat}
> 
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
> {noformat}
> This configuration works with the previous version 2.4.0 of the XSS bundle. 
> When I remove the uppercase variants of the literals from the configuration, 
> I don't get the exception anymore with the latest SNAPSHOT.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (SLING-12388) Handle duplicate literals

2024-07-22 Thread Joerg Hoh (Jira)
Joerg Hoh created SLING-12388:
-

 Summary: Handle duplicate literals
 Key: SLING-12388
 URL: https://issues.apache.org/jira/browse/SLING-12388
 Project: Sling
  Issue Type: Improvement
  Components: XSS Protection API
Reporter: Joerg Hoh


When testing the most recent SNAPSHOT version of the bundle against a recent 
AEM as Cloud Service instance, I got this exception:

{noformat}
13.06.2024 10:04:54.106 *ERROR* [FelixStartLevel] 
org.apache.sling.xss.impl.XSSFilterImpl Unable to load policy from 
/libs/cq/xssprotection/config.xml
java.lang.IllegalArgumentException: duplicate element: a
at 
java.base/java.util.ImmutableCollections$SetN.(ImmutableCollections.java:604)
at java.base/java.util.Set.of(Set.java:701)
at org.owasp.shim.ForJava9AndLater.setOf(ForJava9AndLater.java:61) 
[org.apache.sling.xss:2.4.1.SNAPSHOT]
at 
org.owasp.html.HtmlPolicyBuilder$AttributeBuilder.matching(HtmlPolicyBuilder.java:933)
 [org.apache.sling.xss:2.4.1.SNAPSHOT]
at 
org.apache.sling.xss.impl.AntiSamyPolicyAdapter.(AntiSamyPolicyAdapter.java:145)
 [org.apache.sling.xss:2.4.1.SNAPSHOT]
at 
org.apache.sling.xss.impl.HtmlSanitizer.(HtmlSanitizer.java:40) 
[org.apache.sling.xss:2.4.1.SNAPSHOT]
at 
org.apache.sling.xss.impl.PolicyHandler.(PolicyHandler.java:47) 
[org.apache.sling.xss:2.4.1.SNAPSHOT]
at 
org.apache.sling.xss.impl.XSSFilterImpl.setActivePolicy(XSSFilterImpl.java:331) 
[org.apache.sling.xss:2.4.1.SNAPSHOT]
at 
org.apache.sling.xss.impl.XSSFilterImpl.updatePolicy(XSSFilterImpl.java:293) 
[org.apache.sling.xss:2.4.1.SNAPSHOT]
at 
org.apache.sling.xss.impl.XSSFilterImpl.activate(XSSFilterImpl.java:269) 
[org.apache.sling.xss:2.4.1.SNAPSHOT]
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[...]
13.06.2024 10:04:54.109 *INFO* [FelixStartLevel] 
org.apache.sling.xss.impl.XSSFilterImpl Could not find a policy file at the 
configured location cq/xssprotection/config.xml. Attempting to use the default 
resource embedded in the bundle.
13.06.2024 10:04:54.282 *INFO* [FelixStartLevel] 
org.apache.sling.xss.impl.XSSFilterImpl Installed policy from the embedded 
SLING-INF/content/config.xml file from the bundle.
{noformat}

Analyzing this I found this snippet of the configuration is responsible for it:

{noformat}

















{noformat}

This configuration works with the previous version 2.4.0 of the XSS bundle. 
When I remove the uppercase variants of the literals from the configuration, I 
don't get the exception anymore with the latest SNAPSHOT.










--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (SLING-12371) Always update the metric for unclosed ResourceResolvers

2024-07-18 Thread Joerg Hoh (Jira)


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

Joerg Hoh resolved SLING-12371.
---
Resolution: Fixed

PR merged

> Always update the metric for unclosed ResourceResolvers
> ---
>
> Key: SLING-12371
> URL: https://issues.apache.org/jira/browse/SLING-12371
> Project: Sling
>  Issue Type: Task
>  Components: ResourceResolver
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: Resource Resolver 1.12.0
>
>
> Right now the metric 
> "sling:org.apache.sling.resourceresolver.unclosedResourceResolvers" is only 
> updated when the configuration "logUnclosedResolvers" is enabled, which is 
> not always the case.
> But the metric should be updated even if this setting is not enabled.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (SLING-12369) ModelAdapterFactory: expose the number of RequestDisposableCallbacks as metric

2024-07-17 Thread Joerg Hoh (Jira)


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

Joerg Hoh resolved SLING-12369.
---
Resolution: Won't Do

therefor marking it as "won't do", but maintaining the fix version.

> ModelAdapterFactory: expose the number of RequestDisposableCallbacks as metric
> --
>
> Key: SLING-12369
> URL: https://issues.apache.org/jira/browse/SLING-12369
> Project: Sling
>  Issue Type: Task
>  Components: Sling Models
>Affects Versions: Models Implementation 1.7.0
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: Models Implementation 1.7.2
>
>
> We should expose the number of entries in the map of 
> ModelAdapterFactory.RequestDisposableCallbacks; this would allow us to detect 
> a constantly growing number of entries, which will end up with an OOM. With a 
> metric we have the chance to detect those situations earlier.
> See also https://www.mail-archive.com/dev@sling.apache.org/msg131926.html and 
> SLING-12279



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Reopened] (SLING-12369) ModelAdapterFactory: expose the number of RequestDisposableCallbacks as metric

2024-07-17 Thread Joerg Hoh (Jira)


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

Joerg Hoh reopened SLING-12369:
---

> ModelAdapterFactory: expose the number of RequestDisposableCallbacks as metric
> --
>
> Key: SLING-12369
> URL: https://issues.apache.org/jira/browse/SLING-12369
> Project: Sling
>  Issue Type: Task
>  Components: Sling Models
>Affects Versions: Models Implementation 1.7.0
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: Models Implementation 1.7.2
>
>
> We should expose the number of entries in the map of 
> ModelAdapterFactory.RequestDisposableCallbacks; this would allow us to detect 
> a constantly growing number of entries, which will end up with an OOM. With a 
> metric we have the chance to detect those situations earlier.
> See also https://www.mail-archive.com/dev@sling.apache.org/msg131926.html and 
> SLING-12279



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (SLING-12369) ModelAdapterFactory: expose the number of RequestDisposableCallbacks as metric

2024-07-17 Thread Joerg Hoh (Jira)


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

Joerg Hoh commented on SLING-12369:
---

SLING-12372 changes the way how disposables are stored until they are disposed, 
so this metric has been removed from the codebase.

> ModelAdapterFactory: expose the number of RequestDisposableCallbacks as metric
> --
>
> Key: SLING-12369
> URL: https://issues.apache.org/jira/browse/SLING-12369
> Project: Sling
>  Issue Type: Task
>  Components: Sling Models
>Affects Versions: Models Implementation 1.7.0
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: Models Implementation 1.7.2
>
>
> We should expose the number of entries in the map of 
> ModelAdapterFactory.RequestDisposableCallbacks; this would allow us to detect 
> a constantly growing number of entries, which will end up with an OOM. With a 
> metric we have the chance to detect those situations earlier.
> See also https://www.mail-archive.com/dev@sling.apache.org/msg131926.html and 
> SLING-12279



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (SLING-12219) ResourceUtil.normalize does not handle segments with multiple dots correctly

2024-07-10 Thread Joerg Hoh (Jira)


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

Joerg Hoh closed SLING-12219.
-

> ResourceUtil.normalize does not handle segments with multiple dots correctly
> 
>
> Key: SLING-12219
> URL: https://issues.apache.org/jira/browse/SLING-12219
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Affects Versions: API 2.27.2
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: API 2.27.6
>
>
> If a path segment contains more than two dots but anything else, then 
> ResourceUtil.normalize does not handle these correctly. It should just return 
> null. Instead in some cases it is leaving the segment untouched or shortens 
> it for example from four dots to two dots.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (SLING-11878) Clarify Javadoc on which methods allow a ModifiableValueMap to be changed

2024-07-10 Thread Joerg Hoh (Jira)


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

Joerg Hoh closed SLING-11878.
-

> Clarify Javadoc on which methods allow a ModifiableValueMap to be changed
> -
>
> Key: SLING-11878
> URL: https://issues.apache.org/jira/browse/SLING-11878
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Affects Versions: API 2.27.2
>Reporter: Tomasz Niedźwiedź
>Assignee: Stefan Seifert
>Priority: Minor
> Fix For: API 2.27.6
>
>
> Hi, one of the users of AEM Rules for SonarQube has asked a question about 
> the {{ModifiableValueMap}} interface and the methods through which the map is 
> changeable. Here's the original [GitHub 
> issue|https://github.com/wttech/AEM-Rules-for-SonarQube/issues/237#issuecomment-1536213675].
> Whether the Sonar rule is valid or should be changed depends on the intended 
> way the MVM API should be used. I believe the current implementation of the 
> Sonar rule is based on a piece of Sling API Javadoc that I think could use 
> some clarification.
> Looking at [the latest available version of the 
> Javadoc|https://sling.apache.org/apidocs/sling12/org/apache/sling/api/resource/ModifiableValueMap.html],
>  here's what it says about changing resources through {{ModifiableValueMap}} 
> instances:
> {quote}The {{ModifiableValueMap}} is an extension of the 
> [{{ValueMap}}|https://sling.apache.org/apidocs/sling12/org/apache/sling/api/resource/ValueMap.html]
>  which allows to modify and persist properties. All changes to this map are 
> stored in the transient layer of the resource resolver or more precisely in 
> the transient layer of the resource provider managing this resource.
> Once 
> [{{ResourceResolver.commit()}}|https://sling.apache.org/apidocs/sling12/org/apache/sling/api/resource/ResourceResolver.html#commit--]
>  is called, the changes are finally persisted.
> *The modifiable value map is only changeable through one of these methods*
>  * *{{Map.put(Object, Object)}}*
>  * *{{Map.putAll(java.util.Map)}}*
>  * *{{Map.remove(Object)}}*
> *The map is not modifiable through the collections provided by*
>  * *{{Map.entrySet()}}*
>  * *{{Map.keySet()}}*
>  * *{{Map.values()}}*
> *And it can't be modified by these methods:*
>  * *{{Map.clear()}}*{quote}
> Since the {{ModifiableValueMap}} interface implements {{{}java.util.Map{}}}, 
> it also comes with the following methods:
>  * {{replace}}
>  * {{replaceAll}}
> I've done a quick test in AEM 6.5, by means of the Groovy console, and these 
> methods have the effect of modifying the map's underlying resource once the 
> session is saved/RR is committed.
> Should these methods also be documented as valid? Or is there a reason they 
> shouldn't be called?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (SLING-12249) Clarify "ADDED" resource changes for ancestor nodes of path

2024-07-10 Thread Joerg Hoh (Jira)


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

Joerg Hoh closed SLING-12249.
-

> Clarify "ADDED" resource changes for ancestor nodes of path
> ---
>
> Key: SLING-12249
> URL: https://issues.apache.org/jira/browse/SLING-12249
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Affects Versions: API 2.15.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: API 2.27.6
>
>
> Similar to what was clarified in SLING-6066, events for ancestors of the 
> registered path may not only be received for "REMOVED" resource changes but 
> also for "ADDED" resource changes.
> This happens e.g. for moving resources with the JCR Resource Provider which 
> uses internally the semantics from 
> https://issues.apache.org/jira/browse/OAK-1459?focusedCommentId=13911484&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13911484



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (SLING-11965) Make API build with Java 17

2024-07-10 Thread Joerg Hoh (Jira)


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

Joerg Hoh closed SLING-11965.
-

> Make API build with Java 17
> ---
>
> Key: SLING-11965
> URL: https://issues.apache.org/jira/browse/SLING-11965
> Project: Sling
>  Issue Type: Task
>  Components: API
>Affects Versions: API 2.27.2
>Reporter: Joerg Hoh
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: API 2.27.6
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (SLING-12062) add LazyBindings.putOnly

2024-07-10 Thread Joerg Hoh (Jira)


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

Joerg Hoh closed SLING-12062.
-

> add LazyBindings.putOnly
> 
>
> Key: SLING-12062
> URL: https://issues.apache.org/jira/browse/SLING-12062
> Project: Sling
>  Issue Type: Task
>  Components: API
>Affects Versions: API 2.27.2
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: API 2.27.6
>
>
> The LazyBindings support the lazy evaluation of values to avoid the potential 
> costly resolution of values at provisioning time (the values are only 
> resolved when requested via {{get}}).
> But if for some reasons the same key is put twice into a LazyBinding, the 
> second call to {{put(key, value)}} resolves the already provided value and 
> returns it, but this return value of {{put}} is often ignored.
> So the LazyBindings should have a {{putOnly(key,value)}} method, which 
> behaves the same way as the existing {{put}}, but does not return the 
> (resolved) previous value. This can be used by all providers which just push 
> data into the LazyBindings, but are not interested in any value returned by 
> the normal {{put}}.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (SLING-11546) ValueMap.get("calendar", String.class) conversion loses timezone information

2024-07-10 Thread Joerg Hoh (Jira)


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

Joerg Hoh closed SLING-11546.
-

> ValueMap.get("calendar", String.class) conversion loses timezone information
> 
>
> Key: SLING-11546
> URL: https://issues.apache.org/jira/browse/SLING-11546
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Affects Versions: API 2.21.0
>Reporter: Jelle Bouwmans
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: API 2.27.6
>
> Attachments: image-2022-08-19-10-41-27-129.png, 
> image-2022-08-19-10-45-25-409.png
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> When doing a ValueMap.get("calendar", String.class) conversion, before 
> SLING-8116, 
> ISO8601.format() was used. Now, Calendar.toInstant().toString() is used. This 
> gives a different result, because the ISO8601 gives the correct timezone, but 
> toInstant() gives the Zulu time.
> toInstant() does the following:
> {quote}public final Instant toInstant() \{ return 
> Instant.ofEpochMilli(getTimeInMillis()); }
> {quote}
> Timezones and offsets are completely ignored.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (SLING-11845) ResourceResolver.getSearchPaths() javadoc does not match implementation

2024-07-10 Thread Joerg Hoh (Jira)


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

Joerg Hoh closed SLING-11845.
-

> ResourceResolver.getSearchPaths() javadoc does not match implementation
> ---
>
> Key: SLING-11845
> URL: https://issues.apache.org/jira/browse/SLING-11845
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Affects Versions: API 2.27.2
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: API 2.27.6
>
>
> The [javadoc for 
> ResourceResolver.getSearchPaths()|https://sling.apache.org/apidocs/sling12/org/apache/sling/api/resource/ResourceResolver.html#getSearchPath--]
>  states:
> {quote}If no search path is set an empty array is returned.
> {quote}
> But the current implementation returns an array with a single value "/" in it 
> if no search path is specified 
> ([Link|https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/46f67c7cff13071d96cf58dde86730b6ffbb2639/src/main/java/org/apache/sling/resourceresolver/impl/ResourceResolverFactoryActivator.java#L307]).
> I recommend to adjust the javadoc to match the implementation.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (SLING-12370) Undo SLING-12062

2024-07-10 Thread Joerg Hoh (Jira)


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

Joerg Hoh closed SLING-12370.
-

> Undo SLING-12062
> 
>
> Key: SLING-12370
> URL: https://issues.apache.org/jira/browse/SLING-12370
> Project: Sling
>  Issue Type: Task
>  Components: API
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: API 2.27.6
>
>
> Undo SLING-12062
> See https://lists.apache.org/thread/bk24mrgjdmr3608ov69zbn3jx9drotw4



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (SLING-12371) Always update the metric for unclosed ResourceResolvers

2024-07-05 Thread Joerg Hoh (Jira)


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

Joerg Hoh updated SLING-12371:
--
Fix Version/s: Resource Resolver 1.11.8

> Always update the metric for unclosed ResourceResolvers
> ---
>
> Key: SLING-12371
> URL: https://issues.apache.org/jira/browse/SLING-12371
> Project: Sling
>  Issue Type: Task
>  Components: ResourceResolver
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: Resource Resolver 1.11.8
>
>
> Right now the metric 
> "sling:org.apache.sling.resourceresolver.unclosedResourceResolvers" is only 
> updated when the configuration "logUnclosedResolvers" is enabled, which is 
> not always the case.
> But the metric should be updated even if this setting is not enabled.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (SLING-12369) ModelAdapterFactory: expose the number of RequestDisposableCallbacks as metric

2024-07-05 Thread Joerg Hoh (Jira)


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

Joerg Hoh resolved SLING-12369.
---
Resolution: Fixed

> ModelAdapterFactory: expose the number of RequestDisposableCallbacks as metric
> --
>
> Key: SLING-12369
> URL: https://issues.apache.org/jira/browse/SLING-12369
> Project: Sling
>  Issue Type: Task
>  Components: Sling Models
>Affects Versions: Models Implementation 1.7.0
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: Models Implementation 1.7.2
>
>
> We should expose the number of entries in the map of 
> ModelAdapterFactory.RequestDisposableCallbacks; this would allow us to detect 
> a constantly growing number of entries, which will end up with an OOM. With a 
> metric we have the chance to detect those situations earlier.
> See also https://www.mail-archive.com/dev@sling.apache.org/msg131926.html and 
> SLING-12279



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (SLING-12369) ModelAdapterFactory: expose the number of RequestDisposableCallbacks as metric

2024-07-05 Thread Joerg Hoh (Jira)


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

Joerg Hoh updated SLING-12369:
--
Fix Version/s: Models Implementation 1.7.2

> ModelAdapterFactory: expose the number of RequestDisposableCallbacks as metric
> --
>
> Key: SLING-12369
> URL: https://issues.apache.org/jira/browse/SLING-12369
> Project: Sling
>  Issue Type: Task
>  Components: Sling Models
>Affects Versions: Models Implementation 1.7.0
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: Models Implementation 1.7.2
>
>
> We should expose the number of entries in the map of 
> ModelAdapterFactory.RequestDisposableCallbacks; this would allow us to detect 
> a constantly growing number of entries, which will end up with an OOM. With a 
> metric we have the chance to detect those situations earlier.
> See also https://www.mail-archive.com/dev@sling.apache.org/msg131926.html and 
> SLING-12279



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Assigned] (SLING-12371) Always update the metric for unclosed ResourceResolvers

2024-07-05 Thread Joerg Hoh (Jira)


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

Joerg Hoh reassigned SLING-12371:
-

Assignee: Joerg Hoh

> Always update the metric for unclosed ResourceResolvers
> ---
>
> Key: SLING-12371
> URL: https://issues.apache.org/jira/browse/SLING-12371
> Project: Sling
>  Issue Type: Task
>  Components: ResourceResolver
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
>
> Right now the metric 
> "sling:org.apache.sling.resourceresolver.unclosedResourceResolvers" is only 
> updated when the configuration "logUnclosedResolvers" is enabled, which is 
> not always the case.
> But the metric should be updated even if this setting is not enabled.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (SLING-12371) Always update the metric for unclosed ResourceResolvers

2024-07-05 Thread Joerg Hoh (Jira)
Joerg Hoh created SLING-12371:
-

 Summary: Always update the metric for unclosed ResourceResolvers
 Key: SLING-12371
 URL: https://issues.apache.org/jira/browse/SLING-12371
 Project: Sling
  Issue Type: Task
  Components: ResourceResolver
Reporter: Joerg Hoh


Right now the metric 
"sling:org.apache.sling.resourceresolver.unclosedResourceResolvers" is only 
updated when the configuration "logUnclosedResolvers" is enabled, which is not 
always the case.
But the metric should be updated even if this setting is not enabled.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Assigned] (SLING-12369) ModelAdapterFactory: expose the number of RequestDisposableCallbacks as metric

2024-07-05 Thread Joerg Hoh (Jira)


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

Joerg Hoh reassigned SLING-12369:
-

Assignee: Joerg Hoh

> ModelAdapterFactory: expose the number of RequestDisposableCallbacks as metric
> --
>
> Key: SLING-12369
> URL: https://issues.apache.org/jira/browse/SLING-12369
> Project: Sling
>  Issue Type: Task
>  Components: Sling Models
>Affects Versions: Models Implementation 1.7.0
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
>
> We should expose the number of entries in the map of 
> ModelAdapterFactory.RequestDisposableCallbacks; this would allow us to detect 
> a constantly growing number of entries, which will end up with an OOM. With a 
> metric we have the chance to detect those situations earlier.
> See also https://www.mail-archive.com/dev@sling.apache.org/msg131926.html and 
> SLING-12279



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (SLING-12370) Undo SLING-12062

2024-07-05 Thread Joerg Hoh (Jira)


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

Joerg Hoh resolved SLING-12370.
---
Resolution: Fixed

> Undo SLING-12062
> 
>
> Key: SLING-12370
> URL: https://issues.apache.org/jira/browse/SLING-12370
> Project: Sling
>  Issue Type: Task
>  Components: API
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: API 2.27.6
>
>
> Undo SLING-12062
> See https://lists.apache.org/thread/bk24mrgjdmr3608ov69zbn3jx9drotw4



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (SLING-12370) Undo SLING-12062

2024-07-05 Thread Joerg Hoh (Jira)


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

Joerg Hoh updated SLING-12370:
--
Fix Version/s: API 2.27.6

> Undo SLING-12062
> 
>
> Key: SLING-12370
> URL: https://issues.apache.org/jira/browse/SLING-12370
> Project: Sling
>  Issue Type: Task
>  Components: API
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: API 2.27.6
>
>
> Undo SLING-12062
> See https://lists.apache.org/thread/bk24mrgjdmr3608ov69zbn3jx9drotw4



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (SLING-12370) Undo SLING-12062

2024-07-05 Thread Joerg Hoh (Jira)
Joerg Hoh created SLING-12370:
-

 Summary: Undo SLING-12062
 Key: SLING-12370
 URL: https://issues.apache.org/jira/browse/SLING-12370
 Project: Sling
  Issue Type: Task
  Components: API
Reporter: Joerg Hoh
Assignee: Joerg Hoh


Undo SLING-12062

See https://lists.apache.org/thread/bk24mrgjdmr3608ov69zbn3jx9drotw4





--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (SLING-12369) ModelAdapterFactory: expose the number of RequestDisposableCallbacks as metric

2024-07-03 Thread Joerg Hoh (Jira)
Joerg Hoh created SLING-12369:
-

 Summary: ModelAdapterFactory: expose the number of 
RequestDisposableCallbacks as metric
 Key: SLING-12369
 URL: https://issues.apache.org/jira/browse/SLING-12369
 Project: Sling
  Issue Type: Task
  Components: Sling Models
Affects Versions: Models Implementation 1.7.0
Reporter: Joerg Hoh


We should expose the number of entries in the map of 
ModelAdapterFactory.RequestDisposableCallbacks; this would allow us to detect a 
constantly growing number of entries, which will end up with an OOM. With a 
metric we have the chance to detect those situations earlier.

See also https://www.mail-archive.com/dev@sling.apache.org/msg131926.html and 
SLING-12279



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (SLING-12264) check save() operations

2024-06-18 Thread Joerg Hoh (Jira)


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

Joerg Hoh resolved SLING-12264.
---
Resolution: Fixed

> check save() operations
> ---
>
> Key: SLING-12264
> URL: https://issues.apache.org/jira/browse/SLING-12264
> Project: Sling
>  Issue Type: Task
>  Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.46
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: Repoinit JCR 1.1.52
>
>
> Before doing a session.save() operation, it should always be checked if there 
> is something to save at all. 
> This can speed up the execution of individual repoinit statements if the 
> repoinit statement does not need to be applied.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Assigned] (SLING-12264) check save() operations

2024-06-18 Thread Joerg Hoh (Jira)


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

Joerg Hoh reassigned SLING-12264:
-

Assignee: Joerg Hoh

> check save() operations
> ---
>
> Key: SLING-12264
> URL: https://issues.apache.org/jira/browse/SLING-12264
> Project: Sling
>  Issue Type: Task
>  Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.46
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: Repoinit JCR 1.1.52
>
>
> Before doing a session.save() operation, it should always be checked if there 
> is something to save at all. 
> This can speed up the execution of individual repoinit statements if the 
> repoinit statement does not need to be applied.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (SLING-11965) Make API build with Java 17

2024-06-13 Thread Joerg Hoh (Jira)


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

Joerg Hoh updated SLING-11965:
--
Fix Version/s: API 2.27.6
   (was: API 2.27.4)

> Make API build with Java 17
> ---
>
> Key: SLING-11965
> URL: https://issues.apache.org/jira/browse/SLING-11965
> Project: Sling
>  Issue Type: Task
>  Components: API
>Affects Versions: API 2.27.2
>Reporter: Joerg Hoh
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: API 2.27.6
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (SLING-11878) Clarify Javadoc on which methods allow a ModifiableValueMap to be changed

2024-06-13 Thread Joerg Hoh (Jira)


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

Joerg Hoh updated SLING-11878:
--
Fix Version/s: API 2.27.6
   (was: API 2.27.4)

> Clarify Javadoc on which methods allow a ModifiableValueMap to be changed
> -
>
> Key: SLING-11878
> URL: https://issues.apache.org/jira/browse/SLING-11878
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Affects Versions: API 2.27.2
>Reporter: Tomasz Niedźwiedź
>Assignee: Stefan Seifert
>Priority: Minor
> Fix For: API 2.27.6
>
>
> Hi, one of the users of AEM Rules for SonarQube has asked a question about 
> the {{ModifiableValueMap}} interface and the methods through which the map is 
> changeable. Here's the original [GitHub 
> issue|https://github.com/wttech/AEM-Rules-for-SonarQube/issues/237#issuecomment-1536213675].
> Whether the Sonar rule is valid or should be changed depends on the intended 
> way the MVM API should be used. I believe the current implementation of the 
> Sonar rule is based on a piece of Sling API Javadoc that I think could use 
> some clarification.
> Looking at [the latest available version of the 
> Javadoc|https://sling.apache.org/apidocs/sling12/org/apache/sling/api/resource/ModifiableValueMap.html],
>  here's what it says about changing resources through {{ModifiableValueMap}} 
> instances:
> {quote}The {{ModifiableValueMap}} is an extension of the 
> [{{ValueMap}}|https://sling.apache.org/apidocs/sling12/org/apache/sling/api/resource/ValueMap.html]
>  which allows to modify and persist properties. All changes to this map are 
> stored in the transient layer of the resource resolver or more precisely in 
> the transient layer of the resource provider managing this resource.
> Once 
> [{{ResourceResolver.commit()}}|https://sling.apache.org/apidocs/sling12/org/apache/sling/api/resource/ResourceResolver.html#commit--]
>  is called, the changes are finally persisted.
> *The modifiable value map is only changeable through one of these methods*
>  * *{{Map.put(Object, Object)}}*
>  * *{{Map.putAll(java.util.Map)}}*
>  * *{{Map.remove(Object)}}*
> *The map is not modifiable through the collections provided by*
>  * *{{Map.entrySet()}}*
>  * *{{Map.keySet()}}*
>  * *{{Map.values()}}*
> *And it can't be modified by these methods:*
>  * *{{Map.clear()}}*{quote}
> Since the {{ModifiableValueMap}} interface implements {{{}java.util.Map{}}}, 
> it also comes with the following methods:
>  * {{replace}}
>  * {{replaceAll}}
> I've done a quick test in AEM 6.5, by means of the Groovy console, and these 
> methods have the effect of modifying the map's underlying resource once the 
> session is saved/RR is committed.
> Should these methods also be documented as valid? Or is there a reason they 
> shouldn't be called?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (SLING-12219) ResourceUtil.normalize does not handle segments with multiple dots correctly

2024-06-13 Thread Joerg Hoh (Jira)


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

Joerg Hoh updated SLING-12219:
--
Fix Version/s: API 2.27.6
   (was: API 2.27.4)

> ResourceUtil.normalize does not handle segments with multiple dots correctly
> 
>
> Key: SLING-12219
> URL: https://issues.apache.org/jira/browse/SLING-12219
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Affects Versions: API 2.27.2
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: API 2.27.6
>
>
> If a path segment contains more than two dots but anything else, then 
> ResourceUtil.normalize does not handle these correctly. It should just return 
> null. Instead in some cases it is leaving the segment untouched or shortens 
> it for example from four dots to two dots.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (SLING-11845) ResourceResolver.getSearchPaths() javadoc does not match implementation

2024-06-13 Thread Joerg Hoh (Jira)


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

Joerg Hoh updated SLING-11845:
--
Fix Version/s: API 2.27.6
   (was: API 2.27.4)

> ResourceResolver.getSearchPaths() javadoc does not match implementation
> ---
>
> Key: SLING-11845
> URL: https://issues.apache.org/jira/browse/SLING-11845
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Affects Versions: API 2.27.2
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: API 2.27.6
>
>
> The [javadoc for 
> ResourceResolver.getSearchPaths()|https://sling.apache.org/apidocs/sling12/org/apache/sling/api/resource/ResourceResolver.html#getSearchPath--]
>  states:
> {quote}If no search path is set an empty array is returned.
> {quote}
> But the current implementation returns an array with a single value "/" in it 
> if no search path is specified 
> ([Link|https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/46f67c7cff13071d96cf58dde86730b6ffbb2639/src/main/java/org/apache/sling/resourceresolver/impl/ResourceResolverFactoryActivator.java#L307]).
> I recommend to adjust the javadoc to match the implementation.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (SLING-12215) javadoc of ResourceUtil.normalize does not match implementation

2024-06-13 Thread Joerg Hoh (Jira)


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

Joerg Hoh updated SLING-12215:
--
Fix Version/s: API 2.27.6
   (was: API 2.27.4)

> javadoc of ResourceUtil.normalize does not match implementation
> ---
>
> Key: SLING-12215
> URL: https://issues.apache.org/jira/browse/SLING-12215
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Minor
> Fix For: API 2.27.6
>
>
> The javadoc mentions that it returns null on relative paths, but the method 
> actually handles them



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (SLING-12062) add LazyBindings.putOnly

2024-06-13 Thread Joerg Hoh (Jira)


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

Joerg Hoh updated SLING-12062:
--
Fix Version/s: API 2.27.6
   (was: API 2.27.4)

> add LazyBindings.putOnly
> 
>
> Key: SLING-12062
> URL: https://issues.apache.org/jira/browse/SLING-12062
> Project: Sling
>  Issue Type: Task
>  Components: API
>Affects Versions: API 2.27.2
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: API 2.27.6
>
>
> The LazyBindings support the lazy evaluation of values to avoid the potential 
> costly resolution of values at provisioning time (the values are only 
> resolved when requested via {{get}}).
> But if for some reasons the same key is put twice into a LazyBinding, the 
> second call to {{put(key, value)}} resolves the already provided value and 
> returns it, but this return value of {{put}} is often ignored.
> So the LazyBindings should have a {{putOnly(key,value)}} method, which 
> behaves the same way as the existing {{put}}, but does not return the 
> (resolved) previous value. This can be used by all providers which just push 
> data into the LazyBindings, but are not interested in any value returned by 
> the normal {{put}}.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (SLING-12249) Clarify "ADDED" resource changes for ancestor nodes of path

2024-06-13 Thread Joerg Hoh (Jira)


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

Joerg Hoh updated SLING-12249:
--
Fix Version/s: API 2.27.6
   (was: API 2.27.4)

> Clarify "ADDED" resource changes for ancestor nodes of path
> ---
>
> Key: SLING-12249
> URL: https://issues.apache.org/jira/browse/SLING-12249
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Affects Versions: API 2.15.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: API 2.27.6
>
>
> Similar to what was clarified in SLING-6066, events for ancestors of the 
> registered path may not only be received for "REMOVED" resource changes but 
> also for "ADDED" resource changes.
> This happens e.g. for moving resources with the JCR Resource Provider which 
> uses internally the semantics from 
> https://issues.apache.org/jira/browse/OAK-1459?focusedCommentId=13911484&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13911484



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


  1   2   3   4   5   6   7   8   9   10   >