RE: [VOTE] Release Apache Sling HApi - Sling Hypermedia API client-side tools version 1.0.0

[Stefan Seifert]

no problem adding it later.

stefan

>-Original Message-
>From: Andrei Dulvac [mailto:andrei.dul...@gmail.com]
>Sent: Friday, July 15, 2016 7:38 PM
>To: dev@sling.apache.org
>Subject: Re: [VOTE] Release Apache Sling HApi - Sling Hypermedia API
>client-side tools version 1.0.0
>
>Hi, I'll add some docu for the client as well, thanks for pointing that
>out.
>
>Does it have to be for this release?
>
>-Andrei

Re: [VOTE] Release Apache Sling HApi - Sling Hypermedia API client-side tools version 1.0.0

[Andrei Dulvac]

Hi, I'll add some docu for the client as well, thanks for pointing that
out.

Does it have to be for this release?

-Andrei

On Thu, Jul 14, 2016 at 21:58 Stefan Seifert  wrote:

> +1
>
> perhaps you can add a short documentation for what it is good and how it
> can be used - [1] does not mention the client.
>
> stefan
>
> [1] https://github.com/apache/sling/tree/trunk/contrib/extensions/hapi
>
>

Re: [VOTE] Release Apache Sling HApi - Sling Hypermedia API client-side tools version 1.0.0

[Andrei Dulvac]

Hi Oliver,

Because it's a client-side tool, meant to be used outside the Sling
instance, like it HTTP tests. I guess it could become a bundle, but I don't
really see the point right now.

-Andrei
On Fri, Jul 15, 2016 at 18:54 Oliver Lietz  wrote:

> On Wednesday 13 July 2016 15:59:35 Andrei Dulvac wrote:
> > Hi,
>
> Hi Andrei,
>
> > We solved 2 issues in this release:
> > *https://issues.apache.org/jira/browse/SLING/fixforversion/12337959
> > *
> > 
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachesling-1479/
>
> most of our releases are bundles. Is there a reason why this release is
> built
> without OSGi metadata?
>
> Regards,
> O.
>
>

Re: [VOTE] Release Apache Sling HApi - Sling Hypermedia API client-side tools version 1.0.0

[Oliver Lietz]

On Wednesday 13 July 2016 15:59:35 Andrei Dulvac wrote:
> Hi,

Hi Andrei,

> We solved 2 issues in this release:
> *https://issues.apache.org/jira/browse/SLING/fixforversion/12337959
> *
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1479/

most of our releases are bundles. Is there a reason why this release is built 
without OSGi metadata?

Regards,
O.

[jira] [Commented] (SLING-5849) Inconsistent event handling between local package importer and its factory

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili commented on SLING-5849:


sure, thanks [~marett]!

> Inconsistent event handling between local package importer and its factory
> --
>
> Key: SLING-5849
> URL: https://issues.apache.org/jira/browse/SLING-5849
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution, Extensions
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Attachments: SLING-5849.diff
>
>
> {{LocalDistributionPackageImporterFactory}} factory sends events [0] which 
> are not sent by the {{LocalDistributionPackageImporter}}. As the two classes 
> are used (depending on the configuration) this creates an inconsistent 
> handling of events.
> [0] 
> https://github.com/apache/sling/blob/006f9d1601c7b3dec1cd3ab303bc34e26a4870a3/contrib/extensions/distribution/core/src/main/java/org/apache/sling/distribution/packaging/impl/importer/LocalDistributionPackageImporterFactory.java#L94



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5849) Inconsistent event handling between local package importer and its factory

[Timothee Maret (JIRA)]

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

Timothee Maret updated SLING-5849:
--
Attachment: SLING-5849.diff

> Inconsistent event handling between local package importer and its factory
> --
>
> Key: SLING-5849
> URL: https://issues.apache.org/jira/browse/SLING-5849
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution, Extensions
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Attachments: SLING-5849.diff
>
>
> {{LocalDistributionPackageImporterFactory}} factory sends events [0] which 
> are not sent by the {{LocalDistributionPackageImporter}}. As the two classes 
> are used (depending on the configuration) this creates an inconsistent 
> handling of events.
> [0] 
> https://github.com/apache/sling/blob/006f9d1601c7b3dec1cd3ab303bc34e26a4870a3/contrib/extensions/distribution/core/src/main/java/org/apache/sling/distribution/packaging/impl/importer/LocalDistributionPackageImporterFactory.java#L94



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5849) Inconsistent event handling between local package importer and its factory

[Timothee Maret (JIRA)]

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

Timothee Maret commented on SLING-5849:
---

[~teofili] could you review/apply this ?

> Inconsistent event handling between local package importer and its factory
> --
>
> Key: SLING-5849
> URL: https://issues.apache.org/jira/browse/SLING-5849
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution, Extensions
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Attachments: SLING-5849.diff
>
>
> {{LocalDistributionPackageImporterFactory}} factory sends events [0] which 
> are not sent by the {{LocalDistributionPackageImporter}}. As the two classes 
> are used (depending on the configuration) this creates an inconsistent 
> handling of events.
> [0] 
> https://github.com/apache/sling/blob/006f9d1601c7b3dec1cd3ab303bc34e26a4870a3/contrib/extensions/distribution/core/src/main/java/org/apache/sling/distribution/packaging/impl/importer/LocalDistributionPackageImporterFactory.java#L94



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5849) Inconsistent event handling between local package importer and its factory

[Timothee Maret (JIRA)]

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

Timothee Maret updated SLING-5849:
--
Flags: Patch

> Inconsistent event handling between local package importer and its factory
> --
>
> Key: SLING-5849
> URL: https://issues.apache.org/jira/browse/SLING-5849
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution, Extensions
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Attachments: SLING-5849.diff
>
>
> {{LocalDistributionPackageImporterFactory}} factory sends events [0] which 
> are not sent by the {{LocalDistributionPackageImporter}}. As the two classes 
> are used (depending on the configuration) this creates an inconsistent 
> handling of events.
> [0] 
> https://github.com/apache/sling/blob/006f9d1601c7b3dec1cd3ab303bc34e26a4870a3/contrib/extensions/distribution/core/src/main/java/org/apache/sling/distribution/packaging/impl/importer/LocalDistributionPackageImporterFactory.java#L94



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5849) Inconsistent event handling between local package importer and its factory

[Timothee Maret (JIRA)]

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

Timothee Maret commented on SLING-5849:
---

Opened PR https://github.com/apache/sling/pull/152

> Inconsistent event handling between local package importer and its factory
> --
>
> Key: SLING-5849
> URL: https://issues.apache.org/jira/browse/SLING-5849
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution, Extensions
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>
> {{LocalDistributionPackageImporterFactory}} factory sends events [0] which 
> are not sent by the {{LocalDistributionPackageImporter}}. As the two classes 
> are used (depending on the configuration) this creates an inconsistent 
> handling of events.
> [0] 
> https://github.com/apache/sling/blob/006f9d1601c7b3dec1cd3ab303bc34e26a4870a3/contrib/extensions/distribution/core/src/main/java/org/apache/sling/distribution/packaging/impl/importer/LocalDistributionPackageImporterFactory.java#L94



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5849) Inconsistent event handling between local package importer and its factory

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SLING-5849:
---

GitHub user tmaret opened a pull request:

https://github.com/apache/sling/pull/152

SLING-5849 - Inconsistent event handling between local package importer and 
its factory

* Generate Package Events in the package importer instead of the factory

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/tmaret/sling SLING-5849

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/152.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #152


commit 4151cda6cb741ceaa0975ec0180fedf7ce75434c
Author: tmaret 
Date:   2016-07-15T14:42:35Z

SLING-5849 - Inconsistent event handling between local package importer and 
its factory

* Generate Package Events in the package importer instead of the factory




> Inconsistent event handling between local package importer and its factory
> --
>
> Key: SLING-5849
> URL: https://issues.apache.org/jira/browse/SLING-5849
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution, Extensions
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>
> {{LocalDistributionPackageImporterFactory}} factory sends events [0] which 
> are not sent by the {{LocalDistributionPackageImporter}}. As the two classes 
> are used (depending on the configuration) this creates an inconsistent 
> handling of events.
> [0] 
> https://github.com/apache/sling/blob/006f9d1601c7b3dec1cd3ab303bc34e26a4870a3/contrib/extensions/distribution/core/src/main/java/org/apache/sling/distribution/packaging/impl/importer/LocalDistributionPackageImporterFactory.java#L94



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] sling pull request #152: SLING-5849 - Inconsistent event handling between lo...

[tmaret]

GitHub user tmaret opened a pull request:

https://github.com/apache/sling/pull/152

SLING-5849 - Inconsistent event handling between local package importer and 
its factory

* Generate Package Events in the package importer instead of the factory

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/tmaret/sling SLING-5849

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/152.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #152


commit 4151cda6cb741ceaa0975ec0180fedf7ce75434c
Author: tmaret 
Date:   2016-07-15T14:42:35Z

SLING-5849 - Inconsistent event handling between local package importer and 
its factory

* Generate Package Events in the package importer instead of the factory




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

RE: [DISCUSS] Path filtering support for ResourceChangeListeners

[Stefan Seifert]

i personally would prefer using regex instead of glob syntax, because other 
areas in sling use it as well for path matching (e.g. sling mapping).

about the performance implications where the filtering should take place i 
cannot say much currently.

stefan

>-Original Message-
>From: Radu Cotescu [mailto:r...@apache.org]
>Sent: Friday, July 15, 2016 3:24 PM
>To: Sling Dev
>Subject: [DISCUSS] Path filtering support for ResourceChangeListeners
>
>Hello,
>
>The current release of the Sling API
>org.apache.sling.api.resource.observation.ResourceChangeListener
>(org.apache.sling.api.resource.observation;version=1.0.0) specification
>does not provide any kind of support for path filtering or pattern
>matching. As I understand it, the future regarding Resource observation is
>to switch from registering OSGi EventHandlers to registering
>ResourceChangeListeners. If one concept replaces the other, then we need to
>find an acceptable solution for the filtering support that EventHandlers
>brought to the table [0][1].
>
>The implementation I proposed [2] relied on adding support for the Glob
>pattern matching provided by java.nio.file.PathMatcher (albeit I only
>thought of a sub-set of it). What syntax would you prefer and why? Do we
>need to support the full Glob syntax? Would a sub-set be enough? Do we want
>to also support RegEx? Should we actually filter everything directly in the
>ResourceChangeListener#onChange and not care about providing support for
>filtering in the service's configuration?
>
>Thanks,
>Radu
>
>[0] -
>https://osgi.org/javadoc/r6/cmpn/org/osgi/service/event/EventHandler.html
>[1] -
>https://osgi.org/javadoc/r6/cmpn/org/osgi/service/event/EventConstants.html
>#EVENT_FILTER
>[2] -
>https://github.com/apache/sling/commit/4264dc16205abab300d041d15524c6d996b9
>d40a

[jira] [Created] (SLING-5849) Inconsistent event handling between local package importer and its factory

[Timothee Maret (JIRA)]

Timothee Maret created SLING-5849:
-

 Summary: Inconsistent event handling between local package 
importer and its factory
 Key: SLING-5849
 URL: https://issues.apache.org/jira/browse/SLING-5849
 Project: Sling
  Issue Type: Bug
  Components: Distribution, Extensions
Affects Versions: Content Distribution Core 0.1.18
Reporter: Timothee Maret
Assignee: Timothee Maret


{{LocalDistributionPackageImporterFactory}} factory sends events [0] which are 
not sent by the {{LocalDistributionPackageImporter}}. As the two classes are 
used (depending on the configuration) this creates an inconsistent handling of 
events.



[0] 
https://github.com/apache/sling/blob/006f9d1601c7b3dec1cd3ab303bc34e26a4870a3/contrib/extensions/distribution/core/src/main/java/org/apache/sling/distribution/packaging/impl/importer/LocalDistributionPackageImporterFactory.java#L94





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5837) Allow ResourceChangeListeners to define glob patterns for resource matching

[Radu Cotescu (JIRA)]

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

Radu Cotescu commented on SLING-5837:
-

I opened a thread at http://sling.markmail.org/thread/yn4niose3wb7qilp.

> Allow ResourceChangeListeners to define glob patterns for resource matching
> ---
>
> Key: SLING-5837
> URL: https://issues.apache.org/jira/browse/SLING-5837
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Affects Versions: API 2.12.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: API 2.14.0
>
> Attachments: SLING-5837.patch
>
>
> While the previous way to interact with Resource change events through 
> registering {{EventHandler}} sevices allowed defining glob patterns for 
> matching the watched paths, the current state of the 
> {{org.apache.sling.api.resource.observation.ResourceChangeListener}} only 
> allows subscribing to events for concrete paths.
> In order to allow for the same filtering flexibility, 
> {{ResourceChangeListener}} should also accept glob patterns for its 
> {{resource.paths}} configuration property.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [DISCUSS] Path filtering support for ResourceChangeListeners

[Radu Cotescu]

BTW, the issue is https://issues.apache.org/jira/browse/SLING-5837.

On Fri, 15 Jul 2016 at 15:24 Radu Cotescu  wrote:

> Hello,
>
> The current release of the Sling API
> org.apache.sling.api.resource.observation.ResourceChangeListener
> (org.apache.sling.api.resource.observation;version=1.0.0) specification
> does not provide any kind of support for path filtering or pattern
> matching. As I understand it, the future regarding Resource observation is
> to switch from registering OSGi EventHandlers to registering
> ResourceChangeListeners. If one concept replaces the other, then we need to
> find an acceptable solution for the filtering support that EventHandlers
> brought to the table [0][1].
>
> The implementation I proposed [2] relied on adding support for the Glob
> pattern matching provided by java.nio.file.PathMatcher (albeit I only
> thought of a sub-set of it). What syntax would you prefer and why? Do we
> need to support the full Glob syntax? Would a sub-set be enough? Do we want
> to also support RegEx? Should we actually filter everything directly in the
> ResourceChangeListener#onChange and not care about providing support for
> filtering in the service's configuration?
>
> Thanks,
> Radu
>
> [0] -
> https://osgi.org/javadoc/r6/cmpn/org/osgi/service/event/EventHandler.html
> [1] -
> https://osgi.org/javadoc/r6/cmpn/org/osgi/service/event/EventConstants.html#EVENT_FILTER
> [2] -
> https://github.com/apache/sling/commit/4264dc16205abab300d041d15524c6d996b9d40a
>
>
>

[DISCUSS] Path filtering support for ResourceChangeListeners

[Radu Cotescu]

Hello,

The current release of the Sling API
org.apache.sling.api.resource.observation.ResourceChangeListener
(org.apache.sling.api.resource.observation;version=1.0.0) specification
does not provide any kind of support for path filtering or pattern
matching. As I understand it, the future regarding Resource observation is
to switch from registering OSGi EventHandlers to registering
ResourceChangeListeners. If one concept replaces the other, then we need to
find an acceptable solution for the filtering support that EventHandlers
brought to the table [0][1].

The implementation I proposed [2] relied on adding support for the Glob
pattern matching provided by java.nio.file.PathMatcher (albeit I only
thought of a sub-set of it). What syntax would you prefer and why? Do we
need to support the full Glob syntax? Would a sub-set be enough? Do we want
to also support RegEx? Should we actually filter everything directly in the
ResourceChangeListener#onChange and not care about providing support for
filtering in the service's configuration?

Thanks,
Radu

[0] -
https://osgi.org/javadoc/r6/cmpn/org/osgi/service/event/EventHandler.html
[1] -
https://osgi.org/javadoc/r6/cmpn/org/osgi/service/event/EventConstants.html#EVENT_FILTER
[2] -
https://github.com/apache/sling/commit/4264dc16205abab300d041d15524c6d996b9d40a

[jira] [Updated] (SLING-5837) Allow ResourceChangeListeners to define glob patterns for resource matching

[Radu Cotescu (JIRA)]

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

Radu Cotescu updated SLING-5837:

Fix Version/s: (was: API 2.13.0)
   API 2.14.0

> Allow ResourceChangeListeners to define glob patterns for resource matching
> ---
>
> Key: SLING-5837
> URL: https://issues.apache.org/jira/browse/SLING-5837
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Affects Versions: API 2.12.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: API 2.14.0
>
> Attachments: SLING-5837.patch
>
>
> While the previous way to interact with Resource change events through 
> registering {{EventHandler}} sevices allowed defining glob patterns for 
> matching the watched paths, the current state of the 
> {{org.apache.sling.api.resource.observation.ResourceChangeListener}} only 
> allows subscribing to events for concrete paths.
> In order to allow for the same filtering flexibility, 
> {{ResourceChangeListener}} should also accept glob patterns for its 
> {{resource.paths}} configuration property.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (SLING-5837) Allow ResourceChangeListeners to define glob patterns for resource matching

[Radu Cotescu (JIRA)]

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

Radu Cotescu reopened SLING-5837:
-

> Allow ResourceChangeListeners to define glob patterns for resource matching
> ---
>
> Key: SLING-5837
> URL: https://issues.apache.org/jira/browse/SLING-5837
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Affects Versions: API 2.12.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: API 2.14.0
>
> Attachments: SLING-5837.patch
>
>
> While the previous way to interact with Resource change events through 
> registering {{EventHandler}} sevices allowed defining glob patterns for 
> matching the watched paths, the current state of the 
> {{org.apache.sling.api.resource.observation.ResourceChangeListener}} only 
> allows subscribing to events for concrete paths.
> In order to allow for the same filtering flexibility, 
> {{ResourceChangeListener}} should also accept glob patterns for its 
> {{resource.paths}} configuration property.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[CANCELLED][VOTE] Release Apache Sling API 2.13.0

[Radu Cotescu]

Let's cancel this release until we all agree on a solution for the
ResourceChangeListener path filtering support issues identified in
SLING-5837. I'll open a new thread after I delete the tag and drop the
staging repository.

Thanks,
Radu

On Wed, 13 Jul 2016 at 15:14 Radu Cotescu  wrote:

> Hi Oliver,
>
> The matcher works ok on both Unix and Windows - see [0] for more details.
>
> Regards,
> Radu
>
> [0] -
> https://issues.apache.org/jira/browse/SLING-5837?focusedCommentId=15374960=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15374960
>
>
> On Wed, 13 Jul 2016 at 12:57 Oliver Lietz  wrote:
>
>> On Wednesday 13 July 2016 10:35:22 Radu Cotescu wrote:
>> > Hi,
>> >
>> > We solved one issue in this release:
>> > https://issues.apache.org/jira/browse/SLING/fixforversion/12337851
>>
>> Hi Radu,
>>
>> see my comment in SLING-5837 please.
>>
>> Regards,
>> O.
>>
>>

Re: [DISCUSS] new Scripting Service to provide ResourceResolvers with limited access

[Radu Cotescu]

Hi,

I think I haven't phrased properly my idea so let's give it another shot.

The use cases that I'd like to cover with this service is getting a unified
resource resolver that will be used for:

* resolving script dependencies (data-sly-include / sling:include / other
dependencies like the ones you can define in the Sightly JavaScript Use-API
through the use function, etc.)
* resolving servlets
* resolving scripts that are not request bound (think of workflow
processing engines that support scripts for their steps but that are not
based on HttpServletRequest)

We already have an administrative resource resolver in SlingServletResolver
that for scripting engines gets added into the ScriptContext. ScriptEngines
could rely on it, but passing it down to their own dependency solving
mechanisms might prove tricky, as the ScriptContext provides too much
information and the Bindings are too sensitive for something like this.

Essentially this new service should reside in o.a.s.scripting.api, with an
implementation in o.a.s.scripting.core, so that all o.a.s.scripting
consumers have a single gateway for retrieving scripts, with only one
service user to manage, with a single set of ACLs. For more specific cases
(sub-sets / super-sets of this permissions model) each module should
implement its own access control and reading mechanisms.

I see the service exposing something like:

/**
 * Provides a request-scoped ResourceResolver with only read access to the
search paths. This resolver should be used for script resolution in the
context of the same request rendering process. The ResourceResolver should
not be closed by consumers (calling ResourceResolver#close doesn't do
anything), since this service will handle the closing operation
automatically. The ResourceResolver will be shared between scripting
dependencies that render parts of the response for the same request. */
ScriptingResourceResolver#getRequestScopedResourceResolver()

/**
 * Provides a ResourceResolver with only read access to the search paths.
Once you're done processing Resource with this ResourceResolver make sure
to close it. */
ScriptingResourceResolver#getResourceResolver()

The implementation is very similar to what the SlingServletResolver does
now with the perThreadResourceResolver, but in the end the
SlingServletResolver will delegate this to the new service, like any other
consumer of the o.a.s.scripting.api.

In Sling I think it's safe to create the service-user like (security
experts are asked to chime in):

[:repoinit]
create path (sling:Folder) /libs
create path (sling:Folder) /apps
create service user sling-scripting

set ACL for sling-scripting
  allow jcr:readon  /libs,/apps
  deny  jcr:write   on  /libs,/apps
end

What are your views on this?

Have a great weekend!

Regards,
Radu

On Fri, 15 Jul 2016 at 07:57 Carsten Ziegeler  wrote:

> > On Thursday 14 July 2016 20:55:26 Carsten Ziegeler wrote:
>
> >
> >> In addition, what if for whatever reason want to use a different service
> >> user for the jsp engine than for the sightly engine?
> >
> > You could still add dedicated service users and ACLs.
>
> But only if the implementation is not using a new api which underneath
> resolves to the same service user :)
>
> Carsten
> >
> >> With the proposal we're tying something together which does not
> >> necessarily belong together just for the sake of saving a single OSGi
> >> configuration.
> >
> > Right. I'm not convinced from that approach either.
> >
> > O.
> >
> >> Carsten
> >
> >
>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>
>

[jira] [Commented] (SLING-5831) Support different thread pools for scheduled tasks

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra commented on SLING-5831:


Thanks Carsten for this support!. In Oak we use following approach to use Sling 
Scheduler. Can you suggest what change would be required there to make use of 
this new feature

{code}
public static Registration scheduleWithFixedDelay(
Whiteboard whiteboard, Runnable runnable, long delayInSeconds, 
boolean runOnSingleClusterNode) {
ImmutableMap.Builder builder = ImmutableMap.builder()
.put("scheduler.period", delayInSeconds)
.put("scheduler.concurrent", false);
if (runOnSingleClusterNode) {
//Make use of feature while running in Sling SLING-2979
builder.put("scheduler.runOn", "SINGLE");
}
return whiteboard.register(
Runnable.class, runnable, builder.build());
}
{code}

> Support different thread pools for scheduled tasks
> --
>
> Key: SLING-5831
> URL: https://issues.apache.org/jira/browse/SLING-5831
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Commons Scheduler 2.4.16
>
>
> Right now the scheduler uses a single thread pool. While this thread pool can 
> be configured, it means that all scheduled tasks share this pool. In order to 
> prioratize different tasks over others and avoid blocking important jobs 
> through unimportant once, we could maybe add a configuration property to 
> select a thread pool name.
> If a pool with that name exists, it's used - if not the default is used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5831) Support different thread pools for scheduled tasks

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-5831:
-

[~chetanm] I've done a first implementation which creates now the schedulers on 
demand. To avoid creating endless pools/schedulers, the scheduler is configured 
with a list of allowed thread pool names. If a pool is not in that list, the 
job is scheduled using the default pool.

> Support different thread pools for scheduled tasks
> --
>
> Key: SLING-5831
> URL: https://issues.apache.org/jira/browse/SLING-5831
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Commons Scheduler 2.4.16
>
>
> Right now the scheduler uses a single thread pool. While this thread pool can 
> be configured, it means that all scheduled tasks share this pool. In order to 
> prioratize different tasks over others and avoid blocking important jobs 
> through unimportant once, we could maybe add a configuration property to 
> select a thread pool name.
> If a pool with that name exists, it's used - if not the default is used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[RESULT] [VOTE] Release Apache Sling Testing Sling Mock 1.7.0, Sling Mock 2.0.0, Sling Mock Oak 2.0.0

[Stefan Seifert]

Hi,

The vote has passed with the following result :

+1 (binding): Robert Munteanu, Carsten Ziegeler, Stefan Seifert, Oliver Lietz

I will copy this release to the Sling dist directory and
promote the artifacts to the central Maven repository.


stefan

Re: Prefix for our service user names

[Bertrand Delacretaz]

On Fri, Jul 15, 2016 at 11:48 AM, Oliver Lietz  wrote:
> ...I don't think JCR will lead to issues but maybe our resource resolution 
> with
> selectors and extensions...

Good point so a sling- prefix is probably safer.

-Bertrand

Re: Prefix for our service user names

[Oliver Lietz]

On Friday 15 July 2016 11:35:20 Bertrand Delacretaz wrote:
> Hi,

Hi,

> We're starting to define service users that various Sling modules will
> need (like SLING-5848) and Oliver suggests using a prefix for those
> usernames as a simple form of namespacing.
> 
> How about "sling." - do people see possible issues with JCR usernames
> like sling.someserviceuser ?

I don't think JCR will lead to issues but maybe our resource resolution with 
selectors and extensions.

We should be careful which pattern we choose.

Regards,
O.

> -Bertrand

Prefix for our service user names

[Bertrand Delacretaz]

Hi,

We're starting to define service users that various Sling modules will
need (like SLING-5848) and Oliver suggests using a prefix for those
usernames as a simple form of namespacing.

How about "sling." - do people see possible issues with JCR usernames
like sling.someserviceuser ?

-Bertrand

[jira] [Commented] (SLING-5848) Define service user and ACLs for Scripting

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-5848:


Good idea but let's discuss on dl-dev, I'll start this thread right now.

> Define service user and ACLs for Scripting
> --
>
> Key: SLING-5848
> URL: https://issues.apache.org/jira/browse/SLING-5848
> Project: Sling
>  Issue Type: Task
>  Components: Scripting
>Reporter: Oliver Lietz
>
> Scripting implementations require a (service) ResourceResolver with very 
> limited read rights to read scripts.
> Reading can be limited to these paths:
> * {{/apps}}
> * {{/libs}}
> * {{/etc}} (?)
> Name for service user: {{scripting}} or {{sling-scripting}} or 
> {{sling.scripting}} (?)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5848) Define service user and ACLs for Scripting

[Oliver Lietz (JIRA)]

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

Oliver Lietz updated SLING-5848:

Description: 
Scripting implementations require a (service) ResourceResolver with very 
limited read rights to read scripts.

Reading can be limited to these paths:
* {{/apps}}
* {{/libs}}
* {{/etc}} (?)

Name for service user: {{scripting}} or {{sling-scripting}} or 
{{sling.scripting}} (?)


  was:
Scripting implementations require a (service) ResourceResolver with very 
limited read rights to read scripts.

Reading can be limited to these paths:
* {{/apps}}
* {{/libs}}
* {{/etc}} (?)

Name for service user: {{scripting}} or {{sling-scripting}} (?)



> Define service user and ACLs for Scripting
> --
>
> Key: SLING-5848
> URL: https://issues.apache.org/jira/browse/SLING-5848
> Project: Sling
>  Issue Type: Task
>  Components: Scripting
>Reporter: Oliver Lietz
>
> Scripting implementations require a (service) ResourceResolver with very 
> limited read rights to read scripts.
> Reading can be limited to these paths:
> * {{/apps}}
> * {{/libs}}
> * {{/etc}} (?)
> Name for service user: {{scripting}} or {{sling-scripting}} or 
> {{sling.scripting}} (?)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (SLING-5848) Define service user and ACLs for Scripting

[Oliver Lietz (JIRA)]

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

Oliver Lietz edited comment on SLING-5848 at 7/15/16 9:30 AM:
--

Can we use a {{.}} to separate the {{sling}} prefix? AEM is already using {{-}} 
in names for better readability, e.g. {{authentication-handler}}.


was (Author: olli):
Can we use a {{.}} to separate the {{sling}} prefix? AEM is already using {{-}} 
in names for better readability, e.g. ({{authentication-handler}}).

> Define service user and ACLs for Scripting
> --
>
> Key: SLING-5848
> URL: https://issues.apache.org/jira/browse/SLING-5848
> Project: Sling
>  Issue Type: Task
>  Components: Scripting
>Reporter: Oliver Lietz
>
> Scripting implementations require a (service) ResourceResolver with very 
> limited read rights to read scripts.
> Reading can be limited to these paths:
> * {{/apps}}
> * {{/libs}}
> * {{/etc}} (?)
> Name for service user: {{scripting}} or {{sling-scripting}} (?)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5848) Define service user and ACLs for Scripting

[Oliver Lietz (JIRA)]

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

Oliver Lietz commented on SLING-5848:
-

Can we use a {{.}} to separate the {{sling}} prefix? AEM is already using {{-}} 
in names for better readability, e.g. ({{authentication-handler}}).

> Define service user and ACLs for Scripting
> --
>
> Key: SLING-5848
> URL: https://issues.apache.org/jira/browse/SLING-5848
> Project: Sling
>  Issue Type: Task
>  Components: Scripting
>Reporter: Oliver Lietz
>
> Scripting implementations require a (service) ResourceResolver with very 
> limited read rights to read scripts.
> Reading can be limited to these paths:
> * {{/apps}}
> * {{/libs}}
> * {{/etc}} (?)
> Name for service user: {{scripting}} or {{sling-scripting}} (?)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5848) Define service user and ACLs for Scripting

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-5848:


If we start creating service users that Sling needs I'm in favor of using a 
{{sling-}} prefix for them.

> Define service user and ACLs for Scripting
> --
>
> Key: SLING-5848
> URL: https://issues.apache.org/jira/browse/SLING-5848
> Project: Sling
>  Issue Type: Task
>  Components: Scripting
>Reporter: Oliver Lietz
>
> Scripting implementations require a (service) ResourceResolver with very 
> limited read rights to read scripts.
> Reading can be limited to these paths:
> * {{/apps}}
> * {{/libs}}
> * {{/etc}} (?)
> Name for service user: {{scripting}} or {{sling-scripting}} (?)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5848) Define service user and ACLs for Scripting

[Oliver Lietz (JIRA)]

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

Oliver Lietz updated SLING-5848:

Description: 
Scripting implementations require a (service) ResourceResolver with very 
limited read rights to read scripts.

Reading can be limited to these paths:
* {{/apps}}
* {{/libs}}
* {{/etc}} (?)

Name for service user: {{scripting}} or {{sling-scripting}} (?)


  was:
Scripting implementations require a (service) ResourceResolver with very 
limited read rights to read scripts.

Reading can be limited to this paths:
* {{/apps}}
* {{/libs}}
* {{/etc}} (?)

Name for service user: {{scripting}} or {{sling-scripting}} (?)



> Define service user and ACLs for Scripting
> --
>
> Key: SLING-5848
> URL: https://issues.apache.org/jira/browse/SLING-5848
> Project: Sling
>  Issue Type: Task
>  Components: Scripting
>Reporter: Oliver Lietz
>
> Scripting implementations require a (service) ResourceResolver with very 
> limited read rights to read scripts.
> Reading can be limited to these paths:
> * {{/apps}}
> * {{/libs}}
> * {{/etc}} (?)
> Name for service user: {{scripting}} or {{sling-scripting}} (?)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5848) Define service user and ACLs for Scripting

[Oliver Lietz (JIRA)]

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

Oliver Lietz updated SLING-5848:

Description: 
Scripting implementations require a (service) ResourceResolver with very 
limited read rights to read scripts.

Reading can be limited to this paths:
* {{/apps}}
* {{/libs}}
* {{/etc}} (?)

Name for service user: {{scripting}} or {{sling-scripting}} (?)


  was:
Scripting implementations require a (service) ResourceResolver with very 
limited read rights to read scripts.

Reading can be limited to this paths:
* {{/apps}}
* {{/libs}}
* {{/etc}} (?)



> Define service user and ACLs for Scripting
> --
>
> Key: SLING-5848
> URL: https://issues.apache.org/jira/browse/SLING-5848
> Project: Sling
>  Issue Type: Task
>  Components: Scripting
>Reporter: Oliver Lietz
>
> Scripting implementations require a (service) ResourceResolver with very 
> limited read rights to read scripts.
> Reading can be limited to this paths:
> * {{/apps}}
> * {{/libs}}
> * {{/etc}} (?)
> Name for service user: {{scripting}} or {{sling-scripting}} (?)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5252) Remove getAdministrativeResourceResolver() from Scripting Core

[Oliver Lietz (JIRA)]

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

Oliver Lietz commented on SLING-5252:
-

Right. See SLING-5848 and add your comments please.

> Remove getAdministrativeResourceResolver() from Scripting Core
> --
>
> Key: SLING-5252
> URL: https://issues.apache.org/jira/browse/SLING-5252
> Project: Sling
>  Issue Type: Sub-task
>  Components: Scripting
>Affects Versions: Scripting Core 2.0.34
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting Core 2.0.40
>
>
> 2 occurrences in {{org.apache.sling.scripting.core.impl.ScriptCacheImpl}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-5848) Define service user and ACLs for Scripting

[Oliver Lietz (JIRA)]

Oliver Lietz created SLING-5848:
---

 Summary: Define service user and ACLs for Scripting
 Key: SLING-5848
 URL: https://issues.apache.org/jira/browse/SLING-5848
 Project: Sling
  Issue Type: Task
  Components: Scripting
Reporter: Oliver Lietz


Scripting implementations require a (service) ResourceResolver with very 
limited read rights to read scripts.

Reading can be limited to this paths:
* {{/apps}}
* {{/libs}}
* {{/etc}} (?)




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5837) Allow ResourceChangeListeners to define glob patterns for resource matching

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-5837:
---

really important pro or contra is only point #1 - once we make an release with 
glob support we never can change it to regex without breaking backward 
compatibility.
the other two points could be optimized in later releases as well.

perhaps we should open a short discussion on the mailing list about #1

> Allow ResourceChangeListeners to define glob patterns for resource matching
> ---
>
> Key: SLING-5837
> URL: https://issues.apache.org/jira/browse/SLING-5837
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Affects Versions: API 2.12.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: API 2.13.0
>
> Attachments: SLING-5837.patch
>
>
> While the previous way to interact with Resource change events through 
> registering {{EventHandler}} sevices allowed defining glob patterns for 
> matching the watched paths, the current state of the 
> {{org.apache.sling.api.resource.observation.ResourceChangeListener}} only 
> allows subscribing to events for concrete paths.
> In order to allow for the same filtering flexibility, 
> {{ResourceChangeListener}} should also accept glob patterns for its 
> {{resource.paths}} configuration property.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5252) Remove getAdministrativeResourceResolver() from Scripting Core

[Radu Cotescu (JIRA)]

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

Radu Cotescu commented on SLING-5252:
-

For the {{ScriptCache}} we can just implement a {{ResourceChangeListener}} that 
would automatically get all the notifications about script changes without the 
need of creating a service user.

> Remove getAdministrativeResourceResolver() from Scripting Core
> --
>
> Key: SLING-5252
> URL: https://issues.apache.org/jira/browse/SLING-5252
> Project: Sling
>  Issue Type: Sub-task
>  Components: Scripting
>Affects Versions: Scripting Core 2.0.34
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting Core 2.0.40
>
>
> 2 occurrences in {{org.apache.sling.scripting.core.impl.ScriptCacheImpl}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5837) Allow ResourceChangeListeners to define glob patterns for resource matching

[Radu Cotescu (JIRA)]

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

Radu Cotescu commented on SLING-5837:
-

Let me try to answer punctually:

# I've thought that glob pattern matching is a subset of the LDAP filter syntax 
used by OSGi {{EventHandlers}} so it felt rather natural to enhance the 
{{ResourceChangeListeners}} filtering support;
# yes, you're right; I guess I was too trigger happy;
# we can definitely optimise that;

Should we cancel the release and address your concerns? What do you propose for 
1?

> Allow ResourceChangeListeners to define glob patterns for resource matching
> ---
>
> Key: SLING-5837
> URL: https://issues.apache.org/jira/browse/SLING-5837
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Affects Versions: API 2.12.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: API 2.13.0
>
> Attachments: SLING-5837.patch
>
>
> While the previous way to interact with Resource change events through 
> registering {{EventHandler}} sevices allowed defining glob patterns for 
> matching the watched paths, the current state of the 
> {{org.apache.sling.api.resource.observation.ResourceChangeListener}} only 
> allows subscribing to events for concrete paths.
> In order to allow for the same filtering flexibility, 
> {{ResourceChangeListener}} should also accept glob patterns for its 
> {{resource.paths}} configuration property.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Sling HApi - Sling Hypermedia API client-side tools version 1.0.0

[Bertrand Delacretaz]

On Wed, Jul 13, 2016 at 5:59 PM, Andrei Dulvac  wrote:
> ...Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1479/ ...

+1 for the release of
SHA1(org.apache.sling.hapi.client/1.0.0/org.apache.sling.hapi.client-1.0.0-source-release.zip
= dcdeaff8660e9caaa8fd7239487f98d14885461e

Checked signatures, build and svn tag.

-Bertrand

Re: Updating our parent pom

[Bertrand Delacretaz]

On Thu, Jul 14, 2016 at 9:43 PM, Carsten Ziegeler  wrote:
> ...looking at our parent pom, we have there some really really old
> dependencies

+1 for the updates that you mentioned, as long as our full build with
integration tests still works after that.

-Bertrand

[jira] [Updated] (SLING-5847) Deadlock in JcrResourceBundleProvider.getResourceBundleInternal when preloading is enabled

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-5847:
---
Description: 
Under particular timing situations the {{reloadBundle}} job and a parallel call 
to {{JcrResourceBundleProvider.getResourceBundleInternal()}} might block each 
other and also all new threads calling 
{{JcrResourceBundleProvider.getResourceBundleInternal()}}.

The thread dump in that situation looks like follows

{code}
"0:0:0:0:0:0:0:1 [1468492407436] GET  HTTP/1.1" - Thread 
t@69826
   java.lang.Thread.State: BLOCKED
at 
org.apache.sling.i18n.impl.JcrResourceBundleProvider.registerResourceBundle(JcrResourceBundleProvider.java:458)
- waiting to lock <19c60354> (a 
org.apache.sling.i18n.impl.JcrResourceBundleProvider) owned by 
"pool-8-thread-5" t@111
at 
org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:437)
at 
org.apache.sling.i18n.impl.JcrResourceBundleProvider.createResourceBundle(JcrResourceBundleProvider.java:480)
at 
org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:435)
at 
org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:185)
at 
org.apache.sling.i18n.impl.I18NFilter$CombinedBundleProvider.getResourceBundle(I18NFilter.java:217)
at 
org.apache.sling.i18n.impl.I18NFilter$BaseI18NSlingHttpServletRequest.getResourceBundle(I18NFilter.java:311)
at 
org.apache.sling.api.wrappers.SlingHttpServletRequestWrapper.getResourceBundle(SlingHttpServletRequestWrapper.java:115)
at 
org.apache.sling.api.wrappers.SlingHttpServletRequestWrapper.getResourceBundle(SlingHttpServletRequestWrapper.java:115)
at 
org.apache.sling.api.wrappers.SlingHttpServletRequestWrapper.getResourceBundle(SlingHttpServletRequestWrapper.java:115)
at 
org.apache.sling.api.wrappers.SlingHttpServletRequestWrapper.getResourceBundle(SlingHttpServletRequestWrapper.java:115)
at 
org.apache.sling.api.wrappers.SlingHttpServletRequestWrapper.getResourceBundle(SlingHttpServletRequestWrapper.java:115)
at ...

"pool-8-thread-5" - Thread t@111
   java.lang.Thread.State: WAITING
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <69b06467> (a 
java.util.concurrent.Semaphore$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
at java.util.concurrent.Semaphore.acquire(Semaphore.java:312)
at 
org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:429)
at 
org.apache.sling.i18n.impl.JcrResourceBundleProvider.createResourceBundle(JcrResourceBundleProvider.java:480)
at 
org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:435)
at 
org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:185)
at 
org.apache.sling.i18n.impl.JcrResourceBundleProvider.reloadBundle(JcrResourceBundleProvider.java:357)
at 
org.apache.sling.i18n.impl.JcrResourceBundleProvider.reloadBundle(JcrResourceBundleProvider.java:352)
at 
org.apache.sling.i18n.impl.JcrResourceBundleProvider$2.run(JcrResourceBundleProvider.java:320)
- locked <19c60354> (a 
org.apache.sling.i18n.impl.JcrResourceBundleProvider)
at 
org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:115)
at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}

Here is what happens internally:

Thread 1 has acquired a semaphore for a specific key and now waits for the lock 
hold by thread 2 in 
{code}
 private void registerResourceBundle(Key key, JcrResourceBundle resourceBundle) 
{
Dictionary serviceProps = new Hashtable();
if (key.baseName != null) {
serviceProps.put("baseName", key.baseName);
}
serviceProps.put("locale", key.locale.toString());
ServiceRegistration serviceReg = 
bundleContext.registerService(ResourceBundle.class.getName(),
resourceBundle, serviceProps);
->

[jira] [Resolved] (SLING-5847) Deadlock in JcrResourceBundleProvider.getResourceBundleInternal when preloading is enabled

[Konrad Windszus (JIRA)]

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

Konrad Windszus resolved SLING-5847.

   Resolution: Fixed
Fix Version/s: i18n 2.4.8

> Deadlock in JcrResourceBundleProvider.getResourceBundleInternal when 
> preloading is enabled
> --
>
> Key: SLING-5847
> URL: https://issues.apache.org/jira/browse/SLING-5847
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: i18n 2.4.4
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Critical
> Fix For: i18n 2.4.8
>
>
> Under particular timing situations the {{reloadBundle}} job and a parallel 
> call to {{JcrResourceBundleProvider.getResourceBundleInternal()}} might block 
> each other and also all new threads calling 
> {{JcrResourceBundleProvider.getResourceBundleInternal()}}.
> The thread dump in that situation looks like follows
> {code}
> "0:0:0:0:0:0:0:1 [1468492407436] GET  HTTP/1.1" - Thread 
> t@69826
>java.lang.Thread.State: BLOCKED
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.registerResourceBundle(JcrResourceBundleProvider.java:458)
>   - waiting to lock <19c60354> (a 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider) owned by 
> "pool-8-thread-5" t@111
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:437)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.createResourceBundle(JcrResourceBundleProvider.java:480)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:435)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:185)
>   at 
> org.apache.sling.i18n.impl.I18NFilter$CombinedBundleProvider.getResourceBundle(I18NFilter.java:217)
>   at 
> org.apache.sling.i18n.impl.I18NFilter$BaseI18NSlingHttpServletRequest.getResourceBundle(I18NFilter.java:311)
>   at 
> org.apache.sling.api.wrappers.SlingHttpServletRequestWrapper.getResourceBundle(SlingHttpServletRequestWrapper.java:115)
>   at 
> org.apache.sling.api.wrappers.SlingHttpServletRequestWrapper.getResourceBundle(SlingHttpServletRequestWrapper.java:115)
>   at 
> org.apache.sling.api.wrappers.SlingHttpServletRequestWrapper.getResourceBundle(SlingHttpServletRequestWrapper.java:115)
>   at 
> org.apache.sling.api.wrappers.SlingHttpServletRequestWrapper.getResourceBundle(SlingHttpServletRequestWrapper.java:115)
>   at 
> org.apache.sling.api.wrappers.SlingHttpServletRequestWrapper.getResourceBundle(SlingHttpServletRequestWrapper.java:115)
>   at ...
> "pool-8-thread-5" - Thread t@111
>java.lang.Thread.State: WAITING
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for <69b06467> (a 
> java.util.concurrent.Semaphore$NonfairSync)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
>   at java.util.concurrent.Semaphore.acquire(Semaphore.java:312)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:429)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.createResourceBundle(JcrResourceBundleProvider.java:480)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:435)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:185)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.reloadBundle(JcrResourceBundleProvider.java:357)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.reloadBundle(JcrResourceBundleProvider.java:352)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider$2.run(JcrResourceBundleProvider.java:320)
>   - locked <19c60354> (a 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider)
>   at 
> org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:115)
>   at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 

[jira] [Commented] (SLING-5847) Deadlock in JcrResourceBundleProvider.getResourceBundleInternal when preloading is enabled

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-5847:


Fixed in [r1752795|https://svn.apache.org/r1752795].

[~cziegeler][~alexander.klimetschek] Could you have a look?

> Deadlock in JcrResourceBundleProvider.getResourceBundleInternal when 
> preloading is enabled
> --
>
> Key: SLING-5847
> URL: https://issues.apache.org/jira/browse/SLING-5847
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: i18n 2.4.4
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Critical
>
> Under particular timing situations the {{reloadBundle}} job and a parallel 
> call to {{JcrResourceBundleProvider.getResourceBundleInternal()}} might block 
> each other and also all new threads calling 
> {{JcrResourceBundleProvider.getResourceBundleInternal()}}.
> The thread dump in that situation looks like follows
> {code}
> "0:0:0:0:0:0:0:1 [1468492407436] GET  HTTP/1.1" - Thread 
> t@69826
>java.lang.Thread.State: BLOCKED
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.registerResourceBundle(JcrResourceBundleProvider.java:458)
>   - waiting to lock <19c60354> (a 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider) owned by 
> "pool-8-thread-5" t@111
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:437)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.createResourceBundle(JcrResourceBundleProvider.java:480)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:435)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:185)
>   at 
> org.apache.sling.i18n.impl.I18NFilter$CombinedBundleProvider.getResourceBundle(I18NFilter.java:217)
>   at 
> org.apache.sling.i18n.impl.I18NFilter$BaseI18NSlingHttpServletRequest.getResourceBundle(I18NFilter.java:311)
>   at 
> org.apache.sling.api.wrappers.SlingHttpServletRequestWrapper.getResourceBundle(SlingHttpServletRequestWrapper.java:115)
>   at 
> org.apache.sling.api.wrappers.SlingHttpServletRequestWrapper.getResourceBundle(SlingHttpServletRequestWrapper.java:115)
>   at 
> org.apache.sling.api.wrappers.SlingHttpServletRequestWrapper.getResourceBundle(SlingHttpServletRequestWrapper.java:115)
>   at 
> org.apache.sling.api.wrappers.SlingHttpServletRequestWrapper.getResourceBundle(SlingHttpServletRequestWrapper.java:115)
>   at 
> org.apache.sling.api.wrappers.SlingHttpServletRequestWrapper.getResourceBundle(SlingHttpServletRequestWrapper.java:115)
>   at ...
> "pool-8-thread-5" - Thread t@111
>java.lang.Thread.State: WAITING
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for <69b06467> (a 
> java.util.concurrent.Semaphore$NonfairSync)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
>   at java.util.concurrent.Semaphore.acquire(Semaphore.java:312)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:429)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.createResourceBundle(JcrResourceBundleProvider.java:480)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:435)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:185)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.reloadBundle(JcrResourceBundleProvider.java:357)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.reloadBundle(JcrResourceBundleProvider.java:352)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider$2.run(JcrResourceBundleProvider.java:320)
>   - locked <19c60354> (a 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider)
>   at 
> org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:115)
>   at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> 

[jira] [Updated] (SLING-5847) Deadlock in JcrResourceBundleProvider.getResourceBundleInternal when preloading is enabled

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-5847:
---
Summary: Deadlock in JcrResourceBundleProvider.getResourceBundleInternal 
when preloading is enabled  (was: Deadlock in 
JcrResourceBundleProvider.getResourceBundleInternal)

> Deadlock in JcrResourceBundleProvider.getResourceBundleInternal when 
> preloading is enabled
> --
>
> Key: SLING-5847
> URL: https://issues.apache.org/jira/browse/SLING-5847
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: i18n 2.4.4
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Critical
>
> Under particular timing situations the {{reloadBundle}} job and a parallel 
> call to {{JcrResourceBundleProvider.getResourceBundleInternal()}} might block 
> each other and also all new threads calling 
> {{JcrResourceBundleProvider.getResourceBundleInternal()}}.
> The thread dump in that situation looks like follows
> {code}
> "0:0:0:0:0:0:0:1 [1468492407436] GET  HTTP/1.1" - Thread 
> t@69826
>java.lang.Thread.State: BLOCKED
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.registerResourceBundle(JcrResourceBundleProvider.java:458)
>   - waiting to lock <19c60354> (a 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider) owned by 
> "pool-8-thread-5" t@111
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:437)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.createResourceBundle(JcrResourceBundleProvider.java:480)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:435)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:185)
>   at 
> org.apache.sling.i18n.impl.I18NFilter$CombinedBundleProvider.getResourceBundle(I18NFilter.java:217)
>   at 
> org.apache.sling.i18n.impl.I18NFilter$BaseI18NSlingHttpServletRequest.getResourceBundle(I18NFilter.java:311)
>   at 
> org.apache.sling.api.wrappers.SlingHttpServletRequestWrapper.getResourceBundle(SlingHttpServletRequestWrapper.java:115)
>   at 
> org.apache.sling.api.wrappers.SlingHttpServletRequestWrapper.getResourceBundle(SlingHttpServletRequestWrapper.java:115)
>   at 
> org.apache.sling.api.wrappers.SlingHttpServletRequestWrapper.getResourceBundle(SlingHttpServletRequestWrapper.java:115)
>   at 
> org.apache.sling.api.wrappers.SlingHttpServletRequestWrapper.getResourceBundle(SlingHttpServletRequestWrapper.java:115)
>   at 
> org.apache.sling.api.wrappers.SlingHttpServletRequestWrapper.getResourceBundle(SlingHttpServletRequestWrapper.java:115)
>   at ...
> "pool-8-thread-5" - Thread t@111
>java.lang.Thread.State: WAITING
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for <69b06467> (a 
> java.util.concurrent.Semaphore$NonfairSync)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
>   at java.util.concurrent.Semaphore.acquire(Semaphore.java:312)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:429)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.createResourceBundle(JcrResourceBundleProvider.java:480)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:435)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:185)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.reloadBundle(JcrResourceBundleProvider.java:357)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.reloadBundle(JcrResourceBundleProvider.java:352)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider$2.run(JcrResourceBundleProvider.java:320)
>   - locked <19c60354> (a 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider)
>   at 
> org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:115)
>   at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> 

[jira] [Updated] (SLING-5847) Deadlock in JcrResourceBundleProvider.getResourceBundleInternal

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-5847:
---
Priority: Critical  (was: Major)

> Deadlock in JcrResourceBundleProvider.getResourceBundleInternal
> ---
>
> Key: SLING-5847
> URL: https://issues.apache.org/jira/browse/SLING-5847
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: i18n 2.4.4
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Critical
>
> Under particular timing situations the {{reloadBundle}} job and a parallel 
> call to {{JcrResourceBundleProvider.getResourceBundleInternal()}} might block 
> each other and also all new threads calling 
> {{JcrResourceBundleProvider.getResourceBundleInternal()}}.
> The thread dump in that situation looks like follows
> {code}
> "0:0:0:0:0:0:0:1 [1468492407436] GET  HTTP/1.1" - Thread 
> t@69826
>java.lang.Thread.State: BLOCKED
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.registerResourceBundle(JcrResourceBundleProvider.java:458)
>   - waiting to lock <19c60354> (a 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider) owned by 
> "pool-8-thread-5" t@111
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:437)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.createResourceBundle(JcrResourceBundleProvider.java:480)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:435)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:185)
>   at 
> org.apache.sling.i18n.impl.I18NFilter$CombinedBundleProvider.getResourceBundle(I18NFilter.java:217)
>   at 
> org.apache.sling.i18n.impl.I18NFilter$BaseI18NSlingHttpServletRequest.getResourceBundle(I18NFilter.java:311)
>   at 
> org.apache.sling.api.wrappers.SlingHttpServletRequestWrapper.getResourceBundle(SlingHttpServletRequestWrapper.java:115)
>   at 
> org.apache.sling.api.wrappers.SlingHttpServletRequestWrapper.getResourceBundle(SlingHttpServletRequestWrapper.java:115)
>   at 
> org.apache.sling.api.wrappers.SlingHttpServletRequestWrapper.getResourceBundle(SlingHttpServletRequestWrapper.java:115)
>   at 
> org.apache.sling.api.wrappers.SlingHttpServletRequestWrapper.getResourceBundle(SlingHttpServletRequestWrapper.java:115)
>   at 
> org.apache.sling.api.wrappers.SlingHttpServletRequestWrapper.getResourceBundle(SlingHttpServletRequestWrapper.java:115)
>   at ...
> "pool-8-thread-5" - Thread t@111
>java.lang.Thread.State: WAITING
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for <69b06467> (a 
> java.util.concurrent.Semaphore$NonfairSync)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
>   at java.util.concurrent.Semaphore.acquire(Semaphore.java:312)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:429)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.createResourceBundle(JcrResourceBundleProvider.java:480)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:435)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:185)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.reloadBundle(JcrResourceBundleProvider.java:357)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.reloadBundle(JcrResourceBundleProvider.java:352)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider$2.run(JcrResourceBundleProvider.java:320)
>   - locked <19c60354> (a 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider)
>   at 
> org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:115)
>   at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> Here is what happens internally:
> Thread 1 has acquired a 

[jira] [Commented] (SLING-5831) Support different thread pools for scheduled tasks

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra commented on SLING-5831:


That would not be an issue with current implementation. As mentioned at [1] 
current blockForAvailableThreads would never say its full. So approach should 
work

But going with multiple schedulers would be more cleaner approach and something 
which does not rely on implementation details

[1] http://markmail.org/thread/dgkzt4nnaqh7fa3b

> Support different thread pools for scheduled tasks
> --
>
> Key: SLING-5831
> URL: https://issues.apache.org/jira/browse/SLING-5831
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Commons Scheduler 2.4.16
>
>
> Right now the scheduler uses a single thread pool. While this thread pool can 
> be configured, it means that all scheduled tasks share this pool. In order to 
> prioratize different tasks over others and avoid blocking important jobs 
> through unimportant once, we could maybe add a configuration property to 
> select a thread pool name.
> If a pool with that name exists, it's used - if not the default is used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-5847) Deadlock in JcrResourceBundleProvider.getResourceBundleInternal

[Konrad Windszus (JIRA)]

Konrad Windszus created SLING-5847:
--

 Summary: Deadlock in 
JcrResourceBundleProvider.getResourceBundleInternal
 Key: SLING-5847
 URL: https://issues.apache.org/jira/browse/SLING-5847
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: i18n 2.4.4
Reporter: Konrad Windszus
Assignee: Konrad Windszus


Under particular timing situations the {{reloadBundle}} job and a parallel call 
to {{JcrResourceBundleProvider.getResourceBundleInternal()}} might block each 
other and also all new threads calling 
{{JcrResourceBundleProvider.getResourceBundleInternal()}}.

The thread dump in that situation looks like follows

{code}
"0:0:0:0:0:0:0:1 [1468492407436] GET  HTTP/1.1" - Thread 
t@69826
   java.lang.Thread.State: BLOCKED
at 
org.apache.sling.i18n.impl.JcrResourceBundleProvider.registerResourceBundle(JcrResourceBundleProvider.java:458)
- waiting to lock <19c60354> (a 
org.apache.sling.i18n.impl.JcrResourceBundleProvider) owned by 
"pool-8-thread-5" t@111
at 
org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:437)
at 
org.apache.sling.i18n.impl.JcrResourceBundleProvider.createResourceBundle(JcrResourceBundleProvider.java:480)
at 
org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:435)
at 
org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:185)
at 
org.apache.sling.i18n.impl.I18NFilter$CombinedBundleProvider.getResourceBundle(I18NFilter.java:217)
at 
org.apache.sling.i18n.impl.I18NFilter$BaseI18NSlingHttpServletRequest.getResourceBundle(I18NFilter.java:311)
at 
org.apache.sling.api.wrappers.SlingHttpServletRequestWrapper.getResourceBundle(SlingHttpServletRequestWrapper.java:115)
at 
org.apache.sling.api.wrappers.SlingHttpServletRequestWrapper.getResourceBundle(SlingHttpServletRequestWrapper.java:115)
at 
org.apache.sling.api.wrappers.SlingHttpServletRequestWrapper.getResourceBundle(SlingHttpServletRequestWrapper.java:115)
at 
org.apache.sling.api.wrappers.SlingHttpServletRequestWrapper.getResourceBundle(SlingHttpServletRequestWrapper.java:115)
at 
org.apache.sling.api.wrappers.SlingHttpServletRequestWrapper.getResourceBundle(SlingHttpServletRequestWrapper.java:115)
at ...

"pool-8-thread-5" - Thread t@111
   java.lang.Thread.State: WAITING
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <69b06467> (a 
java.util.concurrent.Semaphore$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
at java.util.concurrent.Semaphore.acquire(Semaphore.java:312)
at 
org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:429)
at 
org.apache.sling.i18n.impl.JcrResourceBundleProvider.createResourceBundle(JcrResourceBundleProvider.java:480)
at 
org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:435)
at 
org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:185)
at 
org.apache.sling.i18n.impl.JcrResourceBundleProvider.reloadBundle(JcrResourceBundleProvider.java:357)
at 
org.apache.sling.i18n.impl.JcrResourceBundleProvider.reloadBundle(JcrResourceBundleProvider.java:352)
at 
org.apache.sling.i18n.impl.JcrResourceBundleProvider$2.run(JcrResourceBundleProvider.java:320)
- locked <19c60354> (a 
org.apache.sling.i18n.impl.JcrResourceBundleProvider)
at 
org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:115)
at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}

Here is what happens internally:

Thread 1 has acquired a semaphore for a specific key and now waits for the lock 
hold by thread 2 in 
{code}
 private void registerResourceBundle(Key key, JcrResourceBundle resourceBundle) 
{
Dictionary serviceProps = new Hashtable();
if (key.baseName != null) {
serviceProps.put("baseName",