[jira] [Updated] (SLING-7436) Wrong content/type in the Default JSON Renderer

[Antonio Sanso (JIRA)]

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

Antonio Sanso updated SLING-7436:
-
Description: 
Steps to reproduce:
 1.Render a page (Renderer enabled) with JSON renderer. E.g:
 [http://localhost.com/dir/page(selector] value).json

2. Now, extend the url with a slash / and a name with any other extensions e.g 
 [http://localhost.com/dir/page.(value).json/file.html].]

 

3. Observe file.html was automatically downloaded

 

Credit: this issue was found by Md. Sabuktagin

  was:
Steps to reproduce:
1.Render a page (Renderer enabled) with JSON renderer. E.g:
http://localhost.com/dir/page(selector value).json

2. Now, extend the url with a slash(/) and a name with any other extensions e.g 
[http://localhost.com/dir/page.(value).json/file.html].]

 

3. Observe file.html was automatically downloaded


> Wrong content/type in the Default JSON Renderer 
> 
>
> Key: SLING-7436
> URL: https://issues.apache.org/jira/browse/SLING-7436
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Reporter: Antonio Sanso
>Priority: Major
>
> Steps to reproduce:
>  1.Render a page (Renderer enabled) with JSON renderer. E.g:
>  [http://localhost.com/dir/page(selector] value).json
> 2. Now, extend the url with a slash / and a name with any other extensions 
> e.g 
>  [http://localhost.com/dir/page.(value).json/file.html].]
>  
> 3. Observe file.html was automatically downloaded
>  
> Credit: this issue was found by Md. Sabuktagin



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SLING-7436) Wrong content/type in the Default JSON Renderer

[Antonio Sanso (JIRA)]

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

Antonio Sanso updated SLING-7436:
-
Description: 
Steps to reproduce:
 1.Render a page (Renderer enabled) with JSON renderer. E.g:
 [http://localhost.com/dir/page(selector] value).json

2. Now, extend the url with a slash / and a name with any other extensions e.g 
 [http://localhost.com/dir/page.(value).json/file.html].]

3. Observe file.html was automatically downloaded

Credit: this issue was found by Md. Sabuktagin

  was:
Steps to reproduce:
 1.Render a page (Renderer enabled) with JSON renderer. E.g:
 [http://localhost.com/dir/page(selector] value).json

2. Now, extend the url with a slash / and a name with any other extensions e.g 
 [http://localhost.com/dir/page.(value).json/file.html].]

 

3. Observe file.html was automatically downloaded

 

Credit: this issue was found by Md. Sabuktagin


> Wrong content/type in the Default JSON Renderer 
> 
>
> Key: SLING-7436
> URL: https://issues.apache.org/jira/browse/SLING-7436
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Reporter: Antonio Sanso
>Priority: Major
>
> Steps to reproduce:
>  1.Render a page (Renderer enabled) with JSON renderer. E.g:
>  [http://localhost.com/dir/page(selector] value).json
> 2. Now, extend the url with a slash / and a name with any other extensions 
> e.g 
>  [http://localhost.com/dir/page.(value).json/file.html].]
> 3. Observe file.html was automatically downloaded
> Credit: this issue was found by Md. Sabuktagin



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SLING-7436) Wrong content/type in the Default JSON Renderer

[Antonio Sanso (JIRA)]

Antonio Sanso created SLING-7436:


 Summary: Wrong content/type in the Default JSON Renderer 
 Key: SLING-7436
 URL: https://issues.apache.org/jira/browse/SLING-7436
 Project: Sling
  Issue Type: Bug
  Components: Servlets
Reporter: Antonio Sanso


Steps to reproduce:
1.Render a page (Renderer enabled) with JSON renderer. E.g:
http://localhost.com/dir/page(selector value).json

2. Now, extend the url with a slash(/) and a name with any other extensions e.g 
[http://localhost.com/dir/page.(value).json/file.html].]

 

3. Observe file.html was automatically downloaded



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-2778) initial Sling/Jolokia integration bundle

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra commented on SLING-2778:


[~justinedelson] Can you provide the path in sling repo (or in github) where 
this code lives?

> initial Sling/Jolokia integration bundle
> 
>
> Key: SLING-2778
> URL: https://issues.apache.org/jira/browse/SLING-2778
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Justin Edelson
>Assignee: Justin Edelson
>Priority: Major
>
> As promised/threatened here: http://markmail.org/message/3r2wgtn4mz3z6b73 I'd 
> like to commit an initial implementation of a Sling/Jolokia 
> ((http://www.jolokia.org/)) integration.
> Although Jolokia provides an OSGi bundle version, a Sling-specific 
> bundelization would provide authentication integration (similar to how the 
> Web Console provider works).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7432) Thread pool clean up code can lead to infinite loops in ThreadLocal.get

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-7432:


Interesting, I did not know about that. I looked briefly at the code and all 
that I found was the passing of 'inheritable' thread locals

{code:java}
if (inheritThreadLocals && parent.inheritableThreadLocals != null)
this.inheritableThreadLocals =
ThreadLocal.createInheritedMap(parent.inheritableThreadLocals);
{code:java}

Do you have any other references for the default thread locals? I'd like to 
make sure I don't mess anything up related to that.

> Thread pool clean up code can lead to infinite loops in ThreadLocal.get
> ---
>
> Key: SLING-7432
> URL: https://issues.apache.org/jira/browse/SLING-7432
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons Threads 3.2.10
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Blocker
> Fix For: Commons Threads 3.2.14
>
>
> The thread local clean up code added in SLING-6261 leads to Threads stuck in 
> {{ThreadLocal.get}}.
> I am working on a simplified test case, but the stack trace is similar to
> {noformat}
> "pool-1-thread-1" prio=10 tid=0x7f47f4374800 nid=0xb19 runnable 
> [0x7f47e734e000]
>java.lang.Thread.State: RUNNABLE
>   at java.lang.ThreadLocal$ThreadLocalMap.set(ThreadLocal.java:429)
>   at java.lang.ThreadLocal$ThreadLocalMap.access$100(ThreadLocal.java:261)
>   at java.lang.ThreadLocal.set(ThreadLocal.java:183)
>   at 
> org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocalsTest$RunnableImplementation.run(ThreadPoolExecutorCleaningThreadLocalsTest.java:100)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (SLING-7432) Thread pool clean up code can lead to infinite loops in ThreadLocal.get

[Robert Munteanu (JIRA)]

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

Robert Munteanu edited comment on SLING-7432 at 1/23/18 9:27 PM:
-

Interesting, I did not know about that. I looked briefly at the code and all 
that I found was the passing of 'inheritable' thread locals

{code:java}
if (inheritThreadLocals && parent.inheritableThreadLocals != null)
this.inheritableThreadLocals =
ThreadLocal.createInheritedMap(parent.inheritableThreadLocals);
{code}

Do you have any other references for the default thread locals? I'd like to 
make sure I don't mess anything up related to that.

_Edit_: formatting


was (Author: rombert):
Interesting, I did not know about that. I looked briefly at the code and all 
that I found was the passing of 'inheritable' thread locals

{code:java}
if (inheritThreadLocals && parent.inheritableThreadLocals != null)
this.inheritableThreadLocals =
ThreadLocal.createInheritedMap(parent.inheritableThreadLocals);
{code:java}

Do you have any other references for the default thread locals? I'd like to 
make sure I don't mess anything up related to that.

> Thread pool clean up code can lead to infinite loops in ThreadLocal.get
> ---
>
> Key: SLING-7432
> URL: https://issues.apache.org/jira/browse/SLING-7432
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons Threads 3.2.10
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Blocker
> Fix For: Commons Threads 3.2.14
>
>
> The thread local clean up code added in SLING-6261 leads to Threads stuck in 
> {{ThreadLocal.get}}.
> I am working on a simplified test case, but the stack trace is similar to
> {noformat}
> "pool-1-thread-1" prio=10 tid=0x7f47f4374800 nid=0xb19 runnable 
> [0x7f47e734e000]
>java.lang.Thread.State: RUNNABLE
>   at java.lang.ThreadLocal$ThreadLocalMap.set(ThreadLocal.java:429)
>   at java.lang.ThreadLocal$ThreadLocalMap.access$100(ThreadLocal.java:261)
>   at java.lang.ThreadLocal.set(ThreadLocal.java:183)
>   at 
> org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocalsTest$RunnableImplementation.run(ThreadPoolExecutorCleaningThreadLocalsTest.java:100)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7432) Thread pool clean up code can lead to infinite loops in ThreadLocal.get

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-7432:


New threads by default carry some thread locals (which are set by Oracle). 
Removing those once a thread from the pool is gonna be reused might have 
negative side-effects.

> Thread pool clean up code can lead to infinite loops in ThreadLocal.get
> ---
>
> Key: SLING-7432
> URL: https://issues.apache.org/jira/browse/SLING-7432
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons Threads 3.2.10
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Blocker
> Fix For: Commons Threads 3.2.14
>
>
> The thread local clean up code added in SLING-6261 leads to Threads stuck in 
> {{ThreadLocal.get}}.
> I am working on a simplified test case, but the stack trace is similar to
> {noformat}
> "pool-1-thread-1" prio=10 tid=0x7f47f4374800 nid=0xb19 runnable 
> [0x7f47e734e000]
>java.lang.Thread.State: RUNNABLE
>   at java.lang.ThreadLocal$ThreadLocalMap.set(ThreadLocal.java:429)
>   at java.lang.ThreadLocal$ThreadLocalMap.access$100(ThreadLocal.java:261)
>   at java.lang.ThreadLocal.set(ThreadLocal.java:183)
>   at 
> org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocalsTest$RunnableImplementation.run(ThreadPoolExecutorCleaningThreadLocalsTest.java:100)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7432) Thread pool clean up code can lead to infinite loops in ThreadLocal.get

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-7432:


While going deeper and deeper in the code we currently have, I wonder whether 
it's all necessary. We have a thread pool where we manage all threads, they 
never "escape" from our control. So we don't need to provide anyone with 
guarantees regarding restoring thread local values after threads have finished 
execution.

I think we can simply set the ThreadLocalMap fields to null and be done with it 
( and testing this assumption now ).

> Thread pool clean up code can lead to infinite loops in ThreadLocal.get
> ---
>
> Key: SLING-7432
> URL: https://issues.apache.org/jira/browse/SLING-7432
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons Threads 3.2.10
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Blocker
> Fix For: Commons Threads 3.2.14
>
>
> The thread local clean up code added in SLING-6261 leads to Threads stuck in 
> {{ThreadLocal.get}}.
> I am working on a simplified test case, but the stack trace is similar to
> {noformat}
> "pool-1-thread-1" prio=10 tid=0x7f47f4374800 nid=0xb19 runnable 
> [0x7f47e734e000]
>java.lang.Thread.State: RUNNABLE
>   at java.lang.ThreadLocal$ThreadLocalMap.set(ThreadLocal.java:429)
>   at java.lang.ThreadLocal$ThreadLocalMap.access$100(ThreadLocal.java:261)
>   at java.lang.ThreadLocal.set(ThreadLocal.java:183)
>   at 
> org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocalsTest$RunnableImplementation.run(ThreadPoolExecutorCleaningThreadLocalsTest.java:100)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Release Apache Sling Commons Threads 3.2.12

[Carsten Ziegeler]

Agree:

-1

Carsten


Robert Munteanu wrote
> On Mon, 2018-01-22 at 14:21 +0200, Robert Munteanu wrote:
>> On Mon, 2018-01-22 at 12:12 +0100, Stefan Egli wrote:
>>> Please vote to approve this release:
>>
>> +1
> 
> I am changing my vote to -1 in light of a blocking issue I discovered
> while doing some extensive tests.
> 
>   https://issues.apache.org/jira/browse/SLING-7432
> 
> Since this leads to threads being permanently blocked I believe we
> should cancel the release rather than release it in this state. 
> 
> Note that the problem is there since 3.2.10.
> 
> Robert
> 
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[jira] [Commented] (SLING-7428) StartupFilter not reliably stopped (and still returning 503) when executing org.apache.sling.scripting.sightly.testing

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-7428:
-

[~kwin] No, it might be a timing issue, when everything is ready and the readme 
is written later on. But I'm not sure about that

> StartupFilter not reliably stopped (and still returning 503) when executing 
> org.apache.sling.scripting.sightly.testing
> --
>
> Key: SLING-7428
> URL: https://issues.apache.org/jira/browse/SLING-7428
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Reporter: Konrad Windszus
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting HTL Testing Content 1.0.8-1.3.1
>
>
> For me the IT 
> https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content
>  fails every second time stating that client received status code 503. This 
> is due to the fact that the condition in 
> https://github.com/apache/sling-org-apache-sling-starter-startup/blob/dbe9746f945312a05f99648357ed4c88b01d325a/src/main/java/org/apache/sling/starter/startup/impl/Activator.java#L107
>  to stop the StartupFilter (which returns the 503) is never fulfilled.
> There is always the untransformed resource at 
> {{/apps/sightly/install/README}} 
> (https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content/blob/master/src/main/resources/SLING-INF/apps/sightly/install/README).
>  We should either remove this resource from the install folder (so that this 
> is no longer being picked up by the JCR installer) or we should no longer 
> check for untransformed resources (not sure about the implications).
> I am not sure why I am not running into this every time I execute the IT but 
> only about half of the time. Seems to be related to some unfortunate timings.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Git force push

[Robert Munteanu]

Hi,

On Tue, 2018-01-23 at 15:05 +0100, Stefan Egli wrote:
> Sounds like a good idea to start with disallowing --force for now,
> given
> there is --force-with-lease for emergencies. The unfortunate bit is
> perhaps that this opens up a way to modify history without noticing
> (which
> is what I've used it for too).

My impression is that --force-with-lease is entirely a client-side
setting, which means that we can't protect against accidents by
disabling it on GitHub, we can only document it as a convention.

Robert

[jira] [Created] (SLING-7434) Authorizable pipe autocreate group does not handle dryRun

[Nicolas Peltier (JIRA)]

Nicolas Peltier created SLING-7434:
--

 Summary: Authorizable pipe autocreate group does not handle dryRun
 Key: SLING-7434
 URL: https://issues.apache.org/jira/browse/SLING-7434
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: pipes 2.0.0
Reporter: Nicolas Peltier


autocreateGroup does not handle dry Run



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SLING-7435) Authorizable pipe autocreate group does not handle dryRun

[Nicolas Peltier (JIRA)]

Nicolas Peltier created SLING-7435:
--

 Summary: Authorizable pipe autocreate group does not handle dryRun
 Key: SLING-7435
 URL: https://issues.apache.org/jira/browse/SLING-7435
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: pipes 2.0.0
Reporter: Nicolas Peltier


autocreateGroup does not handle dry Run



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: documentation locations

[Oliver Lietz]

On Tuesday 23 January 2018 16:43:37 Bertrand Delacretaz wrote:
> Hi,
> 
> On Tue, Jan 23, 2018 at 3:40 PM, Oliver Lietz  wrote:
> > ...AFAIR we agreed on having basic documentation in the README and higher
> > level documentation or documentation spanning multiple modules on Sling's
> > site under /documentation...
> 
> That works for me - however until we have an automated list of all
> Sling modules it's good IMO to list all "important" bundles under
> http://sling.apache.org/documentation/bundles.html with at least a
> link to their own README if that's where their documentation is.

wip: https://oliverlietz.github.io/apache-sling-aggregator/

O.

> -Bertrand

Re: documentation locations

[Bertrand Delacretaz]

Hi,

On Tue, Jan 23, 2018 at 3:40 PM, Oliver Lietz  wrote:
> ...AFAIR we agreed on having basic documentation in the README and higher 
> level
> documentation or documentation spanning multiple modules on Sling's site under
> /documentation...

That works for me - however until we have an automated list of all
Sling modules it's good IMO to list all "important" bundles under
http://sling.apache.org/documentation/bundles.html with at least a
link to their own README if that's where their documentation is.

-Bertrand

[jira] [Commented] (SLING-7320) NPE in sling commons threads

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-7320:


Prevented the NPE in copy with 
https://github.com/apache/sling-org-apache-sling-commons-threads/commit/bb1ec98753d7972a63d961e81725796ac2a918a8.

> NPE in sling commons threads
> 
>
> Key: SLING-7320
> URL: https://issues.apache.org/jira/browse/SLING-7320
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons Threads 3.2.10
> Environment: Linux, jdk18
>Reporter: Ivo Leitão
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: Commons Threads 3.2.14
>
>
> I'm currently running a number of integration tests via pax exam and 
> sometimes I see the following stacktrace. I've already seen this in a running 
> sling also. This happens only in some runs but on that cases is breaking my 
> CI workflow
> Exception in thread "sling-default-5" java.lang.NullPointerException
>   at 
> org.apache.sling.commons.threads.impl.ThreadLocalCleaner.copy(ThreadLocalCleaner.java:186)
>   at 
> org.apache.sling.commons.threads.impl.ThreadLocalCleaner.saveOldThreadLocals(ThreadLocalCleaner.java:176)
>   at 
> org.apache.sling.commons.threads.impl.ThreadLocalCleaner.(ThreadLocalCleaner.java:51)
>   at 
> org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocals.beforeExecute(ThreadPoolExecutorCleaningThreadLocals.java:55)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at java.lang.Thread.run(Thread.java:748)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SLING-7320) NPE in sling commons threads

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-7320:
---
Fix Version/s: Commons Threads 3.2.14

> NPE in sling commons threads
> 
>
> Key: SLING-7320
> URL: https://issues.apache.org/jira/browse/SLING-7320
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons Threads 3.2.10
> Environment: Linux, jdk18
>Reporter: Ivo Leitão
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: Commons Threads 3.2.14
>
>
> I'm currently running a number of integration tests via pax exam and 
> sometimes I see the following stacktrace. I've already seen this in a running 
> sling also. This happens only in some runs but on that cases is breaking my 
> CI workflow
> Exception in thread "sling-default-5" java.lang.NullPointerException
>   at 
> org.apache.sling.commons.threads.impl.ThreadLocalCleaner.copy(ThreadLocalCleaner.java:186)
>   at 
> org.apache.sling.commons.threads.impl.ThreadLocalCleaner.saveOldThreadLocals(ThreadLocalCleaner.java:176)
>   at 
> org.apache.sling.commons.threads.impl.ThreadLocalCleaner.(ThreadLocalCleaner.java:51)
>   at 
> org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocals.beforeExecute(ThreadPoolExecutorCleaningThreadLocals.java:55)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at java.lang.Thread.run(Thread.java:748)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (SLING-7433) Improve logging in case ThreadLocalCleaner does not work

[Konrad Windszus (JIRA)]

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

Konrad Windszus resolved SLING-7433.

   Resolution: Fixed
Fix Version/s: Commons Threads 3.2.14

Fixed in 
https://github.com/apache/sling-org-apache-sling-commons-threads/commit/1ffb9d9c12637e790151ad499cfb2c5738e9dbdd.

> Improve logging in case ThreadLocalCleaner does not work
> 
>
> Key: SLING-7433
> URL: https://issues.apache.org/jira/browse/SLING-7433
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Affects Versions: Commons Threads 3.2.10
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: Commons Threads 3.2.14
>
>
> Currently {{ThreadLocalCleaner}} relies on exceptions in case anything in it 
> does not work as expected. Those exceptions are most probably not correctly 
> caught and logged by the Oracle implementation calling 
> {{ThreadPoolExecutor.beforeExecute(...)}} and 
> {{ThreadPoolExecutor.afterExecute(...)}}. Therefore all exceptions should be 
> caught and logged there explicitly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SLING-7433) Improve logging in case ThreadLocalCleaner does not work

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-7433:
---
Description: Currently {{ThreadLocalCleaner}} relies on exceptions in case 
anything in it does not work as expected. Those exceptions are most probably 
not correctly caught and logged by the Oracle implementation calling 
{{ThreadPoolExecutor.beforeExecute(...)}} and 
{{ThreadPoolExecutor.afterExecute(...)}}. Therefore all exceptions should be 
caught and logged there explicitly.  (was: Currently {{ThreadLocalCleaner}} 
relies on exceptions in case it does not work as expected. Those exceptions are 
most probably not correctly caught and logged by the Oracle implementation 
calling {{ThreadPoolExecutor.beforeExecute(...)}} and 
{{ThreadPoolExecutor.afterExecute(...)}}. Therefore all exceptions should be 
caught and logged there explicitly.)

> Improve logging in case ThreadLocalCleaner does not work
> 
>
> Key: SLING-7433
> URL: https://issues.apache.org/jira/browse/SLING-7433
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Affects Versions: Commons Threads 3.2.10
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently {{ThreadLocalCleaner}} relies on exceptions in case anything in it 
> does not work as expected. Those exceptions are most probably not correctly 
> caught and logged by the Oracle implementation calling 
> {{ThreadPoolExecutor.beforeExecute(...)}} and 
> {{ThreadPoolExecutor.afterExecute(...)}}. Therefore all exceptions should be 
> caught and logged there explicitly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SLING-7433) Improve logging in case ThreadLocalCleaner does not work

[Konrad Windszus (JIRA)]

Konrad Windszus created SLING-7433:
--

 Summary: Improve logging in case ThreadLocalCleaner does not work
 Key: SLING-7433
 URL: https://issues.apache.org/jira/browse/SLING-7433
 Project: Sling
  Issue Type: Improvement
  Components: Commons
Affects Versions: Commons Threads 3.2.10
Reporter: Konrad Windszus
Assignee: Konrad Windszus


Currently {{ThreadLocalCleaner}} relies on exceptions in case it does not work 
as expected. Those exceptions are most probably not correctly caught and logged 
by the Oracle implementation calling {{ThreadPoolExecutor.beforeExecute(...)}} 
and {{ThreadPoolExecutor.afterExecute(...)}}. Therefore all exceptions should 
be caught and logged there explicitly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (SLING-7320) NPE in sling commons threads

[Konrad Windszus (JIRA)]

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

Konrad Windszus reassigned SLING-7320:
--

Assignee: Konrad Windszus

> NPE in sling commons threads
> 
>
> Key: SLING-7320
> URL: https://issues.apache.org/jira/browse/SLING-7320
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons Threads 3.2.10
> Environment: Linux, jdk18
>Reporter: Ivo Leitão
>Assignee: Konrad Windszus
>Priority: Major
>
> I'm currently running a number of integration tests via pax exam and 
> sometimes I see the following stacktrace. I've already seen this in a running 
> sling also. This happens only in some runs but on that cases is breaking my 
> CI workflow
> Exception in thread "sling-default-5" java.lang.NullPointerException
>   at 
> org.apache.sling.commons.threads.impl.ThreadLocalCleaner.copy(ThreadLocalCleaner.java:186)
>   at 
> org.apache.sling.commons.threads.impl.ThreadLocalCleaner.saveOldThreadLocals(ThreadLocalCleaner.java:176)
>   at 
> org.apache.sling.commons.threads.impl.ThreadLocalCleaner.(ThreadLocalCleaner.java:51)
>   at 
> org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocals.beforeExecute(ThreadPoolExecutorCleaningThreadLocals.java:55)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at java.lang.Thread.run(Thread.java:748)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7320) NPE in sling commons threads

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-7320:


The latter NPE can only happen if listener is {{null}}. {{listener}} is a final 
field in {{ThreadLocalCleaner}} and is set only once in the constructor. Can 
you give a test case how to reproduce? At least from within Sling the listener 
can never be {{null}}.

The former NPE can only happen if the initReflectionFields() method has thrown 
an exception (which may happen with other JDKs than OpenJDK/Oracle). I will 
guard around this better in the future.

> NPE in sling commons threads
> 
>
> Key: SLING-7320
> URL: https://issues.apache.org/jira/browse/SLING-7320
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons Threads 3.2.10
> Environment: Linux, jdk18
>Reporter: Ivo Leitão
>Priority: Major
>
> I'm currently running a number of integration tests via pax exam and 
> sometimes I see the following stacktrace. I've already seen this in a running 
> sling also. This happens only in some runs but on that cases is breaking my 
> CI workflow
> Exception in thread "sling-default-5" java.lang.NullPointerException
>   at 
> org.apache.sling.commons.threads.impl.ThreadLocalCleaner.copy(ThreadLocalCleaner.java:186)
>   at 
> org.apache.sling.commons.threads.impl.ThreadLocalCleaner.saveOldThreadLocals(ThreadLocalCleaner.java:176)
>   at 
> org.apache.sling.commons.threads.impl.ThreadLocalCleaner.(ThreadLocalCleaner.java:51)
>   at 
> org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocals.beforeExecute(ThreadPoolExecutorCleaningThreadLocals.java:55)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at java.lang.Thread.run(Thread.java:748)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (SLING-7428) StartupFilter not reliably stopped (and still returning 503) when executing org.apache.sling.scripting.sightly.testing

[Radu Cotescu (JIRA)]

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

Radu Cotescu resolved SLING-7428.
-
Resolution: Fixed

Fixed in [commit 
771e739|https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content/commit/771e739].

> StartupFilter not reliably stopped (and still returning 503) when executing 
> org.apache.sling.scripting.sightly.testing
> --
>
> Key: SLING-7428
> URL: https://issues.apache.org/jira/browse/SLING-7428
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Reporter: Konrad Windszus
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting HTL Testing Content 1.0.8-1.3.1
>
>
> For me the IT 
> https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content
>  fails every second time stating that client received status code 503. This 
> is due to the fact that the condition in 
> https://github.com/apache/sling-org-apache-sling-starter-startup/blob/dbe9746f945312a05f99648357ed4c88b01d325a/src/main/java/org/apache/sling/starter/startup/impl/Activator.java#L107
>  to stop the StartupFilter (which returns the 503) is never fulfilled.
> There is always the untransformed resource at 
> {{/apps/sightly/install/README}} 
> (https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content/blob/master/src/main/resources/SLING-INF/apps/sightly/install/README).
>  We should either remove this resource from the install folder (so that this 
> is no longer being picked up by the JCR installer) or we should no longer 
> check for untransformed resources (not sure about the implications).
> I am not sure why I am not running into this every time I execute the IT but 
> only about half of the time. Seems to be related to some unfortunate timings.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7432) Thread pool clean up code can lead to infinite loops in ThreadLocal.get

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-7432:


Well, I apparently fixed one problem, but I am still able to reproduce the hang 
outside the unit test :| So I need to dig a bit more

> Thread pool clean up code can lead to infinite loops in ThreadLocal.get
> ---
>
> Key: SLING-7432
> URL: https://issues.apache.org/jira/browse/SLING-7432
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons Threads 3.2.10
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Blocker
> Fix For: Commons Threads 3.2.14
>
>
> The thread local clean up code added in SLING-6261 leads to Threads stuck in 
> {{ThreadLocal.get}}.
> I am working on a simplified test case, but the stack trace is similar to
> {noformat}
> "pool-1-thread-1" prio=10 tid=0x7f47f4374800 nid=0xb19 runnable 
> [0x7f47e734e000]
>java.lang.Thread.State: RUNNABLE
>   at java.lang.ThreadLocal$ThreadLocalMap.set(ThreadLocal.java:429)
>   at java.lang.ThreadLocal$ThreadLocalMap.access$100(ThreadLocal.java:261)
>   at java.lang.ThreadLocal.set(ThreadLocal.java:183)
>   at 
> org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocalsTest$RunnableImplementation.run(ThreadPoolExecutorCleaningThreadLocalsTest.java:100)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7432) Thread pool clean up code can lead to infinite loops in ThreadLocal.get

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-7432:


Looks good to me. I am wondering whether 
https://issues.apache.org/jira/browse/SLING-7320 is related but up to now I 
couldn't reproduce the NPE.

> Thread pool clean up code can lead to infinite loops in ThreadLocal.get
> ---
>
> Key: SLING-7432
> URL: https://issues.apache.org/jira/browse/SLING-7432
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons Threads 3.2.10
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Blocker
> Fix For: Commons Threads 3.2.14
>
>
> The thread local clean up code added in SLING-6261 leads to Threads stuck in 
> {{ThreadLocal.get}}.
> I am working on a simplified test case, but the stack trace is similar to
> {noformat}
> "pool-1-thread-1" prio=10 tid=0x7f47f4374800 nid=0xb19 runnable 
> [0x7f47e734e000]
>java.lang.Thread.State: RUNNABLE
>   at java.lang.ThreadLocal$ThreadLocalMap.set(ThreadLocal.java:429)
>   at java.lang.ThreadLocal$ThreadLocalMap.access$100(ThreadLocal.java:261)
>   at java.lang.ThreadLocal.set(ThreadLocal.java:183)
>   at 
> org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocalsTest$RunnableImplementation.run(ThreadPoolExecutorCleaningThreadLocalsTest.java:100)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SLING-7428) StartupFilter not reliably stopped (and still returning 503) when executing org.apache.sling.scripting.sightly.testing

[Radu Cotescu (JIRA)]

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

Radu Cotescu updated SLING-7428:

Fix Version/s: Scripting HTL Testing Content 1.0.8-1.3.1

> StartupFilter not reliably stopped (and still returning 503) when executing 
> org.apache.sling.scripting.sightly.testing
> --
>
> Key: SLING-7428
> URL: https://issues.apache.org/jira/browse/SLING-7428
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Reporter: Konrad Windszus
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting HTL Testing Content 1.0.8-1.3.1
>
>
> For me the IT 
> https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content
>  fails every second time stating that client received status code 503. This 
> is due to the fact that the condition in 
> https://github.com/apache/sling-org-apache-sling-starter-startup/blob/dbe9746f945312a05f99648357ed4c88b01d325a/src/main/java/org/apache/sling/starter/startup/impl/Activator.java#L107
>  to stop the StartupFilter (which returns the 503) is never fulfilled.
> There is always the untransformed resource at 
> {{/apps/sightly/install/README}} 
> (https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content/blob/master/src/main/resources/SLING-INF/apps/sightly/install/README).
>  We should either remove this resource from the install folder (so that this 
> is no longer being picked up by the JCR installer) or we should no longer 
> check for untransformed resources (not sure about the implications).
> I am not sure why I am not running into this every time I execute the IT but 
> only about half of the time. Seems to be related to some unfortunate timings.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (SLING-7431) Allow the HTL IT to run against the latest stable launchpad artifact and against the latest snapshot

[Radu Cotescu (JIRA)]

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

Radu Cotescu resolved SLING-7431.
-
Resolution: Fixed

Fixed in [commit 
f650f92|https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing/commit/f650f92].

> Allow the HTL IT to run against the latest stable launchpad artifact and 
> against the latest snapshot
> 
>
> Key: SLING-7431
> URL: https://issues.apache.org/jira/browse/SLING-7431
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting HTL Testing 1.0.6-1.3.1
>
>
> In order to be able to release the module that provides the HTL IT, the tests 
> should be able to be executed against the most recent release of the Apache 
> Sling launchpad / starter application. However, in order to make sure that 
> HTL can also run on the latest available launchpad / starter application, the 
> tests should also be possible to be executed against a snapshot instance.
> For this two profiles should be made available:
> * one for the snapshot Sling instance, active by default, that would make 
> sure the tests are executed agains the latest snapshot starter application
> * one for releasing, conditionally activated, that would disable the 
> execution of the default profile and would allow executing the tests against 
> the latest released Sling launchpad / starter app



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: documentation locations

[Oliver Lietz]

On Tuesday 23 January 2018 13:54:30 Jason Bailey wrote:
> Is there a determination on where the true source of documentation is?
> We have the sling-site project, we have the README in each individual
> project and the plugins are using the maven-sites-plugin.

AFAIR we agreed on having basic documentation in the README and higher level 
documentation or documentation spanning multiple modules on Sling's site under 
/documentation.
 
> In Git projects it's usually the README or a unique docs folder. In a
> related note, if the README isn't being used for documentation, what should
> be in there?

A link to the documentation.

HTH,
O.

[jira] [Comment Edited] (SLING-7406) Provide HTL specification version info in artifact names

[Radu Cotescu (JIRA)]

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

Radu Cotescu edited comment on SLING-7406 at 1/23/18 2:35 PM:
--

Fixed in the following commits:
* [commit 
af00ddd|https://github.com/apache/sling-org-apache-sling-scripting-sightly-compiler/commit/af00ddd]
* [commit 
bdbbc2a|https://github.com/apache/sling-org-apache-sling-scripting-sightly-compiler-java/commit/bdbbc2a]
* [commit 
e8e3068|https://github.com/apache/sling-org-apache-sling-scripting-sightly/commit/e8e3068]
* [commit 
5bcdcc8|https://github.com/apache/sling-htl-maven-plugin/commit/5bcdcc8]
* [commit 
00faec5|https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content/commit/00faec5]
* [commit 
14b3b60|https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing/commit/14b3b60]
 and [commit 
aacbaae|https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing/commit/aacbaae]


was (Author: radu.cotescu):
Fixed in the following commits:
* [commit 
af00ddd|https://github.com/apache/sling-org-apache-sling-scripting-sightly-compiler/commit/af00ddd]
* [commit 
bdbbc2a|https://github.com/apache/sling-org-apache-sling-scripting-sightly-compiler-java/commit/bdbbc2a]
* [commit 
e8e3068|https://github.com/apache/sling-org-apache-sling-scripting-sightly/commit/e8e3068]
* [commit 
5bcdcc8|https://github.com/apache/sling-htl-maven-plugin/commit/5bcdcc8]
* [commit 
00faec5|https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content/commit/00faec5]
* [commit 
14b3b60|https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing/commit/14b3b60]

> Provide HTL specification version info in artifact names
> 
>
> Key: SLING-7406
> URL: https://issues.apache.org/jira/browse/SLING-7406
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting, Tooling
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting HTL Java Compiler 1.0.22-1.3.1, HTL Maven 
> Plugin 1.1.4-1.3.1, Scripting HTL Compiler 1.0.20-1.3.1, Scripting HTL Engine 
> 1.0.48-1.3.1, Scripting HTL Testing 1.0.6-1.3.1, Scripting HTL Testing 
> Content 1.0.8-1.3.1
>
>
> As discussed in \[0\], the HTL modules versioning scheme should be updated to 
> reflect what HTP specification version they support, in addition to the 
> bundle headers the modules already provide.
> \[0\] - 
> https://lists.apache.org/thread.html/ea63bcfe6fd75b6318b4e27d88b67d9783d945baecef692a5d08ae75@%3Cdev.sling.apache.org%3E



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7432) Thread pool clean up code can lead to infinite loops in ThreadLocal.get

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-7432:


Applied a potential fix in [sling-org-apache-sling-commons-threads commit 
afa59d6|https://github.com/apache/sling-org-apache-sling-commons-threads/commit/afa59d6].
 This at least makes the failing test for me.

[~kwin] - I am going to run some more extensive tests, but it would be good if 
you could also review the change. I've checked and the {{ThreadLocalMap}} has 
the same three fields in Java 7, 8 and 9, so we should be covered at least from 
that point of view.

> Thread pool clean up code can lead to infinite loops in ThreadLocal.get
> ---
>
> Key: SLING-7432
> URL: https://issues.apache.org/jira/browse/SLING-7432
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons Threads 3.2.10
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Blocker
> Fix For: Commons Threads 3.2.14
>
>
> The thread local clean up code added in SLING-6261 leads to Threads stuck in 
> {{ThreadLocal.get}}.
> I am working on a simplified test case, but the stack trace is similar to
> {noformat}
> "pool-1-thread-1" prio=10 tid=0x7f47f4374800 nid=0xb19 runnable 
> [0x7f47e734e000]
>java.lang.Thread.State: RUNNABLE
>   at java.lang.ThreadLocal$ThreadLocalMap.set(ThreadLocal.java:429)
>   at java.lang.ThreadLocal$ThreadLocalMap.access$100(ThreadLocal.java:261)
>   at java.lang.ThreadLocal.set(ThreadLocal.java:183)
>   at 
> org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocalsTest$RunnableImplementation.run(ThreadPoolExecutorCleaningThreadLocalsTest.java:100)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7421) JcrResourceBundle does not correctly support multiple base names

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-7421:


I added an IT for this in 
https://github.com/apache/sling-org-apache-sling-i18n/commit/b1ab32bc1c470e5509c915ae97530ea933989219.

> JcrResourceBundle does not correctly support multiple base names
> 
>
> Key: SLING-7421
> URL: https://issues.apache.org/jira/browse/SLING-7421
> Project: Sling
>  Issue Type: Bug
>  Components: i18n
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Critical
> Fix For: i18n 2.5.12
>
>
> The fix for SLING-4547 is incompete - the {{baseNames}} property is read but 
> not used.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Release Apache Sling Commons Threads 3.2.12

[Oliver Lietz]

On Monday 22 January 2018 12:12:44 Stefan Egli wrote:
> Hi,
> 
> we solved 1 issue in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12341693

+1

O.

[jira] [Resolved] (SLING-7406) Provide HTL specification version info in artifact names

[Radu Cotescu (JIRA)]

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

Radu Cotescu resolved SLING-7406.
-
Resolution: Fixed

Fixed in the following commits:
* [commit 
af00ddd|https://github.com/apache/sling-org-apache-sling-scripting-sightly-compiler/commit/af00ddd]
* [commit 
bdbbc2a|https://github.com/apache/sling-org-apache-sling-scripting-sightly-compiler-java/commit/bdbbc2a]
* [commit 
e8e3068|https://github.com/apache/sling-org-apache-sling-scripting-sightly/commit/e8e3068]
* [commit 
5bcdcc8|https://github.com/apache/sling-htl-maven-plugin/commit/5bcdcc8]
* [commit 
00faec5|https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content/commit/00faec5]
* [commit 
14b3b60|https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing/commit/14b3b60]

> Provide HTL specification version info in artifact names
> 
>
> Key: SLING-7406
> URL: https://issues.apache.org/jira/browse/SLING-7406
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting, Tooling
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting HTL Java Compiler 1.0.22-1.3.1, HTL Maven 
> Plugin 1.1.4-1.3.1, Scripting HTL Compiler 1.0.20-1.3.1, Scripting HTL Engine 
> 1.0.48-1.3.1, Scripting HTL Testing 1.0.6-1.3.1, Scripting HTL Testing 
> Content 1.0.8-1.3.1
>
>
> As discussed in \[0\], the HTL modules versioning scheme should be updated to 
> reflect what HTP specification version they support, in addition to the 
> bundle headers the modules already provide.
> \[0\] - 
> https://lists.apache.org/thread.html/ea63bcfe6fd75b6318b4e27d88b67d9783d945baecef692a5d08ae75@%3Cdev.sling.apache.org%3E



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7428) StartupFilter not reliably stopped (and still returning 503) when executing org.apache.sling.scripting.sightly.testing

[Radu Cotescu (JIRA)]

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

Radu Cotescu commented on SLING-7428:
-

ACK: I'll move the README file. :)

> StartupFilter not reliably stopped (and still returning 503) when executing 
> org.apache.sling.scripting.sightly.testing
> --
>
> Key: SLING-7428
> URL: https://issues.apache.org/jira/browse/SLING-7428
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Reporter: Konrad Windszus
>Assignee: Radu Cotescu
>Priority: Major
>
> For me the IT 
> https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content
>  fails every second time stating that client received status code 503. This 
> is due to the fact that the condition in 
> https://github.com/apache/sling-org-apache-sling-starter-startup/blob/dbe9746f945312a05f99648357ed4c88b01d325a/src/main/java/org/apache/sling/starter/startup/impl/Activator.java#L107
>  to stop the StartupFilter (which returns the 503) is never fulfilled.
> There is always the untransformed resource at 
> {{/apps/sightly/install/README}} 
> (https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content/blob/master/src/main/resources/SLING-INF/apps/sightly/install/README).
>  We should either remove this resource from the install folder (so that this 
> is no longer being picked up by the JCR installer) or we should no longer 
> check for untransformed resources (not sure about the implications).
> I am not sure why I am not running into this every time I execute the IT but 
> only about half of the time. Seems to be related to some unfortunate timings.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Git force push

[Stefan Egli]

Sounds like a good idea to start with disallowing --force for now, given
there is --force-with-lease for emergencies. The unfortunate bit is
perhaps that this opens up a way to modify history without noticing (which
is what I've used it for too).

Cheers,
Stefan

On 23.01.18, 14:59, "Jason Bailey"  wrote:

>The methodology with GIT is usually around never committing anything
>directly to master, rather branch and merge. Internally I have our github
>projects set up to prevent force pushes to master and to allow it on
>branches so that the developer working on that branch has the option of
>fixing things if there is an oops
>
>I haven't seen the -force-with-lease before so I can't say how well it
>works, but that has definitely jumped to the top of my "commands to now
>use"
>
>-Original Message-
>From: Bertrand Delacretaz [mailto:bdelacre...@apache.org]
>Sent: Tuesday, January 23, 2018 8:49 AM
>To: dev 
>Subject: Re: Git force push
>
>EXTERNAL
>
>On Tue, Jan 23, 2018 at 2:33 PM, Stefan Seifert 
>wrote:
>> i would also vote for *not* allowing push --force..
>
>+1, my understanding is that one can destroy history with that...which
>we don't want.
>
>I have never used --force-with-lease so far but according to [1] it only
>allows you to force-push if no-one else has pushed changes up to the
>remote in the interim.
>
>If that's correct (does anyone have experience with it?) I'd be in favor
>of allowing --force-with-lease but not --force. With our many
>repositories we often have a single committer working on a given
>repository for some time, in which case --force-with-lease could help,
>apparently.
>
>-Bertrand
>
>[1] https://developer.atlassian.com/blog/2015/04/force-with-lease/

[jira] [Comment Edited] (SLING-7428) StartupFilter not reliably stopped (and still returning 503) when executing org.apache.sling.scripting.sightly.testing

[Radu Cotescu (JIRA)]

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

Radu Cotescu edited comment on SLING-7428 at 1/23/18 2:08 PM:
--

[~cziegeler], any idea why this issue did not occur with every execution?


was (Author: kwin):
Any idea why this issue did not occur with every execution?

> StartupFilter not reliably stopped (and still returning 503) when executing 
> org.apache.sling.scripting.sightly.testing
> --
>
> Key: SLING-7428
> URL: https://issues.apache.org/jira/browse/SLING-7428
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Reporter: Konrad Windszus
>Assignee: Radu Cotescu
>Priority: Major
>
> For me the IT 
> https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content
>  fails every second time stating that client received status code 503. This 
> is due to the fact that the condition in 
> https://github.com/apache/sling-org-apache-sling-starter-startup/blob/dbe9746f945312a05f99648357ed4c88b01d325a/src/main/java/org/apache/sling/starter/startup/impl/Activator.java#L107
>  to stop the StartupFilter (which returns the 503) is never fulfilled.
> There is always the untransformed resource at 
> {{/apps/sightly/install/README}} 
> (https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content/blob/master/src/main/resources/SLING-INF/apps/sightly/install/README).
>  We should either remove this resource from the install folder (so that this 
> is no longer being picked up by the JCR installer) or we should no longer 
> check for untransformed resources (not sure about the implications).
> I am not sure why I am not running into this every time I execute the IT but 
> only about half of the time. Seems to be related to some unfortunate timings.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[CANCELLED][VOTE] Release Apache Sling Commons Threads 3.2.12

[Stefan Egli]

Cancelling this release as per comment from Robert re SLING-7432.

I'd suggest to use 3.2.14 for a next commons threads release once that is
ready.

Cheers,
Stefan

On 22.01.18, 12:12, "Stefan Egli"  wrote:

>Hi,
>
>we solved 1 issue in this release:
>https://issues.apache.org/jira/browse/SLING/fixforversion/12341693
>
>Staging repository:
>https://repository.apache.org/content/repositories/orgapachesling-1859/
>
>You can use this UNIX script to download the release and verify the
>signatures:
>https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=c
>h
>eck_staged_release.sh;hb=HEAD
>
>Usage:
>sh check_staged_release.sh 1859 /tmp/sling-staging
>
>Please vote to approve this release:
>
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
>
>This majority vote is open for at least 72 hours.
>
>
>
>Cheers,
>Stefan
>
>

[jira] [Commented] (SLING-7428) StartupFilter not reliably stopped (and still returning 503) when executing org.apache.sling.scripting.sightly.testing

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-7428:


Any idea why this issue did not occur with every execution?

> StartupFilter not reliably stopped (and still returning 503) when executing 
> org.apache.sling.scripting.sightly.testing
> --
>
> Key: SLING-7428
> URL: https://issues.apache.org/jira/browse/SLING-7428
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Reporter: Konrad Windszus
>Assignee: Radu Cotescu
>Priority: Major
>
> For me the IT 
> https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content
>  fails every second time stating that client received status code 503. This 
> is due to the fact that the condition in 
> https://github.com/apache/sling-org-apache-sling-starter-startup/blob/dbe9746f945312a05f99648357ed4c88b01d325a/src/main/java/org/apache/sling/starter/startup/impl/Activator.java#L107
>  to stop the StartupFilter (which returns the 503) is never fulfilled.
> There is always the untransformed resource at 
> {{/apps/sightly/install/README}} 
> (https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content/blob/master/src/main/resources/SLING-INF/apps/sightly/install/README).
>  We should either remove this resource from the install folder (so that this 
> is no longer being picked up by the JCR installer) or we should no longer 
> check for untransformed resources (not sure about the implications).
> I am not sure why I am not running into this every time I execute the IT but 
> only about half of the time. Seems to be related to some unfortunate timings.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SLING-7406) Provide HTL specification version info in artifact names

[Radu Cotescu (JIRA)]

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

Radu Cotescu updated SLING-7406:

Fix Version/s: Scripting HTL Testing 1.0.6-1.3.1
   Scripting HTL Testing Content 1.0.8-1.3.1

> Provide HTL specification version info in artifact names
> 
>
> Key: SLING-7406
> URL: https://issues.apache.org/jira/browse/SLING-7406
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting, Tooling
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting HTL Java Compiler 1.0.22-1.3.1, HTL Maven 
> Plugin 1.1.4-1.3.1, Scripting HTL Compiler 1.0.20-1.3.1, Scripting HTL Engine 
> 1.0.48-1.3.1, Scripting HTL Testing 1.0.6-1.3.1, Scripting HTL Testing 
> Content 1.0.8-1.3.1
>
>
> As discussed in \[0\], the HTL modules versioning scheme should be updated to 
> reflect what HTP specification version they support, in addition to the 
> bundle headers the modules already provide.
> \[0\] - 
> https://lists.apache.org/thread.html/ea63bcfe6fd75b6318b4e27d88b67d9783d945baecef692a5d08ae75@%3Cdev.sling.apache.org%3E



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

RE: Git force push

[Jason Bailey]

The methodology with GIT is usually around never committing anything directly 
to master, rather branch and merge. Internally I have our github projects set 
up to prevent force pushes to master and to allow it on branches so that the 
developer working on that branch has the option of fixing things if there is an 
oops

I haven't seen the -force-with-lease before so I can't say how well it works, 
but that has definitely jumped to the top of my "commands to now use"

-Original Message-
From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] 
Sent: Tuesday, January 23, 2018 8:49 AM
To: dev 
Subject: Re: Git force push

EXTERNAL

On Tue, Jan 23, 2018 at 2:33 PM, Stefan Seifert  wrote:
> i would also vote for *not* allowing push --force..

+1, my understanding is that one can destroy history with that...which
we don't want.

I have never used --force-with-lease so far but according to [1] it only allows 
you to force-push if no-one else has pushed changes up to the remote in the 
interim.

If that's correct (does anyone have experience with it?) I'd be in favor of 
allowing --force-with-lease but not --force. With our many repositories we 
often have a single committer working on a given repository for some time, in 
which case --force-with-lease could help, apparently.

-Bertrand

[1] https://developer.atlassian.com/blog/2015/04/force-with-lease/

[jira] [Comment Edited] (SLING-7432) Thread pool clean up code can lead to infinite loops in ThreadLocal.get

[Robert Munteanu (JIRA)]

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

Robert Munteanu edited comment on SLING-7432 at 1/23/18 1:58 PM:
-

Added ignored test in [sling-org-apache-sling-commons-threads commit 
21a553d|https://github.com/apache/sling-org-apache-sling-commons-threads/commit/21a553d]



was (Author: rombert):
Added ignore test in [sling-org-apache-sling-commons-threads commit 
21a553d|https://github.com/apache/sling-org-apache-sling-commons-threads/commit/21a553d]


> Thread pool clean up code can lead to infinite loops in ThreadLocal.get
> ---
>
> Key: SLING-7432
> URL: https://issues.apache.org/jira/browse/SLING-7432
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons Threads 3.2.10
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Blocker
> Fix For: Commons Threads 3.2.14
>
>
> The thread local clean up code added in SLING-6261 leads to Threads stuck in 
> {{ThreadLocal.get}}.
> I am working on a simplified test case, but the stack trace is similar to
> {noformat}
> "pool-1-thread-1" prio=10 tid=0x7f47f4374800 nid=0xb19 runnable 
> [0x7f47e734e000]
>java.lang.Thread.State: RUNNABLE
>   at java.lang.ThreadLocal$ThreadLocalMap.set(ThreadLocal.java:429)
>   at java.lang.ThreadLocal$ThreadLocalMap.access$100(ThreadLocal.java:261)
>   at java.lang.ThreadLocal.set(ThreadLocal.java:183)
>   at 
> org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocalsTest$RunnableImplementation.run(ThreadPoolExecutorCleaningThreadLocalsTest.java:100)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7432) Thread pool clean up code can lead to infinite loops in ThreadLocal.get

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-7432:


Added ignore test in [sling-org-apache-sling-commons-threads commit 
21a553d|https://github.com/apache/sling-org-apache-sling-commons-threads/commit/21a553d]


> Thread pool clean up code can lead to infinite loops in ThreadLocal.get
> ---
>
> Key: SLING-7432
> URL: https://issues.apache.org/jira/browse/SLING-7432
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons Threads 3.2.10
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Blocker
> Fix For: Commons Threads 3.2.14
>
>
> The thread local clean up code added in SLING-6261 leads to Threads stuck in 
> {{ThreadLocal.get}}.
> I am working on a simplified test case, but the stack trace is similar to
> {noformat}
> "pool-1-thread-1" prio=10 tid=0x7f47f4374800 nid=0xb19 runnable 
> [0x7f47e734e000]
>java.lang.Thread.State: RUNNABLE
>   at java.lang.ThreadLocal$ThreadLocalMap.set(ThreadLocal.java:429)
>   at java.lang.ThreadLocal$ThreadLocalMap.access$100(ThreadLocal.java:261)
>   at java.lang.ThreadLocal.set(ThreadLocal.java:183)
>   at 
> org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocalsTest$RunnableImplementation.run(ThreadPoolExecutorCleaningThreadLocalsTest.java:100)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Release Apache Sling Commons Threads 3.2.12

[Robert Munteanu]

On Mon, 2018-01-22 at 14:21 +0200, Robert Munteanu wrote:
> On Mon, 2018-01-22 at 12:12 +0100, Stefan Egli wrote:
> > Please vote to approve this release:
> 
> +1

I am changing my vote to -1 in light of a blocking issue I discovered
while doing some extensive tests.

  https://issues.apache.org/jira/browse/SLING-7432

Since this leads to threads being permanently blocked I believe we
should cancel the release rather than release it in this state. 

Note that the problem is there since 3.2.10.

Robert

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

documentation locations

[Jason Bailey]

Is there a determination on where the true source of documentation is?
We have the sling-site project, we have the README in each individual project 
and the plugins are using the maven-sites-plugin. 

In Git projects it's usually the README or a unique docs folder. In a related 
note, if the README isn't being used for documentation, what should be in there?

[jira] [Created] (SLING-7432) Thread pool clean up code can lead to infinite loops in ThreadLocal.get

[Robert Munteanu (JIRA)]

Robert Munteanu created SLING-7432:
--

 Summary: Thread pool clean up code can lead to infinite loops in 
ThreadLocal.get
 Key: SLING-7432
 URL: https://issues.apache.org/jira/browse/SLING-7432
 Project: Sling
  Issue Type: Bug
  Components: Commons
Affects Versions: Commons Threads 3.2.10
Reporter: Robert Munteanu
Assignee: Robert Munteanu
 Fix For: Commons Threads 3.2.14


The thread local clean up code added in SLING-6261 leads to Threads stuck in 
{{ThreadLocal.get}}.

I am working on a simplified test case, but the stack trace is similar to

{noformat}
"pool-1-thread-1" prio=10 tid=0x7f47f4374800 nid=0xb19 runnable 
[0x7f47e734e000]
   java.lang.Thread.State: RUNNABLE
at java.lang.ThreadLocal$ThreadLocalMap.set(ThreadLocal.java:429)
at java.lang.ThreadLocal$ThreadLocalMap.access$100(ThreadLocal.java:261)
at java.lang.ThreadLocal.set(ThreadLocal.java:183)
at 
org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocalsTest$RunnableImplementation.run(ThreadPoolExecutorCleaningThreadLocalsTest.java:100)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Git force push

[Bertrand Delacretaz]

On Tue, Jan 23, 2018 at 2:33 PM, Stefan Seifert  wrote:
> i would also vote for *not* allowing push --force..

+1, my understanding is that one can destroy history with that...which
we don't want.

I have never used --force-with-lease so far but according to [1] it
only allows you to force-push if no-one else has pushed changes up to
the remote in the interim.

If that's correct (does anyone have experience with it?) I'd be in
favor of allowing --force-with-lease but not --force. With our many
repositories we often have a single committer working on a given
repository for some time, in which case --force-with-lease could help,
apparently.

-Bertrand

[1] https://developer.atlassian.com/blog/2015/04/force-with-lease/

RE: Git force push

[Stefan Seifert]

i would also vote for *not* allowing push --force

stefan

>-Original Message-
>From: Oliver Lietz [mailto:apa...@oliverlietz.de]
>Sent: Tuesday, January 23, 2018 1:21 PM
>To: dev@sling.apache.org
>Subject: Git force push
>
>Hi,
>
>can we have a simple rule (allow vs deny) for git push --force?
>
>Thanks,
>O.
>

Re: Git force push

[Stefan Egli]

I just stumbled upon a problem where I did a commit with a wrong author
email (in SLING-7407) and "thanks" to force push I was able to correct
this. Not saying it is a good idea to do this often though .. ;)

Cheers,
Stefan

On 23.01.18, 13:26, "Radu Cotescu"  wrote:

>Hi Oliver,
>
>Shouldn't we *never* allow force push?
>
>Cheers,
>Radu
>
>On Tue, 23 Jan 2018 at 14:20 Oliver Lietz  wrote:
>
>> Hi,
>>
>> can we have a simple rule (allow vs deny) for git push --force?
>>
>> Thanks,
>> O.
>>
>>

[jira] [Commented] (SLING-7430) Invalid assumptions in SlingSpecificsSightlyIT#testI18nBasename

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-7430:


Actually both values "die Bank" as well as "das Ufer" are valid for key {{the 
bank}} in case no basename is given. That is what I though I had written above 
;-)

> Invalid assumptions in SlingSpecificsSightlyIT#testI18nBasename
> ---
>
> Key: SLING-7430
> URL: https://issues.apache.org/jira/browse/SLING-7430
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Reporter: Konrad Windszus
>Assignee: Radu Cotescu
>Priority: Major
>
> The test at 
> https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing/blob/905ffd59bebd8d9adaa5d172d169e6eac1469a03/src/test/java/org/apache/sling/scripting/sightly/it/SlingSpecificsSightlyIT.java#L342
>  incorrectly assumes that the key being returned when no basename is set is 
> always the key from the dictionary not having the property {{sling:basename}} 
> is set. This is wrong according to both documentation 
> https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#resourcebundle-with-base-names
>  and implementation in i18n.
> Although the implementation might change in the future (SLING-7429) right now 
> the IT needs to be fixed to also accept value "die Bank" being returned 
> (https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content/blob/91e9397133eea906372aae2ea1f4a1e2e46f4c70/src/main/resources/SLING-INF/apps/sightly/locales/de_finance_basename.json#L13)
>  even when no explicit basename is set.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7426) Use bnd Maven plugins

[Oliver Lietz (JIRA)]

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

Oliver Lietz commented on SLING-7426:
-

bq. We export packages as soon as they have a Version annotation, however the 
bnd maven plugin does not do this by default, but requires to also have the new 
R7 export annotation there (it can be configured to work like we do today)

{{-exportcontents: ${packages;VERSIONED}}} is the instruction in the bnd file 
which configures bnd so it does what Felix's Bundle Plugin did by default 
before ([~npeltier], therefore I had to add a {{package-info.java}} in 
{{org.apache.sling.pipes.models}}).

> Use bnd Maven plugins
> -
>
> Key: SLING-7426
> URL: https://issues.apache.org/jira/browse/SLING-7426
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: pipes 2.0.0
>Reporter: Oliver Lietz
>Assignee: Nicolas Peltier
>Priority: Major
> Fix For: pipes 2.0.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7430) Invalid assumptions in SlingSpecificsSightlyIT#testI18nBasename

[Radu Cotescu (JIRA)]

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

Radu Cotescu commented on SLING-7430:
-

[~kwin], I'm afraid you didn't check the test properly. The value "die Bank" is 
expected to be returned whenever an explicit {{basename}} value is passed to 
the 
{{org.apache.sling.i18n.ResourceBundleProvider#getResourceBundle(java.lang.String,
 java.util.Locale)}} method, since there's a dictionary matching both the base 
name and the locale.

It should probably be the other way around: the value of "das Bank" might have 
to be accepted even when not specifying a {{basename}} value. The question is 
how should this be handled? What's the expected value in the current setup?

> Invalid assumptions in SlingSpecificsSightlyIT#testI18nBasename
> ---
>
> Key: SLING-7430
> URL: https://issues.apache.org/jira/browse/SLING-7430
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Reporter: Konrad Windszus
>Assignee: Radu Cotescu
>Priority: Major
>
> The test at 
> https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing/blob/905ffd59bebd8d9adaa5d172d169e6eac1469a03/src/test/java/org/apache/sling/scripting/sightly/it/SlingSpecificsSightlyIT.java#L342
>  incorrectly assumes that the key being returned when no basename is set is 
> always the key from the dictionary not having the property {{sling:basename}} 
> is set. This is wrong according to both documentation 
> https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#resourcebundle-with-base-names
>  and implementation in i18n.
> Although the implementation might change in the future (SLING-7429) right now 
> the IT needs to be fixed to also accept value "die Bank" being returned 
> (https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content/blob/91e9397133eea906372aae2ea1f4a1e2e46f4c70/src/main/resources/SLING-INF/apps/sightly/locales/de_finance_basename.json#L13)
>  even when no explicit basename is set.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SLING-7431) Allow the HTL IT to run against the latest stable launchpad artifact and against the latest snapshot

[Radu Cotescu (JIRA)]

Radu Cotescu created SLING-7431:
---

 Summary: Allow the HTL IT to run against the latest stable 
launchpad artifact and against the latest snapshot
 Key: SLING-7431
 URL: https://issues.apache.org/jira/browse/SLING-7431
 Project: Sling
  Issue Type: Improvement
  Components: Scripting
Reporter: Radu Cotescu
Assignee: Radu Cotescu
 Fix For: Scripting HTL Testing 1.0.6-1.3.1


In order to be able to release the module that provides the HTL IT, the tests 
should be able to be executed against the most recent release of the Apache 
Sling launchpad / starter application. However, in order to make sure that HTL 
can also run on the latest available launchpad / starter application, the tests 
should also be possible to be executed against a snapshot instance.

For this two profiles should be made available:

* one for the snapshot Sling instance, active by default, that would make sure 
the tests are executed agains the latest snapshot starter application
* one for releasing, conditionally activated, that would disable the execution 
of the default profile and would allow executing the tests against the latest 
released Sling launchpad / starter app



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7421) JcrResourceBundle does not correctly support multiple base names

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-7421:


[~radu.cotescu] IMHO the documentation of Sling i18n with regards to basenames 
is quite clear. But I doubt whether the default behaviour for null and empty 
string are wisely choosen. Therefore I opened 
https://issues.apache.org/jira/browse/SLING-7429 to start the dicussion on how 
to improve it. Feel free to propose a different handling there.
With regards to the wrong assumptions in the IT I opened SLING-7430.

> JcrResourceBundle does not correctly support multiple base names
> 
>
> Key: SLING-7421
> URL: https://issues.apache.org/jira/browse/SLING-7421
> Project: Sling
>  Issue Type: Bug
>  Components: i18n
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Critical
> Fix For: i18n 2.5.12
>
>
> The fix for SLING-4547 is incompete - the {{baseNames}} property is read but 
> not used.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SLING-7430) Invalid assumptions in SlingSpecificsSightlyIT#testI18nBasename

[Konrad Windszus (JIRA)]

Konrad Windszus created SLING-7430:
--

 Summary: Invalid assumptions in 
SlingSpecificsSightlyIT#testI18nBasename
 Key: SLING-7430
 URL: https://issues.apache.org/jira/browse/SLING-7430
 Project: Sling
  Issue Type: Bug
  Components: Scripting
Reporter: Konrad Windszus
Assignee: Radu Cotescu


The test at 
https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing/blob/905ffd59bebd8d9adaa5d172d169e6eac1469a03/src/test/java/org/apache/sling/scripting/sightly/it/SlingSpecificsSightlyIT.java#L342
 incorrectly assumes that the key being returned when no basename is set is 
always the key from the dictionary not having the property {{sling:basename}} 
is set. This is wrong according to both documentation 
https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#resourcebundle-with-base-names
 and implementation in i18n.

Although the implementation might change in the future (SLING-7429) right now 
the IT needs to be fixed to also accept value "die Bank" being returned 
(https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content/blob/91e9397133eea906372aae2ea1f4a1e2e46f4c70/src/main/resources/SLING-INF/apps/sightly/locales/de_finance_basename.json#L13)
 even when no explicit basename is set.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7426) Use bnd Maven plugins

[Nicolas Peltier (JIRA)]

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

Nicolas Peltier commented on SLING-7426:


thanks [~cziegeler] (cc [~olli]) will run additional checks 

> Use bnd Maven plugins
> -
>
> Key: SLING-7426
> URL: https://issues.apache.org/jira/browse/SLING-7426
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: pipes 2.0.0
>Reporter: Oliver Lietz
>Assignee: Nicolas Peltier
>Priority: Major
> Fix For: pipes 2.0.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SLING-7429) Improve basename handling

[Konrad Windszus (JIRA)]

Konrad Windszus created SLING-7429:
--

 Summary: Improve basename handling
 Key: SLING-7429
 URL: https://issues.apache.org/jira/browse/SLING-7429
 Project: Sling
  Issue Type: Improvement
  Components: i18n
Affects Versions: i18n 2.5.12
Reporter: Konrad Windszus


Right now the basename handling according to 
https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#resourcebundle-with-base-names
 is as follows

{quote}
The base name argument can take one three values:
# {{null}}, selects messages of mix:language nodes ignoring the existence or 
absence of sling:basename properties
# Empty String, selects messages of mix:language nodes which have 
sling:basename properties, ignoring the actual values
# Any other Value, selects messages of mix:language nodes whose sling:basename 
properties has any value which matches the base name string
{quote}

I think it should somehow be also possible for a client to explicitly select a 
resource bundle which is not having the {{sling:basename}} property set.

This was originally triggered from 
https://issues.apache.org/jira/browse/SLING-7421?focusedCommentId=16335686=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16335686.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (SLING-7421) JcrResourceBundle does not correctly support multiple base names

[Konrad Windszus (JIRA)]

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

Konrad Windszus edited comment on SLING-7421 at 1/23/18 12:41 PM:
--

Yes exactly. But even after having this one fixed Sightly is making wrong 
assumptions on what key is returned in its IT (and other consumers might as 
well). I think the semantics in 
https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#resourcebundle-with-base-names
 are kind of unexpected and we should discuss whether we should change those.


was (Author: kwin):
Yes exactly. But even after having this one fixed Sightly is making wrong 
assumptions on what key is returned in its IT (and other consumers might as 
well). I think the semantics in 
https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#resourcebundle-with-base-names
 are not right and we should discuss whether it would be good to change those.

> JcrResourceBundle does not correctly support multiple base names
> 
>
> Key: SLING-7421
> URL: https://issues.apache.org/jira/browse/SLING-7421
> Project: Sling
>  Issue Type: Bug
>  Components: i18n
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Critical
> Fix For: i18n 2.5.12
>
>
> The fix for SLING-4547 is incompete - the {{baseNames}} property is read but 
> not used.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7421) JcrResourceBundle does not correctly support multiple base names

[Radu Cotescu (JIRA)]

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

Radu Cotescu commented on SLING-7421:
-

It could very well be that the Sightly IT is making wrong assumptions, but I 
also have the impression that the documentation from Sling's I18n is not really 
clear regarding the value of the {{basename}} parameter. What's the solution?

> JcrResourceBundle does not correctly support multiple base names
> 
>
> Key: SLING-7421
> URL: https://issues.apache.org/jira/browse/SLING-7421
> Project: Sling
>  Issue Type: Bug
>  Components: i18n
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Critical
> Fix For: i18n 2.5.12
>
>
> The fix for SLING-4547 is incompete - the {{baseNames}} property is read but 
> not used.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7426) Use bnd Maven plugins

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-7426:
-

I think it makes sense to slowly move to the maven plugin directly maintained 
by the bnd community. I think we could wait for the R7 release, as this makes 
handling of exported packages more compliant to what we do today. We export 
packages as soon as they have a Version annotation, however the bnd maven 
plugin does not do this by default, but requires to also have the new R7 export 
annotation there (it can be configured to work like we do today)

There are subtle difference between the default behaviour of the two maven 
plugins, so whenever a project switches you have to carefully verify that 
everything is like before.

> Use bnd Maven plugins
> -
>
> Key: SLING-7426
> URL: https://issues.apache.org/jira/browse/SLING-7426
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: pipes 2.0.0
>Reporter: Oliver Lietz
>Assignee: Nicolas Peltier
>Priority: Major
> Fix For: pipes 2.0.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SLING-7428) StartupFilter not reliably stopped (and still returning 503) when executing org.apache.sling.scripting.sightly.testing

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-7428:
---
Summary: StartupFilter not reliably stopped (and still returning 503) when 
executing org.apache.sling.scripting.sightly.testing  (was: StartupFilter nor 
reliably stopped (and still returning 503) when executing 
org.apache.sling.scripting.sightly.testing)

> StartupFilter not reliably stopped (and still returning 503) when executing 
> org.apache.sling.scripting.sightly.testing
> --
>
> Key: SLING-7428
> URL: https://issues.apache.org/jira/browse/SLING-7428
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Reporter: Konrad Windszus
>Assignee: Radu Cotescu
>Priority: Major
>
> For me the IT 
> https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content
>  fails every second time stating that client received status code 503. This 
> is due to the fact that the condition in 
> https://github.com/apache/sling-org-apache-sling-starter-startup/blob/dbe9746f945312a05f99648357ed4c88b01d325a/src/main/java/org/apache/sling/starter/startup/impl/Activator.java#L107
>  to stop the StartupFilter (which returns the 503) is never fulfilled.
> There is always the untransformed resource at 
> {{/apps/sightly/install/README}} 
> (https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content/blob/master/src/main/resources/SLING-INF/apps/sightly/install/README).
>  We should either remove this resource from the install folder (so that this 
> is no longer being picked up by the JCR installer) or we should no longer 
> check for untransformed resources (not sure about the implications).
> I am not sure why I am not running into this every time I execute the IT but 
> only about half of the time. Seems to be related to some unfortunate timings.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7428) StartupFilter nor reliably stopped (and still returning 503) when executing org.apache.sling.scripting.sightly.testing

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-7428:
-

I think waiting for untransformed resources makes sense, at least in our setup. 
It means that the installer has resources that can't be processed. Clearly, the 
README can't.

I don't want to create special cases like excluding the README from the check 
or something along those lines. So I guess moving that README to somewhere else 
is the better option

> StartupFilter nor reliably stopped (and still returning 503) when executing 
> org.apache.sling.scripting.sightly.testing
> --
>
> Key: SLING-7428
> URL: https://issues.apache.org/jira/browse/SLING-7428
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Reporter: Konrad Windszus
>Assignee: Radu Cotescu
>Priority: Major
>
> For me the IT 
> https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content
>  fails every second time stating that client received status code 503. This 
> is due to the fact that the condition in 
> https://github.com/apache/sling-org-apache-sling-starter-startup/blob/dbe9746f945312a05f99648357ed4c88b01d325a/src/main/java/org/apache/sling/starter/startup/impl/Activator.java#L107
>  to stop the StartupFilter (which returns the 503) is never fulfilled.
> There is always the untransformed resource at 
> {{/apps/sightly/install/README}} 
> (https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content/blob/master/src/main/resources/SLING-INF/apps/sightly/install/README).
>  We should either remove this resource from the install folder (so that this 
> is no longer being picked up by the JCR installer) or we should no longer 
> check for untransformed resources (not sure about the implications).
> I am not sure why I am not running into this every time I execute the IT but 
> only about half of the time. Seems to be related to some unfortunate timings.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

New i18n release and basename handling (was: [VOTE] Release Apache Sling Starter 10 + associated testing projects and archetypes (take 2))

[Robert Munteanu]

Hi Konrad,

On Tue, 2018-01-23 at 13:13 +0100, Konrad Windszus wrote:
> But before spinning a new release I would like to get some more
> opinions on the basename handling of the i18n bundle in general
> (compare with https://issues.apache.org/jira/browse/SLING-7421?focuse
> dCommentId=16335677=com.atlassian.jira.plugin.system.issuetabpan
> els:comment-tabpanel#comment-16335677677  ira/browse/SLING-
> 7421?focusedCommentId=16335677=com.atlassian.jira.plugin.system.
> issuetabpanels:comment-tabpanel#comment-16335677>). I think most of
> the users might assume something else when it comes to requesting a
> dictionary without a basename. Right now it is not possible to
> explicitly request a value from a dictionary which is not having the
> basename property set.

Without knowing too much about the i18n bundle, I woudl separate fixing
the regression from properly defining the future behaviour. 

I would like to get Sling 10 out the door with the same behaviour as
Sling 9, rather than wait even more to get better basename handling.
After all, no one complained so far :-)

Thanks,

Robert

Re: Git force push

[Radu Cotescu]

Hi Oliver,

Shouldn't we *never* allow force push?

Cheers,
Radu

On Tue, 23 Jan 2018 at 14:20 Oliver Lietz  wrote:

> Hi,
>
> can we have a simple rule (allow vs deny) for git push --force?
>
> Thanks,
> O.
>
>

[CANCELLED] [VOTE] Release Apache Sling Starter 10 + associated testing projects and archetypes (take 2)

[Robert Munteanu]

This release is cancelled since it is affected by SLING-7421 [1].

Thanks to Radu for catching this regression and for Konrad for
assessing the impact of the release.

The plan is to drop the starter 10 release artifact and respin once we
have a new i18n release (maybe include them in the same release vote
for speed.

Thanks,

Robert

[1]: https://issues.apache.org/jira/browse/SLING-7421

On Fri, 2018-01-19 at 19:24 +0200, Robert Munteanu wrote:
> Hi,
> 
> Update note: I've chosen to respin the Starter release with the same
> version, for 2 reasons:
> 
> - it would generate confusion to skip a release
> - chances of anyone depending on the staged slingstart are slim
> 
> If anyone thinks otherwise, I'll restart the release vote as Sling
> 11.
> 
> 
> Time to release Sling 10. This year I've added all the testing
> projects, to retain what was working at the time of the release and
> the
> archetypes, to allow users to start using the new features
> immediately
> rather than releasing them separately.
> 
> This has lead to a rather large release though.
> 
> The following artifacts, with the associated changelogs, are included
> in this release
> 
> - Apache Sling Starter 10
> https://issues.apache.org/jira/projects/SLING/versions/12340941 (13
> issues)
> 
> - Apache Sling Launchpad Testing 10
> https://issues.apache.org/jira/projects/SLING/versions/12317575 (33
> issues)
> 
> - Apache Sling Launchpad Testing WAR 10
> https://issues.apache.org/jira/projects/SLING/versions/12342164 (0
> issues)
> 
> - Apache Sling Launchpad Integration Tests 1.0.6
> https://issues.apache.org/jira/projects/SLING/versions/12341715 (0
> issues)
> 
> - Apache Sling Launchpad Test Bundles 0.0.4 (no changelog)
> - Apache Sling Launchpad Testing Fragment Bundle 2.0.14 (no
> changelog)
> 
> - Apache Sling Launchpad Testing Services 2.0.14
> https://issues.apache.org/jira/projects/SLING/versions/12338823 (2
> issues)
> 
> - Apache Sling Launchpad Testing Services WAR 2.0.14 (no changelog)
> 
> - Apache Sling Archetype Parent 5
> https://issues.apache.org/jira/projects/SLING/versions/12333898 (2
> issues)
> 
> - Apache Sling Bundle Archetype 1.0.6
> https://issues.apache.org/jira/browse/SLING/fixforversion/12333900 (2
> issues)
> 
> - Apache Sling JCRInstall Bundle Archetype 1.0.6
> https://issues.apache.org/jira/browse/SLING/fixforversion/12333901 (2
> issues)
> 
> - Apache Sling Initial Content Archetype 1.0.6
> https://issues.apache.org/jira/browse/SLING/fixforversion/12333902 (2
> issues)
> 
> - Apache Sling Slingstart Archetype 1.0.6
> https://issues.apache.org/jira/browse/SLING/fixforversion/12340954 (2
> issues)
> 
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachesling-185
> 7
> https://repository.apache.org/content/repositories/orgapachesling-185
> 8
> 
> You can use this UNIX script to download the release and verify the
> signatures:
> https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blo
> b;f=check_staged_release.sh;hb=HEAD
> 
> Usage:
> sh check_staged_release.sh 1857 /tmp/sling-stagingsh
> check_staged_release.sh 1858 /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, but I'd be more
> than
> happy to allow extensions if anyone needs more time to validate the
> release.
> 
> Thanks,
> 
> Robert
> 

Git force push

[Oliver Lietz]

Hi,

can we have a simple rule (allow vs deny) for git push --force?

Thanks,
O.

[jira] [Commented] (SLING-7421) JcrResourceBundle does not correctly support multiple base names

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-7421:


Yes exactly. But even after having this one fixed Sightly is making wrong 
assumptions on what key is returned in its IT (and other consumers might as 
well). I think the semantics in 
https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#resourcebundle-with-base-names
 are not right and we should discuss whether it would be good to change those.

> JcrResourceBundle does not correctly support multiple base names
> 
>
> Key: SLING-7421
> URL: https://issues.apache.org/jira/browse/SLING-7421
> Project: Sling
>  Issue Type: Bug
>  Components: i18n
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Critical
> Fix For: i18n 2.5.12
>
>
> The fix for SLING-4547 is incompete - the {{baseNames}} property is read but 
> not used.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7421) JcrResourceBundle does not correctly support multiple base names

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-7421:


[~kwin] - that's what we risk by releasing Sling 10 as-is, right? If that is 
the case I will cancel the Sling 10 release vote again and re-spin once we have 
a release of the i18n bundle with this fix.

> JcrResourceBundle does not correctly support multiple base names
> 
>
> Key: SLING-7421
> URL: https://issues.apache.org/jira/browse/SLING-7421
> Project: Sling
>  Issue Type: Bug
>  Components: i18n
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Critical
> Fix For: i18n 2.5.12
>
>
> The fix for SLING-4547 is incompete - the {{baseNames}} property is read but 
> not used.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Release Apache Sling Starter 10 + associated testing projects and archetypes (take 2)

[Konrad Windszus]

After having evaluated the impact of 
https://issues.apache.org/jira/browse/SLING-7421 
 more closely I am also 
voting -1 for this release.

But before spinning a new release I would like to get some more opinions on the 
basename handling of the i18n bundle in general (compare with 
https://issues.apache.org/jira/browse/SLING-7421?focusedCommentId=16335677=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16335677
 
).
 I think most of the users might assume something else when it comes to 
requesting a dictionary without a basename. Right now it is not possible to 
explicitly request a value from a dictionary which is not having the basename 
property set. 

Konrad

> On 23. Jan 2018, at 12:58, Robert Munteanu  wrote:
> 
> On Tue, 2018-01-23 at 11:49 +0100, Karl Pauls wrote:
>> Sounds like it isn't necessarily a showstopper - I guess Robert has
>> to
>> make the call if he wants to cancel the release or have it pass.
>> 
>> FWIW, I would have liked to have the latest servlets.post 2.3.24
>> release included as well so if we respin the release we might include
>> it as well :-).
> 
> Third time would be the lucky one :-) I have no idea about the i18n
> bundle, but ideally Konrad and Radu would help us narrow down the exact
> problem so we can make an informed decision.
> 
> I am not opposed to re-releasing the starter module only, but, like
> Karl, am not sure of the scope of the issue.
> 
> Robert
> 
>> 
>> regards,
>> 
>> Karl
>> 
>> On Tue, Jan 23, 2018 at 11:37 AM, Radu Cotescu 
>> wrote:
>>> Hi Karl,
>>> 
>>> A project deployed on the Sling 10 Starter that would use i18n with
>>> a
>>> resource bundle provider that should take into account the basename
>>> requested by the client might fail to get the correct translation.
>>> 
>>> Cheers,
>>> Radu
>>> 
>>> On Tue, 23 Jan 2018 at 12:17 Karl Pauls 
>>> wrote:
>>> 
 Hi Radu,
 
 what is the impact of this bug (mostly want to find out if it
 breaks
 us in a major way or if it is just a special case)?
 
 regards,
 
 Karl
 
 On Tue, Jan 23, 2018 at 11:01 AM, Radu Cotescu 
 wrote:
> -1. See
> 
 
 https://issues.apache.org/jira/browse/SLING-6952?focusedCommentId
 =16335586=com.atlassian.jira.plugin.system.issuetabpanels:co
 mment-tabpanel#comment-16335586
> .
> 
> Sorry for this... :(
> 
> Radu
> 
> On Mon, 22 Jan 2018 at 23:16 Karl Pauls 
> wrote:
> 
>> +1
>> 
>> regards,
>> 
>> Karl
>> 
>> On Fri, Jan 19, 2018 at 6:24 PM, Robert Munteanu > che.org>
>> wrote:
>>> Hi,
>>> 
>>> Update note: I've chosen to respin the Starter release with
>>> the same
>>> version, for 2 reasons:
>>> 
>>> - it would generate confusion to skip a release
>>> - chances of anyone depending on the staged slingstart are
>>> slim
>>> 
>>> If anyone thinks otherwise, I'll restart the release vote
>>> as Sling 11.
>>> 
>>> 
>>> Time to release Sling 10. This year I've added all the
>>> testing
>>> projects, to retain what was working at the time of the
>>> release and
 
 the
>>> archetypes, to allow users to start using the new features
>>> immediately
>>> rather than releasing them separately.
>>> 
>>> This has lead to a rather large release though.
>>> 
>>> The following artifacts, with the associated changelogs,
>>> are included
>>> in this release
>>> 
>>> - Apache Sling Starter 10
>>> https://issues.apache.org/jira/projects/SLING/versions/1234
>>> 0941 (13
>> 
>> issues)
>>> 
>>> - Apache Sling Launchpad Testing 10
>>> https://issues.apache.org/jira/projects/SLING/versions/1231
>>> 7575 (33
>> 
>> issues)
>>> 
>>> - Apache Sling Launchpad Testing WAR 10
>>> https://issues.apache.org/jira/projects/SLING/versions/1234
>>> 2164 (0
>> 
>> issues)
>>> 
>>> - Apache Sling Launchpad Integration Tests 1.0.6
>>> https://issues.apache.org/jira/projects/SLING/versions/1234
>>> 1715 (0
>> 
>> issues)
>>> 
>>> - Apache Sling Launchpad Test Bundles 0.0.4 (no changelog)
>>> - Apache Sling Launchpad Testing Fragment Bundle 2.0.14 (no
>>> changelog)
>>> 
>>> - Apache Sling Launchpad Testing Services 2.0.14
>>> https://issues.apache.org/jira/projects/SLING/versions/1233
>>> 8823 (2
>> 
>> issues)
>>> 
>>> - Apache Sling Launchpad Testing Services WAR 2.0.14 (no
>>> changelog)
>>> 
>>> - Apache Sling Archetype Parent 5
>>> 

[jira] [Updated] (SLING-7421) JcrResourceBundle does not correctly support multiple base names

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-7421:
---
Priority: Critical  (was: Major)

> JcrResourceBundle does not correctly support multiple base names
> 
>
> Key: SLING-7421
> URL: https://issues.apache.org/jira/browse/SLING-7421
> Project: Sling
>  Issue Type: Bug
>  Components: i18n
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Critical
> Fix For: i18n 2.5.12
>
>
> The fix for SLING-4547 is incompete - the {{baseNames}} property is read but 
> not used.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7421) JcrResourceBundle does not correctly support multiple base names

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-7421:


To clarify the impact of this bug: Whenever a resource bundle with a certain 
basename is requested the key of any dictionary might be returned (even of 
another one without the basename). This is clearly violating the specs of 
https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#resourcebundle-with-base-names
 and IMHO is quite critical.

> JcrResourceBundle does not correctly support multiple base names
> 
>
> Key: SLING-7421
> URL: https://issues.apache.org/jira/browse/SLING-7421
> Project: Sling
>  Issue Type: Bug
>  Components: i18n
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: i18n 2.5.12
>
>
> The fix for SLING-4547 is incompete - the {{baseNames}} property is read but 
> not used.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (SLING-7421) JcrResourceBundle does not correctly support multiple base names

[Konrad Windszus (JIRA)]

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

Konrad Windszus edited comment on SLING-7421 at 1/23/18 12:06 PM:
--

I think the base name handling should be rethought a bit.
Currently it is not possible to explicitly select a dictionary not having a 
base name (compare with 
https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#resourcebundle-with-base-names).
 But the IT in 
https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing/blob/master/src/test/java/org/apache/sling/scripting/sightly/it/SlingSpecificsSightlyIT.java#L341
 is relying on that. It expects that with a given basename of {{null}} the i18n 
bundle always returns the value of the dictionary in 
https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content/blob/91e9397133eea906372aae2ea1f4a1e2e46f4c70/src/main/resources/SLING-INF/apps/sightly/locales/de.json#L25
 (i.e. the one from the dictionary without the basename). But theoretically the 
i18n bundle might also return the value from the dictionary with another 
basename according to the semantics defined in 
https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#resourcebundle-with-base-names.

I will try to come up with an IT covering the actual fault here but I still 
think that the Sightly IT needs to be revised or we need to rethink the 
basename handling more globally. [~radu.cotescu] Please give your input.


was (Author: kwin):
I think the base name handling should be rethought a bit.
Currently it is not possible to explicitly select a dictionary not having a 
base name (compare with 
https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#resourcebundle-with-base-names).
 But the IT in 
https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing/blob/master/src/test/java/org/apache/sling/scripting/sightly/it/SlingSpecificsSightlyIT.java#L341
 is relying on that. It expects a basename of {{null}} to always return the 
value of the dictionary in 
https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content/blob/91e9397133eea906372aae2ea1f4a1e2e46f4c70/src/main/resources/SLING-INF/apps/sightly/locales/de.json#L25
 (i.e. the one from the dictionary without the basename). But theoretically the 
i18n bundle might also return the value from the dictionary with the basename 
according to the semantics defined in 
https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#resourcebundle-with-base-names.

I will try to come up with an IT covering the actual fault here but I still 
think that the Sightly IT needs to be revised or we need to rethink the 
basename handling more globally. [~radu.cotescu] Please give your input.

> JcrResourceBundle does not correctly support multiple base names
> 
>
> Key: SLING-7421
> URL: https://issues.apache.org/jira/browse/SLING-7421
> Project: Sling
>  Issue Type: Bug
>  Components: i18n
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: i18n 2.5.12
>
>
> The fix for SLING-4547 is incompete - the {{baseNames}} property is read but 
> not used.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7421) JcrResourceBundle does not correctly support multiple base names

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-7421:


I think the base name handling should be rethought a bit.
Currently it is not possible to explicitly select a dictionary not having a 
base name (compare with 
https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#resourcebundle-with-base-names).
 But the IT in 
https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing/blob/master/src/test/java/org/apache/sling/scripting/sightly/it/SlingSpecificsSightlyIT.java#L341
 is relying on that. It expects a basename of {{null}} to always return the 
value of the dictionary in 
https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content/blob/91e9397133eea906372aae2ea1f4a1e2e46f4c70/src/main/resources/SLING-INF/apps/sightly/locales/de.json#L25
 (i.e. the one from the dictionary without the basename). But theoretically the 
i18n bundle might also return the value from the dictionary with the basename 
according to the semantics defined in 
https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#resourcebundle-with-base-names.

I will try to come up with an IT covering the actual fault here but I still 
think that the Sightly IT needs to be revised or we need to rethink the 
basename handling more globally. [~radu.cotescu] Please give your input.

> JcrResourceBundle does not correctly support multiple base names
> 
>
> Key: SLING-7421
> URL: https://issues.apache.org/jira/browse/SLING-7421
> Project: Sling
>  Issue Type: Bug
>  Components: i18n
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: i18n 2.5.12
>
>
> The fix for SLING-4547 is incompete - the {{baseNames}} property is read but 
> not used.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Release Apache Sling Starter 10 + associated testing projects and archetypes (take 2)

[Robert Munteanu]

On Tue, 2018-01-23 at 11:49 +0100, Karl Pauls wrote:
> Sounds like it isn't necessarily a showstopper - I guess Robert has
> to
> make the call if he wants to cancel the release or have it pass.
> 
> FWIW, I would have liked to have the latest servlets.post 2.3.24
> release included as well so if we respin the release we might include
> it as well :-).

Third time would be the lucky one :-) I have no idea about the i18n
bundle, but ideally Konrad and Radu would help us narrow down the exact
problem so we can make an informed decision.

I am not opposed to re-releasing the starter module only, but, like
Karl, am not sure of the scope of the issue.

Robert

> 
> regards,
> 
> Karl
> 
> On Tue, Jan 23, 2018 at 11:37 AM, Radu Cotescu 
> wrote:
> > Hi Karl,
> > 
> > A project deployed on the Sling 10 Starter that would use i18n with
> > a
> > resource bundle provider that should take into account the basename
> > requested by the client might fail to get the correct translation.
> > 
> > Cheers,
> > Radu
> > 
> > On Tue, 23 Jan 2018 at 12:17 Karl Pauls 
> > wrote:
> > 
> > > Hi Radu,
> > > 
> > > what is the impact of this bug (mostly want to find out if it
> > > breaks
> > > us in a major way or if it is just a special case)?
> > > 
> > > regards,
> > > 
> > > Karl
> > > 
> > > On Tue, Jan 23, 2018 at 11:01 AM, Radu Cotescu 
> > > wrote:
> > > > -1. See
> > > > 
> > > 
> > > https://issues.apache.org/jira/browse/SLING-6952?focusedCommentId
> > > =16335586=com.atlassian.jira.plugin.system.issuetabpanels:co
> > > mment-tabpanel#comment-16335586
> > > > .
> > > > 
> > > > Sorry for this... :(
> > > > 
> > > > Radu
> > > > 
> > > > On Mon, 22 Jan 2018 at 23:16 Karl Pauls 
> > > > wrote:
> > > > 
> > > > > +1
> > > > > 
> > > > > regards,
> > > > > 
> > > > > Karl
> > > > > 
> > > > > On Fri, Jan 19, 2018 at 6:24 PM, Robert Munteanu  > > > > che.org>
> > > > > wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > Update note: I've chosen to respin the Starter release with
> > > > > > the same
> > > > > > version, for 2 reasons:
> > > > > > 
> > > > > > - it would generate confusion to skip a release
> > > > > > - chances of anyone depending on the staged slingstart are
> > > > > > slim
> > > > > > 
> > > > > > If anyone thinks otherwise, I'll restart the release vote
> > > > > > as Sling 11.
> > > > > > 
> > > > > > 
> > > > > > Time to release Sling 10. This year I've added all the
> > > > > > testing
> > > > > > projects, to retain what was working at the time of the
> > > > > > release and
> > > 
> > > the
> > > > > > archetypes, to allow users to start using the new features
> > > > > > immediately
> > > > > > rather than releasing them separately.
> > > > > > 
> > > > > > This has lead to a rather large release though.
> > > > > > 
> > > > > > The following artifacts, with the associated changelogs,
> > > > > > are included
> > > > > > in this release
> > > > > > 
> > > > > > - Apache Sling Starter 10
> > > > > > https://issues.apache.org/jira/projects/SLING/versions/1234
> > > > > > 0941 (13
> > > > > 
> > > > > issues)
> > > > > > 
> > > > > > - Apache Sling Launchpad Testing 10
> > > > > > https://issues.apache.org/jira/projects/SLING/versions/1231
> > > > > > 7575 (33
> > > > > 
> > > > > issues)
> > > > > > 
> > > > > > - Apache Sling Launchpad Testing WAR 10
> > > > > > https://issues.apache.org/jira/projects/SLING/versions/1234
> > > > > > 2164 (0
> > > > > 
> > > > > issues)
> > > > > > 
> > > > > > - Apache Sling Launchpad Integration Tests 1.0.6
> > > > > > https://issues.apache.org/jira/projects/SLING/versions/1234
> > > > > > 1715 (0
> > > > > 
> > > > > issues)
> > > > > > 
> > > > > > - Apache Sling Launchpad Test Bundles 0.0.4 (no changelog)
> > > > > > - Apache Sling Launchpad Testing Fragment Bundle 2.0.14 (no
> > > > > > changelog)
> > > > > > 
> > > > > > - Apache Sling Launchpad Testing Services 2.0.14
> > > > > > https://issues.apache.org/jira/projects/SLING/versions/1233
> > > > > > 8823 (2
> > > > > 
> > > > > issues)
> > > > > > 
> > > > > > - Apache Sling Launchpad Testing Services WAR 2.0.14 (no
> > > > > > changelog)
> > > > > > 
> > > > > > - Apache Sling Archetype Parent 5
> > > > > > https://issues.apache.org/jira/projects/SLING/versions/1233
> > > > > > 3898 (2
> > > > > 
> > > > > issues)
> > > > > > 
> > > > > > - Apache Sling Bundle Archetype 1.0.6
> > > > > > https://issues.apache.org/jira/browse/SLING/fixforversion/1
> > > > > > 2333900 (2
> > > > > 
> > > > > issues)
> > > > > > 
> > > > > > - Apache Sling JCRInstall Bundle Archetype 1.0.6
> > > > > > https://issues.apache.org/jira/browse/SLING/fixforversion/1
> > > > > > 2333901 (2
> > > > > 
> > > > > issues)
> > > > > > 
> > > > > > - Apache Sling Initial Content Archetype 1.0.6
> > > > > > https://issues.apache.org/jira/browse/SLING/fixforversion/1
> > > > > > 2333902 (2
> > > > > 
> > > > > issues)
> > > > > > 
> > > > > > - Apache 

[jira] [Created] (SLING-7428) StartupFilter nor reliably stopped (and still returning 503) when executing org.apache.sling.scripting.sightly.testing

[Konrad Windszus (JIRA)]

Konrad Windszus created SLING-7428:
--

 Summary: StartupFilter nor reliably stopped (and still returning 
503) when executing org.apache.sling.scripting.sightly.testing
 Key: SLING-7428
 URL: https://issues.apache.org/jira/browse/SLING-7428
 Project: Sling
  Issue Type: Bug
  Components: Scripting
Reporter: Konrad Windszus
Assignee: Radu Cotescu


For me the IT 
https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content
 fails every second time stating that client received status code 503. This is 
due to the fact that the condition in 
https://github.com/apache/sling-org-apache-sling-starter-startup/blob/dbe9746f945312a05f99648357ed4c88b01d325a/src/main/java/org/apache/sling/starter/startup/impl/Activator.java#L107
 to stop the StartupFilter (which returns the 503) is never fulfilled.
There is always the untransformed resource at {{/apps/sightly/install/README}} 
(https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content/blob/master/src/main/resources/SLING-INF/apps/sightly/install/README).
 We should either remove this resource from the install folder (so that this is 
no longer being picked up by the JCR installer) or we should no longer check 
for untransformed resources (not sure about the implications).

I am not sure why I am not running into this every time I execute the IT but 
only about half of the time. Seems to be related to some unfortunate timings.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7073) Update bundle versions

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-7073:


After looking at the Sightly IT more closely I am pretty sure we are not 
looking at an occurrence of SLING-7421. Basically SLING-7421 was to support 
more than one basename for the same dictionary. If I look at 
https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content/blob/master/src/main/resources/SLING-INF/apps/sightly/locales/de.json
 and 
https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content/blob/master/src/main/resources/SLING-INF/apps/sightly/locales/de_finance_basename.json
 both don't set multiple base names. Maybe we are running into another bug 
here? For sure we should add an according IT in the i18n bundle, but I am 
really unsure what goes wrong here and under what circumstances we see wrong 
values being returned. So right now it is impossible for me to correctly judge 
the impact...

> Update bundle versions
> --
>
> Key: SLING-7073
> URL: https://issues.apache.org/jira/browse/SLING-7073
> Project: Sling
>  Issue Type: Sub-task
>  Components: Launchpad
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Starter 10
>
>
> Before the launchpad release, include the latest versions of external bundles 
> and also check that our own bundles are at the latest versions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Release Apache Sling Starter 10 + associated testing projects and archetypes (take 2)

[Karl Pauls]

Sounds like it isn't necessarily a showstopper - I guess Robert has to
make the call if he wants to cancel the release or have it pass.

FWIW, I would have liked to have the latest servlets.post 2.3.24
release included as well so if we respin the release we might include
it as well :-).

regards,

Karl

On Tue, Jan 23, 2018 at 11:37 AM, Radu Cotescu  wrote:
> Hi Karl,
>
> A project deployed on the Sling 10 Starter that would use i18n with a
> resource bundle provider that should take into account the basename
> requested by the client might fail to get the correct translation.
>
> Cheers,
> Radu
>
> On Tue, 23 Jan 2018 at 12:17 Karl Pauls  wrote:
>
>> Hi Radu,
>>
>> what is the impact of this bug (mostly want to find out if it breaks
>> us in a major way or if it is just a special case)?
>>
>> regards,
>>
>> Karl
>>
>> On Tue, Jan 23, 2018 at 11:01 AM, Radu Cotescu  wrote:
>> > -1. See
>> >
>> https://issues.apache.org/jira/browse/SLING-6952?focusedCommentId=16335586=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16335586
>> > .
>> >
>> > Sorry for this... :(
>> >
>> > Radu
>> >
>> > On Mon, 22 Jan 2018 at 23:16 Karl Pauls  wrote:
>> >
>> >> +1
>> >>
>> >> regards,
>> >>
>> >> Karl
>> >>
>> >> On Fri, Jan 19, 2018 at 6:24 PM, Robert Munteanu 
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > Update note: I've chosen to respin the Starter release with the same
>> >> > version, for 2 reasons:
>> >> >
>> >> > - it would generate confusion to skip a release
>> >> > - chances of anyone depending on the staged slingstart are slim
>> >> >
>> >> > If anyone thinks otherwise, I'll restart the release vote as Sling 11.
>> >> > 
>> >> >
>> >> > Time to release Sling 10. This year I've added all the testing
>> >> > projects, to retain what was working at the time of the release and
>> the
>> >> > archetypes, to allow users to start using the new features immediately
>> >> > rather than releasing them separately.
>> >> >
>> >> > This has lead to a rather large release though.
>> >> >
>> >> > The following artifacts, with the associated changelogs, are included
>> >> > in this release
>> >> >
>> >> > - Apache Sling Starter 10
>> >> > https://issues.apache.org/jira/projects/SLING/versions/12340941 (13
>> >> issues)
>> >> >
>> >> > - Apache Sling Launchpad Testing 10
>> >> > https://issues.apache.org/jira/projects/SLING/versions/12317575 (33
>> >> issues)
>> >> >
>> >> > - Apache Sling Launchpad Testing WAR 10
>> >> > https://issues.apache.org/jira/projects/SLING/versions/12342164 (0
>> >> issues)
>> >> >
>> >> > - Apache Sling Launchpad Integration Tests 1.0.6
>> >> > https://issues.apache.org/jira/projects/SLING/versions/12341715 (0
>> >> issues)
>> >> >
>> >> > - Apache Sling Launchpad Test Bundles 0.0.4 (no changelog)
>> >> > - Apache Sling Launchpad Testing Fragment Bundle 2.0.14 (no changelog)
>> >> >
>> >> > - Apache Sling Launchpad Testing Services 2.0.14
>> >> > https://issues.apache.org/jira/projects/SLING/versions/12338823 (2
>> >> issues)
>> >> >
>> >> > - Apache Sling Launchpad Testing Services WAR 2.0.14 (no changelog)
>> >> >
>> >> > - Apache Sling Archetype Parent 5
>> >> > https://issues.apache.org/jira/projects/SLING/versions/12333898 (2
>> >> issues)
>> >> >
>> >> > - Apache Sling Bundle Archetype 1.0.6
>> >> > https://issues.apache.org/jira/browse/SLING/fixforversion/12333900 (2
>> >> issues)
>> >> >
>> >> > - Apache Sling JCRInstall Bundle Archetype 1.0.6
>> >> > https://issues.apache.org/jira/browse/SLING/fixforversion/12333901 (2
>> >> issues)
>> >> >
>> >> > - Apache Sling Initial Content Archetype 1.0.6
>> >> > https://issues.apache.org/jira/browse/SLING/fixforversion/12333902 (2
>> >> issues)
>> >> >
>> >> > - Apache Sling Slingstart Archetype 1.0.6
>> >> > https://issues.apache.org/jira/browse/SLING/fixforversion/12340954 (2
>> >> issues)
>> >> >
>> >> > Staging repositories:
>> >> >
>> https://repository.apache.org/content/repositories/orgapachesling-1857
>> >> >
>> https://repository.apache.org/content/repositories/orgapachesling-1858
>> >> >
>> >> > You can use this UNIX script to download the release and verify the
>> >> > signatures:
>> >> >
>> >>
>> https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD
>> >> >
>> >> > Usage:
>> >> > sh check_staged_release.sh 1857 /tmp/sling-stagingsh
>> >> check_staged_release.sh 1858 /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, but I'd be more than
>> >> > happy to allow extensions if anyone needs more time to validate the
>> >> > release.
>> >> >
>> >> > Thanks,
>> >> >
>> >> > Robert
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Karl Pauls
>> >> karlpa...@gmail.com
>> >>
>>
>>
>>
>> --

Re: [VOTE] Release Apache Sling Starter 10 + associated testing projects and archetypes (take 2)

[Radu Cotescu]

Hi Karl,

A project deployed on the Sling 10 Starter that would use i18n with a
resource bundle provider that should take into account the basename
requested by the client might fail to get the correct translation.

Cheers,
Radu

On Tue, 23 Jan 2018 at 12:17 Karl Pauls  wrote:

> Hi Radu,
>
> what is the impact of this bug (mostly want to find out if it breaks
> us in a major way or if it is just a special case)?
>
> regards,
>
> Karl
>
> On Tue, Jan 23, 2018 at 11:01 AM, Radu Cotescu  wrote:
> > -1. See
> >
> https://issues.apache.org/jira/browse/SLING-6952?focusedCommentId=16335586=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16335586
> > .
> >
> > Sorry for this... :(
> >
> > Radu
> >
> > On Mon, 22 Jan 2018 at 23:16 Karl Pauls  wrote:
> >
> >> +1
> >>
> >> regards,
> >>
> >> Karl
> >>
> >> On Fri, Jan 19, 2018 at 6:24 PM, Robert Munteanu 
> >> wrote:
> >> > Hi,
> >> >
> >> > Update note: I've chosen to respin the Starter release with the same
> >> > version, for 2 reasons:
> >> >
> >> > - it would generate confusion to skip a release
> >> > - chances of anyone depending on the staged slingstart are slim
> >> >
> >> > If anyone thinks otherwise, I'll restart the release vote as Sling 11.
> >> > 
> >> >
> >> > Time to release Sling 10. This year I've added all the testing
> >> > projects, to retain what was working at the time of the release and
> the
> >> > archetypes, to allow users to start using the new features immediately
> >> > rather than releasing them separately.
> >> >
> >> > This has lead to a rather large release though.
> >> >
> >> > The following artifacts, with the associated changelogs, are included
> >> > in this release
> >> >
> >> > - Apache Sling Starter 10
> >> > https://issues.apache.org/jira/projects/SLING/versions/12340941 (13
> >> issues)
> >> >
> >> > - Apache Sling Launchpad Testing 10
> >> > https://issues.apache.org/jira/projects/SLING/versions/12317575 (33
> >> issues)
> >> >
> >> > - Apache Sling Launchpad Testing WAR 10
> >> > https://issues.apache.org/jira/projects/SLING/versions/12342164 (0
> >> issues)
> >> >
> >> > - Apache Sling Launchpad Integration Tests 1.0.6
> >> > https://issues.apache.org/jira/projects/SLING/versions/12341715 (0
> >> issues)
> >> >
> >> > - Apache Sling Launchpad Test Bundles 0.0.4 (no changelog)
> >> > - Apache Sling Launchpad Testing Fragment Bundle 2.0.14 (no changelog)
> >> >
> >> > - Apache Sling Launchpad Testing Services 2.0.14
> >> > https://issues.apache.org/jira/projects/SLING/versions/12338823 (2
> >> issues)
> >> >
> >> > - Apache Sling Launchpad Testing Services WAR 2.0.14 (no changelog)
> >> >
> >> > - Apache Sling Archetype Parent 5
> >> > https://issues.apache.org/jira/projects/SLING/versions/12333898 (2
> >> issues)
> >> >
> >> > - Apache Sling Bundle Archetype 1.0.6
> >> > https://issues.apache.org/jira/browse/SLING/fixforversion/12333900 (2
> >> issues)
> >> >
> >> > - Apache Sling JCRInstall Bundle Archetype 1.0.6
> >> > https://issues.apache.org/jira/browse/SLING/fixforversion/12333901 (2
> >> issues)
> >> >
> >> > - Apache Sling Initial Content Archetype 1.0.6
> >> > https://issues.apache.org/jira/browse/SLING/fixforversion/12333902 (2
> >> issues)
> >> >
> >> > - Apache Sling Slingstart Archetype 1.0.6
> >> > https://issues.apache.org/jira/browse/SLING/fixforversion/12340954 (2
> >> issues)
> >> >
> >> > Staging repositories:
> >> >
> https://repository.apache.org/content/repositories/orgapachesling-1857
> >> >
> https://repository.apache.org/content/repositories/orgapachesling-1858
> >> >
> >> > You can use this UNIX script to download the release and verify the
> >> > signatures:
> >> >
> >>
> https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD
> >> >
> >> > Usage:
> >> > sh check_staged_release.sh 1857 /tmp/sling-stagingsh
> >> check_staged_release.sh 1858 /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, but I'd be more than
> >> > happy to allow extensions if anyone needs more time to validate the
> >> > release.
> >> >
> >> > Thanks,
> >> >
> >> > Robert
> >> >
> >>
> >>
> >>
> >> --
> >> Karl Pauls
> >> karlpa...@gmail.com
> >>
>
>
>
> --
> Karl Pauls
> karlpa...@gmail.com
>

Re: [VOTE] Release Apache Sling Starter 10 + associated testing projects and archetypes (take 2)

[Karl Pauls]

Hi Radu,

what is the impact of this bug (mostly want to find out if it breaks
us in a major way or if it is just a special case)?

regards,

Karl

On Tue, Jan 23, 2018 at 11:01 AM, Radu Cotescu  wrote:
> -1. See
> https://issues.apache.org/jira/browse/SLING-6952?focusedCommentId=16335586=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16335586
> .
>
> Sorry for this... :(
>
> Radu
>
> On Mon, 22 Jan 2018 at 23:16 Karl Pauls  wrote:
>
>> +1
>>
>> regards,
>>
>> Karl
>>
>> On Fri, Jan 19, 2018 at 6:24 PM, Robert Munteanu 
>> wrote:
>> > Hi,
>> >
>> > Update note: I've chosen to respin the Starter release with the same
>> > version, for 2 reasons:
>> >
>> > - it would generate confusion to skip a release
>> > - chances of anyone depending on the staged slingstart are slim
>> >
>> > If anyone thinks otherwise, I'll restart the release vote as Sling 11.
>> > 
>> >
>> > Time to release Sling 10. This year I've added all the testing
>> > projects, to retain what was working at the time of the release and the
>> > archetypes, to allow users to start using the new features immediately
>> > rather than releasing them separately.
>> >
>> > This has lead to a rather large release though.
>> >
>> > The following artifacts, with the associated changelogs, are included
>> > in this release
>> >
>> > - Apache Sling Starter 10
>> > https://issues.apache.org/jira/projects/SLING/versions/12340941 (13
>> issues)
>> >
>> > - Apache Sling Launchpad Testing 10
>> > https://issues.apache.org/jira/projects/SLING/versions/12317575 (33
>> issues)
>> >
>> > - Apache Sling Launchpad Testing WAR 10
>> > https://issues.apache.org/jira/projects/SLING/versions/12342164 (0
>> issues)
>> >
>> > - Apache Sling Launchpad Integration Tests 1.0.6
>> > https://issues.apache.org/jira/projects/SLING/versions/12341715 (0
>> issues)
>> >
>> > - Apache Sling Launchpad Test Bundles 0.0.4 (no changelog)
>> > - Apache Sling Launchpad Testing Fragment Bundle 2.0.14 (no changelog)
>> >
>> > - Apache Sling Launchpad Testing Services 2.0.14
>> > https://issues.apache.org/jira/projects/SLING/versions/12338823 (2
>> issues)
>> >
>> > - Apache Sling Launchpad Testing Services WAR 2.0.14 (no changelog)
>> >
>> > - Apache Sling Archetype Parent 5
>> > https://issues.apache.org/jira/projects/SLING/versions/12333898 (2
>> issues)
>> >
>> > - Apache Sling Bundle Archetype 1.0.6
>> > https://issues.apache.org/jira/browse/SLING/fixforversion/12333900 (2
>> issues)
>> >
>> > - Apache Sling JCRInstall Bundle Archetype 1.0.6
>> > https://issues.apache.org/jira/browse/SLING/fixforversion/12333901 (2
>> issues)
>> >
>> > - Apache Sling Initial Content Archetype 1.0.6
>> > https://issues.apache.org/jira/browse/SLING/fixforversion/12333902 (2
>> issues)
>> >
>> > - Apache Sling Slingstart Archetype 1.0.6
>> > https://issues.apache.org/jira/browse/SLING/fixforversion/12340954 (2
>> issues)
>> >
>> > Staging repositories:
>> > https://repository.apache.org/content/repositories/orgapachesling-1857
>> > https://repository.apache.org/content/repositories/orgapachesling-1858
>> >
>> > You can use this UNIX script to download the release and verify the
>> > signatures:
>> >
>> https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD
>> >
>> > Usage:
>> > sh check_staged_release.sh 1857 /tmp/sling-stagingsh
>> check_staged_release.sh 1858 /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, but I'd be more than
>> > happy to allow extensions if anyone needs more time to validate the
>> > release.
>> >
>> > Thanks,
>> >
>> > Robert
>> >
>>
>>
>>
>> --
>> Karl Pauls
>> karlpa...@gmail.com
>>



-- 
Karl Pauls
karlpa...@gmail.com

[jira] [Closed] (SLING-7346) Issues with custom fields in PostResponse as a result of fix for SLING-6681(Replace commons.json usage in org.apache.sling.servlets.post)

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-7346.
-

> Issues with custom fields in PostResponse as a result of fix for 
> SLING-6681(Replace commons.json usage in org.apache.sling.servlets.post)
> -
>
> Key: SLING-7346
> URL: https://issues.apache.org/jira/browse/SLING-7346
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Post 2.3.22
>Reporter: Rahul Bhardwaj
>Assignee: Karl Pauls
>Priority: Major
> Fix For: Servlets Post 2.3.24
>
>
> If you set a value of type as map as a custom property in response type, 
> instead of parsing properly, whole map is converted into one string and 
> therefore, json response does not reach client side in an orderly fashion.
> This can be attributed to [0] which was merged as part of fix for 
> SLING-6681(Replace commons.json usage in org.apache.sling.servlets.post)
> [0] 
> -https://github.com/apache/sling/commit/a598bd4f6e9fc4f967e118de705643a04a47bc44#diff-2ff02a567147f2cbef2e344d5338dd14R106



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [RESULT][VOTE] Release Apache Sling Servlets Post 2.3.24

[Karl Pauls]

Time to call the vote on the Apache Sling Servlets Post 2.3.24 release.

* +1 votes from Carsten Ziegeler, Stefan Seifert, and Karl Pauls.

* No other votes.

The vote is successful. I will make the artifacts available as soon as possible.

Re: [VOTE] Release Apache Sling Servlets Post 2.3.24

[Karl Pauls]

+1

regards,

Karl

On Fri, Jan 19, 2018 at 11:31 AM, Stefan Seifert  wrote:
> +1
>



-- 
Karl Pauls
karlpa...@gmail.com

[jira] [Commented] (SLING-7426) Use bnd Maven plugins

[Oliver Lietz (JIRA)]

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

Oliver Lietz commented on SLING-7426:
-

Yes. The bnd Maven Plugin was added by [~cziegeler] in mid 2016 (SLING-5859, 
see also [Building OSGi Bundles with Apache 
Maven|https://blog.osoco.de/2016/05/building-osgi-bundles-with-apache-maven/]) 
and we are now hit by a packaging issue in Felix's Bundle Plugin (SLING-7351). 
Instead of working around the issue I started to switch to the more modern and 
future-proof bnd Maven Plugin.

> Use bnd Maven plugins
> -
>
> Key: SLING-7426
> URL: https://issues.apache.org/jira/browse/SLING-7426
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: pipes 2.0.0
>Reporter: Oliver Lietz
>Assignee: Nicolas Peltier
>Priority: Major
> Fix For: pipes 2.0.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (SLING-6952) Release Sling 10

[Radu Cotescu (JIRA)]

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

Radu Cotescu edited comment on SLING-6952 at 1/23/18 10:02 AM:
---

[~rombert], please check my comment from \[0\]. The staged launchpad uses 
{{org.apache.sling.i18n}} 2.5.10, which seems to have introduced a bug into how 
{{basename}} is handled by the {{ResourceBundleProvider}}. The bug was fixed 
with SLING-7421, but unfortunately there are no tests for this in the {{i18n}} 
bundle.

I think we need to drop the launchpad release from staging, provide some tests 
for SLING-7421, release {{org.apache.sling.i18n}} 2.5.12 and restart the 
launchpad release with this updated dependency.

\[0\] - 
https://issues.apache.org/jira/browse/SLING-7073?focusedCommentId=16335486=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16335486


was (Author: radu.cotescu):
[~rombert], please check my comment from \[0\]. The staged launchpad uses 
{{org.apache.sling.i18n}} 2.5.10, which seems to have introduced a bug into how 
{{basename}} is handled by the {{ResourceBundleProvider}}. The bug was fixed 
with SLING-7421, but unfortunately there are no tests for this in the {{i18n}} 
bundle.

I think we need to drop the launchpad release from staging, provide some tests 
for SLING-7421, release {{org.apache.sling.i18n}} 2.5.12 and restart the 
launchpad release with this updated dependency.

\[0\] - 
https://issues.apache.org/jira/browse/SLING-7073?focusedCommentId=16335529=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16335529

> Release Sling 10
> 
>
> Key: SLING-6952
> URL: https://issues.apache.org/jira/browse/SLING-6952
> Project: Sling
>  Issue Type: Task
>  Components: General
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
>
> Never too early to start planning :-)
> Documentation at 
> https://cwiki.apache.org/confluence/display/SLING/Releasing+a+new+version+of+the+Sling+Launchpad



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Release Apache Sling Starter 10 + associated testing projects and archetypes (take 2)

[Radu Cotescu]

-1. See
https://issues.apache.org/jira/browse/SLING-6952?focusedCommentId=16335586=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16335586
.

Sorry for this... :(

Radu

On Mon, 22 Jan 2018 at 23:16 Karl Pauls  wrote:

> +1
>
> regards,
>
> Karl
>
> On Fri, Jan 19, 2018 at 6:24 PM, Robert Munteanu 
> wrote:
> > Hi,
> >
> > Update note: I've chosen to respin the Starter release with the same
> > version, for 2 reasons:
> >
> > - it would generate confusion to skip a release
> > - chances of anyone depending on the staged slingstart are slim
> >
> > If anyone thinks otherwise, I'll restart the release vote as Sling 11.
> > 
> >
> > Time to release Sling 10. This year I've added all the testing
> > projects, to retain what was working at the time of the release and the
> > archetypes, to allow users to start using the new features immediately
> > rather than releasing them separately.
> >
> > This has lead to a rather large release though.
> >
> > The following artifacts, with the associated changelogs, are included
> > in this release
> >
> > - Apache Sling Starter 10
> > https://issues.apache.org/jira/projects/SLING/versions/12340941 (13
> issues)
> >
> > - Apache Sling Launchpad Testing 10
> > https://issues.apache.org/jira/projects/SLING/versions/12317575 (33
> issues)
> >
> > - Apache Sling Launchpad Testing WAR 10
> > https://issues.apache.org/jira/projects/SLING/versions/12342164 (0
> issues)
> >
> > - Apache Sling Launchpad Integration Tests 1.0.6
> > https://issues.apache.org/jira/projects/SLING/versions/12341715 (0
> issues)
> >
> > - Apache Sling Launchpad Test Bundles 0.0.4 (no changelog)
> > - Apache Sling Launchpad Testing Fragment Bundle 2.0.14 (no changelog)
> >
> > - Apache Sling Launchpad Testing Services 2.0.14
> > https://issues.apache.org/jira/projects/SLING/versions/12338823 (2
> issues)
> >
> > - Apache Sling Launchpad Testing Services WAR 2.0.14 (no changelog)
> >
> > - Apache Sling Archetype Parent 5
> > https://issues.apache.org/jira/projects/SLING/versions/12333898 (2
> issues)
> >
> > - Apache Sling Bundle Archetype 1.0.6
> > https://issues.apache.org/jira/browse/SLING/fixforversion/12333900 (2
> issues)
> >
> > - Apache Sling JCRInstall Bundle Archetype 1.0.6
> > https://issues.apache.org/jira/browse/SLING/fixforversion/12333901 (2
> issues)
> >
> > - Apache Sling Initial Content Archetype 1.0.6
> > https://issues.apache.org/jira/browse/SLING/fixforversion/12333902 (2
> issues)
> >
> > - Apache Sling Slingstart Archetype 1.0.6
> > https://issues.apache.org/jira/browse/SLING/fixforversion/12340954 (2
> issues)
> >
> > Staging repositories:
> > https://repository.apache.org/content/repositories/orgapachesling-1857
> > https://repository.apache.org/content/repositories/orgapachesling-1858
> >
> > You can use this UNIX script to download the release and verify the
> > signatures:
> >
> https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD
> >
> > Usage:
> > sh check_staged_release.sh 1857 /tmp/sling-stagingsh
> check_staged_release.sh 1858 /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, but I'd be more than
> > happy to allow extensions if anyone needs more time to validate the
> > release.
> >
> > Thanks,
> >
> > Robert
> >
>
>
>
> --
> Karl Pauls
> karlpa...@gmail.com
>

[jira] [Comment Edited] (SLING-6952) Release Sling 10

[Radu Cotescu (JIRA)]

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

Radu Cotescu edited comment on SLING-6952 at 1/23/18 9:59 AM:
--

[~rombert], please check my comment from \[0\]. The staged launchpad uses 
{{org.apache.sling.i18n}} 2.5.10, which seems to have introduced a bug into how 
{{basename}} is handled by the {{ResourceBundleProvider}}. The bug was fixed 
with SLING-7421, but unfortunately there are no tests for this in the {{i18n}} 
bundle.

I think we need to drop the launchpad release from staging, provide some tests 
for SLING-7421, release {{org.apache.sling.i18n}} 2.5.12 and restart the 
launchpad release with this updated dependency.

\[0\] - 
https://issues.apache.org/jira/browse/SLING-7073?focusedCommentId=16335529=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16335529


was (Author: radu.cotescu):
[~rombert], please check my comment from \[0\]. The staged launchpad uses 
{{org.apache.sling.i18n}} 2.5.10, which seems to have introduced a bug into how 
{{basename}} is handled by the {{ResourceBundleProvider}}. The bug was fixed 
with SLING-7421, but unfortunately there are not tests for this in the {{i18n}} 
bundle.

I think we need to drop the launchpad release from staging, provide some tests 
for SLING-7421, release {{org.apache.sling.i18n}} 2.5.12 and restart the 
launchpad release with this updated dependency.

\[0\] - 
https://issues.apache.org/jira/browse/SLING-7073?focusedCommentId=16335529=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16335529

> Release Sling 10
> 
>
> Key: SLING-6952
> URL: https://issues.apache.org/jira/browse/SLING-6952
> Project: Sling
>  Issue Type: Task
>  Components: General
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
>
> Never too early to start planning :-)
> Documentation at 
> https://cwiki.apache.org/confluence/display/SLING/Releasing+a+new+version+of+the+Sling+Launchpad



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-6952) Release Sling 10

[Radu Cotescu (JIRA)]

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

Radu Cotescu commented on SLING-6952:
-

[~rombert], please check my comment from \[0\]. The staged launchpad uses 
{{org.apache.sling.i18n}} 2.5.10, which seems to have introduced a bug into how 
{{basename}} is handled by the {{ResourceBundleProvider}}. The bug was fixed 
with SLING-7421, but unfortunately there are not tests for this in the {{i18n}} 
bundle.

I think we need to drop the launchpad release from staging, provide some tests 
for SLING-7421, release {{org.apache.sling.i18n}} 2.5.12 and restart the 
launchpad release with this updated dependency.

\[0\] - 
https://issues.apache.org/jira/browse/SLING-7073?focusedCommentId=16335529=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16335529

> Release Sling 10
> 
>
> Key: SLING-6952
> URL: https://issues.apache.org/jira/browse/SLING-6952
> Project: Sling
>  Issue Type: Task
>  Components: General
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
>
> Never too early to start planning :-)
> Documentation at 
> https://cwiki.apache.org/confluence/display/SLING/Releasing+a+new+version+of+the+Sling+Launchpad



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (SLING-7073) Update bundle versions

[Radu Cotescu (JIRA)]

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

Radu Cotescu edited comment on SLING-7073 at 1/23/18 9:55 AM:
--

Worked with 2.5.8, doesn't work with 2.5.10, works again with 2.5.11-SNAPSHOT, 
which indicates that SLING-7421 fixed the problem.


was (Author: radu.cotescu):
Worked with 2.5.8, doesn't work with 2.5.10, works again with 2.5.11-SNAPSHOT.

> Update bundle versions
> --
>
> Key: SLING-7073
> URL: https://issues.apache.org/jira/browse/SLING-7073
> Project: Sling
>  Issue Type: Sub-task
>  Components: Launchpad
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Starter 10
>
>
> Before the launchpad release, include the latest versions of external bundles 
> and also check that our own bundles are at the latest versions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (SLING-7426) Use bnd Maven plugins

[Nicolas Peltier (JIRA)]

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

Nicolas Peltier resolved SLING-7426.

   Resolution: Fixed
Fix Version/s: pipes 2.0.0

Thanks [~olli] !

> Use bnd Maven plugins
> -
>
> Key: SLING-7426
> URL: https://issues.apache.org/jira/browse/SLING-7426
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: pipes 2.0.0
>Reporter: Oliver Lietz
>Assignee: Nicolas Peltier
>Priority: Major
> Fix For: pipes 2.0.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Please welcome Jason Bailey, Sling committer

[Bertrand Delacretaz]

Hi Jason, welcome!

On Mon, Jan 22, 2018 at 8:45 PM, Jason Bailey  wrote:
> I've been primarily a Java developer since the 1.2 days...
> ...audio codec implementations, swing apps...

Same here...Swing apps in 1999, and they even worked, those were the days!

-Bertrand

[jira] [Commented] (SLING-7426) Use bnd Maven plugins

[Nicolas Peltier (JIRA)]

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

Nicolas Peltier commented on SLING-7426:


is the rationale the arguments detailed here:
http://njbartlett.name/2015/03/27/announcing-bnd-maven-plugin.html
?

> Use bnd Maven plugins
> -
>
> Key: SLING-7426
> URL: https://issues.apache.org/jira/browse/SLING-7426
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: pipes 2.0.0
>Reporter: Oliver Lietz
>Assignee: Nicolas Peltier
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (SLING-7427) Package names should be all lowercase

[Nicolas Peltier (JIRA)]

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

Nicolas Peltier resolved SLING-7427.

Resolution: Fixed

> Package names should be all lowercase
> -
>
> Key: SLING-7427
> URL: https://issues.apache.org/jira/browse/SLING-7427
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Oliver Lietz
>Assignee: Nicolas Peltier
>Priority: Major
> Fix For: pipes 2.0.0
>
>
> {{org.apache.sling.pipes.internal.slingQuery}}
> See [Naming a 
> Package|https://docs.oracle.com/javase/tutorial/java/package/namingpkgs.html].



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7427) Package names should be all lowercase

[Nicolas Peltier (JIRA)]

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

Nicolas Peltier commented on SLING-7427:


thanks for your vigilance [~olli]!

> Package names should be all lowercase
> -
>
> Key: SLING-7427
> URL: https://issues.apache.org/jira/browse/SLING-7427
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Oliver Lietz
>Assignee: Nicolas Peltier
>Priority: Major
> Fix For: pipes 2.0.0
>
>
> {{org.apache.sling.pipes.internal.slingQuery}}
> See [Naming a 
> Package|https://docs.oracle.com/javase/tutorial/java/package/namingpkgs.html].



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7073) Update bundle versions

[Radu Cotescu (JIRA)]

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

Radu Cotescu commented on SLING-7073:
-

Worked with 2.5.8, doesn't work with 2.5.10, works again with 2.5.11-SNAPSHOT.

> Update bundle versions
> --
>
> Key: SLING-7073
> URL: https://issues.apache.org/jira/browse/SLING-7073
> Project: Sling
>  Issue Type: Sub-task
>  Components: Launchpad
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Starter 10
>
>
> Before the launchpad release, include the latest versions of external bundles 
> and also check that our own bundles are at the latest versions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7073) Update bundle versions

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-7073:


If this works with 2.5.10 but not with 2.5.12 then it's likely a problem due to 
SLING-7363. If it works with 2.5.8 but not 2.5.10 or newer it could be 
SLING-7421. Which one is it?

> Update bundle versions
> --
>
> Key: SLING-7073
> URL: https://issues.apache.org/jira/browse/SLING-7073
> Project: Sling
>  Issue Type: Sub-task
>  Components: Launchpad
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Starter 10
>
>
> Before the launchpad release, include the latest versions of external bundles 
> and also check that our own bundles are at the latest versions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7073) Update bundle versions

[Radu Cotescu (JIRA)]

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

Radu Cotescu commented on SLING-7073:
-

{{basename}} doesn't seem to be correctly taken into consideration for that 
method, with the following failure in the HTL tests from 
{{org-apache-sling-scripting-sightly-testing}}:
{noformat}
SlingSpecificsSightlyIT.testI18nBasename:341 expected: but 
was:
{noformat}

> Update bundle versions
> --
>
> Key: SLING-7073
> URL: https://issues.apache.org/jira/browse/SLING-7073
> Project: Sling
>  Issue Type: Sub-task
>  Components: Launchpad
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Starter 10
>
>
> Before the launchpad release, include the latest versions of external bundles 
> and also check that our own bundles are at the latest versions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (SLING-7073) Update bundle versions

[Radu Cotescu (JIRA)]

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

Radu Cotescu edited comment on SLING-7073 at 1/23/18 8:17 AM:
--

{{basename}} doesn't seem to be correctly taken into consideration for 
{{org.apache.sling.i18n.ResourceBundleProvider#getResourceBundle(java.lang.String,
 java.util.Locale)}}, with the following failure in the HTL tests from 
{{org-apache-sling-scripting-sightly-testing}}:
{noformat}
SlingSpecificsSightlyIT.testI18nBasename:341 expected: but 
was:
{noformat}


was (Author: radu.cotescu):
{{basename}} doesn't seem to be correctly taken into consideration for that 
method, with the following failure in the HTL tests from 
{{org-apache-sling-scripting-sightly-testing}}:
{noformat}
SlingSpecificsSightlyIT.testI18nBasename:341 expected: but 
was:
{noformat}

> Update bundle versions
> --
>
> Key: SLING-7073
> URL: https://issues.apache.org/jira/browse/SLING-7073
> Project: Sling
>  Issue Type: Sub-task
>  Components: Launchpad
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Starter 10
>
>
> Before the launchpad release, include the latest versions of external bundles 
> and also check that our own bundles are at the latest versions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7073) Update bundle versions

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-7073:


[~radu.cotescu] - what errors do you see? SLING-7421 fixed an error that was 
there since 2.5.10.

> Update bundle versions
> --
>
> Key: SLING-7073
> URL: https://issues.apache.org/jira/browse/SLING-7073
> Project: Sling
>  Issue Type: Sub-task
>  Components: Launchpad
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Starter 10
>
>
> Before the launchpad release, include the latest versions of external bundles 
> and also check that our own bundles are at the latest versions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)