[jira] [Resolved] (SLING-6721) Migrate to R6 annotations, clean up dependencies

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-6721.
-
Resolution: Fixed

Migrated in rev 1789274

> Migrate to R6 annotations, clean up dependencies
> 
>
> Key: SLING-6721
> URL: https://issues.apache.org/jira/browse/SLING-6721
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Servlets Post 2.3.16
>
>




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

[jira] [Assigned] (SLING-6721) Migrate to R6 annotations, clean up dependencies

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler reassigned SLING-6721:
---

Assignee: Carsten Ziegeler

> Migrate to R6 annotations, clean up dependencies
> 
>
> Key: SLING-6721
> URL: https://issues.apache.org/jira/browse/SLING-6721
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Servlets Post 2.3.16
>
>




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

[jira] [Updated] (SLING-6742) Servlets post is broken with parent 30

[Karl Pauls (JIRA)]

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

Karl Pauls updated SLING-6742:
--
Component/s: Servlets

> Servlets post is broken with parent 30
> --
>
> Key: SLING-6742
> URL: https://issues.apache.org/jira/browse/SLING-6742
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Reporter: Karl Pauls
>
> The issue is that the maven-scr-plugin doesn't get configured with sling 30. 
> That makes it so that the service component xml files don't get generated 
> properly. 
> I switched to sling 29 for now. 



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

[jira] [Commented] (SLING-6679) Replace usage of org.apache.sling.commons.json.* and org.json

[Karl Pauls (JIRA)]

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

Karl Pauls commented on SLING-6679:
---

I did some more clean-up and resolved all the sub-issues. Please reopen if one 
needs more work. Otherwise, I'll wait a little and then start to release the 
affected bundles. 

I'll keep this issue open until we have all the bundles released.

> Replace usage of org.apache.sling.commons.json.* and org.json
> -
>
> Key: SLING-6679
> URL: https://issues.apache.org/jira/browse/SLING-6679
> Project: Sling
>  Issue Type: Improvement
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>
> Following the deprecation of org.apache.sling.commons.json (SLING-6536) we 
> need to replace its usage everywhere else (at least if we want to be able to 
> release other modules that depend on it). 
> This is the umbrella issue for getting this done. The idea is to create 
> sub-issues with patches for individual components, review the patches, and 
> when all are done: close this issue. 
> General discussions and problems should go to this issue and specific ones on 
> the sub-issue in question.



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

[jira] [Resolved] (SLING-6700) Implement johnzon bundle

[Karl Pauls (JIRA)]

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

Karl Pauls resolved SLING-6700.
---
Resolution: Fixed

Done. See SLING-6679 for more.

> Implement johnzon bundle
> 
>
> Key: SLING-6700
> URL: https://issues.apache.org/jira/browse/SLING-6700
> Project: Sling
>  Issue Type: Sub-task
>  Components: Commons
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>
> We might need our own johnzon bundle until we have a working replacement form 
> the official versions. 
> For now, I'll add a new org.apache.sling.commons.johnzon bundle in commons.



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

[jira] [Resolved] (SLING-6713) Remove commons.json and org.json from launchpad

[Karl Pauls (JIRA)]

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

Karl Pauls resolved SLING-6713.
---
Resolution: Fixed

Done. See SLING-6679 for more.

> Remove commons.json and org.json from launchpad
> ---
>
> Key: SLING-6713
> URL: https://issues.apache.org/jira/browse/SLING-6713
> Project: Sling
>  Issue Type: Sub-task
>  Components: Launchpad
>Reporter: Karl Pauls
>Assignee: Karl Pauls
> Attachments: SLING-6713.patch
>
>
> We need to remove commons.json from the launchpad provisioning, add the 
> commons.johnzon bundle, and update all bundles after we switched them to 
> johnzon. 
> Furthermore, we need to make sure it still works :-)



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

[jira] [Resolved] (SLING-6694) Replace commons.json usage in org.apache.sling.jcr.contentloader

[Karl Pauls (JIRA)]

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

Karl Pauls resolved SLING-6694.
---
Resolution: Fixed

Done. See SLING-6679 for more.

> Replace commons.json usage in org.apache.sling.jcr.contentloader
> 
>
> Key: SLING-6694
> URL: https://issues.apache.org/jira/browse/SLING-6694
> Project: Sling
>  Issue Type: Sub-task
>  Components: JCR
>Affects Versions: JCR ContentLoader 2.1.10
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>  Labels: patch-available
> Fix For: JCR ContentLoader 2.2.0
>
> Attachments: SLING-6694-2.patch, SLING-6694.patch
>
>




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

[jira] [Resolved] (SLING-6712) Update sightly engine to latest xss

[Karl Pauls (JIRA)]

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

Karl Pauls resolved SLING-6712.
---
Resolution: Fixed

Done. See SLING-6679 for more.

> Update sightly engine to latest xss
> ---
>
> Key: SLING-6712
> URL: https://issues.apache.org/jira/browse/SLING-6712
> Project: Sling
>  Issue Type: Sub-task
>  Components: Scripting
>Affects Versions: Scripting HTL Engine 1.0.32
>Reporter: Karl Pauls
>Assignee: Karl Pauls
> Fix For: Scripting HTL Engine 1.0.34
>
> Attachments: SLING-6712.patch
>
>
> The engine depends on xss which has a version jump in the api to 2.0.0 if the 
> johnzon patch is applied.



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

[jira] [Resolved] (SLING-6691) Replace commons.json usage in org.apache.sling.discovery.impl

[Karl Pauls (JIRA)]

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

Karl Pauls resolved SLING-6691.
---
Resolution: Fixed

Done. See SLING-6679 for more.

> Replace commons.json usage in org.apache.sling.discovery.impl
> -
>
> Key: SLING-6691
> URL: https://issues.apache.org/jira/browse/SLING-6691
> Project: Sling
>  Issue Type: Sub-task
>  Components: Extensions
>Affects Versions: Discovery Impl 1.2.8
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>  Labels: patch-available
> Fix For: Discovery Impl 1.2.12
>
> Attachments: SLING-6691.patch
>
>




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

[jira] [Resolved] (SLING-6693) Replace commons.json usage in org.apache.sling.hc.core

[Karl Pauls (JIRA)]

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

Karl Pauls resolved SLING-6693.
---
Resolution: Fixed

Done. See SLING-6679 for more.

> Replace commons.json usage in org.apache.sling.hc.core
> --
>
> Key: SLING-6693
> URL: https://issues.apache.org/jira/browse/SLING-6693
> Project: Sling
>  Issue Type: Sub-task
>  Components: Health Check
>Affects Versions: Health Check Core 1.2.6
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>  Labels: patch-available
> Fix For: Health Check Core 1.2.8
>
> Attachments: SLING-6693.patch
>
>




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

[jira] [Resolved] (SLING-6692) Replace commons.json usage in org.apache.sling.discovery.oak

[Karl Pauls (JIRA)]

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

Karl Pauls resolved SLING-6692.
---
Resolution: Fixed

Done. See SLING-6679 for more.

> Replace commons.json usage in org.apache.sling.discovery.oak
> 
>
> Key: SLING-6692
> URL: https://issues.apache.org/jira/browse/SLING-6692
> Project: Sling
>  Issue Type: Sub-task
>  Components: Extensions
>Affects Versions: Discovery Oak 1.2.10
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>  Labels: patch-available
> Fix For: Discovery Oak 1.2.18
>
> Attachments: SLING-6692.patch
>
>




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

[jira] [Resolved] (SLING-6689) Replace commons.json usage in org.apache.sling.discovery.base

[Karl Pauls (JIRA)]

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

Karl Pauls resolved SLING-6689.
---
Resolution: Fixed

Done. See SLING-6679 for more.

> Replace commons.json usage in org.apache.sling.discovery.base
> -
>
> Key: SLING-6689
> URL: https://issues.apache.org/jira/browse/SLING-6689
> Project: Sling
>  Issue Type: Sub-task
>  Components: Extensions
>Affects Versions: Discovery Base 1.1.2
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>  Labels: patch-available
> Fix For: Discovery Base 1.1.4
>
> Attachments: SLING-6689.patch
>
>




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

[jira] [Resolved] (SLING-6690) Replace commons.json usage in org.apache.sling.discovery.commons

[Karl Pauls (JIRA)]

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

Karl Pauls resolved SLING-6690.
---
Resolution: Fixed

Done. See SLING-6679 for more.

> Replace commons.json usage in org.apache.sling.discovery.commons
> 
>
> Key: SLING-6690
> URL: https://issues.apache.org/jira/browse/SLING-6690
> Project: Sling
>  Issue Type: Sub-task
>  Components: Extensions
>Affects Versions: Discovery Commons 1.0.12
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>  Labels: patch-available
> Fix For: Discovery Commons 1.0.20
>
> Attachments: SLING-6690.patch
>
>




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

[jira] [Reopened] (SLING-6687) Replace commons.json usage in org.apache.sling.adapter

[Karl Pauls (JIRA)]

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

Karl Pauls reopened SLING-6687:
---
  Assignee: Karl Pauls  (was: Carsten Ziegeler)

We want to switch to the geronimo provider for the build time dependency on 
javax.json

> Replace commons.json usage in org.apache.sling.adapter
> --
>
> Key: SLING-6687
> URL: https://issues.apache.org/jira/browse/SLING-6687
> Project: Sling
>  Issue Type: Sub-task
>  Components: Extensions
>Affects Versions: Adapter 2.1.8
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>  Labels: patch-available
> Fix For: Adapter 2.1.10
>
> Attachments: SLING-6687.patch
>
>




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

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

Karl Pauls resolved SLING-6685.
---
Resolution: Fixed

Done. See SLING-6679 for more.

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

[jira] [Resolved] (SLING-6687) Replace commons.json usage in org.apache.sling.adapter

[Karl Pauls (JIRA)]

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

Karl Pauls resolved SLING-6687.
---
Resolution: Fixed

Done. See SLING-6679 for more.

> Replace commons.json usage in org.apache.sling.adapter
> --
>
> Key: SLING-6687
> URL: https://issues.apache.org/jira/browse/SLING-6687
> Project: Sling
>  Issue Type: Sub-task
>  Components: Extensions
>Affects Versions: Adapter 2.1.8
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>  Labels: patch-available
> Fix For: Adapter 2.1.10
>
> Attachments: SLING-6687.patch
>
>




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

[jira] [Resolved] (SLING-6684) Replace commons.json usage in org.apache.sling.jcr.jackrabbit.accessmanager

[Karl Pauls (JIRA)]

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

Karl Pauls resolved SLING-6684.
---
Resolution: Fixed

Done. See SLING-6679 for more.

> Replace commons.json usage in org.apache.sling.jcr.jackrabbit.accessmanager
> ---
>
> Key: SLING-6684
> URL: https://issues.apache.org/jira/browse/SLING-6684
> Project: Sling
>  Issue Type: Sub-task
>  Components: JCR
>Affects Versions: JCR Jackrabbit Access Manager 2.1.2
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>  Labels: patch-available
> Fix For: JCR Jackrabbit Access Manager 2.1.4
>
> Attachments: SLING-6684-2.patch, SLING-6684.patch
>
>
> This bundle has no tests so it is hard to say if stuff works. 



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

[jira] [Resolved] (SLING-6683) Replace commons.json usage in org.apache.sling.servlets.get

[Karl Pauls (JIRA)]

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

Karl Pauls resolved SLING-6683.
---
Resolution: Fixed

Done. See SLING-6679 for more.

> Replace commons.json usage in org.apache.sling.servlets.get
> ---
>
> Key: SLING-6683
> URL: https://issues.apache.org/jira/browse/SLING-6683
> Project: Sling
>  Issue Type: Sub-task
>  Components: Servlets
>Affects Versions: Servlets Get 2.1.20
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>  Labels: patch-available
> Fix For: Servlets Get 2.1.24
>
> Attachments: SLING-6683-2.patch, SLING-6683.patch
>
>
> We need to replace the usage of commons.json but this one does heavy rely on 
> some of the helper classes. Its going to be tricky to make sure it still 
> works as intended.



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

[jira] [Resolved] (SLING-6681) Replace commons.json usage in org.apache.sling.servlets.post

[Karl Pauls (JIRA)]

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

Karl Pauls resolved SLING-6681.
---
Resolution: Fixed

Done. See SLING-6679 for more.

> Replace commons.json usage in org.apache.sling.servlets.post
> 
>
> Key: SLING-6681
> URL: https://issues.apache.org/jira/browse/SLING-6681
> Project: Sling
>  Issue Type: Sub-task
>  Components: Servlets
>Affects Versions: Servlets Post 2.3.14
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>  Labels: patch-available
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6681-2.patch, SLING-6681.patch
>
>




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

[jira] [Resolved] (SLING-6682) Replace commons.json usage in org.apache.sling.scripting.javascript

[Karl Pauls (JIRA)]

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

Karl Pauls resolved SLING-6682.
---
Resolution: Fixed

Done. See SLING-6679 for more.

> Replace commons.json usage in org.apache.sling.scripting.javascript
> ---
>
> Key: SLING-6682
> URL: https://issues.apache.org/jira/browse/SLING-6682
> Project: Sling
>  Issue Type: Sub-task
>  Components: Scripting
>Affects Versions: Scripting JavaScript 2.0.30
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>  Labels: patch-available
> Fix For: Scripting JavaScript 2.0.32
>
> Attachments: SLING-6682.patch
>
>




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

[jira] [Created] (SLING-6742) Servlets post is broken with parent 30

[Karl Pauls (JIRA)]

Karl Pauls created SLING-6742:
-

 Summary: Servlets post is broken with parent 30
 Key: SLING-6742
 URL: https://issues.apache.org/jira/browse/SLING-6742
 Project: Sling
  Issue Type: Bug
Reporter: Karl Pauls


The issue is that the maven-scr-plugin doesn't get configured with sling 30. 
That makes it so that the service component xml files don't get generated 
properly. 

I switched to sling 29 for now. 



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

[jira] [Commented] (SLING-6741) i18n build fails with "ServiceLookup gave up" during tests

[Karl Pauls (JIRA)]

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

Karl Pauls commented on SLING-6741:
---

I switched the parent to 29 in r1789245 for now.

> i18n build fails with "ServiceLookup gave up" during tests
> --
>
> Key: SLING-6741
> URL: https://issues.apache.org/jira/browse/SLING-6741
> Project: Sling
>  Issue Type: Bug
>  Components: i18n
>Reporter: Karl Pauls
>
> The build works fine when switching to sling parent 29.



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

[jira] [Created] (SLING-6741) i18n build fails with "ServiceLookup gave up" during tests

[Karl Pauls (JIRA)]

Karl Pauls created SLING-6741:
-

 Summary: i18n build fails with "ServiceLookup gave up" during tests
 Key: SLING-6741
 URL: https://issues.apache.org/jira/browse/SLING-6741
 Project: Sling
  Issue Type: Bug
  Components: i18n
Reporter: Karl Pauls


The build works fine when switching to sling parent 29.



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

[jira] [Updated] (SLING-6737) Migrate to OSGi R6 annotations

[Oliver Lietz (JIRA)]

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

Oliver Lietz updated SLING-6737:

Fix Version/s: Scripting Core 2.0.48

> Migrate to OSGi R6 annotations
> --
>
> Key: SLING-6737
> URL: https://issues.apache.org/jira/browse/SLING-6737
> Project: Sling
>  Issue Type: Task
>  Components: Scripting
>Affects Versions: Scripting Core 2.0.46
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Scripting Core 2.0.48
>
>




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

[jira] [Resolved] (SLING-6737) Migrate to OSGi R6 annotations

[Oliver Lietz (JIRA)]

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

Oliver Lietz resolved SLING-6737.
-
Resolution: Done

> Migrate to OSGi R6 annotations
> --
>
> Key: SLING-6737
> URL: https://issues.apache.org/jira/browse/SLING-6737
> Project: Sling
>  Issue Type: Task
>  Components: Scripting
>Affects Versions: Scripting Core 2.0.46
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Scripting Core 2.0.48
>
>




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

[jira] [Comment Edited] (SLING-6737) Migrate to OSGi R6 annotations

[Oliver Lietz (JIRA)]

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

Oliver Lietz edited comment on SLING-6737 at 3/28/17 7:00 PM:
--

[r1789102|https://svn.apache.org/r1789102]
[r1789107|https://svn.apache.org/r1789107]
[r1789131|https://svn.apache.org/r1789131]


was (Author: olli):
[r1789102|https://svn.apache.org/r1789102]

> Migrate to OSGi R6 annotations
> --
>
> Key: SLING-6737
> URL: https://issues.apache.org/jira/browse/SLING-6737
> Project: Sling
>  Issue Type: Task
>  Components: Scripting
>Affects Versions: Scripting Core 2.0.46
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>




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

[jira] [Updated] (SLING-6724) Scripting core build fails with "ServiceLookup gave up" during tests

[Oliver Lietz (JIRA)]

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

Oliver Lietz updated SLING-6724:

Fix Version/s: Scripting Core 2.0.48

> Scripting core build fails with "ServiceLookup gave up" during tests
> 
>
> Key: SLING-6724
> URL: https://issues.apache.org/jira/browse/SLING-6724
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Reporter: Karl Pauls
>Assignee: Oliver Lietz
> Fix For: Scripting Core 2.0.48
>
>
> Doing:
> {noformat}
> cd bundles/scripting/core
> mvn clean install
> {noformat}
> fails with test errors.



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

[jira] [Resolved] (SLING-6724) Scripting core build fails with "ServiceLookup gave up" during tests

[Oliver Lietz (JIRA)]

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

Oliver Lietz resolved SLING-6724.
-
Resolution: Fixed

build is back to stable

> Scripting core build fails with "ServiceLookup gave up" during tests
> 
>
> Key: SLING-6724
> URL: https://issues.apache.org/jira/browse/SLING-6724
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Reporter: Karl Pauls
>Assignee: Oliver Lietz
> Fix For: Scripting Core 2.0.48
>
>
> Doing:
> {noformat}
> cd bundles/scripting/core
> mvn clean install
> {noformat}
> fails with test errors.



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

[jira] [Created] (SLING-6740) HTL Blog Sample

[Chris Millar (JIRA)]

Chris Millar created SLING-6740:
---

 Summary: HTL Blog Sample
 Key: SLING-6740
 URL: https://issues.apache.org/jira/browse/SLING-6740
 Project: Sling
  Issue Type: Improvement
Reporter: Chris Millar
Priority: Minor


The ESP blog sample is a little long in tooth. It should either be updated or 
replaced by an HTL blog sample.



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

Re: [RT] Configurationless Sling?

[Oliver Lietz]

On Tuesday 28 March 2017 14:59:04 Carsten Ziegeler wrote:
> Oliver Lietz wrote
> 
> > On Monday 27 March 2017 16:02:50 Carsten Ziegeler wrote:
> >> Hi,
> > 
> > Hi,
> > 
> >> for a long time we have tried to use sensible defaults for all of our
> >> configurations. This allows our users to run a default Sling without any
> >> additional configuration (it should even be possible to run it without a
> >> Configuration Admin service available - but that's another story).
> >> 
> >> While we were pretty successful with this, we simply blew it with the
> >> move from login administrative to service users. A lot of the (core)
> >> modules now use service users and these require a configured mapping in
> >> order to work properly. While for example the servlets resolver
> >> previously did not require any configuration, it requires at least the
> >> mapping. Which in turn means you can't simply use that module as-is.
> >> 
> >> Switching to service users is of course a good idea but I'm wondering if
> >> we can find a way to get back to a configurationless Sling again?
> >> 
> >> Clearly we don't want to the mapping to be part of the bundles using the
> >> service users.
> >> 
> >> One possible solution would be an out of the box bundle with the
> >> necessary repo init and configurations. This would cover the core
> >> bundles like servlets resolver and resource resolver.
> > 
> > we already have artifacts for all repoinit statements (bundle) and
> > configurations.
> > 
> > I had to externalize all configurations for Karaf as features only support
> > the simple cfg format inline (but Sling and Oak require newer Config
> > Admin format):
> > 
> > https://github.com/apache/sling/tree/trunk/karaf/org.apache.sling.karaf-co
> > nfigs/src/main/resources
> Interesting. Now, I know we have talked about it and no one had time for
> this so far, but that should really be described through a provisioning
> model and then we generate the karaf feature or whatever is needed out
> of it.
> 
> > That said, Sling is one half only. The other half is Oak.
> > 
> > Configurations are part of a feature which get installed together with its
> > bundles (and features) when using Sling's Karaf features.
> > 
> > The missing piece for repoinit (to make statements part of a feature) is a
> > component which can be feed with "fragments" - similar to what we have for
> > service user mappings and "login administrative" white listings (it's on
> > my
> > TODO). Currently all repoinit statements are executed when installing a
> > sling- launchpad-oak-* feature.
> > 
> > https://github.com/apache/sling/tree/trunk/karaf/org.apache.sling.karaf-re
> > poinit/src/main/resources
> I'm not quiet sure how this work in practice, How do these get installed
> at runtime in a Karaf environment.
> 
> 
> Now, basically this is a similar idea to what I had. We describe this
> stuff as a separate artifact (or more than one) and somehow it gets
> installed.
> 
> It would be good if we have this description only once in our code base
> and not several times and can then generate different artifacts (if
> needed) out of it.

Right, but I'm pretty sure I raised my concerns generating Karaf Features and 
Configurations (and repoinit statements) from provisioning model already.

* Launchpad is _unstable_ most of the time (using snapshots mostly) while 
Karaf Features are _stable_ (only a few snapshots left). Launchpad is in fact 
the test bed for AEM, but Sling Karaf aims at good user experience and 
production readiness.

* There are much more and finer grained features in Karaf than in Launchpad.

* Every (Karaf) feature is backed by an integration test.

* Testing PaxExam's options and versions are already generated from (Karaf) 
features.

* The provisioning model does not support dependencies (yet).

I guess it takes only a few hours to create templates for generating 
provisioning models from (Karaf) features and a few more to split into 
separate files, but I'm more interested in filling the missing piece regarding 
repoinit (and creating immutable/static instances from features with Karaf 
Profiles).

Currently all repoinit statements from karaf-repoinit are executed when 
installing feature sling-oak-tar:

https://github.com/apache/sling/blob/trunk/karaf/org.apache.sling.karaf-features/src/main/feature/feature.xml#L387

https://github.com/apache/sling/blob/trunk/karaf/org.apache.sling.karaf-configs/src/main/resources/org.apache.sling.jcr.repoinit.impl.RepositoryInitializer.config

references=[\
  "raw:classpath://org.apache.sling.karaf-repoinit/sling.txt",\
  "raw:classpath://org.apache.sling.karaf-repoinit/sling-discovery.txt",\
  "raw:classpath://org.apache.sling.karaf-repoinit/sling-event.txt",\
  "raw:classpath://org.apache.sling.karaf-repoinit/sling-i18n.txt",\
  "raw:classpath://org.apache.sling.karaf-repoinit/sling-installer-jcr.txt",\
  "raw:classpath://org.apache.sling.karaf-repoinit/sling-scripting.txt",\
  

Re: Sling Eclipse Tooling and OSGi Bundle Content

[Andreas Schaefer Sr.]

Ahh, stupid me.

That also means that there is no way to edit a single file and have this 
deployed to
Sling / AEM without the entire package.

Thanks - Andy

BTW as an Eclipse newbie how do I deploy an OSGi Bundle to Sling?

> On Mar 28, 2017, at 3:32 AM, Robert Munteanu  wrote:
> 
> Hi Andy,
> 
> On Mon, 2017-03-27 at 10:51 -0700, Andreas Schaefer Sr. wrote:
>> Hi
>> 
>> I am wondering if the current Eclipse Tooling supports OSGi Bundle
>> Content (through Sling-Initial-Content)?
>> 
>> If not are the any places to support them in the future?
> 
> The bundle deployment should work since the initial content is
> processed based on some manifest headers and the resources from
> target/classes.
> 
> Robert

Re: [event] splitting sling.event into API and Implementation bundle

[Carsten Ziegeler]

Stefan Egli wrote
> Nice, will try that.
> 
> An alternative structure would be
> 
> bundles/extensions/event/api
> bundles/extensions/event/impl
> 
> I'd almost prefer this one as it would other patterns we already have.
> 
> If someone has a better name for 'event-impl' or 'event/impl' pls bring it
> forward. I remember the name choice for 'discovery.impl' wasn't that well
> received :)
> 
What about event.resource ? Its an implementation based on the resource api

Or event.resource.impl :)

 Carsten

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

Re: [event] splitting sling.event into API and Implementation bundle

[Daniel Klco]

+1 agree with the structure:

bundles/extensions/event/api
bundles/extensions/event/impl

On Tue, Mar 28, 2017 at 12:03 PM, Stefan Egli  wrote:

> Nice, will try that.
>
> An alternative structure would be
>
> bundles/extensions/event/api
> bundles/extensions/event/impl
>
> I'd almost prefer this one as it would other patterns we already have.
>
> If someone has a better name for 'event-impl' or 'event/impl' pls bring it
> forward. I remember the name choice for 'discovery.impl' wasn't that well
> received :)
>
> Cheers,
> Stefan
>
> On 28/03/17 17:29, "Carsten Ziegeler"  wrote:
>
> >+1
> >
> >The event-impl could embed the event-api bundle (like for example is be
> >done with implementations of the OSGi specs). With that a newer version
> >of event-impl would be a drop in replacement for older versions.
> >
> >And other implementations could do the same.
> >
> >Regards
> >Carsten
> >
> >Stefan Egli wrote
> >> Hi,
> >>
> >> Currently sling.event contains both API and implementation. In order to
> >> support different implementation variants it would be good to have two
> >> separate bundles, one containing just the API and one with the (current)
> >> implementation. I would suggest to create
> >>
> >> bundles/extensions/event-api
> >> bundles/extensions/event-impl
> >>
> >> and to remove the current
> >>
> >> bundles/extensions/event
> >>
> >> Since the api packages contain a package-info.java this change should
> >>not
> >> involve any version-change/backwards incompatibility.
> >>
> >> Opinions?
> >>
> >> Cheers,
> >> Stefan
> >> --
> >> https://issues.apache.org/jira/browse/SLING-6739
> >>
> >>
> >>
> >
> >
> >
> >
> >--
> >Carsten Ziegeler
> >Adobe Research Switzerland
> >cziege...@apache.org
>
>
>

Re: [event] splitting sling.event into API and Implementation bundle

[Stefan Egli]

Nice, will try that.

An alternative structure would be

bundles/extensions/event/api
bundles/extensions/event/impl

I'd almost prefer this one as it would other patterns we already have.

If someone has a better name for 'event-impl' or 'event/impl' pls bring it
forward. I remember the name choice for 'discovery.impl' wasn't that well
received :)

Cheers,
Stefan

On 28/03/17 17:29, "Carsten Ziegeler"  wrote:

>+1
>
>The event-impl could embed the event-api bundle (like for example is be
>done with implementations of the OSGi specs). With that a newer version
>of event-impl would be a drop in replacement for older versions.
>
>And other implementations could do the same.
>
>Regards
>Carsten
>
>Stefan Egli wrote
>> Hi,
>> 
>> Currently sling.event contains both API and implementation. In order to
>> support different implementation variants it would be good to have two
>> separate bundles, one containing just the API and one with the (current)
>> implementation. I would suggest to create
>> 
>> bundles/extensions/event-api
>> bundles/extensions/event-impl
>> 
>> and to remove the current
>> 
>> bundles/extensions/event
>> 
>> Since the api packages contain a package-info.java this change should
>>not
>> involve any version-change/backwards incompatibility.
>> 
>> Opinions?
>> 
>> Cheers,
>> Stefan
>> --
>> https://issues.apache.org/jira/browse/SLING-6739
>> 
>> 
>> 
>
>
> 
>
>-- 
>Carsten Ziegeler
>Adobe Research Switzerland
>cziege...@apache.org

Re: [event] splitting sling.event into API and Implementation bundle

[Carsten Ziegeler]

+1

The event-impl could embed the event-api bundle (like for example is be
done with implementations of the OSGi specs). With that a newer version
of event-impl would be a drop in replacement for older versions.

And other implementations could do the same.

Regards
Carsten

Stefan Egli wrote
> Hi,
> 
> Currently sling.event contains both API and implementation. In order to
> support different implementation variants it would be good to have two
> separate bundles, one containing just the API and one with the (current)
> implementation. I would suggest to create
> 
> bundles/extensions/event-api
> bundles/extensions/event-impl
> 
> and to remove the current
> 
> bundles/extensions/event
> 
> Since the api packages contain a package-info.java this change should not
> involve any version-change/backwards incompatibility.
> 
> Opinions?
> 
> Cheers,
> Stefan
> --
> https://issues.apache.org/jira/browse/SLING-6739
> 
> 
> 


 

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

[event] splitting sling.event into API and Implementation bundle

[Stefan Egli]

Hi,

Currently sling.event contains both API and implementation. In order to
support different implementation variants it would be good to have two
separate bundles, one containing just the API and one with the (current)
implementation. I would suggest to create

bundles/extensions/event-api
bundles/extensions/event-impl

and to remove the current

bundles/extensions/event

Since the api packages contain a package-info.java this change should not
involve any version-change/backwards incompatibility.

Opinions?

Cheers,
Stefan
--
https://issues.apache.org/jira/browse/SLING-6739

[jira] [Created] (SLING-6739) split sling.event into event.api and event.impl

[Stefan Egli (JIRA)]

Stefan Egli created SLING-6739:
--

 Summary: split sling.event into event.api and event.impl
 Key: SLING-6739
 URL: https://issues.apache.org/jira/browse/SLING-6739
 Project: Sling
  Issue Type: Task
  Components: Extensions
Affects Versions: Event 4.2.2
Reporter: Stefan Egli
Assignee: Stefan Egli


Currently sling.event contains both API and implementation. In order to support 
different implementation variants it would be good to have two separate 
bundles, one containing just the API and one with the (current) implementation. 
I would suggest to create

bundles/extensions/event-api
bundles/extensions/event-impl

and to remove the current

bundles/extensions/event



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

Re: [VOTE] Release Apache Sling CAConfig Impl 1.3.2

[Daniel Klco]

+1 checked signatures and build

On Tue, Mar 28, 2017 at 1:42 AM, Carsten Ziegeler 
wrote:

> +1
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

[jira] [Commented] (SLING-2662) Enhance run mode handling

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-2662:


Updated doc in [r1789103|https://svn.apache.org/r1789103].

> Enhance run mode handling
> -
>
> Key: SLING-2662
> URL: https://issues.apache.org/jira/browse/SLING-2662
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Settings 1.1.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Settings 1.2.0
>
>
> Often there is a need to provide different features where the user might have 
> the ability to choose whether a feature should be installed or not.
> This can easily be done with a run mode, so a feature is put into a run mode, 
> and if the run mode is activated by the user, the feature is installed.
> However, there are cases where two features might be concurrent, so either 
> feature A or feature B should be installed. Still run modes can be used by 
> defining two run modes A and B - but in this case if the user does not choose 
> one of the run modes, nothing is installed - or if the user selects both run 
> modes, both are installed.
> We could support such use cases with some configuration properties for the 
> settings service:
> a) we define a property which contains run modes that are usually always 
> active
> b) in addition, we define a property which contains whether a run mode is 
> active unless another run mode is active.
> So for the above use case, we define run mode A as always active and also set 
> the second property to define that A is not active once B is activated by the 
> user
> We could also define a third property which contains a set of run modes that 
> are only choosable on the first startup of the installation, so in the in the 
> example above, if this property is defined for A and B, the user selection of 
> the first startup is preserved



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

Re: [RT] Configurationless Sling?

[Tommaso Teofili]

Il giorno mar 28 mar 2017 alle ore 15:13 Bertrand Delacretaz <
bdelacre...@apache.org> ha scritto:

> On Tue, Mar 28, 2017 at 3:01 PM, Carsten Ziegeler 
> wrote:
> > Julian Sedding wrote
> >>... As a convention for service users, would it make sense to use the
> >> bundle-symbolic-name as the user-ID (or principal-name)?...
>
> > ...We could use the bundle
> > symbolic name and the sub service information. That should be enough. We
> > don't need the class name
>
> +1 and we might prefix this with bundle_ or b_ to make it clear where
> these usernames come from?
>
> I suppose in the vast majority of cases there's one service user per
> bundle, so that would remove a lot of boring configurations.
>

+1

Tommaso


>
> -Bertrand
>

[jira] [Commented] (SLING-6703) Sling Post Servlet: Do not hide original exception in AbstractPostResponse.setError

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6703:


I would have assumed that the Sling Post Servlet never used the administrative 
resource resolver for performing any operations but always relied on the 
request's resource resolver. Anyhow, I think now nothing sensitive is exposed 
and we leverage again the full verbosity of exceptions.

> Sling Post Servlet: Do not hide original exception in 
> AbstractPostResponse.setError
> ---
>
> Key: SLING-6703
> URL: https://issues.apache.org/jira/browse/SLING-6703
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Affects Versions: Servlets Post 2.3.14
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Servlets Post 2.3.16
>
>
> Currently {{AbstractPostResponse.setError}} 
> (https://github.com/apache/sling/blob/4df9ab2d6592422889c71fa13afd453a10a5a626/bundles/servlets/post/src/main/java/org/apache/sling/servlets/post/AbstractPostResponse.java#L221)
>  always ignores the given {{Throwable}} and just creates a new generic 
> {{SlingException}}.
> To e.g. allow {{SlingPostProcessor}} to throw meaningful exceptions which 
> occur in the response body, the given exception should not be wrapped but 
> just the given throwable's message text should be given out in the document.



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

[jira] [Commented] (SLING-6703) Sling Post Servlet: Do not hide original exception in AbstractPostResponse.setError

[Antonio Sanso (JIRA)]

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

Antonio Sanso commented on SLING-6703:
--

[~kwin] just guessing, the fact that you do not see anymore this issue might be 
a direct consequence of the loginAdministrative refactor done lately

> Sling Post Servlet: Do not hide original exception in 
> AbstractPostResponse.setError
> ---
>
> Key: SLING-6703
> URL: https://issues.apache.org/jira/browse/SLING-6703
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Affects Versions: Servlets Post 2.3.14
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Servlets Post 2.3.16
>
>
> Currently {{AbstractPostResponse.setError}} 
> (https://github.com/apache/sling/blob/4df9ab2d6592422889c71fa13afd453a10a5a626/bundles/servlets/post/src/main/java/org/apache/sling/servlets/post/AbstractPostResponse.java#L221)
>  always ignores the given {{Throwable}} and just creates a new generic 
> {{SlingException}}.
> To e.g. allow {{SlingPostProcessor}} to throw meaningful exceptions which 
> occur in the response body, the given exception should not be wrapped but 
> just the given throwable's message text should be given out in the document.



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

Re: [RT] Configurationless Sling?

[Bertrand Delacretaz]

On Tue, Mar 28, 2017 at 3:01 PM, Carsten Ziegeler  wrote:
> Julian Sedding wrote
>>... As a convention for service users, would it make sense to use the
>> bundle-symbolic-name as the user-ID (or principal-name)?...

> ...We could use the bundle
> symbolic name and the sub service information. That should be enough. We
> don't need the class name

+1 and we might prefix this with bundle_ or b_ to make it clear where
these usernames come from?

I suppose in the vast majority of cases there's one service user per
bundle, so that would remove a lot of boring configurations.

-Bertrand

[jira] [Commented] (SLING-6679) Replace usage of org.apache.sling.commons.json.* and org.json

[Karl Pauls (JIRA)]

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

Karl Pauls commented on SLING-6679:
---

I just commited implementations for all the subissues (with the exception of 
the caconfig.impl). I still need to do some clean-up and will start resolving 
them when I did so. 

For now, I put in the SNAPSHOT versions in launchpad and replaced what needed 
replacement (e.g., the webconsole). With that, we have a working launchpad (the 
launchpad/testing works for me) without org.json (I removed the geronimo 
bundle) and without commons.json. 

When I'm done with the clean-up and we think there are no other problems 
anymore (might be good to wait a bit for that) I will start releasing the 
affected bundles and update the SNAPSHOTs in the launchpad with released 
versions. 

> Replace usage of org.apache.sling.commons.json.* and org.json
> -
>
> Key: SLING-6679
> URL: https://issues.apache.org/jira/browse/SLING-6679
> Project: Sling
>  Issue Type: Improvement
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>
> Following the deprecation of org.apache.sling.commons.json (SLING-6536) we 
> need to replace its usage everywhere else (at least if we want to be able to 
> release other modules that depend on it). 
> This is the umbrella issue for getting this done. The idea is to create 
> sub-issues with patches for individual components, review the patches, and 
> when all are done: close this issue. 
> General discussions and problems should go to this issue and specific ones on 
> the sub-issue in question.



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

Re: [RT] Configurationless Sling?

[Carsten Ziegeler]

Julian Sedding wrote
> Hi Carsten
> 
> I fully agree with the intention of your email.
> 
> As a convention for service users, would it make sense to use the
> bundle-symbolic-name as the user-ID (or principal-name)? If we can
> detect the class name of the service that's creating the
> Session/ResourceResolver, we could even use the fully qualified
> classname. Not sure that there is a way other than inspecting the call
> stack, however.

Yes, I guess that is maybe somehow doable. We could use the bundle
symbolic name and the sub service information. That should be enough. We
don't need the class name. It's very unlikely that users with that name
exist out of the box. That would free us from most of the mapping
configurations.

What do others think?

> 
> 
> IIUC the service user mapping is only one part of the story. The other
> part are the permissions required by a service user. I suppose
> permissions are also a kind of configuration? So how would we go about
> having a working default permission setup? Without that, a convention
> for service users becomes kind of pointless. Or am I missing
> something?

Yes, we need the repoinit stuff for this, actually we need repoinit for
two things: setting up a user (we shouldn't do this automatically) and
setting up the ACLs.

Carsten

> 
> Regards
> Julian
> 
> 
> On Mon, Mar 27, 2017 at 4:02 PM, Carsten Ziegeler  
> wrote:
>> Hi,
>>
>> for a long time we have tried to use sensible defaults for all of our
>> configurations. This allows our users to run a default Sling without any
>> additional configuration (it should even be possible to run it without a
>> Configuration Admin service available - but that's another story).
>>
>> While we were pretty successful with this, we simply blew it with the
>> move from login administrative to service users. A lot of the (core)
>> modules now use service users and these require a configured mapping in
>> order to work properly. While for example the servlets resolver
>> previously did not require any configuration, it requires at least the
>> mapping. Which in turn means you can't simply use that module as-is.
>>
>> Switching to service users is of course a good idea but I'm wondering if
>> we can find a way to get back to a configurationless Sling again?
>>
>> Clearly we don't want to the mapping to be part of the bundles using the
>> service users.
>>
>> One possible solution would be an out of the box bundle with the
>> necessary repo init and configurations. This would cover the core
>> bundles like servlets resolver and resource resolver.
>>
>> But maybe there is a better option?
>>
>> Regards
>> Carsten
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
> 


 

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

Re: [RT] Configurationless Sling?

[Carsten Ziegeler]

Oliver Lietz wrote
> On Monday 27 March 2017 16:02:50 Carsten Ziegeler wrote:
>> Hi,
> 
> Hi,
> 
>> for a long time we have tried to use sensible defaults for all of our
>> configurations. This allows our users to run a default Sling without any
>> additional configuration (it should even be possible to run it without a
>> Configuration Admin service available - but that's another story).
>>
>> While we were pretty successful with this, we simply blew it with the
>> move from login administrative to service users. A lot of the (core)
>> modules now use service users and these require a configured mapping in
>> order to work properly. While for example the servlets resolver
>> previously did not require any configuration, it requires at least the
>> mapping. Which in turn means you can't simply use that module as-is.
>>
>> Switching to service users is of course a good idea but I'm wondering if
>> we can find a way to get back to a configurationless Sling again?
>>
>> Clearly we don't want to the mapping to be part of the bundles using the
>> service users.
>>
>> One possible solution would be an out of the box bundle with the
>> necessary repo init and configurations. This would cover the core
>> bundles like servlets resolver and resource resolver.
> 
> we already have artifacts for all repoinit statements (bundle) and 
> configurations.
> 
> I had to externalize all configurations for Karaf as features only support 
> the 
> simple cfg format inline (but Sling and Oak require newer Config Admin 
> format):
> 
> https://github.com/apache/sling/tree/trunk/karaf/org.apache.sling.karaf-configs/src/main/resources

Interesting. Now, I know we have talked about it and no one had time for
this so far, but that should really be described through a provisioning
model and then we generate the karaf feature or whatever is needed out
of it.

> 
> That said, Sling is one half only. The other half is Oak.
> 
> Configurations are part of a feature which get installed together with its 
> bundles (and features) when using Sling's Karaf features.
> 
> The missing piece for repoinit (to make statements part of a feature) is a 
> component which can be feed with "fragments" - similar to what we have for 
> service user mappings and "login administrative" white listings (it's on my 
> TODO). Currently all repoinit statements are executed when installing a sling-
> launchpad-oak-* feature.
> 
> https://github.com/apache/sling/tree/trunk/karaf/org.apache.sling.karaf-repoinit/src/main/resources
>

I'm not quiet sure how this work in practice, How do these get installed
at runtime in a Karaf environment.


Now, basically this is a similar idea to what I had. We describe this
stuff as a separate artifact (or more than one) and somehow it gets
installed.

It would be good if we have this description only once in our code base
and not several times and can then generate different artifacts (if
needed) out of it.

I think we should also split this up into a minimal set. For example I'm
currently trying to get Sling running without JCR - in order to trim the
dependencies down. And in that case I only need the service user mapping
for some core bundles, no repo init etc.

Regards
Carsten

 

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

[jira] [Updated] (SLING-6713) Remove commons.json and org.json from launchpad

[Karl Pauls (JIRA)]

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

Karl Pauls updated SLING-6713:
--
Summary: Remove commons.json and org.json from launchpad  (was: Remove 
commons.json from launchpad)

> Remove commons.json and org.json from launchpad
> ---
>
> Key: SLING-6713
> URL: https://issues.apache.org/jira/browse/SLING-6713
> Project: Sling
>  Issue Type: Sub-task
>  Components: Launchpad
>Reporter: Karl Pauls
>Assignee: Karl Pauls
> Attachments: SLING-6713.patch
>
>
> We need to remove commons.json from the launchpad provisioning, add the 
> commons.johnzon bundle, and update all bundles after we switched them to 
> johnzon. 
> Furthermore, we need to make sure it still works :-)



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

[jira] [Created] (SLING-6738) Import ACLs with JSON content

[Guillaume Lucazeau (JIRA)]

Guillaume Lucazeau created SLING-6738:
-

 Summary: Import ACLs with JSON content
 Key: SLING-6738
 URL: https://issues.apache.org/jira/browse/SLING-6738
 Project: Sling
  Issue Type: Improvement
  Components: JCR
Affects Versions: JCR ContentLoader 2.1.10
Reporter: Guillaume Lucazeau


It would be nice to be able to create ACLs found in a JSON content exported 
from Sling. Currently, the node are protected and the import fails.

"rep:policy": {
"jcr:primaryType": "rep:ACL",
"allow": {
"rep:privileges": [
"jcr:addChildNodes"
],
"rep:principalName": "myUser",
"jcr:primaryType": "rep:GrantACE"
}
}



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

[jira] [Commented] (SLING-6737) Migrate to OSGi R6 annotations

[Oliver Lietz (JIRA)]

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

Oliver Lietz commented on SLING-6737:
-

[r1789102|https://svn.apache.org/r1789102]

> Migrate to OSGi R6 annotations
> --
>
> Key: SLING-6737
> URL: https://issues.apache.org/jira/browse/SLING-6737
> Project: Sling
>  Issue Type: Task
>  Components: Scripting
>Affects Versions: Scripting Core 2.0.46
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>




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

[jira] [Created] (SLING-6737) Migrate to OSGi R6 annotations

[Oliver Lietz (JIRA)]

Oliver Lietz created SLING-6737:
---

 Summary: Migrate to OSGi R6 annotations
 Key: SLING-6737
 URL: https://issues.apache.org/jira/browse/SLING-6737
 Project: Sling
  Issue Type: Task
  Components: Scripting
Affects Versions: Scripting Core 2.0.46
Reporter: Oliver Lietz
Assignee: Oliver Lietz






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

[jira] [Commented] (SLING-2662) Enhance run mode handling

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-2662:


Haven't looked closely enough, this is still described at 
https://sling.apache.org/documentation/bundles/sling-settings-org-apache-sling-settings.html#selecting-the-active-run-modes.
 I will try to make the documentation even clearer.

> Enhance run mode handling
> -
>
> Key: SLING-2662
> URL: https://issues.apache.org/jira/browse/SLING-2662
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Settings 1.1.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Settings 1.2.0
>
>
> Often there is a need to provide different features where the user might have 
> the ability to choose whether a feature should be installed or not.
> This can easily be done with a run mode, so a feature is put into a run mode, 
> and if the run mode is activated by the user, the feature is installed.
> However, there are cases where two features might be concurrent, so either 
> feature A or feature B should be installed. Still run modes can be used by 
> defining two run modes A and B - but in this case if the user does not choose 
> one of the run modes, nothing is installed - or if the user selects both run 
> modes, both are installed.
> We could support such use cases with some configuration properties for the 
> settings service:
> a) we define a property which contains run modes that are usually always 
> active
> b) in addition, we define a property which contains whether a run mode is 
> active unless another run mode is active.
> So for the above use case, we define run mode A as always active and also set 
> the second property to define that A is not active once B is activated by the 
> user
> We could also define a third property which contains a set of run modes that 
> are only choosable on the first startup of the installation, so in the in the 
> example above, if this property is defined for A and B, the user selection of 
> the first startup is preserved



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

[jira] [Commented] (SLING-2662) Enhance run mode handling

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-2662:


The update to the documentation page at 
https://sling.apache.org/documentation/bundles/sling-settings-org-apache-sling-settings.html
 removed the description of property {{sling.run.modes}} completely, which is 
still supported according to 
https://github.com/apache/sling/blob/trunk/bundles/extensions/settings/src/main/java/org/apache/sling/settings/impl/SlingSettingsServiceImpl.java#L198.
Was the property description removed by mistake or is the property 
{{sling.run.modes}} deprecated in favour of {{sling.run.mode.install.options}} 
and {{sling.run.mode.options}}?

> Enhance run mode handling
> -
>
> Key: SLING-2662
> URL: https://issues.apache.org/jira/browse/SLING-2662
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Settings 1.1.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Settings 1.2.0
>
>
> Often there is a need to provide different features where the user might have 
> the ability to choose whether a feature should be installed or not.
> This can easily be done with a run mode, so a feature is put into a run mode, 
> and if the run mode is activated by the user, the feature is installed.
> However, there are cases where two features might be concurrent, so either 
> feature A or feature B should be installed. Still run modes can be used by 
> defining two run modes A and B - but in this case if the user does not choose 
> one of the run modes, nothing is installed - or if the user selects both run 
> modes, both are installed.
> We could support such use cases with some configuration properties for the 
> settings service:
> a) we define a property which contains run modes that are usually always 
> active
> b) in addition, we define a property which contains whether a run mode is 
> active unless another run mode is active.
> So for the above use case, we define run mode A as always active and also set 
> the second property to define that A is not active once B is activated by the 
> user
> We could also define a third property which contains a set of run modes that 
> are only choosable on the first startup of the installation, so in the in the 
> example above, if this property is defined for A and B, the user selection of 
> the first startup is preserved



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

Re: [VOTE] Release Apache Sling File System Resource Provider 2.0.0, File System Resource Provider 1.3.0

[Robert Munteanu]

On Mon, 2017-03-27 at 16:21 +, Stefan Seifert wrote:
> Please vote to approve this release:

+1

Robert

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

Re: Sling Eclipse Tooling and OSGi Bundle Content

[Robert Munteanu]

Hi Andy,

On Mon, 2017-03-27 at 10:51 -0700, Andreas Schaefer Sr. wrote:
> Hi
> 
> I am wondering if the current Eclipse Tooling supports OSGi Bundle
> Content (through Sling-Initial-Content)?
> 
> If not are the any places to support them in the future?

The bundle deployment should work since the initial content is
processed based on some manifest headers and the resources from
target/classes.

Robert

Re: Metrics in Sling

[Bertrand Delacretaz]

On Mon, Mar 27, 2017 at 11:16 PM, Clelia Meneghin  wrote:
> ...I added a Metric to the Sling Bundles resourceresolver and engine
> Please review the issue [0], [1], [2], [3], [4], [5], [6], [7] ..

Thanks! As this is core code we'll need to review before eventually
using these contributions.

For now I have linked them to SLING-5410 as they include good ideas on
which metrics to implement.

-Bertrand

Re: [VOTE] Release Apache Sling File System Resource Provider 2.0.0, File System Resource Provider 1.3.0

[Carsten Ziegeler]

+1


 

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

[jira] [Resolved] (SLING-4465) Use new Scripting Thymeleaf features in Fling sample

[Oliver Lietz (JIRA)]

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

Oliver Lietz resolved SLING-4465.
-
Resolution: Done

> Use new Scripting Thymeleaf features in Fling sample
> 
>
> Key: SLING-4465
> URL: https://issues.apache.org/jira/browse/SLING-4465
> Project: Sling
>  Issue Type: Task
>  Components: Samples
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>Priority: Minor
> Fix For: Samples Fling 0.0.2
>
>




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

Re: Maven dependency to org.apache.sling.commons.johnzon

[Karl Pauls]

I know. Not saying it was wrong - this way it just hit the trunk before I
could cleanup my mess :-)

Don't worry about it. I'm close to getting this committed anyways. I'll
update it together with the rest.

regards,

Karl

On Tuesday, March 28, 2017, Carsten Ziegeler  wrote:

> Karl Pauls wrote
> > I agree. I'm not at the point where I can commit anything so all the
> > patches are subject to clean-up and I wouldn't want them to get out
> > before that. Carsten jumped the gun somewhat on this one but I'll
> > clean-up when I'm ready to commit all of this.
> >
> :) I just applied one of your patches to spare the pain of merging.
> So what are the coordinates to use?
>
> Carsten
>
> > regards,
> >
> > Karl
> >
> > On Mon, Mar 27, 2017 at 8:52 PM, Justin Edelson
> > > wrote:
> >> As part of the Commons JSON migration (kudos to all those plugging away
> at
> >> this thankless task), I see that some dependencies are being created
> >> directly to org.apache.sling.commons.johnzon, e.g.
> >> https://github.com/apache/sling/blob/trunk/bundles/
> extensions/adapter/pom.xml#L89
> >> .
> >>
> >> IIUC, we should really be depending upon the javax.json API, not our
> >> bundling of it. While I don't see any problems related to this right
> now,
> >> it seems like we could end up accidentally creating a dependency to the
> >> Johnzon implementation (or our wrapper of the Johnzon implementation).
> >>
> >> WDYT?
> >
> >
> >
>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org 
>


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