[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors
[
https://issues.apache.org/jira/browse/SLING-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15606631#comment-15606631
]
Justin Edelson commented on SLING-6187:
---
I'm not sure what you mean by "already handled". Unless a SlingPostProcessor
removes the parameter with the @suffix, a property with that name is happily
created. Which _could_ be the desired behavior -- the Post servlet has no way
of knowing unless the client tells it.
Yes, I agree that this change would require existing clients to change *if*
they want to make such an assertion.
> Provide a way for a POST request to assert a set of required
> SlingPostProcessors
>
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
>
> I would like to add support for a new "special" request parameter understood
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter
> may contain a comma-delimited list of names (see below) which *must* be
> available *at the time the request is processed* in order for the request to
> be handled. Whether or not those processors _do_ anything or whether the
> request succeeds or not is a separate question; this is just a preflight
> check if you will.
> If any of the required SlingPostProcessors are not available, the request
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service
> registration property {{postProcessor.name}} and default to the simple name
> of the SlingPostProcessor's implementation class if that property is not
> defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors
[
https://issues.apache.org/jira/browse/SLING-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15606603#comment-15606603
]
Alexander Klimetschek commented on SLING-6187:
--
regarding 2): the @suffix is in a separate request parameter and this is
already handled IIRC.
The name of the post processor is a server implementation detail and with a new
request parameter existing clients would have to be changed. Maybe there is a
other way to ensure it...
> Provide a way for a POST request to assert a set of required
> SlingPostProcessors
>
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
>
> I would like to add support for a new "special" request parameter understood
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter
> may contain a comma-delimited list of names (see below) which *must* be
> available *at the time the request is processed* in order for the request to
> be handled. Whether or not those processors _do_ anything or whether the
> request succeeds or not is a separate question; this is just a preflight
> check if you will.
> If any of the required SlingPostProcessors are not available, the request
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service
> registration property {{postProcessor.name}} and default to the simple name
> of the SlingPostProcessor's implementation class if that property is not
> defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors
[
https://issues.apache.org/jira/browse/SLING-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15606583#comment-15606583
]
Justin Edelson commented on SLING-6187:
---
[~alexander.klimetschek] There's two problems I see with the approach you are
describing (if I am in fact understanding it):
1) There's nothing that requires that SlingPostProcessors operate on @suffix
parameters, so merely checking that the modification list doesn't contain any
@suffix parameters after the operation is complete doesn't guarantee that a
particular SlingPostProcessor was present.
2) It is totally legal for a JCR property name to contain an @ sign, so
checking that the list of modifications for the @ sign is not valid.
> Provide a way for a POST request to assert a set of required
> SlingPostProcessors
>
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
>
> I would like to add support for a new "special" request parameter understood
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter
> may contain a comma-delimited list of names (see below) which *must* be
> available *at the time the request is processed* in order for the request to
> be handled. Whether or not those processors _do_ anything or whether the
> request succeeds or not is a separate question; this is just a preflight
> check if you will.
> If any of the required SlingPostProcessors are not available, the request
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service
> registration property {{postProcessor.name}} and default to the simple name
> of the SlingPostProcessor's implementation class if that property is not
> defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors
[
https://issues.apache.org/jira/browse/SLING-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15606487#comment-15606487
]
Alexander Klimetschek commented on SLING-6187:
--
Having clients to specify that doesn't feel quite right - it should be a server
side validation.
What if the sling post servlet understands the @suffix (in this case
@Encrypted) and detects if no post processor has handled it?
> Provide a way for a POST request to assert a set of required
> SlingPostProcessors
>
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
>
> I would like to add support for a new "special" request parameter understood
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter
> may contain a comma-delimited list of names (see below) which *must* be
> available *at the time the request is processed* in order for the request to
> be handled. Whether or not those processors _do_ anything or whether the
> request succeeds or not is a separate question; this is just a preflight
> check if you will.
> If any of the required SlingPostProcessors are not available, the request
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service
> registration property {{postProcessor.name}} and default to the simple name
> of the SlingPostProcessor's implementation class if that property is not
> defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-6183) Sling Models - Provide a mechanism to export model objects via servlets
[
https://issues.apache.org/jira/browse/SLING-6183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15606449#comment-15606449
]
dan mcweeney commented on SLING-6183:
-
So can you explain what happens when one model points at another model? For
example, I have an Order Model what uses:
{code}
@Exporter(name = 'jackson', extension = 'json')
{code}
which has a method:
{code}
@JsonProperty(“items”)
public List getItems();
{code}
The resources returned by the getItems method have a resourceType which is
serviced by a Sling Model. When the Order model gets exported what is in that
list?
If it's an array of Exported Models what named exporter does it use, the one
defined with the Order or the one defined with the "Item"?
Another slight variation what if it returns a List where Item is an
object type managed by Sling Models, which also has an @Exporter annotation?
Also I wonder if it would be better to support a Media type instead of just an
extension. I realize content negotiation isn't really fully baked into Sling
but I can see where you might want to be able to support a plain
application/json export and also a application/vnd.org.sling.models.item+json.
> Sling Models - Provide a mechanism to export model objects via servlets
> ---
>
> Key: SLING-6183
> URL: https://issues.apache.org/jira/browse/SLING-6183
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
>Reporter: Justin Edelson
> Fix For: Sling Models API 1.3.0, Sling Models Impl 1.3.0
>
> Attachments: SLING-6183.patch
>
>
> I would like to introduce a new feature to Sling Models named Exporters.
> Exporters allow for a model class to be exported into a specific Java object
> type in a automated fashion. The simplest example is to support String
> serialization, although different Exporters may support whatever target
> classes they see fit.
> Exporters are implemented through an SPI. This initial contribution includes
> an exporter using the Jackson library which supports both {{String}} and
> {{Map}} exports.
> Interfacing with the registered Exporters is done through three new methods
> on the {{ModelFactory}} interface:
> * {{exportMode}}
> * {{exportModelForResource}}
> * {{exportModelForRequest}}
> In addition, using these functionality, model objects can have
> automatically-registered servlets which export the model (from either the
> request or the request's resource) as a {{String}} and then serve that
> {{String}} to the client.
> Registering these servlets is done through a new annotation named
> {{@Exporter}}
> For example, you might add this annotation to a Model class
> {{@Exporter(name = 'jackson', extension = 'json')}}
> This will register a servlet for the model's resource type with the extension
> `json` and a selector of `model` (by default, the {{@Exporter}} annotation
> can also define a different selector).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-6185) I18NHttpServletRequest#getLocale should never return null
[
https://issues.apache.org/jira/browse/SLING-6185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved SLING-6185.
-
Resolution: Fixed
Thanks for your patch, it's applied
> I18NHttpServletRequest#getLocale should never return null
> -
>
> Key: SLING-6185
> URL: https://issues.apache.org/jira/browse/SLING-6185
> Project: Sling
> Issue Type: Bug
> Components: i18n
>Affects Versions: i18n 2.5.4
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: i18n 2.5.6
>
> Attachments: SLING-6185.patch
>
>
> According to the JEE API, the {{ServletRequest#getLocale}} should never
> return {{null}}, the ultimate fallback being the default locale for the
> server.
> However, the Sling wrapper
> {{o.a.s.i.i.I18NFilter.I18NHttpServletRequest#getLocale}} _may_ return
> {{null}} in case:
> 1. the localeResolver does return {{empty list}} (allowed as per API)
> 2. {{The bundleProvider#getDefaultLocale}} returns {{null}} (not clear if
> allowed or not)
> With the current Sling code, 2. can occurs at
> https://github.com/apache/sling/blob/trunk/bundles/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/I18NFilter.java#L198
> [0]
> https://github.com/apache/sling/blob/trunk/bundles/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/I18NFilter.java#L280-L283
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-6185) I18NHttpServletRequest#getLocale should never return null
[
https://issues.apache.org/jira/browse/SLING-6185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated SLING-6185:
Fix Version/s: i18n 2.5.6
> I18NHttpServletRequest#getLocale should never return null
> -
>
> Key: SLING-6185
> URL: https://issues.apache.org/jira/browse/SLING-6185
> Project: Sling
> Issue Type: Bug
> Components: i18n
>Affects Versions: i18n 2.5.4
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: i18n 2.5.6
>
> Attachments: SLING-6185.patch
>
>
> According to the JEE API, the {{ServletRequest#getLocale}} should never
> return {{null}}, the ultimate fallback being the default locale for the
> server.
> However, the Sling wrapper
> {{o.a.s.i.i.I18NFilter.I18NHttpServletRequest#getLocale}} _may_ return
> {{null}} in case:
> 1. the localeResolver does return {{empty list}} (allowed as per API)
> 2. {{The bundleProvider#getDefaultLocale}} returns {{null}} (not clear if
> allowed or not)
> With the current Sling code, 2. can occurs at
> https://github.com/apache/sling/blob/trunk/bundles/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/I18NFilter.java#L198
> [0]
> https://github.com/apache/sling/blob/trunk/bundles/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/I18NFilter.java#L280-L283
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors
[
https://issues.apache.org/jira/browse/SLING-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15606111#comment-15606111
]
Rob Ryan commented on SLING-6187:
-
Thanks, sorry my confusion.
> Provide a way for a POST request to assert a set of required
> SlingPostProcessors
>
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
>
> I would like to add support for a new "special" request parameter understood
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter
> may contain a comma-delimited list of names (see below) which *must* be
> available *at the time the request is processed* in order for the request to
> be handled. Whether or not those processors _do_ anything or whether the
> request succeeds or not is a separate question; this is just a preflight
> check if you will.
> If any of the required SlingPostProcessors are not available, the request
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service
> registration property {{postProcessor.name}} and default to the simple name
> of the SlingPostProcessor's implementation class if that property is not
> defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors
[
https://issues.apache.org/jira/browse/SLING-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15606101#comment-15606101
]
Justin Edelson edited comment on SLING-6187 at 10/25/16 6:37 PM:
-
[~rr...@adobe.com] perhaps the description isn't clear -- the "list" is
populated as part of the request. The thesis being that only the party sending
the request knows what is necessary to handle it.
IIOW, this is about allowing the request to make assertions as to how it needs
to be handled (which is similar to the extant {{:operation}} parameter).
was (Author: justinedelson):
[~rr...@adobe.com] perhaps the description isn't clear -- the "list" is
populated as part of the request. The thesis being that only the party sending
the request knows what is necessary to handle it.
> Provide a way for a POST request to assert a set of required
> SlingPostProcessors
>
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
>
> I would like to add support for a new "special" request parameter understood
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter
> may contain a comma-delimited list of names (see below) which *must* be
> available *at the time the request is processed* in order for the request to
> be handled. Whether or not those processors _do_ anything or whether the
> request succeeds or not is a separate question; this is just a preflight
> check if you will.
> If any of the required SlingPostProcessors are not available, the request
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service
> registration property {{postProcessor.name}} and default to the simple name
> of the SlingPostProcessor's implementation class if that property is not
> defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors
[
https://issues.apache.org/jira/browse/SLING-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15606101#comment-15606101
]
Justin Edelson edited comment on SLING-6187 at 10/25/16 6:36 PM:
-
[~rr...@adobe.com] perhaps the description isn't clear -- the "list" is
populated as part of the request. The thesis being that only the party sending
the request knows what is necessary to handle it.
was (Author: justinedelson):
[~rr...@adobe.com] perhaps the description isn't clear -- the "list" is
populated as part of the request.
> Provide a way for a POST request to assert a set of required
> SlingPostProcessors
>
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
>
> I would like to add support for a new "special" request parameter understood
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter
> may contain a comma-delimited list of names (see below) which *must* be
> available *at the time the request is processed* in order for the request to
> be handled. Whether or not those processors _do_ anything or whether the
> request succeeds or not is a separate question; this is just a preflight
> check if you will.
> If any of the required SlingPostProcessors are not available, the request
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service
> registration property {{postProcessor.name}} and default to the simple name
> of the SlingPostProcessor's implementation class if that property is not
> defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors
[
https://issues.apache.org/jira/browse/SLING-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15606101#comment-15606101
]
Justin Edelson commented on SLING-6187:
---
[~rr...@adobe.com] perhaps the description isn't clear -- the "list" is
populated as part of the request.
> Provide a way for a POST request to assert a set of required
> SlingPostProcessors
>
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
>
> I would like to add support for a new "special" parameter understood by the
> Sling Post Servlet named {{:requiredPostProcessors}}. This parameter may
> contain a comma-delimited list of names (see below) which *must* be available
> *at the time the request is processed* in order for the request to be
> handled. Whether or not those processors _do_ anything or whether the request
> succeeds or not is a separate question; this is just a preflight check if you
> will.
> If any of the required SlingPostProcessors are not available, the request
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service
> registration property {{postProcessor.name}} and default to the simple name
> of the SlingPostProcessor's implementation class if that property is not
> defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors
[
https://issues.apache.org/jira/browse/SLING-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson updated SLING-6187:
--
Description:
I would like to add support for a new "special" request parameter understood by
the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter may
contain a comma-delimited list of names (see below) which *must* be available
*at the time the request is processed* in order for the request to be handled.
Whether or not those processors _do_ anything or whether the request succeeds
or not is a separate question; this is just a preflight check if you will.
If any of the required SlingPostProcessors are not available, the request will
fail with a 501 error.
The name of a SlingPostProcessor will be defined by a newly defined service
registration property {{postProcessor.name}} and default to the simple name of
the SlingPostProcessor's implementation class if that property is not defined.
was:
I would like to add support for a new "special" parameter understood by the
Sling Post Servlet named {{:requiredPostProcessors}}. This parameter may
contain a comma-delimited list of names (see below) which *must* be available
*at the time the request is processed* in order for the request to be handled.
Whether or not those processors _do_ anything or whether the request succeeds
or not is a separate question; this is just a preflight check if you will.
If any of the required SlingPostProcessors are not available, the request will
fail with a 501 error.
The name of a SlingPostProcessor will be defined by a newly defined service
registration property {{postProcessor.name}} and default to the simple name of
the SlingPostProcessor's implementation class if that property is not defined.
> Provide a way for a POST request to assert a set of required
> SlingPostProcessors
>
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
>
> I would like to add support for a new "special" request parameter understood
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter
> may contain a comma-delimited list of names (see below) which *must* be
> available *at the time the request is processed* in order for the request to
> be handled. Whether or not those processors _do_ anything or whether the
> request succeeds or not is a separate question; this is just a preflight
> check if you will.
> If any of the required SlingPostProcessors are not available, the request
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service
> registration property {{postProcessor.name}} and default to the simple name
> of the SlingPostProcessor's implementation class if that property is not
> defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors
[
https://issues.apache.org/jira/browse/SLING-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15606079#comment-15606079
]
Rob Ryan commented on SLING-6187:
-
A single monolithic list is probably not the best thing here, maybe follow the
service user style with 'amended' configurations to allow separate modules to
specify required post processors.
> Provide a way for a POST request to assert a set of required
> SlingPostProcessors
>
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
>
> I would like to add support for a new "special" parameter understood by the
> Sling Post Servlet named {{:requiredPostProcessors}}. This parameter may
> contain a comma-delimited list of names (see below) which *must* be available
> *at the time the request is processed* in order for the request to be
> handled. Whether or not those processors _do_ anything or whether the request
> succeeds or not is a separate question; this is just a preflight check if you
> will.
> If any of the required SlingPostProcessors are not available, the request
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service
> registration property {{postProcessor.name}} and default to the simple name
> of the SlingPostProcessor's implementation class if that property is not
> defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors
Justin Edelson created SLING-6187:
-
Summary: Provide a way for a POST request to assert a set of
required SlingPostProcessors
Key: SLING-6187
URL: https://issues.apache.org/jira/browse/SLING-6187
Project: Sling
Issue Type: Improvement
Components: Servlets
Reporter: Justin Edelson
Assignee: Justin Edelson
Fix For: Servlets Post 2.3.16
I would like to add support for a new "special" parameter understood by the
Sling Post Servlet named {{:requiredPostProcessors}}. This parameter may
contain a comma-delimited list of names (see below) which *must* be available
*at the time the request is processed* in order for the request to be handled.
Whether or not those processors _do_ anything or whether the request succeeds
or not is a separate question; this is just a preflight check if you will.
If any of the required SlingPostProcessors are not available, the request will
fail with a 501 error.
The name of a SlingPostProcessor will be defined by a newly defined service
registration property {{postProcessor.name}} and default to the simple name of
the SlingPostProcessor's implementation class if that property is not defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (SLING-5542) BundleUpdateTask should log problems on loglevel WARN
[ https://issues.apache.org/jira/browse/SLING-5542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-5542. --- > BundleUpdateTask should log problems on loglevel WARN > - > > Key: SLING-5542 > URL: https://issues.apache.org/jira/browse/SLING-5542 > Project: Sling > Issue Type: Improvement > Components: Installer >Affects Versions: Installer Core 3.6.4 >Reporter: Jörg Hoh >Assignee: Carsten Ziegeler > Fix For: Installer Core 3.7.0 > > Attachments: SLING-5542.patch > > > A failing UpdateTask should log the exception on loglevel WARN instead of > just INFO. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4867) EntityResourceList should be thread-safe
[
https://issues.apache.org/jira/browse/SLING-4867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler closed SLING-4867.
---
> EntityResourceList should be thread-safe
>
>
> Key: SLING-4867
> URL: https://issues.apache.org/jira/browse/SLING-4867
> Project: Sling
> Issue Type: Bug
> Components: Installer
>Affects Versions: Installer Core 3.6.6
>Reporter: Julian Sedding
>Assignee: Carsten Ziegeler
> Fix For: Installer Core 3.7.0
>
>
> There was a Jenkins test failure\[0\] due to the following exception. This
> looks like {{EntityResourceList}} should be thread-safe.
> [~cziegeler], I took the liberty to assign the issue to you. Hope that's ok.
> {noformat}
> Exception in thread "OsgiInstallerImpl"
> java.util.ConcurrentModificationException
> at java.util.ArrayList.sort(ArrayList.java:1456)
> at java.util.Collections.sort(Collections.java:141)
> at
> org.apache.sling.installer.core.impl.EntityResourceList.getActiveResource(EntityResourceList.java:125)
> at
> org.apache.sling.installer.factories.configuration.impl.ConfigTaskCreator.createTask(ConfigTaskCreator.java:71)
> at
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.getTask(OsgiInstallerImpl.java:632)
> at
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.computeTasks(OsgiInstallerImpl.java:612)
> at
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.run(OsgiInstallerImpl.java:262)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> \[0\] https://builds.apache.org/job/sling-trunk-1.8/1292/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (SLING-5014) Installer blacklist, to avoid reinstalling older bundles
[ https://issues.apache.org/jira/browse/SLING-5014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-5014. --- > Installer blacklist, to avoid reinstalling older bundles > > > Key: SLING-5014 > URL: https://issues.apache.org/jira/browse/SLING-5014 > Project: Sling > Issue Type: Bug > Components: Installer >Affects Versions: Installer Core 3.6.6 >Reporter: Dominik Süß >Assignee: Carsten Ziegeler > Fix For: Installer Core 3.7.0 > > Attachments: SLING-5014-1.diff > > > In case a bundle has mutliple install candiates only the highest version > (with the highest priorty for the same versions) wins. An uninstall directive > in the Sling bootstrap.txt file or provisioning model uninstalls this > version. The way the OSGi install behavior is defined this lets the next > artifact in the priority queue to get active and consequently only leads to > downgrade to the next in the queue. > As the uninstall directive declares a range that should be uninstalled the > expectation is that after a startup with such an uninstall directive none of > the declared versions are in an installed state. In consequence the OSGi > installer must save this metainformation in the state that prevents a > downgrade to a version that is part of an active uninstall directive. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4894) Allow failed package install to retry later on
[ https://issues.apache.org/jira/browse/SLING-4894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-4894. --- > Allow failed package install to retry later on > -- > > Key: SLING-4894 > URL: https://issues.apache.org/jira/browse/SLING-4894 > Project: Sling > Issue Type: Improvement > Components: Installer >Affects Versions: Installer Core 3.6.8 >Reporter: Timothee Maret > Fix For: Installer Core 3.7.0 > > > Currently, when an artifact can't be installed for any reason, the > OsgiInstaller will set the IGNORED state. The installer does not retry to > install artifacts with the IGNORED state. > This issue tracks allowing packages installations to be tried later (for > instance on restart) when they fail. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-5586) Installer properties should be removed from dictionary
[ https://issues.apache.org/jira/browse/SLING-5586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-5586. --- > Installer properties should be removed from dictionary > -- > > Key: SLING-5586 > URL: https://issues.apache.org/jira/browse/SLING-5586 > Project: Sling > Issue Type: Improvement > Components: Installer >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Installer Core 3.7.0 > > > The installer uses some private properties like the resource hint, or the > installer hint. These properties should be removed from the dictionary in > order to not store them in config admin -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[VOTE RESULT] Release Apache Sling Installer Core 3.7.0
The vote passed with three binding +1 votes and one non binding +1 vote Thanks Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Commented] (SLING-6165) Expose a service for Sling Scripting that provides request-scoped Resource Resolvers for scripting dependencies
[
https://issues.apache.org/jira/browse/SLING-6165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605824#comment-15605824
]
Alexander Klimetschek commented on SLING-6165:
--
SLING-5277 has a
[patch|https://issues.apache.org/jira/secure/attachment/12835048/SLING-5277-new.patch]
that might help.
Make sure to test it with a servlet that doesn't do resource type lookups (and
no filter that does so).
> Expose a service for Sling Scripting that provides request-scoped Resource
> Resolvers for scripting dependencies
> ---
>
> Key: SLING-6165
> URL: https://issues.apache.org/jira/browse/SLING-6165
> Project: Sling
> Issue Type: New Feature
> Components: Scripting
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting Core 2.0.42, Scripting API 2.1.10
>
>
> A new Sling Scripting service ({{ScriptingResourceResolverFactory}}) should
> be implemented in order to provide access to request-based
> {{ResourceResolvers}} for solving script dependencies.
> The following two methods should be available:
> {noformat}
> /**
> * Provides a request-scoped {@link 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
> {@code ResourceResolver} should not be closed by consumers (calling
> * {@link ResourceResolver#close} doesn't do anything), since this service
> will handle the closing operation automatically. The
> * {@code ResourceResolver} will be shared between scripting dependencies
> that render parts of the response for the same request.
> */
> ResourceResolver getRequestScopedResourceResolver()
> /**
> * Provides a {@link ResourceResolver} with only read access to the search
> paths. Once you're done processing {@link Resource}s with this
> * {@code ResourceResolver} make sure to close it.
> */
> ResourceResolver getResourceResolver()
> {noformat}
> [sling-dev email
> thread|https://lists.apache.org/thread.html/db2a78249baf2d6234a4549a5aff8b5474256add9829f86ac78d1c56@%3Cdev.sling.apache.org%3E]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-6165) Expose a service for Sling Scripting that provides request-scoped Resource Resolvers for scripting dependencies
[
https://issues.apache.org/jira/browse/SLING-6165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605809#comment-15605809
]
Radu Cotescu commented on SLING-6165:
-
Yeah, [~olli] also suggested we do a lazy init. I'll implement this rather
trivial change tomorrow and test it with the HTL modules to see how it performs.
> Expose a service for Sling Scripting that provides request-scoped Resource
> Resolvers for scripting dependencies
> ---
>
> Key: SLING-6165
> URL: https://issues.apache.org/jira/browse/SLING-6165
> Project: Sling
> Issue Type: New Feature
> Components: Scripting
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting Core 2.0.42, Scripting API 2.1.10
>
>
> A new Sling Scripting service ({{ScriptingResourceResolverFactory}}) should
> be implemented in order to provide access to request-based
> {{ResourceResolvers}} for solving script dependencies.
> The following two methods should be available:
> {noformat}
> /**
> * Provides a request-scoped {@link 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
> {@code ResourceResolver} should not be closed by consumers (calling
> * {@link ResourceResolver#close} doesn't do anything), since this service
> will handle the closing operation automatically. The
> * {@code ResourceResolver} will be shared between scripting dependencies
> that render parts of the response for the same request.
> */
> ResourceResolver getRequestScopedResourceResolver()
> /**
> * Provides a {@link ResourceResolver} with only read access to the search
> paths. Once you're done processing {@link Resource}s with this
> * {@code ResourceResolver} make sure to close it.
> */
> ResourceResolver getResourceResolver()
> {noformat}
> [sling-dev email
> thread|https://lists.apache.org/thread.html/db2a78249baf2d6234a4549a5aff8b5474256add9829f86ac78d1c56@%3Cdev.sling.apache.org%3E]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SLING-5277) Performance: per thread script resolver (admin session) is always created even if cache is hit
[ https://issues.apache.org/jira/browse/SLING-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605790#comment-15605790 ] Alexander Klimetschek edited comment on SLING-5277 at 10/25/16 4:39 PM: AFAICS, SLING-6165 just moves this to a different place, but has the same problem that the admin/service resolver is created for each request (upon SlingRequestEvent.EventType.EVENT_INIT it does rrf.getServiceResourceResolver(null) in ScriptingResourceResolverFactoryImpl), even if it is never accessed, because nothing asks for resolving a resource type etc. Note that this issue is not about admin vs. service user but about performance of creating this extra session, which adds cost to every single sling request, even if not used at all. was (Author: alexander.klimetschek): AFAICS, SLING-6165 just moves this to a different place, but has the same problem that the admin resolver is created for each request (upon SlingRequestEvent.EventType.EVENT_INIT it does rrf.getServiceResourceResolver(null) in ScriptingResourceResolverFactoryImpl), even if it is never accessed, because nothing asks for resolving a resource type etc. > Performance: per thread script resolver (admin session) is always created > even if cache is hit > -- > > Key: SLING-5277 > URL: https://issues.apache.org/jira/browse/SLING-5277 > Project: Sling > Issue Type: Bug > Components: Servlets >Reporter: Alexander Klimetschek > Attachments: SLING-5277-new.patch, SLING-5277.patch > > > Since SLING-3441, for every request, a new admin / privileged session is > [created in the > SlingServletResolver|https://github.com/apache/sling/blob/trunk/bundles/servlets/resolver/src/main/java/org/apache/sling/servlets/resolver/internal/SlingServletResolver.java#L532]. > It is created before the script/servlet cache is checked, so in most cases > when the cache is hit it is never used, but the cost of creating an extra > session (which can vary, especially with concurrent traffic) is incurred. > The per thread script resolver can be created lazily instead of directly in > the event to avoid this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-6165) Expose a service for Sling Scripting that provides request-scoped Resource Resolvers for scripting dependencies
[
https://issues.apache.org/jira/browse/SLING-6165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605795#comment-15605795
]
Alexander Klimetschek commented on SLING-6165:
--
Would be great if the ScriptingResourceResolverFactory could fix the SLING-5277
performance issue - to only create the extra JCR session (service user /
service resolver) if it is actually used, and not for every single request.
> Expose a service for Sling Scripting that provides request-scoped Resource
> Resolvers for scripting dependencies
> ---
>
> Key: SLING-6165
> URL: https://issues.apache.org/jira/browse/SLING-6165
> Project: Sling
> Issue Type: New Feature
> Components: Scripting
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting Core 2.0.42, Scripting API 2.1.10
>
>
> A new Sling Scripting service ({{ScriptingResourceResolverFactory}}) should
> be implemented in order to provide access to request-based
> {{ResourceResolvers}} for solving script dependencies.
> The following two methods should be available:
> {noformat}
> /**
> * Provides a request-scoped {@link 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
> {@code ResourceResolver} should not be closed by consumers (calling
> * {@link ResourceResolver#close} doesn't do anything), since this service
> will handle the closing operation automatically. The
> * {@code ResourceResolver} will be shared between scripting dependencies
> that render parts of the response for the same request.
> */
> ResourceResolver getRequestScopedResourceResolver()
> /**
> * Provides a {@link ResourceResolver} with only read access to the search
> paths. Once you're done processing {@link Resource}s with this
> * {@code ResourceResolver} make sure to close it.
> */
> ResourceResolver getResourceResolver()
> {noformat}
> [sling-dev email
> thread|https://lists.apache.org/thread.html/db2a78249baf2d6234a4549a5aff8b5474256add9829f86ac78d1c56@%3Cdev.sling.apache.org%3E]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5277) Performance: per thread script resolver (admin session) is always created even if cache is hit
[ https://issues.apache.org/jira/browse/SLING-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605790#comment-15605790 ] Alexander Klimetschek commented on SLING-5277: -- AFAICS, SLING-6165 just moves this to a different place, but has the same problem that the admin resolver is created for each request (upon SlingRequestEvent.EventType.EVENT_INIT it does rrf.getServiceResourceResolver(null) in ScriptingResourceResolverFactoryImpl), even if it is never accessed, because nothing asks for resolving a resource type etc. > Performance: per thread script resolver (admin session) is always created > even if cache is hit > -- > > Key: SLING-5277 > URL: https://issues.apache.org/jira/browse/SLING-5277 > Project: Sling > Issue Type: Bug > Components: Servlets >Reporter: Alexander Klimetschek > Attachments: SLING-5277-new.patch, SLING-5277.patch > > > Since SLING-3441, for every request, a new admin / privileged session is > [created in the > SlingServletResolver|https://github.com/apache/sling/blob/trunk/bundles/servlets/resolver/src/main/java/org/apache/sling/servlets/resolver/internal/SlingServletResolver.java#L532]. > It is created before the script/servlet cache is checked, so in most cases > when the cache is hit it is never used, but the cost of creating an extra > session (which can vary, especially with concurrent traffic) is incurred. > The per thread script resolver can be created lazily instead of directly in > the event to avoid this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5277) Performance: per thread script resolver (admin session) is always created even if cache is hit
[ https://issues.apache.org/jira/browse/SLING-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605714#comment-15605714 ] Radu Cotescu commented on SLING-5277: - I guess so. But we also haven't reached consensus in SLING-6165. > Performance: per thread script resolver (admin session) is always created > even if cache is hit > -- > > Key: SLING-5277 > URL: https://issues.apache.org/jira/browse/SLING-5277 > Project: Sling > Issue Type: Bug > Components: Servlets >Reporter: Alexander Klimetschek > Attachments: SLING-5277-new.patch, SLING-5277.patch > > > Since SLING-3441, for every request, a new admin / privileged session is > [created in the > SlingServletResolver|https://github.com/apache/sling/blob/trunk/bundles/servlets/resolver/src/main/java/org/apache/sling/servlets/resolver/internal/SlingServletResolver.java#L532]. > It is created before the script/servlet cache is checked, so in most cases > when the cache is hit it is never used, but the cost of creating an extra > session (which can vary, especially with concurrent traffic) is incurred. > The per thread script resolver can be created lazily instead of directly in > the event to avoid this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-920) Sling Jenkins setup
[ https://issues.apache.org/jira/browse/SLING-920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605620#comment-15605620 ] Robert Munteanu commented on SLING-920: --- Updated the sling-ide build to send failure emails to comm...@sling.apache.org, there are pretty of emails going that way now, one more is not going to hurt. Also enabled the setting to send a separate email to individuals that broke the build. > Sling Jenkins setup > --- > > Key: SLING-920 > URL: https://issues.apache.org/jira/browse/SLING-920 > Project: Sling > Issue Type: Task > Components: Testing >Reporter: Bertrand Delacretaz > > Use this issue to record changes to the Jenkins setup at > https://builds.apache.org/view/S-Z/view/Sling/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-6186) Add support for checking code coverage with jacoco
[
https://issues.apache.org/jira/browse/SLING-6186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-6186.
-
Resolution: Fixed
Fixed in [r1766545|https://svn.apache.org/r1766545].
> Add support for checking code coverage with jacoco
> --
>
> Key: SLING-6186
> URL: https://issues.apache.org/jira/browse/SLING-6186
> Project: Sling
> Issue Type: Improvement
> Components: Scripting
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting HTL JS Use Provider 1.0.18, Scripting HTL
> Engine 1.0.28, Scripting HTL Compiler 1.0.4, Scripting HTL Java Compiler
> 1.0.6, Scripting HTL Models Use Provider 1.0.6
>
>
> The HTL bundles pom files should provide the setup for the
> {{jacoco-maven-plugin}} in order to be able to generate code coverage reports.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-6186) Add support for checking code coverage with jacoco
Radu Cotescu created SLING-6186:
---
Summary: Add support for checking code coverage with jacoco
Key: SLING-6186
URL: https://issues.apache.org/jira/browse/SLING-6186
Project: Sling
Issue Type: Improvement
Components: Scripting
Reporter: Radu Cotescu
Assignee: Radu Cotescu
Fix For: Scripting HTL Engine 1.0.28, Scripting HTL Compiler
1.0.4, Scripting HTL Java Compiler 1.0.6, Scripting HTL Models Use Provider
1.0.6, Scripting HTL JS Use Provider 1.0.18
The HTL bundles pom files should provide the setup for the
{{jacoco-maven-plugin}} in order to be able to generate code coverage reports.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SLING-6185) I18NHttpServletRequest#getLocale should never return null
[
https://issues.apache.org/jira/browse/SLING-6185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605107#comment-15605107
]
Timothee Maret edited comment on SLING-6185 at 10/25/16 12:16 PM:
--
Attaching svn compatible patch for alternative solution, patch is otherwise
available at
https://github.com/tmaret/sling/commit/74e6e3a2bd21469241cf39fbca9913b051b82312.patch
[~cziegeler] I think it'd make sense for you to quickly look at it as it seems
you are the main contributor here.
was (Author: marett):
Attaching svn compatible patch for alternative solution, patch is otherwise
available at
https://github.com/tmaret/sling/commit/74e6e3a2bd21469241cf39fbca9913b051b82312.patch
> I18NHttpServletRequest#getLocale should never return null
> -
>
> Key: SLING-6185
> URL: https://issues.apache.org/jira/browse/SLING-6185
> Project: Sling
> Issue Type: Bug
> Components: i18n
>Affects Versions: i18n 2.5.4
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Attachments: SLING-6185.patch
>
>
> According to the JEE API, the {{ServletRequest#getLocale}} should never
> return {{null}}, the ultimate fallback being the default locale for the
> server.
> However, the Sling wrapper
> {{o.a.s.i.i.I18NFilter.I18NHttpServletRequest#getLocale}} _may_ return
> {{null}} in case:
> 1. the localeResolver does return {{empty list}} (allowed as per API)
> 2. {{The bundleProvider#getDefaultLocale}} returns {{null}} (not clear if
> allowed or not)
> With the current Sling code, 2. can occurs at
> https://github.com/apache/sling/blob/trunk/bundles/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/I18NFilter.java#L198
> [0]
> https://github.com/apache/sling/blob/trunk/bundles/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/I18NFilter.java#L280-L283
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-6185) I18NHttpServletRequest#getLocale should never return null
[
https://issues.apache.org/jira/browse/SLING-6185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated SLING-6185:
--
Flags: Patch
> I18NHttpServletRequest#getLocale should never return null
> -
>
> Key: SLING-6185
> URL: https://issues.apache.org/jira/browse/SLING-6185
> Project: Sling
> Issue Type: Bug
> Components: i18n
>Affects Versions: i18n 2.5.4
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Attachments: SLING-6185.patch
>
>
> According to the JEE API, the {{ServletRequest#getLocale}} should never
> return {{null}}, the ultimate fallback being the default locale for the
> server.
> However, the Sling wrapper
> {{o.a.s.i.i.I18NFilter.I18NHttpServletRequest#getLocale}} _may_ return
> {{null}} in case:
> 1. the localeResolver does return {{empty list}} (allowed as per API)
> 2. {{The bundleProvider#getDefaultLocale}} returns {{null}} (not clear if
> allowed or not)
> With the current Sling code, 2. can occurs at
> https://github.com/apache/sling/blob/trunk/bundles/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/I18NFilter.java#L198
> [0]
> https://github.com/apache/sling/blob/trunk/bundles/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/I18NFilter.java#L280-L283
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-6185) I18NHttpServletRequest#getLocale should never return null
[
https://issues.apache.org/jira/browse/SLING-6185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated SLING-6185:
--
Attachment: SLING-6185.patch
Attaching svn compatible patch for alternative solution, patch is otherwise
available at
https://github.com/tmaret/sling/commit/74e6e3a2bd21469241cf39fbca9913b051b82312.patch
> I18NHttpServletRequest#getLocale should never return null
> -
>
> Key: SLING-6185
> URL: https://issues.apache.org/jira/browse/SLING-6185
> Project: Sling
> Issue Type: Bug
> Components: i18n
>Affects Versions: i18n 2.5.4
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Attachments: SLING-6185.patch
>
>
> According to the JEE API, the {{ServletRequest#getLocale}} should never
> return {{null}}, the ultimate fallback being the default locale for the
> server.
> However, the Sling wrapper
> {{o.a.s.i.i.I18NFilter.I18NHttpServletRequest#getLocale}} _may_ return
> {{null}} in case:
> 1. the localeResolver does return {{empty list}} (allowed as per API)
> 2. {{The bundleProvider#getDefaultLocale}} returns {{null}} (not clear if
> allowed or not)
> With the current Sling code, 2. can occurs at
> https://github.com/apache/sling/blob/trunk/bundles/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/I18NFilter.java#L198
> [0]
> https://github.com/apache/sling/blob/trunk/bundles/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/I18NFilter.java#L280-L283
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SLING-6185) I18NHttpServletRequest#getLocale should never return null
[
https://issues.apache.org/jira/browse/SLING-6185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15604798#comment-15604798
]
Timothee Maret edited comment on SLING-6185 at 10/25/16 9:54 AM:
-
[~cziegeler] I suggest to fix this by
1. Clarifying that
{{org.apache.sling.i18n.ResourceBundleProvider#getDefaultLocale}} must not
return null and ;
2. Fixing {{CombinedBundleProvider#getDefaultLocale}} such that it returns
{{Locale.ENGLISH}} as fallback
This would require changing the unit tests {{ResourceBundleProviderIT}} which
cover returning {{null}} in some cases.
Alternatively, we could
1. Clarify that
{{org.apache.sling.i18n.ResourceBundleProvider#getDefaultLocale}} _may_ return
null and ;
2. Fixing {{I18NHttpServletRequest#getLocaleList}} such that it returns
{{Locale.ENGLISH}} as fallback when ResourceBundleProvider#getDefaultLocale
returns {{null}}, and we keep the tests as is.
wdyt ?
was (Author: marett):
[~cziegeler] I suggest to fix this by
1. Clarifying that
{{org.apache.sling.i18n.ResourceBundleProvider#getDefaultLocale}} must not
return null and ;
2. Fixing {{CombinedBundleProvider#getDefaultLocale}} such that it returns
{{Locale.ENGLISH}} as fallback
wdyt ?
> I18NHttpServletRequest#getLocale should never return null
> -
>
> Key: SLING-6185
> URL: https://issues.apache.org/jira/browse/SLING-6185
> Project: Sling
> Issue Type: Bug
> Components: i18n
>Affects Versions: i18n 2.5.4
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>
> According to the JEE API, the {{ServletRequest#getLocale}} should never
> return {{null}}, the ultimate fallback being the default locale for the
> server.
> However, the Sling wrapper
> {{o.a.s.i.i.I18NFilter.I18NHttpServletRequest#getLocale}} _may_ return
> {{null}} in case:
> 1. the localeResolver does return {{empty list}} (allowed as per API)
> 2. {{The bundleProvider#getDefaultLocale}} returns {{null}} (not clear if
> allowed or not)
> With the current Sling code, 2. can occurs at
> https://github.com/apache/sling/blob/trunk/bundles/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/I18NFilter.java#L198
> [0]
> https://github.com/apache/sling/blob/trunk/bundles/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/I18NFilter.java#L280-L283
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-6185) I18NHttpServletRequest#getLocale should never return null
[
https://issues.apache.org/jira/browse/SLING-6185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15604798#comment-15604798
]
Timothee Maret commented on SLING-6185:
---
[~cziegeler] I suggest to fix this by
1. Clarifying that
{{org.apache.sling.i18n.ResourceBundleProvider#getDefaultLocale}} must not
return null and ;
2. Fixing {{CombinedBundleProvider#getDefaultLocale}} such that it returns
{{Locale.ENGLISH}} as fallback
wdyt ?
> I18NHttpServletRequest#getLocale should never return null
> -
>
> Key: SLING-6185
> URL: https://issues.apache.org/jira/browse/SLING-6185
> Project: Sling
> Issue Type: Bug
> Components: i18n
>Affects Versions: i18n 2.5.4
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>
> According to the JEE API, the {{ServletRequest#getLocale}} should never
> return {{null}}, the ultimate fallback being the default locale for the
> server.
> However, the Sling wrapper
> {{o.a.s.i.i.I18NFilter.I18NHttpServletRequest#getLocale}} _may_ return
> {{null}} in case:
> 1. the localeResolver does return {{empty list}} (allowed as per API)
> 2. {{The bundleProvider#getDefaultLocale}} returns {{null}} (not clear if
> allowed or not)
> With the current Sling code, 2. can occurs at
> https://github.com/apache/sling/blob/trunk/bundles/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/I18NFilter.java#L198
> [0]
> https://github.com/apache/sling/blob/trunk/bundles/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/I18NFilter.java#L280-L283
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-6185) I18NHttpServletRequest#getLocale should never return null
Timothee Maret created SLING-6185:
-
Summary: I18NHttpServletRequest#getLocale should never return null
Key: SLING-6185
URL: https://issues.apache.org/jira/browse/SLING-6185
Project: Sling
Issue Type: Bug
Components: i18n
Affects Versions: i18n 2.5.4
Reporter: Timothee Maret
Assignee: Timothee Maret
According to the JEE API, the {{ServletRequest#getLocale}} should never return
{{null}}, the ultimate fallback being the default locale for the server.
However, the Sling wrapper
{{o.a.s.i.i.I18NFilter.I18NHttpServletRequest#getLocale}} _may_ return {{null}}
in case:
1. the localeResolver does return {{empty list}} (allowed as per API)
2. {{The bundleProvider#getDefaultLocale}} returns {{null}} (not clear if
allowed or not)
With the current Sling code, 2. can occurs at
https://github.com/apache/sling/blob/trunk/bundles/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/I18NFilter.java#L198
[0]
https://github.com/apache/sling/blob/trunk/bundles/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/I18NFilter.java#L280-L283
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SLING-5135) Whitelist legit usages of loginAdministrative and administrative ResourceResolver
[
https://issues.apache.org/jira/browse/SLING-5135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15604510#comment-15604510
]
Oliver Lietz edited comment on SLING-5135 at 10/25/16 9:01 AM:
---
[~bdelacretaz]: can we align the property names making them consistent? Maybe
just
{{whitelist.bypass}}
{{whitelist.bundles.regex}}
{{whitelist.bundles.default}}
{{whitelist.bundles.additional}}
as all lists use BSNs anyway.
edit: {{bundles}} added to distinguish from {{bypass}}
was (Author: olli):
[~bdelacretaz]: can we align the property names making them consistent? Maybe
just
{{whitelist.regex}}
{{whitelist.default}}
{{whitelist.additional}}
as all lists use BSNs anyway.
> Whitelist legit usages of loginAdministrative and administrative
> ResourceResolver
> -
>
> Key: SLING-5135
> URL: https://issues.apache.org/jira/browse/SLING-5135
> Project: Sling
> Issue Type: Bug
> Components: JCR
>Reporter: Antonio Sanso
>Assignee: Bertrand Delacretaz
> Attachments: SLING-5135.patch, SLING-5135.patch
>
>
> {{AbstractSlingRepositoryManager}} contains a method that disable
> loginAdministrative support
> {code}
> /**
> * Returns whether to disable the
> * {@code SlingRepository.loginAdministrative} method or not.
> *
> * @return {@code true} if {@code SlingRepository.loginAdministrative} is
> * disabled.
> */
> public final boolean isDisableLoginAdministrative()
> {code}
> This is a global configuration. It would be nice to have an extension of such
> mechanism that contains a white list of (few) legit usage of
> {{loginAdministrative}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-6165) Expose a service for Sling Scripting that provides request-scoped Resource Resolvers for scripting dependencies
[
https://issues.apache.org/jira/browse/SLING-6165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15604697#comment-15604697
]
Oliver Lietz commented on SLING-6165:
-
The whitelisting is a somewhat different aspect and probably no longer required
for scripting bundles as {{#setup()}} was removed.
> Expose a service for Sling Scripting that provides request-scoped Resource
> Resolvers for scripting dependencies
> ---
>
> Key: SLING-6165
> URL: https://issues.apache.org/jira/browse/SLING-6165
> Project: Sling
> Issue Type: New Feature
> Components: Scripting
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting Core 2.0.42, Scripting API 2.1.10
>
>
> A new Sling Scripting service ({{ScriptingResourceResolverFactory}}) should
> be implemented in order to provide access to request-based
> {{ResourceResolvers}} for solving script dependencies.
> The following two methods should be available:
> {noformat}
> /**
> * Provides a request-scoped {@link 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
> {@code ResourceResolver} should not be closed by consumers (calling
> * {@link ResourceResolver#close} doesn't do anything), since this service
> will handle the closing operation automatically. The
> * {@code ResourceResolver} will be shared between scripting dependencies
> that render parts of the response for the same request.
> */
> ResourceResolver getRequestScopedResourceResolver()
> /**
> * Provides a {@link ResourceResolver} with only read access to the search
> paths. Once you're done processing {@link Resource}s with this
> * {@code ResourceResolver} make sure to close it.
> */
> ResourceResolver getResourceResolver()
> {noformat}
> [sling-dev email
> thread|https://lists.apache.org/thread.html/db2a78249baf2d6234a4549a5aff8b5474256add9829f86ac78d1c56@%3Cdev.sling.apache.org%3E]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-6165) Expose a service for Sling Scripting that provides request-scoped Resource Resolvers for scripting dependencies
[
https://issues.apache.org/jira/browse/SLING-6165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15604661#comment-15604661
]
Oliver Lietz commented on SLING-6165:
-
{quote}
Bonus points for removing bundles from our default login admin whitelist \[1\]
if this new service allows that.
Currently both o.a.s.scripting.core and o.a.s.scripting.sightly are whitelisted
by default.
{quote}
[~bdelacretaz], [~cziegeler], exposing a service with access to the repository
for *all* without any checks contradicts the service user mapping and system
user concept.
IMHO this is rather not a bonus and I prefer having a check if the service user
of the using bundle matches the service user of the exposing bundle (Scripting
Core in this case).
> Expose a service for Sling Scripting that provides request-scoped Resource
> Resolvers for scripting dependencies
> ---
>
> Key: SLING-6165
> URL: https://issues.apache.org/jira/browse/SLING-6165
> Project: Sling
> Issue Type: New Feature
> Components: Scripting
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting Core 2.0.42, Scripting API 2.1.10
>
>
> A new Sling Scripting service ({{ScriptingResourceResolverFactory}}) should
> be implemented in order to provide access to request-based
> {{ResourceResolvers}} for solving script dependencies.
> The following two methods should be available:
> {noformat}
> /**
> * Provides a request-scoped {@link 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
> {@code ResourceResolver} should not be closed by consumers (calling
> * {@link ResourceResolver#close} doesn't do anything), since this service
> will handle the closing operation automatically. The
> * {@code ResourceResolver} will be shared between scripting dependencies
> that render parts of the response for the same request.
> */
> ResourceResolver getRequestScopedResourceResolver()
> /**
> * Provides a {@link ResourceResolver} with only read access to the search
> paths. Once you're done processing {@link Resource}s with this
> * {@code ResourceResolver} make sure to close it.
> */
> ResourceResolver getResourceResolver()
> {noformat}
> [sling-dev email
> thread|https://lists.apache.org/thread.html/db2a78249baf2d6234a4549a5aff8b5474256add9829f86ac78d1c56@%3Cdev.sling.apache.org%3E]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-6165) Expose a service for Sling Scripting that provides request-scoped Resource Resolvers for scripting dependencies
[
https://issues.apache.org/jira/browse/SLING-6165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15604549#comment-15604549
]
Carsten Ziegeler commented on SLING-6165:
-
Unless we have other use cases, I would keep it in the scripting for now and
not make it generally available as part of the core API
> Expose a service for Sling Scripting that provides request-scoped Resource
> Resolvers for scripting dependencies
> ---
>
> Key: SLING-6165
> URL: https://issues.apache.org/jira/browse/SLING-6165
> Project: Sling
> Issue Type: New Feature
> Components: Scripting
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting Core 2.0.42, Scripting API 2.1.10
>
>
> A new Sling Scripting service ({{ScriptingResourceResolverFactory}}) should
> be implemented in order to provide access to request-based
> {{ResourceResolvers}} for solving script dependencies.
> The following two methods should be available:
> {noformat}
> /**
> * Provides a request-scoped {@link 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
> {@code ResourceResolver} should not be closed by consumers (calling
> * {@link ResourceResolver#close} doesn't do anything), since this service
> will handle the closing operation automatically. The
> * {@code ResourceResolver} will be shared between scripting dependencies
> that render parts of the response for the same request.
> */
> ResourceResolver getRequestScopedResourceResolver()
> /**
> * Provides a {@link ResourceResolver} with only read access to the search
> paths. Once you're done processing {@link Resource}s with this
> * {@code ResourceResolver} make sure to close it.
> */
> ResourceResolver getResourceResolver()
> {noformat}
> [sling-dev email
> thread|https://lists.apache.org/thread.html/db2a78249baf2d6234a4549a5aff8b5474256add9829f86ac78d1c56@%3Cdev.sling.apache.org%3E]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5277) Performance: per thread script resolver (admin session) is always created even if cache is hit
[ https://issues.apache.org/jira/browse/SLING-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15604544#comment-15604544 ] Carsten Ziegeler commented on SLING-5277: - Isn't this superceeded by SLING-6165? /cc [~radu.cotescu] > Performance: per thread script resolver (admin session) is always created > even if cache is hit > -- > > Key: SLING-5277 > URL: https://issues.apache.org/jira/browse/SLING-5277 > Project: Sling > Issue Type: Bug > Components: Servlets >Reporter: Alexander Klimetschek > Attachments: SLING-5277-new.patch, SLING-5277.patch > > > Since SLING-3441, for every request, a new admin / privileged session is > [created in the > SlingServletResolver|https://github.com/apache/sling/blob/trunk/bundles/servlets/resolver/src/main/java/org/apache/sling/servlets/resolver/internal/SlingServletResolver.java#L532]. > It is created before the script/servlet cache is checked, so in most cases > when the cache is hit it is never used, but the cost of creating an extra > session (which can vary, especially with concurrent traffic) is incurred. > The per thread script resolver can be created lazily instead of directly in > the event to avoid this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5135) Whitelist legit usages of loginAdministrative and administrative ResourceResolver
[
https://issues.apache.org/jira/browse/SLING-5135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15604510#comment-15604510
]
Oliver Lietz commented on SLING-5135:
-
[~bdelacretaz]: can we align the property names making them consistent? Maybe
just
{{whitelist.regex}}
{{whitelist.default}}
{{whitelist.additional}}
as all lists use BSNs anyway.
> Whitelist legit usages of loginAdministrative and administrative
> ResourceResolver
> -
>
> Key: SLING-5135
> URL: https://issues.apache.org/jira/browse/SLING-5135
> Project: Sling
> Issue Type: Bug
> Components: JCR
>Reporter: Antonio Sanso
>Assignee: Bertrand Delacretaz
> Attachments: SLING-5135.patch, SLING-5135.patch
>
>
> {{AbstractSlingRepositoryManager}} contains a method that disable
> loginAdministrative support
> {code}
> /**
> * Returns whether to disable the
> * {@code SlingRepository.loginAdministrative} method or not.
> *
> * @return {@code true} if {@code SlingRepository.loginAdministrative} is
> * disabled.
> */
> public final boolean isDisableLoginAdministrative()
> {code}
> This is a global configuration. It would be nice to have an extension of such
> mechanism that contains a white list of (few) legit usage of
> {{loginAdministrative}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (SLING-6153) Improve MapEntries implementation
[ https://issues.apache.org/jira/browse/SLING-6153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-6153. --- > Improve MapEntries implementation > - > > Key: SLING-6153 > URL: https://issues.apache.org/jira/browse/SLING-6153 > Project: Sling > Issue Type: Improvement > Components: ResourceResolver >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Resource Resolver 1.5.0 > > > Looking at the MapEntries implementation it does the same thing in some cases > several times during handling change events. > We should optimize this and also verify that everything is handled by tests. > The current unit tests check more single methods but not the whole > functionality -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-6105) Register old resource event bridge automatically
[ https://issues.apache.org/jira/browse/SLING-6105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-6105. --- > Register old resource event bridge automatically > > > Key: SLING-6105 > URL: https://issues.apache.org/jira/browse/SLING-6105 > Project: Sling > Issue Type: Sub-task > Components: ResourceResolver >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Critical > Fix For: Resource Resolver 1.5.0 > > > Currently the observation to OSGi events bridge is only registered if a > configuration is available. However, this > a) adds the need of a configuration > b) if event handlers are available but the configuration is missing, the > system does not work > c) if no event handlers are available but the configuration is, events are > send with no one listening > We can improve the mechanism, by adding a service tracker for event handlers > listening for resource events. If there are any, we register the bridge. If > there are none, we don't -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-6131) MapEntries: Invalid logic around added/changed/removed property names
[
https://issues.apache.org/jira/browse/SLING-6131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler closed SLING-6131.
---
> MapEntries: Invalid logic around added/changed/removed property names
> -
>
> Key: SLING-6131
> URL: https://issues.apache.org/jira/browse/SLING-6131
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Reporter: Bertrand Delacretaz
>Assignee: Carsten Ziegeler
>Priority: Critical
> Fix For: Resource Resolver 1.5.0
>
>
> The SLING-6000 changes have introduced code that looks incorrect and breaks a
> number of integration tests (MappingEventsProxyTest,
> ResourceResolverProxyTest, VanityPathTest) as (for example) changing a single
> property of a map entry does not cause MapEntries to send events anymore.
> In the affected code below, from the MapEntries class, the changedAttributes
> and removedAttributes section are not reached if addedAttributes is null, I
> don't think that's intentional.
> [~cziegeler] could you have a look? I have assigned this to you as IIUC you
> wrote that SLING-6000 code.
> This is blocking SLING-5135 but I'll commit that code and disable the
> affected integration tests until this is fixed.
> {code}
> Set addedAttributes = rc.getAddedPropertyNames();
> if (addedAttributes != null) {
> ...
> wasResolverRefreshed = doAddAttributes(path, addedAttributes,
> wasResolverRefreshed);
> ...
> Set changedAttributes = rc.getChangedPropertyNames();
> ...
> Set removedAttributes = rc.getRemovedPropertyNames();
> } else {
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (SLING-6159) Implementation should not rely on sling:VanityPath mixin
[ https://issues.apache.org/jira/browse/SLING-6159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-6159. --- > Implementation should not rely on sling:VanityPath mixin > > > Key: SLING-6159 > URL: https://issues.apache.org/jira/browse/SLING-6159 > Project: Sling > Issue Type: Improvement > Components: ResourceResolver >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Resource Resolver 1.5.0 > > > The handling of vanity paths is since a long time a little bit broken: > on startup a query is done using the mixin sling:VanityPath, from that point > on observation is used but only checking the existence of the respective > properties, but not the mixin. So it will find/use the props even if the > mixin is not set. Then you restart, and these things are gone as the query > does not find them. > We should not rely on the mixin at all - we simply use the properties. We do > the same for other things like the resource type as well, there is a mixin > defined but we don't check it. And mixins are a JCR only concept anyway -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-3558) Updating of sling:VanityPath mixins is ignored by sling resource resolution
[ https://issues.apache.org/jira/browse/SLING-3558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-3558. --- > Updating of sling:VanityPath mixins is ignored by sling resource resolution > --- > > Key: SLING-3558 > URL: https://issues.apache.org/jira/browse/SLING-3558 > Project: Sling > Issue Type: Bug > Components: ResourceResolver >Reporter: Antonio Sanso >Assignee: Carsten Ziegeler >Priority: Critical > Fix For: Resource Resolver 1.5.0 > > > Updating (adding/removing) of sling:VanityPath mixins is ignored by sling > resource resolution. The reason behind it is that the event handler in the > MapEntries doesn't listen for sling:VanityPath (mixin) but only for > sling:vanityPath (property name). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-6000) MapEntries should move to new ResourceChangeListener API
[ https://issues.apache.org/jira/browse/SLING-6000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-6000. --- > MapEntries should move to new ResourceChangeListener API > - > > Key: SLING-6000 > URL: https://issues.apache.org/jira/browse/SLING-6000 > Project: Sling > Issue Type: Task > Components: ResourceResolver >Reporter: Hanish Bansal >Assignee: Carsten Ziegeler > Fix For: Resource Resolver 1.5.0 > > > org.apache.sling.resourceresolver.impl.mapping.MapEntries currently > implements org.osgi.service.event.EventHandler Interface. We should start > using the new ResourceChangeListener API. > See [0] for details : > https://issues.apache.org/jira/browse/SLING-5994 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-6148) MapEntries get CHANGED event right after DELETE
[
https://issues.apache.org/jira/browse/SLING-6148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler closed SLING-6148.
---
> MapEntries get CHANGED event right after DELETE
> ---
>
> Key: SLING-6148
> URL: https://issues.apache.org/jira/browse/SLING-6148
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Reporter: Bertrand Delacretaz
>Assignee: Carsten Ziegeler
>Priority: Critical
> Fix For: JCR Resource 2.9.0, Resource Resolver 1.5.0
>
>
> Investigating SLING-6147 I see this in the logs when deleting a /content node:
> {code}
> 13.10.2016 16:20:23.895 *DEBUG* [oak-executor-17]
> org.apache.sling.resourceresolver.impl.mapping.MapEntries onChange,
> type=REMOVED, path=/content
> 13.10.2016 16:20:23.895 *DEBUG* [oak-executor-17]
> org.apache.sling.resourceresolver.impl.mapping.MapEntries onChange,
> type=CHANGED, path=/content
> 13.10.2016 16:20:23.895 *DEBUG* [oak-executor-17]
> org.apache.sling.resourceresolver.impl.mapping.MapEntries doAddVanity getting
> /content
> {code}
> And MapEntries.isValidVanityPath() then fails as it's getting a null resource.
> [~cziegeler] I suppose this is related to recent listener mechanism changes?
> Getting a CHANGED event after the DELETE doesn't seem correct.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (SLING-6164) Introduce optional property names hint to ResourceChangeListener
[ https://issues.apache.org/jira/browse/SLING-6164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-6164. --- > Introduce optional property names hint to ResourceChangeListener > > > Key: SLING-6164 > URL: https://issues.apache.org/jira/browse/SLING-6164 > Project: Sling > Issue Type: Improvement > Components: API, JCR >Affects Versions: JCR Resource 2.8.0, API 2.14.2, Resource Resolver 1.4.18 >Reporter: Stefan Egli >Assignee: Stefan Egli > Fix For: JCR Resource 2.9.0, API 2.15.0, Resource Resolver 1.5.0 > > Attachments: SLING-6164.patch > > > As [discussed on the list|http://sling.markmail.org/thread/usq4a7pglhakd7uq] > it would be useful to allow resource providers to optionally filter for > property names for ResourceChangeListeners. We could thus introduce an > optional _property names hint_ osgi property to the ResourceChangeListener as > well as the corresponding getter to ObserverConfiguration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-6161) Correctly implement Path.matches
[ https://issues.apache.org/jira/browse/SLING-6161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-6161. --- > Correctly implement Path.matches > > > Key: SLING-6161 > URL: https://issues.apache.org/jira/browse/SLING-6161 > Project: Sling > Issue Type: Task > Components: API >Affects Versions: API 2.14.2 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Blocker > Fix For: API 2.15.0 > > > With SLING-5909 a new behaviour has been introduced to Path.matches() which > supports matches a Path against a glob pattern. > The attached test only convers a Path object with "/", but it is unclear what > the intend of this change actually is - and what the semantics is. > The javadoc of matches() right now clearly states that the argument should be > a path, therefore glob pattern is not supported in that method. > [~radu.cotescu] Could you please comment on the intended behaviour? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-6121) Clarify glob pattern handling and support globs and search paths
[ https://issues.apache.org/jira/browse/SLING-6121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-6121. --- > Clarify glob pattern handling and support globs and search paths > > > Key: SLING-6121 > URL: https://issues.apache.org/jira/browse/SLING-6121 > Project: Sling > Issue Type: Sub-task > Components: API, JCR, ResourceResolver >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: API 2.15.0 > > > Looking at the documentation of the glob pattern it is a little bit unclear > to me: > Does the part after the prefix "glob:" need to start with a "/" ? If not, > what does it mean? > Is the special token for search paths supported, e.g. glob:./foo/**/*.html ? > If not, we should implement this -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-6056) achieve 1:1 mapping between observation and resource change listener
[ https://issues.apache.org/jira/browse/SLING-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-6056. --- > achieve 1:1 mapping between observation and resource change listener > > > Key: SLING-6056 > URL: https://issues.apache.org/jira/browse/SLING-6056 > Project: Sling > Issue Type: Task > Components: API, JCR, ResourceResolver >Affects Versions: JCR Resource 2.8.0, API 2.14.2, Resource Resolver 1.4.18 >Reporter: Stefan Egli >Assignee: Carsten Ziegeler >Priority: Critical > Fix For: JCR Resource 2.9.0, API 2.15.0, Resource Resolver 1.5.0 > > Attachments: SLING-6056.patch > > > At the moment it seems there is a 1:n mapping between 1 OakResourceListener > (and 1 BasicObservationReporter) and n ResourceChangeListeners. The idea > however is to get rid of such a bottleneck and have a 1:1 mapping (that might > or might not be in the BasicObservationReporter, that I don't know). We > should implement such a 1:1 mapping. > See [thread on dev list|http://sling.markmail.org/thread/uwhda777psgklwo6] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-6123) Pass additional information like the search path to the listeners
[ https://issues.apache.org/jira/browse/SLING-6123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-6123. --- > Pass additional information like the search path to the listeners > - > > Key: SLING-6123 > URL: https://issues.apache.org/jira/browse/SLING-6123 > Project: Sling > Issue Type: Sub-task > Components: API, ResourceResolver >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: API 2.15.0, Resource Resolver 1.5.0 > > > Some listeners registers themselve with the special token "." for the search > paths, however when they process the event, they have no clue about the > search path and it's ordering. > We could pass the search path as an additional information to the resource > change listener -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-6066) Clarify and complete removal resource events
[ https://issues.apache.org/jira/browse/SLING-6066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-6066. --- > Clarify and complete removal resource events > > > Key: SLING-6066 > URL: https://issues.apache.org/jira/browse/SLING-6066 > Project: Sling > Issue Type: Improvement > Components: API, ResourceResolver >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Blocker > Fix For: API 2.15.0, Resource Resolver 1.5.0 > > > As recently discussed in the mailing list, if a ResourceChangeListener is > interested in removal events, the listener might not get the event it is > interested in. For example, if the listener is registered with a glob > pattern, like **.jsp, but the parent (or any parent) of a jsp is removed. In > that case no removal event for the jsp itself is sent. Which means the > listener is unaware of removals. > We need to clarify this in the javadocs, but also should implement handling > removal in the following: > If a listener is registered for removal events - regardless if a glob pattern > is used or not - the listener will be notified of removals of any parent node > up to the top level node. For example if a listener is interested in > /a/b/c/**/*.jsp, a removal of any resource below "c", but also removal of > "a", "b", or "c" is reported to the listener. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-6138) Use JcrResourceListener for observation
[ https://issues.apache.org/jira/browse/SLING-6138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-6138. --- > Use JcrResourceListener for observation > --- > > Key: SLING-6138 > URL: https://issues.apache.org/jira/browse/SLING-6138 > Project: Sling > Issue Type: Improvement > Components: JCR >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: JCR Resource 2.9.0, API 2.15.0, Resource Resolver 1.5.0 > > > There are several improvements in Oak wrt to observation (e.g. OAK-4581). All > of them are based on the JCR level therefore we only benefit from it if we're > using a JcrResourceListener and not an Oak observer. > Therefore we should remove the special handling for Oak and base the whole > implementation on the JcrResourceListener again > /cc [~egli] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
