[jira] [Updated] (SLING-9353) Failure to install replication package not accounted for in metrics

[Alexei Krainiouk (Jira)]

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

Alexei Krainiouk updated SLING-9353:

Description: 
The problem is that all exception thrown by installPackage are caught in
 
[ContentPackageExtractor.handle(...)|https://github.com/apache/sling-org-apache-sling-distribution-journal]
 method and turned into DistributionException.
However the [code responsible for 
reporting|https://github.com/apache/sling-org-apache-sling-distribution-journal]
 replication failures is not set to catch DistributionException

The fix is submitted in this pull request: 
https://github.com/apache/sling-org-apache-sling-distribution-journal/pull/27

  was:
The problem is that all exception thrown by installPackage are caught in
 
[ContentPackageExtractor.handle(...)|https://github.com/apache/sling-org-apache-sling-distribution-journal]
 method and turned into DistributionException.
However the [code responsible for 
reporting|https://github.com/apache/sling-org-apache-sling-distribution-journal]
 replication failures is not set to catch DistributionException

 

This apparently is the real root cause for 
[SKYOPS-5037|https://jira.corp.adobe.com/browse/SKYOPS-5037] as well.


> Failure to install replication package not accounted for in metrics
> ---
>
> Key: SLING-9353
> URL: https://issues.apache.org/jira/browse/SLING-9353
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Reporter: Alexei Krainiouk
>Priority: Blocker
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The problem is that all exception thrown by installPackage are caught in
>  
> [ContentPackageExtractor.handle(...)|https://github.com/apache/sling-org-apache-sling-distribution-journal]
>  method and turned into DistributionException.
> However the [code responsible for 
> reporting|https://github.com/apache/sling-org-apache-sling-distribution-journal]
>  replication failures is not set to catch DistributionException
> The fix is submitted in this pull request: 
> https://github.com/apache/sling-org-apache-sling-distribution-journal/pull/27



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

[jira] [Created] (SLING-9353) Failure to install replication package not accounted for in metrics

[Alexei Krainiouk (Jira)]

Alexei Krainiouk created SLING-9353:
---

 Summary: Failure to install replication package not accounted for 
in metrics
 Key: SLING-9353
 URL: https://issues.apache.org/jira/browse/SLING-9353
 Project: Sling
  Issue Type: Bug
  Components: Content Distribution
Reporter: Alexei Krainiouk


The problem is that all exception thrown by installPackage are caught in
 
[ContentPackageExtractor.handle(...)|https://github.com/apache/sling-org-apache-sling-distribution-journal]
 method and turned into DistributionException.
However the [code responsible for 
reporting|https://github.com/apache/sling-org-apache-sling-distribution-journal]
 replication failures is not set to catch DistributionException

 

This apparently is the real root cause for 
[SKYOPS-5037|https://jira.corp.adobe.com/browse/SKYOPS-5037] as well.



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

[jira] [Resolved] (SLING-9328) Allow loading template libraries from bundles

[Radu Cotescu (Jira)]

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

Radu Cotescu resolved SLING-9328.
-
Resolution: Fixed

Implemented in [commit 
fde8c6e|https://github.com/apache/sling-org-apache-sling-scripting-sightly/commit/fde8c6e].

> Allow loading template libraries from bundles
> -
>
> Key: SLING-9328
> URL: https://issues.apache.org/jira/browse/SLING-9328
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting HTL Engine 1.4.0-1.4.0
>
>
> The HTL engine allows defining template libraries (i.e. a file providing a 
> collection of templates), which can then be referenced so that a certain 
> template is loaded. With the option of providing HTL files as either bundled 
> scripts or precompiled {{RenderUnits}}, the {{RenderUnitProvider}} needs to 
> be enhanced so that it attempts to resolve the template libraries either in 
> the bundle providing the current {{RenderUnit}} or in the wired bundles.



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

[jira] [Resolved] (SLING-9343) Versions of o.a.s.scripting.sightly bundles different from artifact versions

[Radu Cotescu (Jira)]

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

Radu Cotescu resolved SLING-9343.
-
Resolution: Fixed

Fixed in:
# [commit 
a0f0e77|https://github.com/apache/sling-org-apache-sling-scripting-sightly/commit/a0f0e77]
# [commit 
98844b8|https://github.com/apache/sling-org-apache-sling-scripting-sightly-compiler/commit/98844b8]
# [commit 
b5892a9|https://github.com/apache/sling-org-apache-sling-scripting-sightly-compiler-java/commit/b5892a9]
# [commit 
2990c35|https://github.com/apache/sling-org-apache-sling-scripting-sightly-runtime/commit/2990c35]

> Versions of o.a.s.scripting.sightly bundles different from artifact versions
> 
>
> Key: SLING-9343
> URL: https://issues.apache.org/jira/browse/SLING-9343
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting HTL Compiler 1.2.0-1.4.0, Scripting HTL Engine 
> 1.2.0-1.4.0, Scripting HTL Java Compiler 1.1.4-1.4.0, Scripting HTL Runtime 
> 1.1.2-1.4.0
>Reporter: Stefan Seifert
>Assignee: Radu Cotescu
>Priority: Critical
> Fix For: Scripting HTL Engine 1.4.0-1.4.0, Scripting HTL Java 
> Compiler 1.2.0-1.4.0, Scripting HTL Compiler 1.2.6-1.4.0, Scripting HTL 
> Runtime 1.2.2-1.4.0
>
>
> i've noticed that since the switch to the bnd-maven-plugin the bundle 
> versions of the scripting slightly bundles are transformed in a way that does 
> no longer match with the artifact version.
> example for 
> [org.apache.sling.scripting.sightly|https://repo1.maven.org/maven2/org/apache/sling/org.apache.sling.scripting.sightly/]:
> {noformat}
> 1.1.0-1.4.0 -> 1.1.0.1_4_0
> 1.1.2-1.4.0 -> 1.1.2.1_4_0
> 1.2.0-1.4.0 -> 1.2.0.0  -> this was the switch to bnd-maven-plugin
> 1.3.0-1.4.0 -> 1.3.0.0
> 1.3.2-1.4.0 -> 1.3.2.0
> {noformat}



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

[jira] [Updated] (SLING-9343) Versions of o.a.s.scripting.sightly bundles different from artifact versions

[Radu Cotescu (Jira)]

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

Radu Cotescu updated SLING-9343:

Fix Version/s: Scripting HTL Java Compiler 1.2.0-1.4.0
   Scripting HTL Runtime 1.2.2-1.4.0
   Scripting HTL Compiler 1.2.6-1.4.0

> Versions of o.a.s.scripting.sightly bundles different from artifact versions
> 
>
> Key: SLING-9343
> URL: https://issues.apache.org/jira/browse/SLING-9343
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting HTL Compiler 1.2.0-1.4.0, Scripting HTL Engine 
> 1.2.0-1.4.0, Scripting HTL Java Compiler 1.1.4-1.4.0, Scripting HTL Runtime 
> 1.1.2-1.4.0
>Reporter: Stefan Seifert
>Assignee: Radu Cotescu
>Priority: Critical
> Fix For: Scripting HTL Engine 1.4.0-1.4.0, Scripting HTL Java 
> Compiler 1.2.0-1.4.0, Scripting HTL Compiler 1.2.6-1.4.0, Scripting HTL 
> Runtime 1.2.2-1.4.0
>
>
> i've noticed that since the switch to the bnd-maven-plugin the bundle 
> versions of the scripting slightly bundles are transformed in a way that does 
> no longer match with the artifact version.
> example for 
> [org.apache.sling.scripting.sightly|https://repo1.maven.org/maven2/org/apache/sling/org.apache.sling.scripting.sightly/]:
> {noformat}
> 1.1.0-1.4.0 -> 1.1.0.1_4_0
> 1.1.2-1.4.0 -> 1.1.2.1_4_0
> 1.2.0-1.4.0 -> 1.2.0.0  -> this was the switch to bnd-maven-plugin
> 1.3.0-1.4.0 -> 1.3.0.0
> 1.3.2-1.4.0 -> 1.3.2.0
> {noformat}



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

[jira] [Updated] (SLING-9343) Versions of o.a.s.scripting.sightly bundles different from artifact versions

[Radu Cotescu (Jira)]

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

Radu Cotescu updated SLING-9343:

Affects Version/s: Scripting HTL Java Compiler 1.1.4-1.4.0
   Scripting HTL Runtime 1.1.2-1.4.0

> Versions of o.a.s.scripting.sightly bundles different from artifact versions
> 
>
> Key: SLING-9343
> URL: https://issues.apache.org/jira/browse/SLING-9343
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting HTL Compiler 1.2.0-1.4.0, Scripting HTL Engine 
> 1.2.0-1.4.0, Scripting HTL Java Compiler 1.1.4-1.4.0, Scripting HTL Runtime 
> 1.1.2-1.4.0
>Reporter: Stefan Seifert
>Assignee: Radu Cotescu
>Priority: Critical
> Fix For: Scripting HTL Engine 1.4.0-1.4.0
>
>
> i've noticed that since the switch to the bnd-maven-plugin the bundle 
> versions of the scripting slightly bundles are transformed in a way that does 
> no longer match with the artifact version.
> example for 
> [org.apache.sling.scripting.sightly|https://repo1.maven.org/maven2/org/apache/sling/org.apache.sling.scripting.sightly/]:
> {noformat}
> 1.1.0-1.4.0 -> 1.1.0.1_4_0
> 1.1.2-1.4.0 -> 1.1.2.1_4_0
> 1.2.0-1.4.0 -> 1.2.0.0  -> this was the switch to bnd-maven-plugin
> 1.3.0-1.4.0 -> 1.3.0.0
> 1.3.2-1.4.0 -> 1.3.2.0
> {noformat}



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

[jira] [Updated] (SLING-9343) Versions of o.a.s.scripting.sightly bundles different from artifact versions

[Radu Cotescu (Jira)]

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

Radu Cotescu updated SLING-9343:

Affects Version/s: Scripting HTL Compiler 1.2.0-1.4.0

> Versions of o.a.s.scripting.sightly bundles different from artifact versions
> 
>
> Key: SLING-9343
> URL: https://issues.apache.org/jira/browse/SLING-9343
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting HTL Compiler 1.2.0-1.4.0, Scripting HTL Engine 
> 1.2.0-1.4.0
>Reporter: Stefan Seifert
>Assignee: Radu Cotescu
>Priority: Critical
> Fix For: Scripting HTL Engine 1.4.0-1.4.0
>
>
> i've noticed that since the switch to the bnd-maven-plugin the bundle 
> versions of the scripting slightly bundles are transformed in a way that does 
> no longer match with the artifact version.
> example for 
> [org.apache.sling.scripting.sightly|https://repo1.maven.org/maven2/org/apache/sling/org.apache.sling.scripting.sightly/]:
> {noformat}
> 1.1.0-1.4.0 -> 1.1.0.1_4_0
> 1.1.2-1.4.0 -> 1.1.2.1_4_0
> 1.2.0-1.4.0 -> 1.2.0.0  -> this was the switch to bnd-maven-plugin
> 1.3.0-1.4.0 -> 1.3.0.0
> 1.3.2-1.4.0 -> 1.3.2.0
> {noformat}



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

[jira] [Updated] (SLING-9343) Versions of o.a.s.scripting.sightly bundles different from artifact versions

[Radu Cotescu (Jira)]

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

Radu Cotescu updated SLING-9343:

Affects Version/s: Scripting HTL Engine 1.2.0-1.4.0

> Versions of o.a.s.scripting.sightly bundles different from artifact versions
> 
>
> Key: SLING-9343
> URL: https://issues.apache.org/jira/browse/SLING-9343
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting HTL Engine 1.2.0-1.4.0
>Reporter: Stefan Seifert
>Assignee: Radu Cotescu
>Priority: Critical
> Fix For: Scripting HTL Engine 1.4.0-1.4.0
>
>
> i've noticed that since the switch to the bnd-maven-plugin the bundle 
> versions of the scripting slightly bundles are transformed in a way that does 
> no longer match with the artifact version.
> example for 
> [org.apache.sling.scripting.sightly|https://repo1.maven.org/maven2/org/apache/sling/org.apache.sling.scripting.sightly/]:
> {noformat}
> 1.1.0-1.4.0 -> 1.1.0.1_4_0
> 1.1.2-1.4.0 -> 1.1.2.1_4_0
> 1.2.0-1.4.0 -> 1.2.0.0  -> this was the switch to bnd-maven-plugin
> 1.3.0-1.4.0 -> 1.3.0.0
> 1.3.2-1.4.0 -> 1.3.2.0
> {noformat}



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

[jira] [Updated] (SLING-9343) Versions of o.a.s.scripting.sightly bundles different from artifact versions

[Radu Cotescu (Jira)]

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

Radu Cotescu updated SLING-9343:

Fix Version/s: Scripting HTL Engine 1.4.0-1.4.0

> Versions of o.a.s.scripting.sightly bundles different from artifact versions
> 
>
> Key: SLING-9343
> URL: https://issues.apache.org/jira/browse/SLING-9343
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Reporter: Stefan Seifert
>Assignee: Radu Cotescu
>Priority: Critical
> Fix For: Scripting HTL Engine 1.4.0-1.4.0
>
>
> i've noticed that since the switch to the bnd-maven-plugin the bundle 
> versions of the scripting slightly bundles are transformed in a way that does 
> no longer match with the artifact version.
> example for 
> [org.apache.sling.scripting.sightly|https://repo1.maven.org/maven2/org/apache/sling/org.apache.sling.scripting.sightly/]:
> {noformat}
> 1.1.0-1.4.0 -> 1.1.0.1_4_0
> 1.1.2-1.4.0 -> 1.1.2.1_4_0
> 1.2.0-1.4.0 -> 1.2.0.0  -> this was the switch to bnd-maven-plugin
> 1.3.0-1.4.0 -> 1.3.0.0
> 1.3.2-1.4.0 -> 1.3.2.0
> {noformat}



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

Re: Exploring content distribution as a service

[Timothee Maret]

Hi Dirk,

The service would expose distribution queues via a REST API. Primary
consumers will be Sling Content Distribution agents. The API could
eventually be used for other use cases but it's not an immediate goal.

Regards,

Timothee

Le jeu. 9 avr. 2020 à 15:52, Dirk Rudolph  a
écrit :

> Hi Timothee,
>
> that sounds great, indeed. Is a Sling as source, the Kafka journal as
> messaging system and anything like solr as sink, what you have in mind?
>
> In the past I tried to implement a distribution with Solr as sink, which
> unfortunately was more complicated than I thought initially.
>
> Regards,
> Dirk
>
>
> > On 9 Apr 2020, at 15:06, Timothee Maret  wrote:
> >
> > Hi,
> >
> > At Adobe we rely on journal based content distribution [0] for AEM in the
> > cloud. We would like to explore with the idea of providing content
> > distribution as a service.
> >
> > We are planning to work on that service under the Sling umbrella and
> think
> > of leveraging the existing journal based content distribution bundles
> [1].
> > This effort will likely require refactoring the code and the bundle
> > dependencies. We will strive to keep backward compatibility and plan to
> > evaluate the feasibility in branches for the existing modules.
> >
> > If the Sling community is fine with this, we'd start prototyping the
> > service in the Sling whiteboard [2].
> >
> > Regards,
> >
> > Timothee
> >
> > [0]
> https://github.com/apache/sling-org-apache-sling-distribution-journal
> > [1]
> >
> https://github.com/apache/sling-aggregator/blob/master/docs/groups/distribution.md
> > [2] https://github.com/apache/sling-whiteboard
>
>

Re: [VOTE] Deprecate org.apache.launchpad.test-services-war

[Bertrand Delacretaz]

On Thu, Apr 9, 2020 at 6:25 PM Konrad Windszus  wrote:
> If we deprecate (and I am not against it) we should IMHO deprecate
> https://github.com/apache/sling-org-apache-sling-launchpad-testing-war
>  at
> the same time and say War in general may or may not work!..

I'm +1 on that.

-Bertrand

[jira] [Resolved] (SLING-9352) Remove search patch restriction from the ScriptCacheImpl

[Radu Cotescu (Jira)]

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

Radu Cotescu resolved SLING-9352.
-
Resolution: Fixed

Implemented in [commit 
95a3f2f|https://github.com/apache/sling-org-apache-sling-scripting-core/commit/95a3f2f].

> Remove search patch restriction from the ScriptCacheImpl
> 
>
> Key: SLING-9352
> URL: https://issues.apache.org/jira/browse/SLING-9352
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Affects Versions: Scripting Core 2.0.32
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting Core 2.2.2
>
>
> This issue essentially reverts SLING-4936, such that the {{ScriptCacheImpl}} 
> can also be used with bundled scripts. The callers of the API should be the 
> ones responsible for storing the scripts with unique keys - paths / URLs that 
> they fully control.



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

[jira] [Created] (SLING-9352) Remove search patch restriction from the ScriptCacheImpl

[Radu Cotescu (Jira)]

Radu Cotescu created SLING-9352:
---

 Summary: Remove search patch restriction from the ScriptCacheImpl
 Key: SLING-9352
 URL: https://issues.apache.org/jira/browse/SLING-9352
 Project: Sling
  Issue Type: Improvement
  Components: Scripting
Affects Versions: Scripting Core 2.0.32
Reporter: Radu Cotescu
Assignee: Radu Cotescu
 Fix For: Scripting Core 2.2.2


This issue essentially reverts SLING-4936, such that the {{ScriptCacheImpl}} 
can also be used with bundled scripts. The callers of the API should be the 
ones responsible for storing the scripts with unique keys - paths / URLs that 
they fully control.



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

[jira] [Resolved] (SLING-9348) ResourceCollector is not weighing scripts with a method in the name correctly

[Radu Cotescu (Jira)]

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

Radu Cotescu resolved SLING-9348.
-
Resolution: Fixed

Fixed in 
https://github.com/apache/sling-org-apache-sling-servlets-resolver/commit/fc79361ee30f0afa7978b4542a515e9a38fd6919.

> ResourceCollector is not weighing scripts with a method in the name correctly
> -
>
> Key: SLING-9348
> URL: https://issues.apache.org/jira/browse/SLING-9348
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Servlets Resolver 2.6.4
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>Priority: Major
> Fix For: Servlets Resolver 2.6.6
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> The ResourceCollector that creates the weighted resources for script 
> selection is giving equal priority to scripts that have the method in their 
> path and those that don't. E.g.:
> foo/html.servlet and foo/html.GET.servlet will have the same weight. 
> That is wrong as the one with the GET should have preference.



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

[jira] [Updated] (SLING-9348) ResourceCollector is not weighing scripts with a method in the name correctly

[Radu Cotescu (Jira)]

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

Radu Cotescu updated SLING-9348:

Summary: ResourceCollector is not weighing scripts with a method in the 
name correctly  (was: ResourceCollector is not weighing scripts with a method 
in the name correctly.)

> ResourceCollector is not weighing scripts with a method in the name correctly
> -
>
> Key: SLING-9348
> URL: https://issues.apache.org/jira/browse/SLING-9348
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Servlets Resolver 2.6.4
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>Priority: Major
> Fix For: Servlets Resolver 2.6.6
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The ResourceCollector that creates the weighted resources for script 
> selection is giving equal priority to scripts that have the method in their 
> path and those that don't. E.g.:
> foo/html.servlet and foo/html.GET.servlet will have the same weight. 
> That is wrong as the one with the GET should have preference.



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

[jira] [Resolved] (SLING-9349) Provide the list of TypeProviders for a BundledRenderUnit

[Radu Cotescu (Jira)]

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

Radu Cotescu resolved SLING-9349.
-
Resolution: Fixed

Implemented in [commit 
70542e3|https://github.com/apache/sling-org-apache-sling-scripting-bundle-tracker/commit/70542e3].

> Provide the list of TypeProviders for a BundledRenderUnit
> -
>
> Key: SLING-9349
> URL: https://issues.apache.org/jira/browse/SLING-9349
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting Bundle Tracker 0.2.0
>
>
> A {{BundledRenderUnit}} currently only offers access to the bundle that 
> provides it. However, script engines that would need to solve dependencies 
> based on the {{ScriptContext}} provided {{BundledRenderUnit}} might need more 
> than just the providing bundle in order to generate the whole component 
> inheritance chain.
> Since the {{BundledScriptTracker}} already calculates the {{TypeProvider}} 
> chain, this information could be exposed into the {{BundledRenderUnit}}.



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

[jira] [Resolved] (SLING-9350) Recompile scripts which hold a stale ScriptEngine reference

[Radu Cotescu (Jira)]

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

Radu Cotescu resolved SLING-9350.
-
Resolution: Fixed

Fixed in [commit 
bef6415|https://github.com/apache/sling-org-apache-sling-scripting-bundle-tracker/commit/bef6415].

> Recompile scripts which hold a stale ScriptEngine reference
> ---
>
> Key: SLING-9350
> URL: https://issues.apache.org/jira/browse/SLING-9350
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting Bundle Tracker 0.1.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting Bundle Tracker 0.2.0
>
>
> The {{org.apache.sling.scripting.bundle.tracker.internal.Script}} 
> implementation wraps and caches a {{javax.script.CompiledScript}}. However, 
> the wrapped {{javax.script.CompiledScript}} should be recompiled if a newer 
> suitable {{ScriptEngineFactory}} gets registered.



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

Re: [VOTE] Deprecate org.apache.launchpad.test-services-war

[Konrad Windszus]

For me the tests are interesting (although an edge case).
But the deployment should not be as a bundle into OSGi but rather as a 
dedicated 2nd war 
(https://www.eclipse.org/jetty/documentation/9.4.x/jetty-maven-plugin.html#deploy-war-running-pre-assembled-war
 

 ) while executing 
https://github.com/apache/sling-org-apache-sling-launchpad-testing-war/blob/fa39f6a3c238cd79da4962ebf3f827f19b567016/pom.xml#L128
 

That was also the intention I guess as services-war have the packaging war 
(https://github.com/apache/sling-org-apache-sling-launchpad-test-services-war/blob/e93ea20c1f62d8219efd0e749c7e12f4225695d2/pom.xml#L31).

Konrad

If we deprecate (and I am not against it) we should IMHO deprecate 
https://github.com/apache/sling-org-apache-sling-launchpad-testing-war 
 at the 
same time and say War in general may or may not work!

> On 9. Apr 2020, at 18:15, Robert Munteanu  wrote:
> 
> Hi,
> 
> With SLING-8680 [1] we seem to have found a interesting scenario in our
> testing setup:
> 
> - org.apache.sling.launchpad.test-services-war [2] is packaged as a WAR
> file with a manifest, exposing two Servlets
> - before SLING-8680 [1] we only checked for a manifest when
> transforming resources, now we reject the WAR file
> - we have two tests that validate that those servlets are running
> properly - see WarSelectorServletTest.java [3]
> 
> IMO we should not test or support this scenario (WAR files installed as
> OSGi bundles) as it's a quite convoluted and specific scenario.
> 
> Therefore I propose that we retire this module following our Deprecated
> Sling Modules process and delete the two tests.
> 
> Please vote to accept this retirement. This majority vote is open for
> at least 72 hours.
> 
> Thanks,
> Robert
> 
> [1]: https://issues.apache.org/jira/browse/SLING-8680
> [2]: 
> https://github.com/apache/sling-org-apache-sling-launchpad-test-services-war/blob/e93ea20c1f62d8219efd0e749c7e12f4225695d2/pom.xml
> [3]: 
> https://github.com/apache/sling-org-apache-sling-launchpad-integration-tests/blob/49e5c948a0115566f778a5696e7f3df45e5dd3f5/src/main/java/org/apache/sling/launchpad/webapp/integrationtest/servlets/resolution/WarSelectorServletTest.java
> 

Re: Consistently failing ITs

[Robert Munteanu]

Reviewing the setup I came to the conclusion that we should actually
retire that module. See "[VOTE] Deprecate org.apache.launchpad.test-
services-war" on dev@sling and 
https://issues.apache.org/jira/browse/SLING-9351 .

Thanks,
Robert

On Mon, 2020-04-06 at 16:10 +0200, Konrad Windszus wrote:
> That is because testing war (
> https://github.com/apache/sling-org-apache-sling-launchpad-testing-war/blob/master/src/main/provisioning/model.txt
> <
> https://github.com/apache/sling-org-apache-sling-launchpad-testing-war/blob/master/src/main/provisioning/model.txt>
> ;) does not deploy anything apart from the starter and some test-
> bundles.
> It IMHO must deploy 
> https://github.com/apache/sling-org-apache-sling-launchpad-test-services-war
> <
> https://github.com/apache/sling-org-apache-sling-launchpad-test-services-war
> > in addition.
> Konrad
> 
> > On 6. Apr 2020, at 16:04, Robert Munteanu 
> > wrote:
> > 
> > FWIW, the same tests fail in launchpad-testing-war as well [1].
> > 
> > So that is probably not the right fix to do.
> > 
> > [1]: 
> > https://builds.apache.org/job/Sling/job/sling-org-apache-sling-launchpad-testing-war/job/master/68/console
> > 
> > 
> > 
> > On Wed, 2020-04-01 at 16:06 +0200, Robert Munteanu wrote:
> > > Sounds like a reasonable explanation to me.
> > > 
> > > Thanks,
> > > Robert
> > > 
> > > On Wed, 2020-04-01 at 16:03 +0200, Konrad Windszus wrote:
> > > > What I assume happened was the following:
> > > > 
> > > > The WAR was incorrectly treated as bundle and therefore
> > > > installed
> > > > by
> > > > the OSGi Installer for bundles.
> > > > As consequence the according servlets were registered.
> > > > 
> > > > 
> > > > > On 1. Apr 2020, at 16:00, Robert Munteanu  > > > > >
> > > > > wrote:
> > > > > 
> > > > > I agree in principle. But why did these not fail until now?
> > > > > 
> > > > > Thanks,
> > > > > Robert
> > > > > 
> > > > > On Wed, 2020-04-01 at 15:39 +0200, Konrad Windszus wrote:
> > > > > > IMHO there are some test which should only be executed
> > > > > > from 
> > > > > > https://github.com/apache/sling-org-apache-sling-launchpad-testing-war
> > > > > > , namely 
> > > > > > https://github.com/apache/sling-org-apache-sling-launchpad-integration-tests/blob/bd0c0c270b73e582dc5dfa3ed25231c951d0c98d/src/main/java/org/apache/sling/launchpad/webapp/integrationtest/servlets/resolution/WarSelectorServletTest.java
> > > > > > .
> > > > > > 
> > > > > > That should IMHO be moved to 
> > > > > > https://github.com/apache/sling-org-apache-sling-launchpad-testing-war
> > > > > > to make sure it is not executed with 
> > > > > > https://github.com/apache/sling-org-apache-sling-launchpad-testing.
> > > > > > WDYT?
> > > > > > 
> > > > > > Konrad
> > > > > > 
> > > > > > > On 1. Apr 2020, at 15:29, Konrad Windszus <
> > > > > > > konra...@gmx.de>
> > > > > > > wrote:
> > > > > > > 
> > > > > > > Done with 
> > > > > > > https://github.com/apache/sling-org-apache-sling-launchpad-test-bundles/commit/43956dd07234ddc3263ce29c5b7c3f7198ad4caf
> > > > > > > <
> > > > > > > https://github.com/apache/sling-org-apache-sling-launchpad-test-bundles/commit/43956dd07234ddc3263ce29c5b7c3f7198ad4caf>
> > > > > > > ;.
> > > > > > > 
> > > > > > > That leaves us with 2 remaining issues:
> > > > > > > 
> > > > > > > [ERROR] Failures: 
> > > > > > > [ERROR]   WarSelectorServletTest.testSelectorOne:23-
> > > > > > > > ResolutionTestBase.assertServlet:75 Content contains
> > > > > > > servlet.class.name property (** Resource dumped by
> > > > > > > PlainTextRenderer**
> > > > > > > Resource path:/servlet-resolution-
> > > > > > > tests/1585747495298/this_is_a_test_node_
> > > > > > > Resource metadata: {sling.modificationTime=-1,
> > > > > > > sling.characterEncoding=null, sling.parameterMap={},
> > > > > > > sling.contentType=null, sling.creationTime=-1,
> > > > > > > sling.contentLength=-1, sling.resolutionPath=/servlet-
> > > > > > > resolution-
> > > > > > > tests/1585747495298/this_is_a_test_node_,
> > > > > > > sling.resolutionPathInfo=.WAR_TEST_SEL_1.txt}
> > > > > > > Resource type: nt:unstructured
> > > > > > > Resource super type: -
> > > > > > > 
> > > > > > > ** Resource properties **
> > > > > > > jcr:primaryType: nt:unstructured
> > > > > > > text: This is a test node 1585747503024
> > > > > > > )
> > > > > > > [ERROR]   WarSelectorServletTest.testSelectorTwo:29-
> > > > > > > > ResolutionTestBase.assertServlet:75 Content contains
> > > > > > > servlet.class.name property (** Resource dumped by
> > > > > > > PlainTextRenderer**
> > > > > > > Resource path:/servlet-resolution-
> > > > > > > tests/1585747495298/this_is_a_test_node_
> > > > > > > Resource metadata: {sling.modificationTime=-1,
> > > > > > > sling.characterEncoding=null, sling.parameterMap={},
> > > > > > > sling.contentType=null, sling.creationTime=-1,
> > > > > > > sling.contentLength=-1, sling.resolutionPath=/servlet-
> > > > > > > resolution-
> > > > > > > tests/1585747495298/this_is_a_test_node_,
> > > > > > > 

Re: [VOTE] Deprecate org.apache.launchpad.test-services-war

[Robert Munteanu]

On Thu, 2020-04-09 at 18:15 +0200, Robert Munteanu wrote:
> Please vote to accept this retirement. This majority vote is open for
> at least 72 hours.

+1
Robert


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

[VOTE] Deprecate org.apache.launchpad.test-services-war

[Robert Munteanu]

Hi,

With SLING-8680 [1] we seem to have found a interesting scenario in our
testing setup:

- org.apache.sling.launchpad.test-services-war [2] is packaged as a WAR
file with a manifest, exposing two Servlets
- before SLING-8680 [1] we only checked for a manifest when
transforming resources, now we reject the WAR file
- we have two tests that validate that those servlets are running
properly - see WarSelectorServletTest.java [3]

IMO we should not test or support this scenario (WAR files installed as
OSGi bundles) as it's a quite convoluted and specific scenario.

Therefore I propose that we retire this module following our Deprecated
Sling Modules process and delete the two tests.

Please vote to accept this retirement. This majority vote is open for
at least 72 hours.

Thanks,
Robert

[1]: https://issues.apache.org/jira/browse/SLING-8680
[2]: 
https://github.com/apache/sling-org-apache-sling-launchpad-test-services-war/blob/e93ea20c1f62d8219efd0e749c7e12f4225695d2/pom.xml
[3]: 
https://github.com/apache/sling-org-apache-sling-launchpad-integration-tests/blob/49e5c948a0115566f778a5696e7f3df45e5dd3f5/src/main/java/org/apache/sling/launchpad/webapp/integrationtest/servlets/resolution/WarSelectorServletTest.java

[jira] [Updated] (SLING-9351) Deprecate org.apache.launchpad.test-services-war

[Robert Munteanu (Jira)]

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

Robert Munteanu updated SLING-9351:
---
Summary: Deprecate org.apache.launchpad.test-services-war  (was: Retire 
org.apache.launchpad.test-services-war)

> Deprecate org.apache.launchpad.test-services-war
> 
>
> Key: SLING-9351
> URL: https://issues.apache.org/jira/browse/SLING-9351
> Project: Sling
>  Issue Type: Task
>  Components: Launchpad, Testing
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Starter 12
>
>
> With SLING-8660 we seem to have found a interesting scenario in our testing 
> setup:
>  - org.apache.sling.launchpad.test-services-war is packaged as a WAR file 
> with a manifest, exposing two Servlets
>  - before SLING-8660 we only checked for a manifest when transforming 
> resources, now we reject the WAR file
>  - we have two tests that validate that those servlets are running properly - 
> see [WarSelectorServletTest.java 
> (permalink)|https://github.com/apache/sling-org-apache-sling-launchpad-integration-tests/blob/49e5c948a0115566f778a5696e7f3df45e5dd3f5/src/main/java/org/apache/sling/launchpad/webapp/integrationtest/servlets/resolution/WarSelectorServletTest.java]
> IMO we should not test or support this scenario (WAR files installed as OSGi 
> bundles) as it's a quite convoluted and specific scenario.
> Therefore I propose that we retire this module following our [Deprecated 
> Sling Modules 
> process|https://sling.apache.org/documentation/development/deprecating-sling-modules.html]
>  and delete the two tests.



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

[jira] [Updated] (SLING-9351) Deprecate org.apache.launchpad.test-services-war

[Robert Munteanu (Jira)]

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

Robert Munteanu updated SLING-9351:
---
Description: 
With SLING-8680 we seem to have found a interesting scenario in our testing 
setup:
 - org.apache.sling.launchpad.test-services-war is packaged as a WAR file with 
a manifest, exposing two Servlets
 - before SLING-8680 we only checked for a manifest when transforming 
resources, now we reject the WAR file
 - we have two tests that validate that those servlets are running properly - 
see [WarSelectorServletTest.java 
(permalink)|https://github.com/apache/sling-org-apache-sling-launchpad-integration-tests/blob/49e5c948a0115566f778a5696e7f3df45e5dd3f5/src/main/java/org/apache/sling/launchpad/webapp/integrationtest/servlets/resolution/WarSelectorServletTest.java]

IMO we should not test or support this scenario (WAR files installed as OSGi 
bundles) as it's a quite convoluted and specific scenario.

Therefore I propose that we retire this module following our [Deprecated Sling 
Modules 
process|https://sling.apache.org/documentation/development/deprecating-sling-modules.html]
 and delete the two tests.

  was:
With SLING-8660 we seem to have found a interesting scenario in our testing 
setup:
 - org.apache.sling.launchpad.test-services-war is packaged as a WAR file with 
a manifest, exposing two Servlets
 - before SLING-8660 we only checked for a manifest when transforming 
resources, now we reject the WAR file
 - we have two tests that validate that those servlets are running properly - 
see [WarSelectorServletTest.java 
(permalink)|https://github.com/apache/sling-org-apache-sling-launchpad-integration-tests/blob/49e5c948a0115566f778a5696e7f3df45e5dd3f5/src/main/java/org/apache/sling/launchpad/webapp/integrationtest/servlets/resolution/WarSelectorServletTest.java]

IMO we should not test or support this scenario (WAR files installed as OSGi 
bundles) as it's a quite convoluted and specific scenario.

Therefore I propose that we retire this module following our [Deprecated Sling 
Modules 
process|https://sling.apache.org/documentation/development/deprecating-sling-modules.html]
 and delete the two tests.


> Deprecate org.apache.launchpad.test-services-war
> 
>
> Key: SLING-9351
> URL: https://issues.apache.org/jira/browse/SLING-9351
> Project: Sling
>  Issue Type: Task
>  Components: Launchpad, Testing
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Starter 12
>
>
> With SLING-8680 we seem to have found a interesting scenario in our testing 
> setup:
>  - org.apache.sling.launchpad.test-services-war is packaged as a WAR file 
> with a manifest, exposing two Servlets
>  - before SLING-8680 we only checked for a manifest when transforming 
> resources, now we reject the WAR file
>  - we have two tests that validate that those servlets are running properly - 
> see [WarSelectorServletTest.java 
> (permalink)|https://github.com/apache/sling-org-apache-sling-launchpad-integration-tests/blob/49e5c948a0115566f778a5696e7f3df45e5dd3f5/src/main/java/org/apache/sling/launchpad/webapp/integrationtest/servlets/resolution/WarSelectorServletTest.java]
> IMO we should not test or support this scenario (WAR files installed as OSGi 
> bundles) as it's a quite convoluted and specific scenario.
> Therefore I propose that we retire this module following our [Deprecated 
> Sling Modules 
> process|https://sling.apache.org/documentation/development/deprecating-sling-modules.html]
>  and delete the two tests.



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

[jira] [Created] (SLING-9351) Retire org.apache.launchpad.test-services-war

[Robert Munteanu (Jira)]

Robert Munteanu created SLING-9351:
--

 Summary: Retire org.apache.launchpad.test-services-war
 Key: SLING-9351
 URL: https://issues.apache.org/jira/browse/SLING-9351
 Project: Sling
  Issue Type: Task
  Components: Launchpad, Testing
Reporter: Robert Munteanu
Assignee: Robert Munteanu
 Fix For: Starter 12


With SLING-8660 we seem to have found a interesting scenario in our testing 
setup:
 - org.apache.sling.launchpad.test-services-war is packaged as a WAR file with 
a manifest, exposing two Servlets
 - before SLING-8660 we only checked for a manifest when transforming 
resources, now we reject the WAR file
 - we have two tests that validate that those servlets are running properly - 
see [WarSelectorServletTest.java 
(permalink)|https://github.com/apache/sling-org-apache-sling-launchpad-integration-tests/blob/49e5c948a0115566f778a5696e7f3df45e5dd3f5/src/main/java/org/apache/sling/launchpad/webapp/integrationtest/servlets/resolution/WarSelectorServletTest.java]

IMO we should not test or support this scenario (WAR files installed as OSGi 
bundles) as it's a quite convoluted and specific scenario.

Therefore I propose that we retire this module following our [Deprecated Sling 
Modules 
process|https://sling.apache.org/documentation/development/deprecating-sling-modules.html]
 and delete the two tests.



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

[jira] [Created] (SLING-9350) Recompile scripts which hold a stale ScriptEngine reference

[Radu Cotescu (Jira)]

Radu Cotescu created SLING-9350:
---

 Summary: Recompile scripts which hold a stale ScriptEngine 
reference
 Key: SLING-9350
 URL: https://issues.apache.org/jira/browse/SLING-9350
 Project: Sling
  Issue Type: Bug
  Components: Scripting
Affects Versions: Scripting Bundle Tracker 0.1.0
Reporter: Radu Cotescu
Assignee: Radu Cotescu
 Fix For: Scripting Bundle Tracker 0.2.0


The {{org.apache.sling.scripting.bundle.tracker.internal.Script}} 
implementation wraps and caches a {{javax.script.CompiledScript}}. However, the 
wrapped {{javax.script.CompiledScript}} should be recompiled if a newer 
suitable {{ScriptEngineFactory}} gets registered.



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

[jira] [Created] (SLING-9349) Provide the list of TypeProviders for a BundledRenderUnit

[Radu Cotescu (Jira)]

Radu Cotescu created SLING-9349:
---

 Summary: Provide the list of TypeProviders for a BundledRenderUnit
 Key: SLING-9349
 URL: https://issues.apache.org/jira/browse/SLING-9349
 Project: Sling
  Issue Type: Improvement
  Components: Scripting
Reporter: Radu Cotescu
Assignee: Radu Cotescu
 Fix For: Scripting Bundle Tracker 0.2.0


A {{BundledRenderUnit}} currently only offers access to the bundle that 
provides it. However, script engines that would need to solve dependencies 
based on the {{ScriptContext}} provided {{BundledRenderUnit}} might need more 
than just the providing bundle in order to generate the whole component 
inheritance chain.

Since the {{BundledScriptTracker}} already calculates the {{TypeProvider}} 
chain, this information could be exposed into the {{BundledRenderUnit}}.



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

Re: Exploring content distribution as a service

[Dirk Rudolph]

Hi Timothee,

that sounds great, indeed. Is a Sling as source, the Kafka journal as messaging 
system and anything like solr as sink, what you have in mind? 

In the past I tried to implement a distribution with Solr as sink, which 
unfortunately was more complicated than I thought initially.

Regards,
Dirk


> On 9 Apr 2020, at 15:06, Timothee Maret  wrote:
> 
> Hi,
> 
> At Adobe we rely on journal based content distribution [0] for AEM in the
> cloud. We would like to explore with the idea of providing content
> distribution as a service.
> 
> We are planning to work on that service under the Sling umbrella and think
> of leveraging the existing journal based content distribution bundles [1].
> This effort will likely require refactoring the code and the bundle
> dependencies. We will strive to keep backward compatibility and plan to
> evaluate the feasibility in branches for the existing modules.
> 
> If the Sling community is fine with this, we'd start prototyping the
> service in the Sling whiteboard [2].
> 
> Regards,
> 
> Timothee
> 
> [0] https://github.com/apache/sling-org-apache-sling-distribution-journal
> [1]
> https://github.com/apache/sling-aggregator/blob/master/docs/groups/distribution.md
> [2] https://github.com/apache/sling-whiteboard

[GitHub] [sling-whiteboard] rombert commented on issue #51: SAML2 Service Provider Pull Request

[GitBox]

rombert commented on issue #51: SAML2 Service Provider Pull Request
URL: https://github.com/apache/sling-whiteboard/pull/51#issuecomment-611539465
 
 
   I've been thinking some more about how to make sure the reviews are 
productive and reduce the time needed to get this into the whiteboard.
   
   The idea I came up with takes two complementary approaches:
   
   1. Simplify testing
   1. Reduce the amount of submitted code
   
   For item 1 I suggest that you provide a docker script or docker-compose 
setup that launches a SAML-enable identity provider. One idea would be 
[Keycloak with 
Docker](https://www.keycloak.org/getting-started/getting-started-docker), but I 
admit I'm not at all familiar with identity providers to offer an informed 
suggestion.
   
   This would allow you to drop ~400 LOC in the `idp` package and maybe some 
other parts that are only used from there.
   
   For item 2 item 1 already helps :-) I think you can start with submitting 
the minimal functionality that works - and I get that is the 
AuthenticationHandler.
   
   I see code for the ExternalIdentityProvider and LoginModule as well. If that 
is not needed for the basic login flow, I would suggest submitting them as 
follow-up PRs once we merge the initial one.
   
   I also see a potential of dropping some code with the TokenStore class. You 
mention it's derived from the class in the `o.a.s.auth.form` bundle. Maybe 
that's something we can export, or you can inline the class in this bundle. The 
code looks quite complex and is large, I think it's a good idea to keep the 
duplication out of the bundle.
   
   Would that work for you?


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


With regards,
Apache Git Services

Re: Exploring content distribution as a service

[Bertrand Delacretaz]

Hi Tim,

On Thu, Apr 9, 2020 at 3:06 PM Timothee Maret  wrote:
> ...If the Sling community is fine with this, we'd start prototyping the
> service in the Sling whiteboard [2]...

Sounds like a great plan to me, the whiteboard is here for that!

-Bertrand

[RESULT][VOTE] Release Apache Sling Testing Clients version 2.0.0 and Apache Sling Testing Rules version 2.0.0

[Andrei Dulvac]

Hi,

The vote has passed with the following result :

+1 (binding): Daniel, Robert, Andrei

No -1 votes

I will copy this release to the Sling dist directory and
promote the artifacts to the central Maven repository.

Thanks,
- Andrei

On Tue, Apr 7, 2020 at 12:51 PM Andrei Dulvac  wrote:

> Hi Robert.
>
> The reasoning is that for the testing clients, which is packaged as a
> bundle, I still like to use semver  for the maven version, even though not
> strictly required.
>
> For the testing rules, it's a bit trickier, but the reasoning is the
> testing clients are supposed to be used as a transient dependency by the
> end user.
>
> I'll have a think about the overall strategy. I don't think a major
> version bump is a problem, but it's a valid point, for sure.
>
> Here's my +1 as well.
>
> Thanks
> Andrei
>
> On Tue, 7 Apr 2020 at 10:43, Robert Munteanu  wrote:
>
>> On Mon, 2020-04-06 at 15:20 +0200, Andrei Dulvac wrote:
>> > Please vote to approve this release:
>>
>> +1
>>
>> As a side note, do you really want a 2.0 version? From a "marketing"
>> point of view these don't add much - the testing rules just has two
>> bugfixes.
>>
>> It does not hurt anything, but then again consumers might be suprised.
>>
>> Robert
>>
>

Re: [VOTE] Release Apache Sling Auth Core 1.4.6

[Daniel Klco]

+1

On Thu, Apr 9, 2020 at 7:17 AM  wrote:

> +1
>
> David
>
> On Thu, 9 Apr 2020 at 10:19, Carsten Ziegeler 
> wrote:
>
> > Hi,
> >
> > we solved 2 issues in this release
> >
> >
> >
> https://issues.apache.org/jira/browse/SLING-9345?jql=project%20%3D%20SLING%20AND%20fixVersion%20%3D%20%22Auth%20Core%201.4.6%22
> >
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachesling-2238
> >
> > 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 2238 /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
> > Carsten
> > --
> > Carsten Ziegeler
> > Adobe Research Switzerland
> > cziege...@apache.org
> >
>

[jira] [Created] (SLING-9348) ResourceCollector is not weighing scripts with a method in the name correctly.

[Karl Pauls (Jira)]

Karl Pauls created SLING-9348:
-

 Summary: ResourceCollector is not weighing scripts with a method 
in the name correctly.
 Key: SLING-9348
 URL: https://issues.apache.org/jira/browse/SLING-9348
 Project: Sling
  Issue Type: Bug
  Components: Scripting
Affects Versions: Servlets Resolver 2.6.4
Reporter: Karl Pauls
Assignee: Karl Pauls
 Fix For: Servlets Resolver 2.6.6


The ResourceCollector that creates the weighted resources for script selection 
is giving equal priority to scripts that have the method in their path and 
those that don't. E.g.:

foo/html.servlet and foo/html.GET.servlet will have the same weight. 

That is wrong as the one with the GET should have preference.



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

Exploring content distribution as a service

[Timothee Maret]

Hi,

At Adobe we rely on journal based content distribution [0] for AEM in the
cloud. We would like to explore with the idea of providing content
distribution as a service.

We are planning to work on that service under the Sling umbrella and think
of leveraging the existing journal based content distribution bundles [1].
This effort will likely require refactoring the code and the bundle
dependencies. We will strive to keep backward compatibility and plan to
evaluate the feasibility in branches for the existing modules.

If the Sling community is fine with this, we'd start prototyping the
service in the Sling whiteboard [2].

Regards,

Timothee

[0] https://github.com/apache/sling-org-apache-sling-distribution-journal
[1]
https://github.com/apache/sling-aggregator/blob/master/docs/groups/distribution.md
[2] https://github.com/apache/sling-whiteboard

[jira] [Commented] (SLING-9344) Sling CMS - Namespace for nodes is wrong in nodetypes.cnd

[Dan Klco (Jira)]

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

Dan Klco commented on SLING-9344:
-

[~alldaysunshine] - good callout. This indeed does seem to be the same issue as 
SLING-9012, I've closed that as a duplicate since the issue was resolved on 
this ticket. 

> Sling CMS - Namespace for nodes is wrong in nodetypes.cnd
> -
>
> Key: SLING-9344
> URL: https://issues.apache.org/jira/browse/SLING-9344
> Project: Sling
>  Issue Type: Bug
>  Components: App CMS
>Affects Versions: App CMS 0.10.0
> Environment: Hardware does not matter, I assume - but I did test on 
> two different macs with Amazon Corretto 8 as JDK.
>Reporter: Matthias Herold
>Assignee: Dan Klco
>Priority: Major
> Fix For: App CMS 0.16.2
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The namespace specified in the file 
> ui/src/main/resources/SLING-INF/nodetypes/nodetypes.cnd of repository 
> sling-org-apache-sling-app-cms is wrong.
> Line 24 reads: http://www.sling.apache.org/sling/1.0'>
> This should be: http://sling.apache.org/jcr/sling/1.0'> 
> This is a major issue when creating new repositories: when you build a custom 
> starter package including Apache CMS and create a new repository with this 
> starter package afterwards, the namespace of all nodes in the repository is 
> automatically wrong. In normal operation, you won't notice that. But when you 
> export content as package from a sling instance with the right namespace and 
> import the content to a sling instance with the wrong namespace the import 
> will fail. I did not test the other way round, but assume the issue also 
> occurs there. 
> Suggested fix: change
> http://www.sling.apache.org/sling/1.0
> to 
> http://sling.apache.org/jcr/sling/1.0
> in 
> sling-org-apache-sling-app-cms/ui/src/main/resources/SLING-INF/nodetypes/nodetypes.cnd



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

[jira] [Resolved] (SLING-9012) Unkown nodetype during package installation

[Dan Klco (Jira)]

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

Dan Klco resolved SLING-9012.
-
Resolution: Duplicate

> Unkown nodetype during package installation
> ---
>
> Key: SLING-9012
> URL: https://issues.apache.org/jira/browse/SLING-9012
> Project: Sling
>  Issue Type: Bug
>  Components: App CMS
>Affects Versions: CMS 0.14.0
>Reporter: Christoph Thodte
>Assignee: Dan Klco
>Priority: Major
>
> It is not possible to install a package on sling cms on 
> /bin/cpm/package.service.html 
> I got always messages like these nodetype is unkown like
> {noformat}
> javax.jcr.nodetype.NoSuchNodeTypeException: Node type sling0:OsgiConfig does 
> not exist
> {noformat}
> But on a Sling Starter 11  it works without problems. I look for some 
> configuration or similar. But I don't find something.
> Do you have an idea?



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

[jira] [Closed] (SLING-9187) Allow to provide provisioning model name and runmodes via feature model folders

[Carsten Ziegeler (Jira)]

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

Carsten Ziegeler closed SLING-9187.
---

> Allow to provide provisioning model name and runmodes via feature model 
> folders
> ---
>
> Key: SLING-9187
> URL: https://issues.apache.org/jira/browse/SLING-9187
> Project: Sling
>  Issue Type: Improvement
>  Components: Feature Model, Maven Plugins and Archetypes
>Affects Versions: slingfeature-maven-plugin 1.1.18
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>Priority: Major
> Fix For: Slingstart Maven Plugin 1.9.10
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> With SLING-9179 and SLING-9178 we allowed to provide runmodes with the 
> feature model folders and a default provisioning model name, respectively. 
> I think it would be good to allow a provisioning model name per folder 
> similar to what we allow for the runmodes. That would mean we would allow 
> more than one attribute per folder - hence, I think we should switch away 
> from the delimter "|" we used for the runmodes and just reuse the attributed 
> header style we use in OSGi. 
> In other words, it would look like:
> ;provisioning.model.name="foo";provisioning.runmodes="author,publish"
>  
> I will provide a PR for this - please merge the PR and resolve this issue if 
> you like it.



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

[jira] [Closed] (SLING-9177) Support same feature file format as slingfeature maven plugin

[Carsten Ziegeler (Jira)]

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

Carsten Ziegeler closed SLING-9177.
---

> Support same feature file format as slingfeature maven plugin
> -
>
> Key: SLING-9177
> URL: https://issues.apache.org/jira/browse/SLING-9177
> Project: Sling
>  Issue Type: Improvement
>  Components: Feature Model, Maven Plugins and Archetypes
>Affects Versions: Slingstart Maven Plugin 1.9.8
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: Slingstart Maven Plugin 1.9.10
>
>
> The slingfeature maven plugin supports comments in feature files; it also 
> supports feature files without an id.
> For the conversion from a feature file to a provisioning model, we should 
> support the same in the slingstart maven plugin



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

[jira] [Closed] (SLING-9178) Allow configuring the default name for the provisioning model

[Carsten Ziegeler (Jira)]

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

Carsten Ziegeler closed SLING-9178.
---

> Allow configuring the default name for the provisioning model
> -
>
> Key: SLING-9178
> URL: https://issues.apache.org/jira/browse/SLING-9178
> Project: Sling
>  Issue Type: Improvement
>  Components: Feature Model, Maven Plugins and Archetypes
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: Slingstart Maven Plugin 1.9.10
>
>
> For the FM->PM conversion, the prov model defaults to the artifact id of the 
> project. There might be cases, where a different default helps avoiding to 
> set this explicitely in each and every feature model.



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

[jira] [Closed] (SLING-9179) Allow to configure (additional) runmodes per feature model location

[Carsten Ziegeler (Jira)]

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

Carsten Ziegeler closed SLING-9179.
---

> Allow to configure (additional) runmodes per feature model location
> ---
>
> Key: SLING-9179
> URL: https://issues.apache.org/jira/browse/SLING-9179
> Project: Sling
>  Issue Type: Improvement
>  Components: Feature Model, Maven Plugins and Archetypes
>Affects Versions: Slingstart Maven Plugin 1.9.8
>Reporter: Karl Pauls
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: Slingstart Maven Plugin 1.9.10
>
>
> For the FM->PM conversion, it would be good if one could configure 
> (additional) runmodes to be used for features found in a given directory. It 
> already is possible to specify different directories to look for feature 
> models to convert - maybe it would be possible to add an optional attribute 
> to each configured folder containing additional runmodes or something.



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

[jira] [Closed] (SLING-8842) CP Converter creates packaging "slingfeature" instead of "slingosgifeature"

[Carsten Ziegeler (Jira)]

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

Carsten Ziegeler closed SLING-8842.
---

> CP Converter creates packaging "slingfeature" instead of "slingosgifeature"
> ---
>
> Key: SLING-8842
> URL: https://issues.apache.org/jira/browse/SLING-8842
> Project: Sling
>  Issue Type: Bug
>  Components: Feature Model
>Affects Versions: Feature Model Converter 1.0.8
>Reporter: Mika Goeckel
>Assignee: Carsten Ziegeler
>Priority: Minor
> Fix For: Feature Model Converter 1.0.14
>
>
> I used the sling-feature-converter-maven-plugin to create features.json files 
> from the sling-starter provisioning txt files.
> The converter creates feature files with packaging „slingfeature“ but 
> installes them using „slingosgifeature“.
>  
> Then I use the slingfeature-maven-plugin to create a „full“ version from the 
> files created above. The -full file has an „assembled-features“ section 
> containing the single feature files with packaging „slingfeature“, itself on 
> the other hand declares a packaging „slingosgifeature“.
>  
> Now I try to use the -full feature json as prototype for my own feature.json.
> When I now use slingfeature-maven-plugin to assemble the artifacts, it tries 
> to find them with packaging „slingfeature“ (as declared in the 
> assembled-section) – but can't find them as they have been installed as 
> „slingosgifeature“.
>  
> Could it be, that this is coming from FeatureJSONWriter Line 519:
>  
> // When providing a classifier a type must be provided and so we set it to 
> 'slingfeature'
>    idString =
>    groupId + "/" +
>    (nameOption.isEmpty() ? name : nameOption) + "/" +
>    version +
>    (nameOption.isEmpty() ? "" :
>    "/slingfeature/" + name );



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

[jira] [Closed] (SLING-9333) Artifact metadata is incorrectly writing a comma to separate the parameters

[Carsten Ziegeler (Jira)]

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

Carsten Ziegeler closed SLING-9333.
---

> Artifact metadata is incorrectly writing a comma to separate the parameters
> ---
>
> Key: SLING-9333
> URL: https://issues.apache.org/jira/browse/SLING-9333
> Project: Sling
>  Issue Type: Bug
>  Components: Tooling
>Affects Versions: Sling Provisioning Model 1.8.4, Feature Model Converter 
> 1.0.12, Slingstart Maven Plugin 1.9.8
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Blocker
> Fix For: Sling Provisioning Model 1.8.6, Feature Model Converter 
> 1.0.14, Slingstart Maven Plugin 1.9.10
>
>
> Artifact metadata is separated by space only, however the writer writes out a 
> comma and a space. Which then results in wrong values when the parameters are 
> read again



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

[VOTE RESULT] Release Apache Sling Provisioning Model 1.8.6, Feature Model Converter 1.0.14, Slinstart Maven Plugin 1.9.10

[Carsten Ziegeler]

The vote passed with four binding +1 votes

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

Re: [VOTE] Release Apache Sling Auth Core 1.4.6

[davidb]

+1

David

On Thu, 9 Apr 2020 at 10:19, Carsten Ziegeler  wrote:

> Hi,
>
> we solved 2 issues in this release
>
>
> https://issues.apache.org/jira/browse/SLING-9345?jql=project%20%3D%20SLING%20AND%20fixVersion%20%3D%20%22Auth%20Core%201.4.6%22
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-2238
>
> 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 2238 /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
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

[jira] [Resolved] (SLING-9347) Allow to specify includes/excludes for contents report

[Carsten Ziegeler (Jira)]

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

Carsten Ziegeler resolved SLING-9347.
-
Resolution: Fixed

Implemented include and exclude paramters. Refactored matching into separate 
class which is shared by several mojos
https://github.com/apache/sling-slingfeature-maven-plugin/commit/f0f7ca16544ae841b5a42856915019dbb75f1808

> Allow to specify includes/excludes for contents report
> --
>
> Key: SLING-9347
> URL: https://issues.apache.org/jira/browse/SLING-9347
> Project: Sling
>  Issue Type: Bug
>  Components: Maven Plugins and Archetypes
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.2.0
>
>
> The contents report from the info mojo reports all bundles and artifacts. We 
> should add support for specifying includes and excludes



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

[jira] [Created] (SLING-9347) Allow to specify includes/excludes for contents report

[Carsten Ziegeler (Jira)]

Carsten Ziegeler created SLING-9347:
---

 Summary: Allow to specify includes/excludes for contents report
 Key: SLING-9347
 URL: https://issues.apache.org/jira/browse/SLING-9347
 Project: Sling
  Issue Type: Bug
  Components: Maven Plugins and Archetypes
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: slingfeature-maven-plugin 1.2.0


The contents report from the info mojo reports all bundles and artifacts. We 
should add support for specifying includes and excludes



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

[Discussion] Sling distribution DELETE request expects remove permissions on source endpoint

[Mohit Arora]

Hello team,

We were hoping to have some discussion around [0] where when distributing 
content from source endpoint to a target endpoint, in case of DELETE request, 
sling.distribution.core bundle expects the source endpoint to have 
jcr:removeNode permissions on source instance. However, the actual deletion 
happens on the target instance. Is this an expected behavior? What was the 
rationale behind introducing this behavior?

Mohit

[0] https://issues.apache.org/jira/browse/SLING-9212

[jira] [Updated] (SLING-9345) Update to parent 38 and OSGi DS annotations

[Robert Munteanu (Jira)]

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

Robert Munteanu updated SLING-9345:
---
Parent: SLING-8734
Issue Type: Sub-task  (was: Improvement)

> Update to parent 38 and OSGi DS annotations
> ---
>
> Key: SLING-9345
> URL: https://issues.apache.org/jira/browse/SLING-9345
> Project: Sling
>  Issue Type: Sub-task
>  Components: Authentication
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: Auth Core 1.4.6
>
>




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

Re: [VOTE] Release Apache Sling Auth Core 1.4.6

[Robert Munteanu]

On Thu, 2020-04-09 at 11:19 +0200, Carsten Ziegeler wrote:
> Please vote to approve this release:

+1
Robert


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

[jira] [Commented] (SLING-9344) Sling CMS - Namespace for nodes is wrong in nodetypes.cnd

[Matthias Herold (Jira)]

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

Matthias Herold commented on SLING-9344:


Thank you for providing such a great package and for the quick fix. I think 
this might also fix SLING-9012 - I'm afraid I did not not spot the duplicate 
when filing the issue. 

> Sling CMS - Namespace for nodes is wrong in nodetypes.cnd
> -
>
> Key: SLING-9344
> URL: https://issues.apache.org/jira/browse/SLING-9344
> Project: Sling
>  Issue Type: Bug
>  Components: App CMS
>Affects Versions: App CMS 0.10.0
> Environment: Hardware does not matter, I assume - but I did test on 
> two different macs with Amazon Corretto 8 as JDK.
>Reporter: Matthias Herold
>Assignee: Dan Klco
>Priority: Major
> Fix For: App CMS 0.16.2
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The namespace specified in the file 
> ui/src/main/resources/SLING-INF/nodetypes/nodetypes.cnd of repository 
> sling-org-apache-sling-app-cms is wrong.
> Line 24 reads: http://www.sling.apache.org/sling/1.0'>
> This should be: http://sling.apache.org/jcr/sling/1.0'> 
> This is a major issue when creating new repositories: when you build a custom 
> starter package including Apache CMS and create a new repository with this 
> starter package afterwards, the namespace of all nodes in the repository is 
> automatically wrong. In normal operation, you won't notice that. But when you 
> export content as package from a sling instance with the right namespace and 
> import the content to a sling instance with the wrong namespace the import 
> will fail. I did not test the other way round, but assume the issue also 
> occurs there. 
> Suggested fix: change
> http://www.sling.apache.org/sling/1.0
> to 
> http://sling.apache.org/jcr/sling/1.0
> in 
> sling-org-apache-sling-app-cms/ui/src/main/resources/SLING-INF/nodetypes/nodetypes.cnd



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

Re: [VOTE] Release Apache Sling Auth Core 1.4.6

[Carsten Ziegeler]

+1

Carsten

On 09.04.2020 11:19, Carsten Ziegeler wrote:

Hi,

we solved 2 issues in this release

https://issues.apache.org/jira/browse/SLING-9345?jql=project%20%3D%20SLING%20AND%20fixVersion%20%3D%20%22Auth%20Core%201.4.6%22 



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

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 2238 /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
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org


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

[VOTE] Release Apache Sling Auth Core 1.4.6

[Carsten Ziegeler]

Hi,

we solved 2 issues in this release

https://issues.apache.org/jira/browse/SLING-9345?jql=project%20%3D%20SLING%20AND%20fixVersion%20%3D%20%22Auth%20Core%201.4.6%22

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

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 2238 /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
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[jira] [Resolved] (SLING-9345) Update to parent 38 and OSGi DS annotations

[Carsten Ziegeler (Jira)]

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

Carsten Ziegeler resolved SLING-9345.
-
Resolution: Fixed

Updated in 
https://github.com/apache/sling-org-apache-sling-auth-core/commit/c20aac62dfc1566bf24b8d6e24628f5650df836b
Fixed also some metatype issues with the update

> Update to parent 38 and OSGi DS annotations
> ---
>
> Key: SLING-9345
> URL: https://issues.apache.org/jira/browse/SLING-9345
> Project: Sling
>  Issue Type: Improvement
>  Components: Authentication
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: Auth Core 1.4.6
>
>




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

[jira] [Commented] (SLING-9060) Improve Redirect handling for Resources that can be served from alternative URLs

[Ian Boston (Jira)]

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

Ian Boston commented on SLING-9060:
---

For completeness,  it was decided not to pursue this issue as the immediate 
need for it has passed.

> Improve Redirect handling for Resources that can be served from alternative 
> URLs
> 
>
> Key: SLING-9060
> URL: https://issues.apache.org/jira/browse/SLING-9060
> Project: Sling
>  Issue Type: Improvement
>  Components: API, Servlets
>Affects Versions: API 2.22.0, Servlets Get 2.1.40
>Reporter: Ian Boston
>Assignee: Ian Boston
>Priority: Major
> Fix For: Servlets Get 2.1.42, API 2.23.0
>
>  Time Spent: 14h 20m
>  Remaining Estimate: 0h
>
> Improve the mechanism used to redirect streamed binary requests so that it 
> has the context of the request and can be extended without provider API 
> changes.
>  
> This was discussed on list at [https://markmail.org/message/msmxgulkmzx7czth 
> |https://markmail.org/message/msmxgulkmzx7czth]
> PR to follow



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

[jira] [Resolved] (SLING-9060) Improve Redirect handling for Resources that can be served from alternative URLs

[Ian Boston (Jira)]

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

Ian Boston resolved SLING-9060.
---
Resolution: Won't Fix

> Improve Redirect handling for Resources that can be served from alternative 
> URLs
> 
>
> Key: SLING-9060
> URL: https://issues.apache.org/jira/browse/SLING-9060
> Project: Sling
>  Issue Type: Improvement
>  Components: API, Servlets
>Affects Versions: API 2.22.0, Servlets Get 2.1.40
>Reporter: Ian Boston
>Assignee: Ian Boston
>Priority: Major
> Fix For: Servlets Get 2.1.42, API 2.23.0
>
>  Time Spent: 14h 20m
>  Remaining Estimate: 0h
>
> Improve the mechanism used to redirect streamed binary requests so that it 
> has the context of the request and can be extended without provider API 
> changes.
>  
> This was discussed on list at [https://markmail.org/message/msmxgulkmzx7czth 
> |https://markmail.org/message/msmxgulkmzx7czth]
> PR to follow



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

[jira] [Resolved] (SLING-9346) Skip files for which a script engine mapping doesn't exist

[Radu Cotescu (Jira)]

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

Radu Cotescu resolved SLING-9346.
-
Resolution: Fixed

Fixed in [commit 
603a3b9|https://github.com/apache/sling-scriptingbundle-maven-plugin/commit/603a3b9].

> Skip files for which a script engine mapping doesn't exist
> --
>
> Key: SLING-9346
> URL: https://issues.apache.org/jira/browse/SLING-9346
> Project: Sling
>  Issue Type: Bug
>  Components: Maven Plugins and Archetypes
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting Bundle Maven Plugin 0.2.0
>
>
> The Scripting Bundle Maven Plugin should skip files for which a script engine 
> mapping doesn't exist and analyse only {{requires}}, {{extends}} and files 
> with extensions covered by a mapping.



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

[jira] [Created] (SLING-9346) Skip files for which a script engine mapping doesn't exist

[Radu Cotescu (Jira)]

Radu Cotescu created SLING-9346:
---

 Summary: Skip files for which a script engine mapping doesn't exist
 Key: SLING-9346
 URL: https://issues.apache.org/jira/browse/SLING-9346
 Project: Sling
  Issue Type: Bug
  Components: Maven Plugins and Archetypes
Reporter: Radu Cotescu
Assignee: Radu Cotescu
 Fix For: Scripting Bundle Maven Plugin 0.2.0


The Scripting Bundle Maven Plugin should skip files for which a script engine 
mapping doesn't exist and analyse only {{requires}}, {{extends}} and files with 
extensions covered by a mapping.



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