[jira] [Comment Edited] (SLING-5677) Provide default customizer for executing TeleporterRule tests

[Konrad Windszus (JIRA)]

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

Konrad Windszus edited comment on SLING-5677 at 9/22/16 4:53 PM:
-

Applied the changes towards the junit.core and junit.teleporter in 
[r1743902|https://svn.apache.org/r1743902] and the sample project leveraging 
the property based customizer in [r1743904|https://svn.apache.org/r1743904].


was (Author: kwin):
Applied the changes towards the junit.core and junit.teleporter in 
[r1743902|https://svn.apache.org/r1743902] and the sample project leveraging 
the property based customizer in [r1743904|https://svn.aache.org/r1743904].

> Provide default customizer for executing TeleporterRule tests
> -
>
> Key: SLING-5677
> URL: https://issues.apache.org/jira/browse/SLING-5677
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.8
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: JUnit Tests Teleporter 1.0.8, JUnit Core 1.0.18
>
>
> Currently for executing ITs leveraging {{TeleporterRule}} there need to be a 
> Customizer referenced, otherwise those ITs would not be executed.
> There should be a DefaultCustomizer which should be used, when there is no 
> other customizer referenced, which must support the following features:
> # setting baseUrl via system property
> # setting serverCredentials via system property
> # setting timeouts via system property
> # setting the dependencyPrefix (both includes and excludes) through system 
> properties.
> For a reasoning have a look at the discussion in 
> http://www.mail-archive.com/dev@sling.apache.org/msg55723.html.



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

[jira] [Commented] (SLING-6025) Context-Aware Config: Provide configuration parameter metadata

[ASF GitHub Bot (JIRA)]

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

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

Github user stefanseifert closed the pull request at:

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


> Context-Aware Config: Provide configuration parameter metadata
> --
>
> Key: SLING-6025
> URL: https://issues.apache.org/jira/browse/SLING-6025
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> in order to support configuration editors GUIs we need to provide metadata 
> which configurations with parameter metadata are defined by the applications.
> this means:
> * list of all configurations registered (singleton, collections, nested) with
> ** their respective configuration names
> ** label (optional)
> ** description (optional)
> * list of all parameters for each configuration
> * parameter metadata:
> ** name
> ** type (only supported: String,int,long,double,boolean and arrays of them)
> ** label (optional)
> ** description (optional)
> ** default value
> ** further custom properties that may customized the configuration editor 
> (e.g. widget type to use, optional)
> the applications needs a possibility to provide such configuration+parameter 
> metadata. by default the annotation interface classes are used for this. they 
> have to be detected on the runtime in the classpath when a new bundle is 
> deployed using an osgi extender pattern (quite similar to sling models). to 
> the annotation classes further annotations can be applied an class and 
> property level to provide the additional metadata (label, description etc.).
> currently we can only support automatic detection of parameter metadata for 
> configurations which are defined and accessed with annotation classes, not 
> when the application used direct valuemap access or the low-level 
> ConfigurationResourceResolver.
> by making the configuration metadata provider pluggable via an SPI we can 
> ship the default configuration providing metadata detected from the deployed 
> annotation classes, but leave a door open to add other sources as well.



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

[jira] [Commented] (SLING-6023) Context-Aware Config: Add pluggable context paths strategies

[ASF GitHub Bot (JIRA)]

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

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

Github user stefanseifert closed the pull request at:

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


> Context-Aware Config: Add pluggable context paths strategies
> 
>
> Key: SLING-6023
> URL: https://issues.apache.org/jira/browse/SLING-6023
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> by default the context paths for which configurations can be linked are 
> defined by the existence of a {{sling:config}} property on that node.
> we want to keep this as default behavior, but this is getting cumbersome if a 
> "massive multi-tenant scenario" is used with hundreds of sites grouped by 
> regions etc. that follow up a consistent repository scheme. in this case it 
> would be easier to not to be forced to create a sling:config property on each 
> site root and link it to the correct configuration (and move it when the site 
> is moved), but to provide an own strategy implementation how these context 
> paths are detected.
> new strategies can be registered as OSGi services, service ranking controls 
> which is asked first. via a service property it should be possible to 
> register a special strategy only for a subpath e.g. /content/tenant1 it 
> should apply to.



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

[jira] [Commented] (SLING-6026) Context-Aware Config: Pluggable configuration persistence

[ASF GitHub Bot (JIRA)]

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

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

Github user stefanseifert closed the pull request at:

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


> Context-Aware Config: Pluggable configuration persistence
> -
>
> Key: SLING-6026
> URL: https://issues.apache.org/jira/browse/SLING-6026
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> currently configuration data is only read, and it's hard-coded how it's 
> stored in the configuration resource (properties directly in the resource).
> we need to enhance this to provide a management API to read+write 
> configuration data (required for configuration editor GUIs).
> additional the details of the persistence should be pluggable with a simple 
> default implementation which can be similar to what is present today. but in 
> more complex environments it may be desired to:
> * use special node types to store the configuration in (e.g. to make sure 
> they are stored in an index)
> * use a jcr:content subnode to store configuration data in
> * assign special resource types to support a configuration editor
> * decide in which path the configurations are stored



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

[GitHub] sling pull request #174: SLING-6026 Context-Aware Config: Pluggable configur...

[stefanseifert]

Github user stefanseifert closed the pull request at:

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


---
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.
---

[GitHub] sling pull request #170: SLING-6025 Context-Aware Config: Provide configurat...

[stefanseifert]

Github user stefanseifert closed the pull request at:

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


---
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.
---

[GitHub] sling pull request #171: SLING-6023 Context-Aware Config: Add pluggable cont...

[stefanseifert]

Github user stefanseifert closed the pull request at:

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


---
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.
---

[jira] [Resolved] (SLING-6007) XSSFilterImpl should move to new ResourceChangeListener API

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-6007.
-
Resolution: Fixed

Thanks for your patch, [~abdul.hameed]
It's applied, I also made the listener an ExternalResourceChangeListener to 
detect changes done within the cluster

> XSSFilterImpl should move to new ResourceChangeListener API   
> 
>
> Key: SLING-6007
> URL: https://issues.apache.org/jira/browse/SLING-6007
> Project: Sling
>  Issue Type: Task
>  Components: XSS Protection API
>Reporter: Hanish Bansal
>Assignee: Carsten Ziegeler
> Fix For: XSS Protection API 1.0.16
>
> Attachments: SLING-6007.txt
>
>
> org.apache.sling.xss.impl.XSSFilterImpl 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] [Updated] (SLING-6007) XSSFilterImpl should move to new ResourceChangeListener API

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-6007:

Fix Version/s: XSS Protection API 1.0.16

> XSSFilterImpl should move to new ResourceChangeListener API   
> 
>
> Key: SLING-6007
> URL: https://issues.apache.org/jira/browse/SLING-6007
> Project: Sling
>  Issue Type: Task
>  Components: XSS Protection API
>Reporter: Hanish Bansal
>Assignee: Carsten Ziegeler
> Fix For: XSS Protection API 1.0.16
>
> Attachments: SLING-6007.txt
>
>
> org.apache.sling.xss.impl.XSSFilterImpl 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] [Assigned] (SLING-6007) XSSFilterImpl should move to new ResourceChangeListener API

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler reassigned SLING-6007:
---

Assignee: Carsten Ziegeler

> XSSFilterImpl should move to new ResourceChangeListener API   
> 
>
> Key: SLING-6007
> URL: https://issues.apache.org/jira/browse/SLING-6007
> Project: Sling
>  Issue Type: Task
>  Components: XSS Protection API
>Reporter: Hanish Bansal
>Assignee: Carsten Ziegeler
> Fix For: XSS Protection API 1.0.16
>
> Attachments: SLING-6007.txt
>
>
> org.apache.sling.xss.impl.XSSFilterImpl 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] [Resolved] (SLING-5996) DistributedEventSender should move to new ResourceChangeListener API

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-5996.
-
Resolution: Fixed

Changed to ResourceChangeListener
Also moved to parent pom 28 and use official OSGi annotations

> DistributedEventSender should move to new ResourceChangeListener API
> 
>
> Key: SLING-5996
> URL: https://issues.apache.org/jira/browse/SLING-5996
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Reporter: Hanish Bansal
>Assignee: Carsten Ziegeler
> Fix For: Distributed Event Admin 1.1.0
>
>
> org.apache.sling.event.dea.impl.DistributedEventSender 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] [Updated] (SLING-5996) DistributedEventSender should move to new ResourceChangeListener API

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-5996:

Fix Version/s: Distributed Event Admin 1.1.0

> DistributedEventSender should move to new ResourceChangeListener API
> 
>
> Key: SLING-5996
> URL: https://issues.apache.org/jira/browse/SLING-5996
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Reporter: Hanish Bansal
>Assignee: Carsten Ziegeler
> Fix For: Distributed Event Admin 1.1.0
>
>
> org.apache.sling.event.dea.impl.DistributedEventSender 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] [Commented] (SLING-6059) Context-Aware Config: Make resource inheritance for configuration collections configurable

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6059:
---

{quote}
Ok, let's keep it simple, I suggest we use "sling:config-inherit" with values 
true|false. I like inherit more than merging as merging might imply that you 
would merge "/conf/global/feature/a" with "/conf/site1/feature/a"
{quote}

agreed, i will come up with an implementation proposal for this.

> Context-Aware Config: Make resource inheritance for configuration collections 
> configurable
> --
>
> Key: SLING-6059
> URL: https://issues.apache.org/jira/browse/SLING-6059
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> currently and automatic merging/combining of configuration resource items 
> takes place. example:
> {noformat}
> /conf/site1/feature/a
> /conf/site1/feature/c
> /conf/global/feature/b
> /libs/conf/feature/c
> {noformat}
> this returns a,b,c when config resource collection for "feature" is 
> requested. c is from /conf/site1/feature/c and not from /libs/conf/feature/c.
> this is inconsistent to the support for properties (where currently no such 
> "merging" is supported), and can have undesired effects.
> furthermore it is problematic when saving configuration collections via the 
> ConfigurationManager interface (SLING-6026). when storing a set of config 
> resources for /conf/site1 they are stored as children of /conf/site1/feature. 
> but when reading them again they are automatically merged with the others 
> from the fallback paths, and the user has no possibility to prevent this.
> so we should either disable this merging on paths, or implement it correctly 
> with giving the user control when merging should take place or not (confmgr 
> has a special property for this).



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

[jira] [Commented] (SLING-6059) Context-Aware Config: Make resource inheritance for configuration collections configurable

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6059:
-

ConfMgr has more complex magic, e.g. if "/conf/global/feature/c" has no 
jcr:content it will not be inherited and it supports a symlink property.
This is definitely too much magic

Yes I was thinking along the same lines with respect to the resource merger.

Ok, let's keep it simple, I suggest we use "sling:config-inherit" with values 
true|false. I like inherit more than merging as merging might imply that you 
would merge "/conf/global/feature/a" with "/conf/site1/feature/a"

> Context-Aware Config: Make resource inheritance for configuration collections 
> configurable
> --
>
> Key: SLING-6059
> URL: https://issues.apache.org/jira/browse/SLING-6059
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> currently and automatic merging/combining of configuration resource items 
> takes place. example:
> {noformat}
> /conf/site1/feature/a
> /conf/site1/feature/c
> /conf/global/feature/b
> /libs/conf/feature/c
> {noformat}
> this returns a,b,c when config resource collection for "feature" is 
> requested. c is from /conf/site1/feature/c and not from /libs/conf/feature/c.
> this is inconsistent to the support for properties (where currently no such 
> "merging" is supported), and can have undesired effects.
> furthermore it is problematic when saving configuration collections via the 
> ConfigurationManager interface (SLING-6026). when storing a set of config 
> resources for /conf/site1 they are stored as children of /conf/site1/feature. 
> but when reading them again they are automatically merged with the others 
> from the fallback paths, and the user has no possibility to prevent this.
> so we should either disable this merging on paths, or implement it correctly 
> with giving the user control when merging should take place or not (confmgr 
> has a special property for this).



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

[jira] [Commented] (SLING-6066) Clarify and complete removal resource events

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6066:
-

Updated javadocs for ResourceChangeListener

> 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, JCR, ResourceResolver
>Reporter: Carsten Ziegeler
> Fix For: JCR Resource 2.8.2, API 2.15.0, Resource Resolver 1.4.20
>
>
> 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] [Updated] (SLING-6066) Clarify and complete removal resource events

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-6066:

Fix Version/s: Resource Resolver 1.4.20
   API 2.15.0
   JCR Resource 2.8.2

> 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, JCR, ResourceResolver
>Reporter: Carsten Ziegeler
> Fix For: JCR Resource 2.8.2, API 2.15.0, Resource Resolver 1.4.20
>
>
> 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] [Commented] (SLING-6059) Context-Aware Config: Make resource inheritance for configuration collections configurable

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6059:
---

hmm, this can quickly get as complex as the sling resource merger with 
hiding/allowing a list of resources by it's name.

i thought about a much simpler solution (as it is supported by the AEM ConfMgr 
currently):
* by default, no configuration lists are merged if you overwrite a named 
configuration on a more specific level (e.g. "feature")
* if you set a "merge" property to true then the resource list on the current 
level is merged with the list on the next-higher level (name duplicates are 
eliminated)
* same logic could be applied to property merging on property level (SLING-6058)

example:
{noformat}
/conf/global/feature/a
/conf/global/feature/b
/conf/global/feature/c
/conf/site1/feature/a
/conf/site1/feature/d
/conf/site2
{noformat}

* for "site1/feature" you get: a,d
* for "site2/feature" your get a,b,c
* if you set a "merge=true" property on /conf/site1/feature you will get a,b,c,d
* for all other usecases you still need to copy what you need and to not set 
merged
* we may support the merged property on both sides, and merging applies if one 
or both sides have set merging=true, and is not applied if the most-specific 
level defines merging=false

if we are sure we need more complexity and control on the inheritance, we 
perhaps should use the resource merger syntax (or the resource merger impl 
itself), instead inventing another complex inheritance description language.

> Context-Aware Config: Make resource inheritance for configuration collections 
> configurable
> --
>
> Key: SLING-6059
> URL: https://issues.apache.org/jira/browse/SLING-6059
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> currently and automatic merging/combining of configuration resource items 
> takes place. example:
> {noformat}
> /conf/site1/feature/a
> /conf/site1/feature/c
> /conf/global/feature/b
> /libs/conf/feature/c
> {noformat}
> this returns a,b,c when config resource collection for "feature" is 
> requested. c is from /conf/site1/feature/c and not from /libs/conf/feature/c.
> this is inconsistent to the support for properties (where currently no such 
> "merging" is supported), and can have undesired effects.
> furthermore it is problematic when saving configuration collections via the 
> ConfigurationManager interface (SLING-6026). when storing a set of config 
> resources for /conf/site1 they are stored as children of /conf/site1/feature. 
> but when reading them again they are automatically merged with the others 
> from the fallback paths, and the user has no possibility to prevent this.
> so we should either disable this merging on paths, or implement it correctly 
> with giving the user control when merging should take place or not (confmgr 
> has a special property for this).



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

[jira] [Comment Edited] (SLING-6059) Context-Aware Config: Make resource inheritance for configuration collections configurable

[Stefan Seifert (JIRA)]

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

Stefan Seifert edited comment on SLING-6059 at 9/22/16 12:08 PM:
-

One common use case is adding/overwriting exhisting configurations, for example 
health checks. There will be predefined HCs somewhere under libs/ and in /conf 
you can override them, usually adding your own. Clearly you don't want to 
repeat/copy all of the existing ones.
So for the example above, a "inherit=true" property on the feature resource 
would do the trick.
But I assume there a some use cases where you want to inherit all but not some 
explicit ones, we could add a property listing those names on the feature 
resource or provide a special resource type, for example - we have three global 
features
{noformat}
/conf/global/feature/b
/conf/global/feature/a
/conf/global/feature/c
{noformat}
and site 1 wants to inherit all but "a":
{noformat}
/conf/site1/feature/
+ inherit=true
/conf/site1/feature/a
+ hide=true
{noformat}

or the first variant would be:
{noformat}
/conf/site1/feature/
+ inherit=true
+ hide=a
{noformat}
The other use case might be where you don't want to inherit all but just a few:
{noformat}
/conf/site1/feature/
+ inherit=b
{noformat}
vs
{noformat}
/conf/site1/feature/
/conf/site1/feature/b
+ inherit=true
{noformat}

Of course we have to come up with better property names, this is just to 
illustrate the possibilites

[~sseif...@pro-vision.de] WDYT?




was (Author: cziegeler):
One common use case is adding/overwriting exhisting configurations, for example 
health checks. There will be predefined HCs somewhere under libs/ and in /conf 
you can override them, usually adding your own. Clearly you don't want to 
repeat/copy all of the existing ones.
So for the example above, a "inherit=true" property on the feature resource 
would do the trick.
But I assume there a some use cases where you want to inherit all but not some 
explicit ones, we could add a property listing those names on the feature 
resource or provide a special resource type, for example - we have three global 
features
/conf/global/feature/b
/conf/global/feature/a
/conf/global/feature/c
and site 1 wants to inherit all but "a":
/conf/site1/feature/
+ inherit=true
/conf/site1/feature/a
+ hide=true

or the first variant would be:
/conf/site1/feature/
+ inherit=true
+ hide=a

The other use case might be where you don't want to inherit all but just a few:
/conf/site1/feature/
+ inherit=b
vs
/conf/site1/feature/
/conf/site1/feature/b
+ inherit=true

Of course we have to come up with better property names, this is just to 
illustrate the possibilites

[~sseif...@pro-vision.de] WDYT?



> Context-Aware Config: Make resource inheritance for configuration collections 
> configurable
> --
>
> Key: SLING-6059
> URL: https://issues.apache.org/jira/browse/SLING-6059
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> currently and automatic merging/combining of configuration resource items 
> takes place. example:
> {noformat}
> /conf/site1/feature/a
> /conf/site1/feature/c
> /conf/global/feature/b
> /libs/conf/feature/c
> {noformat}
> this returns a,b,c when config resource collection for "feature" is 
> requested. c is from /conf/site1/feature/c and not from /libs/conf/feature/c.
> this is inconsistent to the support for properties (where currently no such 
> "merging" is supported), and can have undesired effects.
> furthermore it is problematic when saving configuration collections via the 
> ConfigurationManager interface (SLING-6026). when storing a set of config 
> resources for /conf/site1 they are stored as children of /conf/site1/feature. 
> but when reading them again they are automatically merged with the others 
> from the fallback paths, and the user has no possibility to prevent this.
> so we should either disable this merging on paths, or implement it correctly 
> with giving the user control when merging should take place or not (confmgr 
> has a special property for this).



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

Re: Clarification on https://sling.apache.org/documentation/the-sling-engine/url-decomposition.html

[Konrad Windszus]

I clarified 
http://sling.staging.apache.org/documentation/the-sling-engine/url-decomposition.html
 

 in r1761914 and r1761917. Please quickly cross-check 
http://sling.staging.apache.org/documentation/the-sling-engine/url-decomposition.html
 
.
 I will later publish those changes.

> On 20 Sep 2016, at 11:41, Konrad Windszus  wrote:
> 
> Thanks, got it. Indeed the algorithm seems to differ whether it resolves to 
> an existing path or a non-existing path. Are there any more tests for the 
> resolve method except for the basic ones in 
> https://github.com/apache/sling/blob/c9e59667d8f9cd698bc33a51f3e6a22e85d4a952/bundles/resourceresolver/src/test/java/org/apache/sling/resourceresolver/impl/ResourceResolverImplTest.java#L318?
>  
>   
> >
> Thanks,
> Konrad
> 
>> On 20 Sep 2016, at 11:08, Carsten Ziegeler > > wrote:
>> 
>>> Hi Bertrand, I agree that referencing test cases is for sure good and 
>>> validating those assumptions with those as well (if that is not yet the 
>>> case). Currently though I have troubles to find the according code.
>>> The selector, extension and suffix handling is in 
>>> https://github.com/apache/sling/blob/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/request/SlingRequestPathInfo.java
>>>  and nicely tested in 
>>> https://github.com/apache/sling/blob/c9e59667d8f9cd698bc33a51f3e6a22e85d4a952/bundles/engine/src/test/java/org/apache/sling/engine/impl/request/SlingRequestPathInfoTest.java.
>>> 
>>> But the part which actually extracts the resource from the request url is 
>>> hard to find. So the place where the resource path is separated from the 
>>> rest.
>>> I only found 
>>> https://github.com/apache/sling/blob/c9e59667d8f9cd698bc33a51f3e6a22e85d4a952/bundles/engine/src/main/java/org/apache/sling/engine/impl/request/RequestData.java#L232
>>>  which just relies on HttpServletRequest.getPathInfo() to call 
>>> ResourceResolver.resolve with that path. But that will always use the full 
>>> path (everything up to the query part of the URL) as resource path, which 
>>> is obviously not true.
>>> 
>>> Can someone give me a pointer where in the code the longest resource path 
>>> followed by „.“ algorithm is implemented to find the resource path?
>> 
>> Everything is done in ResourceResolverImpl.resolve and the methods
>> called from there. I think the real work is done in one of  the
>> resolveInternal methods
>> 
>> Carsten
>> 
>>> Is there some servlet filter implemented which overwrites the 
>>> HttpServletRequest.getPathInfo()?
>>> 
>>> Thanks,
>>> Konrad
>>> 
 Am 20.09.2016 um 10:13 schrieb Bertrand Delacretaz 
 :
 
 Hi Konrad,
 
 On Mon, Sep 19, 2016 at 11:37 AM, Konrad Windszus  wrote:
> ...So basically we have to distinguish between existing and non existing 
> resource paths...
 
 Even if someone knew these details off the top of their head (which I
 don't) IMO the only sane way to document these things in a foolproof
 way is with automated tests. Keep the docs at the overview / basic
 principles level, and put the Whole Truth in readable tests.
 
 I think the script resolution page [1], which points to the
 ScriptSelectionTest [2] is a good example of that, that we might want
 to replicate for the URL decomposition components.
 
 -Bertrand
 
 [1] 
 https://sling.apache.org/documentation/the-sling-engine/url-to-script-resolution.html
 [2] 
 http://svn.apache.org/repos/asf/sling/trunk/bundles/servlets/resolver/src/test/java/org/apache/sling/servlets/resolver/internal/helper/ScriptSelectionTest.java
>>> 
>>> 
>> 
>> 
>> 
>> 
>> -- 
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org  
>> >

[jira] [Commented] (SLING-6059) Context-Aware Config: Make resource inheritance for configuration collections configurable

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6059:
-

One common use case is adding/overwriting exhisting configurations, for example 
health checks. There will be predefined HCs somewhere under libs/ and in /conf 
you can override them, usually adding your own. Clearly you don't want to 
repeat/copy all of the existing ones.
So for the example above, a "inherit=true" property on the feature resource 
would do the trick.
But I assume there a some use cases where you want to inherit all but not some 
explicit ones, we could add a property listing those names on the feature 
resource or provide a special resource type, for example - we have three global 
features
/conf/global/feature/b
/conf/global/feature/a
/conf/global/feature/c
and site 1 wants to inherit all but "a":
/conf/site1/feature/
+ inherit=true
/conf/site1/feature/a
+ hide=true

or the first variant would be:
/conf/site1/feature/
+ inherit=true
+ hide=a

The other use case might be where you don't want to inherit all but just a few:
/conf/site1/feature/
+ inherit=b
vs
/conf/site1/feature/
/conf/site1/feature/b
+ inherit=true

Of course we have to come up with better property names, this is just to 
illustrate the possibilites

[~sseif...@pro-vision.de] WDYT?



> Context-Aware Config: Make resource inheritance for configuration collections 
> configurable
> --
>
> Key: SLING-6059
> URL: https://issues.apache.org/jira/browse/SLING-6059
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> currently and automatic merging/combining of configuration resource items 
> takes place. example:
> {noformat}
> /conf/site1/feature/a
> /conf/site1/feature/c
> /conf/global/feature/b
> /libs/conf/feature/c
> {noformat}
> this returns a,b,c when config resource collection for "feature" is 
> requested. c is from /conf/site1/feature/c and not from /libs/conf/feature/c.
> this is inconsistent to the support for properties (where currently no such 
> "merging" is supported), and can have undesired effects.
> furthermore it is problematic when saving configuration collections via the 
> ConfigurationManager interface (SLING-6026). when storing a set of config 
> resources for /conf/site1 they are stored as children of /conf/site1/feature. 
> but when reading them again they are automatically merged with the others 
> from the fallback paths, and the user has no possibility to prevent this.
> so we should either disable this merging on paths, or implement it correctly 
> with giving the user control when merging should take place or not (confmgr 
> has a special property for this).



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

[jira] [Resolved] (SLING-5999) JcrResourceBundleProvider should move to new ResourceChangeListener API

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-5999.
-
Resolution: Resolved

I've now switched back to the root listener, if we want to improve this we can 
track it in another issue

> JcrResourceBundleProvider should move to new ResourceChangeListener API   
> 
>
> Key: SLING-5999
> URL: https://issues.apache.org/jira/browse/SLING-5999
> Project: Sling
>  Issue Type: Task
>  Components: i18n
>Reporter: Hanish Bansal
>Assignee: Carsten Ziegeler
> Fix For: i18n 2.5.4
>
>
> org.apache.sling.i18n.impl.JcrResourceBundleProvider 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] [Comment Edited] (SLING-5999) JcrResourceBundleProvider should move to new ResourceChangeListener API

[Konrad Windszus (JIRA)]

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

Konrad Windszus edited comment on SLING-5999 at 9/22/16 11:42 AM:
--

There was never any path restriction implemented (except through bugs) or 
documented at 
http://sling.apache.org/documentation/bundles/internationalization-support-i18n.html.
 If we want to start that now that will cause a lot of pain during upgrade for 
existing software. Therefore we must be very careful when we introduce that now.
Instead this bundle always relied on nodetypes and mixins to find all 
dictionaries (both are not really a concept of Sling but rather of JCR and 
therefore not really supported by Sling API either, which lead to problems like 
the one outlined in 
https://issues.apache.org/jira/browse/SLING-4814?focusedCommentId=14591461=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14591461).
 Therefore it would probably be a good idea to rethink that approach and come 
up with an alternative way of how dictionaries stored in resources are found 
which is really independent of JCR (probably that should then also be reflected 
in the class names).


was (Author: kwin):
There was never any path restriction implemented (except through bugs) or 
documented at 
http://sling.apache.org/documentation/bundles/internationalization-support-i18n.html.
 If we want to start that now that will cause a lot of pain during upgrade for 
existing software.
Instead this bundle always relied on nodetypes and mixins to find all 
dictionaries (both are not really a concept of Sling but rather of JCR and 
therefore not really supported by Sling API either, which lead to problems like 
the one outlined in 
https://issues.apache.org/jira/browse/SLING-4814?focusedCommentId=14591461=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14591461).
 Therefore it would probably be a good idea to rethink that approach and come 
up with an alternative way of how dictionaries stored in resources are found.

> JcrResourceBundleProvider should move to new ResourceChangeListener API   
> 
>
> Key: SLING-5999
> URL: https://issues.apache.org/jira/browse/SLING-5999
> Project: Sling
>  Issue Type: Task
>  Components: i18n
>Reporter: Hanish Bansal
>Assignee: Carsten Ziegeler
> Fix For: i18n 2.5.4
>
>
> org.apache.sling.i18n.impl.JcrResourceBundleProvider 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] [Comment Edited] (SLING-5999) JcrResourceBundleProvider should move to new ResourceChangeListener API

[Konrad Windszus (JIRA)]

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

Konrad Windszus edited comment on SLING-5999 at 9/22/16 11:41 AM:
--

There was never any path restriction implemented (except through bugs) or 
documented at 
http://sling.apache.org/documentation/bundles/internationalization-support-i18n.html.
 If we want to start that now that will cause a lot of pain during upgrade for 
existing software.
Instead this bundle always relied on nodetypes and mixins to find all 
dictionaries (both are not really a concept of Sling but rather of JCR and 
therefore not really supported by Sling API either, which lead to problems like 
the one outlined in 
https://issues.apache.org/jira/browse/SLING-4814?focusedCommentId=14591461=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14591461).
 Therefore it would probably be a good idea to rethink that approach and come 
up with an alternative way of how dictionaries stored in resources are found.


was (Author: kwin):
There was never any restriction implemented (except through bugs) or documented 
at 
http://sling.apache.org/documentation/bundles/internationalization-support-i18n.html.
 If we want to start that now that will cause a lot of pain during upgrade for 
existing software.

> JcrResourceBundleProvider should move to new ResourceChangeListener API   
> 
>
> Key: SLING-5999
> URL: https://issues.apache.org/jira/browse/SLING-5999
> Project: Sling
>  Issue Type: Task
>  Components: i18n
>Reporter: Hanish Bansal
>Assignee: Carsten Ziegeler
> Fix For: i18n 2.5.4
>
>
> org.apache.sling.i18n.impl.JcrResourceBundleProvider 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] [Commented] (SLING-5999) JcrResourceBundleProvider should move to new ResourceChangeListener API

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-5999:


There was never any restriction implemented (except through bugs) or documented 
at 
http://sling.apache.org/documentation/bundles/internationalization-support-i18n.html.
 If we want to start that now that will cause a lot of pain during upgrade for 
existing software.

> JcrResourceBundleProvider should move to new ResourceChangeListener API   
> 
>
> Key: SLING-5999
> URL: https://issues.apache.org/jira/browse/SLING-5999
> Project: Sling
>  Issue Type: Task
>  Components: i18n
>Reporter: Hanish Bansal
>Assignee: Carsten Ziegeler
> Fix For: i18n 2.5.4
>
>
> org.apache.sling.i18n.impl.JcrResourceBundleProvider 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] [Reopened] (SLING-5999) JcrResourceBundleProvider should move to new ResourceChangeListener API

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler reopened SLING-5999:
-

> JcrResourceBundleProvider should move to new ResourceChangeListener API   
> 
>
> Key: SLING-5999
> URL: https://issues.apache.org/jira/browse/SLING-5999
> Project: Sling
>  Issue Type: Task
>  Components: i18n
>Reporter: Hanish Bansal
>Assignee: Carsten Ziegeler
> Fix For: i18n 2.5.4
>
>
> org.apache.sling.i18n.impl.JcrResourceBundleProvider 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] [Commented] (SLING-5999) JcrResourceBundleProvider should move to new ResourceChangeListener API

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-5999:
-

That is true :( Do we really need to listen to the whole repository? Or can we 
make some paths configurable?
Listeners on root should really be avoided

> JcrResourceBundleProvider should move to new ResourceChangeListener API   
> 
>
> Key: SLING-5999
> URL: https://issues.apache.org/jira/browse/SLING-5999
> Project: Sling
>  Issue Type: Task
>  Components: i18n
>Reporter: Hanish Bansal
>Assignee: Carsten Ziegeler
> Fix For: i18n 2.5.4
>
>
> org.apache.sling.i18n.impl.JcrResourceBundleProvider 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] [Commented] (SLING-5999) JcrResourceBundleProvider should move to new ResourceChangeListener API

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-5999:


If I understand the code correctly, this change will not detect new 
dictionaries any longer. So basically the fix being done for SLING-4814 is no 
longer effective. Basically anywhere in the repository a new dictionary may be 
added. That new dictionary must be detected by the event listener as well!

> JcrResourceBundleProvider should move to new ResourceChangeListener API   
> 
>
> Key: SLING-5999
> URL: https://issues.apache.org/jira/browse/SLING-5999
> Project: Sling
>  Issue Type: Task
>  Components: i18n
>Reporter: Hanish Bansal
>Assignee: Carsten Ziegeler
> Fix For: i18n 2.5.4
>
>
> org.apache.sling.i18n.impl.JcrResourceBundleProvider 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)

RE: [CANCEL][VOTE] Release Apache Sling Discovery Commons 1.0.14 and Discovery Oak 1.2.12

[Stefan Seifert]

i've update the sling api dependency to 2.11 to fix the sling build.

stefan

>-Original Message-
>From: Stefan Egli [mailto:stefane...@apache.org]
>Sent: Wednesday, September 21, 2016 6:30 PM
>To: dev@sling.apache.org
>Subject: [CANCEL][VOTE] Release Apache Sling Discovery Commons 1.0.14
>and Discovery Oak 1.2.12
>
>Thx Daniel for spotting, not sure why I didn't spot this during
>testing..
>
>I'm cancelling this release and will redo.
>
>Cheers,
>Stefan
>
>On 21/09/16 18:13, "Daniel Klco"  wrote:
>
>>-1 This seems to depend on an unreleased version of the Sling API,
>>specifically:
>>
>>org.apache.sling:org.apache.sling.api:jar:2.10.0
>>
>>Released versions:
>>
>>http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.sling%22%
>20A
>>ND%20a%3A%22org.apache.sling.api%22
>>
>>Please find build failure logs here:
>>https://gist.github.com/klcodanr/70cb1d351ec92e40936490f117c9d7c2
>>
>>
>>On Wed, Sep 21, 2016 at 11:11 AM, Stefan Egli 
>>wrote:
>>
>>> +1
>>>
>>> Cheers,
>>> Stefan
>>>
>>> On 21/09/16 17:06, "Stefan Egli"  wrote:
>>>
>>> >Hi,
>>> >
>>> >We solved 3 issues in these 2 related releases:
>>> >
>>> >https://issues.apache.org/jira/browse/SLING/fixforversion/12335443
>>> >https://issues.apache.org/jira/browse/SLING/fixforversion/12338203
>>> >
>>> >Staging repository:
>>> >https://repository.apache.org/content/repositories/orgapachesling-
>1525
>>> >
>>> >You can use this UNIX script to download the release and verify the
>>> >signatures:
>>> >http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>>> >
>>> >Usage:
>>> >sh check_staged_release.sh 1525 /tmp/sling-staging
>>> >
>>> >Please vote to approve this release:
>>> >
>>> >  [ ] +1 Approve the release
>>> >  [ ]  0 Don't care
>>> >  [ ] -1 Don't release, because ...
>>> >
>>> >This majority vote is open for at least 72 hours.
>>> >
>>> >Cheers,
>>> >Stefan
>>> >
>>> >
>>> >
>>> >
>>> >
>>>
>>>
>>>
>
>

[jira] [Updated] (SLING-6066) Clarify and complete removal resource events

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-6066:

Issue Type: Improvement  (was: Sub-task)
Parent: (was: SLING-5994)

> 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, JCR, ResourceResolver
>Reporter: Carsten Ziegeler
>
> 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] [Resolved] (SLING-5999) JcrResourceBundleProvider should move to new ResourceChangeListener API

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-5999.
-
Resolution: Fixed

I've changed the code to use the ResourceChangeListener and instead of 
registering a single listener at the root, for each language root, a separate 
listener is registered

> JcrResourceBundleProvider should move to new ResourceChangeListener API   
> 
>
> Key: SLING-5999
> URL: https://issues.apache.org/jira/browse/SLING-5999
> Project: Sling
>  Issue Type: Task
>  Components: i18n
>Reporter: Hanish Bansal
>Assignee: Carsten Ziegeler
> Fix For: i18n 2.5.4
>
>
> org.apache.sling.i18n.impl.JcrResourceBundleProvider 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)

Sling Committer Round Table @ adaptTo() 2016

[Stefan Seifert]

fyi: we reserved a timeslot for a "Sling Committer Round Table" at adaptTo() 
2016 conference next week:

tuesday 27.9.16 18:30-19:30 in the conference room

all committers that are present at the conference are invited!
(the meeting is not private, so others that are interested may join as well)

we will build an ad-hoc agenda at the beginning of the meeting. if we discuss 
topics of relevance we will document it here in the mailing list as well.

see you next week!

stefan

[jira] [Updated] (SLING-6007) XSSFilterImpl should move to new ResourceChangeListener API

[abdul hameed pathan (JIRA)]

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

abdul hameed pathan updated SLING-6007:
---
Attachment: SLING-6007.txt

[~cziegeler] submitting the patch, please review it.

> XSSFilterImpl should move to new ResourceChangeListener API   
> 
>
> Key: SLING-6007
> URL: https://issues.apache.org/jira/browse/SLING-6007
> Project: Sling
>  Issue Type: Task
>  Components: XSS Protection API
>Reporter: Hanish Bansal
> Attachments: SLING-6007.txt
>
>
> org.apache.sling.xss.impl.XSSFilterImpl 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] [Updated] (SLING-6003) JavaScriptEngineFactory should move to new ResourceChangeListener API

[abdul hameed pathan (JIRA)]

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

abdul hameed pathan updated SLING-6003:
---
Attachment: SLING-6003.txt

[~cziegeler] Submitting the patch. please review.

> JavaScriptEngineFactory should move to new ResourceChangeListener API 
> --
>
> Key: SLING-6003
> URL: https://issues.apache.org/jira/browse/SLING-6003
> Project: Sling
>  Issue Type: Task
>  Components: Scripting
>Reporter: Hanish Bansal
> Attachments: SLING-6003.txt
>
>
> org.apache.sling.scripting.java.impl.JavaScriptEngineFactory 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)

Re: Observation with the ResourceChangeListener

[Carsten Ziegeler]

I've created SLING-6066 for handling remove events with a proposal on
how to implement it.

No one commented on how we should handle changes to resource mappings
where currently the listener is registered for changes in the whole
resource tree and filters on property names. I guess we make the paths
to listen for configurable and do the property name filtering in the
listener.

Carsten

> Hi,
> 
> as you know we're currently in the process of moving away from the OSGi
> event based observation to the ResourceChangeListener interfaces. Main
> reason is moving to a more scalable/better performing solution.
> 
> We started very simple with the ResourceChangeListener: listeners
> register themselves with the three where they are interested in changes.
> They can also specify whether they are interested in adds, removes,
> and/or updates. This is basic functionality.
> 
> Recently, support for a glob pattern was added, for example scripting
> engines like jsp are only interested in changes of "*.jsp" files. While
> this sounds like a great idea, this only works reliable for adds and
> updates. However it does not work for removes, if e.g. only the parent
> resource of a jsp (or any parent) is removed, then usually you only get
> a resource removal event for that parent. As the listener is registered
> with the *.jsp pattern and the parent name usually does not match this,
> the listener does not get this event at all.
> 
> I guess a good compromise would be to do the filtering for add and
> update but send all remove events for the relevant tree to the listener.
> 
> For resource mapping we currently register a listener that listens to
> all events that deal with certain properties. So if a specific property
> is added, removed, or updated this listener should be triggered. Again
> for add and update this might be solvable, but for a delete it is not.
> Furthermore the information about properties for a change event is
> currently specified as optional, so the listener can't rely that this
> information is send. And I don't think that it makes sense to send this
> information for each and every event we have, as usually listeners do
> not care about specific properties.
> 
> I tend to move this special filtering to the listener. However this
> leaves us still with the problem that the listener is mounted at /. I
> think we should narrow down the support for resource mappings to
> specific paths. We can make this configurable of course.
> 
> Finally, recently some people suggested that we support all of Oaks
> filtering possibilities for the ResourceChangeListener. I'm not a fan of
> that - first of all, we should only support what is really needed.
> Second, as soon as we support it, it means that every resource provider
> needs to support it which might but a high burden for nothing on the
> implementations. And finally, as we already see with the globbing,
> filtering is nice but we have to be careful for remove events and
> clearly specifiy how this works - and specify it in a way that it really
> works for the listeners.
> 
> Regards
> Carsten
> 


 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[jira] [Created] (SLING-6066) Clarify and complete removal resource events

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-6066:
---

 Summary: Clarify and complete removal resource events
 Key: SLING-6066
 URL: https://issues.apache.org/jira/browse/SLING-6066
 Project: Sling
  Issue Type: Sub-task
  Components: API, JCR, ResourceResolver
Reporter: Carsten Ziegeler


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)

[Discovery] Mark certain cluster nodes to not participate in leader election

[Chetan Mehrotra]

I have a hetrogeneous cluster deployment consisting of different type
of Sling instance. Of this some of the Sling instance play worker role
and connect to same repository.

Would it be possible to have a config where such cluster members do
not participate in leader election and hence do not become candidate
for running cluster singleton jobs

Chetan Mehrotra

Re: [i18n] Integration tests fails with Oak

[Carsten Ziegeler]

> Hi,
> 
> I moved the i18n integration tests to use Oak (instead of jackrabbit 2)
> and now one integration test fails. Right now, I don't see a good reason
> why.
> Any help or hint appreciated.
> 
I found the problem: the it test was buggy. It created duplicate message
entries for the same key.
Fixed now

 Regards

Carsten

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org