RE: [VOTE] Release Apache Sling API 2.10.0 ... Path util classes

[Stefan Seifert]

-1 for the API bundle (unless this is by intention:)

why have we in the new API bundle two different packages with path-related 
utility classes?

org.apache.sling.api.resource.util (SLING-5220, comparing paths)
  Path
  PathSet

org.apache.sling.resource.path (SLING-5455, bulding paths)
  PathBuilder

the latter is even missing the "api" part in the package name - is this by 
intention?
perhaps Path and PathBuilder could even be combined in one single class.

stefan


>-Original Message-
>From: Robert Munteanu [mailto:romb...@apache.org]
>Sent: Tuesday, February 02, 2016 10:34 PM
>To: Sling Dev
>Subject: [VOTE] Release Apache Sling API 2.10.0, Apache Sling Resource
>Resolver 1.3.0, Apache Sling JCR Resource Resolver 2.6.0, Apache Sling
>Servlet Resolver 2.3.10
>
>Hi,
>
>We solved a large number of issues issues in these releases:
>
>https://issues.apache.org/jira/browse/SLING/fixforversion/12329540 (
>Apache Sling API 2.10.0, 21 issues)
>https://issues.apache.org/jira/browse/SLING/fixforversion/12332988 (
>Apache Sling Resource Resolver 1.3.0, 22 issues )
>https://issues.apache.org/jira/browse/SLING/fixforversion/1242 (
>Apache Sling JCR Resource Resolver 2.6.0, 12 issues )
>https://issues.apache.org/jira/browse/SLING/fixforversion/12333753 (
>Apache Sling Servlet Resolver 2.3.10, 3 issues)
>
>Staging repository:
>https://repository.apache.org/content/repositories/orgapachesling-1416/
>
>You can use this UNIX script to download the release and verify the
>signatures:
>http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
>Usage:
>sh check_staged_release.sh 1416 /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.

[jira] [Resolved] (SLING-5414) Make the contents of the provisioning model available at runtime

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-5414.
-
Resolution: Fixed

Resolving this for now, we should create new issues for further improvements

> Make the contents of the provisioning model available at runtime
> 
>
> Key: SLING-5414
> URL: https://issues.apache.org/jira/browse/SLING-5414
> Project: Sling
>  Issue Type: New Feature
>  Components: Maven Plugins and Archetypes
>Affects Versions: Slingstart Maven Plugin 1.4.0
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: Slingstart Maven Plugin 1.4.2
>
> Attachments: SLING-5414.patch
>
>
> For SLING-5355 we need to make additional sections from the provisioning 
> model available at runtime, so that ACLs can be set at startup, and also to 
> be able to reuse their definitions later for auditing/verification purposes.
> A simple way to do that is to copy those sections in the sling_bootstrap.txt 
> file. I have created a patch that does that, will attach it here for review.
> _edit: as discussed below, we'll make the full text of the model available at 
> runtime_



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

Re: Logging question.

[Chetan Mehrotra]

Not sure but with above setup you might get duplicate logs as both
appender if attached to same logger would write to console. A better
way would be to use Logback Appender filter to filter out all message
effectively disabling those appenders

  

  ALL
  DENY
  DENY
 
  
Chetan Mehrotra


On Wed, Feb 3, 2016 at 9:34 PM, Ian Boston  wrote:
> Hi,
> For completeness for anyone else wanting to use the Docker logger
> drivers
>
> Starting with
>  -Dorg.apache.sling.commons.log.configurationFile=logtoconsole.xml
> where  logtoconsole.xml contains [1], with 1 appender per file in log/*
> matching the name redirects everything to stdout. The pattern can contain
> tag to identify the source.
> Unfortunately there doesn't appear to be a wildcard available on Logback to
> override all possible loggers.
>
> Thanks for your help.
>
> Best Regards
> Ian
>
>
> 1
>
> 
> 
>
>   
> 
> 
>   %d{dd.MM. HH:mm:ss.SSS} *%level* [%thread] %logger
> %message%n
> 
>   
>
>class="ch.qos.logback.core.ConsoleAppender">
>  
>error.log %d %-5level %X{sling.userId:-NA} [%thread]
> %logger{30} %marker- %msg %n
>  
>   
>
> 
>
>   
> 
>   
>
>  actionClass="org.apache.sling.commons.log.logback.OsgiAction"/>
>  actionClass="org.apache.sling.commons.log.logback.OsgiAppenderRefAction"/>
> 
> 
>
>
>
> On 3 February 2016 at 13:15, Ian Boston  wrote:
>
>> Hi,
>> Thanks for the pointer, I'll give that a go.
>> Best Regards
>> Ian
>>
>> On 3 February 2016 at 13:09, Chetan Mehrotra 
>> wrote:
>>
>>> As of now you can attach a console appender to ROOT logger so as to
>>> also redirect the logs to console but it would not be possible to
>>> disable any other FileAppender. So both appender would remain active.
>>>
>>> There are ways to override the OSGi based appenders [1] but that would
>>> be quite hacky as you would need to do it for each configured
>>> appender!
>>>
>>> To support this case we would need to change the logic to provide such an
>>> option
>>>
>>> Chetan Mehrotra
>>> [1]
>>> https://sling.apache.org/documentation/development/logging.html#configuring-osgi-appenders-in-the-logback-config
>>>
>>> On Wed, Feb 3, 2016 at 6:14 PM, Ian Boston  wrote:
>>> > Hi,
>>> > Is there a master switch in Sling which I can throw to make all logging
>>> > appear on stdout regardless of the OSGi LogWriter configuration ?
>>> Hopefully
>>> > this is already documented.
>>> >
>>> > I know that sounds like a dumb thing to do. The stdout in question of a
>>> > Docker container connected to a Docker logging driver that I can
>>> forward to
>>> > ELK via FluentD without ever touching the disk. I can categorise the
>>> stream
>>> > as it's written so I don't mind that the log lines from multiple
>>> categories
>>> > are interlaced as long as they are lines (including stack traces).
>>> >
>>> > I would rather treat the Sling instance (Docker container) as a black
>>> box
>>> > and not install a specific Logback or SLF4J Logging driver connecting
>>> > directly to the ELK stack, as there are other applications running that
>>> are
>>> > black boxes.
>>> >
>>> > Best Regards
>>> > ian
>>>
>>
>>

[jira] [Commented] (SLING-5274) Include authentication in RequestProgressTracker

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra commented on SLING-5274:


+1. Looks useful and would simplify debugging authentication issues 

> Include authentication in RequestProgressTracker
> 
>
> Key: SLING-5274
> URL: https://issues.apache.org/jira/browse/SLING-5274
> Project: Sling
>  Issue Type: Improvement
>  Components: Engine
>Reporter: Alexander Klimetschek
> Attachments: SLING-5274.patch
>
>
> The request progress tracker only starts with the sling filters, after the 
> sling authentication ran through. Since authentication steps can be complex 
> with multiple handlers (just like filters) and can have a major performance 
> impact (custom auth handlers, slow resource resolver login) it would be very 
> useful to include it with detailed information.



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

[jira] [Created] (SLING-5482) Update documentation following the latest Sling API changes

[Robert Munteanu (JIRA)]

Robert Munteanu created SLING-5482:
--

 Summary: Update documentation following the latest Sling API 
changes
 Key: SLING-5482
 URL: https://issues.apache.org/jira/browse/SLING-5482
 Project: Sling
  Issue Type: Task
  Components: Documentation
Reporter: Robert Munteanu


Following the latest Sling API changes ( see SLING-4750, SLING-4751 ) we need 
to update the documentation with

- what was deprecated
- what new extension points were added ( OSGi components )
- what are the new best practices

Some candidate pages ( suggested by [~bdelacretaz] ) :

- https://sling.apache.org/documentation/the-sling-engine/resources.html
- 
https://sling.apache.org/documentation/bundles/apache-sling-eventing-and-job-handling.html

Also, it's worth checking out if we need a new page about observation or if we 
should add a new one



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

Re: An API to retrieve the search path?

[Carsten Ziegeler]

Bertrand Delacretaz wrote
> Hi Carsten,
> 
> On Tue, Feb 2, 2016 at 4:24 PM, Carsten Ziegeler  wrote:
>> ...With the new observation api we have a more
>> elegant solution: you can register the listener with a relative path and
>> the search paths are automatically added
> 
> Do we have docs or examples that show how to adapt existing code?
> 

I don't think so.

Carsten

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

Re: [VOTE] Release Apache Sling discovery.oak 1.2.6

[Carsten Ziegeler]

+1


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

Re: [VOTE] Release Apache Sling discovery.oak 1.2.6

[Robert Munteanu]

On Wed, 2016-02-03 at 17:09 +0100, Stefan Egli wrote:
> Please vote to approve this release:

+1

Robert

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

Re: [VOTE] Release Apache Sling discovery.oak 1.2.6

[Stefan Egli]

+1

Cheers,
Stefan

On 03/02/16 17:09, "Stefan Egli"  wrote:

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

[VOTE] Release Apache Sling discovery.oak 1.2.6

[Stefan Egli]

Hi,

We solved 1 issue in this release:
https://issues.apache.org/jira/browse/SLING/fixforversion/12334752

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

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

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

Please vote to approve this release:

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

This majority vote is open for at least 72 hours.

Cheers,
Stefan

Re: Logging question.

[Ian Boston]

Hi,
For completeness for anyone else wanting to use the Docker logger
drivers

Starting with
 -Dorg.apache.sling.commons.log.configurationFile=logtoconsole.xml
where  logtoconsole.xml contains [1], with 1 appender per file in log/*
matching the name redirects everything to stdout. The pattern can contain
tag to identify the source.
Unfortunately there doesn't appear to be a wildcard available on Logback to
override all possible loggers.

Thanks for your help.

Best Regards
Ian


1




  


  %d{dd.MM. HH:mm:ss.SSS} *%level* [%thread] %logger
%message%n

  

  
 
   error.log %d %-5level %X{sling.userId:-NA} [%thread]
%logger{30} %marker- %msg %n
 
  



  

  








On 3 February 2016 at 13:15, Ian Boston  wrote:

> Hi,
> Thanks for the pointer, I'll give that a go.
> Best Regards
> Ian
>
> On 3 February 2016 at 13:09, Chetan Mehrotra 
> wrote:
>
>> As of now you can attach a console appender to ROOT logger so as to
>> also redirect the logs to console but it would not be possible to
>> disable any other FileAppender. So both appender would remain active.
>>
>> There are ways to override the OSGi based appenders [1] but that would
>> be quite hacky as you would need to do it for each configured
>> appender!
>>
>> To support this case we would need to change the logic to provide such an
>> option
>>
>> Chetan Mehrotra
>> [1]
>> https://sling.apache.org/documentation/development/logging.html#configuring-osgi-appenders-in-the-logback-config
>>
>> On Wed, Feb 3, 2016 at 6:14 PM, Ian Boston  wrote:
>> > Hi,
>> > Is there a master switch in Sling which I can throw to make all logging
>> > appear on stdout regardless of the OSGi LogWriter configuration ?
>> Hopefully
>> > this is already documented.
>> >
>> > I know that sounds like a dumb thing to do. The stdout in question of a
>> > Docker container connected to a Docker logging driver that I can
>> forward to
>> > ELK via FluentD without ever touching the disk. I can categorise the
>> stream
>> > as it's written so I don't mind that the log lines from multiple
>> categories
>> > are interlaced as long as they are lines (including stack traces).
>> >
>> > I would rather treat the Sling instance (Docker container) as a black
>> box
>> > and not install a specific Logback or SLF4J Logging driver connecting
>> > directly to the ELK stack, as there are other applications running that
>> are
>> > black boxes.
>> >
>> > Best Regards
>> > ian
>>
>
>

Re: An API to retrieve the search path?

[Bertrand Delacretaz]

Hi Carsten,

On Tue, Feb 2, 2016 at 4:24 PM, Carsten Ziegeler  wrote:
> ...With the new observation api we have a more
> elegant solution: you can register the listener with a relative path and
> the search paths are automatically added

Do we have docs or examples that show how to adapt existing code?

-Bertrand

Re: Repoinit ITs fail on Jenkins ( was: Jenkins build is still unstable: sling-trunk-1.7 #3294)

[Bertrand Delacretaz]

Hi,

On Wed, Feb 3, 2016 at 9:05 AM, Robert Munteanu  wrote:
> ...There seems to be something wrong with the repoinit ITs on Jenkins...

I have reactivated those tests now, SLING-5452 should fix the status 404 issue.

-Bertrand

[jira] [Resolved] (SLING-5452) ClientSideTeleporter should check for web console readiness

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz resolved SLING-5452.

Resolution: Fixed

Implemented a webconsole readiness check in revision 1728331 and reactivated 
the repoinit IT tests in 1728335

> ClientSideTeleporter should check for web console readiness
> ---
>
> Key: SLING-5452
> URL: https://issues.apache.org/jira/browse/SLING-5452
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.6
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: JUnit Tests Teleporter 1.0.8
>
>
> Before installing its test bundle, the {{ClientSideTeleporter}} should 
> (optionally?) check, via HTTP, that the OSGi console is ready to accept it. 
> The customizer could optionally set a longer retry timeout for installing the 
> bundle.
> This is not a problem in our launchpad test suite as the Sling readiness is 
> checked extensively before starting tests, but in smaller test suites it's 
> useful for the teleporter to be self-contained in this respect.



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

[jira] [Updated] (SLING-5452) ClientSideTeleporter should check for web console readiness

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz updated SLING-5452:
---
Fix Version/s: JUnit Tests Teleporter 1.0.8

> ClientSideTeleporter should check for web console readiness
> ---
>
> Key: SLING-5452
> URL: https://issues.apache.org/jira/browse/SLING-5452
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.6
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: JUnit Tests Teleporter 1.0.8
>
>
> Before installing its test bundle, the {{ClientSideTeleporter}} should 
> (optionally?) check, via HTTP, that the OSGi console is ready to accept it. 
> The customizer could optionally set a longer retry timeout for installing the 
> bundle.
> This is not a problem in our launchpad test suite as the Sling readiness is 
> checked extensively before starting tests, but in smaller test suites it's 
> useful for the teleporter to be self-contained in this respect.



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

[jira] [Resolved] (SLING-5481) Improve the Sling Hamcrest Matchers mismatch message

[Konrad Windszus (JIRA)]

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

Konrad Windszus resolved SLING-5481.

Resolution: Fixed

Fixed in [r1728333|http://svn.apache.org/r178333].

Now the messages look like this:

{quote}
Expected: Resource with children ["child1"]
 but: was Resource with children ["child2","child3"] (resource: 
)
{quote}
or
{quote}
Expected: Resource with properties []
 but: was Resource with properties [] 
(resource: )
{quote}

It still includes the original toString() representation but in addition always 
either all properties or all child names.

> Improve the Sling Hamcrest Matchers mismatch message
> 
>
> Key: SLING-5481
> URL: https://issues.apache.org/jira/browse/SLING-5481
> Project: Sling
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Apache Sling Testing Hamcrest 1.0.0
>
>
> Currently both hamcrest matchers added in SLING-5063 rely on the resource's 
> {{toString()}} method to print out the comparison value.
> An example mismatch might look like this
> {quote}
> Expected: Resource with children ["child1"]
>  but: was  resources=[Ljava.lang.String;@1875b888]>
> {quote}
> It would be nice to tweak the mismatch error message by overwriting the 
> {{describeMismatchSafely}} method.



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

[jira] [Resolved] (SLING-5480) Change in JMX names (OAK-3477) breaks discovery.oak's SynchronizedClocksHealthCheck

[Stefan Egli (JIRA)]

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

Stefan Egli resolved SLING-5480.

Resolution: Fixed

> Change in JMX names (OAK-3477) breaks discovery.oak's 
> SynchronizedClocksHealthCheck
> ---
>
> Key: SLING-5480
> URL: https://issues.apache.org/jira/browse/SLING-5480
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Discovery Oak 1.2.4
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Discovery Oak 1.2.6
>
>
> OAK-3477 changed the naming convention of JMX Mbeans created by oak. 
> Originally the DocumentNodeStore was created as follows:
> {noformat}
> domain/type/name/properties
> org.apache.jackrabbit.oak "DocumentNodeStore" "Document node store 
> management"{id=6}
> {noformat}
> while OAK-3477 changed that to:
> {noformat}
> domain/type/name/properties
> org.apache.jackrabbit.oak DocumentNodeStore   Document node store 
> management
> {noformat}
> (meaning, the type is not quoted anymore, plus the id is gone)
> This breaks the query used in {{SynchronizedClocksHealthCheck}} to get the 
> {{DocumentNodeStoreMBean}} (fyi [~chetanm]). Currently this results in the 
> health check to report that: "Intra-cluster test n/a (No DocumentNodeStore 
> MBean found) " - ie it goes rather unnoticed and effectively the health-check 
> is disabled. So we need to adjust the query in SynchronizedClocksHealthCheck.



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

[jira] [Created] (SLING-5481) Improve the Sling Hamcrest Matchers mismatch message

[Konrad Windszus (JIRA)]

Konrad Windszus created SLING-5481:
--

 Summary: Improve the Sling Hamcrest Matchers mismatch message
 Key: SLING-5481
 URL: https://issues.apache.org/jira/browse/SLING-5481
 Project: Sling
  Issue Type: Improvement
Reporter: Konrad Windszus
Assignee: Konrad Windszus
 Fix For: Apache Sling Testing Hamcrest 1.0.0


Currently both hamcrest matchers added in SLING-5063 rely on the resource's 
{{toString()}} method to print out the comparison value.
An example mismatch might look like this
{quote}
Expected: Resource with children ["child1"]
 but: was 
{quote}

It would be nice to tweak the mismatch error message by overwriting the 
{{describeMismatchSafely}} method.



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

[jira] [Updated] (SLING-5231) Remove getAdministrativeResourceResolver() usage from Discovery components

[Stefan Egli (JIRA)]

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

Stefan Egli updated SLING-5231:
---
Fix Version/s: (was: Discovery Oak 1.2.6)
   Discovery Oak 1.2.8

.. and another move to discovery.oak 1.2.8 (to get out SLING-5480)

> Remove getAdministrativeResourceResolver() usage from Discovery components
> --
>
> Key: SLING-5231
> URL: https://issues.apache.org/jira/browse/SLING-5231
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Discovery Impl 1.2.0, Discovery Commons 1.0.2, Discovery 
> Base 1.0.2, Discovery Oak 1.0.2
>Reporter: Antonio Sanso
> Fix For: Discovery Impl 1.2.8, Discovery Base 1.1.4, Discovery 
> Commons 1.0.12, Discovery Oak 1.2.8
>
> Attachments: base-patch.txt, commons-patch.txt, impl-patch.txt, 
> oak-patch.txt
>
>
> * {{org.apache.sling.discovery.base}}: 6
> * {{org.apache.sling.discovery.commons}}: 3
> * {{org.apache.sling.discovery.oak}}: 4
> total of 13 occurrences 



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

[jira] [Commented] (SLING-5480) Change in JMX names (OAK-3477) breaks discovery.oak's SynchronizedClocksHealthCheck

[Stefan Egli (JIRA)]

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

Stefan Egli commented on SLING-5480:


done in rev 1728328

> Change in JMX names (OAK-3477) breaks discovery.oak's 
> SynchronizedClocksHealthCheck
> ---
>
> Key: SLING-5480
> URL: https://issues.apache.org/jira/browse/SLING-5480
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Discovery Oak 1.2.4
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Discovery Oak 1.2.6
>
>
> OAK-3477 changed the naming convention of JMX Mbeans created by oak. 
> Originally the DocumentNodeStore was created as follows:
> {noformat}
> domain/type/name/properties
> org.apache.jackrabbit.oak "DocumentNodeStore" "Document node store 
> management"{id=6}
> {noformat}
> while OAK-3477 changed that to:
> {noformat}
> domain/type/name/properties
> org.apache.jackrabbit.oak DocumentNodeStore   Document node store 
> management
> {noformat}
> (meaning, the type is not quoted anymore, plus the id is gone)
> This breaks the query used in {{SynchronizedClocksHealthCheck}} to get the 
> {{DocumentNodeStoreMBean}} (fyi [~chetanm]). Currently this results in the 
> health check to report that: "Intra-cluster test n/a (No DocumentNodeStore 
> MBean found) " - ie it goes rather unnoticed and effectively the health-check 
> is disabled. So we need to adjust the query in SynchronizedClocksHealthCheck.



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

[jira] [Created] (SLING-5480) Change in JMX names (OAK-3477) breaks discovery.oak's SynchronizedClocksHealthCheck

[Stefan Egli (JIRA)]

Stefan Egli created SLING-5480:
--

 Summary: Change in JMX names (OAK-3477) breaks discovery.oak's 
SynchronizedClocksHealthCheck
 Key: SLING-5480
 URL: https://issues.apache.org/jira/browse/SLING-5480
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Discovery Oak 1.2.4
Reporter: Stefan Egli
Assignee: Stefan Egli
 Fix For: Discovery Oak 1.2.6


OAK-3477 changed the naming convention of JMX Mbeans created by oak. Originally 
the DocumentNodeStore was created as follows:
{noformat}
domain/type/name/properties
org.apache.jackrabbit.oak   "DocumentNodeStore" "Document node store 
management"{id=6}
{noformat}
while OAK-3477 changed that to:
{noformat}
domain/type/name/properties
org.apache.jackrabbit.oak   DocumentNodeStore   Document node store 
management
{noformat}
(meaning, the type is not quoted anymore, plus the id is gone)

This breaks the query used in {{SynchronizedClocksHealthCheck}} to get the 
{{DocumentNodeStoreMBean}} (fyi [~chetanm]). Currently this results in the 
health check to report that: "Intra-cluster test n/a (No DocumentNodeStore 
MBean found) " - ie it goes rather unnoticed and effectively the health-check 
is disabled. So we need to adjust the query in SynchronizedClocksHealthCheck.



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

[jira] [Commented] (SLING-5414) Make the contents of the provisioning model available at runtime

[Oliver Lietz (JIRA)]

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

Oliver Lietz commented on SLING-5414:
-

Right. For provisioning on Karaf it's {{feature.xml}} and an additional 
configuration ({{karaf-maven-plugin}}) in a POM for building a Karaf-based 
Sling distribution.

> Make the contents of the provisioning model available at runtime
> 
>
> Key: SLING-5414
> URL: https://issues.apache.org/jira/browse/SLING-5414
> Project: Sling
>  Issue Type: New Feature
>  Components: Maven Plugins and Archetypes
>Affects Versions: Slingstart Maven Plugin 1.4.0
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: Slingstart Maven Plugin 1.4.2
>
> Attachments: SLING-5414.patch
>
>
> For SLING-5355 we need to make additional sections from the provisioning 
> model available at runtime, so that ACLs can be set at startup, and also to 
> be able to reuse their definitions later for auditing/verification purposes.
> A simple way to do that is to copy those sections in the sling_bootstrap.txt 
> file. I have created a patch that does that, will attach it here for review.
> _edit: as discussed below, we'll make the full text of the model available at 
> runtime_



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

Re: Logging question.

[Ian Boston]

Hi,
Thanks for the pointer, I'll give that a go.
Best Regards
Ian

On 3 February 2016 at 13:09, Chetan Mehrotra 
wrote:

> As of now you can attach a console appender to ROOT logger so as to
> also redirect the logs to console but it would not be possible to
> disable any other FileAppender. So both appender would remain active.
>
> There are ways to override the OSGi based appenders [1] but that would
> be quite hacky as you would need to do it for each configured
> appender!
>
> To support this case we would need to change the logic to provide such an
> option
>
> Chetan Mehrotra
> [1]
> https://sling.apache.org/documentation/development/logging.html#configuring-osgi-appenders-in-the-logback-config
>
> On Wed, Feb 3, 2016 at 6:14 PM, Ian Boston  wrote:
> > Hi,
> > Is there a master switch in Sling which I can throw to make all logging
> > appear on stdout regardless of the OSGi LogWriter configuration ?
> Hopefully
> > this is already documented.
> >
> > I know that sounds like a dumb thing to do. The stdout in question of a
> > Docker container connected to a Docker logging driver that I can forward
> to
> > ELK via FluentD without ever touching the disk. I can categorise the
> stream
> > as it's written so I don't mind that the log lines from multiple
> categories
> > are interlaced as long as they are lines (including stack traces).
> >
> > I would rather treat the Sling instance (Docker container) as a black box
> > and not install a specific Logback or SLF4J Logging driver connecting
> > directly to the ELK stack, as there are other applications running that
> are
> > black boxes.
> >
> > Best Regards
> > ian
>

Re: Logging question.

[Chetan Mehrotra]

As of now you can attach a console appender to ROOT logger so as to
also redirect the logs to console but it would not be possible to
disable any other FileAppender. So both appender would remain active.

There are ways to override the OSGi based appenders [1] but that would
be quite hacky as you would need to do it for each configured
appender!

To support this case we would need to change the logic to provide such an option

Chetan Mehrotra
[1] 
https://sling.apache.org/documentation/development/logging.html#configuring-osgi-appenders-in-the-logback-config

On Wed, Feb 3, 2016 at 6:14 PM, Ian Boston  wrote:
> Hi,
> Is there a master switch in Sling which I can throw to make all logging
> appear on stdout regardless of the OSGi LogWriter configuration ? Hopefully
> this is already documented.
>
> I know that sounds like a dumb thing to do. The stdout in question of a
> Docker container connected to a Docker logging driver that I can forward to
> ELK via FluentD without ever touching the disk. I can categorise the stream
> as it's written so I don't mind that the log lines from multiple categories
> are interlaced as long as they are lines (including stack traces).
>
> I would rather treat the Sling instance (Docker container) as a black box
> and not install a specific Logback or SLF4J Logging driver connecting
> directly to the ELK stack, as there are other applications running that are
> black boxes.
>
> Best Regards
> ian

Logging question.

[Ian Boston]

Hi,
Is there a master switch in Sling which I can throw to make all logging
appear on stdout regardless of the OSGi LogWriter configuration ? Hopefully
this is already documented.

I know that sounds like a dumb thing to do. The stdout in question of a
Docker container connected to a Docker logging driver that I can forward to
ELK via FluentD without ever touching the disk. I can categorise the stream
as it's written so I don't mind that the log lines from multiple categories
are interlaced as long as they are lines (including stack traces).

I would rather treat the Sling instance (Docker container) as a black box
and not install a specific Logback or SLF4J Logging driver connecting
directly to the ELK stack, as there are other applications running that are
black boxes.

Best Regards
ian

Re: Sling Resource Merger and intended behaviour of sling:hideProperties and sling:hideChildren

[Julian Sedding]

+1 for clarifying and fixing the meaning of sling:hideChildren and
sling:hideProperties. I think it is much more intuitive that it only
affects the inherited children and properties.

Regards
Julian

On Wed, Feb 3, 2016 at 11:41 AM, Konrad Windszus  wrote:
> I was still thinking about the original problem:
> What is a use case for hiding local properties/resources?
>
> I could only come up with one use case actually:
> You rely on sling:resourceSuperType for the OverridingResourcePicker and 
> don't want to expose that property in the merged view!
> For that you could use sling:hideProperties="sling:resourceSuperType" because 
> that will hide the local property as well as the property with that name from 
> all of the underlying resources.
> Just removing that property from your resource is not an option here (because 
> it is important for the merging itself).
>
> Since this is not a very convincing use case I would propose to just change 
> the meaning of sling:hideChildren and sling:hideProperties to only act on the 
> underlying resources. This affects the wildcards as well as the case where 
> you give individual names as values.
> The only exception would be sling:hideResource as that will hide the local as 
> well as the underlying resources of that name.
>
> That way it is easy to completely disable inheritance (by setting both 
> sling:hideProperties=* and sling:hideChildren=*), which is IMHO a much more 
> common use case.
>
> I will propose a patch in SLING-5468.
> Konrad
>
>
>> On 03 Feb 2016, at 08:43, Julian Sedding  wrote:
>>
>> Hi Konrad
>>
>> I read through the page. Good job! It looks fine and I didn't spot any
>> error. (Not that I am an authority on the Resource Merger...).
>>
>> Regards
>> Julian
>>
>>
>> On Tue, Feb 2, 2016 at 7:54 PM, Konrad Windszus  wrote:
>>> I contributed some documentation in 
>>> http://sling.staging.apache.org/documentation/bundles/resource-merger.html 
>>> .
>>> Would you be so kind and quickly cross-check?
>>> I would still be interested though in someone else’s opinion on how the 
>>> sling:hideProperties=* is supposed to work.
>>> Thanks
>>> Konrad
>>>
>>>
 On 29 Jan 2016, at 18:09, Julian Sedding  wrote:

 There is some more documentation at
 https://github.com/gknob/sling-resourcemerger, where the feature was
 originally developed. Haven't had time to read it yet.

 Regards
 Julian

 On Fri, Jan 29, 2016 at 6:02 PM, Konrad Windszus
  wrote:
> As being suggested by Julian Sedding in 
> https://issues.apache.org/jira/browse/SLING-5468 I want to get your input 
> on how the properties
> "sling:hideProperties=*”  and "sling:hideChildren=*” are supposed to work 
> in the Sling Resource Merger.
>
> At least for the OverridingResourcePicker using the wildcard hides both 
> the local as well as the inherited resources/properties. This is causing 
> some trouble as that way I cannot easily replace the whole resource 
> without considering any underlying resources.
> The only documentation about those properties is at 
> https://issues.apache.org/jira/browse/SLING-2986?focusedCommentId=13802834&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13802834
>  but that does not really explain how those should behave in terms of 
> inheritance. Also the implementation changed quite a bit due to the 
> refactoring being done in 
> https://issues.apache.org/jira/browse/SLING-3423.
>
> For me this looks rather like a bug because I cannot come up with a good 
> use case where you would be interested to even hide your own/local 
> properties/child resources. Those properties should IMHO always refer 
> only to the inherited/underlying resources/properties but not to the 
> local ones (i.e. the ones next to the resource defining 
> sling:hideProperties or sling:hideChildren.
> WDYT?
>
> Thanks for your input,
> Konrad
>
>>>
>

[jira] [Resolved] (SLING-5479) Run distribution integration tests with launchpad 8

[Marius Petria (JIRA)]

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

Marius Petria resolved SLING-5479.
--
   Resolution: Fixed
Fix Version/s: Content Distribution Core 0.1.14

Thanks [~dulceanu], I committed a slightly modified version in revision 1728301.


> Run distribution integration tests with launchpad 8
> ---
>
> Key: SLING-5479
> URL: https://issues.apache.org/jira/browse/SLING-5479
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Andrei Dulceanu
>Assignee: Marius Petria
>Priority: Minor
> Fix For: Content Distribution Core 0.1.14
>
> Attachments: SLING-5479.2.diff, SLING-5479.patch
>
>
> At the moment the integration tests from distribution module are run with 
> launchpad 7. We should run them against the latest launchpad 8.



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

[jira] [Updated] (SLING-5479) Run distribution integration tests with launchpad 8

[Marius Petria (JIRA)]

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

Marius Petria updated SLING-5479:
-
Component/s: (was: Testing)

> Run distribution integration tests with launchpad 8
> ---
>
> Key: SLING-5479
> URL: https://issues.apache.org/jira/browse/SLING-5479
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Andrei Dulceanu
>Assignee: Marius Petria
>Priority: Minor
> Attachments: SLING-5479.2.diff, SLING-5479.patch
>
>
> At the moment the integration tests from distribution module are run with 
> launchpad 7. We should run them against the latest launchpad 8.



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

[jira] [Assigned] (SLING-5479) Run distribution integration tests with launchpad 8

[Marius Petria (JIRA)]

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

Marius Petria reassigned SLING-5479:


Assignee: Marius Petria

> Run distribution integration tests with launchpad 8
> ---
>
> Key: SLING-5479
> URL: https://issues.apache.org/jira/browse/SLING-5479
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution, Testing
>Reporter: Andrei Dulceanu
>Assignee: Marius Petria
>Priority: Minor
> Attachments: SLING-5479.2.diff, SLING-5479.patch
>
>
> At the moment the integration tests from distribution module are run with 
> launchpad 7. We should run them against the latest launchpad 8.



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

Re: Sling Resource Merger and intended behaviour of sling:hideProperties and sling:hideChildren

[Konrad Windszus]

I was still thinking about the original problem:
What is a use case for hiding local properties/resources?

I could only come up with one use case actually:
You rely on sling:resourceSuperType for the OverridingResourcePicker and don't 
want to expose that property in the merged view!
For that you could use sling:hideProperties="sling:resourceSuperType" because 
that will hide the local property as well as the property with that name from 
all of the underlying resources.
Just removing that property from your resource is not an option here (because 
it is important for the merging itself).

Since this is not a very convincing use case I would propose to just change the 
meaning of sling:hideChildren and sling:hideProperties to only act on the 
underlying resources. This affects the wildcards as well as the case where you 
give individual names as values.
The only exception would be sling:hideResource as that will hide the local as 
well as the underlying resources of that name.

That way it is easy to completely disable inheritance (by setting both 
sling:hideProperties=* and sling:hideChildren=*), which is IMHO a much more 
common use case.

I will propose a patch in SLING-5468.
Konrad


> On 03 Feb 2016, at 08:43, Julian Sedding  wrote:
> 
> Hi Konrad
> 
> I read through the page. Good job! It looks fine and I didn't spot any
> error. (Not that I am an authority on the Resource Merger...).
> 
> Regards
> Julian
> 
> 
> On Tue, Feb 2, 2016 at 7:54 PM, Konrad Windszus  wrote:
>> I contributed some documentation in 
>> http://sling.staging.apache.org/documentation/bundles/resource-merger.html 
>> .
>> Would you be so kind and quickly cross-check?
>> I would still be interested though in someone else’s opinion on how the 
>> sling:hideProperties=* is supposed to work.
>> Thanks
>> Konrad
>> 
>> 
>>> On 29 Jan 2016, at 18:09, Julian Sedding  wrote:
>>> 
>>> There is some more documentation at
>>> https://github.com/gknob/sling-resourcemerger, where the feature was
>>> originally developed. Haven't had time to read it yet.
>>> 
>>> Regards
>>> Julian
>>> 
>>> On Fri, Jan 29, 2016 at 6:02 PM, Konrad Windszus
>>>  wrote:
 As being suggested by Julian Sedding in 
 https://issues.apache.org/jira/browse/SLING-5468 I want to get your input 
 on how the properties
 "sling:hideProperties=*”  and "sling:hideChildren=*” are supposed to work 
 in the Sling Resource Merger.
 
 At least for the OverridingResourcePicker using the wildcard hides both 
 the local as well as the inherited resources/properties. This is causing 
 some trouble as that way I cannot easily replace the whole resource 
 without considering any underlying resources.
 The only documentation about those properties is at 
 https://issues.apache.org/jira/browse/SLING-2986?focusedCommentId=13802834&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13802834
  but that does not really explain how those should behave in terms of 
 inheritance. Also the implementation changed quite a bit due to the 
 refactoring being done in https://issues.apache.org/jira/browse/SLING-3423.
 
 For me this looks rather like a bug because I cannot come up with a good 
 use case where you would be interested to even hide your own/local 
 properties/child resources. Those properties should IMHO always refer only 
 to the inherited/underlying resources/properties but not to the local ones 
 (i.e. the ones next to the resource defining sling:hideProperties or 
 sling:hideChildren.
 WDYT?
 
 Thanks for your input,
 Konrad
 
>> 

[jira] [Commented] (SLING-5466) Pending distribution changes are lost if the Apache Sling Distribution Agent - Sync Agents Factory configuration is changed.

[Marius Petria (JIRA)]

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

Marius Petria commented on SLING-5466:
--

[~jaybrown] that probably happens if the list of endpoints is changed. In order 
to have a stable name for your endpoint you should give it an explicit label 

{noformat}
packageImporter.endpoints = ["endpoint0=http://localhost:4503/";, 
"endpoint4=http://localhost:4504/";]
{noformat}

> Pending distribution changes are lost if the  Apache Sling Distribution Agent 
> - Sync Agents Factory configuration is changed.
> -
>
> Key: SLING-5466
> URL: https://issues.apache.org/jira/browse/SLING-5466
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution
>Affects Versions: Content Distribution Core 0.1.4
> Environment: Windows 7 x64, AEM/CQ 6.1.0
>Reporter: Jay Brown
>  Labels: patch
>
> [Using Content Distribution Core 0.1.3.r1680309 -- wasn't available in the 
> list]
> When running Sling with pending distribution changes queued for a node that 
> is down, a change to the Sling Distribution Agent - Sync Agents Factory 
> configuration can cause the pending changes to be distributed to the wrong 
> Sling node.
> It appears that changes to be distributed to a node are assigned to a generic 
> "endpoint" name (not the host, itself).  During the creation of the change 
> nodes, the index (position) of the distribution target host in the 
> packageExporter.endpoints OSGi configuration field is used to assign the 
> pending changes to an endpoint named "endpoint[n])," where [n] is the 
> position of the server address packageExporter.endpoints field.  If 
> distribution changes are queued for a host that is down AND the order of the 
> packageExporter.endpoints is changed, which potentially causes endpoint[n] to 
> represent a different host, the changes are then shipped off to the wrong 
> host, and the original host never receives the queued changes.



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

[jira] [Updated] (SLING-5479) Run distribution integration tests with launchpad 8

[Marius Petria (JIRA)]

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

Marius Petria updated SLING-5479:
-
Attachment: SLING-5479.2.diff

I modified a little bit the patch to correct the service users creation.

> Run distribution integration tests with launchpad 8
> ---
>
> Key: SLING-5479
> URL: https://issues.apache.org/jira/browse/SLING-5479
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution, Testing
>Reporter: Andrei Dulceanu
>Priority: Minor
> Attachments: SLING-5479.2.diff, SLING-5479.patch
>
>
> At the moment the integration tests from distribution module are run with 
> launchpad 7. We should run them against the latest launchpad 8.



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

[jira] [Commented] (SLING-5452) ClientSideTeleporter should check for web console readiness

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-5452:


For now I have @Ignored those tests, revision 1728282

> ClientSideTeleporter should check for web console readiness
> ---
>
> Key: SLING-5452
> URL: https://issues.apache.org/jira/browse/SLING-5452
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.6
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
>
> Before installing its test bundle, the {{ClientSideTeleporter}} should 
> (optionally?) check, via HTTP, that the OSGi console is ready to accept it. 
> The customizer could optionally set a longer retry timeout for installing the 
> bundle.
> This is not a problem in our launchpad test suite as the Sling readiness is 
> checked extensively before starting tests, but in smaller test suites it's 
> useful for the teleporter to be self-contained in this respect.



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

[jira] [Commented] (SLING-5452) ClientSideTeleporter should check for web console readiness

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-5452:


As reported by [~rombert] the repoinit tests are currently failing on Jenkins 
and this is apparently the core issue:

{code}
java.io.IOException: Got status code 404 for 
http://localhost:49661/system/console/bundles
at 
org.apache.sling.testing.teleporter.client.TeleporterHttpClient.installBundle(TeleporterHttpClient.java:77)
{code}

> ClientSideTeleporter should check for web console readiness
> ---
>
> Key: SLING-5452
> URL: https://issues.apache.org/jira/browse/SLING-5452
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.6
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
>
> Before installing its test bundle, the {{ClientSideTeleporter}} should 
> (optionally?) check, via HTTP, that the OSGi console is ready to accept it. 
> The customizer could optionally set a longer retry timeout for installing the 
> bundle.
> This is not a problem in our launchpad test suite as the Sling readiness is 
> checked extensively before starting tests, but in smaller test suites it's 
> useful for the teleporter to be self-contained in this respect.



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

Re: Repoinit ITs fail on Jenkins ( was: Jenkins build is still unstable: sling-trunk-1.7 #3294)

[Bertrand Delacretaz]

Hi,

On Wed, Feb 3, 2016 at 9:05 AM, Robert Munteanu  wrote:
> ...They all fails with 'Got status code 404 for http://localhost:49661/sys
> tem/console/bundles'...

Ok I'll have a look, I suppose that's
https://issues.apache.org/jira/browse/SLING-5452

-Bertrand

[jira] [Commented] (SLING-5414) Make the contents of the provisioning model available at runtime

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-5414:


I'm fine with releasing as is, providing the model to the launchpad but medium 
term my idea is to

* a) Generate a fragment bundle at build time, that contains the provisioning 
model, and inject it in the model
* b) Provide an API to retrieve and parse the provisioning model at runtime. 
The bundle that does this uses the fragment bundle created by a)

I've tried both at 
https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-problem/ but I'm not 
happy with the implementation of a) there, need to revisit this. On the other 
hand the (trivial) {{bundles/extensions/provisioning-model-provider}} that's 
there could stay as is once a) works. I probably won't have time to work again 
on this before a week, so I'm fine releasing the slingstart plugin as is if 
that's useful.

> Make the contents of the provisioning model available at runtime
> 
>
> Key: SLING-5414
> URL: https://issues.apache.org/jira/browse/SLING-5414
> Project: Sling
>  Issue Type: New Feature
>  Components: Maven Plugins and Archetypes
>Affects Versions: Slingstart Maven Plugin 1.4.0
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: Slingstart Maven Plugin 1.4.2
>
> Attachments: SLING-5414.patch
>
>
> For SLING-5355 we need to make additional sections from the provisioning 
> model available at runtime, so that ACLs can be set at startup, and also to 
> be able to reuse their definitions later for auditing/verification purposes.
> A simple way to do that is to copy those sections in the sling_bootstrap.txt 
> file. I have created a patch that does that, will attach it here for review.
> _edit: as discussed below, we'll make the full text of the model available at 
> runtime_



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

Re: [VOTE] Release Apache Sling API 2.10.0, Apache Sling Resource Resolver 1.3.0, Apache Sling JCR Resource Resolver 2.6.0, Apache Sling Servlet Resolver 2.3.10

[Stefan Egli]

+1

Cheers,
Stefan

On 02/02/16 22:34, "Robert Munteanu"  wrote:

>Hi,
>
>We solved a large number of issues issues in these releases:
>
>https://issues.apache.org/jira/browse/SLING/fixforversion/12329540 (
>Apache Sling API 2.10.0, 21 issues)
>https://issues.apache.org/jira/browse/SLING/fixforversion/12332988 (
>Apache Sling Resource Resolver 1.3.0, 22 issues )
>https://issues.apache.org/jira/browse/SLING/fixforversion/1242 (
>Apache Sling JCR Resource Resolver 2.6.0, 12 issues )
>https://issues.apache.org/jira/browse/SLING/fixforversion/12333753 (
>Apache Sling Servlet Resolver 2.3.10, 3 issues)
>
>Staging repository:
>https://repository.apache.org/content/repositories/orgapachesling-1416/
>
>You can use this UNIX script to download the release and verify the
>signatures:
>http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
>Usage:
>sh check_staged_release.sh 1416 /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.

[jira] [Updated] (SLING-5479) Run distribution integration tests with launchpad 8

[Andrei Dulceanu (JIRA)]

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

Andrei Dulceanu updated SLING-5479:
---
Attachment: SLING-5479.patch

[~mpetria]: I attached a patch which allows starting an author and a publish 
instance with launchpad 8, but there's more work to be done because there are 
still some tests failing.

> Run distribution integration tests with launchpad 8
> ---
>
> Key: SLING-5479
> URL: https://issues.apache.org/jira/browse/SLING-5479
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution, Testing
>Reporter: Andrei Dulceanu
>Priority: Minor
> Attachments: SLING-5479.patch
>
>
> At the moment the integration tests from distribution module are run with 
> launchpad 7. We should run them against the latest launchpad 8.



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

[jira] [Created] (SLING-5479) Run distribution integration tests with launchpad 8

[Andrei Dulceanu (JIRA)]

Andrei Dulceanu created SLING-5479:
--

 Summary: Run distribution integration tests with launchpad 8
 Key: SLING-5479
 URL: https://issues.apache.org/jira/browse/SLING-5479
 Project: Sling
  Issue Type: Improvement
  Components: Distribution, Testing
Reporter: Andrei Dulceanu
Priority: Minor


At the moment the integration tests from distribution module are run with 
launchpad 7. We should run them against the latest launchpad 8.



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

[jira] [Commented] (SLING-5414) Make the contents of the provisioning model available at runtime

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-5414:
-

The model parser is a bundle which can easily be used within your app.
Not sure about how to get the prov model

> Make the contents of the provisioning model available at runtime
> 
>
> Key: SLING-5414
> URL: https://issues.apache.org/jira/browse/SLING-5414
> Project: Sling
>  Issue Type: New Feature
>  Components: Maven Plugins and Archetypes
>Affects Versions: Slingstart Maven Plugin 1.4.0
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: Slingstart Maven Plugin 1.4.2
>
> Attachments: SLING-5414.patch
>
>
> For SLING-5355 we need to make additional sections from the provisioning 
> model available at runtime, so that ACLs can be set at startup, and also to 
> be able to reuse their definitions later for auditing/verification purposes.
> A simple way to do that is to copy those sections in the sling_bootstrap.txt 
> file. I have created a patch that does that, will attach it here for review.
> _edit: as discussed below, we'll make the full text of the model available at 
> runtime_



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

Repoinit ITs fail on Jenkins ( was: Jenkins build is still unstable: sling-trunk-1.7 #3294)

[Robert Munteanu]

On Wed, 2016-02-03 at 00:39 +, Apache Jenkins Server wrote:
> See 
> 

There seems to be something wrong with the repoinit ITs on Jenkins

They all fails with 'Got status code 404 for http://localhost:49661/sys
tem/console/bundles'

https://builds.apache.org/job/sling-trunk-1.7/3295/org.apache.sling$org
.apache.sling.repoinit.it/testReport/

Robert

[jira] [Resolved] (SLING-5460) Allow skipping resource merges in the Sling Resource Merger

[Konrad Windszus (JIRA)]

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

Konrad Windszus resolved SLING-5460.

Resolution: Duplicate

> Allow skipping resource merges in the Sling Resource Merger
> ---
>
> Key: SLING-5460
> URL: https://issues.apache.org/jira/browse/SLING-5460
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Affects Versions: Resource Merger 1.2.10
>Reporter: Radu Cotescu
> Fix For: Resource Merger 1.2.12
>
>
> Assuming there are two components A and B, where B inherits / overlays A, 
> either through {{sling:resourceSuperType}} or through regular search path 
> overlay, there's no way to define in B that some content trees should not be 
> merged, if B is obtained through the Resource Merger.
> A property like {{sling:skipMerging}} would make sense, which should be added 
> to the child resource in order for it not to inherit anything from the parent.



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