[jira] [Commented] (SLING-5983) Remove deprecated jcr resource API

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-5983:
-

[~karlpauls] Yes, lgtm, thanks

> Remove deprecated jcr resource API
> --
>
> Key: SLING-5983
> URL: https://issues.apache.org/jira/browse/SLING-5983
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Carsten Ziegeler
>Assignee: Karl Pauls
> Fix For: JCR Resource 2.9.4
>
> Attachments: SLING-5983.patch
>
>
> The jcr resource API has been deprecated for some time and not used anymore 
> in our codebase, we should now remove it from the jcr resource bundle
> We should also remove the deprecated PathMapper



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (SLING-5983) Remove deprecated jcr resource API

[Karl Pauls (JIRA)]

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

Karl Pauls edited comment on SLING-5983 at 4/10/17 10:02 PM:
-

[~cziegeler], something like the attached [^SLING-5983.patch]? 



was (Author: karlpauls):
[~cziegeler], something like the attached [^SLING-5983.patch]

> Remove deprecated jcr resource API
> --
>
> Key: SLING-5983
> URL: https://issues.apache.org/jira/browse/SLING-5983
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Carsten Ziegeler
>Assignee: Karl Pauls
> Fix For: JCR Resource 2.9.4
>
> Attachments: SLING-5983.patch
>
>
> The jcr resource API has been deprecated for some time and not used anymore 
> in our codebase, we should now remove it from the jcr resource bundle
> We should also remove the deprecated PathMapper



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-5983) Remove deprecated jcr resource API

[Karl Pauls (JIRA)]

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

Karl Pauls updated SLING-5983:
--
Attachment: SLING-5983.patch

[~cziegeler], something like the attached [^SLING-5983.patch]

> Remove deprecated jcr resource API
> --
>
> Key: SLING-5983
> URL: https://issues.apache.org/jira/browse/SLING-5983
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Carsten Ziegeler
>Assignee: Karl Pauls
> Fix For: JCR Resource 2.9.4
>
> Attachments: SLING-5983.patch
>
>
> The jcr resource API has been deprecated for some time and not used anymore 
> in our codebase, we should now remove it from the jcr resource bundle
> We should also remove the deprecated PathMapper



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (SLING-5983) Remove deprecated jcr resource API

[Karl Pauls (JIRA)]

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

Karl Pauls reassigned SLING-5983:
-

Assignee: Karl Pauls

> Remove deprecated jcr resource API
> --
>
> Key: SLING-5983
> URL: https://issues.apache.org/jira/browse/SLING-5983
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Carsten Ziegeler
>Assignee: Karl Pauls
> Fix For: JCR Resource 2.9.4
>
>
> The jcr resource API has been deprecated for some time and not used anymore 
> in our codebase, we should now remove it from the jcr resource bundle
> We should also remove the deprecated PathMapper



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (SLING-6773) Separate HeathCheck API from Implementation

[Justin Edelson (JIRA)]

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

Justin Edelson resolved SLING-6773.
---
Resolution: Fixed

Change made in r1790879 

> Separate HeathCheck API from Implementation
> ---
>
> Key: SLING-6773
> URL: https://issues.apache.org/jira/browse/SLING-6773
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check
>Affects Versions: Health Check Core 1.2.6
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Health Check Core 1.2.8, Health Check API 1.0.0
>
> Attachments: SLING-6773.diff
>
>
> Currently, the HealthCheck API and implementation are bundled together in one 
> bundle. In order for implementors of HealthChecks to only need to depend upon 
> a minimal dependency, we should package the API separately.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6763) Remove org.apache.sling.commons.json dependency from esx engine

[Oliver Lietz (JIRA)]

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

Oliver Lietz commented on SLING-6763:
-

[~labertasch], have a look at Scripting Thymeleaf or Scripting FreeMarker for 
integration testing with Pax Exam.

> Remove org.apache.sling.commons.json dependency from esx engine
> ---
>
> Key: SLING-6763
> URL: https://issues.apache.org/jira/browse/SLING-6763
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Reporter: Senol Tas
>Assignee: Bertrand Delacretaz
> Fix For: Scripting ESX 0.2.0
>
>
> remove org.apache.sling.commons.json dependency from esx engine and replace 
> with native build in nashorn JSON parser
> + minor updates in the demo package to showcase the usage of dynamically 
> changing handlebars templates based on selector.
> + added experimental es6 transpiler as preperation for sandboxing the engine
> + updated demo with es6 classes and imports
> i created a pull request on github:
> https://github.com/apache/sling/pull/209



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6763) Remove org.apache.sling.commons.json dependency from esx engine

[Oliver Lietz (JIRA)]

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

Oliver Lietz updated SLING-6763:

Fix Version/s: Scripting ESX 0.2.0

> Remove org.apache.sling.commons.json dependency from esx engine
> ---
>
> Key: SLING-6763
> URL: https://issues.apache.org/jira/browse/SLING-6763
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Reporter: Senol Tas
>Assignee: Bertrand Delacretaz
> Fix For: Scripting ESX 0.2.0
>
>
> remove org.apache.sling.commons.json dependency from esx engine and replace 
> with native build in nashorn JSON parser
> + minor updates in the demo package to showcase the usage of dynamically 
> changing handlebars templates based on selector.
> + added experimental es6 transpiler as preperation for sandboxing the engine
> + updated demo with es6 classes and imports
> i created a pull request on github:
> https://github.com/apache/sling/pull/209



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6763) Remove org.apache.sling.commons.json dependency from esx engine

[Oliver Lietz (JIRA)]

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

Oliver Lietz updated SLING-6763:

Affects Version/s: (was: Scripting ESX 0.2.0)

> Remove org.apache.sling.commons.json dependency from esx engine
> ---
>
> Key: SLING-6763
> URL: https://issues.apache.org/jira/browse/SLING-6763
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Reporter: Senol Tas
>Assignee: Bertrand Delacretaz
> Fix For: Scripting ESX 0.2.0
>
>
> remove org.apache.sling.commons.json dependency from esx engine and replace 
> with native build in nashorn JSON parser
> + minor updates in the demo package to showcase the usage of dynamically 
> changing handlebars templates based on selector.
> + added experimental es6 transpiler as preperation for sandboxing the engine
> + updated demo with es6 classes and imports
> i created a pull request on github:
> https://github.com/apache/sling/pull/209



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6763) Remove org.apache.sling.commons.json dependency from esx engine

[Senol Tas (JIRA)]

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

Senol Tas commented on SLING-6763:
--

+ any help writing test-cases is appreciated. a blueprint which i could take up 
from would be also cool :-)

> Remove org.apache.sling.commons.json dependency from esx engine
> ---
>
> Key: SLING-6763
> URL: https://issues.apache.org/jira/browse/SLING-6763
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Apache Sling Scripting ESX 0.2.0
>Reporter: Senol Tas
>Assignee: Bertrand Delacretaz
>
> remove org.apache.sling.commons.json dependency from esx engine and replace 
> with native build in nashorn JSON parser
> + minor updates in the demo package to showcase the usage of dynamically 
> changing handlebars templates based on selector.
> + added experimental es6 transpiler as preperation for sandboxing the engine
> + updated demo with es6 classes and imports
> i created a pull request on github:
> https://github.com/apache/sling/pull/209



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6763) Remove org.apache.sling.commons.json dependency from esx engine

[Senol Tas (JIRA)]

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

Senol Tas commented on SLING-6763:
--

Thanks Bertrand for the Feedback.

I bundled the sling-babel implementation with the code and extended the maven 
build script to automatically install node dependencies. also adapted the 
README as it is not required to do separate installation for the demo anymore.
to test it: 
update the readme test example from:
```var output  = "" + currentNode.properties.title + "";
 to ```var output  = `${currentNode.properties.title}`;```
Which is the es6 template string, if this is getting rendered it is working.
as reference you can use: https://babeljs.io/learn-es2015/


> Remove org.apache.sling.commons.json dependency from esx engine
> ---
>
> Key: SLING-6763
> URL: https://issues.apache.org/jira/browse/SLING-6763
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Apache Sling Scripting ESX 0.2.0
>Reporter: Senol Tas
>Assignee: Bertrand Delacretaz
>
> remove org.apache.sling.commons.json dependency from esx engine and replace 
> with native build in nashorn JSON parser
> + minor updates in the demo package to showcase the usage of dynamically 
> changing handlebars templates based on selector.
> + added experimental es6 transpiler as preperation for sandboxing the engine
> + updated demo with es6 classes and imports
> i created a pull request on github:
> https://github.com/apache/sling/pull/209



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6763) Remove org.apache.sling.commons.json dependency from esx engine

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-6763:


Also, minor typo, "decoreateScript" should be "decorateScript"

> Remove org.apache.sling.commons.json dependency from esx engine
> ---
>
> Key: SLING-6763
> URL: https://issues.apache.org/jira/browse/SLING-6763
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Apache Sling Scripting ESX 0.2.0
>Reporter: Senol Tas
>Assignee: Bertrand Delacretaz
>
> remove org.apache.sling.commons.json dependency from esx engine and replace 
> with native build in nashorn JSON parser
> + minor updates in the demo package to showcase the usage of dynamically 
> changing handlebars templates based on selector.
> + added experimental es6 transpiler as preperation for sandboxing the engine
> + updated demo with es6 classes and imports
> i created a pull request on github:
> https://github.com/apache/sling/pull/209



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6763) Remove org.apache.sling.commons.json dependency from esx engine

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-6763:


Thanks for your contribution! 

The {{sling-babel.js}} file is quite long and looks like it might have been 
generated, as opposed to handwritten code, could you briefly explain what it's 
about and if generated how that happens?

Also, I don't see any changes under src/test which might indicate "suboptimal" 
test coverage, is there a way to test these new features? Does the demo package 
allows for doing that manually? If yes that's ok as a temporary state until 
there's stronger test coverage, which we should have before releasing this 
module.

> Remove org.apache.sling.commons.json dependency from esx engine
> ---
>
> Key: SLING-6763
> URL: https://issues.apache.org/jira/browse/SLING-6763
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Apache Sling Scripting ESX 0.2.0
>Reporter: Senol Tas
>Assignee: Bertrand Delacretaz
>
> remove org.apache.sling.commons.json dependency from esx engine and replace 
> with native build in nashorn JSON parser
> + minor updates in the demo package to showcase the usage of dynamically 
> changing handlebars templates based on selector.
> + added experimental es6 transpiler as preperation for sandboxing the engine
> + updated demo with es6 classes and imports
> i created a pull request on github:
> https://github.com/apache/sling/pull/209



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (SLING-6763) Remove org.apache.sling.commons.json dependency from esx engine

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz reassigned SLING-6763:
--

Assignee: Bertrand Delacretaz

> Remove org.apache.sling.commons.json dependency from esx engine
> ---
>
> Key: SLING-6763
> URL: https://issues.apache.org/jira/browse/SLING-6763
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Apache Sling Scripting ESX 0.2.0
>Reporter: Senol Tas
>Assignee: Bertrand Delacretaz
>
> remove org.apache.sling.commons.json dependency from esx engine and replace 
> with native build in nashorn JSON parser
> + minor updates in the demo package to showcase the usage of dynamically 
> changing handlebars templates based on selector.
> + added experimental es6 transpiler as preperation for sandboxing the engine
> + updated demo with es6 classes and imports
> i created a pull request on github:
> https://github.com/apache/sling/pull/209



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6763) Remove org.apache.sling.commons.json dependency from esx engine

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz updated SLING-6763:
---
Summary: Remove org.apache.sling.commons.json dependency from esx engine  
(was: Remove org.apache.sling.commons.json depdency from esx engine)

> Remove org.apache.sling.commons.json dependency from esx engine
> ---
>
> Key: SLING-6763
> URL: https://issues.apache.org/jira/browse/SLING-6763
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Apache Sling Scripting ESX 0.2.0
>Reporter: Senol Tas
>
> remove org.apache.sling.commons.json dependency from esx engine and replace 
> with native build in nashorn JSON parser
> + minor updates in the demo package to showcase the usage of dynamically 
> changing handlebars templates based on selector.
> + added experimental es6 transpiler as preperation for sandboxing the engine
> + updated demo with es6 classes and imports
> i created a pull request on github:
> https://github.com/apache/sling/pull/209



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6685) Replace commons.json usage in org.apache.sling.xss

[Karl Pauls (JIRA)]

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

Karl Pauls commented on SLING-6685:
---

[~sseif...@pro-vision.de], should I reopen this issue and go ahead and move the 
JSONUtil in a separate packages? 

> Replace commons.json usage in org.apache.sling.xss
> --
>
> Key: SLING-6685
> URL: https://issues.apache.org/jira/browse/SLING-6685
> Project: Sling
>  Issue Type: Sub-task
>  Components: XSS Protection API
>Affects Versions: XSS Protection API 1.0.18
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>  Labels: patch-available
> Fix For: XSS Protection API 1.0.20
>
> Attachments: SLING-6685-2.patch, SLING-6685.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Wiki access

[Konrad Windszus]

Thanks, Carsten. I will extend the documentation and point to 
https://cwiki.apache.org/confluence/spaces/viewspacesummary.action?key=SLING=true
 for a list of all current admins.
I think asking for edit permissions via the mailing list is the way to go then.
Konrad

> On 10. Apr 2017, at 08:47, Carsten Ziegeler  wrote:
> 
> Hi,
> 
> it seems we have a lot of admins for that space, and I'm one of them :)
> So I added your id and gave you appropriate permissions to work on that
> wiki.
> 
> Regards
> Carsten
> 
> Konrad Windszus wrote
>> Hi, according to http://sling.apache.org/documentation.html#the-public-wiki 
>> the wiki is open for self-registration (which is true) and automatically 
>> grants everyone write/edit access (which is obviously not true). I see that 
>> the root page is write-restricted to the group sling-committers. How do I 
>> become member of that group? My Confluence username is "kwin".
>> 
>> The only documentation I found at Apache is 
>> https://cwiki.apache.org/confluence/display/INFRA/Cwiki which does not say 
>> anything about how the group memberships are managed, so I assume that this 
>> is done on the project level. Who is currently wiki space admin for 
>> https://cwiki.apache.org/confluence/display/SLING/?
>> 
>> Thanks,
>> Konrad
>> 
> 
> 
> 
> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

[jira] [Commented] (SLING-6261) ThreadExpiringThreadPool is relying on uncaught exceptions to kill threads

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6261:
-

Good point, we could also simply revert to the current mechanism if the 
reflection trick does not work.

> ThreadExpiringThreadPool is relying on uncaught exceptions to kill threads
> --
>
> Key: SLING-6261
> URL: https://issues.apache.org/jira/browse/SLING-6261
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Affects Versions: Commons Threads 3.2.6
>Reporter: Konrad Windszus
> Fix For: Commons Threads 3.2.8
>
> Attachments: SLING-6261-v01.patch
>
>
> In {{o.a.s.commons.threads.impl.ThreadExpiringThreadPool}} a 
> {{RuntimeException}} with message "Kill old thread" is used in 
> {{checkMaxThreadAge(final Thread thread)}}. This leads by default to a 
> suspension of the thread when debugging with Eclipse (as since Neon JDT will 
> suspend the thread on all uncaught exceptions). More information is available 
> in 
> http://stackoverflow.com/questions/6290470/eclipse-debugger-always-blocks-on-threadpoolexecutor-without-any-obvious-excepti.
>  There should be a different mechanism to kill the thread than an uncaught 
> exception.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (SLING-6777) ValidationServiceImpl breaks when hitting closed resolver for resource bundles (i18n)

[Oliver Lietz (JIRA)]

Oliver Lietz created SLING-6777:
---

 Summary: ValidationServiceImpl breaks when hitting closed resolver 
for resource bundles (i18n)
 Key: SLING-6777
 URL: https://issues.apache.org/jira/browse/SLING-6777
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Reporter: Oliver Lietz


{noformat}
java.lang.IllegalStateException: Resource resolver is already closed.
at 
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.checkClosed(ResourceResolverImpl.java:186)
at 
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.findResources(ResourceResolverImpl.java:731)
at 
org.apache.sling.i18n.impl.JcrResourceBundle.loadPotentialLanguageRoots(JcrResourceBundle.java:328)
at 
org.apache.sling.i18n.impl.JcrResourceBundle.(JcrResourceBundle.java:85)
at 
org.apache.sling.i18n.impl.JcrResourceBundleProvider.createResourceBundle(JcrResourceBundleProvider.java:452)
at 
org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:411)
at 
org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:180)
at 
org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:171)
at 
org.apache.sling.validation.impl.ValidationServiceImpl.getDefaultResourceBundle(ValidationServiceImpl.java:196)
at 
org.apache.sling.validation.impl.ValidationServiceImpl.validate(ValidationServiceImpl.java:292)
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (SLING-6776) Rename ValidationContextImpl to ValidatorContextImpl

[Oliver Lietz (JIRA)]

Oliver Lietz created SLING-6776:
---

 Summary: Rename ValidationContextImpl to ValidatorContextImpl
 Key: SLING-6776
 URL: https://issues.apache.org/jira/browse/SLING-6776
 Project: Sling
  Issue Type: Improvement
  Components: Extensions, Validation
Affects Versions: Validation 1.0.0
Reporter: Oliver Lietz


{{ValidationContextImpl}} implements {{ValidatorContext}} and should be named 
accordingly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6261) ThreadExpiringThreadPool is relying on uncaught exceptions to kill threads

[Julian Sedding (JIRA)]

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

Julian Sedding commented on SLING-6261:
---

I think the approach looks pretty good and is definitely an improvement. 
However, I have not thoroughly reviewed the code.

We need to consider what happens on other JVMs than Oracle's, however. I don't 
know if ThreadLocals are implemented the same way and accessing the (internal) 
fields via reflection works. IMHO this requires us to:

- make sure the ThreadLocal cleaning functionality is disabled if the fields 
cannot be found via reflection (I think an "info" level log message at startup 
to indicate this situation would be appropriate)
- (possibly later) enhance the code to cover other JVMs


> ThreadExpiringThreadPool is relying on uncaught exceptions to kill threads
> --
>
> Key: SLING-6261
> URL: https://issues.apache.org/jira/browse/SLING-6261
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Affects Versions: Commons Threads 3.2.6
>Reporter: Konrad Windszus
> Fix For: Commons Threads 3.2.8
>
> Attachments: SLING-6261-v01.patch
>
>
> In {{o.a.s.commons.threads.impl.ThreadExpiringThreadPool}} a 
> {{RuntimeException}} with message "Kill old thread" is used in 
> {{checkMaxThreadAge(final Thread thread)}}. This leads by default to a 
> suspension of the thread when debugging with Eclipse (as since Neon JDT will 
> suspend the thread on all uncaught exceptions). More information is available 
> in 
> http://stackoverflow.com/questions/6290470/eclipse-debugger-always-blocks-on-threadpoolexecutor-without-any-obvious-excepti.
>  There should be a different mechanism to kill the thread than an uncaught 
> exception.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (SLING-6772) Provide default mapping for service users

[Julian Sedding (JIRA)]

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

Julian Sedding edited comment on SLING-6772 at 4/10/17 8:28 AM:


I'm fine with your suggestion (don't fully understand the property name, yet, 
but that's not critical imho).

-Could we additionally enhance the javadoc to mention that "subservice name" 
should (must?) not have a double dash? We could even enforce it via an illegal 
argument exception. That way we could check for the last occurrence of a double 
dash to identify the "subservice name". As it is optional, we would als need to 
fall back to interpreting everything after {{serviceuser\-\-}} as the BSN. At 
the very least we need to document this constraint on "subservice name" for the 
default user mapping.-

-We could always log a warning or error (or even throw an exception) if there 
is ambiguity and help the developer fix it by changing the subservice name or 
by providing an explicit configuration.-

EDIT: After looking at the code, I think the above does not apply, since the 
user-name is generated, but does not need to be parsed. Therefore, either we 
find a user with a matching principal name, or we have no effective mapping (in 
which case I hope there is a warning/error, probably a LoginException).


was (Author: jsedding):
I'm fine with your suggestion (don't fully understand the property name, yet, 
but that's not critical imho).

-Could we additionally enhance the javadoc to mention that "subservice name" 
should (must?) not have a double dash? We could even enforce it via an illegal 
argument exception. That way we could check for the last occurrence of a double 
dash to identify the "subservice name". As it is optional, we would als need to 
fall back to interpreting everything after {{serviceuser\-\-}} as the BSN. At 
the very least we need to document this constraint on "subservice name" for the 
default user mapping.-

-We could always log a warning or error (or even throw an exception) if there 
is ambiguity and help the developer fix it by changing the subservice name or 
by providing an explicit configuration.-

After looking at the code, I think the above does not apply, since the 
user-name is generated, but does not need to be parsed. Therefore, either we 
find a user with a matching principal name, or we have no effective mapping (in 
which case I hope there is a warning/error, probably a LoginException).

> Provide default mapping for service users
> -
>
> Key: SLING-6772
> URL: https://issues.apache.org/jira/browse/SLING-6772
> Project: Sling
>  Issue Type: Improvement
>  Components: Service User Mapper
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Service User Mapper 1.3.0
>
> Attachments: SLING-6772.karaf.patch, SLING-6772.repoinit.patch
>
>
> As discussed in [1] we should aim at making Sling configurationless again. 
> One part which currently always needs configurations is the service user 
> mapper. We should add a default mapping, from a bundle symblic name and sub 
> service to 
> {noformat}
> "serviceuser@" + {bundle.symblicName} + [":" + sub service]
> {noformat}
> [1] 
> https://lists.apache.org/thread.html/6f90d751ddd20d7041475ba5d5fc89beda1906048ff91cc2f564e63e@%3Cdev.sling.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (SLING-6772) Provide default mapping for service users

[Julian Sedding (JIRA)]

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

Julian Sedding edited comment on SLING-6772 at 4/10/17 8:28 AM:


I'm fine with your suggestion (don't fully understand the property name, yet, 
but that's not critical imho).

-Could we additionally enhance the javadoc to mention that "subservice name" 
should (must?) not have a double dash? We could even enforce it via an illegal 
argument exception. That way we could check for the last occurrence of a double 
dash to identify the "subservice name". As it is optional, we would als need to 
fall back to interpreting everything after {{serviceuser\-\-}} as the BSN. At 
the very least we need to document this constraint on "subservice name" for the 
default user mapping.-

-We could always log a warning or error (or even throw an exception) if there 
is ambiguity and help the developer fix it by changing the subservice name or 
by providing an explicit configuration.-

After looking at the code, I think the above does not apply, since the 
user-name is generated, but does not need to be parsed. Therefore, either we 
find a user with a matching principal name, or we have no effective mapping (in 
which case I hope there is a warning/error, probably a LoginException).


was (Author: jsedding):
I'm fine with your suggestion (don't fully understand the property name, yet, 
but that's not critical imho).

Could we additionally enhance the javadoc to mention that "subservice name" 
should (must?) not have a double dash? We could even enforce it via an illegal 
argument exception. That way we could check for the last occurrence of a double 
dash to identify the "subservice name". As it is optional, we would als need to 
fall back to interpreting everything after {{serviceuser--}} as the BSN. At the 
very least we need to document this constraint on "subservice name" for the 
default user mapping.

We could always log a warning or error (or even throw an exception) if there is 
ambiguity and help the developer fix it by changing the subservice name or by 
providing an explicit configuration.

> Provide default mapping for service users
> -
>
> Key: SLING-6772
> URL: https://issues.apache.org/jira/browse/SLING-6772
> Project: Sling
>  Issue Type: Improvement
>  Components: Service User Mapper
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Service User Mapper 1.3.0
>
> Attachments: SLING-6772.karaf.patch, SLING-6772.repoinit.patch
>
>
> As discussed in [1] we should aim at making Sling configurationless again. 
> One part which currently always needs configurations is the service user 
> mapper. We should add a default mapping, from a bundle symblic name and sub 
> service to 
> {noformat}
> "serviceuser@" + {bundle.symblicName} + [":" + sub service]
> {noformat}
> [1] 
> https://lists.apache.org/thread.html/6f90d751ddd20d7041475ba5d5fc89beda1906048ff91cc2f564e63e@%3Cdev.sling.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-4043) The JCR properties view does not display escaped properties with escaped values correctly

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-4043:


I would very much like to make the {{JcrNode}} delegate most of the heavy 
lifting to the {{ResourceProxy}}. Do you think we can do that, at least in a 
first step, just for reading? This might allow us to not regress and lose 
formatting changes.I am more concerned about comments rather than formatting 
changes ( I think vlt ci already does that anyway ).

Alternatively we could allow ResourceProxy to safely update an existing XML 
file.



> The JCR properties view does not display escaped properties with escaped 
> values correctly
> -
>
> Key: SLING-4043
> URL: https://issues.apache.org/jira/browse/SLING-4043
> Project: Sling
>  Issue Type: Bug
>  Components: IDE
>Affects Versions: Sling Eclipse IDE 1.0.2
>Reporter: Robert Munteanu
>Assignee: Konrad Windszus
> Fix For: Sling Eclipse IDE 1.2.0
>
>
> Consider a property serialized as 
> {noformat}org.apache.sling.commons.log.pattern="\{0,date,-MM-dd 
> HH:mm:ss.SSS} {4} [{3}] {5}"{noformat}
> The value displayed by the JCR properties view is {noformat}{4} [{3}] 
> {5}{noformat}, while the value displayed when editing is 
> {noformat}\{0,date,-MM-dd HH:mm:ss.SSS} {4} [{3}] {5}{noformat}
> In fact, both the display and edit modes should work with the unescaped value 
> {noformat}{0,date,-MM-dd HH:mm:ss.SSS} {4} [{3}] {5}{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6772) Provide default mapping for service users

[Julian Sedding (JIRA)]

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

Julian Sedding commented on SLING-6772:
---

I'm fine with your suggestion (don't fully understand the property name, yet, 
but that's not critical imho).

Could we additionally enhance the javadoc to mention that "subservice name" 
should (must?) not have a double dash? We could even enforce it via an illegal 
argument exception. That way we could check for the last occurrence of a double 
dash to identify the "subservice name". As it is optional, we would als need to 
fall back to interpreting everything after {{serviceuser--}} as the BSN. At the 
very least we need to document this constraint on "subservice name" for the 
default user mapping.

We could always log a warning or error (or even throw an exception) if there is 
ambiguity and help the developer fix it by changing the subservice name or by 
providing an explicit configuration.

> Provide default mapping for service users
> -
>
> Key: SLING-6772
> URL: https://issues.apache.org/jira/browse/SLING-6772
> Project: Sling
>  Issue Type: Improvement
>  Components: Service User Mapper
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Service User Mapper 1.3.0
>
> Attachments: SLING-6772.karaf.patch, SLING-6772.repoinit.patch
>
>
> As discussed in [1] we should aim at making Sling configurationless again. 
> One part which currently always needs configurations is the service user 
> mapper. We should add a default mapping, from a bundle symblic name and sub 
> service to 
> {noformat}
> "serviceuser@" + {bundle.symblicName} + [":" + sub service]
> {noformat}
> [1] 
> https://lists.apache.org/thread.html/6f90d751ddd20d7041475ba5d5fc89beda1906048ff91cc2f564e63e@%3Cdev.sling.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [Jenkins] Job list needs to be updated [was Re: Build failed in Jenkins: sling-bundles-extensions-event-1.7 #19]

[Robert Munteanu]

On Mon, 2017-04-10 at 08:50 +0200, Carsten Ziegeler wrote:
> Hi
> 
> it seems the job list on Jenkins is referencing the old Sling Event
> source which has changed recently (split up of api and impl).
> Could someone please update the jobs on Jenkins accordingly?

Done in http://svn.apache.org/viewvc?view=revision=1790790 .

Robert

> 
> Thanks
> Carsten
> 
> Apache Jenkins Server wrote
> > See  > .7/19/display/redirect?page=changes>
> > 
> > Changes:
> > 
> > [cziegeler] SLING-6739 : split of sling.event to
> > sling.event.resource (and api). Use old project name / bundle
> > symbolic name and version for compatibility
> > 
> > --
> > Started by an SCM change
> > [EnvInject] - Loading node environment variables.
> > Building remotely on ubuntu-1 (ubuntu trusty) in workspace  > /builds.apache.org/job/sling-bundles-extensions-event-1.7/ws/>
> > Updating https://svn.apache.org/repos/asf/sling/trunk/bundles/exten
> > sions/event at revision '2017-04-10T06:05:07.174 +'
> > U resource/pom.xml
> > U api/pom.xml
> > U api/README.md
> > At revision 1790781
> > 
> > Parsing POMs
> > ERROR: No such file  > tensions-event-1.7/ws/pom.xml>
> > Perhaps you need to specify the correct POM file path in the
> > project configuration?
> > Recording test results
> > ERROR: Step ?Publish JUnit test result report? failed: Test reports
> > were found but none of them are new. Did tests run? 
> > For example,  > s-event-1.7/ws/target/failsafe-reports/TEST-
> > org.apache.sling.event.it.ChaosTest.xml> is 25 days old
> > 
> > 
> > 
> 
> 
>  
> 

Re: [VOTE] Release Apache Sling Service User Mapper 1.3.0

[Carsten Ziegeler]

Oliver Lietz wrote
> On Saturday 08 April 2017 14:44:55 Carsten Ziegeler wrote:
>> Oliver Lietz wrote
>>
>>> On Thursday 06 April 2017 21:59:34 Julian Sedding wrote:
 The configuration property "user.default.mapping" should be called "
 use.default.mapping", or maybe rather "default.mapping.enabled" to avoid
 typos and confusion.
>>>
>>> We already messed up property names in component configurations (incl.
>>> typos), but as Julian opened that topic here are my € 0.02: use dots to
>>> create a (hierarchical) structure and camel case or snake case to
>>> compound separate words – like logging configs in any application, e.g.
>>> Tomcat
>>> https://tomcat.apache.org/tomcat-8.0-doc/logging.html (->
>>> useDefaultMapping or default_mapping_enabled)
>>
>> Avoid camel casing :) With the new component property types of R7 camel
>> casing can cause in some cases a little bit of trouble. We ran into this
>> while defining annotations for the http whiteboard which unfortunately
>> in some cases uses camel casing.
> 
> Really? Can you point me to an example or elaborate on the issues? I would 
> have expected minor issues with snake case due to dot to underscore mapping 
> but none with camel case.
> 
It's not a major issue - everything works, but R7 allows you to define
component property type annotations. These are the equivalent to the
@SlingServlet annotation we had in our SCR annotations. So basically you
can define your own annotation being used by other component developers
to add properties. This works with camel casing.

However, you can also define a single value annotation which has
slightly different key name mapping rules. For example, if you have the
property "servlet.asyncSupported" you can write such an annotation ASync
having a field like:

boolean servlet_asyncSupported();

and then use it to annotate your component

 @Async(servlet_asyncSupported = true)

Now, you can convert the above into a single value annotation:

boolean value();

so you could do:

@Async(true)

However in this case the information about the property name is lost and
then the class name is used. And in this case camel casing is used to
insert dots, so an annotation name of @AsyncSupported results in the
property being named "async.supported".

I hope this makes it a little bit clear. So in short camel case is no
problem, but it might create some annoyance down the road. Avoiding it
in the first place is imho a good thing.

Now, if you want to further discuss how these things work in R7, please
let's move this off the Sling dev list.

Regards

Carsten

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

Re: [VOTE] Release Apache Sling Service User Mapper 1.3.0

[Oliver Lietz]

On Saturday 08 April 2017 14:44:55 Carsten Ziegeler wrote:
> Oliver Lietz wrote
> 
> > On Thursday 06 April 2017 21:59:34 Julian Sedding wrote:
> >> The configuration property "user.default.mapping" should be called "
> >> use.default.mapping", or maybe rather "default.mapping.enabled" to avoid
> >> typos and confusion.
> > 
> > We already messed up property names in component configurations (incl.
> > typos), but as Julian opened that topic here are my € 0.02: use dots to
> > create a (hierarchical) structure and camel case or snake case to
> > compound separate words – like logging configs in any application, e.g.
> > Tomcat
> > https://tomcat.apache.org/tomcat-8.0-doc/logging.html (->
> > useDefaultMapping or default_mapping_enabled)
> 
> Avoid camel casing :) With the new component property types of R7 camel
> casing can cause in some cases a little bit of trouble. We ran into this
> while defining annotations for the http whiteboard which unfortunately
> in some cases uses camel casing.

Really? Can you point me to an example or elaborate on the issues? I would 
have expected minor issues with snake case due to dot to underscore mapping 
but none with camel case.

Thanks,
O.

> Regards
> Carsten

[Jenkins] Job list needs to be updated [was Re: Build failed in Jenkins: sling-bundles-extensions-event-1.7 #19]

[Carsten Ziegeler]

Hi

it seems the job list on Jenkins is referencing the old Sling Event
source which has changed recently (split up of api and impl).
Could someone please update the jobs on Jenkins accordingly?

Thanks
Carsten

Apache Jenkins Server wrote
> See 
> 
> 
> Changes:
> 
> [cziegeler] SLING-6739 : split of sling.event to sling.event.resource (and 
> api). Use old project name / bundle symbolic name and version for 
> compatibility
> 
> --
> Started by an SCM change
> [EnvInject] - Loading node environment variables.
> Building remotely on ubuntu-1 (ubuntu trusty) in workspace 
> 
> Updating 
> https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/event at 
> revision '2017-04-10T06:05:07.174 +'
> U resource/pom.xml
> U api/pom.xml
> U api/README.md
> At revision 1790781
> 
> Parsing POMs
> ERROR: No such file 
> 
> Perhaps you need to specify the correct POM file path in the project 
> configuration?
> Recording test results
> ERROR: Step ?Publish JUnit test result report? failed: Test reports were 
> found but none of them are new. Did tests run? 
> For example, 
> 
>  is 25 days old
> 
> 
> 


 

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

Re: Wiki access

[Carsten Ziegeler]

Hi,

it seems we have a lot of admins for that space, and I'm one of them :)
So I added your id and gave you appropriate permissions to work on that
wiki.

Regards
Carsten

Konrad Windszus wrote
> Hi, according to http://sling.apache.org/documentation.html#the-public-wiki 
> the wiki is open for self-registration (which is true) and automatically 
> grants everyone write/edit access (which is obviously not true). I see that 
> the root page is write-restricted to the group sling-committers. How do I 
> become member of that group? My Confluence username is "kwin".
> 
> The only documentation I found at Apache is 
> https://cwiki.apache.org/confluence/display/INFRA/Cwiki which does not say 
> anything about how the group memberships are managed, so I assume that this 
> is done on the project level. Who is currently wiki space admin for 
> https://cwiki.apache.org/confluence/display/SLING/?
> 
> Thanks,
> Konrad
> 


 

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