[VOTE] Release Apache Sling Context-Aware Configuration API 1.0.0, SPI 1.0.0, Impl 1.0.0, BND Plugin 1.0.0, Resource Builder 1.0.2, Testing Hamcrest 1.0.0

[Stefan Seifert]

Hi,

Context-Aware Configuration API 1.0.0  (4 Issues)
https://issues.apache.org/jira/browse/SLING/fixforversion/12338139

Context-Aware Configuration SPI 1.0.0  (7 Issues)
https://issues.apache.org/jira/browse/SLING/fixforversion/12338440

Context-Aware Configuration Impl 1.0.0  (16 Issues)
https://issues.apache.org/jira/browse/SLING/fixforversion/12338442

Context-Aware Configuration BND Plugin 1.0.0  (1 Issue)
https://issues.apache.org/jira/browse/SLING/fixforversion/12338444

Resource Builder 1.0.2 (1 Issue)
https://issues.apache.org/jira/browse/SLING/fixforversion/12338269

Testing Hamcrest 1.0.0 (5 Issues)
https://issues.apache.org/jira/browse/SLING/fixforversion/12333647

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-1540/

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


Documentation for Sling Context-Aware Configuration
http://sling.apache.org/documentation/bundles/context-aware-configuration/context-aware-configuration.html


stefan

[jira] [Resolved] (SLING-6158) Context-Aware Config: BND Plugin

[Stefan Seifert (JIRA)]

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

Stefan Seifert resolved SLING-6158.
---
Resolution: Fixed

Completed: At revision: 1764969  


> Context-Aware Config: BND Plugin
> 
>
> Key: SLING-6158
> URL: https://issues.apache.org/jira/browse/SLING-6158
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Minor
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration BND Plugin 1.0.0
>
>
> BND plugin to auto-generate required bundle header for @Configuration 
> annotated classes in project.



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

[jira] [Created] (SLING-6158) Context-Aware Config: BND Plugin

[Stefan Seifert (JIRA)]

Stefan Seifert created SLING-6158:
-

 Summary: Context-Aware Config: BND Plugin
 Key: SLING-6158
 URL: https://issues.apache.org/jira/browse/SLING-6158
 Project: Sling
  Issue Type: New Feature
  Components: Extensions
Reporter: Stefan Seifert
Assignee: Stefan Seifert
Priority: Minor
 Fix For: Context-Aware Configuration BND Plugin 1.0.0


BND plugin to auto-generate required bundle header for @Configuration annotated 
classes in project.



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

[jira] [Updated] (SLING-6157) Context-Aware Config: Change java package name to o.a.s.caconfig

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-6157:
--
Fix Version/s: Context-Aware Configuration Impl 1.0.0
   Context-Aware Configuration SPI 1.0.0

> Context-Aware Config: Change java package name to o.a.s.caconfig
> 
>
> Key: SLING-6157
> URL: https://issues.apache.org/jira/browse/SLING-6157
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Context-Aware Configuration API 1.0.0
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Minor
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration API 1.0.0, Context-Aware 
> Configuration SPI 1.0.0, Context-Aware Configuration Impl 1.0.0
>
>
> change the java package names from {{org.apache.sling.contextaware.config}} 
> to {{org.apache.sling.caconfig}}.
> see discussion 
> https://lists.apache.org/thread.html/844a6e56c5b5020106d145edc7fd9faa721642b2c905987c81a1b548@%3Cdev.sling.apache.org%3E



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

[jira] [Updated] (SLING-6154) Context-Aware Config: Use camel case for property names

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-6154:
--
Fix Version/s: Context-Aware Configuration Impl 1.0.0

> Context-Aware Config: Use camel case for property names
> ---
>
> Key: SLING-6154
> URL: https://issues.apache.org/jira/browse/SLING-6154
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Minor
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration Impl 1.0.0
>
>
> to be more consistent with other parts of sling we should use camelcase names 
> like
> {noformat}
> sling:configRef
> sling:configCollectionInherit
> sling:configPropertyInherit  
> {noformat}



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

[jira] [Updated] (SLING-6152) Context-Aware Config: Config reference should be detected in ContextPathStrategy

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-6152:
--
Fix Version/s: (was: Context-Aware Configuration API 1.0.0)
   Context-Aware Configuration Impl 1.0.0
   Context-Aware Configuration SPI 1.0.0

> Context-Aware Config: Config reference should be detected in 
> ContextPathStrategy
> 
>
> Key: SLING-6152
> URL: https://issues.apache.org/jira/browse/SLING-6152
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Context-Aware Configuration API 1.0.0
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration SPI 1.0.0, Context-Aware 
> Configuration Impl 1.0.0
>
>
> currently the DefaultContextPathStrategy checks for the availability of the 
> sling:config-ref prop, but it does not return it's value, this is done in the 
> DefaultConfigurationResourceResolvingStrategy.
> this is as bit inconsistent, leading to configure the lookup of SLING-6149 in 
> multiple places, and makes it more difficult to define scenarios where the 
> config references is build on a conventions-based pattern (e.g. derived from 
> content path) instead of an explicit sling:config-ref property.
> the logic itself and other implementation details of both strategies remain 
> untouched.



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

[jira] [Updated] (SLING-6114) Support nested configurations in configurated locations

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-6114:
--
Fix Version/s: (was: Context-Aware Configuration API 1.0.0)
   Context-Aware Configuration Impl 1.0.0

> Support nested configurations in configurated locations
> ---
>
> Key: SLING-6114
> URL: https://issues.apache.org/jira/browse/SLING-6114
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Carsten Ziegeler
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration Impl 1.0.0
>
>
> Let's assume you have a content like this:
> /content/level1/level2[@sling-config-ref='/conf/project/sub']
> and configurations
> /conf/project/something
> /conf/project/sub/something-else
> the default path strategy should directly go up the hierarchy in the 
> configured location (/conf in this case), so /conf/project/sub is tried 
> first, then /conf/project and then the other configured paths.
> The only question is if you have
> /libs/conf/project/sub
> is this handled before /conf/project or after?



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

[jira] [Updated] (SLING-6149) Context-Aware Config: Make lookup resource name for sling:config-ref property configurable

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-6149:
--
Fix Version/s: (was: Context-Aware Configuration API 1.0.0)
   Context-Aware Configuration Impl 1.0.0

> Context-Aware Config: Make lookup resource name for sling:config-ref property 
> configurable
> --
>
> Key: SLING-6149
> URL: https://issues.apache.org/jira/browse/SLING-6149
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Minor
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration Impl 1.0.0
>
>
> by default, the sling:config-ref property is looked up directly in the 
> context root resource. it should be possible to define alternative lookup 
> paths e.g. to look in a child node jcr:content for it.



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

[jira] [Updated] (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:all-tabpanel
 ]

Stefan Seifert updated SLING-6059:
--
Fix Version/s: (was: Context-Aware Configuration API 1.0.0)
   Context-Aware Configuration Impl 1.0.0

> 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 Impl 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] [Updated] (SLING-6057) Context-Aware Config: Separate Maven Project for SPI

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-6057:
--
Fix Version/s: (was: Context-Aware Configuration API 1.0.0)
   Context-Aware Configuration SPI 1.0.0

> Context-Aware Config: Separate Maven Project for SPI
> 
>
> Key: SLING-6057
> URL: https://issues.apache.org/jira/browse/SLING-6057
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Minor
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration SPI 1.0.0
>
>
> the SPI packages should go into a separate project.
> most applications only need to import the API packages, no need to confuse 
> them with the interfaces from the SPI.



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

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

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-6026:
--
Fix Version/s: (was: Context-Aware Configuration API 1.0.0)
   Context-Aware Configuration Impl 1.0.0
   Context-Aware Configuration SPI 1.0.0

> 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 SPI 1.0.0, Context-Aware 
> Configuration Impl 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)

[jira] [Updated] (SLING-6029) Context-Aware Config: Adapt defaulting strategy

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-6029:
--
Fix Version/s: (was: Context-Aware Configuration API 1.0.0)
   Context-Aware Configuration Impl 1.0.0

> Context-Aware Config: Adapt defaulting strategy
> ---
>
> Key: SLING-6029
> URL: https://issues.apache.org/jira/browse/SLING-6029
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration Impl 1.0.0
>
>
> as discusesd in mail thread 
> http://apache-sling.73963.n3.nabble.com/contextaware-config-Default-configuration-and-naming-td4064399.html
>  we should change:
> * default folder name to /conf
> * rename the {{sling:config}} property name to {{sling:config-ref}}
> * and change the way default configuration is detected by following the 
> example below
> for a content structure like this
> {noformat}
>  /content
>/tenant1   - context path /content/tenant1
>  /region1 - context path /content/tenant1/region1
>/site1 - context path /content/tenant1/region1/site1
>  /page1
> {noformat}
> the configuration is looked up at this paths (in this order)
> {noformat}
>  /conf/tenant1/region1/site1
>  /conf/tenant1/region1
>  /conf/tenant1
>  /conf/global
>  /apps/conf
>  /libs/conf
> {noformat}



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

[jira] [Updated] (SLING-6058) Context-Aware Config: Property Inheritance/Merging

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-6058:
--
Fix Version/s: (was: Context-Aware Configuration API 1.0.0)
   Context-Aware Configuration Impl 1.0.0

> Context-Aware Config: Property Inheritance/Merging
> --
>
> Key: SLING-6058
> URL: https://issues.apache.org/jira/browse/SLING-6058
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Minor
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration Impl 1.0.0
>
>
> currently the context-aware config implementation supports resource 
> inheritance, but not property inheritance, that means no properties gets 
> merged in the resource inheritance chain.
> there was a long discussion on the mailing list about this topics with 
> arguments to support this, and other not to support this
> http://apache-sling.73963.n3.nabble.com/Context-Aware-Configs-Merging-tt4063382.html
> the goal of this ticket is to support it, but make it configurable so it can 
> be switched on and off.



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

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

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-6023:
--
Fix Version/s: (was: Context-Aware Configuration API 1.0.0)
   Context-Aware Configuration Impl 1.0.0
   Context-Aware Configuration SPI 1.0.0

> 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 SPI 1.0.0, Context-Aware 
> Configuration Impl 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] [Updated] (SLING-6024) Context-Aware Config: Introduce "bucket name" parameter in ConfigurationResourceResolver

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-6024:
--
Fix Version/s: Context-Aware Configuration Impl 1.0.0

> Context-Aware Config: Introduce "bucket name" parameter in 
> ConfigurationResourceResolver
> 
>
> Key: SLING-6024
> URL: https://issues.apache.org/jira/browse/SLING-6024
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Minor
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration API 1.0.0, Context-Aware 
> Configuration Impl 1.0.0
>
>
> follow-up from discussion: 
> http://apache-sling.73963.n3.nabble.com/context-aware-config-why-sling-configs-node-tt4064393.html
> we want to introduce a "bucket-name" parameter in 
> ConfigurationResourceResolver interface to make it explicit each high-level 
> configuration-like resolver should define one.



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

[jira] [Updated] (SLING-5982) Use custom converter adaption from ValueMap to Annotation class

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-5982:
--
Fix Version/s: (was: Context-Aware Configuration API 1.0.0)
   Context-Aware Configuration Impl 1.0.0

> Use custom converter adaption from ValueMap to Annotation class
> ---
>
> Key: SLING-5982
> URL: https://issues.apache.org/jira/browse/SLING-5982
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration Impl 1.0.0
>
>
> this is about the context-aware configuration: 
> https://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/contextaware-config
> currently we use the out-of-the-box functionality of the OSGi converter 
> server to map a resource valuemap properties to an annotation class. this 
> works very well.
> however some things need to be improved, and we need a custom conversion 
> adapter rules for this:
> * the dynamic proxy created by the converter (see 
> [ConvertingImpl#createProxy|https://github.com/apache/felix/blob/trunk/converter/src/main/java/org/apache/felix/converter/impl/ConvertingImpl.java#L311])
>  only knows the Map interface, not ValueMap, thus it accesses directly the 
> "raw" type from the value map. all the conversion magic that exists in the 
> JCR value map implementation is not applied. the converter has it's own 
> magic, but it will not always produce the same results as the JCR mapping 
> magic. thus we need an adaption rule from ValueMap to  
> which used the valuemap get methods with the type required for the property 
> as second argument.
> * problem: the converter service currently supports explicit mappings from 
> type A to B, not mapping from type A to any type. most of the rule method 
> variants are currently not implemented in the felix converter impl. i will 
> post a question for this issues on the felix mailing list.
> once we have this custom conversion rule in place we can do further 
> improvements:
> * create our own sling-variant of "ConversionException" and make sure it is 
> thrown in all relevant cases (on conversion, on property accesS) instead of 
> the built-in one from the conversion service
> * support nested configurations and nested configuration lists - when access 
> to a subresource is detected (does currently not work, valuemap returns null) 
> adapt the subresource to valuemap and convert it.



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

[jira] [Updated] (SLING-5886) Sling Context-Aware Configuration - Initial Contribution

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-5886:
--
Fix Version/s: Context-Aware Configuration Impl 1.0.0
   Context-Aware Configuration SPI 1.0.0

> Sling Context-Aware Configuration - Initial Contribution
> 
>
> Key: SLING-5886
> URL: https://issues.apache.org/jira/browse/SLING-5886
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: Sling-9-ReleaseNotes, contextaware-config
> Fix For: Context-Aware Configuration API 1.0.0, Context-Aware 
> Configuration SPI 1.0.0, Context-Aware Configuration Impl 1.0.0
>
>
> as discussed in the mailing list (see [my post from april 
> 2016|http://apache-sling.73963.n3.nabble.com/RT-Use-cases-for-content-specific-configurations-in-Sling-amp-Contribution-td4060813.html])
>  i want to contribute the wcm.io Configuration parts that are not 
> AEM-specific.
> the current features of wcm.io Configuration are described here: 
> http://wcm.io/config/
> the main goal is to support "context-specific" configuration, that means 
> configuration that is different for different content paths (e.g. sites, 
> tenants).
> during the contribution some changes and refactorings are required/planned, 
> e.g.:
> * remove some dependencies to wcm.io build environment, Guava and others
> * remove the "application" distinction currently part of wcm.io Configuration 
> in favor or a more path-based distinction
> * refactor the user-faced configuration API to further simplify it and 
> support OSGi R6-style annotation classed for typed configuration access
> _Update: as discussed at http://sling.markmail.org/thread/ka3ewlswfgjy7rpu 
> the name of this new module is Context-Aware Configuration_



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

[jira] [Updated] (SLING-6018) Use Java 7 as the base for contextaware configurations

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-6018:
--
Fix Version/s: (was: Context-Aware Configuration API 1.0.0)
   Context-Aware Configuration Impl 1.0.0

> Use Java 7 as the base for contextaware configurations
> --
>
> Key: SLING-6018
> URL: https://issues.apache.org/jira/browse/SLING-6018
> Project: Sling
>  Issue Type: Task
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration Impl 1.0.0
>
>
> As this feature might also be interesting for existing applications we should 
> use Java 7 as the base



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

[jira] [Updated] (SLING-6016) Context-Aware Config: Support adapting configuration resources

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-6016:
--
Fix Version/s: Context-Aware Configuration Impl 1.0.0

> Context-Aware Config: Support adapting configuration resources
> --
>
> Key: SLING-6016
> URL: https://issues.apache.org/jira/browse/SLING-6016
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Context-Aware Configuration API 1.0.0
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration API 1.0.0, Context-Aware 
> Configuration Impl 1.0.0
>
>
> carsten introduced in rev. 1758332 a new feature:
> the ConfigurationBuilder#as method should also support adapting to any other 
> object for which a sling adapter manager exits, not only to configuration 
> annotation classes.
> this is currently not reflected in the API, and unit tests are missing.



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

[jira] [Updated] (SLING-6060) Context-Aware Config: Configuration property override providers

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-6060:
--
Fix Version/s: (was: Context-Aware Configuration API 1.1.0)
   Context-Aware Configuration Impl 1.1.0
   Context-Aware Configuration SPI 1.1.0

> Context-Aware Config: Configuration property override providers
> ---
>
> Key: SLING-6060
> URL: https://issues.apache.org/jira/browse/SLING-6060
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Stefan Seifert
>Priority: Minor
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration SPI 1.1.0, Context-Aware 
> Configuration Impl 1.1.0
>
>
> add support similar to http://wcm.io/config/core/override-providers.html
> this is esp. useful for test/QA systems where a bunch of content and 
> configuration packages are imported from the production system, and only a 
> few of them need to be overwritten e.g. ip addresses, host names.
> these override providers should not be active by default. perhaps they should 
> go into a separate package - but we need the SPI for them in the core 
> implementation.
> this is somewhat related to SLING-6058
> information about overriding that is in place should be provided in the 
> Configuration Management API (ConfigurationManager) as well.



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

[jira] [Updated] (SLING-6115) Context-Aware Config: Web Console Plugin

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-6115:
--
Fix Version/s: (was: Context-Aware Configuration API 1.1.0)
   Context-Aware Configuration Impl 1.1.0

> Context-Aware Config: Web Console Plugin
> 
>
> Key: SLING-6115
> URL: https://issues.apache.org/jira/browse/SLING-6115
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Priority: Minor
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration Impl 1.1.0
>
>
> with the first implementation prototype a web console plugin was included 
> which can be used to test/debug configuration resource resolution.
> it was not maintained properly during all the refactoring and new features 
> that were added since then, thus is quite broken currently.
> the web console plugin has to be refactored and fixed, and perhaps enhanced 
> to support the new features as well.



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

[jira] [Updated] (SLING-6137) Context-Aware Config: Configuration Manager - Support resource collection and property inheritance

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-6137:
--
Fix Version/s: (was: Context-Aware Configuration API 1.1.0)
   Context-Aware Configuration Impl 1.1.0

> Context-Aware Config: Configuration Manager - Support resource collection and 
> property inheritance
> --
>
> Key: SLING-6137
> URL: https://issues.apache.org/jira/browse/SLING-6137
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Stefan Seifert
>Priority: Minor
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration Impl 1.1.0
>
>
> the ConfigurationManager interface that is part of the "management API" 
> dedicated for tooling support like configuration editors should support 
> providing information about inherited configuration data (resource 
> collections, properties) as well to be able to visualize this information.
> this may be usable for a configuration editor and the web console 
> (SLING-6115) as well.



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

[jira] [Updated] (SLING-6155) Context-Aware Config: Integration Test unstable on Apache Jenkins

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-6155:
--
Fix Version/s: (was: Context-Aware Configuration API 1.1.0)
   Context-Aware Configuration Impl 1.1.0

> Context-Aware Config: Integration Test unstable on Apache Jenkins
> -
>
> Key: SLING-6155
> URL: https://issues.apache.org/jira/browse/SLING-6155
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Stefan Seifert
>Priority: Minor
>  Labels: contextaware-config, integration-test
> Fix For: Context-Aware Configuration Impl 1.1.0
>
>
> the integration tests for context-aware config are currently flaky for java 
> 1.7 (but run smooth with java 1.8). i cannot reproduce the problem when 
> running them locally with java 1.7.
> example: 
> https://builds.apache.org/job/sling-contrib-extensions-contextaware-config-integration-tests-1.7/11/console
> seems to be a startup racing condition with getting the resource 
> resolver/root resource.
> {noformat}
> Results :
> Tests in error: 
>   AdaptToConfigClassIT.setUp:54 » IllegalState Cannot read root resource
>   ConfigurationManagerIT.setUp:69 » IllegalState Cannot read root resource
>   ConfigurationManagerIT.setUp:69 » IllegalState Cannot read root resource
>   ConfigurationManagerIT.setUp:69 » IllegalState Cannot read root resource
>   ConfigurationManagerIT.setUp:69 » IllegalState Cannot read root resource
> org.apache.sling.contextaware.config.it.ConfigurationResolverConfigClassIT.testExistingConfig(org.apache.sling.contextaware.config.it.ConfigurationResolverConfigClassIT)
>   Run 1: ConfigurationResolverConfigClassIT.setUp:53 » IllegalState unable to 
> get a ser...
>   Run 2: ConfigurationResolverConfigClassIT.tearDown:59 » NullPointer
> org.apache.sling.contextaware.config.it.ConfigurationResolverConfigClassIT.testNonExistingConfig(org.apache.sling.contextaware.config.it.ConfigurationResolverConfigClassIT)
>   Run 1: ConfigurationResolverConfigClassIT.setUp:53 » IllegalState unable to 
> get a ser...
>   Run 2: ConfigurationResolverConfigClassIT.tearDown:59 » NullPointer
> org.apache.sling.contextaware.config.it.ConfigurationResolverValueMapIT.testExistingConfig(org.apache.sling.contextaware.config.it.ConfigurationResolverValueMapIT)
>   Run 1: ConfigurationResolverValueMapIT.setUp:53 » IllegalState unable to 
> get a servic...
>   Run 2: ConfigurationResolverValueMapIT.tearDown:59 » NullPointer
> org.apache.sling.contextaware.config.it.ConfigurationResolverValueMapIT.testNonExistingConfig(org.apache.sling.contextaware.config.it.ConfigurationResolverValueMapIT)
>   Run 1: ConfigurationResolverValueMapIT.setUp:53 » IllegalState unable to 
> get a servic...
>   Run 2: ConfigurationResolverValueMapIT.tearDown:59 » NullPointer
> {noformat}



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

[jira] [Commented] (SLING-5827) HealthCheckMetadata wrongly assumes (String) SERVICE_PID

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-5827:
--

[~kwin]  [~cziegeler]'s changes for SLING-5839 fixed it to use SERVICE_ID 
instead of SERVICE_PID (although the SERVICE_PID is still used to derive a more 
speaking HC name if available). Generally it's best to explicitly set the 
service property "hc.name" (the use of SERVICE_ID/SERVICE_PID in 
getHealthCheckTitle() is only a fallback mechanism)

> HealthCheckMetadata wrongly assumes (String) SERVICE_PID 
> -
>
> Key: SLING-5827
> URL: https://issues.apache.org/jira/browse/SLING-5827
> Project: Sling
>  Issue Type: Bug
>  Components: Health Check
>Affects Versions: Health Check Core 1.2.4
>Reporter: Ivo Leitão
>Assignee: Bertrand Delacretaz
>Priority: Critical
> Fix For: Health Check Core 1.2.6
>
>
> I'm getting a classcastexception in the healthcheck component. This is 
> happenning only for my components (don't know why :-S).
> I have looked at the source code and in my case at the 
> AsyncHelthCheckExecutor the code passes the lines bellow
> {code:title=AsyncHelthCheckExecutor.java|borderStyle=solid}
> ServiceReference serviceReference = event.getServiceReference();
> final boolean isHealthCheck = 
> serviceReference.isAssignableTo(bundleContext.getBundle(), 
> HealthCheck.class.getName());
> if (isHealthCheck) {
> // True at my case
> }
> {code}
> Later in the method getHealthCheckTitle of the class HealthCheckMetadata at 
> the line bellow:
> {code:title=HealthCheckMetadata.java|borderStyle=solid}
>  if (StringUtils.isBlank(name)) {
> name = (String) ref.getProperty(Constants.SERVICE_PID);
> }
> {code}
> ref.getProperty(Constants.SERVICE_PID) is returning an ArrayList and I have 
> the stacktrace bellow as a result
> {code:title=Stacktrace|borderStyle=solid}
> java.lang.ClassCastException: java.util.ArrayList cannot be cast to 
> java.lang.String
>   at 
> org.apache.sling.hc.util.HealthCheckMetadata.getHealthCheckTitle(HealthCheckMetadata.java:146)
>   at 
> org.apache.sling.hc.util.HealthCheckMetadata.(HealthCheckMetadata.java:53)
>   at 
> org.apache.sling.hc.core.impl.executor.AsyncHealthCheckExecutor.serviceChanged(AsyncHealthCheckExecutor.java:114)
>   at 
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:991)
>   at 
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:839)
>   at 
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:546)
>   at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4557)
>   at org.apache.felix.framework.Felix.registerService(Felix.java:3549)
>   at 
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348)
>   at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:869)
>   at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:857)
>   at 
> org.apache.felix.scr.impl.manager.RegistrationManager.changeRegistration(RegistrationManager.java:133)
>   at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:915)
>   at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:715)
>   at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.enable(AbstractComponentManager.java:399)
>   at 
> org.apache.felix.scr.impl.config.ConfigurableComponentHolder.enableComponents(ConfigurableComponentHolder.java:676)
>   at 
> org.apache.felix.scr.impl.BundleComponentActivator.initialEnable(BundleComponentActivator.java:339)
>   at 
> org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:360)
>   at org.apache.felix.scr.impl.Activator.access$000(Activator.java:53)
>   at 
> org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:260)
>   at 
> org.apache.felix.utils.extender.AbstractExtender.createExtension(AbstractExtender.java:259)
>   at 
> org.apache.felix.utils.extender.AbstractExtender.modifiedBundle(AbstractExtender.java:232)
>   at 
> org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:482)
>   at 
> org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:415)
>   at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232)
>   at 
> org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444)
>   at 
> 

[jira] [Resolved] (SLING-6157) Context-Aware Config: Change java package name to o.a.s.caconfig

[Stefan Seifert (JIRA)]

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

Stefan Seifert resolved SLING-6157.
---
Resolution: Fixed

Completed: At revision: 1764966  


> Context-Aware Config: Change java package name to o.a.s.caconfig
> 
>
> Key: SLING-6157
> URL: https://issues.apache.org/jira/browse/SLING-6157
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Context-Aware Configuration 1.0.0
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Minor
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> change the java package names from {{org.apache.sling.contextaware.config}} 
> to {{org.apache.sling.caconfig}}.
> see discussion 
> https://lists.apache.org/thread.html/844a6e56c5b5020106d145edc7fd9faa721642b2c905987c81a1b548@%3Cdev.sling.apache.org%3E



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

Re: [context-aware config] java package name

[Chetan Mehrotra]

On Sat, Oct 15, 2016 at 2:49 AM, Stefan Seifert  wrote:
> ok, let's take o.a.s.caconfig - it's short and still unique

+1

Chetan Mehrotra

RE: [context-aware config] java package name

[Stefan Seifert]

ok, let's take o.a.s.caconfig - it's short and still unique

-> https://issues.apache.org/jira/browse/SLING-6157

stefan

>-Original Message-
>From: Georg Henzler [mailto:ghenz...@apache.org]
>Sent: Friday, October 14, 2016 10:55 PM
>To: dev@sling.apache.org
>Subject: Re: [context-aware config] java package name
>
>
>> just removing the ".".
>
>+1 for removing the dot (if it was to be kept, at least it would have to
>be "o.a.s.config.contextaware" instead of "o.a.s.contextaware.config" to
>be a meaningful hierarchy).
>
>regarding d) other proposals:
>
>As o.a.s.contextawareconfig gets fairly long, using the brief
>"o.a.s.caconfig" could be better. Although a little bit cryptic at
>first, it still clearly shows that it is about a configuration mechanism
>and people will quickly get used to what "ca" means. Also "caconfig"
>will be fairly unique when googling it.
>
>-Georg

[jira] [Created] (SLING-6157) Context-Aware Config: Change java package name to o.a.s.caconfig

[Stefan Seifert (JIRA)]

Stefan Seifert created SLING-6157:
-

 Summary: Context-Aware Config: Change java package name to 
o.a.s.caconfig
 Key: SLING-6157
 URL: https://issues.apache.org/jira/browse/SLING-6157
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Context-Aware Configuration 1.0.0
Reporter: Stefan Seifert
Assignee: Stefan Seifert
Priority: Minor
 Fix For: Context-Aware Configuration 1.0.0


change the java package names from {{org.apache.sling.contextaware.config}} to 
{{org.apache.sling.caconfig}}.

see discussion 
https://lists.apache.org/thread.html/844a6e56c5b5020106d145edc7fd9faa721642b2c905987c81a1b548@%3Cdev.sling.apache.org%3E



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

Re: [context-aware config] java package name

[Georg Henzler]

just removing the ".".


+1 for removing the dot (if it was to be kept, at least it would have to 
be "o.a.s.config.contextaware" instead of "o.a.s.contextaware.config" to 
be a meaningful hierarchy).


regarding d) other proposals:

As o.a.s.contextawareconfig gets fairly long, using the brief 
"o.a.s.caconfig" could be better. Although a little bit cryptic at 
first, it still clearly shows that it is about a configuration mechanism 
and people will quickly get used to what "ca" means. Also "caconfig" 
will be fairly unique when googling it.


-Georg

RE: [context-aware config] java package name

[Stefan Seifert]

>Having an adjective as root package is rather strange and I'm not aware of
>one
>at Sling. If we really want to have context aware[1] in the package name
>I'm
>in favor of o.a.s.contextawareconfig.

than it would be

o.a.s.contextawareconfig  => "highlevel configuration API"
o.a.s.contextawareconfig.resource  => "lowlevel resource API"
o.a.s.contextawareconfig.annotation => java annotations

just removing the ".".

stefan

RE: [context-aware config] java package name

[Oliver Lietz]

On Friday 14 October 2016 14:20:06 Stefan Seifert wrote:
> >I see the point to distinguish between "highlevel configuration API" and
> >"lowlevel resource API" but even highlevel API is build around resources
> >(as
> >everything in Sling). Maybe there is another way/name to make the
> >difference
> >obvious.
> >
> >The "context-aware config" name still sounds too bulky to me but YMMV.
> >
> >1.) o.a.s.configuration (it will become *THE* way to do configuration in
> >Sling/AEM besides *OSGi* configurations)
> >
> >2.) o.a.s.resource.configuration (it's build around resources, how to diff
> >low
> >from high has to be solved)
> >
> >3.) o.a.s.contextawareconfig
> 
> @oliver: can you also live with carstens proposal:
> 
> o.a.s.contextaware.config, o.a.s.contextaware.resource,
> o.a.s.contextaware.config.annotation
> 
> this makes sense to me and gives the dot between contextaware and config a
> meaning.
> 
> your point seems to be mainly getting rid of the "contextaware" part, but
> this is what's all about. otherwise we have to restart the whole naming
> process again, but i think it's not worth the effort.

Having an adjective as root package is rather strange and I'm not aware of one 
at Sling. If we really want to have context aware[1] in the package name I'm 
in favor of o.a.s.contextawareconfig.

Regards,
O.

[1] https://en.wikipedia.org/wiki/Context_awareness

> stefan

[jira] [Commented] (SLING-3558) Updating of sling:VanityPath mixins is ignored by sling resource resolution

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-3558:
-

[~asanso] I think the handling of vanity paths is slightly broken in MapEntries.
On initial startup, a query is performed, explicitely searching for resources 
with the mixin set and only those are used
During runtime, the mixin is not checked at all anymore - so if a new node with 
the correct property - but without the mixin - is added, it gets picked up.
Therefore after removal of the mixin, the vanity path is still used.

I think we should change the implementation to use the vanitypath property on 
any resource regardless if the mixin is set, other resource providers don't 
have the concept of mixins

> 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
>Priority: Critical
>
> 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] [Resolved] (SLING-6153) Improve MapEntries implementation

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-6153.
-
Resolution: Fixed

> 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] [Commented] (SLING-3558) Updating of sling:VanityPath mixins is ignored by sling resource resolution

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-3558:
-

I've enabled and adjusted the test in rev 1764935

> 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
>Priority: Critical
>
> 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] [Commented] (SLING-6153) Improve MapEntries implementation

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6153:
-

Finished the clean up of the implementation in rev 1764933, all tests are 
enabled again and pass.

> 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] [Created] (SLING-6156) JsUseProvider should use the sling-scripting service user for solving scripting dependencies

[Radu Cotescu (JIRA)]

Radu Cotescu created SLING-6156:
---

 Summary: JsUseProvider should use the sling-scripting service user 
for solving scripting dependencies
 Key: SLING-6156
 URL: https://issues.apache.org/jira/browse/SLING-6156
 Project: Sling
  Issue Type: Bug
  Components: Scripting
Affects Versions: Scripting HTL JS Use Provider 1.0.12
Reporter: Radu Cotescu
Assignee: Radu Cotescu
 Fix For: Scripting HTL JS Use Provider 1.0.16


In SLING-5334 the {{JsUseProvider}} was modified for better handling of script 
resolution for components using inheritance. However, the resolver that's 
currently used for solving these dependencies is not the correct one, since 
{{SlingScript}} resources will always use the request resource resolver.

The fix is to switch to a resource resolver backed by the {{sling-scripting}} 
service user.



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

[jira] [Updated] (SLING-6156) The JsUseProvider should use the sling-scripting service user for solving scripting dependencies

[Radu Cotescu (JIRA)]

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

Radu Cotescu updated SLING-6156:

Summary: The JsUseProvider should use the sling-scripting service user for 
solving scripting dependencies  (was: JsUseProvider should use the 
sling-scripting service user for solving scripting dependencies)

> The JsUseProvider should use the sling-scripting service user for solving 
> scripting dependencies
> 
>
> Key: SLING-6156
> URL: https://issues.apache.org/jira/browse/SLING-6156
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting HTL JS Use Provider 1.0.12
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting HTL JS Use Provider 1.0.16
>
>
> In SLING-5334 the {{JsUseProvider}} was modified for better handling of 
> script resolution for components using inheritance. However, the resolver 
> that's currently used for solving these dependencies is not the correct one, 
> since {{SlingScript}} resources will always use the request resource resolver.
> The fix is to switch to a resource resolver backed by the {{sling-scripting}} 
> service user.



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

Re: svn commit: r1764891 - /sling/trunk/launchpad/builder/set-sling-snapshots.sh

[Bertrand Delacretaz]

On Fri, Oct 14, 2016 at 4:12 PM, Robert Munteanu  wrote:
> ...Seems the rat plugin is being pedantic and looking for a license header..

Ah sorry about that, fixed now!

-Bertrand

[jira] [Commented] (SLING-6155) Context-Aware Config: Integration Test unstable on Apache Jenkins

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6155:
---

i switched to launchpad 9-SNAPSHOT and deactivated the java 1.7 integration 
test (via create_jobs.groovy).

still fails with java 1.8 - this time with timeouts
https://builds.apache.org/job/sling-contrib-extensions-contextaware-config-integration-tests-1.8/10/console

not reproducible locally.

> Context-Aware Config: Integration Test unstable on Apache Jenkins
> -
>
> Key: SLING-6155
> URL: https://issues.apache.org/jira/browse/SLING-6155
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Stefan Seifert
>Priority: Minor
>  Labels: contextaware-config, integration-test
> Fix For: Context-Aware Configuration 1.1.0
>
>
> the integration tests for context-aware config are currently flaky for java 
> 1.7 (but run smooth with java 1.8). i cannot reproduce the problem when 
> running them locally with java 1.7.
> example: 
> https://builds.apache.org/job/sling-contrib-extensions-contextaware-config-integration-tests-1.7/11/console
> seems to be a startup racing condition with getting the resource 
> resolver/root resource.
> {noformat}
> Results :
> Tests in error: 
>   AdaptToConfigClassIT.setUp:54 » IllegalState Cannot read root resource
>   ConfigurationManagerIT.setUp:69 » IllegalState Cannot read root resource
>   ConfigurationManagerIT.setUp:69 » IllegalState Cannot read root resource
>   ConfigurationManagerIT.setUp:69 » IllegalState Cannot read root resource
>   ConfigurationManagerIT.setUp:69 » IllegalState Cannot read root resource
> org.apache.sling.contextaware.config.it.ConfigurationResolverConfigClassIT.testExistingConfig(org.apache.sling.contextaware.config.it.ConfigurationResolverConfigClassIT)
>   Run 1: ConfigurationResolverConfigClassIT.setUp:53 » IllegalState unable to 
> get a ser...
>   Run 2: ConfigurationResolverConfigClassIT.tearDown:59 » NullPointer
> org.apache.sling.contextaware.config.it.ConfigurationResolverConfigClassIT.testNonExistingConfig(org.apache.sling.contextaware.config.it.ConfigurationResolverConfigClassIT)
>   Run 1: ConfigurationResolverConfigClassIT.setUp:53 » IllegalState unable to 
> get a ser...
>   Run 2: ConfigurationResolverConfigClassIT.tearDown:59 » NullPointer
> org.apache.sling.contextaware.config.it.ConfigurationResolverValueMapIT.testExistingConfig(org.apache.sling.contextaware.config.it.ConfigurationResolverValueMapIT)
>   Run 1: ConfigurationResolverValueMapIT.setUp:53 » IllegalState unable to 
> get a servic...
>   Run 2: ConfigurationResolverValueMapIT.tearDown:59 » NullPointer
> org.apache.sling.contextaware.config.it.ConfigurationResolverValueMapIT.testNonExistingConfig(org.apache.sling.contextaware.config.it.ConfigurationResolverValueMapIT)
>   Run 1: ConfigurationResolverValueMapIT.setUp:53 » IllegalState unable to 
> get a servic...
>   Run 2: ConfigurationResolverValueMapIT.tearDown:59 » NullPointer
> {noformat}



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

RE: [VOTE] Release Apache Sling Scripting HTL Java Compiler 1.0.4, Apache Sling Scripting HTL Engine 1.0.24

[Stefan Seifert]

+1

RE: [VOTE] Release Apache Sling Parent 29

[Stefan Seifert]

+1 

RE: [context-aware config] java package name

[Stefan Seifert]

>I see the point to distinguish between "highlevel configuration API" and
>"lowlevel resource API" but even highlevel API is build around resources
>(as
>everything in Sling). Maybe there is another way/name to make the
>difference
>obvious.
>
>The "context-aware config" name still sounds too bulky to me but YMMV.
>
>1.) o.a.s.configuration (it will become *THE* way to do configuration in
>Sling/AEM besides *OSGi* configurations)
>
>2.) o.a.s.resource.configuration (it's build around resources, how to diff
>low
>from high has to be solved)
>
>3.) o.a.s.contextawareconfig

@oliver: can you also live with carstens proposal:

o.a.s.contextaware.config, o.a.s.contextaware.resource,
o.a.s.contextaware.config.annotation

this makes sense to me and gives the dot between contextaware and config a 
meaning.

your point seems to be mainly getting rid of the "contextaware" part, but this 
is what's all about.
otherwise we have to restart the whole naming process again, but i think it's 
not worth the effort.

stefan

Re: svn commit: r1764891 - /sling/trunk/launchpad/builder/set-sling-snapshots.sh

[Robert Munteanu]

Hi Bertrand,

On Fri, 2016-10-14 at 13:28 +, bdelacre...@apache.org wrote:
> +#!/bin/bash
> +#
> +# EXPERIMENTAL script to remove versions from the
> +# provisioning model lines of Sling artifacts.
> +#

Seems the rat plugin is being pedantic and looking for a license header
:-)

I'm not 100% sure one is required here, but you may want to either add
one or exclude this script from the rat checks.

Robert

[jira] [Resolved] (SLING-6099) NPE in StartupFilterImpl if pathInfo is null

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz resolved SLING-6099.

Resolution: Fixed

Fixed by http://svn.apache.org/r1763407

> NPE in StartupFilterImpl if pathInfo is null
> 
>
> Key: SLING-6099
> URL: https://issues.apache.org/jira/browse/SLING-6099
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
>
> StartupFilterImpl can throw an NPE if 
> {{((HttpServletRequest)request).getPathInfo()}} returns null



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

[jira] [Updated] (SLING-6155) Context-Aware Config: Integration Test unstable on Apache Jenkins

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-6155:
--
Summary: Context-Aware Config: Integration Test unstable on Apache Jenkins  
(was: Context-Aware Config: Integration Test with Java 1.7 unstable)

oh, it happens with Java 1.8 as well
https://builds.apache.org/job/sling-contrib-extensions-contextaware-config-integration-tests-1.8/7/console

> Context-Aware Config: Integration Test unstable on Apache Jenkins
> -
>
> Key: SLING-6155
> URL: https://issues.apache.org/jira/browse/SLING-6155
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Stefan Seifert
>Priority: Minor
>  Labels: contextaware-config, integration-test
> Fix For: Context-Aware Configuration 1.1.0
>
>
> the integration tests for context-aware config are currently flaky for java 
> 1.7 (but run smooth with java 1.8). i cannot reproduce the problem when 
> running them locally with java 1.7.
> example: 
> https://builds.apache.org/job/sling-contrib-extensions-contextaware-config-integration-tests-1.7/11/console
> seems to be a startup racing condition with getting the resource 
> resolver/root resource.
> {noformat}
> Results :
> Tests in error: 
>   AdaptToConfigClassIT.setUp:54 » IllegalState Cannot read root resource
>   ConfigurationManagerIT.setUp:69 » IllegalState Cannot read root resource
>   ConfigurationManagerIT.setUp:69 » IllegalState Cannot read root resource
>   ConfigurationManagerIT.setUp:69 » IllegalState Cannot read root resource
>   ConfigurationManagerIT.setUp:69 » IllegalState Cannot read root resource
> org.apache.sling.contextaware.config.it.ConfigurationResolverConfigClassIT.testExistingConfig(org.apache.sling.contextaware.config.it.ConfigurationResolverConfigClassIT)
>   Run 1: ConfigurationResolverConfigClassIT.setUp:53 » IllegalState unable to 
> get a ser...
>   Run 2: ConfigurationResolverConfigClassIT.tearDown:59 » NullPointer
> org.apache.sling.contextaware.config.it.ConfigurationResolverConfigClassIT.testNonExistingConfig(org.apache.sling.contextaware.config.it.ConfigurationResolverConfigClassIT)
>   Run 1: ConfigurationResolverConfigClassIT.setUp:53 » IllegalState unable to 
> get a ser...
>   Run 2: ConfigurationResolverConfigClassIT.tearDown:59 » NullPointer
> org.apache.sling.contextaware.config.it.ConfigurationResolverValueMapIT.testExistingConfig(org.apache.sling.contextaware.config.it.ConfigurationResolverValueMapIT)
>   Run 1: ConfigurationResolverValueMapIT.setUp:53 » IllegalState unable to 
> get a servic...
>   Run 2: ConfigurationResolverValueMapIT.tearDown:59 » NullPointer
> org.apache.sling.contextaware.config.it.ConfigurationResolverValueMapIT.testNonExistingConfig(org.apache.sling.contextaware.config.it.ConfigurationResolverValueMapIT)
>   Run 1: ConfigurationResolverValueMapIT.setUp:53 » IllegalState unable to 
> get a servic...
>   Run 2: ConfigurationResolverValueMapIT.tearDown:59 » NullPointer
> {noformat}



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

[jira] [Created] (SLING-6155) Context-Aware Config: Integration Test with Java 1.7 unstable

[Stefan Seifert (JIRA)]

Stefan Seifert created SLING-6155:
-

 Summary: Context-Aware Config: Integration Test with Java 1.7 
unstable
 Key: SLING-6155
 URL: https://issues.apache.org/jira/browse/SLING-6155
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Reporter: Stefan Seifert
Priority: Minor
 Fix For: Context-Aware Configuration 1.1.0


the integration tests for context-aware config are currently flaky for java 1.7 
(but run smooth with java 1.8). i cannot reproduce the problem when running 
them locally with java 1.7.

example: 
https://builds.apache.org/job/sling-contrib-extensions-contextaware-config-integration-tests-1.7/11/console

seems to be a startup racing condition with getting the resource resolver/root 
resource.

{noformat}
Results :

Tests in error: 
  AdaptToConfigClassIT.setUp:54 » IllegalState Cannot read root resource
  ConfigurationManagerIT.setUp:69 » IllegalState Cannot read root resource
  ConfigurationManagerIT.setUp:69 » IllegalState Cannot read root resource
  ConfigurationManagerIT.setUp:69 » IllegalState Cannot read root resource
  ConfigurationManagerIT.setUp:69 » IllegalState Cannot read root resource
org.apache.sling.contextaware.config.it.ConfigurationResolverConfigClassIT.testExistingConfig(org.apache.sling.contextaware.config.it.ConfigurationResolverConfigClassIT)
  Run 1: ConfigurationResolverConfigClassIT.setUp:53 » IllegalState unable to 
get a ser...
  Run 2: ConfigurationResolverConfigClassIT.tearDown:59 » NullPointer

org.apache.sling.contextaware.config.it.ConfigurationResolverConfigClassIT.testNonExistingConfig(org.apache.sling.contextaware.config.it.ConfigurationResolverConfigClassIT)
  Run 1: ConfigurationResolverConfigClassIT.setUp:53 » IllegalState unable to 
get a ser...
  Run 2: ConfigurationResolverConfigClassIT.tearDown:59 » NullPointer

org.apache.sling.contextaware.config.it.ConfigurationResolverValueMapIT.testExistingConfig(org.apache.sling.contextaware.config.it.ConfigurationResolverValueMapIT)
  Run 1: ConfigurationResolverValueMapIT.setUp:53 » IllegalState unable to get 
a servic...
  Run 2: ConfigurationResolverValueMapIT.tearDown:59 » NullPointer

org.apache.sling.contextaware.config.it.ConfigurationResolverValueMapIT.testNonExistingConfig(org.apache.sling.contextaware.config.it.ConfigurationResolverValueMapIT)
  Run 1: ConfigurationResolverValueMapIT.setUp:53 » IllegalState unable to get 
a servic...
  Run 2: ConfigurationResolverValueMapIT.tearDown:59 » NullPointer
{noformat}



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

[jira] [Resolved] (SLING-5800) Release o.a.s.launchpad.integration-tests

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz resolved SLING-5800.

Resolution: Fixed

Marking this fixed, release has been done

> Release o.a.s.launchpad.integration-tests
> -
>
> Key: SLING-5800
> URL: https://issues.apache.org/jira/browse/SLING-5800
> Project: Sling
>  Issue Type: Task
>  Components: Testing
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
>
> We need to release the integration-tests module and this probably means 
> releasing a set of other modules, as it depends on a number of snapshots:
> {code}
> mvn dependency:tree | grep SNAPS
> [INFO] Building Apache Sling Integration Tests 1.0.1-SNAPSHOT
> [INFO] 
> org.apache.sling:org.apache.sling.launchpad.integration-tests:jar:1.0.1-SNAPSHOT
> [INFO] +- 
> org.apache.sling:org.apache.sling.commons.testing:jar:2.0.25-SNAPSHOT:compile
> [INFO] +- 
> org.apache.sling:org.apache.sling.junit.remote:jar:1.0.11-SNAPSHOT:compile
> [INFO] +- 
> org.apache.sling:org.apache.sling.junit.teleporter:jar:1.0.7-SNAPSHOT:compile
> [INFO] +- 
> org.apache.sling:org.apache.sling.launchpad.test-services:jar:2.0.9-SNAPSHOT:compile
> [INFO] +- org.apache.sling:org.apache.sling.jcr.api:jar:2.3.1-SNAPSHOT:compile
> {code}



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

Re: Launchpad stable and launchpad unstable

[Carsten Ziegeler]

Bertrand Delacretaz wrote
> On Mon, Oct 3, 2016 at 3:20 PM, Robert Munteanu  wrote:
>> ...If we make building an unstable launchpad really simple, e.g. an addition
>> profile or a mojo property, I don't think we lose anything...
> 
> I've committed an experimental script [1] which modifies the
> launchpad/builder provisioning model files to remove the version
> numbers for all Sling artifacts. See comments in the script for
> details (and enjoy the sed regexp ;-)
> 
> When doing so, the Slingstart plugin uses the latest snapshot instead
> of a specified version, IIUC.
> 
> The script doesn't fully work yet (see comments in the script -
> patches or hints welcome) but once it does the process for running our
> integration tests on this all-snapshots launchpad would be:
> 
> 1) Run this script in launchpad/builder, build and deploy that, with a
> specific classifier or other marker
> 2) Run the launchpad/testing build using that special launchpad jar
> 3) Revert the code changes caused by step 1), unless working in a
> throwaway folder
> 
> Would that work for you guys?
> 
Sorry I already replied to your commit as I didn't see this mail :(

I think a script is fine and thanks for taking it up.
My initial thoughts were to do this in the slingstart maven plugin
This would give a little bit more control - if required, like enabling
snapshots only for a single feature or something. Or having a blacklist.

But maybe that's not needed anyways

Carsten

 

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

[jira] [Resolved] (SLING-6154) Context-Aware Config: Use camel case for property names

[Stefan Seifert (JIRA)]

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

Stefan Seifert resolved SLING-6154.
---
Resolution: Fixed

Completed: At revision: 1764896  

also updated the docs

> Context-Aware Config: Use camel case for property names
> ---
>
> Key: SLING-6154
> URL: https://issues.apache.org/jira/browse/SLING-6154
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Minor
>  Labels: contextaware-config
>
> to be more consistent with other parts of sling we should use camelcase names 
> like
> {noformat}
> sling:configRef
> sling:configCollectionInherit
> sling:configPropertyInherit  
> {noformat}



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

Re: svn commit: r1764891 - /sling/trunk/launchpad/builder/set-sling-snapshots.sh

[Carsten Ziegeler]

Thanks for taking this up!

I'm just wondering if this wouldn't be something we do in the slingstart
maven plugin instead?
But if the script works, that's fine as well

Regards
Carsten

Bertrand Delacretaz wrote
> Author: bdelacretaz
> Date: Fri Oct 14 13:28:51 2016
> New Revision: 1764891
> 
> URL: http://svn.apache.org/viewvc?rev=1764891=rev
> Log:
> Experimental script to generate an all-snapshots launchpad, for integration 
> tests
> 
> Added:
> sling/trunk/launchpad/builder/set-sling-snapshots.sh   (with props)
> 
> Added: sling/trunk/launchpad/builder/set-sling-snapshots.sh
> URL: 
> http://svn.apache.org/viewvc/sling/trunk/launchpad/builder/set-sling-snapshots.sh?rev=1764891=auto
> ==
> --- sling/trunk/launchpad/builder/set-sling-snapshots.sh (added)
> +++ sling/trunk/launchpad/builder/set-sling-snapshots.sh Fri Oct 14 13:28:51 
> 2016
> @@ -0,0 +1,41 @@
> +#!/bin/bash
> +#
> +# EXPERIMENTAL script to remove versions from the
> +# provisioning model lines of Sling artifacts.
> +#
> +# Meant to create an alternate version of the Sling
> +# launchpad using all the latest snapshots, for 
> +# integration testing in parallel with a stable
> +# versions that uses releases.
> +#
> +# This script modifies provisioning model files under
> +# src/main/provisioning, the changes are NOT
> +# meant to be committed, just meant to build and
> +# deploy an "all snapshots" launchpad jar meant to
> +# be used by the launchpad/testing module.
> +#
> +# To verify the results use
> +# mvn dependency:resolve | grep org.apache.sling
> +#
> +# For some reason currently two modules are not resolved
> +# to snapshots although their versions are correctly removed
> +# in the provisioning model:
> +#
> +# mvn dependency:resolve | grep org.apache.sling | grep -v SNAPSHOT
> +# [INFO] --- maven-dependency-plugin:2.10:resolve (default-cli) @ 
> org.apache.sling.launchpad ---
> +# [INFO]
> org.apache.sling:org.apache.sling.resourceresolver:jar:1.4.18:provided
> +# [INFO]org.apache.sling:org.apache.sling.i18n:jar:2.5.4:provided
> +#
> +
> +function removeSlingVersions() {
> + sed 
> 's/\(org.apache.sling\)\/\(org.apache.sling.*\)\/.*/org.apache.sling\/\2/g' < 
> $1
> +}
> +
> +SRC="src/main/provisioning/*.txt"
> +echo "Removing Sling versions from provisioning model files under $SRC..."
> +for i in $SRC
> +do
> + TMP=/tmp/$ME_$$
> + removeSlingVersions $i > $TMP
> + mv $TMP $i
> +done
> \ No newline at end of file
> 
> Propchange: sling/trunk/launchpad/builder/set-sling-snapshots.sh
> --
> svn:executable = *
> 
> 
> 


 

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

Re: Launchpad stable and launchpad unstable

[Bertrand Delacretaz]

On Mon, Oct 3, 2016 at 3:20 PM, Robert Munteanu  wrote:
>...If we make building an unstable launchpad really simple, e.g. an addition
> profile or a mojo property, I don't think we lose anything...

I've committed an experimental script [1] which modifies the
launchpad/builder provisioning model files to remove the version
numbers for all Sling artifacts. See comments in the script for
details (and enjoy the sed regexp ;-)

When doing so, the Slingstart plugin uses the latest snapshot instead
of a specified version, IIUC.

The script doesn't fully work yet (see comments in the script -
patches or hints welcome) but once it does the process for running our
integration tests on this all-snapshots launchpad would be:

1) Run this script in launchpad/builder, build and deploy that, with a
specific classifier or other marker
2) Run the launchpad/testing build using that special launchpad jar
3) Revert the code changes caused by step 1), unless working in a
throwaway folder

Would that work for you guys?

-Bertrand

(BTW the resulting launchpad with all snapshots doesn't start, might
be a good indicator that we need this!

[1] 
https://svn.apache.org/repos/asf/sling/trunk/launchpad/builder/set-sling-snapshots.sh

[jira] [Created] (SLING-6154) Context-Aware Config: Use camel case for property names

[Stefan Seifert (JIRA)]

Stefan Seifert created SLING-6154:
-

 Summary: Context-Aware Config: Use camel case for property names
 Key: SLING-6154
 URL: https://issues.apache.org/jira/browse/SLING-6154
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Stefan Seifert
Assignee: Stefan Seifert
Priority: Minor


to be more consistent with other parts of sling we should use camelcase names 
like

{noformat}
sling:configRef
sling:configCollectionInherit
sling:configPropertyInherit  
{noformat}



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

RE: [context-aware config] property names camel case?

[Stefan Seifert]

ok, will change this => ticket https://issues.apache.org/jira/browse/SLING-6154

stefan

>-Original Message-
>From: Konrad Windszus [mailto:konra...@gmx.de]
>Sent: Friday, October 14, 2016 1:14 PM
>To: dev@sling.apache.org
>Subject: Re: [context-aware config] property names camel case?
>
>I would also prefer camelcase.
>See other places in Sling like
>https://sling.apache.org/documentation/bundles/resource-merger.html
> or
>https://sling.apache.org/documentation/the-sling-engine/mappings-for-
>resource-resolution.html engine/mappings-for-resource-resolution.html>.
>
>> On 14 Oct 2016, at 13:04, Carsten Ziegeler  wrote:
>>
>> Stefan Seifert wrote
>>> in [1] oliver mentioned the usage of property names in the current
>implementation:
>>>
>>> sling:config-ref
>>> sling:config-collection-inherit
>>> sling:config-property-inherit
>>>
>>> should we use headless camel case instead? is this more consistent with
>the other parts of sling?
>>>
>>> sling:configRef
>>> sling:configCollectionInherit
>>> sling:configPropertyInherit
>>>
>>>
>> As mentioned as a response to Olli camel case would be more consistent.
>> So if it is not too much work, we should change it. Otherwise I think it
>> is not that important.
>>
>> Carsten
>>
>>
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
>>

Re: [context-aware config] java package name

[Oliver Lietz]

On Friday 14 October 2016 13:14:02 Carsten Ziegeler wrote:
> Stefan Seifert wrote
> 
> > in [1] oliver mentioned that the current java package name is not
> > consistent/not ideal.
> > 
> > currently wie use
> > o.a.s.contextaware.config  => "highlevel configuration API"
> > o.a.s.contextaware.config.resource  => "lowlevel resource API"
> > 
> > bertrand and myself noted that the package name should included
> > "contextaware" somewhere, using only org.apache.sling.configuration is
> > too generic/misleading.
> > 
> > so, what should we use?
> > 
> > a) keep o.a.s.contextaware.config + o.a.s.contextaware.config.resource
> > 
> > b) switch to o.a.s.contextawareconfig + o.a.s.contextawareconfig.resource
> > to get rid of the additional dot that is a bit inconsistent
> > 
> > c) switch to o.a.s.configuration + o.a.s.configuration.resource which is
> > misleading as it applies only to context-aware config
> > 
> > d) other proposals?
> > 
> > i hope we find a consensus in the next hours... or we just stick with a)
> 
> As noted in the other thread, my proposal would be:
> 
> o.a.s.contextaware.config, o.a.s.contextaware.resource,
> o.a.s.contextaware.config.annotation
> 
> So similar to a) but with moving resource one level down.
> 
> Just to make it more difficult to decide
> 
> a) or b) are good as well
> 
> The important point is that we don't use "configuration" as this is
> confusing and separate the resource part from the settings (config).

I see the point to distinguish between "highlevel configuration API" and 
"lowlevel resource API" but even highlevel API is build around resources (as 
everything in Sling). Maybe there is another way/name to make the difference 
obvious.

The "context-aware config" name still sounds too bulky to me but YMMV.

1.) o.a.s.configuration (it will become *THE* way to do configuration in 
Sling/AEM besides *OSGi* configurations)

2.) o.a.s.resource.configuration (it's build around resources, how to diff low 
from high has to be solved)

3.) o.a.s.contextawareconfig

Sorry for the noise.

O.

> Carsten

[jira] [Commented] (SLING-6004) JspScriptEngineFactory should move to new ResourceChangeListener API

[Rachit Kumar (JIRA)]

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

Rachit Kumar commented on SLING-6004:
-

[~cziegeler]

Please review the patch for the issue.  I have changed the path to '/' because 
the path is dynamically added upon bundles registration. 
I saw a similar fix in SLING-5999 : 
https://fisheye6.atlassian.com/changelog/sling?cs=1761721

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

[Rachit Kumar (JIRA)]

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

Rachit Kumar updated SLING-6004:

Attachment: patch.txt

> JspScriptEngineFactory should move to new ResourceChangeListener API  
> -
>
> Key: SLING-6004
> URL: https://issues.apache.org/jira/browse/SLING-6004
> Project: Sling
>  Issue Type: Task
>  Components: Scripting
>Reporter: Hanish Bansal
> Attachments: patch.txt
>
>
> org.apache.sling.scripting.jsp.JspScriptEngineFactory 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-5827) HealthCheckMetadata wrongly assumes (String) SERVICE_PID

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-5827:


[~bdelacretaz] Shouldn't this be rather fixed by relying on the SERVICE_ID 
instead 
(https://issues.apache.org/jira/browse/SLING-5828?focusedCommentId=15367537=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15367537)?

> HealthCheckMetadata wrongly assumes (String) SERVICE_PID 
> -
>
> Key: SLING-5827
> URL: https://issues.apache.org/jira/browse/SLING-5827
> Project: Sling
>  Issue Type: Bug
>  Components: Health Check
>Affects Versions: Health Check Core 1.2.4
>Reporter: Ivo Leitão
>Assignee: Bertrand Delacretaz
>Priority: Critical
> Fix For: Health Check Core 1.2.6
>
>
> I'm getting a classcastexception in the healthcheck component. This is 
> happenning only for my components (don't know why :-S).
> I have looked at the source code and in my case at the 
> AsyncHelthCheckExecutor the code passes the lines bellow
> {code:title=AsyncHelthCheckExecutor.java|borderStyle=solid}
> ServiceReference serviceReference = event.getServiceReference();
> final boolean isHealthCheck = 
> serviceReference.isAssignableTo(bundleContext.getBundle(), 
> HealthCheck.class.getName());
> if (isHealthCheck) {
> // True at my case
> }
> {code}
> Later in the method getHealthCheckTitle of the class HealthCheckMetadata at 
> the line bellow:
> {code:title=HealthCheckMetadata.java|borderStyle=solid}
>  if (StringUtils.isBlank(name)) {
> name = (String) ref.getProperty(Constants.SERVICE_PID);
> }
> {code}
> ref.getProperty(Constants.SERVICE_PID) is returning an ArrayList and I have 
> the stacktrace bellow as a result
> {code:title=Stacktrace|borderStyle=solid}
> java.lang.ClassCastException: java.util.ArrayList cannot be cast to 
> java.lang.String
>   at 
> org.apache.sling.hc.util.HealthCheckMetadata.getHealthCheckTitle(HealthCheckMetadata.java:146)
>   at 
> org.apache.sling.hc.util.HealthCheckMetadata.(HealthCheckMetadata.java:53)
>   at 
> org.apache.sling.hc.core.impl.executor.AsyncHealthCheckExecutor.serviceChanged(AsyncHealthCheckExecutor.java:114)
>   at 
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:991)
>   at 
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:839)
>   at 
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:546)
>   at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4557)
>   at org.apache.felix.framework.Felix.registerService(Felix.java:3549)
>   at 
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348)
>   at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:869)
>   at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:857)
>   at 
> org.apache.felix.scr.impl.manager.RegistrationManager.changeRegistration(RegistrationManager.java:133)
>   at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:915)
>   at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:715)
>   at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.enable(AbstractComponentManager.java:399)
>   at 
> org.apache.felix.scr.impl.config.ConfigurableComponentHolder.enableComponents(ConfigurableComponentHolder.java:676)
>   at 
> org.apache.felix.scr.impl.BundleComponentActivator.initialEnable(BundleComponentActivator.java:339)
>   at 
> org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:360)
>   at org.apache.felix.scr.impl.Activator.access$000(Activator.java:53)
>   at 
> org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:260)
>   at 
> org.apache.felix.utils.extender.AbstractExtender.createExtension(AbstractExtender.java:259)
>   at 
> org.apache.felix.utils.extender.AbstractExtender.modifiedBundle(AbstractExtender.java:232)
>   at 
> org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:482)
>   at 
> org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:415)
>   at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232)
>   at 
> org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444)
>   at 
> org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:916)
>   at 
> 

[jira] [Resolved] (SLING-5827) HealthCheckMetadata wrongly assumes (String) SERVICE_PID

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz resolved SLING-5827.

Resolution: Fixed

> HealthCheckMetadata wrongly assumes (String) SERVICE_PID 
> -
>
> Key: SLING-5827
> URL: https://issues.apache.org/jira/browse/SLING-5827
> Project: Sling
>  Issue Type: Bug
>  Components: Health Check
>Affects Versions: Health Check Core 1.2.4
>Reporter: Ivo Leitão
>Assignee: Bertrand Delacretaz
>Priority: Critical
> Fix For: Health Check Core 1.2.6
>
>
> I'm getting a classcastexception in the healthcheck component. This is 
> happenning only for my components (don't know why :-S).
> I have looked at the source code and in my case at the 
> AsyncHelthCheckExecutor the code passes the lines bellow
> {code:title=AsyncHelthCheckExecutor.java|borderStyle=solid}
> ServiceReference serviceReference = event.getServiceReference();
> final boolean isHealthCheck = 
> serviceReference.isAssignableTo(bundleContext.getBundle(), 
> HealthCheck.class.getName());
> if (isHealthCheck) {
> // True at my case
> }
> {code}
> Later in the method getHealthCheckTitle of the class HealthCheckMetadata at 
> the line bellow:
> {code:title=HealthCheckMetadata.java|borderStyle=solid}
>  if (StringUtils.isBlank(name)) {
> name = (String) ref.getProperty(Constants.SERVICE_PID);
> }
> {code}
> ref.getProperty(Constants.SERVICE_PID) is returning an ArrayList and I have 
> the stacktrace bellow as a result
> {code:title=Stacktrace|borderStyle=solid}
> java.lang.ClassCastException: java.util.ArrayList cannot be cast to 
> java.lang.String
>   at 
> org.apache.sling.hc.util.HealthCheckMetadata.getHealthCheckTitle(HealthCheckMetadata.java:146)
>   at 
> org.apache.sling.hc.util.HealthCheckMetadata.(HealthCheckMetadata.java:53)
>   at 
> org.apache.sling.hc.core.impl.executor.AsyncHealthCheckExecutor.serviceChanged(AsyncHealthCheckExecutor.java:114)
>   at 
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:991)
>   at 
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:839)
>   at 
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:546)
>   at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4557)
>   at org.apache.felix.framework.Felix.registerService(Felix.java:3549)
>   at 
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348)
>   at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:869)
>   at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:857)
>   at 
> org.apache.felix.scr.impl.manager.RegistrationManager.changeRegistration(RegistrationManager.java:133)
>   at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:915)
>   at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:715)
>   at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.enable(AbstractComponentManager.java:399)
>   at 
> org.apache.felix.scr.impl.config.ConfigurableComponentHolder.enableComponents(ConfigurableComponentHolder.java:676)
>   at 
> org.apache.felix.scr.impl.BundleComponentActivator.initialEnable(BundleComponentActivator.java:339)
>   at 
> org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:360)
>   at org.apache.felix.scr.impl.Activator.access$000(Activator.java:53)
>   at 
> org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:260)
>   at 
> org.apache.felix.utils.extender.AbstractExtender.createExtension(AbstractExtender.java:259)
>   at 
> org.apache.felix.utils.extender.AbstractExtender.modifiedBundle(AbstractExtender.java:232)
>   at 
> org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:482)
>   at 
> org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:415)
>   at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232)
>   at 
> org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444)
>   at 
> org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:916)
>   at 
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:835)
>   at 
> org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:517)
>   at 

[jira] [Commented] (SLING-6153) Improve MapEntries implementation

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6153:
-

Cleaned up configuration handling (no need to keep single config values in 
MapEntries as it holds the whole factory which has the configuration) in rev 
1764881
Started also to clean up methods and avoid duplicate actions

> 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] [Commented] (SLING-6153) Improve MapEntries implementation

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-6153:


FWIW, note that launchpad/test-services/...ResourceResolverTest includes one 
ignored test due to SLING-3558 - if you add more tests MapEntries it might be 
worth adding one for that as well.

> 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] [Resolved] (SLING-6147) Four tests fail in ResourceResolverTest

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz resolved SLING-6147.

Resolution: Fixed

All ResourceResolverTest tests indeed pass now, thanks you very much!

> Four tests fail in ResourceResolverTest
> ---
>
> Key: SLING-6147
> URL: https://issues.apache.org/jira/browse/SLING-6147
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
>  Labels: sling-IT
>
> As per 
> https://builds.apache.org/view/S-Z/view/Sling-Dashboard/job/sling-launchpad-testing-1.8/lastBuild/org.apache.sling$org.apache.sling.launchpad.testing/testReport/org.apache.sling.launchpad.webapp.integrationtest/ResourceResolverProxyTest/runWriteableResourcesTest/
> java.lang.AssertionError: 4 tests failed:[
> * 
> test_resolve_extension(org.apache.sling.launchpad.testservices.serversidetests.ResourceResolverTest):
>  expected: but was:, 
> * 
> test_resolve_selectors_extension(org.apache.sling.launchpad.testservices.serversidetests.ResourceResolverTest):
>  expected: but 
> was:, 
> * 
> test_resolve(org.apache.sling.launchpad.testservices.serversidetests.ResourceResolverTest):
>  expected: but was:, 
> * 
> test_resolve_with_sling_alias_limited_access(org.apache.sling.launchpad.testservices.serversidetests.ResourceResolverTest):
>  expected: but was:]
>   at org.junit.Assert.fail(Assert.java:88)
>   at 
> org.apache.sling.launchpad.webapp.integrationtest.util.ServerSideTestClient.assertTestsPass(ServerSideTestClient.java:109)
>   at 
> org.apache.sling.launchpad.webapp.integrationtest.ResourceResolverProxyTest.runWriteableResourcesTest(ResourceResolverProxyTest.java:26)



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

[jira] [Commented] (SLING-6147) Four tests fail in ResourceResolverTest

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6147:
-

[~bdelacretaz] with rev1764878 all tests pass again for me, could you please 
verify?
I'll increase the test coverage of MapEntries with SLING-6153 

> Four tests fail in ResourceResolverTest
> ---
>
> Key: SLING-6147
> URL: https://issues.apache.org/jira/browse/SLING-6147
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
>  Labels: sling-IT
>
> As per 
> https://builds.apache.org/view/S-Z/view/Sling-Dashboard/job/sling-launchpad-testing-1.8/lastBuild/org.apache.sling$org.apache.sling.launchpad.testing/testReport/org.apache.sling.launchpad.webapp.integrationtest/ResourceResolverProxyTest/runWriteableResourcesTest/
> java.lang.AssertionError: 4 tests failed:[
> * 
> test_resolve_extension(org.apache.sling.launchpad.testservices.serversidetests.ResourceResolverTest):
>  expected: but was:, 
> * 
> test_resolve_selectors_extension(org.apache.sling.launchpad.testservices.serversidetests.ResourceResolverTest):
>  expected: but 
> was:, 
> * 
> test_resolve(org.apache.sling.launchpad.testservices.serversidetests.ResourceResolverTest):
>  expected: but was:, 
> * 
> test_resolve_with_sling_alias_limited_access(org.apache.sling.launchpad.testservices.serversidetests.ResourceResolverTest):
>  expected: but was:]
>   at org.junit.Assert.fail(Assert.java:88)
>   at 
> org.apache.sling.launchpad.webapp.integrationtest.util.ServerSideTestClient.assertTestsPass(ServerSideTestClient.java:109)
>   at 
> org.apache.sling.launchpad.webapp.integrationtest.ResourceResolverProxyTest.runWriteableResourcesTest(ResourceResolverProxyTest.java:26)



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

[jira] [Resolved] (SLING-6148) MapEntries get CHANGED event right after DELETE

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-6148.
-
Resolution: Fixed

The code of MapEntries seemed to be highly optimized for the way changes used 
to be reported through the Oak observer - now as we switched back to a JCR 
Listener, the changes are reported differently (still correct), but this broke 
the MapEntries.
While working on this, I noticed that there is some room for improvement and 
obviously also test coverage. Created SLING-6153 for this

> 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.8.2, 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)

Re: [context-aware config] property names camel case?

[Konrad Windszus]

I would also prefer camelcase.
See other places in Sling like 
https://sling.apache.org/documentation/bundles/resource-merger.html 
 or 
https://sling.apache.org/documentation/the-sling-engine/mappings-for-resource-resolution.html
 
.

> On 14 Oct 2016, at 13:04, Carsten Ziegeler  wrote:
> 
> Stefan Seifert wrote
>> in [1] oliver mentioned the usage of property names in the current 
>> implementation:
>> 
>> sling:config-ref
>> sling:config-collection-inherit
>> sling:config-property-inherit
>> 
>> should we use headless camel case instead? is this more consistent with the 
>> other parts of sling?
>> 
>> sling:configRef
>> sling:configCollectionInherit
>> sling:configPropertyInherit  
>> 
>> 
> As mentioned as a response to Olli camel case would be more consistent.
> So if it is not too much work, we should change it. Otherwise I think it
> is not that important.
> 
> Carsten
> 
> 
> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
> 

Re: [context-aware config] java package name

[Carsten Ziegeler]

Stefan Seifert wrote
> in [1] oliver mentioned that the current java package name is not 
> consistent/not ideal.
> 
> currently wie use
> o.a.s.contextaware.config  => "highlevel configuration API"
> o.a.s.contextaware.config.resource  => "lowlevel resource API"
> 
> bertrand and myself noted that the package name should included 
> "contextaware" somewhere, using only org.apache.sling.configuration is too 
> generic/misleading.
> 
> so, what should we use?
> 
> a) keep o.a.s.contextaware.config + o.a.s.contextaware.config.resource
> 
> b) switch to o.a.s.contextawareconfig + o.a.s.contextawareconfig.resource to 
> get rid of the additional dot that is a bit inconsistent
> 
> c) switch to o.a.s.configuration + o.a.s.configuration.resource which is 
> misleading as it applies only to context-aware config
> 
> d) other proposals?
> 
> i hope we find a consensus in the next hours... or we just stick with a)
> 
As noted in the other thread, my proposal would be:

o.a.s.contextaware.config, o.a.s.contextaware.resource,
o.a.s.contextaware.config.annotation

So similar to a) but with moving resource one level down.

Just to make it more difficult to decide

a) or b) are good as well

The important point is that we don't use "configuration" as this is
confusing and separate the resource part from the settings (config).

Carsten

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

[jira] [Commented] (SLING-5788) Implement a Sightly Maven Plugin

[Radu Cotescu (JIRA)]

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

Radu Cotescu commented on SLING-5788:
-

[~jshurmer], the documentation is available at 
https://sling.apache.org/documentation/development/htl-maven-plugin.html.

> Implement a Sightly Maven Plugin
> 
>
> Key: SLING-5788
> URL: https://issues.apache.org/jira/browse/SLING-5788
> Project: Sling
>  Issue Type: New Feature
>  Components: Tooling
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: HTL Maven Plugin 1.0.0
>
>
> A Sightly Maven Plugin would be useful for static script validation. The 
> plugin can easily be developed based on the Sightly frontend compiler 
> extracted from SLING-5787.



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

Re: [context-aware config] property names camel case?

[Carsten Ziegeler]

Stefan Seifert wrote
> in [1] oliver mentioned the usage of property names in the current 
> implementation:
> 
> sling:config-ref
> sling:config-collection-inherit
> sling:config-property-inherit
> 
> should we use headless camel case instead? is this more consistent with the 
> other parts of sling?
> 
> sling:configRef
> sling:configCollectionInherit
> sling:configPropertyInherit  
> 
> 
As mentioned as a response to Olli camel case would be more consistent.
So if it is not too much work, we should change it. Otherwise I think it
is not that important.

Carsten

 

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

[context-aware config] java package name

[Stefan Seifert]

in [1] oliver mentioned that the current java package name is not 
consistent/not ideal.

currently wie use
o.a.s.contextaware.config  => "highlevel configuration API"
o.a.s.contextaware.config.resource  => "lowlevel resource API"

bertrand and myself noted that the package name should included "contextaware" 
somewhere, using only org.apache.sling.configuration is too generic/misleading.

so, what should we use?

a) keep o.a.s.contextaware.config + o.a.s.contextaware.config.resource

b) switch to o.a.s.contextawareconfig + o.a.s.contextawareconfig.resource to 
get rid of the additional dot that is a bit inconsistent

c) switch to o.a.s.configuration + o.a.s.configuration.resource which is 
misleading as it applies only to context-aware config

d) other proposals?

i hope we find a consensus in the next hours... or we just stick with a)

stefan


[1] 
https://lists.apache.org/thread.html/eed70b8c06e15ee113b76d6d8827dee984a86e00691b2a9990af1144@%3Cdev.sling.apache.org%3E

Re: [context-aware config] first release this week?

[Carsten Ziegeler]

Oliver Lietz wrote
> On Thursday 13 October 2016 20:36:10 Stefan Seifert wrote:
>>> Do we really want org.apache.sling.contextaware.config as package name?
>>> Sling Content Distribution uses org.apache.sling.distribution, so
>>> org.apache.sling.configuration for Sling's context-ware configuration
>>> should be fine, no?
>>
>> only "configuration" is misleading, because it's not about osgi
>> configuration, but only about context-aware configuration. thus
>> "contextaware" has to be part of the package name.
> 
> I do remember the discussion regarding the naming and do not want that 
> starting again. But not sure if the "product label" has to be also the 
> package 
> name – for distribution, which is also a *very* generic name – it has to be 
> not. And as this configurations are based on resources I should have 
> suggested 
> o.a.s.resource.configuration.
> 
>> one could argue if it should be
>>   o.a.s.contextaware.config
>> or
>>   o.a.s.contextawareconfig

I'm fine with contextawareconfig - I think over time we renamed the
packages a little bit, and for example had everything as sub packages of
contextaware (config, resource).
I think we either rename it to contextawareconfig
or go with
contextaware.config
.resource
.annotation
leaving contextaware empty

> 
> The second fits better in our naming pattern. Also these modules are the 
> first 
> using dashes in property names (or node/resource types) instead of camel case.

Hmm, true, haven't really thought about it. I guess camel case would be
more consistent, but I think in the end it's not that important

Regards
Carsten
> 
>>> Any hints for using it on AEM 6.1?
>>
>> i've created a small sample project using it with AEM 6.1 at [1].
>> no further dependencies are required atm.
>> but without customization via SPI it does not yet support cq:Page node types
>> or other AEM specifica.
> 
> Will you provide AEM extensions, tooling and GUI under wcm.io umbrella?
> 
> Hopefully I will find some time in the next weeks to move a project from 
> custom configuration to _context-aware_ configuration (POC). 
> 
> Thanks for contributing that stuff to Sling, Stefan!
> 
> Regards,
> O.
> 
>> stefan
>>
>> [1] https://github.com/stefanseifert/sling-contextaware-config-aem-sample
> 
> 
> 


 

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

[context-aware config] property names camel case?

[Stefan Seifert]

in [1] oliver mentioned the usage of property names in the current 
implementation:

sling:config-ref
sling:config-collection-inherit
sling:config-property-inherit

should we use headless camel case instead? is this more consistent with the 
other parts of sling?

sling:configRef
sling:configCollectionInherit
sling:configPropertyInherit  


stefan


[1] 
https://lists.apache.org/thread.html/eed70b8c06e15ee113b76d6d8827dee984a86e00691b2a9990af1144@%3Cdev.sling.apache.org%3E

[jira] [Commented] (SLING-6054) JcrEventTrigger aggregation resulting in unconsistent package

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili commented on SLING-6054:


fixed the previous issue in r1764869.

> JcrEventTrigger aggregation resulting in unconsistent package
> -
>
> Key: SLING-6054
> URL: https://issues.apache.org/jira/browse/SLING-6054
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
>
> {{JcrEventTrigger}} aggregates generated {{DistributionRequests}} in order to 
> mitigate the risk of having badly ordered events result in distributions that 
> may lead to unconsistent state of the receiving instance.
> In case 2 nodes one of which is descendant of the others get aggregated in 
> the same request the resulting package will only include siblings of the deep 
> path with its names, not their properties, resulting in removing existing 
> properties by the deep node's siblings on the receiving side.
> I am not 100% sure this is a desired behaviour in FileVault, however since 
> this may also affect custom serializers I think the right fix is to add the 
> siblings's paths to such distribution requests.



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

RE: [context-aware config] first release this week?

[Oliver Lietz]

On Thursday 13 October 2016 20:36:10 Stefan Seifert wrote:
> >Do we really want org.apache.sling.contextaware.config as package name?
> >Sling Content Distribution uses org.apache.sling.distribution, so
> >org.apache.sling.configuration for Sling's context-ware configuration
> >should be fine, no?
> 
> only "configuration" is misleading, because it's not about osgi
> configuration, but only about context-aware configuration. thus
> "contextaware" has to be part of the package name.

I do remember the discussion regarding the naming and do not want that 
starting again. But not sure if the "product label" has to be also the package 
name – for distribution, which is also a *very* generic name – it has to be 
not. And as this configurations are based on resources I should have suggested 
o.a.s.resource.configuration.

> one could argue if it should be
>   o.a.s.contextaware.config
> or
>   o.a.s.contextawareconfig

The second fits better in our naming pattern. Also these modules are the first 
using dashes in property names (or node/resource types) instead of camel case.

> >Any hints for using it on AEM 6.1?
> 
> i've created a small sample project using it with AEM 6.1 at [1].
> no further dependencies are required atm.
> but without customization via SPI it does not yet support cq:Page node types
> or other AEM specifica.

Will you provide AEM extensions, tooling and GUI under wcm.io umbrella?

Hopefully I will find some time in the next weeks to move a project from 
custom configuration to _context-aware_ configuration (POC). 

Thanks for contributing that stuff to Sling, Stefan!

Regards,
O.

> stefan
> 
> [1] https://github.com/stefanseifert/sling-contextaware-config-aem-sample

[jira] [Resolved] (SLING-6151) Allow HApi core to be disabled

[Andrei Dulvac (JIRA)]

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

Andrei Dulvac resolved SLING-6151.
--
Resolution: Fixed

> Allow HApi core to be disabled
> --
>
> Key: SLING-6151
> URL: https://issues.apache.org/jira/browse/SLING-6151
> Project: Sling
>  Issue Type: Improvement
>  Components: HApi
>Affects Versions: HApi 1.0.0
>Reporter: Andrei Dulvac
>Assignee: Andrei Dulvac
> Fix For: HApi 2.0.0
>
>
> Allow HApi core to be disabled with an OSGi configuration. Disabling it 
> should not output any html attributes in the components where it's used.



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

[jira] [Commented] (SLING-6112) Make Sling IDE independent of m2e-tycho

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6112:


There is an error marker in each pom.xml which is not setup correctly. This is 
probably the best way of doing it and Eclipse user's should be familiar with 
looking at the Problems view and searching for quick fixes in case there are 
any errors exposed.

> Make Sling IDE independent of m2e-tycho
> ---
>
> Key: SLING-6112
> URL: https://issues.apache.org/jira/browse/SLING-6112
> Project: Sling
>  Issue Type: Improvement
>  Components: Tooling
>Affects Versions: Sling Eclipse IDE 1.1.0
>Reporter: Konrad Windszus
>Assignee: Robert Munteanu
> Fix For: Sling Eclipse IDE 1.1.2
>
> Attachments: SLING-6112-v01.patch, SLING-6112-v02.patch, 
> SLING-6112-v03.patch
>
>
> Currently Sling IDE requires the installation of m2e-tycho. This was being 
> added in https://issues.apache.org/jira/browse/SLING-3608. Now that the 
> maven-bundle-plugin ships with m2e support OOTB (FELIX-4009) we should get 
> rid of that dependency.
> This is also important since newer versions of the maven-bundle-plugin 
> conflict with that extension 
> (https://issues.apache.org/jira/browse/FELIX-4009?focusedCommentId=15192263=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15192263).
> See also the discussion at 
> http://www.mail-archive.com/dev@sling.apache.org/msg60112.html.



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

[jira] [Comment Edited] (SLING-6112) Make Sling IDE independent of m2e-tycho

[Konrad Windszus (JIRA)]

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

Konrad Windszus edited comment on SLING-6112 at 10/14/16 10:00 AM:
---

There is an error marker in each pom.xml which is not setup correctly. This is 
probably the best way of doing it and Eclipse users should be familiar with 
looking at the Problems view and searching for quick fixes in case there are 
any errors exposed.


was (Author: kwin):
There is an error marker in each pom.xml which is not setup correctly. This is 
probably the best way of doing it and Eclipse user's should be familiar with 
looking at the Problems view and searching for quick fixes in case there are 
any errors exposed.

> Make Sling IDE independent of m2e-tycho
> ---
>
> Key: SLING-6112
> URL: https://issues.apache.org/jira/browse/SLING-6112
> Project: Sling
>  Issue Type: Improvement
>  Components: Tooling
>Affects Versions: Sling Eclipse IDE 1.1.0
>Reporter: Konrad Windszus
>Assignee: Robert Munteanu
> Fix For: Sling Eclipse IDE 1.1.2
>
> Attachments: SLING-6112-v01.patch, SLING-6112-v02.patch, 
> SLING-6112-v03.patch
>
>
> Currently Sling IDE requires the installation of m2e-tycho. This was being 
> added in https://issues.apache.org/jira/browse/SLING-3608. Now that the 
> maven-bundle-plugin ships with m2e support OOTB (FELIX-4009) we should get 
> rid of that dependency.
> This is also important since newer versions of the maven-bundle-plugin 
> conflict with that extension 
> (https://issues.apache.org/jira/browse/FELIX-4009?focusedCommentId=15192263=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15192263).
> See also the discussion at 
> http://www.mail-archive.com/dev@sling.apache.org/msg60112.html.



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

[jira] [Created] (SLING-6153) Improve MapEntries implementation

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-6153:
---

 Summary: 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] [Commented] (SLING-6112) Make Sling IDE independent of m2e-tycho

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-6112:


OK, let me take a look and see how obvious this is. My worry is that after 
upgrading and things stop working no one will be looking for the quick fix.

> Make Sling IDE independent of m2e-tycho
> ---
>
> Key: SLING-6112
> URL: https://issues.apache.org/jira/browse/SLING-6112
> Project: Sling
>  Issue Type: Improvement
>  Components: Tooling
>Affects Versions: Sling Eclipse IDE 1.1.0
>Reporter: Konrad Windszus
>Assignee: Robert Munteanu
> Fix For: Sling Eclipse IDE 1.1.2
>
> Attachments: SLING-6112-v01.patch, SLING-6112-v02.patch, 
> SLING-6112-v03.patch
>
>
> Currently Sling IDE requires the installation of m2e-tycho. This was being 
> added in https://issues.apache.org/jira/browse/SLING-3608. Now that the 
> maven-bundle-plugin ships with m2e support OOTB (FELIX-4009) we should get 
> rid of that dependency.
> This is also important since newer versions of the maven-bundle-plugin 
> conflict with that extension 
> (https://issues.apache.org/jira/browse/FELIX-4009?focusedCommentId=15192263=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15192263).
> See also the discussion at 
> http://www.mail-archive.com/dev@sling.apache.org/msg60112.html.



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

[jira] [Commented] (SLING-6112) Make Sling IDE independent of m2e-tycho

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6112:


This is exactly what I implemented in the patch v03. There are two quick fixes 
when such a condition is detected:
# Install m2e-tycho through Maven Discovery
# Expose a dialog where it is explained how to configure "maven-bundle-plugin" 
correctly.

The patch attached to SLING-6129 will additionally add a 3rd quickfix which 
explains how to configure "bnd-maven-plugin".

> Make Sling IDE independent of m2e-tycho
> ---
>
> Key: SLING-6112
> URL: https://issues.apache.org/jira/browse/SLING-6112
> Project: Sling
>  Issue Type: Improvement
>  Components: Tooling
>Affects Versions: Sling Eclipse IDE 1.1.0
>Reporter: Konrad Windszus
>Assignee: Robert Munteanu
> Fix For: Sling Eclipse IDE 1.1.2
>
> Attachments: SLING-6112-v01.patch, SLING-6112-v02.patch, 
> SLING-6112-v03.patch
>
>
> Currently Sling IDE requires the installation of m2e-tycho. This was being 
> added in https://issues.apache.org/jira/browse/SLING-3608. Now that the 
> maven-bundle-plugin ships with m2e support OOTB (FELIX-4009) we should get 
> rid of that dependency.
> This is also important since newer versions of the maven-bundle-plugin 
> conflict with that extension 
> (https://issues.apache.org/jira/browse/FELIX-4009?focusedCommentId=15192263=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15192263).
> See also the discussion at 
> http://www.mail-archive.com/dev@sling.apache.org/msg60112.html.



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

Re: [context-aware config] first release this week?

[Bertrand Delacretaz]

On Thu, Oct 13, 2016 at 10:36 PM, Stefan Seifert  wrote:
> ...only "configuration" is misleading, because it's not about osgi 
> configuration, but only
> about context-aware configuration. thus "contextaware" has to be part of the 
> package name...

I agree that just "configuration" would be too generic in this case.

-Bertrand

[jira] [Commented] (SLING-6148) MapEntries get CHANGED event right after DELETE

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6148:
-

Thanks, I just committed a fix for the JcrResourceListener which should 
correctly handle the observation events now.
Still the tests don't pass. I've also committed a couple of fixes for the 
MapEntries and start getting a feeling how all the stuff works

> 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.8.2, 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] [Commented] (SLING-6149) Context-Aware Config: Make lookup resource name for sling:config-ref property configurable

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6149:
---

simplified together with SLING-6152 in rev. 1764843 

> Context-Aware Config: Make lookup resource name for sling:config-ref property 
> configurable
> --
>
> Key: SLING-6149
> URL: https://issues.apache.org/jira/browse/SLING-6149
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Minor
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> by default, the sling:config-ref property is looked up directly in the 
> context root resource. it should be possible to define alternative lookup 
> paths e.g. to look in a child node jcr:content for it.



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

[JIRA]

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

Jörg Hoh commented on SLING-5277:
-

Is there any progress on this?

> 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.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-6112) Make Sling IDE independent of m2e-tycho

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-6112:


In my opinion the right thing to do would be to rely on the bnd-maven-plugin 
and not install the tycho-m2e feature at all. We're stuck with an old version 
unfortunately.

This however comes with the drawback that

- we no longer support older versions of the maven-bundle-plugin
- we require users to configure newer versions of the maven-bundle-plugin for 
correct execution

which is IMO a blocker at the moment. Not even the Sling project has moved to 
the bnd-maven-plugin, and we are quite quick to adopt new stuff.

So in my opinion what would be good to have is to have this tycho-m2e feature 
opt-in, rather than mandatory, so that it can be disabled/uninstalled by those 
who don't want it, but it still works for those who (like me initially) have no 
idea about old vs new maven-bundle-plugin and why the bnd-maven-plugin is good 
to go. Not to mention those that can't migrate.

Thoughts?

> Make Sling IDE independent of m2e-tycho
> ---
>
> Key: SLING-6112
> URL: https://issues.apache.org/jira/browse/SLING-6112
> Project: Sling
>  Issue Type: Improvement
>  Components: Tooling
>Affects Versions: Sling Eclipse IDE 1.1.0
>Reporter: Konrad Windszus
>Assignee: Robert Munteanu
> Fix For: Sling Eclipse IDE 1.1.2
>
> Attachments: SLING-6112-v01.patch, SLING-6112-v02.patch, 
> SLING-6112-v03.patch
>
>
> Currently Sling IDE requires the installation of m2e-tycho. This was being 
> added in https://issues.apache.org/jira/browse/SLING-3608. Now that the 
> maven-bundle-plugin ships with m2e support OOTB (FELIX-4009) we should get 
> rid of that dependency.
> This is also important since newer versions of the maven-bundle-plugin 
> conflict with that extension 
> (https://issues.apache.org/jira/browse/FELIX-4009?focusedCommentId=15192263=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15192263).
> See also the discussion at 
> http://www.mail-archive.com/dev@sling.apache.org/msg60112.html.



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

Re: Un-hiding the AUTH_SERVICE_BUNDLE in CommonResourceResolverFactoryImpl, ok?

[Bertrand Delacretaz]

On Mon, Oct 10, 2016 at 4:43 PM, Carsten Ziegeler  wrote:
> ...we should filter these values in ResourceResolverControl
> for getting the attributes, otherwise the using bundle can be fetch from
> the attributes. Currently that code just filters the password...

I have added tests in http://svn.apache.org/r1764845 ,
AUTH_SERVICE_BUNDLE is correctly hidden.

-Bertrand

[jira] [Resolved] (SLING-6152) Context-Aware Config: Config reference should be detected in ContextPathStrategy

[Stefan Seifert (JIRA)]

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

Stefan Seifert resolved SLING-6152.
---
Resolution: Fixed

Completed: At revision: 1764843  


> Context-Aware Config: Config reference should be detected in 
> ContextPathStrategy
> 
>
> Key: SLING-6152
> URL: https://issues.apache.org/jira/browse/SLING-6152
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Context-Aware Configuration 1.0.0
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> currently the DefaultContextPathStrategy checks for the availability of the 
> sling:config-ref prop, but it does not return it's value, this is done in the 
> DefaultConfigurationResourceResolvingStrategy.
> this is as bit inconsistent, leading to configure the lookup of SLING-6149 in 
> multiple places, and makes it more difficult to define scenarios where the 
> config references is build on a conventions-based pattern (e.g. derived from 
> content path) instead of an explicit sling:config-ref property.
> the logic itself and other implementation details of both strategies remain 
> untouched.



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

[jira] [Resolved] (SLING-3234) Sling buildbot continuous integration

[Robert Munteanu (JIRA)]

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

Robert Munteanu resolved SLING-3234.

Resolution: Later

Resolving as 'Later' after disabling the sling builders from buildbot.

We can always reopen if we decide to re-activate the buildbot.

> Sling buildbot continuous integration
> -
>
> Key: SLING-3234
> URL: https://issues.apache.org/jira/browse/SLING-3234
> Project: Sling
>  Issue Type: Task
>  Components: Testing
>Reporter: Bertrand Delacretaz
>
> Buildbot jobs have been setup for Sling in INFRA-6962;
> * http://ci.apache.org/builders/sling-trunk (triggered by commits)
> * http://ci.apache.org/builders/sling-trunk-oak (runs after sling-trunk)
> We'll use this issue to keep track of changes related to this buildbot setup, 
> as we did with SLING-920 for our Jenkins builds.
> I suggest marking issues that cause intermittent buildbot failures as 
> blockers for this issue, so that we can quickly check if failed builds are 
> due to known issues.
> Builds can be started manually via IRC if needed, via #asftest. Talk to the 
> sling-bot there, start with "help force", "status" or "commands".
> [1] 
> https://svn.apache.org/repos/infra/infrastructure/buildbot/aegis/buildmaster/master1/projects/sling.conf



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

[jira] [Created] (SLING-6152) Context-Aware Config: Config reference should be detected in ContextPathStrategy

[Stefan Seifert (JIRA)]

Stefan Seifert created SLING-6152:
-

 Summary: Context-Aware Config: Config reference should be detected 
in ContextPathStrategy
 Key: SLING-6152
 URL: https://issues.apache.org/jira/browse/SLING-6152
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Context-Aware Configuration 1.0.0
Reporter: Stefan Seifert
Assignee: Stefan Seifert
 Fix For: Context-Aware Configuration 1.0.0


currently the DefaultContextPathStrategy checks for the availability of the 
sling:config-ref prop, but it does not return it's value, this is done in the 
DefaultConfigurationResourceResolvingStrategy.

this is as bit inconsistent, leading to configure the lookup of SLING-6149 in 
multiple places, and makes it more difficult to define scenarios where the 
config references is build on a conventions-based pattern (e.g. derived from 
content path) instead of an explicit sling:config-ref property.

the logic itself and other implementation details of both strategies remain 
untouched.



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

Re: [VOTE] Release Apache Sling Scripting HTL Java Compiler 1.0.4, Apache Sling Scripting HTL Engine 1.0.24

[Carsten Ziegeler]

+1

 

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

[jira] [Closed] (SLING-6122) Sling Pipes javadoc fails

[Oliver Lietz (JIRA)]

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

Oliver Lietz closed SLING-6122.
---

> Sling Pipes javadoc fails
> -
>
> Key: SLING-6122
> URL: https://issues.apache.org/jira/browse/SLING-6122
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Nicolas Peltier
>Assignee: Oliver Lietz
> Fix For: Pipes 0.0.10
>
> Attachments: SLING-6122.patch
>
>
> sling pipes javadoc fails, preventing release to be done



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

[jira] [Closed] (SLING-6063) plumber servlet doesn't persist changes anymore

[Oliver Lietz (JIRA)]

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

Oliver Lietz closed SLING-6063.
---

> plumber servlet doesn't persist changes anymore
> ---
>
> Key: SLING-6063
> URL: https://issues.apache.org/jira/browse/SLING-6063
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Nicolas Peltier
>Assignee: Robert Munteanu
> Fix For: Pipes 0.0.10
>
> Attachments: SLING-6063.patch
>
>
> since the writer enhancement, plumber's commit had disappeared, resulting in 
> systematic unchanged resources



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

[jira] [Closed] (SLING-6073) pipe writer and additionalbindings configurations added through POST break the pipe

[Oliver Lietz (JIRA)]

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

Oliver Lietz closed SLING-6073.
---

> pipe writer and additionalbindings configurations added through POST break 
> the pipe
> ---
>
> Key: SLING-6073
> URL: https://issues.apache.org/jira/browse/SLING-6073
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Nicolas Peltier
>Assignee: Oliver Lietz
> Fix For: Pipes 0.0.10
>
> Attachments: SLING-6073.patch
>
>
> if POST contains protected properties (like jcr:created / jcr:createdBy), 
> those properties shouldn't be taken in account by writer or 
> additionalbinding, like it is done in other places



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

[jira] [Closed] (SLING-6032) Not sling pipe

[Oliver Lietz (JIRA)]

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

Oliver Lietz closed SLING-6032.
---

> Not sling pipe
> --
>
> Key: SLING-6032
> URL: https://issues.apache.org/jira/browse/SLING-6032
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Nicolas Peltier
>Assignee: Robert Munteanu
> Fix For: Pipes 0.0.10
>
> Attachments: SLING-6032.patch
>
>
> a not sling pipe, working as a reference sling pipe would be useful:
> - output nothing if referred pipe has any output,
> - output input if referred pipe has no output



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

[jira] [Closed] (SLING-5523) filter pipe should be able to filter out resources that *have* a configured child

[Oliver Lietz (JIRA)]

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

Oliver Lietz closed SLING-5523.
---

> filter pipe should be able to filter out resources that *have* a configured 
> child
> -
>
> Key: SLING-5523
> URL: https://issues.apache.org/jira/browse/SLING-5523
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Nicolas Peltier
>Assignee: Robert Munteanu
> Fix For: Pipes 0.0.10
>
> Attachments: SLING-5434-5523-DOC.patch, SLING-5523.patch
>
>
> implementing that feature as is could be complicated. A simple way of doing 
> it is to add a "not" flag that inverts the filter results (if filter passes 
> and not, filter fails, if filter fails and not, filter succeeds, filter 
> succeeds in other cases (exclusive or of filter and not flag))



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

[jira] [Closed] (SLING-5735) Pipes XPathPipe does not log query

[Oliver Lietz (JIRA)]

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

Oliver Lietz closed SLING-5735.
---

> Pipes XPathPipe does not log query
> --
>
> Key: SLING-5735
> URL: https://issues.apache.org/jira/browse/SLING-5735
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Jonathan Bell
>Assignee: Stefan Seifert
>Priority: Minor
> Fix For: Pipes 0.0.10
>
> Attachments: XPathPipe.diff
>
>
> The XPathPipe ideally should log the query being executed.
> Patch is included.



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

[jira] [Closed] (SLING-5729) pipe expressions should allow regexp with {n} or {n,m}

[Oliver Lietz (JIRA)]

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

Oliver Lietz closed SLING-5729.
---

> pipe expressions should allow regexp with {n} or {n,m}
> --
>
> Key: SLING-5729
> URL: https://issues.apache.org/jira/browse/SLING-5729
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Nicolas Peltier
>Assignee: Stefan Seifert
>Priority: Minor
> Fix For: Pipes 0.0.10
>
> Attachments: SLING-5729.patch
>
>
> expressions like
> {Code}
> ${(new Regexp('/foo/bar/./../.{8}').test(path)}"
> {Code}
> can't work right now because of the rather simple regexp for extracting them



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

[jira] [Closed] (SLING-5718) Pipes size parameter is ignored

[Oliver Lietz (JIRA)]

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

Oliver Lietz closed SLING-5718.
---

> Pipes size parameter is ignored
> ---
>
> Key: SLING-5718
> URL: https://issues.apache.org/jira/browse/SLING-5718
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Jordan Shurmer
>Assignee: Oliver Lietz
> Fix For: Pipes 0.0.10
>
> Attachments: SLING-5718.patch
>
>   Original Estimate: 10m
>  Remaining Estimate: 10m
>
> The "size" parameter which can be passed in when executing a Pipe is ignored.
> line 92 of PlumbServlet.Java gets it
> {code}int size = request.getParameter(PARAM_SIZE) != null ? 
> Integer.parseInt(request.getParameter(PARAM_SIZE)) : NB_MAX;{code}
> but it is never used.



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

[jira] [Closed] (SLING-5728) enhance filterpipe logging

[Oliver Lietz (JIRA)]

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

Oliver Lietz closed SLING-5728.
---

> enhance filterpipe logging
> --
>
> Key: SLING-5728
> URL: https://issues.apache.org/jira/browse/SLING-5728
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Nicolas Peltier
>Assignee: Stefan Seifert
>Priority: Minor
> Fix For: Pipes 0.0.10
>
> Attachments: SLING-5728.patch
>
>
> - when a filter pipe's expression fails to generate a boolean, it should 
> output the expression instead of a ClassCast exception,
> - when a filter pipe filters out a resource, it should log this in DEBUG, not 
> INFO



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

[jira] [Closed] (SLING-5818) make sling pipe writer a persistent configuration

[Oliver Lietz (JIRA)]

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

Oliver Lietz closed SLING-5818.
---

> make sling pipe writer a persistent configuration
> -
>
> Key: SLING-5818
> URL: https://issues.apache.org/jira/browse/SLING-5818
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Nicolas Peltier
>Assignee: Robert Munteanu
> Fix For: Pipes 0.0.10
>
> Attachments: SLING-5818.patch
>
>
> right now, the only way to configure the output of a pipe is to add a json as 
> parameter of the pipe request. Sometimes the output is as important/complex 
> as the pipe itself, and should be persisted.
> This could be also the opportunity to rewrite how writer is managed in a far 
> from ideal if/else block. 
> servlet/plumber should *always* take a writer in account, and call it each 
> time,
> default being path writer, writer should still be overridable through a 
> request parameter



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

[jira] [Closed] (SLING-5362) Default output should be truncated

[Oliver Lietz (JIRA)]

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

Oliver Lietz closed SLING-5362.
---

> Default output should be truncated
> --
>
> Key: SLING-5362
> URL: https://issues.apache.org/jira/browse/SLING-5362
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Nicolas Peltier
>Assignee: Oliver Lietz
> Fix For: Pipes 0.0.10
>
> Attachments: SLING-5362.patch
>
>
> default output is the paths of modified resources, which tends to be far too 
> big as soon as you do lot of changes, should be truncated / paginated by 
> default.
> This issue had been fixed already between initial donation and final commit. 
> Will attach the patch to this ticket



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

[jira] [Closed] (SLING-5434) WritePipe shoud remove properties at the very end

[Oliver Lietz (JIRA)]

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

Oliver Lietz closed SLING-5434.
---

> WritePipe shoud remove properties at the very end
> -
>
> Key: SLING-5434
> URL: https://issues.apache.org/jira/browse/SLING-5434
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Nicolas Peltier
>Assignee: Robert Munteanu
> Fix For: Pipes 0.0.10
>
> Attachments: SLING-5434-DOC.patch, SLING-5434.patch
>
>
> in order to allow all expressions at current state to use the values of 
> properties to be removed.
> test & fix in attached patch
> related to thread 
> http://mail-archives.apache.org/mod_mbox/sling-users/201601.mbox/%3C2FBC4C5C-A110-40A2-A7CF-F2B11170DD8F%40adobe.com%3E



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