date:20210423



sonarcloud[bot] commented on pull request #74:
URL: 
https://github.com/apache/sling-org-apache-sling-feature-cpconverter/pull/74#issuecomment-826023026


   SonarCloud Quality Gate failed.
   
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=74=false=BUG)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=74=false=BUG)
 [0 
Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=74=false=BUG)
  
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=74=false=VULNERABILITY)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=74=false=VULNERABILITY)
 [0 
Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=74=false=VULNERABILITY)
  
   [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-feature-cpconverter=74=false=SECURITY_HOTSPOT)
 [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-feature-cpconverter=74=false=SECURITY_HOTSPOT)
 [2 Security 
Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-feature-cpconverter=74=false=SECURITY_HOTSPOT)
  
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=74=false=CODE_SMELL)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=74=false=CODE_SMELL)
 [8 Code 
Smells](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=74=false=CODE_SMELL)
   
   [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-cpconverter=74=new_coverage=list)
 [60.2% 
Coverage](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-cpconverter=74=new_coverage=list)
  
   [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-cpconverter=74=new_duplicated_lines_density=list)
 [4.2% 
Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-cpconverter=74=new_duplicated_lines_density=list)
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [sling-org-apache-sling-feature-cpconverter] sonarcloud[bot] removed a comment on pull request #74: SLING-10243 extract Sling-Initial-Content



sonarcloud[bot] removed a comment on pull request #74:
URL: 
https://github.com/apache/sling-org-apache-sling-feature-cpconverter/pull/74#issuecomment-824047400


   SonarCloud Quality Gate failed.
   
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=74=false=BUG)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=74=false=BUG)
 [0 
Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=74=false=BUG)
  
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=74=false=VULNERABILITY)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=74=false=VULNERABILITY)
 [0 
Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=74=false=VULNERABILITY)
  
   [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-feature-cpconverter=74=false=SECURITY_HOTSPOT)
 [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-feature-cpconverter=74=false=SECURITY_HOTSPOT)
 [2 Security 
Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-feature-cpconverter=74=false=SECURITY_HOTSPOT)
  
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=74=false=CODE_SMELL)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=74=false=CODE_SMELL)
 [8 Code 
Smells](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=74=false=CODE_SMELL)
   
   [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-cpconverter=74=new_coverage=list)
 [60.2% 
Coverage](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-cpconverter=74=new_coverage=list)
  
   [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-cpconverter=74=new_duplicated_lines_density=list)
 [4.2% 
Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-cpconverter=74=new_duplicated_lines_density=list)
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: SAML auth handler and additional Maven repo (was: [git] New git repository - org-apache-sling-auth-saml2)

2021-04-23 Thread Cris Rockwell

Hi Robert

There are a few things the Shibboleth devs wanted to reinforce with me. A)
They don’t upload artifacts to Maven Central. The canonical way to get
their latest libraries is through the Shibboleth repo. The v4.0.1 was
uploaded to Central by other parties, and they don't know anything about
it. B) Given that supply-chain attacks happen more frequently (e.g.
SolarWinds, npm issues, etc), it’s important to actually validate the
dependency artifact’s signatures during the build. C) Maven Central has 'no
well-defined provenance and no in-band signature check in all builds'

After adding a plugin (pgpverify-maven-plugin) which checks dependency
signatures, I have to agree.
The build failed when due to invalid dependency signatures

https://ci-builds.apache.org/blue/organizations/jenkins/Sling%2Fmodules%2Fsling-org-apache-sling-auth-saml2/detail/PR-1/2/pipeline

[ERROR] net.shibboleth.utilities:java-support:pom:8.0.0 PGP Signature
INVALID
KeyId: 0x51B52DC5DD452F92BE342CC2858FC4C4F43856A3 UserIds: [J. Daniel Kulp <
d...@kulp.com>, J. Daniel Kulp , J. Daniel Kulp <
dk...@progress.com>, J. Daniel Kulp , J. Daniel Kulp <
dan.k...@sopera.com>]

For me, ensuring against dependency supply-chain attacks is more important
than choosing to trust certain repositories inherently.
As a test, I added the Shib repo back to ensure that the build passes with
dependency signatures checking.

The plugin provides a warning...
No keysmap specified in configuration or keysmap contains no entries.
PGPVerify will only check artifacts against their signature. File
corruption will be detected. However, without a keysmap as a reference for
trust, valid signatures of any public key will be accepted.

So, I would actually like to provide a key mapping for the OpenSAML library
and clear that warning.

Regards
Cris

On Apr 23, 2021, at 10:52 AM, Robert Munteanu wrote:

Hi Cris,

On Fri, 2021-04-23 at 09:31 -0400, Cris Rockwell wrote:

The OpenSAML library was selected because of the support the Shibboleth
Consortium has within higher education[0].
My institution is a member of the consortium. I am confident about the
ongoing support the project has and the maintenance
it receives now and in the future.

When it comes to using the OpenSAML library, it’s necessary to follow
the guidelines about obtaining legitimate versions of the artifacts[1]
That means using library artifacts provided by the Shibboleth
Repository, and not using the OpenSAML artifacts from Maven Central.

It’s also important to use the library for all parts of the process
when it comes to SAML protocols [2]
This requires providing lots of dependencies, which the library
requires

First of all, I don't see the choice of external libraries as an issue,
I am sure that you have chosen well.

My only concern is that the recommendation of not having repositories
and build repositories defined for artifacts deployed to Maven Central.
The official requirements [3] state that:

In addition we discourage the usage of and
and instead publish any required components to the
Central Repository. This applies for your own components as well as for
3rd party artifacts.

The downsides to using a third party repository are:

- if the Shibbboleth Maven repository is retired, our artifacts become
invalid
- some organisations have strict procurement rules and would require
vetting additional repositories

In the end, I don't think it's a blocker but we should avoid third
party repositories if at all possible.

However, I have filed a PR [4] that removes the extra Maven repository
and the build still passes. If the repository is not actually needed,
the whole discussion is moot :-)

Thanks,
Robert

[3]: https://central.sonatype.org/publish/requirements/
[4]: https://github.com/apache/sling-org-apache-sling-auth-saml2/pull/1

[jira] [Assigned] (SLING-10327) SlingAdaptable: simplify getAdapter()



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

Joerg Hoh reassigned SLING-10327:
-

Assignee: Joerg Hoh

> SlingAdaptable: simplify getAdapter()
> -
>
> Key: SLING-10327
> URL: https://issues.apache.org/jira/browse/SLING-10327
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: API 2.23.4
>
>
> use {{computeIfAbsent}} to simplify the code.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (SLING-8759) Replace the SlingAdaptable.adapterCache with a ConcurrentMap



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

Joerg Hoh edited comment on SLING-8759 at 4/23/21, 8:32 PM:


I created SLING-10327 to handle the refactoring of getAdapter(), so we can keep 
this one open. Unfortunately the Git comments reference this one already (and 
rewriting them now doesn't seem to be the best idea).

[~rombert] do you have a good idea how avoid the mandatory memory overhead 
while keeping the ConcurrentMap approach? If not, I suggest to release Sling 
API 2.23.4 without SLING-8759.


was (Author: joerghoh):
I created SLING-10327 to handle the refactoring of getAdapter(), so we can keep 
this one open. Unfortunately the Git comments reference this one already (and 
rewriting them now doesn't seem to be the best idea).

> Replace the SlingAdaptable.adapterCache with a ConcurrentMap
> 
>
> Key: SLING-8759
> URL: https://issues.apache.org/jira/browse/SLING-8759
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Reporter: Robert Munteanu
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: API 2.23.4
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> The SlingAdaptable.adapterCache is based on a HashMap guarded by a 
> {{synchronized}} block, with lazy initialisation. This looks like a perfect 
> scenario for {{ConcurrentMap.computeIfAbsent}}. The increased memory usage 
> should be measured though, as a simple implementation will not use lazy 
> initialisation, e.g.
> {code}
> diff --git a/src/main/java/org/apache/sling/api/adapter/SlingAdaptable.java 
> b/src/main/java/org/apache/sling/api/adapter/SlingAdaptable.java
> index 5adf0ce..6bed14f 100644
> --- a/src/main/java/org/apache/sling/api/adapter/SlingAdaptable.java
> +++ b/src/main/java/org/apache/sling/api/adapter/SlingAdaptable.java
> @@ -20,6 +20,8 @@ package org.apache.sling.api.adapter;
>  
>  import java.util.HashMap;
>  import java.util.Map;
> +import java.util.concurrent.ConcurrentHashMap;
> +import java.util.concurrent.ConcurrentMap;
>  
>  /**
>   * The SlingAdaptable class is an (abstract) default 
> implementation
> @@ -74,7 +76,7 @@ public abstract class SlingAdaptable implements Adaptable {
>   * are intended to be short-lived to not hold on to objects and classes 
> for
>   * too long.
>   */
> -private Map, Object> adaptersCache;
> +private ConcurrentMap, Object> adaptersCache = new 
> ConcurrentHashMap, Object>();
>  
>  /**
>   * Calls into the registered {@link AdapterManager} to adapt this object 
> to
> @@ -94,22 +96,8 @@ public abstract class SlingAdaptable implements Adaptable {
>   */
>  @SuppressWarnings("unchecked")
>  public  AdapterType adaptTo(Class type) {
> -AdapterType result = null;
> -synchronized ( this ) {
> -if ( adaptersCache != null ) {
> -result = (AdapterType) adaptersCache.get(type);
> -}
> -if ( result == null ) {
> -final AdapterManager mgr = ADAPTER_MANAGER;
> -result = (mgr == null ? null : mgr.getAdapter(this, type));
> -if ( result != null ) {
> -if ( adaptersCache == null ) {
> -adaptersCache = new HashMap, Object>();
> -}
> -adaptersCache.put(type, result);
> -}
> -}
> -}
> -return result;
> +return (AdapterType) adaptersCache.computeIfAbsent(type, (klazz) -> {
> +return ADAPTER_MANAGER.getAdapter(this, type);
> +});
>  }
>  }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SLING-8759) Replace the SlingAdaptable.adapterCache with a ConcurrentMap



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

Joerg Hoh commented on SLING-8759:
--

I created SLING-10327 to handle the refactoring of getAdapter(), so we can keep 
this one open. Unfortunately the Git comments reference this one already (and 
rewriting them now doesn't seem to be the best idea).

> Replace the SlingAdaptable.adapterCache with a ConcurrentMap
> 
>
> Key: SLING-8759
> URL: https://issues.apache.org/jira/browse/SLING-8759
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Reporter: Robert Munteanu
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: API 2.23.4
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> The SlingAdaptable.adapterCache is based on a HashMap guarded by a 
> {{synchronized}} block, with lazy initialisation. This looks like a perfect 
> scenario for {{ConcurrentMap.computeIfAbsent}}. The increased memory usage 
> should be measured though, as a simple implementation will not use lazy 
> initialisation, e.g.
> {code}
> diff --git a/src/main/java/org/apache/sling/api/adapter/SlingAdaptable.java 
> b/src/main/java/org/apache/sling/api/adapter/SlingAdaptable.java
> index 5adf0ce..6bed14f 100644
> --- a/src/main/java/org/apache/sling/api/adapter/SlingAdaptable.java
> +++ b/src/main/java/org/apache/sling/api/adapter/SlingAdaptable.java
> @@ -20,6 +20,8 @@ package org.apache.sling.api.adapter;
>  
>  import java.util.HashMap;
>  import java.util.Map;
> +import java.util.concurrent.ConcurrentHashMap;
> +import java.util.concurrent.ConcurrentMap;
>  
>  /**
>   * The SlingAdaptable class is an (abstract) default 
> implementation
> @@ -74,7 +76,7 @@ public abstract class SlingAdaptable implements Adaptable {
>   * are intended to be short-lived to not hold on to objects and classes 
> for
>   * too long.
>   */
> -private Map, Object> adaptersCache;
> +private ConcurrentMap, Object> adaptersCache = new 
> ConcurrentHashMap, Object>();
>  
>  /**
>   * Calls into the registered {@link AdapterManager} to adapt this object 
> to
> @@ -94,22 +96,8 @@ public abstract class SlingAdaptable implements Adaptable {
>   */
>  @SuppressWarnings("unchecked")
>  public  AdapterType adaptTo(Class type) {
> -AdapterType result = null;
> -synchronized ( this ) {
> -if ( adaptersCache != null ) {
> -result = (AdapterType) adaptersCache.get(type);
> -}
> -if ( result == null ) {
> -final AdapterManager mgr = ADAPTER_MANAGER;
> -result = (mgr == null ? null : mgr.getAdapter(this, type));
> -if ( result != null ) {
> -if ( adaptersCache == null ) {
> -adaptersCache = new HashMap, Object>();
> -}
> -adaptersCache.put(type, result);
> -}
> -}
> -}
> -return result;
> +return (AdapterType) adaptersCache.computeIfAbsent(type, (klazz) -> {
> +return ADAPTER_MANAGER.getAdapter(this, type);
> +});
>  }
>  }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (SLING-10327) SlingAdaptable: simplify getAdapter()

Joerg Hoh created SLING-10327:
-

 Summary: SlingAdaptable: simplify getAdapter()
 Key: SLING-10327
 URL: https://issues.apache.org/jira/browse/SLING-10327
 Project: Sling
  Issue Type: Improvement
  Components: API
Reporter: Joerg Hoh
 Fix For: API 2.23.4


use {{computeIfAbsent}} to simplify the code.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SLING-8759) Replace the SlingAdaptable.adapterCache with a ConcurrentMap



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

Joerg Hoh commented on SLING-8759:
--

You are right. But: Is a ConcurrentMap really necessary here?

* I tested that codepath (with a cache hit) for performance by invoking it in a 
loop; and it turned out that the code with the {{synchronized}} statement 
consumed pretty much the same amount of time (single-threaded), 2019ms vs 
1974ms (favoring a bit the ConcurrentHashMap).
* I am not sure how much concurrency we will see in reality, because that would 
mostly mean, that the Adaptable is shared between multiple threads. And I have 
seen the biggest usecase for adaptables in the are of Resources and 
ResourceResolvers, which are not thread-safe.
* And as you already mentioned, I would not neglect the memory overhead. 
According to [1] a ConcurrentHashmap consumes > 200 bytes. Assuming that we 
have a lot of classes, which inherit from Adaptable, but which are not always 
using {{.adaptTo()}}, it will incur quite some overhead, because right now the 
Map is not instantiated in that case.

So, I would suggest to keep with the {{synchronized}} block, unless we have 
data showing that it can be indeed a problem.

[1] 
https://stackoverflow.com/questions/11103216/concurrenthashmap-memory-overhead

> Replace the SlingAdaptable.adapterCache with a ConcurrentMap
> 
>
> Key: SLING-8759
> URL: https://issues.apache.org/jira/browse/SLING-8759
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Reporter: Robert Munteanu
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: API 2.23.4
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> The SlingAdaptable.adapterCache is based on a HashMap guarded by a 
> {{synchronized}} block, with lazy initialisation. This looks like a perfect 
> scenario for {{ConcurrentMap.computeIfAbsent}}. The increased memory usage 
> should be measured though, as a simple implementation will not use lazy 
> initialisation, e.g.
> {code}
> diff --git a/src/main/java/org/apache/sling/api/adapter/SlingAdaptable.java 
> b/src/main/java/org/apache/sling/api/adapter/SlingAdaptable.java
> index 5adf0ce..6bed14f 100644
> --- a/src/main/java/org/apache/sling/api/adapter/SlingAdaptable.java
> +++ b/src/main/java/org/apache/sling/api/adapter/SlingAdaptable.java
> @@ -20,6 +20,8 @@ package org.apache.sling.api.adapter;
>  
>  import java.util.HashMap;
>  import java.util.Map;
> +import java.util.concurrent.ConcurrentHashMap;
> +import java.util.concurrent.ConcurrentMap;
>  
>  /**
>   * The SlingAdaptable class is an (abstract) default 
> implementation
> @@ -74,7 +76,7 @@ public abstract class SlingAdaptable implements Adaptable {
>   * are intended to be short-lived to not hold on to objects and classes 
> for
>   * too long.
>   */
> -private Map, Object> adaptersCache;
> +private ConcurrentMap, Object> adaptersCache = new 
> ConcurrentHashMap, Object>();
>  
>  /**
>   * Calls into the registered {@link AdapterManager} to adapt this object 
> to
> @@ -94,22 +96,8 @@ public abstract class SlingAdaptable implements Adaptable {
>   */
>  @SuppressWarnings("unchecked")
>  public  AdapterType adaptTo(Class type) {
> -AdapterType result = null;
> -synchronized ( this ) {
> -if ( adaptersCache != null ) {
> -result = (AdapterType) adaptersCache.get(type);
> -}
> -if ( result == null ) {
> -final AdapterManager mgr = ADAPTER_MANAGER;
> -result = (mgr == null ? null : mgr.getAdapter(this, type));
> -if ( result != null ) {
> -if ( adaptersCache == null ) {
> -adaptersCache = new HashMap, Object>();
> -}
> -adaptersCache.put(type, result);
> -}
> -}
> -}
> -return result;
> +return (AdapterType) adaptersCache.computeIfAbsent(type, (klazz) -> {
> +return ADAPTER_MANAGER.getAdapter(this, type);
> +});
>  }
>  }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [VOTE] Release Apache Sling Bundle Resource Provider version 2.3.4

2021-04-23 Thread Eric Norman

+1

On Fri, Apr 23, 2021 at 11:02 AM Eric Norman  wrote:

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

Re: [VOTE] Release Apache Sling Scripting SPI 1.0.2

2021-04-23 Thread Eric Norman

+1

On Fri, Apr 23, 2021 at 8:21 AM Radu Cotescu  wrote:

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

[VOTE] Release Apache Sling Bundle Resource Provider version 2.3.4

2021-04-23 Thread Eric Norman

Hi,

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

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

You can use this UNIX script to download the release and verify the
signatures:
https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD

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

Please vote to approve this release:

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

This majority vote is open for at least 72 hours.

[jira] [Commented] (SLING-10141) Update to Sling Bundle Parent 41

2021-04-23 Thread Eric Norman (Jira)



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

Eric Norman commented on SLING-10141:
-

Updated from parent 40 to parent 41 at: 
https://github.com/apache/sling-org-apache-sling-bundleresource-impl/commit/6169d543dc58551315e73f0667f5e180fae85f5a

> Update to Sling Bundle Parent 41
> 
>
> Key: SLING-10141
> URL: https://issues.apache.org/jira/browse/SLING-10141
> Project: Sling
>  Issue Type: Sub-task
>Reporter: Eric Norman
>Assignee: Eric Norman
>Priority: Major
> Fix For: Bundle Resource 2.3.4
>
>
> Update to Sling Bundle Parent 41



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (SLING-10141) Update to Sling Bundle Parent 41

2021-04-23 Thread Eric Norman (Jira)



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

Eric Norman updated SLING-10141:

Description: Update to Sling Bundle Parent 41  (was: Update to Sling Bundle 
Parent 40)

> Update to Sling Bundle Parent 41
> 
>
> Key: SLING-10141
> URL: https://issues.apache.org/jira/browse/SLING-10141
> Project: Sling
>  Issue Type: Sub-task
>Reporter: Eric Norman
>Assignee: Eric Norman
>Priority: Major
> Fix For: Bundle Resource 2.3.4
>
>
> Update to Sling Bundle Parent 41



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (SLING-10141) Update to Sling Bundle Parent 41

2021-04-23 Thread Eric Norman (Jira)



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

Eric Norman updated SLING-10141:

Summary: Update to Sling Bundle Parent 41  (was: Update to Sling Bundle 
Parent 40)

> Update to Sling Bundle Parent 41
> 
>
> Key: SLING-10141
> URL: https://issues.apache.org/jira/browse/SLING-10141
> Project: Sling
>  Issue Type: Sub-task
>Reporter: Eric Norman
>Assignee: Eric Norman
>Priority: Major
> Fix For: Bundle Resource 2.3.4
>
>
> Update to Sling Bundle Parent 40



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SLING-10118) Fully cache the GraphQLSchema objects

2021-04-23 Thread Jira



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

Thierry Ygé commented on SLING-10118:
-

[~bdelacretaz] in our tests, caching the schema help to reduce by 25% an 
initial 17 min test duration.

In fact at the request level for the generated schema, it saved an extra 200 ms 
per request, which is the time it need to perform the "buildSchema" code in 
that specific context independently of the query complexity.  As we need to 
quickly re-fetch a lot of content that execute GraphQL queries (for example 
about 33k requests , with 20 parallel worker threads, we saved up to 5 min of 
computations).

So for requests that would generally need 400 ms to respond, it will save 
around 50% , for request that take 20s it save still about 200 ms (as it is the 
same schema just a more complex query), but since there are more likely 
requests that served  response in 400 ms, the average saved time was about 25% 
at the end.

So the more your Schema (SDL) is large the more time is saved with that extra 
caching, and the gain is likely to appear on low complexity GraphQL queries.

Caching or not caching based on some annotation could be an idea, currently we 
don't see in our use cases why it wouldn't need to be cached, but you may have 
some other use cases in mind.

 

> Fully cache the GraphQLSchema objects
> -
>
> Key: SLING-10118
> URL: https://issues.apache.org/jira/browse/SLING-10118
> Project: Sling
>  Issue Type: Bug
>  Components: GraphQL
>Affects Versions: GraphQL Core 0.0.10
>Reporter: Thierry Ygé
>Priority: Major
>
> Currently in SLING-10085 the GraphQLSchema couldn't be cached due to wired 
> resource.
> Thus it still need half the time to spend on building the schema, while 
> generally the resource is only used to be passed later to the fetcher. As 
> that resource then change, I suggested to wrap it via a proxy Resource 
> implementation that would be passed instead of the real resource.
> That proxy will then use a map  to lookup for the current resource used at 
> execute/validate time. The key for the map is to use the current thread.
> I will submit a PR with the solution I suggest to use.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: SAML auth handler and additional Maven repo (was: [git] New git repository - org-apache-sling-auth-saml2)

2021-04-23 Thread Cris Rockwell

Ok Thanks for the clarification.

Let me take a bit of time to review the hashes. 

For example, comparing this

https://build.shibboleth.net/nexus/content/groups/public/org/opensaml/opensaml-xmlsec-impl/4.0.1/opensaml-xmlsec-impl-4.0.1.jar.sha1
to this

https://repo1.maven.org/maven2/org/opensaml/opensaml-xmlsec-impl/4.0.1/opensaml-xmlsec-impl-4.0.1.jar.sha1

The example above shows this artifact hash is the same, so maybe it’s fine to 
get it from Central.
I'll just reach out to the Shibboleth dev team to get their thoughts.

Cris 



> On Apr 23, 2021, at 10:52 AM, Robert Munteanu  wrote:
> 
> Hi Cris,
> 
> On Fri, 2021-04-23 at 09:31 -0400, Cris Rockwell wrote:
>> The OpenSAML library was selected because of the support the Shibboleth
>> Consortium has within higher education[0].
>> My institution is a member of the consortium. I am confident about the
>> ongoing support the project has and the maintenance 
>> it receives now and in the future. 
>> 
>> When it comes to using the OpenSAML library, it’s necessary to follow
>> the guidelines about obtaining legitimate versions of the artifacts[1]
>> That means using library artifacts provided by the Shibboleth
>> Repository, and not using the OpenSAML artifacts from Maven Central.
>> 
>> It’s also important to use the library for all parts of the process
>> when it comes to SAML protocols [2]
>> This requires providing lots of dependencies, which the library
>> requires
> 
> First of all, I don't see the choice of external libraries as an issue,
> I am sure that you have chosen well.
> 
> My only concern is that the recommendation of not having repositories
> and build repositories defined for artifacts deployed to Maven Central.
> The official requirements [3] state that:
> 
>   In addition we discourage the usage of  and
>and instead publish any required components to the
>   Central Repository. This applies for your own components as well as for
>   3rd party artifacts.
> 
> The downsides to using a third party repository are:
> 
> - if the Shibbboleth Maven repository is retired, our artifacts become
> invalid
> - some organisations have strict procurement rules and would require
> vetting additional repositories
> 
> In the end, I don't think it's a blocker but we should avoid third
> party repositories if at all possible.
> 
> However, I have filed a PR [4] that removes the extra Maven repository
> and the build still passes. If the repository is not actually needed,
> the whole discussion is moot :-)
> 
> Thanks,
> Robert
> 
> [3]: https://central.sonatype.org/publish/requirements/
> [4]: https://github.com/apache/sling-org-apache-sling-auth-saml2/pull/1
>

[GitHub] [sling-org-apache-sling-servlets-resolver] sonarcloud[bot] commented on pull request #7: [SLING-9230] - Servlet should not be allowed to register with invalid…



sonarcloud[bot] commented on pull request #7:
URL: 
https://github.com/apache/sling-org-apache-sling-servlets-resolver/pull/7#issuecomment-825731798


   SonarCloud Quality Gate failed.
   
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=BUG)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=BUG)
 [0 
Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=BUG)
  
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=VULNERABILITY)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=VULNERABILITY)
 [0 
Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=VULNERABILITY)
  
   [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-servlets-resolver=7=false=SECURITY_HOTSPOT)
 [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-servlets-resolver=7=false=SECURITY_HOTSPOT)
 [0 Security 
Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-servlets-resolver=7=false=SECURITY_HOTSPOT)
  
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=CODE_SMELL)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=CODE_SMELL)
 [0 Code 
Smells](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=CODE_SMELL)
   
   [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-servlets-resolver=7=new_coverage=list)
 [70.0% 
Coverage](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-servlets-resolver=7=new_coverage=list)
  
   [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-servlets-resolver=7=new_duplicated_lines_density=list)
 [0.0% 
Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-servlets-resolver=7=new_duplicated_lines_density=list)
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [sling-org-apache-sling-servlets-resolver] sonarcloud[bot] removed a comment on pull request #7: [SLING-9230] - Servlet should not be allowed to register with invalid…



sonarcloud[bot] removed a comment on pull request #7:
URL: 
https://github.com/apache/sling-org-apache-sling-servlets-resolver/pull/7#issuecomment-825619009


   SonarCloud Quality Gate failed.
   
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=BUG)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=BUG)
 [0 
Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=BUG)
  
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=VULNERABILITY)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=VULNERABILITY)
 [0 
Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=VULNERABILITY)
  
   [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-servlets-resolver=7=false=SECURITY_HOTSPOT)
 [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-servlets-resolver=7=false=SECURITY_HOTSPOT)
 [0 Security 
Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-servlets-resolver=7=false=SECURITY_HOTSPOT)
  
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=CODE_SMELL)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=CODE_SMELL)
 [0 Code 
Smells](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=CODE_SMELL)
   
   [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-servlets-resolver=7=new_coverage=list)
 [70.0% 
Coverage](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-servlets-resolver=7=new_coverage=list)
  
   [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-servlets-resolver=7=new_duplicated_lines_density=list)
 [0.0% 
Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-servlets-resolver=7=new_duplicated_lines_density=list)
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[VOTE] Release Apache Sling Scripting SPI 1.0.2

2021-04-23 Thread Radu Cotescu

Hi,

We solved 3 issues in this release:
https://issues.apache.org/jira/browse/SLING/fixforversion/12349958

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

You can use this UNIX script to download the release and verify the signatures:
https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD

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

Please vote to approve this release:

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

This majority vote is open for at least 72 hours.

Regards,
Radu Cotescu

[jira] [Comment Edited] (SLING-10118) Fully cache the GraphQLSchema objects



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

Bertrand Delacretaz edited comment on SLING-10118 at 4/23/21, 3:16 PM:
---

Thank you for the clarification, I understand the "wired" part now. I have 
slightly refactored the schema generation as there was some code duplication, 
in [commit 
9abddb77|https://github.com/apache/sling-org-apache-sling-graphql-core/commit/9abddb77904a079a5c3c58de0901ac576fb6b53f].

As you say the {{GraphQLSchema}} object is created in several steps:
{code:java}
String schemaSdl = prepareSchemaDefinition(schemaProvider, queryResource, 
selectors);
TypeDefinitionRegistry typeDefinitionRegistry = 
getTypeDefinitionRegistry(schemaSdl, queryResource, selectors);
schema = buildSchema(typeDefinitionRegistry, queryResource);
{code}
And currently only the result of {{getTypeDefinitionRegistry}} is cached. 
Caching the {{GraphQLSchema}} objects should be more efficient ([~tyge] do you 
have metrics that demonstrate that?).
h2. How about caching based on a "vary" schema annotation ?

The problem for caching is that the generated schema can potentially depend on 
many things:
 * 1) The Resource to which the query applies, including potentially all its 
attributes
 * 2) The Request's selectors
 * 3) The current set of OSGi services and Sling scripts or servlets, which 
might change at runtime.

However, in practice and especially on production systems it can be safe to 
assume that 3) never changes after startup - which might be expressed by a 
configuration of the GraphQL Core module ("assume stable OSGi services and 
scripts").

To allow whatever generates the schema to indicate what can cause it to change, 
we might use a schema comment similar to the HTTP Vary header:
{code:java}
# sling-schema-vary: resource-type, selectors
{code}
This example value indicates that the generated schema depends only on the 
current resource type and on the request selectors, which is probably true in 
the vast majority of cases.

So I think the below rules would allow us to implement caching of the 
{{GraphQLSchema}} in a simple way, using the resource type + selectors as the 
key:
 * To activate the cache, the "assume stable OSGi services and scripts" option 
must be set. That might actually be a cache lifetime value, where zero disables 
the cache and N meaning "assume stability for N minutes". That N value can then 
define the cache entries time to live.
 * For a specific schema to be cached, it must include the 
{{sling-schema-vary}} comment (or directive, TBD)
 * We initially recognize only {{resource-type}} and {{selectors}} in that 
"vary" value and build the cache keys accordingly.
* If any of the above conditions are not met, the schema object is not cached
* Log messages and metrics allow for observing the caching behavior

I think this allows for fully caching the schema generation steps up to the 
creation of the {{GraphQLSchema}} object, with constraints that should be 
acceptable.

WDYT?

/cc [~radu] as I think you wrote the current caching code


was (Author: bdelacretaz):
Thank you for the clarification, I understand the "wired" part now. I have 
slightly refactored the schema generation as there was some code duplication, 
in [commit 
9abddb77|https://github.com/apache/sling-org-apache-sling-graphql-core/commit/9abddb77904a079a5c3c58de0901ac576fb6b53f].

As you say the {{GraphQLSchema}} object is created in several steps:
{code:java}
String schemaSdl = prepareSchemaDefinition(schemaProvider, queryResource, 
selectors);
TypeDefinitionRegistry typeDefinitionRegistry = 
getTypeDefinitionRegistry(schemaSdl, queryResource, selectors);
schema = buildSchema(typeDefinitionRegistry, queryResource);
{code}
And currently only the result of {{getTypeDefinitionRegistry}} is cached. 
Caching the {{GraphQLSchema}} objects should be more efficient ([~tyge] do you 
have metrics that demonstrate that?).
h2. How about caching based on a "vary" schema annotation ?

The problem for caching is that the generated schema can potentially depend on 
many things:
 * 1) The Resource to which the query applies, including potentially all its 
attributes
 * 2) The Request's selectors
 * 3) The current set of OSGi services and Sling scripts or servlets, which 
might change at runtime.

However, in practice and especially on production systems it can be safe to 
assume that 3) never changes after startup - which might be expressed by a 
configuration of the GraphQL Core module ("assume stable OSGi services and 
scripts").

To allow whatever generates the schema to indicate what can cause it to change, 
we might use a schema comment similar to the HTTP Vary header:
{code:java}
# sling-schema-vary: resource-type, selectors
{code}
This example value indicates that the generated schema depends only on the 
current resource type and on the request

CFP for ApacheCon 2021 closes in ONE WEEK

2021-04-23 Thread Rich Bowen


[You are receiving this because you're subscribed to one or more dev@
mailing lists for an Apache project, or the ApacheCon Announce list.]

Time is running out to submit your talk for ApacheCon 2021.

The Call for Presentations for ApacheCon @Home 2021, focused on Europe
and North America time zones, closes May 3rd, and is at
https://www.apachecon.com/acah2021/cfp.html

The CFP for ApacheCon Asia, focused on Asia/Pacific time zones, is at
https://apachecon.com/acasia2021/cfp.html and also closes on May 3rd.

ApacheCon is our main event, featuring content from any and all of our
projects, and is your best opportunity to get your project in front of
the largest audience of enthusiasts.

Please don't wait for the last minute. Get your talks in today!

--
Rich Bowen, VP Conferences
The Apache Software Foundation
https://apachecon.com/
@apachecon

[jira] [Reopened] (SLING-8759) Replace the SlingAdaptable.adapterCache with a ConcurrentMap

2021-04-23 Thread Robert Munteanu (Jira)



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

Robert Munteanu reopened SLING-8759:


[~joerghoh] - I don't think this is solved as proposed - there is no 
ConcurrentMap usage. I am not sure if we should just do that. Maybe create a 
follow-up for the conccurent map usage and repurpose this as a code cleanup 
issue?

> Replace the SlingAdaptable.adapterCache with a ConcurrentMap
> 
>
> Key: SLING-8759
> URL: https://issues.apache.org/jira/browse/SLING-8759
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Reporter: Robert Munteanu
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: API 2.23.4
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> The SlingAdaptable.adapterCache is based on a HashMap guarded by a 
> {{synchronized}} block, with lazy initialisation. This looks like a perfect 
> scenario for {{ConcurrentMap.computeIfAbsent}}. The increased memory usage 
> should be measured though, as a simple implementation will not use lazy 
> initialisation, e.g.
> {code}
> diff --git a/src/main/java/org/apache/sling/api/adapter/SlingAdaptable.java 
> b/src/main/java/org/apache/sling/api/adapter/SlingAdaptable.java
> index 5adf0ce..6bed14f 100644
> --- a/src/main/java/org/apache/sling/api/adapter/SlingAdaptable.java
> +++ b/src/main/java/org/apache/sling/api/adapter/SlingAdaptable.java
> @@ -20,6 +20,8 @@ package org.apache.sling.api.adapter;
>  
>  import java.util.HashMap;
>  import java.util.Map;
> +import java.util.concurrent.ConcurrentHashMap;
> +import java.util.concurrent.ConcurrentMap;
>  
>  /**
>   * The SlingAdaptable class is an (abstract) default 
> implementation
> @@ -74,7 +76,7 @@ public abstract class SlingAdaptable implements Adaptable {
>   * are intended to be short-lived to not hold on to objects and classes 
> for
>   * too long.
>   */
> -private Map, Object> adaptersCache;
> +private ConcurrentMap, Object> adaptersCache = new 
> ConcurrentHashMap, Object>();
>  
>  /**
>   * Calls into the registered {@link AdapterManager} to adapt this object 
> to
> @@ -94,22 +96,8 @@ public abstract class SlingAdaptable implements Adaptable {
>   */
>  @SuppressWarnings("unchecked")
>  public  AdapterType adaptTo(Class type) {
> -AdapterType result = null;
> -synchronized ( this ) {
> -if ( adaptersCache != null ) {
> -result = (AdapterType) adaptersCache.get(type);
> -}
> -if ( result == null ) {
> -final AdapterManager mgr = ADAPTER_MANAGER;
> -result = (mgr == null ? null : mgr.getAdapter(this, type));
> -if ( result != null ) {
> -if ( adaptersCache == null ) {
> -adaptersCache = new HashMap, Object>();
> -}
> -adaptersCache.put(type, result);
> -}
> -}
> -}
> -return result;
> +return (AdapterType) adaptersCache.computeIfAbsent(type, (klazz) -> {
> +return ADAPTER_MANAGER.getAdapter(this, type);
> +});
>  }
>  }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

SAML auth handler and additional Maven repo (was: [git] New git repository - org-apache-sling-auth-saml2)

2021-04-23 Thread Robert Munteanu

Hi Cris,

On Fri, 2021-04-23 at 09:31 -0400, Cris Rockwell wrote:
> The OpenSAML library was selected because of the support the Shibboleth
> Consortium has within higher education[0].
> My institution is a member of the consortium. I am confident about the
> ongoing support the project has and the maintenance 
> it receives now and in the future. 
> 
> When it comes to using the OpenSAML library, it’s necessary to follow
> the guidelines about obtaining legitimate versions of the artifacts[1]
> That means using library artifacts provided by the Shibboleth
> Repository, and not using the OpenSAML artifacts from Maven Central.
> 
> It’s also important to use the library for all parts of the process
> when it comes to SAML protocols [2]
> This requires providing lots of dependencies, which the library
> requires

First of all, I don't see the choice of external libraries as an issue,
I am sure that you have chosen well.

My only concern is that the recommendation of not having repositories
and build repositories defined for artifacts deployed to Maven Central.
The official requirements [3] state that:

   In addition we discourage the usage of  and
and instead publish any required components to the
   Central Repository. This applies for your own components as well as for
   3rd party artifacts.

The downsides to using a third party repository are:

- if the Shibbboleth Maven repository is retired, our artifacts become
invalid
- some organisations have strict procurement rules and would require
vetting additional repositories

In the end, I don't think it's a blocker but we should avoid third
party repositories if at all possible.

However, I have filed a PR [4] that removes the extra Maven repository
and the build still passes. If the repository is not actually needed,
the whole discussion is moot :-)

Thanks,
Robert

[3]: https://central.sonatype.org/publish/requirements/
[4]: https://github.com/apache/sling-org-apache-sling-auth-saml2/pull/1

[jira] [Comment Edited] (SLING-10118) Fully cache the GraphQLSchema objects



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

Bertrand Delacretaz edited comment on SLING-10118 at 4/23/21, 2:26 PM:
---

Thank you for the clarification, I understand the "wired" part now. I have 
slightly refactored the schema generation as there was some code duplication, 
in [commit 
9abddb77|https://github.com/apache/sling-org-apache-sling-graphql-core/commit/9abddb77904a079a5c3c58de0901ac576fb6b53f].

As you say the {{GraphQLSchema}} object is created in several steps:
{code:java}
String schemaSdl = prepareSchemaDefinition(schemaProvider, queryResource, 
selectors);
TypeDefinitionRegistry typeDefinitionRegistry = 
getTypeDefinitionRegistry(schemaSdl, queryResource, selectors);
schema = buildSchema(typeDefinitionRegistry, queryResource);
{code}
And currently only the result of {{getTypeDefinitionRegistry}} is cached. 
Caching the {{GraphQLSchema}} objects should be more efficient ([~tyge] do you 
have metrics that demonstrate that?).
h2. How about caching based on a "vary" schema annotation ?

The problem for caching is that the generated schema can potentially depend on 
many things:
 * 1) The Resource to which the query applies, including potentially all its 
attributes
 * 2) The Request's selectors
 * 3) The current set of OSGi services and Sling scripts or servlets, which 
might change at runtime.

However, in practice and especially on production systems it can be safe to 
assume that 3) never changes after startup - which might be expressed by a 
configuration of the GraphQL Core module ("assume stable OSGi services and 
scripts").

To allow whatever generates the schema to indicate what can cause it to change, 
we might use a schema comment similar to the HTTP Vary header:
{code:java}
# sling-schema-vary: resource-type, selectors
{code}
This example value indicates that the generated schema depends only on the 
current resource type and on the request selectors, which is probably true in 
the vast majority of cases.

So I think the below rules would allow us to implement caching of the 
{{GraphQLSchema}} in a simple way, using the resource type + selectors as the 
key:
 * To activate the cache, the "assume stable OSGi services and scripts" option 
must be set. That might actually be a cache lifetime value, where zero disables 
the cache and N meaning "assume stability for N minutes". That N value can then 
define the cache entries time to live.
 * For a specific schema to be cached, it must include the 
{{sling-schema-vary}} comment (or directive, TBD)
 * We initially recognize only {{resource-type}} and {{selectors}} in that 
"vary" value and build the cache keys accordingly.

I think this allows for fully caching the schema generation steps up to the 
creation of the {{GraphQLSchema}} object, with constraints that should be 
acceptable.

WDYT?

/cc [~radu] as I think you wrote the current caching code


was (Author: bdelacretaz):
Thank you for the clarification, I understand the "wired" part now. I have 
slightly refactored the schema generation as there was some code duplication, 
in [commit 
9abddb77|https://github.com/apache/sling-org-apache-sling-graphql-core/commit/9abddb77904a079a5c3c58de0901ac576fb6b53f].

As you say the {{GraphQLSchema}} object is created in several steps:
{code:java}
String schemaSdl = prepareSchemaDefinition(schemaProvider, queryResource, 
selectors);
TypeDefinitionRegistry typeDefinitionRegistry = 
getTypeDefinitionRegistry(schemaSdl, queryResource, selectors);
schema = buildSchema(typeDefinitionRegistry, queryResource);
{code}
And currently only the result of {{getTypeDefinitionRegistry}} is cached. 
Caching the {{GraphQLSchema}} objects should be more efficient ([~tyge] do you 
have metrics that demonstrate that?).
h2. How about caching based on a "vary" schema annotation ?

The problem for caching is that the generated schema can potentially depend on 
many things:
 * 1) The Resource to which the query applies, including potentially all its 
attributes
 * 2) The Request's selectors
 * 3) The current set of OSGi services and Sling scripts or servlets, which 
might change at runtime.

However, in practice and especially on production systems it can be safe to 
assume that 3) never changes after startup - which might be expressed by a 
configuration of the GraphQL Core module ("assume stable OSGi services and 
scripts").

To allow whatever generates the schema to indicate what can cause it to change, 
we might use a schema comment similar to the HTTP Vary header:
{code:java}
# sling-schema-vary: resource-type, selectors
{code}
This example value indicates that the generated schema depends only on the 
current resource type and on the request selectors, which is probably true in 
the vast majority of cases.

So I think the below rules would allow us to implement caching of the

[jira] [Commented] (SLING-10118) Fully cache the GraphQLSchema objects



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

Bertrand Delacretaz commented on SLING-10118:
-

Thank you for the clarification, I understand the "wired" part now. I have 
slightly refactored the schema generation as there was some code duplication, 
in [commit 
9abddb77|https://github.com/apache/sling-org-apache-sling-graphql-core/commit/9abddb77904a079a5c3c58de0901ac576fb6b53f].

As you say the {{GraphQLSchema}} object is created in several steps:

{code}
String schemaSdl = prepareSchemaDefinition(schemaProvider, queryResource, 
selectors);
TypeDefinitionRegistry typeDefinitionRegistry = 
getTypeDefinitionRegistry(schemaSdl, queryResource, selectors);
schema = buildSchema(typeDefinitionRegistry, queryResource);
{code}

And currently only the result of {{getTypeDefinitionRegistry}} is cached. 
Caching the {{GraphQLSchema}} objects should be more efficient ([~tyge] do you 
have metrics that demonstrate that?).

The problem for caching is that the generated schema can potentially depend on 
many things: 

* 1) The Resource to which the query applies, including potentially all its 
attributes
* 2) The Request's selectors
* 3) The current set of OSGi services and Sling scripts or servlets, which 
might change at runtime.

However, in practice and especially on production systems it can be safe to 
assume that 3) never changes after startup - which might be expressed by a 
configuration of the GraphQL Core module ("assume stable OSGi services and 
scripts").

To allow whatever generates the schema to indicate what can cause it to change, 
we might use a schema comment similar to the HTTP Vary header:

{code}
# sling-schema-vary: resource-type, selectors
{code}

This example value indicates that the generated schema depends only on the 
current resource type and on the request selectors, which is probably true in 
the vast majority of cases.

So I think the below rules would allow us to implement caching of the 
{{GraphQLSchema}} in a simple way, using the resource type + selectors as the 
key:

* To activate the cache, the "assume stable OSGi services and scripts" option 
must be set. That might actually be a cache lifetime value, where zero disables 
the cache and N meaning "assume stability for N minutes". That N value can then 
define the cache entries time to live.
* For a specific schema to be cached, it must include the {{sling-schema-vary}} 
comment (or directive, TBD)
* We initially recognize only {{resource-type}} and {{selectors}} in that 
"vary" value and build the cache keys accordingly.

I think this allows for fully caching the schema generation steps up to the 
creation of the {{GraphQLSchema}} object, with constraints that should be 
acceptable.

WDYT?

> Fully cache the GraphQLSchema objects
> -
>
> Key: SLING-10118
> URL: https://issues.apache.org/jira/browse/SLING-10118
> Project: Sling
>  Issue Type: Bug
>  Components: GraphQL
>Affects Versions: GraphQL Core 0.0.10
>Reporter: Thierry Ygé
>Priority: Major
>
> Currently in SLING-10085 the GraphQLSchema couldn't be cached due to wired 
> resource.
> Thus it still need half the time to spend on building the schema, while 
> generally the resource is only used to be passed later to the fetcher. As 
> that resource then change, I suggested to wrap it via a proxy Resource 
> implementation that would be passed instead of the real resource.
> That proxy will then use a map  to lookup for the current resource used at 
> execute/validate time. The key for the map is to use the current thread.
> I will submit a PR with the solution I suggest to use.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (SLING-10118) Fully cache the GraphQLSchema objects



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

Bertrand Delacretaz edited comment on SLING-10118 at 4/23/21, 2:23 PM:
---

Thank you for the clarification, I understand the "wired" part now. I have 
slightly refactored the schema generation as there was some code duplication, 
in [commit 
9abddb77|https://github.com/apache/sling-org-apache-sling-graphql-core/commit/9abddb77904a079a5c3c58de0901ac576fb6b53f].

As you say the {{GraphQLSchema}} object is created in several steps:
{code:java}
String schemaSdl = prepareSchemaDefinition(schemaProvider, queryResource, 
selectors);
TypeDefinitionRegistry typeDefinitionRegistry = 
getTypeDefinitionRegistry(schemaSdl, queryResource, selectors);
schema = buildSchema(typeDefinitionRegistry, queryResource);
{code}
And currently only the result of {{getTypeDefinitionRegistry}} is cached. 
Caching the {{GraphQLSchema}} objects should be more efficient ([~tyge] do you 
have metrics that demonstrate that?).
h2. How about caching based on a "vary" schema annotation ?

The problem for caching is that the generated schema can potentially depend on 
many things:
 * 1) The Resource to which the query applies, including potentially all its 
attributes
 * 2) The Request's selectors
 * 3) The current set of OSGi services and Sling scripts or servlets, which 
might change at runtime.

However, in practice and especially on production systems it can be safe to 
assume that 3) never changes after startup - which might be expressed by a 
configuration of the GraphQL Core module ("assume stable OSGi services and 
scripts").

To allow whatever generates the schema to indicate what can cause it to change, 
we might use a schema comment similar to the HTTP Vary header:
{code:java}
# sling-schema-vary: resource-type, selectors
{code}
This example value indicates that the generated schema depends only on the 
current resource type and on the request selectors, which is probably true in 
the vast majority of cases.

So I think the below rules would allow us to implement caching of the 
{{GraphQLSchema}} in a simple way, using the resource type + selectors as the 
key:
 * To activate the cache, the "assume stable OSGi services and scripts" option 
must be set. That might actually be a cache lifetime value, where zero disables 
the cache and N meaning "assume stability for N minutes". That N value can then 
define the cache entries time to live.
 * For a specific schema to be cached, it must include the 
{{sling-schema-vary}} comment (or directive, TBD)
 * We initially recognize only {{resource-type}} and {{selectors}} in that 
"vary" value and build the cache keys accordingly.

I think this allows for fully caching the schema generation steps up to the 
creation of the {{GraphQLSchema}} object, with constraints that should be 
acceptable.

WDYT?


was (Author: bdelacretaz):
Thank you for the clarification, I understand the "wired" part now. I have 
slightly refactored the schema generation as there was some code duplication, 
in [commit 
9abddb77|https://github.com/apache/sling-org-apache-sling-graphql-core/commit/9abddb77904a079a5c3c58de0901ac576fb6b53f].

As you say the {{GraphQLSchema}} object is created in several steps:

{code}
String schemaSdl = prepareSchemaDefinition(schemaProvider, queryResource, 
selectors);
TypeDefinitionRegistry typeDefinitionRegistry = 
getTypeDefinitionRegistry(schemaSdl, queryResource, selectors);
schema = buildSchema(typeDefinitionRegistry, queryResource);
{code}

And currently only the result of {{getTypeDefinitionRegistry}} is cached. 
Caching the {{GraphQLSchema}} objects should be more efficient ([~tyge] do you 
have metrics that demonstrate that?).

The problem for caching is that the generated schema can potentially depend on 
many things: 

* 1) The Resource to which the query applies, including potentially all its 
attributes
* 2) The Request's selectors
* 3) The current set of OSGi services and Sling scripts or servlets, which 
might change at runtime.

However, in practice and especially on production systems it can be safe to 
assume that 3) never changes after startup - which might be expressed by a 
configuration of the GraphQL Core module ("assume stable OSGi services and 
scripts").

To allow whatever generates the schema to indicate what can cause it to change, 
we might use a schema comment similar to the HTTP Vary header:

{code}
# sling-schema-vary: resource-type, selectors
{code}

This example value indicates that the generated schema depends only on the 
current resource type and on the request selectors, which is probably true in 
the vast majority of cases.

So I think the below rules would allow us to implement caching of the 
{{GraphQLSchema}} in a simple way, using the resource type + selectors as the 
key:

* To activate the cache, the "assume stable OSGi

[jira] [Resolved] (SLING-10308) Sling Dynamic Include - Changing the resulting DOM for JSI

2021-04-23 Thread Dan Klco (Jira)



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

Dan Klco resolved SLING-10308.
--
Resolution: Fixed

Resolved in 
https://github.com/apache/sling-org-apache-sling-dynamic-include/commit/b8046c97a21c7e5051b524dd74e4d8a834cc574d

> Sling Dynamic Include - Changing the resulting DOM for JSI
> --
>
> Key: SLING-10308
> URL: https://issues.apache.org/jira/browse/SLING-10308
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Dynamic Include 3.2.0
>Reporter: Maximilian Voss
>Assignee: Dan Klco
>Priority: Major
>
> Using Java Script Include will result into a different DOM as it will include 
> a div in which the component is nested as well as a script tag next to the 
> div.
> Especially if JSI is used for container components which are relying on the 
> underlying DOM structure this will result into issues, e.g. Slick Carousel 
> which interprets the script tag as carousel slide.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (SLING-10118) Fully cache the GraphQLSchema objects



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

Bertrand Delacretaz updated SLING-10118:

Summary: Fully cache the GraphQLSchema objects  (was: Fully cache 
GraphQLSchema)

> Fully cache the GraphQLSchema objects
> -
>
> Key: SLING-10118
> URL: https://issues.apache.org/jira/browse/SLING-10118
> Project: Sling
>  Issue Type: Bug
>  Components: GraphQL
>Affects Versions: GraphQL Core 0.0.10
>Reporter: Thierry Ygé
>Priority: Major
>
> Currently in SLING-10085 the GraphQLSchema couldn't be cached due to wired 
> resource.
> Thus it still need half the time to spend on building the schema, while 
> generally the resource is only used to be passed later to the fetcher. As 
> that resource then change, I suggested to wrap it via a proxy Resource 
> implementation that would be passed instead of the real resource.
> That proxy will then use a map  to lookup for the current resource used at 
> execute/validate time. The key for the map is to use the current thread.
> I will submit a PR with the solution I suggest to use.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (SLING-10308) Sling Dynamic Include - Changing the resulting DOM for JSI

2021-04-23 Thread Dan Klco (Jira)



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

Dan Klco reassigned SLING-10308:


Assignee: Dan Klco

> Sling Dynamic Include - Changing the resulting DOM for JSI
> --
>
> Key: SLING-10308
> URL: https://issues.apache.org/jira/browse/SLING-10308
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Dynamic Include 3.2.0
>Reporter: Maximilian Voss
>Assignee: Dan Klco
>Priority: Major
>
> Using Java Script Include will result into a different DOM as it will include 
> a div in which the component is nested as well as a script tag next to the 
> div.
> Especially if JSI is used for container components which are relying on the 
> underlying DOM structure this will result into issues, e.g. Slick Carousel 
> which interprets the script tag as carousel slide.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [sling-org-apache-sling-dynamic-include] klcodanr merged pull request #20: Moving the JS calling part into the DIV, thus it get replaced after d…



klcodanr merged pull request #20:
URL: https://github.com/apache/sling-org-apache-sling-dynamic-include/pull/20


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [git] New git repository - org-apache-sling-auth-saml2

2021-04-23 Thread Cris Rockwell

Hi Robert

Regarding

"Note that we still need to clarify the status of the additional Maven
artifact repository [1] and probably need to review the deps (there are
lots of them) before starting a release. But that's for later."

I aware there are many dependencies in this project
[1]: 
https://github.com/apache/sling-org-apache-sling-auth-saml2/blob/master/pom.xml 

 


Here’s some snippets about the bundle. 

Bundle Classpath
.,metrics-core-4.1.9.jar,guava-28.2-jre.jar,failureaccess-1.0.1.jar,checker-qual-2.11.1.jar,opensaml-core-4.0.1.jar,opensaml-saml-impl-4.0.1.jar,opensaml-saml-api-4.0.1.jar,opensaml-xmlsec-api-4.0.1.jar,opensaml-xmlsec-impl-4.0.1.jar,opensaml-security-api-4.0.1.jar,opensaml-security-impl-4.0.1.jar,opensaml-storage-api-4.0.1.jar,opensaml-profile-api-4.0.1.jar,opensaml-messaging-api-4.0.1.jar,opensaml-soap-api-4.0.1.jar,opensaml-soap-impl-4.0.1.jar,java-support-8.0.0.jar,velocity-1.7.jar,commons-lang-2.6.jar,error_prone_annotations-2.3.4.jar,xmlsec-2.1.4.jar,cryptacular-1.2.4.jar

Exported Packages   org.apache.sling.auth.saml2,version=1.0.0

Imported Packages   javax.annotation,version=1.3.0 from 
org.apache.geronimo.specs.geronimo-annotation_1.3_spec (7) 

javax.crypto,version=0.0.0.JavaSE_011 from org.apache.felix.framework (0) 

javax.crypto.spec,version=0.0.0.JavaSE_011 from org.apache.felix.framework (0) 

javax.jcr,version=2.0.0 from org.apache.sling.jcr.jcr-wrapper (112) 

javax.jcr,version=1.1.0 from org.apache.sling.jcr.jcr-wrapper (112) 

javax.lang.model.element,version=0.0.0.JavaSE_011 from 
org.apache.felix.framework (0) 
javax.naming,version=0.0.0.JavaSE_011 from org.apache.felix.framework (0) 

javax.net,version=0.0.0.JavaSE_011 from org.apache.felix.framework (0) 

javax.net.ssl,version=0.0.0.JavaSE_011 from org.apache.felix.framework (0) 

javax.script,version=0.0.0.JavaSE_011 from org.apache.felix.framework (0) 

javax.security.auth,version=0.0.0.JavaSE_011 from org.apache.felix.framework 
(0) 
javax.security.auth.callback,version=0.0.0.JavaSE_011 from 
org.apache.felix.framework (0) 
javax.security.auth.login,version=0.0.0.JavaSE_011 from 
org.apache.felix.framework (0) 
javax.security.auth.x500,version=0.0.0.JavaSE_011 from 
org.apache.felix.framework (0) 
javax.servlet,version=2.6.0 from org.apache.felix.http.servlet-api (43) 

javax.servlet,version=3.1.0 from org.apache.felix.http.servlet-api (43) 

javax.servlet,version=3.0.0 from org.apache.felix.http.servlet-api (43) 

javax.servlet.http,version=2.6.0 from org.apache.felix.http.servlet-api (43) 

javax.servlet.http,version=3.1.0 from org.apache.felix.http.servlet-api (43) 

javax.servlet.http,version=3.0.0 from org.apache.felix.http.servlet-api (43) 

javax.sql,version=0.0.0.JavaSE_011 from org.apache.felix.framework (0) 

javax.xml.crypto,version=0.0.0.JavaSE_011 from org.apache.felix.framework (0) 

javax.xml.crypto.dom,version=0.0.0.JavaSE_011 from org.apache.felix.framework 
(0) 
javax.xml.crypto.dsig,version=0.0.0.JavaSE_011 from org.apache.felix.framework 
(0) 
javax.xml.crypto.dsig.dom,version=0.0.0.JavaSE_011 from 
org.apache.felix.framework (0) 
javax.xml.crypto.dsig.keyinfo,version=0.0.0.JavaSE_011 from 
org.apache.felix.framework (0) 
javax.xml.crypto.dsig.spec,version=0.0.0.JavaSE_011 from 
org.apache.felix.framework (0) 
javax.xml.datatype,version=2.1.0 from org.apache.felix.framework (0) 

javax.xml.namespace,version=2.1.0 from org.apache.felix.framework (0) 

javax.xml.parsers,version=2.1.0 from org.apache.felix.framework

Re: Releasing new Sling API?

2021-04-23 Thread Jörg Hoh

Hi,

The only outstanding issue is SLING-8742, for which Robert mentioned, that
he won't work on it. The remaining ones are resolved.
If there's no objection in the next days, I would like to try my very first
release for Sling API 2.23.4 next week.

Jörg

Am Di., 6. Apr. 2021 um 11:59 Uhr schrieb Robert Munteanu <
romb...@apache.org>:

> Hi,
>
> On Thu, 2021-04-01 at 20:06 +0200, Bertrand Delacretaz wrote:
> > I'm not planning to work on any of those at the moment but I see that
> > https://issues.apache.org/jira/browse/SLING-8742 has an unanswered
> > question.
>
> I clarified that this is not on my TODO list for the short term.
>
> Thanks,
> Robert
>
>

-- 
Cheers,
Jörg Hoh,

https://cqdump.joerghoh.de
Twitter: @joerghoh

[jira] [Resolved] (SLING-8759) Replace the SlingAdaptable.adapterCache with a ConcurrentMap



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

Joerg Hoh resolved SLING-8759.
--
Resolution: Fixed

> Replace the SlingAdaptable.adapterCache with a ConcurrentMap
> 
>
> Key: SLING-8759
> URL: https://issues.apache.org/jira/browse/SLING-8759
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Reporter: Robert Munteanu
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: API 2.23.4
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> The SlingAdaptable.adapterCache is based on a HashMap guarded by a 
> {{synchronized}} block, with lazy initialisation. This looks like a perfect 
> scenario for {{ConcurrentMap.computeIfAbsent}}. The increased memory usage 
> should be measured though, as a simple implementation will not use lazy 
> initialisation, e.g.
> {code}
> diff --git a/src/main/java/org/apache/sling/api/adapter/SlingAdaptable.java 
> b/src/main/java/org/apache/sling/api/adapter/SlingAdaptable.java
> index 5adf0ce..6bed14f 100644
> --- a/src/main/java/org/apache/sling/api/adapter/SlingAdaptable.java
> +++ b/src/main/java/org/apache/sling/api/adapter/SlingAdaptable.java
> @@ -20,6 +20,8 @@ package org.apache.sling.api.adapter;
>  
>  import java.util.HashMap;
>  import java.util.Map;
> +import java.util.concurrent.ConcurrentHashMap;
> +import java.util.concurrent.ConcurrentMap;
>  
>  /**
>   * The SlingAdaptable class is an (abstract) default 
> implementation
> @@ -74,7 +76,7 @@ public abstract class SlingAdaptable implements Adaptable {
>   * are intended to be short-lived to not hold on to objects and classes 
> for
>   * too long.
>   */
> -private Map, Object> adaptersCache;
> +private ConcurrentMap, Object> adaptersCache = new 
> ConcurrentHashMap, Object>();
>  
>  /**
>   * Calls into the registered {@link AdapterManager} to adapt this object 
> to
> @@ -94,22 +96,8 @@ public abstract class SlingAdaptable implements Adaptable {
>   */
>  @SuppressWarnings("unchecked")
>  public  AdapterType adaptTo(Class type) {
> -AdapterType result = null;
> -synchronized ( this ) {
> -if ( adaptersCache != null ) {
> -result = (AdapterType) adaptersCache.get(type);
> -}
> -if ( result == null ) {
> -final AdapterManager mgr = ADAPTER_MANAGER;
> -result = (mgr == null ? null : mgr.getAdapter(this, type));
> -if ( result != null ) {
> -if ( adaptersCache == null ) {
> -adaptersCache = new HashMap, Object>();
> -}
> -adaptersCache.put(type, result);
> -}
> -}
> -}
> -return result;
> +return (AdapterType) adaptersCache.computeIfAbsent(type, (klazz) -> {
> +return ADAPTER_MANAGER.getAdapter(this, type);
> +});
>  }
>  }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Sling Declarative Dynamic Resources

2021-04-23 Thread Ruben Reusser


Carsten,

I think I understand your security concern - do you see another way to 
solve this in that case?


Ruben

On 4/22/2021 10:31 PM, Carsten Ziegeler wrote:

Thanks Ruben,

in my opinion /apps belongs to developers. In our case its immutable 
for good reasons. Drilling a hole into this and allowing non 
developers contribute to /apps, especially in a dynamic fashion 
circumventing the immutability sounds very risky and can result in 
security problems.


I understand that extra configuration options are added to partially 
address this, but then it comes down to how effective these are and 
what holes they might have.


Now, in general I'm not against a feature like dynamic resources - but 
making something immutable mutable especially for a different audience 
is too dangerous.


Regards
Carsten

[jira] [Comment Edited] (SLING-10118) Fully cache GraphQLSchema

2021-04-23 Thread Jira



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

Thierry Ygé edited comment on SLING-10118 at 4/23/21, 12:19 PM:


[~bdelacretaz] the current implementation is not fully caching the GraphQL 
Schema, only the first part to extract the type definition is cached, then it 
need to inject the resource in the buildWiring method, to finally get the 
schema object ready to be used (execute or validate). Wiring resource is the 
term used in (1).

This PR aim to fully cache it, so that we gain the extra time it needs to build 
the schema (which grows linearly with the size of the SDL).

(1) 
[https://github.com/apache/sling-org-apache-sling-graphql-core/blob/master/src/main/java/org/apache/sling/graphql/core/engine/DefaultQueryExecutor.java#L375]


was (Author: petitbear68):
[~bdelacretaz] the current implementation is not fully caching the GraphQL 
Schema, only the first part is cached, then it need to inject the resource , to 
finally get the schema object ready to be used (execute or validate). Wiring 
resource is the term used in (1).

This PR aim to fully cache it, so that we gain the extra time it needs to build 
the schema (which grows linearly with the size of the SDL).

(1) 
https://github.com/apache/sling-org-apache-sling-graphql-core/blob/master/src/main/java/org/apache/sling/graphql/core/engine/DefaultQueryExecutor.java#L375

> Fully cache GraphQLSchema
> -
>
> Key: SLING-10118
> URL: https://issues.apache.org/jira/browse/SLING-10118
> Project: Sling
>  Issue Type: Bug
>  Components: GraphQL
>Affects Versions: GraphQL Core 0.0.10
>Reporter: Thierry Ygé
>Priority: Major
>
> Currently in SLING-10085 the GraphQLSchema couldn't be cached due to wired 
> resource.
> Thus it still need half the time to spend on building the schema, while 
> generally the resource is only used to be passed later to the fetcher. As 
> that resource then change, I suggested to wrap it via a proxy Resource 
> implementation that would be passed instead of the real resource.
> That proxy will then use a map  to lookup for the current resource used at 
> execute/validate time. The key for the map is to use the current thread.
> I will submit a PR with the solution I suggest to use.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [sling-org-apache-sling-servlets-resolver] sonarcloud[bot] commented on pull request #7: [SLING-9230] - Servlet should not be allowed to register with invalid…



sonarcloud[bot] commented on pull request #7:
URL: 
https://github.com/apache/sling-org-apache-sling-servlets-resolver/pull/7#issuecomment-825619009


   SonarCloud Quality Gate failed.
   
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=BUG)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=BUG)
 [0 
Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=BUG)
  
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=VULNERABILITY)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=VULNERABILITY)
 [0 
Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=VULNERABILITY)
  
   [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-servlets-resolver=7=false=SECURITY_HOTSPOT)
 [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-servlets-resolver=7=false=SECURITY_HOTSPOT)
 [0 Security 
Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-servlets-resolver=7=false=SECURITY_HOTSPOT)
  
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=CODE_SMELL)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=CODE_SMELL)
 [0 Code 
Smells](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=CODE_SMELL)
   
   [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-servlets-resolver=7=new_coverage=list)
 [70.0% 
Coverage](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-servlets-resolver=7=new_coverage=list)
  
   [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-servlets-resolver=7=new_duplicated_lines_density=list)
 [0.0% 
Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-servlets-resolver=7=new_duplicated_lines_density=list)
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [sling-org-apache-sling-servlets-resolver] sonarcloud[bot] removed a comment on pull request #7: [SLING-9230] - Servlet should not be allowed to register with invalid…



sonarcloud[bot] removed a comment on pull request #7:
URL: 
https://github.com/apache/sling-org-apache-sling-servlets-resolver/pull/7#issuecomment-825121992


   SonarCloud Quality Gate failed.
   
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=BUG)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=BUG)
 [0 
Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=BUG)
  
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=VULNERABILITY)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=VULNERABILITY)
 [0 
Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=VULNERABILITY)
  
   [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-servlets-resolver=7=false=SECURITY_HOTSPOT)
 [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-servlets-resolver=7=false=SECURITY_HOTSPOT)
 [0 Security 
Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-servlets-resolver=7=false=SECURITY_HOTSPOT)
  
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=CODE_SMELL)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=CODE_SMELL)
 [0 Code 
Smells](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-servlets-resolver=7=false=CODE_SMELL)
   
   [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-servlets-resolver=7=new_coverage=list)
 [70.0% 
Coverage](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-servlets-resolver=7=new_coverage=list)
  
   [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-servlets-resolver=7=new_duplicated_lines_density=list)
 [0.0% 
Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-servlets-resolver=7=new_duplicated_lines_density=list)
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (SLING-10118) Fully cache GraphQLSchema

2021-04-23 Thread Jira



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

Thierry Ygé commented on SLING-10118:
-

[~bdelacretaz] the current implementation is not fully caching the GraphQL 
Schema, only the first part is cached, then it need to inject the resource , to 
finally get the schema object ready to be used (execute or validate). Wiring 
resource is the term used in (1).

This PR aim to fully cache it, so that we gain the extra time it needs to build 
the schema (which grows linearly with the size of the SDL).

(1) 
https://github.com/apache/sling-org-apache-sling-graphql-core/blob/master/src/main/java/org/apache/sling/graphql/core/engine/DefaultQueryExecutor.java#L375

> Fully cache GraphQLSchema
> -
>
> Key: SLING-10118
> URL: https://issues.apache.org/jira/browse/SLING-10118
> Project: Sling
>  Issue Type: Bug
>  Components: GraphQL
>Affects Versions: GraphQL Core 0.0.10
>Reporter: Thierry Ygé
>Priority: Major
>
> Currently in SLING-10085 the GraphQLSchema couldn't be cached due to wired 
> resource.
> Thus it still need half the time to spend on building the schema, while 
> generally the resource is only used to be passed later to the fetcher. As 
> that resource then change, I suggested to wrap it via a proxy Resource 
> implementation that would be passed instead of the real resource.
> That proxy will then use a map  to lookup for the current resource used at 
> execute/validate time. The key for the map is to use the current thread.
> I will submit a PR with the solution I suggest to use.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [sling-org-apache-sling-graphql-core] bdelacretaz commented on pull request #18: SLING-10118 Fully cache GraphQLSchema



bdelacretaz commented on pull request #18:
URL: 
https://github.com/apache/sling-org-apache-sling-graphql-core/pull/18#issuecomment-825616000


   Before reviewing this, I have asked clarification questions in SLING-10118 
as I don't really understand what this aims to fix.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (SLING-10118) Fully cache GraphQLSchema



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

Bertrand Delacretaz commented on SLING-10118:
-

bq. in SLING-10085 the GraphQLSchema couldn't be cached due to wired 
resource

I don't understand, does that mean the SLING-10085 caching is not working? Not 
sure what you mean by "wired resource", can you clarify?

bq. The key for the map is to use the current thread...

I don't understand this either, maybe clarifying the "wired resource" term will 
also clarify this?

> Fully cache GraphQLSchema
> -
>
> Key: SLING-10118
> URL: https://issues.apache.org/jira/browse/SLING-10118
> Project: Sling
>  Issue Type: Bug
>  Components: GraphQL
>Affects Versions: GraphQL Core 0.0.10
>Reporter: Thierry Ygé
>Priority: Major
>
> Currently in SLING-10085 the GraphQLSchema couldn't be cached due to wired 
> resource.
> Thus it still need half the time to spend on building the schema, while 
> generally the resource is only used to be passed later to the fetcher. As 
> that resource then change, I suggested to wrap it via a proxy Resource 
> implementation that would be passed instead of the real resource.
> That proxy will then use a map  to lookup for the current resource used at 
> execute/validate time. The key for the map is to use the current thread.
> I will submit a PR with the solution I suggest to use.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [sling-org-apache-sling-api] joerghoh merged pull request #26: SLING-8759 use computeIfAbsent to reduce code size



joerghoh merged pull request #26:
URL: https://github.com/apache/sling-org-apache-sling-api/pull/26


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [sling-org-apache-sling-api] sonarcloud[bot] commented on pull request #26: SLING-8759 use computeIfAbsent to reduce code size



sonarcloud[bot] commented on pull request #26:
URL: 
https://github.com/apache/sling-org-apache-sling-api/pull/26#issuecomment-825614326


   Kudos, SonarCloud Quality Gate passed!
   
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=26=false=BUG)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=26=false=BUG)
 [0 
Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=26=false=BUG)
  
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=26=false=VULNERABILITY)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=26=false=VULNERABILITY)
 [0 
Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=26=false=VULNERABILITY)
  
   [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-api=26=false=SECURITY_HOTSPOT)
 [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-api=26=false=SECURITY_HOTSPOT)
 [0 Security 
Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-api=26=false=SECURITY_HOTSPOT)
  
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=26=false=CODE_SMELL)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=26=false=CODE_SMELL)
 [0 Code 
Smells](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=26=false=CODE_SMELL)
   
   [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-api=26=new_coverage=list)
 [100.0% 
Coverage](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-api=26=new_coverage=list)
  
   [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-api=26=new_duplicated_lines_density=list)
 [0.0% 
Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-api=26=new_duplicated_lines_density=list)
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [sling-org-apache-sling-api] sonarcloud[bot] removed a comment on pull request #26: SLING-8759 use computeIfAbsent to reduce code size



sonarcloud[bot] removed a comment on pull request #26:
URL: 
https://github.com/apache/sling-org-apache-sling-api/pull/26#issuecomment-821067059


   Kudos, SonarCloud Quality Gate passed!
   
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=26=false=BUG)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=26=false=BUG)
 [0 
Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=26=false=BUG)
  
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=26=false=VULNERABILITY)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=26=false=VULNERABILITY)
 [0 
Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=26=false=VULNERABILITY)
  
   [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-api=26=false=SECURITY_HOTSPOT)
 [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-api=26=false=SECURITY_HOTSPOT)
 [0 Security 
Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-api=26=false=SECURITY_HOTSPOT)
  
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=26=false=CODE_SMELL)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=26=false=CODE_SMELL)
 [0 Code 
Smells](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=26=false=CODE_SMELL)
   
   [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-api=26=new_coverage=list)
 [100.0% 
Coverage](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-api=26=new_coverage=list)
  
   [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-api=26=new_duplicated_lines_density=list)
 [0.0% 
Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-api=26=new_duplicated_lines_density=list)
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [sling-org-apache-sling-graphql-core] raducotescu commented on a change in pull request #18: SLING-10118 Fully cache GraphQLSchema



raducotescu commented on a change in pull request #18:
URL: 
https://github.com/apache/sling-org-apache-sling-graphql-core/pull/18#discussion_r619019334



##
File path: 
src/main/java/org/apache/sling/graphql/core/engine/DefaultQueryExecutor.java
##
@@ -147,8 +147,8 @@ public ValidationResult validate(@NotNull String query, 
@NotNull Maphttp://www.apache.org/licenses/LICENSE-2.0
+ ~
+ ~ Unless required by applicable law or agreed to in writing,
+ ~ software distributed under the License is distributed on an
+ ~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ ~ KIND, either express or implied.  See the License for the
+ ~ specific language governing permissions and limitations
+ ~ under the License.
+ 
~*/
+package org.apache.sling.graphql.core.engine;
+
+import org.apache.sling.api.resource.Resource;
+import org.apache.sling.api.resource.ResourceMetadata;
+import org.apache.sling.api.resource.ResourceResolver;
+import org.apache.sling.api.resource.ValueMap;
+import org.jetbrains.annotations.NotNull;
+import org.jetbrains.annotations.Nullable;
+
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.Iterator;
+import java.util.Map;
+
+class CurrentThreadResource implements Resource {
+
+private static final Map mappedResources = 
Collections.synchronizedMap(new HashMap<>());
+
+/**
+ * @return the resource assigned to current thread
+ */
+private static Resource getCurrentResource() {
+return mappedResources.get(Thread.currentThread());
+}
+
+/**
+ * @param resource the resource assigned to current thread
+ */
+static void setCurrentResource(final Resource resource) {
+mappedResources.putIfAbsent(Thread.currentThread(), resource);
+}
+
+/**
+ * Remove existing map entry for current thread
+ */
+static void dispose() {
+mappedResources.remove(Thread.currentThread());
+}
+
+@Override
+public @NotNull String getPath() {
+return getCurrentResource().getPath();
+}
+
+@Override
+public @NotNull String getName() {
+return getCurrentResource().getName();
+}
+
+@Override
+public @Nullable Resource getParent() {
+return getCurrentResource().getParent();
+}
+
+@Override
+public @NotNull Iterator listChildren() {
+return getCurrentResource().listChildren();
+}
+
+@Override
+public @NotNull Iterable getChildren() {
+return getCurrentResource().getChildren();
+}
+
+@Override
+public @Nullable Resource getChild(@NotNull String s) {
+return getCurrentResource().getChild(s);
+}
+
+@Override
+public @NotNull String getResourceType() {
+return getCurrentResource().getResourceType();
+}
+
+@Override
+public @Nullable String getResourceSuperType() {
+return getCurrentResource().getResourceSuperType();
+}
+
+@Override
+public boolean hasChildren() {
+return getCurrentResource().hasChildren();
+}
+
+@Override
+public boolean isResourceType(String s) {
+return getCurrentResource().isResourceType(s);
+}
+
+@Override
+public @NotNull ResourceMetadata getResourceMetadata() {
+return getCurrentResource().getResourceMetadata();
+}
+
+@Override
+public @NotNull ResourceResolver getResourceResolver() {
+return getCurrentResource().getResourceResolver();

Review comment:
   This resource resolver might be already closed when the actual resource 
will be used and I don't know how you could refetch it with the same 
authentication details.

##
File path: 
src/main/java/org/apache/sling/graphql/core/engine/DefaultQueryExecutor.java
##
@@ -147,8 +147,8 @@ public ValidationResult validate(@NotNull String query, 
@NotNull Map

[GitHub] [sling-org-apache-sling-graphql-core] sonarcloud[bot] commented on pull request #18: SLING-10118 Fully cache GraphQLSchema



sonarcloud[bot] commented on pull request #18:
URL: 
https://github.com/apache/sling-org-apache-sling-graphql-core/pull/18#issuecomment-825558716


   Kudos, SonarCloud Quality Gate passed!
   
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-graphql-core=18=false=BUG)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-graphql-core=18=false=BUG)
 [0 
Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-graphql-core=18=false=BUG)
  
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-graphql-core=18=false=VULNERABILITY)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-graphql-core=18=false=VULNERABILITY)
 [0 
Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-graphql-core=18=false=VULNERABILITY)
  
   [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-graphql-core=18=false=SECURITY_HOTSPOT)
 [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-graphql-core=18=false=SECURITY_HOTSPOT)
 [0 Security 
Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-graphql-core=18=false=SECURITY_HOTSPOT)
  
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-graphql-core=18=false=CODE_SMELL)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-graphql-core=18=false=CODE_SMELL)
 [1 Code 
Smell](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-graphql-core=18=false=CODE_SMELL)
   
   [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-graphql-core=18=new_coverage=list)
 [100.0% 
Coverage](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-graphql-core=18=new_coverage=list)
  
   [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-graphql-core=18=new_duplicated_lines_density=list)
 [0.0% 
Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-graphql-core=18=new_duplicated_lines_density=list)
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Updated] (SLING-10326) Include scheduled jobs for sling jobs inventory printer



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

Natalia Angulo Herrera updated SLING-10326:
---
Issue Type: Improvement  (was: Bug)

> Include scheduled jobs for sling jobs inventory printer
> ---
>
> Key: SLING-10326
> URL: https://issues.apache.org/jira/browse/SLING-10326
> Project: Sling
>  Issue Type: Improvement
>  Components: Feature InventoryPrinters
>Reporter: Natalia Angulo Herrera
>Priority: Major
>
> Sling Jobs InventoryPrinter is returning scheduled jobs in text format but it 
> is not doing it for JSON format. Include them in the json printer as well 
> [https://github.com/apache/sling-org-apache-sling-event/blob/8ff61f84b80cb62dd52ffc41a6c2d08457548cb6/src/main/java/org/apache/sling/event/impl/jobs/console/InventoryPlugin.java#L186]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (SLING-10326) Include scheduled jobs for sling jobs inventory printer



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

Natalia Angulo Herrera updated SLING-10326:
---
Issue Type: Bug  (was: Improvement)

> Include scheduled jobs for sling jobs inventory printer
> ---
>
> Key: SLING-10326
> URL: https://issues.apache.org/jira/browse/SLING-10326
> Project: Sling
>  Issue Type: Bug
>  Components: Feature InventoryPrinters
>Reporter: Natalia Angulo Herrera
>Priority: Major
>
> Sling Jobs InventoryPrinter is returning scheduled jobs in text format but it 
> is not doing it for JSON format. Include them in the json printer as well 
> [https://github.com/apache/sling-org-apache-sling-event/blob/8ff61f84b80cb62dd52ffc41a6c2d08457548cb6/src/main/java/org/apache/sling/event/impl/jobs/console/InventoryPlugin.java#L186]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (SLING-10326) Include scheduled jobs for sling jobs inventory printer



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

Natalia Angulo Herrera updated SLING-10326:
---
Component/s: Feature InventoryPrinters

> Include scheduled jobs for sling jobs inventory printer
> ---
>
> Key: SLING-10326
> URL: https://issues.apache.org/jira/browse/SLING-10326
> Project: Sling
>  Issue Type: Improvement
>  Components: Feature InventoryPrinters
>Reporter: Natalia Angulo Herrera
>Priority: Major
>
> Sling Jobs InventoryPrinter is returning scheduled jobs in text format but it 
> is not doing it for JSON format. Include them in the json printer as well 
> [https://github.com/apache/sling-org-apache-sling-event/blob/8ff61f84b80cb62dd52ffc41a6c2d08457548cb6/src/main/java/org/apache/sling/event/impl/jobs/console/InventoryPlugin.java#L186]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (SLING-10326) Include scheduled jobs for sling jobs inventory printer

Natalia Angulo Herrera created SLING-10326:
--

 Summary: Include scheduled jobs for sling jobs inventory printer
 Key: SLING-10326
 URL: https://issues.apache.org/jira/browse/SLING-10326
 Project: Sling
  Issue Type: Improvement
Reporter: Natalia Angulo Herrera


Sling Jobs InventoryPrinter is returning scheduled jobs in text format but it 
is not doing it for JSON format. Include them in the json printer as well 
[https://github.com/apache/sling-org-apache-sling-event/blob/8ff61f84b80cb62dd52ffc41a6c2d08457548cb6/src/main/java/org/apache/sling/event/impl/jobs/console/InventoryPlugin.java#L186]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [sling-org-apache-sling-dynamic-include] rombert commented on pull request #20: Moving the JS calling part into the DIV, thus it get replaced after d…



rombert commented on pull request #20:
URL: 
https://github.com/apache/sling-org-apache-sling-dynamic-include/pull/20#issuecomment-825472107


   Code overall LGTM but it is way out of my area of expertise regarding 
dynamic includes . @klcodanr  - maybe you can review?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Resolved] (SLING-10289) Sling Dynamic Include 3.2.0 configuration of arrays broken

2021-04-23 Thread Robert Munteanu (Jira)



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

Robert Munteanu resolved SLING-10289.
-
  Assignee: Robert Munteanu
Resolution: Fixed

Merged, thanks [~AndreasWurm]!

> Sling Dynamic Include 3.2.0 configuration of arrays broken
> --
>
> Key: SLING-10289
> URL: https://issues.apache.org/jira/browse/SLING-10289
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Dynamic Include 3.2.0
>Reporter: Andreas Wurm
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Dynamic Include 3.3.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> XML config like this stopped working > 3.1.6 and will only pick up first value
> {code:java}
> include-filter.config.resource-types="[wcm/components/content/downloadteaser,wcm/components/static/menu,wcm/components/static/menuflyout]"{code}
> fixed this by changing the Configuration Attribute to String[]
> {code:java}
>   @AttributeDefinition(name = "Resource types",
>   description = "Filter will replace components with selected 
> resource types",
>   type = AttributeType.STRING)
>   String[] include$_$filter_config_resource$_$types() default {};{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [sling-org-apache-sling-dynamic-include] rombert merged pull request #21: SLING-10289 fix array configuration



rombert merged pull request #21:
URL: https://github.com/apache/sling-org-apache-sling-dynamic-include/pull/21


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [sling-org-apache-sling-dynamic-include] rombert commented on pull request #21: SLING-10289 fix array configuration