[jira] [Updated] (SLING-6090) Avoid using nt:resource while creating file nodes via SlingPostServlet

2016-10-11 Thread Chetan Mehrotra (JIRA)

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

Chetan Mehrotra updated SLING-6090:
---
Description: 
Currently Sling uses {{nt:resource}} nodetype while creating file nodes in 
{{SlingFileUploadHandler}} and {{StreamedChunk}}. 

As discussed in OAK-4567 and also in best practices at [1] it would be better 
to avoid using a referenceable nodetype and instead use another nodetype like 
{{oak:Resource}} 

Mail thread on DL

[1] 
https://adapt.to/2016/en/schedule/let_s-run-the-whole-web-on-apache-sling-and-oak-.html
[2] http://markmail.org/thread/77xvjxtx42euhss4
[3] http://markmail.org/thread/tnqbcegadnyaflw4

  was:
Currently Sling uses {{nt:resource}} nodetype while creating file nodes in 
{{SlingFileUploadHandler}} and {{StreamedChunk}}. 

As discussed in OAK-4567 and also in best practices at [1] it would be better 
to avoid using a referenceable nodetype and instead use another nodetype like 
{{oak:Resource}} 

Mail thread on DL

[1] 
https://adapt.to/2016/en/schedule/let_s-run-the-whole-web-on-apache-sling-and-oak-.html
[2] http://markmail.org/thread/77xvjxtx42euhss4


> Avoid using nt:resource while creating file nodes via SlingPostServlet
> --
>
> Key: SLING-6090
> URL: https://issues.apache.org/jira/browse/SLING-6090
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Servlets Post 2.3.16
>
>
> Currently Sling uses {{nt:resource}} nodetype while creating file nodes in 
> {{SlingFileUploadHandler}} and {{StreamedChunk}}. 
> As discussed in OAK-4567 and also in best practices at [1] it would be better 
> to avoid using a referenceable nodetype and instead use another nodetype like 
> {{oak:Resource}} 
> Mail thread on DL
> [1] 
> https://adapt.to/2016/en/schedule/let_s-run-the-whole-web-on-apache-sling-and-oak-.html
> [2] http://markmail.org/thread/77xvjxtx42euhss4
> [3] http://markmail.org/thread/tnqbcegadnyaflw4



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


Re: sling ci builds per module

2016-10-11 Thread Chetan Mehrotra
Build feedback is now lot more faster and something one can rely on

Thanks Robert!.
Chetan Mehrotra


On Wed, Oct 12, 2016 at 3:01 AM, Stefan Seifert  wrote:
> that's great, thanks!
>
> stefan
>
>>-Original Message-
>>From: Robert Munteanu [mailto:romb...@apache.org]
>>Sent: Tuesday, October 11, 2016 11:18 PM
>>To: dev@sling.apache.org
>>Subject: Re: sling ci builds per module
>>
>>For the record, this is now done.
>>
>>Robert


[context-aware config] first release this week?

2016-10-11 Thread Stefan Seifert
we've reached a quite good featureset in the current implementation of the 
context-ware configuration [1].

to make it usable by projects it would be useful to make a release soon.

there are some planned extensions missing, but i've moved them to version 1.1.0 
because i think they are not really imporant vor version 1.0.0 and should not 
break the API or SPI. [2]

i will have no time to work on this new issues the next two weeks, and the 
remaining time slots in this week i want to use to provide documentation about 
the API/SPI and content structure/inheritance features of the implementation 
that is available now.

if no one objects i will start a release vote by end of this week.

stefan


[1] https://issues.apache.org/jira/browse/SLING/fixforversion/12338139
[2] 
https://issues.apache.org/jira/issues/?jql=project%20%3D%20sling%20AND%20labels%20%3D%20contextaware-config%20AND%20resolution%20%3D%20unresolved%20ORDER%20BY%20priority%20DESC%2C%20key%20ASC




RE: [context-aware config] context path strategy depending on request information?

2016-10-11 Thread Stefan Seifert
we currently cannot come up with an elegant solution supporting it directly in 
the API/SPI.

if a project needs this feature it can be implemented in project-specific code 
by implementing a thread local for getting the current request, and passing it 
into a custom ConfigurationResourceResolvingStrategy.

stefan

p.s. the title of this thread is misleading - configuraiton resource resolving 
strategy is meant instead of context path strategy.


>-Original Message-
>From: Stefan Seifert [mailto:sseif...@pro-vision.de]
>Sent: Friday, September 30, 2016 3:24 PM
>To: dev@sling.apache.org
>Subject: [context-aware config] context path strategy depending on request
>information?
>
>on the adaptTo() conference there was feedback from one participant after
>my talk [1]:
>- he asked if it is possible to provide different context-aware
>configuration for different hostnames, but with the same content path
>- i assume this is some tenant-specific solution where all tenants share
>the same content, but display different personalization
>
>technically speaking we would need to extend the methods in the
>ConfigurationResourceResolvingStrategy interface [2] with an additional
>SlingServletRequest parameter to support detecting the matching config path
>based on information from there e.g. domain name.
>
>but this would only be possible if we extend the
>ConfigurationResolver/Builder API as well and pass in the current request -
>otherwise we have no means to get it (or only via a unloved threadlocal
>hack). we have to make it optional, because in most cases the request will
>not be needed. but then applications requiring request-based configuration
>solution always need to make sure they provide this additional parameter.
>it also gets difficult to provide configuration editor GUI support in this
>case, because the domain names are not known in the author instance,
>mapping only takes place on the publish instances.
>
>WDYT - should we add support for it? not sure if this is really a common
>usecase.
>
>stefan
>
>[1] https://adapt.to/2016/en/schedule/sling-context-aware-
>configuration.html
>[2]
>https://github.com/apache/sling/blob/trunk/contrib/extensions/contextaware-
>config/spi/src/main/java/org/apache/sling/contextaware/config/resource/spi/
>ConfigurationResourceResolvingStrategy.java
>
>




RE: sling ci builds per module

2016-10-11 Thread Stefan Seifert
that's great, thanks!

stefan

>-Original Message-
>From: Robert Munteanu [mailto:romb...@apache.org]
>Sent: Tuesday, October 11, 2016 11:18 PM
>To: dev@sling.apache.org
>Subject: Re: sling ci builds per module
>
>For the record, this is now done.
>
>Robert


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

2016-10-11 Thread 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:
--
Description: 
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.

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


> 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 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-6137) Context-Aware Config: Configuration Manager - Support resource collection and property inheritance

2016-10-11 Thread 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:
--
Description: 
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.

  was:
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 able visualize this information.

this may be usable for a configuration editor and the web console (SLING-6115) 
as well.


> 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 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-6060) Context-Aware Config: Configuration property override providers

2016-10-11 Thread 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 1.0.0)
   Context-Aware Configuration 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 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



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


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

2016-10-11 Thread 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 1.0.0)
   Context-Aware Configuration 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 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

2016-10-11 Thread 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:
--
Labels: contextaware-config  (was: )

> 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 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 able 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] [Commented] (SLING-6115) Context-Aware Config: Web Console Plugin

2016-10-11 Thread Stefan Seifert (JIRA)

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

Stefan Seifert commented on SLING-6115:
---

it would make sense to base the web console plugin on the configuration 
management API, which is also used by configuration editors.

maybe we should wait until SLING-6137 is implemented.

ideally the web console should support debugging both 
ConfigurationResourceResolver and ConfigurationResolver features.

> 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 1.0.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] [Created] (SLING-6137) Context-Aware Config: Configuration Manager - Support resource collection and property inheritance

2016-10-11 Thread Stefan Seifert (JIRA)
Stefan Seifert created SLING-6137:
-

 Summary: 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
 Fix For: Context-Aware Configuration 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 able 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)


Re: sling ci builds per module

2016-10-11 Thread Robert Munteanu
For the record, this is now done.

Robert

On Wed, 2016-09-28 at 22:52 +, Stefan Seifert wrote:
> discussed at the Sling Committer Round Table @ adaptTo() 2016
> 
> we all agreed that we need CI build individually per module/bundle,
> not a big build for all bundles at once.
> 
> benefits:
> - much faster feedback in case of a broken build, and much more
> specific
> - if one module is broken only it's own CI build is affected, all
> other are still green
> - CI build for one module is much faster, leading to much shorter
> debugging cycles in case of problems
> - it's much easier to use tools like travis without having to work
> around build time and log output size limitations
> 
> alternatives discussed:
> - we were very unhappy with the apache Jenkins lately, but the reason
> may be that the single full CI build was just too big and fragile
> - travis would be a simple option to use esp. when sling is migrated
> to git and we have one single git repo per module. bertrand pointed
> out there is an official support from ASF to use travis.
> - we could ask infra to support us with our own jenkins instance we
> maintain ourselves. but we do not want to go this way due to its
> maintance efforts unless there is no other way.
> - we decided to stick with the ASF Jenkins for now, and got the way
> to CI builds for each module which robert has already started in
> SLING-6061
> 
> robert currently uses the jenkins job DSL plugin to auto-generate new
> jobs and update existing jobs to the current job definition. the
> source script and job definition template is maintained in svn, as
> soon as this is changed all auto-generated jobs get updated. and
> alternative would be to use the Jenkins pipeline plugin, but
> currently we think creating individual jobs is easier for us to
> understand and maintain.
> 
> some requirements for the ci build ans integration:
> 
> - it would be nice to have a CI build notification within the github
> mirrors of the git modules showing red/green status on each commit
> (which is available e.g. for travis - is it possible with the ASF
> Jenkins as well?)
> 
> - if new branches are created or PRs are submitted a CI build should
> run for them as well, reporting it's status in the github views
> 
> - the CI build should run for the supported JDKs for each module,
> e.g. java7+java8 or java8-only
> 
> - from the git project it the Jenkins CI job should be easy found. if
> a common naming scheme for the Jenkins jobs is used which e.g.
> include the git repo name this should be easy.
> 
> - each CI job has to deploy the current module's snapshot to the
> apache maven snapshot repo, to make it available to other builds.
> 
> 
> stefan
> 
> 
> 



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

2016-10-11 Thread Stefan Seifert (JIRA)

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

Stefan Seifert commented on SLING-6115:
---

Completed: At revision: 1764356  

because the current impl of web console plugin is broken i've disabled it for 
now.

> 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 1.0.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] [Resolved] (SLING-6061) Create per-module Jenkins jobs

2016-10-11 Thread Robert Munteanu (JIRA)

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

Robert Munteanu resolved SLING-6061.

Resolution: Fixed

All module jobs are now modularised. Any follow-up fixes will be handled 
separately.

> Create per-module Jenkins jobs
> --
>
> Key: SLING-6061
> URL: https://issues.apache.org/jira/browse/SLING-6061
> Project: Sling
>  Issue Type: Improvement
>  Components: General
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>
> As discussed on [dev@sling: CI alternatives for 
> Sling|http://markmail.org/message/mdn4anwe6kxqxa2z] we should investigate 
> generating per-module builds instead of having 'full' builds.
> The reason is that our currently large builds are slow and feedback is 
> useless since most of the times at least one module is failing.
> We will first prototype a build using the Jenkins [Job DSL 
> Plugin|https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin], which 
> will allow us to programatically define what build jobs are generated and 
> their configuration.
> The proposed approach is to gradually transfer project from a large job to 
> per-module jobs, using the following mechanism ( details to be filled in ):
> * create a mechanism which will allow us to skip building some modules on 
> Jenkins
> * create a Jenkins DSL Job config in SVN which will generate builds for 
> specific modules ( the i18n module is a good candidate, since it is flaky on 
> Jenkins recently )
> * exclude the 'modularised' build modules from the main build
> In time, we will move out all bundle modules from the current reactor and we 
> should have the following main classes of build jobs:
> * bundles
> * launchpads ( main, contrib, etc )
> * utility modules ( testing )
> * integration tests
> * tooling/maven
> * tooling/ide
> Note that this does not exclude 'bigger' modules like for instance Sightly 
> which contain bundles, content and integration tests. At first I'd like to 
> get a feel of what solution is best for us.



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


[GitHub] sling pull request #182: Adding dateFormat

2016-10-11 Thread heervisscher
GitHub user heervisscher opened a pull request:

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

Adding dateFormat

PR to test the flow...

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

$ git pull https://github.com/heervisscher/sling SLING-6102

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

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

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

This closes #182


commit 8d7adc7afec6b38c275df89642e42a7701bfe735
Author: Feike Visser 
Date:   2016-10-11T20:59:51Z

Adding dateFormat




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


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

2016-10-11 Thread Stefan Seifert (JIRA)

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

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

Completed: At revision: 1764347  


> 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 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-6136) Remove workaround for KARAF-4760 (FELIX-5261, comments in *.config files)

2016-10-11 Thread Oliver Lietz (JIRA)

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

Oliver Lietz updated SLING-6136:

Component/s: Karaf

> Remove workaround for KARAF-4760 (FELIX-5261, comments in *.config files)
> -
>
> Key: SLING-6136
> URL: https://issues.apache.org/jira/browse/SLING-6136
> Project: Sling
>  Issue Type: Task
>  Components: Karaf
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Karaf Features 0.2.0, Karaf Distribution 0.2.0, Karaf 
> Configs 0.2.0
>
>
> workaround added in [r1764341|https://svn.apache.org/r1764341] (using cfg 
> format)



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


[jira] [Created] (SLING-6136) Remove workaround for KARAF-4760 (FELIX-5261, comments in *.config files)

2016-10-11 Thread Oliver Lietz (JIRA)
Oliver Lietz created SLING-6136:
---

 Summary: Remove workaround for KARAF-4760 (FELIX-5261, comments in 
*.config files)
 Key: SLING-6136
 URL: https://issues.apache.org/jira/browse/SLING-6136
 Project: Sling
  Issue Type: Task
Reporter: Oliver Lietz
Assignee: Oliver Lietz
 Fix For: Karaf Features 0.2.0, Karaf Distribution 0.2.0, Karaf 
Configs 0.2.0


workaround added in [r1764341|https://svn.apache.org/r1764341] (using cfg 
format)



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


[jira] [Commented] (SLING-6134) org.apache.sling.samples.jcr.contentloader does not build

2016-10-11 Thread Robert Munteanu (JIRA)

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

Robert Munteanu commented on SLING-6134:


Great, thanks for the quick fix!

> org.apache.sling.samples.jcr.contentloader does not build
> -
>
> Key: SLING-6134
> URL: https://issues.apache.org/jira/browse/SLING-6134
> Project: Sling
>  Issue Type: Bug
>  Components: Samples
>Reporter: Robert Munteanu
>Assignee: Oliver Lietz
>
> The build fails with compilation errors both on Jenkins and locally. [~olli] 
> - since you submitted this module I assigned it to you, but feel free to 
> disagree :-)
> {noformat}[INFO] -
> [ERROR] COMPILATION ERROR : 
> [INFO] -
> [ERROR] 
> /home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[43,42]
>  cannot find symbol
>   symbol:   class BaseContentReader
>   location: package org.apache.sling.jcr.contentloader
> [ERROR] 
> /home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[87,39]
>  cannot find symbol
>   symbol: class BaseContentReader
> [ERROR] 
> /home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[75,29]
>  cannot find symbol
>   symbol:   variable PROPERTY_CONTENTTYPES
>   location: interface org.apache.sling.jcr.contentloader.ContentReader
> [ERROR] 
> /home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[98,9]
>  cannot find symbol
>   symbol:   method configure(org.osgi.service.component.ComponentContext)
>   location: class 
> org.apache.sling.samples.jcr.contentloader.internal.GsonReader
> [ERROR] 
> /home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[104,9]
>  cannot find symbol
>   symbol:   method configure(org.osgi.service.component.ComponentContext)
>   location: class 
> org.apache.sling.samples.jcr.contentloader.internal.GsonReader
> [ERROR] 
> /home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[109,9]
>  cannot find symbol
>   symbol:   variable extensions
>   location: class 
> org.apache.sling.samples.jcr.contentloader.internal.GsonReader
> [ERROR] 
> /home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[110,9]
>  cannot find symbol
>   symbol:   variable contentTypes
>   location: class 
> org.apache.sling.samples.jcr.contentloader.internal.GsonReader
> [INFO] 7 errors {noformat}



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


[jira] [Resolved] (SLING-6134) org.apache.sling.samples.jcr.contentloader does not build

2016-10-11 Thread Oliver Lietz (JIRA)

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

Oliver Lietz resolved SLING-6134.
-
Resolution: Later

moved to whiteboard in [r1764333|https://svn.apache.org/r1764333] and removed 
from builds in [r1764336|https://svn.apache.org/r1764336]

> org.apache.sling.samples.jcr.contentloader does not build
> -
>
> Key: SLING-6134
> URL: https://issues.apache.org/jira/browse/SLING-6134
> Project: Sling
>  Issue Type: Bug
>  Components: Samples
>Reporter: Robert Munteanu
>Assignee: Oliver Lietz
>
> The build fails with compilation errors both on Jenkins and locally. [~olli] 
> - since you submitted this module I assigned it to you, but feel free to 
> disagree :-)
> {noformat}[INFO] -
> [ERROR] COMPILATION ERROR : 
> [INFO] -
> [ERROR] 
> /home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[43,42]
>  cannot find symbol
>   symbol:   class BaseContentReader
>   location: package org.apache.sling.jcr.contentloader
> [ERROR] 
> /home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[87,39]
>  cannot find symbol
>   symbol: class BaseContentReader
> [ERROR] 
> /home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[75,29]
>  cannot find symbol
>   symbol:   variable PROPERTY_CONTENTTYPES
>   location: interface org.apache.sling.jcr.contentloader.ContentReader
> [ERROR] 
> /home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[98,9]
>  cannot find symbol
>   symbol:   method configure(org.osgi.service.component.ComponentContext)
>   location: class 
> org.apache.sling.samples.jcr.contentloader.internal.GsonReader
> [ERROR] 
> /home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[104,9]
>  cannot find symbol
>   symbol:   method configure(org.osgi.service.component.ComponentContext)
>   location: class 
> org.apache.sling.samples.jcr.contentloader.internal.GsonReader
> [ERROR] 
> /home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[109,9]
>  cannot find symbol
>   symbol:   variable extensions
>   location: class 
> org.apache.sling.samples.jcr.contentloader.internal.GsonReader
> [ERROR] 
> /home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[110,9]
>  cannot find symbol
>   symbol:   variable contentTypes
>   location: class 
> org.apache.sling.samples.jcr.contentloader.internal.GsonReader
> [INFO] 7 errors {noformat}



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


Re: [VOTE] Release Apache Sling Scripting Core 2.0.40

2016-10-11 Thread Robert Munteanu
On Tue, 2016-10-11 at 13:51 +, Radu Cotescu wrote:
> Please vote to approve this release:

+1

Robert

signature.asc
Description: This is a digitally signed message part


[jira] [Commented] (SLING-6134) org.apache.sling.samples.jcr.contentloader does not build

2016-10-11 Thread Oliver Lietz (JIRA)

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

Oliver Lietz commented on SLING-6134:
-

[~rombert], I guess this sample is based on my work to make Content Loader 
extensible (but was implemented differently by [~tomek.rekawek]).

> org.apache.sling.samples.jcr.contentloader does not build
> -
>
> Key: SLING-6134
> URL: https://issues.apache.org/jira/browse/SLING-6134
> Project: Sling
>  Issue Type: Bug
>  Components: Samples
>Reporter: Robert Munteanu
>Assignee: Oliver Lietz
>
> The build fails with compilation errors both on Jenkins and locally. [~olli] 
> - since you submitted this module I assigned it to you, but feel free to 
> disagree :-)
> {noformat}[INFO] -
> [ERROR] COMPILATION ERROR : 
> [INFO] -
> [ERROR] 
> /home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[43,42]
>  cannot find symbol
>   symbol:   class BaseContentReader
>   location: package org.apache.sling.jcr.contentloader
> [ERROR] 
> /home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[87,39]
>  cannot find symbol
>   symbol: class BaseContentReader
> [ERROR] 
> /home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[75,29]
>  cannot find symbol
>   symbol:   variable PROPERTY_CONTENTTYPES
>   location: interface org.apache.sling.jcr.contentloader.ContentReader
> [ERROR] 
> /home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[98,9]
>  cannot find symbol
>   symbol:   method configure(org.osgi.service.component.ComponentContext)
>   location: class 
> org.apache.sling.samples.jcr.contentloader.internal.GsonReader
> [ERROR] 
> /home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[104,9]
>  cannot find symbol
>   symbol:   method configure(org.osgi.service.component.ComponentContext)
>   location: class 
> org.apache.sling.samples.jcr.contentloader.internal.GsonReader
> [ERROR] 
> /home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[109,9]
>  cannot find symbol
>   symbol:   variable extensions
>   location: class 
> org.apache.sling.samples.jcr.contentloader.internal.GsonReader
> [ERROR] 
> /home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[110,9]
>  cannot find symbol
>   symbol:   variable contentTypes
>   location: class 
> org.apache.sling.samples.jcr.contentloader.internal.GsonReader
> [INFO] 7 errors {noformat}



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


[jira] [Updated] (SLING-6135) ResourceEditor build failure on Jenkins

2016-10-11 Thread Robert Munteanu (JIRA)

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

Robert Munteanu updated SLING-6135:
---
Description: 
The resource editor fails to build on Jenkins, and I have no idea how to tackle 
the node build error. [~sandro] - IIRC you were the one who contributed the 
module, perhaps you have an idea about how to fix the build.

The error lines that I spotted are:

* {{[ERROR] gyp_main.py: error: no such option: --no-parallel}}
* {{[ERROR] node-pre-gyp ERR! stack Error: Failed to execute 'node-gyp 
configure --fallback-to-build 
--module=/home/jenkins/jenkins-slave/workspace/sling-contrib-explorers-resourceeditor-1.7/frontend/node_modules/grunt-node-inspector/node_modules/node-inspector/node_modules/v8-debug/build/debug/v0.4.6/node-v14-linux-x64/debug.node
 --module_name=debug 
--module_path=/home/jenkins/jenkins-slave/workspace/sling-contrib-explorers-resourceeditor-1.7/frontend/node_modules/grunt-node-inspector/node_modules/node-inspector/node_modules/v8-debug/build/debug/v0.4.6/node-v14-linux-x64'
 (1)}}
* {{[ERROR] Error: Cannot find module './pre-binding'}}

  was:
The resource editor fails to build on Jenkins, and I have no idea how to tackle 
the node build error. [~sandro] - IIRC you were the one which contributed the 
module, perhaps you have an idea about how to fix the build.

The error lines that I spotted are:

* {{[ERROR] gyp_main.py: error: no such option: --no-parallel}}
* {{[ERROR] node-pre-gyp ERR! stack Error: Failed to execute 'node-gyp 
configure --fallback-to-build 
--module=/home/jenkins/jenkins-slave/workspace/sling-contrib-explorers-resourceeditor-1.7/frontend/node_modules/grunt-node-inspector/node_modules/node-inspector/node_modules/v8-debug/build/debug/v0.4.6/node-v14-linux-x64/debug.node
 --module_name=debug 
--module_path=/home/jenkins/jenkins-slave/workspace/sling-contrib-explorers-resourceeditor-1.7/frontend/node_modules/grunt-node-inspector/node_modules/node-inspector/node_modules/v8-debug/build/debug/v0.4.6/node-v14-linux-x64'
 (1)}}
* {{[ERROR] Error: Cannot find module './pre-binding'}}


> ResourceEditor build failure on Jenkins
> ---
>
> Key: SLING-6135
> URL: https://issues.apache.org/jira/browse/SLING-6135
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Robert Munteanu
>Assignee: Sandro Boehme
> Attachments: resourceeditor_failure.txt
>
>
> The resource editor fails to build on Jenkins, and I have no idea how to 
> tackle the node build error. [~sandro] - IIRC you were the one who 
> contributed the module, perhaps you have an idea about how to fix the build.
> The error lines that I spotted are:
> * {{[ERROR] gyp_main.py: error: no such option: --no-parallel}}
> * {{[ERROR] node-pre-gyp ERR! stack Error: Failed to execute 'node-gyp 
> configure --fallback-to-build 
> --module=/home/jenkins/jenkins-slave/workspace/sling-contrib-explorers-resourceeditor-1.7/frontend/node_modules/grunt-node-inspector/node_modules/node-inspector/node_modules/v8-debug/build/debug/v0.4.6/node-v14-linux-x64/debug.node
>  --module_name=debug 
> --module_path=/home/jenkins/jenkins-slave/workspace/sling-contrib-explorers-resourceeditor-1.7/frontend/node_modules/grunt-node-inspector/node_modules/node-inspector/node_modules/v8-debug/build/debug/v0.4.6/node-v14-linux-x64'
>  (1)}}
> * {{[ERROR] Error: Cannot find module './pre-binding'}}



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


[jira] [Updated] (SLING-6135) ResourceEditor build failure on Jenkins

2016-10-11 Thread Robert Munteanu (JIRA)

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

Robert Munteanu updated SLING-6135:
---
Attachment: resourceeditor_failure.txt

> ResourceEditor build failure on Jenkins
> ---
>
> Key: SLING-6135
> URL: https://issues.apache.org/jira/browse/SLING-6135
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Robert Munteanu
>Assignee: Sandro Boehme
> Attachments: resourceeditor_failure.txt
>
>
> The resource editor fails to build on Jenkins, and I have no idea how to 
> tackle the node build error. [~sandro] - IIRC you were the one which 
> contributed the module, perhaps you have an idea about how to fix the build.
> The error lines that I spotted are:
> * {{[ERROR] gyp_main.py: error: no such option: --no-parallel}}
> * {{[ERROR] node-pre-gyp ERR! stack Error: Failed to execute 'node-gyp 
> configure --fallback-to-build 
> --module=/home/jenkins/jenkins-slave/workspace/sling-contrib-explorers-resourceeditor-1.7/frontend/node_modules/grunt-node-inspector/node_modules/node-inspector/node_modules/v8-debug/build/debug/v0.4.6/node-v14-linux-x64/debug.node
>  --module_name=debug 
> --module_path=/home/jenkins/jenkins-slave/workspace/sling-contrib-explorers-resourceeditor-1.7/frontend/node_modules/grunt-node-inspector/node_modules/node-inspector/node_modules/v8-debug/build/debug/v0.4.6/node-v14-linux-x64'
>  (1)}}
> * {{[ERROR] Error: Cannot find module './pre-binding'}}



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


[jira] [Created] (SLING-6135) ResourceEditor build failure on Jenkins

2016-10-11 Thread Robert Munteanu (JIRA)
Robert Munteanu created SLING-6135:
--

 Summary: ResourceEditor build failure on Jenkins
 Key: SLING-6135
 URL: https://issues.apache.org/jira/browse/SLING-6135
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Reporter: Robert Munteanu
Assignee: Sandro Boehme
 Attachments: resourceeditor_failure.txt

The resource editor fails to build on Jenkins, and I have no idea how to tackle 
the node build error. [~sandro] - IIRC you were the one which contributed the 
module, perhaps you have an idea about how to fix the build.

The error lines that I spotted are:

* {{[ERROR] gyp_main.py: error: no such option: --no-parallel}}
* {{[ERROR] node-pre-gyp ERR! stack Error: Failed to execute 'node-gyp 
configure --fallback-to-build 
--module=/home/jenkins/jenkins-slave/workspace/sling-contrib-explorers-resourceeditor-1.7/frontend/node_modules/grunt-node-inspector/node_modules/node-inspector/node_modules/v8-debug/build/debug/v0.4.6/node-v14-linux-x64/debug.node
 --module_name=debug 
--module_path=/home/jenkins/jenkins-slave/workspace/sling-contrib-explorers-resourceeditor-1.7/frontend/node_modules/grunt-node-inspector/node_modules/node-inspector/node_modules/v8-debug/build/debug/v0.4.6/node-v14-linux-x64'
 (1)}}
* {{[ERROR] Error: Cannot find module './pre-binding'}}



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


[jira] [Commented] (SLING-920) Sling Jenkins setup

2016-10-11 Thread Robert Munteanu (JIRA)

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

Robert Munteanu commented on SLING-920:
---

Disabled the following jobs, as they are replaced by per-module jobs:

* sling-contrib-1.7
* sling-samples-1.7

> Sling Jenkins setup
> ---
>
> Key: SLING-920
> URL: https://issues.apache.org/jira/browse/SLING-920
> Project: Sling
>  Issue Type: Task
>  Components: Testing
>Reporter: Bertrand Delacretaz
>
> Use this issue to record changes to the Jenkins setup at 
> https://builds.apache.org/view/S-Z/view/Sling/



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


[jira] [Updated] (SLING-6134) org.apache.sling.samples.jcr.contentloader does not build

2016-10-11 Thread Oliver Lietz (JIRA)

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

Oliver Lietz updated SLING-6134:

Summary: org.apache.sling.samples.jcr.contentloader does not build  (was: 
org.apache.sling.samples.jcr.contentloader dues not build)

> org.apache.sling.samples.jcr.contentloader does not build
> -
>
> Key: SLING-6134
> URL: https://issues.apache.org/jira/browse/SLING-6134
> Project: Sling
>  Issue Type: Bug
>  Components: Samples
>Reporter: Robert Munteanu
>Assignee: Oliver Lietz
>
> The build fails with compilation errors both on Jenkins and locally. [~olli] 
> - since you submitted this module I assigned it to you, but feel free to 
> disagree :-)
> {noformat}[INFO] -
> [ERROR] COMPILATION ERROR : 
> [INFO] -
> [ERROR] 
> /home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[43,42]
>  cannot find symbol
>   symbol:   class BaseContentReader
>   location: package org.apache.sling.jcr.contentloader
> [ERROR] 
> /home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[87,39]
>  cannot find symbol
>   symbol: class BaseContentReader
> [ERROR] 
> /home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[75,29]
>  cannot find symbol
>   symbol:   variable PROPERTY_CONTENTTYPES
>   location: interface org.apache.sling.jcr.contentloader.ContentReader
> [ERROR] 
> /home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[98,9]
>  cannot find symbol
>   symbol:   method configure(org.osgi.service.component.ComponentContext)
>   location: class 
> org.apache.sling.samples.jcr.contentloader.internal.GsonReader
> [ERROR] 
> /home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[104,9]
>  cannot find symbol
>   symbol:   method configure(org.osgi.service.component.ComponentContext)
>   location: class 
> org.apache.sling.samples.jcr.contentloader.internal.GsonReader
> [ERROR] 
> /home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[109,9]
>  cannot find symbol
>   symbol:   variable extensions
>   location: class 
> org.apache.sling.samples.jcr.contentloader.internal.GsonReader
> [ERROR] 
> /home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[110,9]
>  cannot find symbol
>   symbol:   variable contentTypes
>   location: class 
> org.apache.sling.samples.jcr.contentloader.internal.GsonReader
> [INFO] 7 errors {noformat}



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


[jira] [Created] (SLING-6134) org.apache.sling.samples.jcr.contentloader dues not build

2016-10-11 Thread Robert Munteanu (JIRA)
Robert Munteanu created SLING-6134:
--

 Summary: org.apache.sling.samples.jcr.contentloader dues not build
 Key: SLING-6134
 URL: https://issues.apache.org/jira/browse/SLING-6134
 Project: Sling
  Issue Type: Bug
  Components: Samples
Reporter: Robert Munteanu
Assignee: Oliver Lietz


The build fails with compilation errors both on Jenkins and locally. [~olli] - 
since you submitted this module I assigned it to you, but feel free to disagree 
:-)

{noformat}[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] 
/home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[43,42]
 cannot find symbol
  symbol:   class BaseContentReader
  location: package org.apache.sling.jcr.contentloader
[ERROR] 
/home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[87,39]
 cannot find symbol
  symbol: class BaseContentReader
[ERROR] 
/home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[75,29]
 cannot find symbol
  symbol:   variable PROPERTY_CONTENTTYPES
  location: interface org.apache.sling.jcr.contentloader.ContentReader
[ERROR] 
/home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[98,9]
 cannot find symbol
  symbol:   method configure(org.osgi.service.component.ComponentContext)
  location: class org.apache.sling.samples.jcr.contentloader.internal.GsonReader
[ERROR] 
/home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[104,9]
 cannot find symbol
  symbol:   method configure(org.osgi.service.component.ComponentContext)
  location: class org.apache.sling.samples.jcr.contentloader.internal.GsonReader
[ERROR] 
/home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[109,9]
 cannot find symbol
  symbol:   variable extensions
  location: class org.apache.sling.samples.jcr.contentloader.internal.GsonReader
[ERROR] 
/home/jenkins/jenkins-slave/workspace/sling-samples-org.apache.sling.samples.jcr.contentloader-1.8/src/main/java/org/apache/sling/samples/jcr/contentloader/internal/GsonReader.java:[110,9]
 cannot find symbol
  symbol:   variable contentTypes
  location: class org.apache.sling.samples.jcr.contentloader.internal.GsonReader
[INFO] 7 errors {noformat}



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


[jira] [Updated] (SLING-6133) Refactor Event Utility

2016-10-11 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler updated SLING-6133:

Priority: Trivial  (was: Major)

> Refactor Event Utility 
> ---
>
> Key: SLING-6133
> URL: https://issues.apache.org/jira/browse/SLING-6133
> Project: Sling
>  Issue Type: Improvement
>  Components: Event
>Affects Versions: Event 4.1.0
>Reporter: Jörg Hoh
>Priority: Trivial
> Fix For: Event 4.2.0
>
> Attachments: patch-SLING-6133.diff
>
>
> The Utility.checkJobTopic is a bit cumbersome and also lacks a testcase.



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


[jira] [Updated] (SLING-6133) Refactor Event Utility

2016-10-11 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler updated SLING-6133:

Fix Version/s: Event 4.2.0

> Refactor Event Utility 
> ---
>
> Key: SLING-6133
> URL: https://issues.apache.org/jira/browse/SLING-6133
> Project: Sling
>  Issue Type: Improvement
>  Components: Event
>Affects Versions: Event 4.1.0
>Reporter: Jörg Hoh
>Priority: Trivial
> Fix For: Event 4.2.0
>
> Attachments: patch-SLING-6133.diff
>
>
> The Utility.checkJobTopic is a bit cumbersome and also lacks a testcase.



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


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

2016-10-11 Thread Stefan Seifert (JIRA)

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

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

Completed: At revision: 1764311  


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



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


[jira] [Updated] (SLING-6133) Refactor Event Utility

2016-10-11 Thread JIRA

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

Jörg Hoh updated SLING-6133:

Attachment: patch-SLING-6133.diff

A patch including small improvements to the javadoc and a testcase

> Refactor Event Utility 
> ---
>
> Key: SLING-6133
> URL: https://issues.apache.org/jira/browse/SLING-6133
> Project: Sling
>  Issue Type: Improvement
>  Components: Event
>Affects Versions: Event 4.1.0
>Reporter: Jörg Hoh
> Attachments: patch-SLING-6133.diff
>
>
> The Utility.checkJobTopic is a bit cumbersome and also lacks a testcase.



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


[jira] [Created] (SLING-6133) Refactor Event Utility

2016-10-11 Thread JIRA
Jörg Hoh created SLING-6133:
---

 Summary: Refactor Event Utility 
 Key: SLING-6133
 URL: https://issues.apache.org/jira/browse/SLING-6133
 Project: Sling
  Issue Type: Improvement
  Components: Event
Affects Versions: Event 4.1.0
Reporter: Jörg Hoh


The Utility.checkJobTopic is a bit cumbersome and also lacks a testcase.



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


[jira] [Resolved] (SLING-6132) ResourceBuilder: Use absolute resource path should switch to hierachy mode

2016-10-11 Thread Stefan Seifert (JIRA)

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

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

Completed: At revision: 1764295  


> ResourceBuilder: Use absolute resource path should switch to hierachy mode
> --
>
> Key: SLING-6132
> URL: https://issues.apache.org/jira/browse/SLING-6132
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Resource Builder 1.0.0
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
> Fix For: Resource Builder 1.0.2
>
>
> when using an absolute resource path the resource build should implicitly 
> switch back to hierarchy mode from this point on - otherwise it will create 
> unexpected results for further resource creations.



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


[jira] [Created] (SLING-6132) ResourceBuilder: Use absolute resource path should switch to hierachy mode

2016-10-11 Thread Stefan Seifert (JIRA)
Stefan Seifert created SLING-6132:
-

 Summary: ResourceBuilder: Use absolute resource path should switch 
to hierachy mode
 Key: SLING-6132
 URL: https://issues.apache.org/jira/browse/SLING-6132
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Resource Builder 1.0.0
Reporter: Stefan Seifert
Assignee: Stefan Seifert
 Fix For: Resource Builder 1.0.2


when using an absolute resource path the resource build should implicitly 
switch back to hierarchy mode from this point on - otherwise it will create 
unexpected results for further resource creations.



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


[GitHub] sling pull request #181: Issue/sling 5135

2016-10-11 Thread bdelacretaz
Github user bdelacretaz closed the pull request at:

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


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


[jira] [Commented] (SLING-5135) Whitelist legit usages of loginAdministrative and administrative ResourceResolver

2016-10-11 Thread Bertrand Delacretaz (JIRA)

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

Bertrand Delacretaz commented on SLING-5135:


I have committed the bundles/ changes in revision 1764281, still working on 
integration in the launchpad modules and tests.

> Whitelist legit usages of loginAdministrative and administrative 
> ResourceResolver
> -
>
> Key: SLING-5135
> URL: https://issues.apache.org/jira/browse/SLING-5135
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Reporter: Antonio Sanso
>Assignee: Bertrand Delacretaz
> Attachments: SLING-5135.patch, SLING-5135.patch
>
>
> {{AbstractSlingRepositoryManager}} contains a method that disable 
> loginAdministrative support
> {code}
> /**
>  * Returns whether to disable the
>  * {@code SlingRepository.loginAdministrative} method or not.
>  *
>  * @return {@code true} if {@code SlingRepository.loginAdministrative} is
>  * disabled.
>  */
> public final boolean isDisableLoginAdministrative() 
> {code}
> This is a global configuration. It would be nice to have an extension of such 
> mechanism that contains a white list of (few) legit usage of 
> {{loginAdministrative}}



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


[jira] [Comment Edited] (SLING-6131) MapEntries: Invalid logic around added/changed/removed property names

2016-10-11 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler edited comment on SLING-6131 at 10/11/16 3:51 PM:
---

It seems the "else" part is not sending an OSGi event if the mapping changed. 
Testing a fix now...


was (Author: cziegeler):
It seems the "else" part is not sending an OSGi event if the mapping changed.

> MapEntries: Invalid logic around added/changed/removed property names
> -
>
> Key: SLING-6131
> URL: https://issues.apache.org/jira/browse/SLING-6131
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Reporter: Bertrand Delacretaz
>Assignee: Carsten Ziegeler
>Priority: Critical
> Fix For: Resource Resolver 1.4.20
>
>
> The SLING-6000 changes have introduced code that looks incorrect and breaks a 
> number of integration tests (MappingEventsProxyTest, 
> ResourceResolverProxyTest, VanityPathTest) as (for example) changing a single 
> property of a map entry does not cause MapEntries to send events anymore.
> In the affected code below, from the MapEntries class, the changedAttributes 
> and removedAttributes section are not reached if addedAttributes is null, I 
> don't think that's intentional.
> [~cziegeler] could you have a look? I have assigned this to you as IIUC you 
> wrote that SLING-6000 code.
> This is blocking SLING-5135 but I'll commit that code and disable the 
> affected integration tests until this is fixed.
> {code}
> Set addedAttributes = rc.getAddedPropertyNames();
> if (addedAttributes != null) {
>   ...
>   wasResolverRefreshed = doAddAttributes(path, addedAttributes, 
> wasResolverRefreshed);
>   ...
>   Set changedAttributes = rc.getChangedPropertyNames();
>   ...
>   Set removedAttributes = rc.getRemovedPropertyNames();
> } else {
> {code}



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


[jira] [Commented] (SLING-6131) MapEntries: Invalid logic around added/changed/removed property names

2016-10-11 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler commented on SLING-6131:
-

It seems the "else" part is not sending an OSGi event if the mapping changed.

> MapEntries: Invalid logic around added/changed/removed property names
> -
>
> Key: SLING-6131
> URL: https://issues.apache.org/jira/browse/SLING-6131
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Reporter: Bertrand Delacretaz
>Assignee: Carsten Ziegeler
>Priority: Critical
> Fix For: Resource Resolver 1.4.20
>
>
> The SLING-6000 changes have introduced code that looks incorrect and breaks a 
> number of integration tests (MappingEventsProxyTest, 
> ResourceResolverProxyTest, VanityPathTest) as (for example) changing a single 
> property of a map entry does not cause MapEntries to send events anymore.
> In the affected code below, from the MapEntries class, the changedAttributes 
> and removedAttributes section are not reached if addedAttributes is null, I 
> don't think that's intentional.
> [~cziegeler] could you have a look? I have assigned this to you as IIUC you 
> wrote that SLING-6000 code.
> This is blocking SLING-5135 but I'll commit that code and disable the 
> affected integration tests until this is fixed.
> {code}
> Set addedAttributes = rc.getAddedPropertyNames();
> if (addedAttributes != null) {
>   ...
>   wasResolverRefreshed = doAddAttributes(path, addedAttributes, 
> wasResolverRefreshed);
>   ...
>   Set changedAttributes = rc.getChangedPropertyNames();
>   ...
>   Set removedAttributes = rc.getRemovedPropertyNames();
> } else {
> {code}



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


[jira] [Commented] (SLING-6131) MapEntries: Invalid logic around added/changed/removed property names

2016-10-11 Thread Bertrand Delacretaz (JIRA)

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

Bertrand Delacretaz commented on SLING-6131:


Ok, I see, so I suppose something else is wrong as this breaks the mentioned 
tests: if you create a new mapping the 
{{TOPIC_RESOURCE_RESOLVER_MAPPING_CHANGED}} events are correctly delivered, but 
if you later change its {{sling:vanityPath}} property, for example, no such 
events are generated.

> MapEntries: Invalid logic around added/changed/removed property names
> -
>
> Key: SLING-6131
> URL: https://issues.apache.org/jira/browse/SLING-6131
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Reporter: Bertrand Delacretaz
>Assignee: Carsten Ziegeler
>Priority: Critical
> Fix For: Resource Resolver 1.4.20
>
>
> The SLING-6000 changes have introduced code that looks incorrect and breaks a 
> number of integration tests (MappingEventsProxyTest, 
> ResourceResolverProxyTest, VanityPathTest) as (for example) changing a single 
> property of a map entry does not cause MapEntries to send events anymore.
> In the affected code below, from the MapEntries class, the changedAttributes 
> and removedAttributes section are not reached if addedAttributes is null, I 
> don't think that's intentional.
> [~cziegeler] could you have a look? I have assigned this to you as IIUC you 
> wrote that SLING-6000 code.
> This is blocking SLING-5135 but I'll commit that code and disable the 
> affected integration tests until this is fixed.
> {code}
> Set addedAttributes = rc.getAddedPropertyNames();
> if (addedAttributes != null) {
>   ...
>   wasResolverRefreshed = doAddAttributes(path, addedAttributes, 
> wasResolverRefreshed);
>   ...
>   Set changedAttributes = rc.getChangedPropertyNames();
>   ...
>   Set removedAttributes = rc.getRemovedPropertyNames();
> } else {
> {code}



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


[jira] [Updated] (SLING-6131) MapEntries: Invalid logic around added/changed/removed property names

2016-10-11 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler updated SLING-6131:

Fix Version/s: Resource Resolver 1.4.20

> MapEntries: Invalid logic around added/changed/removed property names
> -
>
> Key: SLING-6131
> URL: https://issues.apache.org/jira/browse/SLING-6131
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Reporter: Bertrand Delacretaz
>Assignee: Carsten Ziegeler
>Priority: Minor
> Fix For: Resource Resolver 1.4.20
>
>
> The SLING-6000 changes have introduced code that looks incorrect and breaks a 
> number of integration tests (MappingEventsProxyTest, 
> ResourceResolverProxyTest, VanityPathTest) as (for example) changing a single 
> property of a map entry does not cause MapEntries to send events anymore.
> In the affected code below, from the MapEntries class, the changedAttributes 
> and removedAttributes section are not reached if addedAttributes is null, I 
> don't think that's intentional.
> [~cziegeler] could you have a look? I have assigned this to you as IIUC you 
> wrote that SLING-6000 code.
> This is blocking SLING-5135 but I'll commit that code and disable the 
> affected integration tests until this is fixed.
> {code}
> Set addedAttributes = rc.getAddedPropertyNames();
> if (addedAttributes != null) {
>   ...
>   wasResolverRefreshed = doAddAttributes(path, addedAttributes, 
> wasResolverRefreshed);
>   ...
>   Set changedAttributes = rc.getChangedPropertyNames();
>   ...
>   Set removedAttributes = rc.getRemovedPropertyNames();
> } else {
> {code}



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


[jira] [Updated] (SLING-6131) MapEntries: Invalid logic around added/changed/removed property names

2016-10-11 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler updated SLING-6131:

Priority: Critical  (was: Minor)

> MapEntries: Invalid logic around added/changed/removed property names
> -
>
> Key: SLING-6131
> URL: https://issues.apache.org/jira/browse/SLING-6131
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Reporter: Bertrand Delacretaz
>Assignee: Carsten Ziegeler
>Priority: Critical
> Fix For: Resource Resolver 1.4.20
>
>
> The SLING-6000 changes have introduced code that looks incorrect and breaks a 
> number of integration tests (MappingEventsProxyTest, 
> ResourceResolverProxyTest, VanityPathTest) as (for example) changing a single 
> property of a map entry does not cause MapEntries to send events anymore.
> In the affected code below, from the MapEntries class, the changedAttributes 
> and removedAttributes section are not reached if addedAttributes is null, I 
> don't think that's intentional.
> [~cziegeler] could you have a look? I have assigned this to you as IIUC you 
> wrote that SLING-6000 code.
> This is blocking SLING-5135 but I'll commit that code and disable the 
> affected integration tests until this is fixed.
> {code}
> Set addedAttributes = rc.getAddedPropertyNames();
> if (addedAttributes != null) {
>   ...
>   wasResolverRefreshed = doAddAttributes(path, addedAttributes, 
> wasResolverRefreshed);
>   ...
>   Set changedAttributes = rc.getChangedPropertyNames();
>   ...
>   Set removedAttributes = rc.getRemovedPropertyNames();
> } else {
> {code}



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


[jira] [Commented] (SLING-6131) MapEntries: Invalid logic around added/changed/removed property names

2016-10-11 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler commented on SLING-6131:
-

[~bdelacretaz] The change is actually intentional. If the addedAttributes is 
null, it means that no information about attributes is delivered. Only if it is 
not null, it means that added/changed/removed are reported, it might be empty 
in this case.
Nevertheless, if it is null it goes into the else case which should work 
nevertheless

> MapEntries: Invalid logic around added/changed/removed property names
> -
>
> Key: SLING-6131
> URL: https://issues.apache.org/jira/browse/SLING-6131
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Reporter: Bertrand Delacretaz
>Assignee: Carsten Ziegeler
>Priority: Minor
>
> The SLING-6000 changes have introduced code that looks incorrect and breaks a 
> number of integration tests (MappingEventsProxyTest, 
> ResourceResolverProxyTest, VanityPathTest) as (for example) changing a single 
> property of a map entry does not cause MapEntries to send events anymore.
> In the affected code below, from the MapEntries class, the changedAttributes 
> and removedAttributes section are not reached if addedAttributes is null, I 
> don't think that's intentional.
> [~cziegeler] could you have a look? I have assigned this to you as IIUC you 
> wrote that SLING-6000 code.
> This is blocking SLING-5135 but I'll commit that code and disable the 
> affected integration tests until this is fixed.
> {code}
> Set addedAttributes = rc.getAddedPropertyNames();
> if (addedAttributes != null) {
>   ...
>   wasResolverRefreshed = doAddAttributes(path, addedAttributes, 
> wasResolverRefreshed);
>   ...
>   Set changedAttributes = rc.getChangedPropertyNames();
>   ...
>   Set removedAttributes = rc.getRemovedPropertyNames();
> } else {
> {code}



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


[GitHub] sling pull request #181: Issue/sling 5135

2016-10-11 Thread bdelacretaz
GitHub user bdelacretaz opened a pull request:

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

Issue/sling 5135

Ready to commit this

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

$ git pull https://github.com/bdelacretaz/sling issue/SLING-5135

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

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

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

This closes #181


commit fe8f9559bda6ba5a05c01bba6a85e640fb8ac143
Author: Bertrand Delacretaz 
Date:   2016-10-10T12:44:15Z

SLING-5135 - whitelist works for both loginAdministrative and 
getAdministrativeResourceResolver

commit 72d87914e4979368dbf15b49634b9d4eee71687c
Author: Bertrand Delacretaz 
Date:   2016-10-10T12:45:00Z

SLING-5135 - disable one test that fails since updating to latest 
snapshots. Apparently unrelated to whitelist implementation.

commit 11deaf70fe81c2f8529143c1a348792d692b5624
Author: Bertrand Delacretaz 
Date:   2016-10-10T12:45:47Z

SLING-5135 - update to latest snapshots to include login admin whitelist. 
Causes some other tests to fail

commit e131df5d34fdb61f0adf15749c4dbcfb63397270
Author: Bertrand Delacretaz 
Date:   2016-10-10T13:42:20Z

SLING-5135 - test passes now that missing default login admin whitelistings 
have been added

commit eec9d8791d3c6da65d57df7129b6e9fa051b792b
Author: Bertrand Delacretaz 
Date:   2016-10-11T12:09:07Z

MapEntries: add calling bundle info

commit 448a3fa4b729320008357445bb6b4a8f35a9edae
Author: Bertrand Delacretaz 
Date:   2016-10-11T14:16:23Z

Fix get property bug




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


[jira] [Updated] (SLING-6130) Restrict access for principal everyone and move configuration to repoinit

2016-10-11 Thread Oliver Lietz (JIRA)

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

Oliver Lietz updated SLING-6130:

Description: 
Currently {{everyone}} can {{read}} from {{/}} (configured in 
{{OakSlingRepositoryManager}}).

Access for {{everyone}} should be restricted:

* {{read}} should be restricted to {{/content}}
* configuration of principals and ACLs should be done with _repoinit_

# Change path from {{/}} to {{/content}} in {{OakSlingRepositoryManager}} (/) 
([r1764259|https://svn.apache.org/r1764259])
# Fix modules (samples) relying on _unrestricted_ {{read}} access
# Move configuration of ACLs to _repoinit_

discussion on 
[dev@|https://lists.apache.org/thread.html/36908ed62ac93c63cad594a897f8abceb93f08da5bcea30dbce98e58@%3Cdev.sling.apache.org%3E]

  was:
Currently {{everyone}} can {{read}} from {{/}} (configured in 
{{OakSlingRepositoryManager}}).

Access for {{everyone}} should be restricted:

* {{read}} should be restricted to {{/content}}
* configuration of principals and ACLs should be done with _repoinit_

# Change path from {{/}} to {{/content}} in {{OakSlingRepositoryManager}}
# Fix modules (samples) relying on _unrestricted_ {{read}} access
# Move configuration of ACLs to _repoinit_

discussion on 
[dev@|https://lists.apache.org/thread.html/36908ed62ac93c63cad594a897f8abceb93f08da5bcea30dbce98e58@%3Cdev.sling.apache.org%3E]


> Restrict access for principal everyone and move configuration to repoinit
> -
>
> Key: SLING-6130
> URL: https://issues.apache.org/jira/browse/SLING-6130
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR, Oak
>Affects Versions: JCR Oak Server 1.1.0
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>  Labels: security
> Fix For: JCR Oak Server 1.1.2
>
>
> Currently {{everyone}} can {{read}} from {{/}} (configured in 
> {{OakSlingRepositoryManager}}).
> Access for {{everyone}} should be restricted:
> * {{read}} should be restricted to {{/content}}
> * configuration of principals and ACLs should be done with _repoinit_
> # Change path from {{/}} to {{/content}} in {{OakSlingRepositoryManager}} (/) 
> ([r1764259|https://svn.apache.org/r1764259])
> # Fix modules (samples) relying on _unrestricted_ {{read}} access
> # Move configuration of ACLs to _repoinit_
> discussion on 
> [dev@|https://lists.apache.org/thread.html/36908ed62ac93c63cad594a897f8abceb93f08da5bcea30dbce98e58@%3Cdev.sling.apache.org%3E]



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


Re: Build failed in Jenkins: sling-launchpad-builder-1.8 #33

2016-10-11 Thread Robert Munteanu
On Tue, 2016-10-11 at 14:33 +, Apache Jenkins Server wrote:
See 

java.io.IOException: Failed to mkdirs: 


Definitely looks like a Jenkins issue, filed

  https://issues.apache.org/jira/browse/INFRA-12747

Robert


Re: [VOTE] Release Apache Sling Scripting Core 2.0.40

2016-10-11 Thread Carsten Ziegeler
+1

 

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



[jira] [Commented] (SLING-5135) Whitelist legit usages of loginAdministrative and administrative ResourceResolver

2016-10-11 Thread Bertrand Delacretaz (JIRA)

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

Bertrand Delacretaz commented on SLING-5135:


The failing integration tests are caused by SLING-6131 in addition to 
MapEntries not providing the calling bundle.

> Whitelist legit usages of loginAdministrative and administrative 
> ResourceResolver
> -
>
> Key: SLING-5135
> URL: https://issues.apache.org/jira/browse/SLING-5135
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Reporter: Antonio Sanso
>Assignee: Bertrand Delacretaz
> Attachments: SLING-5135.patch, SLING-5135.patch
>
>
> {{AbstractSlingRepositoryManager}} contains a method that disable 
> loginAdministrative support
> {code}
> /**
>  * Returns whether to disable the
>  * {@code SlingRepository.loginAdministrative} method or not.
>  *
>  * @return {@code true} if {@code SlingRepository.loginAdministrative} is
>  * disabled.
>  */
> public final boolean isDisableLoginAdministrative() 
> {code}
> This is a global configuration. It would be nice to have an extension of such 
> mechanism that contains a white list of (few) legit usage of 
> {{loginAdministrative}}



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


[jira] [Created] (SLING-6131) MapEntries: Invalid logic around added/changed/removed property names

2016-10-11 Thread Bertrand Delacretaz (JIRA)
Bertrand Delacretaz created SLING-6131:
--

 Summary: MapEntries: Invalid logic around added/changed/removed 
property names
 Key: SLING-6131
 URL: https://issues.apache.org/jira/browse/SLING-6131
 Project: Sling
  Issue Type: Bug
  Components: ResourceResolver
Reporter: Bertrand Delacretaz
Assignee: Carsten Ziegeler
Priority: Minor


The SLING-6000 changes have introduced code that looks incorrect and breaks a 
number of integration tests (MappingEventsProxyTest, ResourceResolverProxyTest, 
VanityPathTest) as (for example) changing a single property of a map entry does 
not cause MapEntries to send events anymore.

In the affected code below, from the MapEntries class, the changedAttributes 
and removedAttributes section are not reached if addedAttributes is null, I 
don't think that's intentional.

[~cziegeler] could you have a look? I have assigned this to you as IIUC you 
wrote that SLING-6000 code.

This is blocking SLING-5135 but I'll commit that code and disable the affected 
integration tests until this is fixed.

{code}
Set addedAttributes = rc.getAddedPropertyNames();
if (addedAttributes != null) {
  ...
  wasResolverRefreshed = doAddAttributes(path, addedAttributes, 
wasResolverRefreshed);
  ...
  Set changedAttributes = rc.getChangedPropertyNames();
  ...
  Set removedAttributes = rc.getRemovedPropertyNames();
} else {
{code}




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


Re: [VOTE] Release Apache Sling Scripting Core 2.0.40

2016-10-11 Thread Daniel Klco
+1 - Checked signatures and build

On Tue, Oct 11, 2016 at 9:51 AM, Radu Cotescu  wrote:

> Hi,
>
> We solved 2 issues for this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12337945
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1533
>
> You can use this UNIX script to download the releases and verify the
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 1533 /tmp/sling-staging
>
> Please vote to approve this release:
>
>   [ ] +1 Approve the release
>   [ ]  0 Don't care
>   [ ] -1 Don't release, because ...
>
> This majority vote is open for at least 72 hours.
>
> Cheers,
> Radu
>


[jira] [Updated] (SLING-6129) Sling IDE: Support bnd-maven-plugin as well

2016-10-11 Thread Konrad Windszus (JIRA)

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

Konrad Windszus updated SLING-6129:
---
Attachment: SLING-6129-v01.patch

This patch comprises all changes from SLING-6112-v03 and in addition adds 
support for bnd-maven-plugin.
[~rombert] Please have a look.

> Sling IDE: Support bnd-maven-plugin as well
> ---
>
> Key: SLING-6129
> URL: https://issues.apache.org/jira/browse/SLING-6129
> Project: Sling
>  Issue Type: Improvement
>  Components: IDE
>Affects Versions: Sling Eclipse IDE 1.1.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Attachments: SLING-6129-v01.patch
>
>
> Currently the project configurator being added in SLING-3612 is only bound to 
> to the goals "manifest" and "bundle" of the maven-bundle-plugin. It should 
> also be automatically called for goal "bnd-process" of the bnd-maven-plugin 
> (https://github.com/bndtools/bnd/tree/master/maven/bnd-maven-plugin).



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


[VOTE] Release Apache Sling Scripting Core 2.0.40

2016-10-11 Thread Radu Cotescu
Hi,

We solved 2 issues for this release:
https://issues.apache.org/jira/browse/SLING/fixforversion/12337945

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

You can use this UNIX script to download the releases and verify the
signatures:
http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 1533 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Cheers,
Radu


[jira] [Created] (SLING-6130) Restrict access for principal everyone and move configuration to repoinit

2016-10-11 Thread Oliver Lietz (JIRA)
Oliver Lietz created SLING-6130:
---

 Summary: Restrict access for principal everyone and move 
configuration to repoinit
 Key: SLING-6130
 URL: https://issues.apache.org/jira/browse/SLING-6130
 Project: Sling
  Issue Type: Improvement
  Components: JCR, Oak
Affects Versions: JCR Oak Server 1.1.0
Reporter: Oliver Lietz
Assignee: Oliver Lietz
 Fix For: JCR Oak Server 1.1.2


Currently {{everyone}} can {{read}} from {{/}} (configured in 
{{OakSlingRepositoryManager}}).

Access for {{everyone}} should be restricted:

* {{read}} should be restricted to {{/content}}
* configuration of principals and ACLs should be done with _repoinit_

# Change path from {{/}} to {{/content}} in {{OakSlingRepositoryManager}}
# Fix modules (samples) relying on _unrestricted_ {{read}} access
# Move configuration of ACLs to _repoinit_

discussion on 
[dev@|https://lists.apache.org/thread.html/36908ed62ac93c63cad594a897f8abceb93f08da5bcea30dbce98e58@%3Cdev.sling.apache.org%3E]



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


Re: restricting access for the "everyone" principal

2016-10-11 Thread Oliver Lietz
On Thursday 06 October 2016 13:38:28 Carsten Ziegeler wrote:
> Bertrand Delacretaz wrote
> 
> > Hi,
> > 
> > On Thu, Oct 6, 2016 at 12:03 PM, Radu Cotescu  wrote:
> >> ...Should we change this and only allow "jcr:read" on a new /content
> >> folder
> >> for "everyone"?...
> > 
> > That might break a number of integration tests, I guess a dry run is
> > needed before making a decision, to see how much work is needed to fix
> > them.
> 
> And while I think this restriction makes sense it might also break
> samples which do not use /content.
> This can be fixed of course, but if me make this change we shouldn't
> forget to adjust those things

As it seems we agree on restricting access for everyone, I will change the 
path from "/" to "/content" in OakSlingRepositoryManager in a first step and 
await what breaks (SLING-6130).

Regards,
O.

> Carsten



[jira] [Commented] (SLING-6070) Reduce temporary storage required in JcrResourceListener, call reportChanges earlier

2016-10-11 Thread Stefan Egli (JIRA)

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

Stefan Egli commented on SLING-6070:


bq. Since Oak uses a breadth-first tree traversal when compiling the jcr 
events, this fact can be used to detect the earliest possible moment to forward 
events, which is as soon as a child traversal has finished. That way, only 
parent changes need to be kept, not the entire tree of changes.
Unlike written in the comment, Sling should not make this assumption. So this 
statement is actually wrong/useless

> Reduce temporary storage required in JcrResourceListener, call reportChanges 
> earlier
> 
>
> Key: SLING-6070
> URL: https://issues.apache.org/jira/browse/SLING-6070
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Affects Versions: JCR Resource 2.8.0
>Reporter: Stefan Egli
> Fix For: JCR Resource 2.8.2
>
>
> As noticed in OAK-4581 
> ([here|https://issues.apache.org/jira/browse/OAK-4581?focusedCommentId=15525601=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15525601])
>  one advantage of using OakResourceListener over JcrResourceListener (hence 
> the term 'optimize for oak' of the config parameter) is that 
> OakResourceListener uses a NodeObserver, which calls added/removed/changed 
> after each child traversal has finished. This will in turn be used by the 
> OakResourceListener to call ObservationReporter.reportChanges. In the 
> JcrResourceListener.onEvent case however this is not possible, as the events 
> are delivered for each node/property individually, and they first have to be 
> 'mapped' to ResourceChanges. This is currently done by keeping maps of 
> added/removed/changed ResourceChanges and only after all events (that are 
> passed in 1 onEvent) are processed is reportChanges invoked. This has the 
> downside of a potentially very large temporary memory usage (these maps can 
> get big).
> A suggested improvement is to follow the same pattern as is done in the 
> OakResourceListener/NodeObserver pair: to forward the events (by callling 
> reportChanges) as early as possible. Since Oak uses a breadth-first tree 
> traversal when compiling the jcr events, this fact can be used to detect the 
> earliest possible moment to forward events, which is as soon as a child 
> traversal has finished. That way, only parent changes need to be kept, not 
> the entire tree of changes.



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


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

2016-10-11 Thread Konrad Windszus (JIRA)

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

Konrad Windszus updated SLING-6112:
---
Attachment: SLING-6112-v03.patch

Attached is a third version of the fix which
# adds markers and according quick fixes in case incremental build is not 
correctly set up (with a suggestion to either download m2e-tycho or use 
maven-bundle-plugin 3.2.0 with correct configuration) 
# fixes a minor glitch with the secondaryTo field
# fixes SLING-6128
# only removes the {{associateSites}} configuration from the 
{{generate-repository-facade}} goal of {{repository-utils}}
[~rombert] Please try again and let me know what you think of this patch

> 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-6128) Sling IDE: Remove Lifecycle Mapping Extension Point for content-package

2016-10-11 Thread Konrad Windszus (JIRA)

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

Konrad Windszus commented on SLING-6128:


The patch v3 attached in SLING-6112 removes the lifecycle mapping.

> Sling IDE: Remove Lifecycle Mapping Extension Point for content-package
> ---
>
> Key: SLING-6128
> URL: https://issues.apache.org/jira/browse/SLING-6128
> Project: Sling
>  Issue Type: Improvement
>  Components: IDE
>Affects Versions: Sling Eclipse IDE 1.1.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>
> The lifecycle mapping code for packaging {{content-package}} being added with 
> SLING-3100 is not necessary and should be removed. 
> Compare with http://www.mail-archive.com/dev@sling.apache.org/msg60234.html.



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


[jira] [Resolved] (SLING-5304) Pattern Broken in resource resolver mapping

2016-10-11 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler resolved SLING-5304.
-
Resolution: Won't Fix

> Pattern Broken in resource resolver mapping
> ---
>
> Key: SLING-5304
> URL: https://issues.apache.org/jira/browse/SLING-5304
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Reporter: Antonio Sanso
>Priority: Minor
>
> Steps to Reproduce:
> Create a Page and add the property vanityPath with the value 
> "/portal_[sS][uU][bB][sS][iI][tT][eE]" to the jcr:conten 
> If you try to resolve  /portal_suBSite this will return NonExistingResource
>  



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


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

2016-10-11 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler reassigned SLING-6066:
---

Assignee: Carsten Ziegeler

> Clarify and complete removal resource events
> 
>
> Key: SLING-6066
> URL: https://issues.apache.org/jira/browse/SLING-6066
> Project: Sling
>  Issue Type: Improvement
>  Components: API, JCR, ResourceResolver
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Blocker
> Fix For: JCR Resource 2.8.2, API 2.15.0, Resource Resolver 1.4.20
>
>
> As recently discussed in the mailing list, if a ResourceChangeListener is 
> interested in removal events, the listener might not get the event it is 
> interested in. For example, if the listener is registered with a glob 
> pattern, like **.jsp, but the parent (or any parent) of a jsp is removed. In 
> that case no removal event for the jsp itself is sent.  Which means the 
> listener is unaware of removals.
> We need to clarify this in the javadocs, but also should implement handling 
> removal in the following:
> If a listener is registered for removal events - regardless if a glob pattern 
> is used or not - the listener will be notified of removals of any parent node 
> up to the top level node. For example if a listener is interested in 
> /a/b/c/**/*.jsp, a removal of any resource below "c", but also removal of 
> "a", "b", or "c" is reported to the listener.



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


[jira] [Commented] (SLING-6126) Ability to specify TTL for separate health check

2016-10-11 Thread Georg Henzler (JIRA)

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

Georg Henzler commented on SLING-6126:
--

If it is a DevOps Setup that checks for the health of an instance after 
deployment, probably it's better to first call
/system/health/regularcheckstag.txt <-- returns quickly for the case something 
basic went wrong
and then 
/system/health/longrunningchecktag.txt?timeout=360 <-- this can be waited 
for synchronously and will return exactly after the long running check is 
finished.

Would that work for you? If not, I'm not opposed to add the TTL config setting 
for individual HCs (see my comments in PR), just questioning if it really 
provides value or just adds additional complexity.

> Ability to specify TTL for separate health check
> 
>
> Key: SLING-6126
> URL: https://issues.apache.org/jira/browse/SLING-6126
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check
>Reporter: Evgeniy Fitsner
>
> Currently there is no ability to specify TTL for separate health check.
> Ex.: in my case "hc" validating against repository about 3-5 minutes 
> therefore I couldn't specify TTL globally to not impact on other "hc" 
> results. This "hc" I couldn't execute by scheduler to prevent CPU from high 
> loading, also results for this check remains relevant for an 1-3 hours.
> Therefore if it make sense not only for me I've added "[pull 
> request|https://github.com/apache/sling/pull/180]; for this functionality:
> * If property "hc.ttl" specified within HC - it will be used as TTL for 
> result, otherwise cache will use default TTL value



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


[jira] [Commented] (SLING-5014) Installer blacklist, to avoid reinstalling older bundles

2016-10-11 Thread JIRA

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

Dominik Süß commented on SLING-5014:


[~cziegeler] - I can revisit this within the next 1-2 weeks. Sorry about the 
reformatting, this was created right after switching a new IDE which had some 
automatisms in there that I was not used to (and forgot to crosscheck the patch 
as I just did search for initial review).  I will crosscheck the osgi installer 
and see how to best hook in there and see how we can make the corresponding 
state handling of OSGi Installer more reliable based on problematic scenarios 
that we worked around or patched in quite brute manner in the past (e.g. 
cleaning osgi installer state cache). So this might take some time until I come 
up with a sequence of patches addressing those issues including the aspect of 
blacklisting.

> Installer blacklist, to avoid reinstalling older bundles
> 
>
> Key: SLING-5014
> URL: https://issues.apache.org/jira/browse/SLING-5014
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Core 3.6.6
>Reporter: Dominik Süß
> Attachments: SLING-5014-1.diff
>
>
> In case a bundle has mutliple install candiates only the highest version 
> (with the highest priorty for the same versions) wins. An uninstall directive 
> in the Sling bootstrap.txt file or provisioning model uninstalls this 
> version. The way the OSGi install behavior is defined this lets the next 
> artifact in the priority queue to get active and consequently only leads to 
> downgrade to the next in the queue.
> As the uninstall directive declares a range that should be uninstalled the 
> expectation is that after a startup with such an uninstall directive none of 
> the declared versions are in an installed state. In consequence the OSGi 
> installer must save this metainformation in the state that prevents a 
> downgrade to a version that is part of an active uninstall directive.



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


[jira] [Created] (SLING-6129) Sling IDE: Support bnd-maven-plugin as well

2016-10-11 Thread Konrad Windszus (JIRA)
Konrad Windszus created SLING-6129:
--

 Summary: Sling IDE: Support bnd-maven-plugin as well
 Key: SLING-6129
 URL: https://issues.apache.org/jira/browse/SLING-6129
 Project: Sling
  Issue Type: Improvement
  Components: IDE
Affects Versions: Sling Eclipse IDE 1.1.0
Reporter: Konrad Windszus
Assignee: Konrad Windszus


Currently the project configurator being added in SLING-3612 is only bound to 
to the goals "manifest" and "bundle" of the maven-bundle-plugin. It should also 
be automatically called for goal "bnd-process" of the bnd-maven-plugin 
(https://github.com/bndtools/bnd/tree/master/maven/bnd-maven-plugin).



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


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

2016-10-11 Thread Stefan Seifert (JIRA)

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

Stefan Seifert reopened SLING-6059:
---

reopening: discussion in mailing list about details of the inheritance property 
handling - we will implement option e)
https://lists.apache.org/thread.html/782a00bd06816bcbcaca43bbb46c9f32d019826ec25e086de9b704a9@%3Cdev.sling.apache.org%3E

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



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


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

2016-10-11 Thread Stefan Seifert (JIRA)

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

Stefan Seifert commented on SLING-6058:
---

discussion in mailing list about details of the inheritance property handling - 
we will implement option e)
https://lists.apache.org/thread.html/782a00bd06816bcbcaca43bbb46c9f32d019826ec25e086de9b704a9@%3Cdev.sling.apache.org%3E

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


RE: [context-aware config] performance impact of inhertiance

2016-10-11 Thread Stefan Seifert

>If we think that inheritance is used sparsely then I think e) is the
>best option - at least it is easy to understand. If you want to have
>inheritance all over the place, it means that you have to set the
>correct property all over the place. But then, this is still the
>approach with less magic or hidden behaviour.

ok, than we will go for e) - the best compromise between flexibility and 
performance.
i will update the impl for SLING-6059 and SLING-6058.

stefan



Re: Sling IDE: Lifecycle Mapping Extension Point

2016-10-11 Thread Konrad Windszus
Just for completeness: This feature of m2e was added in the context of 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=337010 
, so is actually pretty 
old, so we can safely rely on it.

> On 11 Oct 2016, at 09:04, Konrad Windszus  wrote:
> 
> This should not be necessary. Whenever there is an unknown packaging the 
> DefaultLifecycleMapping.java is used which derives from 
> AbstractCustomizableLifecycleMapping as well.
> There is even a test explicitly written for that in 
> https://github.com/tesla/m2e-core-tests/blob/2aea30eae086696da8ffce648c2eea010184b348/org.eclipse.m2e.tests/src/org/eclipse/m2e/tests/lifecycle/LifecycleMappingTest.java#L391
>  
> .
> So I go ahead and remove those parts from the m2e-ui plugin.
> 
>> On 11 Oct 2016, at 01:27, Georg Henzler > > wrote:
>> 
>> If I remember it correctly, it was needed to make the project configurator 
>> work at all. Note that ContentPackageLifecycleMapping is not just empty but 
>> extends AbstractCustomizableLifecycleMapping [1] and this code only becomes 
>> active for content packages because of the reference chain [2]. But maybe 
>> the situation has changed with current m2e versions, might be worth checking 
>> what impact removing the ContentPackageLifecycleMapping has.
>> 
>> Regards
>> Georg
>> 
>> [1]
>> https://github.com/jvanzyl/m2e-core/blob/master/org.eclipse.m2e.core/src/org/eclipse/m2e/core/project/configurator/AbstractCustomizableLifecycleMapping.java
>>  
>> 
>> 
>> [2]
>> packaging "content-package" -> id 
>> "org.apache.sling.ide.eclipse.m2e.contentPackageLifecycleMapping" -> 
>> ContentPackageLifecycleMapping that extends 
>> AbstractCustomizableLifecycleMapping
>> https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/lifecycle-mapping-metadata.xml#L40
>> https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/lifecycle-mapping-metadata.xml#L41
>> https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/plugin.xml#L64
>> https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/plugin.xml#L65
>> 
>> 
>> On 2016-10-10 15:05, Konrad Windszus wrote:
>>> In
>>> https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/lifecycle-mapping-metadata.xml#L41
>>> 
>>> we have referenced the explicit lifecycle mapping id from
>>> https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/plugin.xml#L62
>>> 
>>> which references the class
>>> https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/src/org/apache/sling/ide/eclipse/m2e/internal/ContentPackageLifecycleMapping.java
>>> .
>>> The latter is empty.
>>> I am wondering why the lifecycle mapping extension point was ever
>>> necessary because we do nothing specific in
>>> ContentPackageLifecycleMapping.java
>>> 
>>> and m2e should be able to come up with a a default lifecycle id based
>>> on the configured plugin executions.
>>> If there is no good reason for that, I would rather get rid of the
>>> explicit lifecycle mapping id and only configure the plugin execution
>>> similar to the one for maven-bundle-plugin.
>>> @Georg Henzler: Because the original source code was contributed by
>>> you in https://issues.apache.org/jira/browse/SLING-3100
>>>  maybe you can share
>>> your thoughts.
>>> Thanks,
>>> Konrad
> 



[jira] [Created] (SLING-6128) Sling IDE: Remove Lifecycle Mapping Extension Point for content-package

2016-10-11 Thread Konrad Windszus (JIRA)
Konrad Windszus created SLING-6128:
--

 Summary: Sling IDE: Remove Lifecycle Mapping Extension Point for 
content-package
 Key: SLING-6128
 URL: https://issues.apache.org/jira/browse/SLING-6128
 Project: Sling
  Issue Type: Improvement
  Components: IDE
Affects Versions: Sling Eclipse IDE 1.1.0
Reporter: Konrad Windszus
Assignee: Konrad Windszus


The lifecycle mapping code for packaging {{content-package}} being added with 
SLING-3100 is not necessary and should be removed. 
Compare with http://www.mail-archive.com/dev@sling.apache.org/msg60234.html.



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


Re: Sling IDE: Lifecycle Mapping Extension Point

2016-10-11 Thread Konrad Windszus
This should not be necessary. Whenever there is an unknown packaging the 
DefaultLifecycleMapping.java is used which derives from 
AbstractCustomizableLifecycleMapping as well.
There is even a test explicitly written for that in 
https://github.com/tesla/m2e-core-tests/blob/2aea30eae086696da8ffce648c2eea010184b348/org.eclipse.m2e.tests/src/org/eclipse/m2e/tests/lifecycle/LifecycleMappingTest.java#L391
 
.
So I go ahead and remove those parts from the m2e-ui plugin.

> On 11 Oct 2016, at 01:27, Georg Henzler  wrote:
> 
> If I remember it correctly, it was needed to make the project configurator 
> work at all. Note that ContentPackageLifecycleMapping is not just empty but 
> extends AbstractCustomizableLifecycleMapping [1] and this code only becomes 
> active for content packages because of the reference chain [2]. But maybe the 
> situation has changed with current m2e versions, might be worth checking what 
> impact removing the ContentPackageLifecycleMapping has.
> 
> Regards
> Georg
> 
> [1]
> https://github.com/jvanzyl/m2e-core/blob/master/org.eclipse.m2e.core/src/org/eclipse/m2e/core/project/configurator/AbstractCustomizableLifecycleMapping.java
> 
> [2]
> packaging "content-package" -> id 
> "org.apache.sling.ide.eclipse.m2e.contentPackageLifecycleMapping" -> 
> ContentPackageLifecycleMapping that extends 
> AbstractCustomizableLifecycleMapping
> https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/lifecycle-mapping-metadata.xml#L40
> https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/lifecycle-mapping-metadata.xml#L41
> https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/plugin.xml#L64
> https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/plugin.xml#L65
> 
> 
> On 2016-10-10 15:05, Konrad Windszus wrote:
>> In
>> https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/lifecycle-mapping-metadata.xml#L41
>> 
>> we have referenced the explicit lifecycle mapping id from
>> https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/plugin.xml#L62
>> 
>> which references the class
>> https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/src/org/apache/sling/ide/eclipse/m2e/internal/ContentPackageLifecycleMapping.java
>> .
>> The latter is empty.
>> I am wondering why the lifecycle mapping extension point was ever
>> necessary because we do nothing specific in
>> ContentPackageLifecycleMapping.java
>> 
>> and m2e should be able to come up with a a default lifecycle id based
>> on the configured plugin executions.
>> If there is no good reason for that, I would rather get rid of the
>> explicit lifecycle mapping id and only configure the plugin execution
>> similar to the one for maven-bundle-plugin.
>> @Georg Henzler: Because the original source code was contributed by
>> you in https://issues.apache.org/jira/browse/SLING-3100
>>  maybe you can share
>> your thoughts.
>> Thanks,
>> Konrad



[jira] [Resolved] (SLING-6127) Update to Apache Felix Http Jetty 3.4.0 and Http Bridge 3.0.16

2016-10-11 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler resolved SLING-6127.
-
Resolution: Fixed

Updated in rev 1764203

> Update to Apache Felix Http Jetty 3.4.0 and Http Bridge 3.0.16
> --
>
> Key: SLING-6127
> URL: https://issues.apache.org/jira/browse/SLING-6127
> Project: Sling
>  Issue Type: Improvement
>  Components: Launchpad
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Launchpad Base 2.6.12, Launchpad Builder 9
>
>
> We should update the versions to get the latest features / bug fixes



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


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

2016-10-11 Thread Konrad Windszus (JIRA)

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

Konrad Windszus edited comment on SLING-6112 at 10/11/16 6:58 AM:
--

This is indeed expected. With m-b-p 3.2.0 it only works if explicitly 
configured 
(http://felix.apache.org/documentation/faqs/apache-felix-bundle-plugin-faq.html#use-scr-metadata-generated-by-bnd-in-unit-tests).
 

For me it is important that m2e-tycho is not necessarily required for Sling IDE 
(so the project configurator runs without it), but rather a helpful addition 
when using m-b-p < 3.2.0 for the incremental build, therefore you can always 
install the extension through Maven Discovery. Also if you use 
https://github.com/bndtools/bnd/tree/master/maven/bnd-maven-plugin it should 
work without any problems. 

We can think about providing an additional warning in case when a configuration 
is detected which does not automatically generate the MANIFEST.MF, but this is 
probably a bit tricky to do correctly.


was (Author: kwin):
This is indeed expected. With m-b-p 3.2.0 it only works if explicitly 
configured 
(http://felix.apache.org/documentation/faqs/apache-felix-bundle-plugin-faq.html#use-scr-metadata-generated-by-bnd-in-unit-tests).
 

For me it is important that m2e-tycho is not necessarily required for Sling IDE 
(but rather maybe a helpful addition when using m-b-p < 3.2.0, therefore you 
can always install the extension through Maven Discovery). Also if you use 
https://github.com/bndtools/bnd/tree/master/maven/bnd-maven-plugin it should 
work without any problems. 

We can think about providing an additional warning in case when a configuration 
is detected which does not automatically generate the MANIFEST.MF, but this is 
probably a bit tricky to do correctly.

> 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
>
>
> 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-6127) Update to Apache Felix Http Jetty 3.4.0 and Http Bridge 3.0.16

2016-10-11 Thread Carsten Ziegeler (JIRA)
Carsten Ziegeler created SLING-6127:
---

 Summary: Update to Apache Felix Http Jetty 3.4.0 and Http Bridge 
3.0.16
 Key: SLING-6127
 URL: https://issues.apache.org/jira/browse/SLING-6127
 Project: Sling
  Issue Type: Improvement
  Components: Launchpad
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: Launchpad Base 2.6.12, Launchpad Builder 9


We should update the versions to get the latest features / bug fixes



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


[jira] [Resolved] (SLING-6002) ScriptCacheImpl should move to new ResourceChangeListener API

2016-10-11 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler resolved SLING-6002.
-
Resolution: Fixed

Search path handling looks fine, I've improved the impl slightly to better 
handle removal of parent nodes

> ScriptCacheImpl should move to new ResourceChangeListener API 
> --
>
> Key: SLING-6002
> URL: https://issues.apache.org/jira/browse/SLING-6002
> Project: Sling
>  Issue Type: Task
>  Components: Scripting
>Reporter: Hanish Bansal
>Assignee: Carsten Ziegeler
> Fix For: Scripting Core 2.0.40
>
> Attachments: Patch.txt
>
>
> org.apache.sling.scripting.core.impl.ScriptCacheImpl 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-6112) Make Sling IDE independent of m2e-tycho

2016-10-11 Thread Konrad Windszus (JIRA)

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

Konrad Windszus commented on SLING-6112:


This is indeed expected. With m-b-p 3.2.0 it only works if explicitly 
configured 
(http://felix.apache.org/documentation/faqs/apache-felix-bundle-plugin-faq.html#use-scr-metadata-generated-by-bnd-in-unit-tests).
 

For me it is important that m2e-tycho is not necessarily required for Sling IDE 
(but rather maybe a helpful addition when using m-b-p < 3.2.0, therefore you 
can always install the extension through Maven Discovery). Also if you use 
https://github.com/bndtools/bnd/tree/master/maven/bnd-maven-plugin it should 
work without any problems. 

We can think about providing an additional warning in case when a configuration 
is detected which does not automatically generate the MANIFEST.MF, but this is 
probably a bit tricky to do correctly.

> 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
>
>
> 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] [Resolved] (SLING-6001) ProcessorManagerImpl should move to new ResourceChangeListener API

2016-10-11 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler resolved SLING-6001.
-
Resolution: Fixed

I've updated the implemenation to use a glob pattern and create a resource 
resolver on demand. In addition, removal events are now handled correctly

> ProcessorManagerImpl should move to new ResourceChangeListener API
> ---
>
> Key: SLING-6001
> URL: https://issues.apache.org/jira/browse/SLING-6001
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Reporter: Hanish Bansal
>Assignee: Carsten Ziegeler
> Fix For: Rewriter 1.1.6
>
> Attachments: patch.txt
>
>
> org.apache.sling.rewriter.impl.ProcessorManagerImpl 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-6126) Ability to specify TTL for separate health check

2016-10-11 Thread Evgeniy Fitsner (JIRA)

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

Evgeniy Fitsner commented on SLING-6126:


Dear [~henzlerg],

Suddenly but this is not an option in my case, because we have a deployment 
every 3 weeks. After deployment DevOps should check that instance is working 
w/o errors therefore they will check "hc" 1,2,3,...,n times to validate that 
instance is working (I'm not sure how often this heavy "hc" will be executed 
but I know that  "hc" enough expensive to CPU/Memory resources, approximately 
"hc" execution time (3 min) and period in which "hc" result will be 
relevant(approximately 30min)). In case of "hc" fail between deployments we 
need to execute it once again immediately after environment repair rather than 
wait next scheduled execution.

So for case above it's OK if user try to execute "hc", then wait a little (for 
example 5 minutes to complete all "hc") and execute "hc" again - in this case 
user will see cached relevant results immediately.

In my pull request I've only added global TTL override if service contains 
HealthCheck.TTL property.

> Ability to specify TTL for separate health check
> 
>
> Key: SLING-6126
> URL: https://issues.apache.org/jira/browse/SLING-6126
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check
>Reporter: Evgeniy Fitsner
>
> Currently there is no ability to specify TTL for separate health check.
> Ex.: in my case "hc" validating against repository about 3-5 minutes 
> therefore I couldn't specify TTL globally to not impact on other "hc" 
> results. This "hc" I couldn't execute by scheduler to prevent CPU from high 
> loading, also results for this check remains relevant for an 1-3 hours.
> Therefore if it make sense not only for me I've added "[pull 
> request|https://github.com/apache/sling/pull/180]; for this functionality:
> * If property "hc.ttl" specified within HC - it will be used as TTL for 
> result, otherwise cache will use default TTL value



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