[jira] [Comment Edited] (SLING-8848) Wrong calculation for copy/move whether single provider can be used

[Carsten Ziegeler (Jira)]

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

Carsten Ziegeler edited comment on SLING-8848 at 11/15/19 6:27 AM:
---

Fixed in 
https://github.com/apache/sling-org-apache-sling-resourceresolver/commit/c571ac6a9feea403e65d1bb5f68ab6638d20009b

And added more tests that verify the behaviour - the previous tests for 
copy/move did not detect the wrong calculation


was (Author: cziegeler):
Fixed in 
https://github.com/apache/sling-org-apache-sling-resourceresolver/commit/c571ac6a9feea403e65d1bb5f68ab6638d20009b

> Wrong calculation for copy/move whether single provider can be used
> ---
>
> Key: SLING-8848
> URL: https://issues.apache.org/jira/browse/SLING-8848
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.6.14
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: Resource Resolver 1.6.16
>
>
> When a copy/move is performed, the resource resolver checks whether a single 
> provider can perform the copy/move or if sub providers exist (or source and 
> dest have a different provider).
> The checking for sub providers is currently wrong and leads to a copy/move 
> being done "manually" (resource by resource)
> Credits to Christian Keller for finding this and submitting a patch



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

[jira] [Resolved] (SLING-8848) Wrong calculation for copy/move whether single provider can be used

[Carsten Ziegeler (Jira)]

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

Carsten Ziegeler resolved SLING-8848.
-
Resolution: Fixed

Fixed in 
https://github.com/apache/sling-org-apache-sling-resourceresolver/commit/c571ac6a9feea403e65d1bb5f68ab6638d20009b

> Wrong calculation for copy/move whether single provider can be used
> ---
>
> Key: SLING-8848
> URL: https://issues.apache.org/jira/browse/SLING-8848
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.6.14
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: Resource Resolver 1.6.16
>
>
> When a copy/move is performed, the resource resolver checks whether a single 
> provider can perform the copy/move or if sub providers exist (or source and 
> dest have a different provider).
> The checking for sub providers is currently wrong and leads to a copy/move 
> being done "manually" (resource by resource)
> Credits to Christian Keller for finding this and submitting a patch



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

[jira] [Created] (SLING-8848) Wrong calculation for copy/move whether single provider can be used

[Carsten Ziegeler (Jira)]

Carsten Ziegeler created SLING-8848:
---

 Summary: Wrong calculation for copy/move whether single provider 
can be used
 Key: SLING-8848
 URL: https://issues.apache.org/jira/browse/SLING-8848
 Project: Sling
  Issue Type: Bug
  Components: ResourceResolver
Affects Versions: Resource Resolver 1.6.14
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: Resource Resolver 1.6.16


When a copy/move is performed, the resource resolver checks whether a single 
provider can perform the copy/move or if sub providers exist (or source and 
dest have a different provider).
The checking for sub providers is currently wrong and leads to a copy/move 
being done "manually" (resource by resource)
Credits to Christian Keller for finding this and submitting a patch



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

[jira] [Comment Edited] (SLING-8706) Injections for java.util.Optional<> should be automatic optional

[Evgeny Tugarev (Jira)]

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

Evgeny Tugarev edited comment on SLING-8706 at 11/14/19 8:03 PM:
-

Thanks, [~sseifert] this exactly what I meant.


was (Author: etugarev):
Thanks, [~sseifert] this exactly what I meant. I'll check for other tickets :)

> Injections for java.util.Optional<> should be automatic optional 
> -
>
> Key: SLING-8706
> URL: https://issues.apache.org/jira/browse/SLING-8706
> Project: Sling
>  Issue Type: Improvement
>  Components: Sling Models
>Reporter: Jörg Hoh
>Priority: Major
>
> The current approach to support optional injections requires to annotate the 
> field with {{@Optional}} plus proper handling within the javacode (null 
> checks etc), which can be forgotten.
> So instead of
> {code}
> @Inject @Optional
> String fieldname;
> {code}
> it should also be possible to use this
> {code}
> @Inject
> Optional fieldname;
> {code}
> with the very same semantic. But the developer is forced to deal with the 
> case that the value is not present.



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

sling12 timeline/feature models

[Ruben Reusser]

hi,

I was wondering if there is a release timeline for Sling12. It seems 
Sling12 would be a great candidate to move over to feature models.


Would love to hear what the community thinks about that and if there is 
a way to contribute/get together and work on the sling 12 release.


Ruben

[jira] [Resolved] (SLING-8847) Upgrade to parent pom 35

[Radu Cotescu (Jira)]

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

Radu Cotescu resolved SLING-8847.
-
Resolution: Fixed

Fixed in [commit 
b2f9347|https://github.com/apache/sling-org-apache-sling-xss/commit/b2f9347].

> Upgrade to parent pom 35
> 
>
> Key: SLING-8847
> URL: https://issues.apache.org/jira/browse/SLING-8847
> Project: Sling
>  Issue Type: Sub-task
>  Components: XSS Protection API
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: XSS Protection API 2.1.12
>
>
> The {{org.apache.sling.xss}} bundle should be updated to version 35 of the 
> {{sling-bundle-parent}} pom, in order to allow builds with Java 11 and above.



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

[jira] [Updated] (SLING-8847) Upgrade to parent pom 35

[Radu Cotescu (Jira)]

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

Radu Cotescu updated SLING-8847:

Description: The {{org.apache.sling.xss}} bundle should be updated to 
version 35 of the {{sling-bundle-parent}} pom, in order to allow builds with 
Java 11 and above.

> Upgrade to parent pom 35
> 
>
> Key: SLING-8847
> URL: https://issues.apache.org/jira/browse/SLING-8847
> Project: Sling
>  Issue Type: Sub-task
>  Components: XSS Protection API
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: XSS Protection API 2.1.12
>
>
> The {{org.apache.sling.xss}} bundle should be updated to version 35 of the 
> {{sling-bundle-parent}} pom, in order to allow builds with Java 11 and above.



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

[jira] [Created] (SLING-8847) Upgrade to parent pom 35

[Radu Cotescu (Jira)]

Radu Cotescu created SLING-8847:
---

 Summary: Upgrade to parent pom 35
 Key: SLING-8847
 URL: https://issues.apache.org/jira/browse/SLING-8847
 Project: Sling
  Issue Type: Sub-task
  Components: XSS Protection API
Reporter: Radu Cotescu
Assignee: Radu Cotescu
 Fix For: XSS Protection API 2.1.12






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

Re: auto-created PRs from github/dependabot for security-related deps updates

[Eric Norman]

Well, if what you depend on is using proper semantic package versioning and
the version numbers you depend on have not changed, then there would be no
harm in updating the minimum version in your pom to the new one.  The
output in your manifest would be identical.

So it is more than just enforcement at runtime,  but a signal that the
maintainer is paying attention to security alerts and has verified the new
"security fixed" minimum version has been verified as not causing any
problems.

For me the hypothetical downside risks don't outweigh the upside benefit of
signaling that the maintainers are paying attention to security alerts.
Plus any automated security scans would stop warning about the old unsafe
dependencies.

But that's just my opinion.

Regards,
-Eric

On Thu, Nov 14, 2019 at 7:45 AM Stefan Seifert 
wrote:

> well, updating the dependency would not guarantee this, because our bundle
> contains only a dependency to the latest package version of the 3rdparty
> dep, not the bundle version which contains the security fix.
> thus the dependency may be fulfilled with an slightly older bundle that is
> still vulnerable.
>
> on the other hand updating to the latest version in such a huge step (2.3
> to 2.9) may lead to more hassle on target systems where only a new update
> of our bundle should be deployed and this forces updating other bundles as
> well (with no really need by the implementation of the bundle).
>
> in my pov the osgi package version dependencies are not the right vehicle
> to enforce deploying 3rdparty bundles without vulnerabilities on the target
> systems.
>
> stefan
>
> >-Original Message-
> >From: Eric Norman [mailto:enor...@apache.org]
> >Sent: Thursday, November 14, 2019 4:14 PM
> >To: Sling Developers List
> >Subject: Re: auto-created PRs from github/dependabot for security-related
> >deps updates
> >
> >I think I would prefer that we don't ever depend on any version with known
> >security issues .  So for me, it would be appropriate to take these PRs
> >seriously and apply the updates as requested.
> >
> >What would it hurt to have the next release of the affected sling bundle
> >depend on the newer minimum version to encourage adoption of the more
> >secure version of the dependency?
> >
> >Regards,
> >-Eric
> >
> >On Thu, Nov 14, 2019 at 2:01 AM Stefan Seifert 
> >wrote:
> >
> >> github started to auto-create PRs like this: [1]
> >>
> >> this feature is nice for standalone projects keeping their deps up-to-
> >date
> >> - but in our case it usually means the minimum API version of a
> >dependency
> >> we compile against, and not the version of the dependency we are running
> >in
> >> our OSGi container with.
> >>
> >> so for most our modules (except e.g. maven plugins) i think we do not
> >want
> >> this. we cannot switch this feature globally off as we have no access to
> >> the security area in the github project settings [2]. we could "talk
> >back"
> >> to the bot telling him to ignore this actual dependency (but not all for
> >> the project).
> >>
> >> WDYT?
> >>
> >> stefan
> >>
> >> [1]
> >> https://github.com/apache/sling-org-apache-sling-models-
> >jacksonexporter/pull/2
> >> [2]
> >> https://github.com/apache/sling-org-apache-sling-models-
> >jacksonexporter/network/alerts
> >>
> >>
> >>
>

RE: issues switching to bnd maven plugin

[Stefan Seifert]

this does not work for multi-line comments like for Import-Package:
https://github.com/apache/sling-org-apache-sling-caconfig-impl/blob/161ecfc1a1cf6f43e10af76d960283e11b3624fa/pom.xml#L56-L63

afaik bnd does not support # comments in between lines split with \

stefan

>-Original Message-
>From: Konrad Windszus [mailto:konra...@gmx.de]
>Sent: Thursday, November 14, 2019 5:38 PM
>To: dev@sling.apache.org
>Subject: Re: issues switching to bnd maven plugin
>
>Hi Stefan,
>usually you put the bnd parameter into CDATA.
>Then you can place comments in a line starting with "#"
>(https://bnd.bndtools.org/md/805-instructions.html
>).
>That should work well.
>At least it does for bundle-parent (https://github.com/apache/sling-
>parent/blob/cef099f9ebf55a23a99b1b297e42a5e620b1df99/sling-bundle-
>parent/pom.xml#L66 parent/blob/cef099f9ebf55a23a99b1b297e42a5e620b1df99/sling-bundle-
>parent/pom.xml#L66>).
>The merging is actually a feature of bnd itself.
>Konrad
>
>> On 14. Nov 2019, at 16:50, Stefan Seifert  wrote:
>>
>> i was able to find a solution for this problem, although the syntax is a
>bit fragile and non-intuitive:
>> https://github.com/apache/sling-org-apache-sling-caconfig-
>impl/commit/161ecfc1a1cf6f43e10af76d960283e11b3624fa
>>
>> the reason it was ignored completely in my first attempts was that i
>defined a  section directly on the plugin element, whereas
>in the parent pom it was defined on an execution element, which always had
>higher precedence. moving it down to the same position in the local POM
>lead to respecting both and merging the configurations.
>>
>> and putting comments in between the lines of the import statements worked
>as well with a) removing the CDATA around it and b) making sure the comment
>lines also end with "\" (outside the comment). not nice, but works.
>>
>> stefan
>>
>>
>>> -Original Message-
>>> From: Julian Sedding [mailto:jsedd...@gmail.com]
>>> Sent: Friday, November 1, 2019 12:34 PM
>>> To: Sling Developers List
>>> Subject: Re: issues switching to bnd maven plugin
>>>
>>> Hi Stefan
>>>
>>> I agree with your goals, but I think that *should* be possible with
>>> the bnd-maven-plugin. Recently I looked into the source of the plugin
>>> and the documentation suggests that you need to use either bnd
>>> instructions in the pom or a bnd-file (in my understanding that is per
>>> maven module). The instructions from a parent pom are then merged
>>> using custom logic, see [0]. Maybe reading the implementation of
>>> "loadProperties"[1] helps get you unstuck?
>>>
>>> Regards
>>> Julian
>>>
>>> [0] https://github.com/bndtools/bnd/blob/master/maven/bnd-maven-
>>> plugin/src/main/java/aQute/bnd/maven/plugin/BndMavenPlugin.java#L138-
>L150
>>> [1] https://github.com/bndtools/bnd/blob/master/maven/bnd-maven-
>>> plugin/src/main/java/aQute/bnd/maven/plugin/BndMavenPlugin.java#L479-
>L488
>>>
>>> On Fri, Nov 1, 2019 at 11:49 AM Stefan Seifert 
>>> wrote:

 additionally to the problems with the bnd baseline maven plugin I'm a
>bit
>>> happy with the way to express project-level bnd instructions with the
>bnd-
>>> maven-plugin, encountered on the branch [1].

 1. basically the bnd maven plugin supports both bnd.bnd file and
>>> configuration via bnd config parameter in the POM (although the latter
>is
>>> not recommended).
 - i know the bnd people have their own special view on POM files and
>XML
>>> file format and try to put everything outside the POM
 - i personally prefer to have those instructions all in the POM, e.g.
>>> they are then easily detectable also for uploaded libraries with their
>POM
>>> on maven central (and not only in the source jar)
 - in general it does not seem to be possible to define a "chain" of
>parts
>>> of bnd configurations in multiple parent poms, each contributing some
>>> aspect
 - unlike the maven-bundle-plugin there is only a single "bnd"
>>> configuration parameter (we are using it in sling-bundle-parent), and it
>>> does not seem to possible to define additional instructions in the local
>>> POM
 - or i did something wrong when trying it
 - especially if there are multiple parent POMs involved this seems to
>be
>>> a big restriction for me

 2. sometimes a module has some complex instructions which need line-by-
>>> line comments to know the reason why they are there
 - see [2] for example in caconfig-impl
 - this is no longer possible in a bnd file because it breaks the multi
>>> line syntax with \ in the line endings
 - so i ended up collecting the comments above the instructions [3], but
>>> this is not a good replacement
 - is there a better solution?

 3. i would like to have back an XML-structured way of defining bnd
>>> instructions as it was the case in maven-bundle-plugin in bnd-maven-
>plugin!
 - this was easy to document
 - and it nicely followed the maven-ways 

Re: issues switching to bnd maven plugin

[Konrad Windszus]

Hi Stefan,
usually you put the bnd parameter into CDATA.
Then you can place comments in a line starting with "#" 
(https://bnd.bndtools.org/md/805-instructions.html 
).
That should work well.
At least it does for bundle-parent 
(https://github.com/apache/sling-parent/blob/cef099f9ebf55a23a99b1b297e42a5e620b1df99/sling-bundle-parent/pom.xml#L66
 
).
The merging is actually a feature of bnd itself.
Konrad

> On 14. Nov 2019, at 16:50, Stefan Seifert  wrote:
> 
> i was able to find a solution for this problem, although the syntax is a bit 
> fragile and non-intuitive:
> https://github.com/apache/sling-org-apache-sling-caconfig-impl/commit/161ecfc1a1cf6f43e10af76d960283e11b3624fa
> 
> the reason it was ignored completely in my first attempts was that i defined 
> a  section directly on the plugin element, whereas in the 
> parent pom it was defined on an execution element, which always had higher 
> precedence. moving it down to the same position in the local POM lead to 
> respecting both and merging the configurations.
> 
> and putting comments in between the lines of the import statements worked as 
> well with a) removing the CDATA around it and b) making sure the comment 
> lines also end with "\" (outside the comment). not nice, but works.
> 
> stefan
> 
> 
>> -Original Message-
>> From: Julian Sedding [mailto:jsedd...@gmail.com]
>> Sent: Friday, November 1, 2019 12:34 PM
>> To: Sling Developers List
>> Subject: Re: issues switching to bnd maven plugin
>> 
>> Hi Stefan
>> 
>> I agree with your goals, but I think that *should* be possible with
>> the bnd-maven-plugin. Recently I looked into the source of the plugin
>> and the documentation suggests that you need to use either bnd
>> instructions in the pom or a bnd-file (in my understanding that is per
>> maven module). The instructions from a parent pom are then merged
>> using custom logic, see [0]. Maybe reading the implementation of
>> "loadProperties"[1] helps get you unstuck?
>> 
>> Regards
>> Julian
>> 
>> [0] https://github.com/bndtools/bnd/blob/master/maven/bnd-maven-
>> plugin/src/main/java/aQute/bnd/maven/plugin/BndMavenPlugin.java#L138-L150
>> [1] https://github.com/bndtools/bnd/blob/master/maven/bnd-maven-
>> plugin/src/main/java/aQute/bnd/maven/plugin/BndMavenPlugin.java#L479-L488
>> 
>> On Fri, Nov 1, 2019 at 11:49 AM Stefan Seifert 
>> wrote:
>>> 
>>> additionally to the problems with the bnd baseline maven plugin I'm a bit
>> happy with the way to express project-level bnd instructions with the bnd-
>> maven-plugin, encountered on the branch [1].
>>> 
>>> 1. basically the bnd maven plugin supports both bnd.bnd file and
>> configuration via bnd config parameter in the POM (although the latter is
>> not recommended).
>>> - i know the bnd people have their own special view on POM files and XML
>> file format and try to put everything outside the POM
>>> - i personally prefer to have those instructions all in the POM, e.g.
>> they are then easily detectable also for uploaded libraries with their POM
>> on maven central (and not only in the source jar)
>>> - in general it does not seem to be possible to define a "chain" of parts
>> of bnd configurations in multiple parent poms, each contributing some
>> aspect
>>> - unlike the maven-bundle-plugin there is only a single "bnd"
>> configuration parameter (we are using it in sling-bundle-parent), and it
>> does not seem to possible to define additional instructions in the local
>> POM
>>> - or i did something wrong when trying it
>>> - especially if there are multiple parent POMs involved this seems to be
>> a big restriction for me
>>> 
>>> 2. sometimes a module has some complex instructions which need line-by-
>> line comments to know the reason why they are there
>>> - see [2] for example in caconfig-impl
>>> - this is no longer possible in a bnd file because it breaks the multi
>> line syntax with \ in the line endings
>>> - so i ended up collecting the comments above the instructions [3], but
>> this is not a good replacement
>>> - is there a better solution?
>>> 
>>> 3. i would like to have back an XML-structured way of defining bnd
>> instructions as it was the case in maven-bundle-plugin in bnd-maven-plugin!
>>> - this was easy to document
>>> - and it nicely followed the maven-ways of inheriting and overwriting
>> individual parameters
>>> 
>>> stefan
>>> 
>>> [1] https://github.com/apache/sling-org-apache-sling-caconfig-
>> impl/tree/feature/SLING-8824-parent25
>>> [2] https://github.com/apache/sling-org-apache-sling-caconfig-
>> impl/blob/67fe5f95fe35665c30d95302264941715dcc8b60/pom.xml#L51-L59
>>> [3] https://github.com/apache/sling-org-apache-sling-caconfig-
>> impl/blob/5cf6a823255434c323060cf50ec51400d57499cd/bnd.bnd#L1-L8
>>> 
>>> 
> 

[jira] [Resolved] (SLING-8846) Successfully handling clear command should be logged

[Timothee Maret (Jira)]

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

Timothee Maret resolved SLING-8846.
---
Resolution: Fixed

> Successfully handling clear command should be logged
> 
>
> Key: SLING-8846
> URL: https://issues.apache.org/jira/browse/SLING-8846
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Journal Core 0.1.2
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.6
>
>
> We don't yet log successful processing of clear commands. We should log a 
> statement at INFO level 
> [here|https://github.com/apache/sling-org-apache-sling-distribution-journal/blob/0b977dbd4782291c14f4173e76ef1451568100a2/src/main/java/org/apache/sling/distribution/journal/impl/subscriber/DistributionSubscriber.java#L712].



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

[jira] [Commented] (SLING-8846) Successfully handling clear command should be logged

[Timothee Maret (Jira)]

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

Timothee Maret commented on SLING-8846:
---

Done in 
[dc8e24e5cdd45c72865d14b70e0977cd1f43e3af|https://github.com/apache/sling-org-apache-sling-distribution-journal/commit/dc8e24e5cdd45c72865d14b70e0977cd1f43e3af]

> Successfully handling clear command should be logged
> 
>
> Key: SLING-8846
> URL: https://issues.apache.org/jira/browse/SLING-8846
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Journal Core 0.1.2
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.6
>
>
> We don't yet log successful processing of clear commands. We should log a 
> statement at INFO level 
> [here|https://github.com/apache/sling-org-apache-sling-distribution-journal/blob/0b977dbd4782291c14f4173e76ef1451568100a2/src/main/java/org/apache/sling/distribution/journal/impl/subscriber/DistributionSubscriber.java#L712].



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

[jira] [Updated] (SLING-8743) Move DistributionQueueBuilderFactory class from impl to api surface

[Timothee Maret (Jira)]

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

Timothee Maret updated SLING-8743:
--
Fix Version/s: Content Distribution Journal Core 0.1.6

> Move DistributionQueueBuilderFactory class from impl to api surface
> ---
>
> Key: SLING-8743
> URL: https://issues.apache.org/jira/browse/SLING-8743
> Project: Sling
>  Issue Type: Task
>  Components: Content Distribution
>Reporter: Mohit Arora
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.6
>
>
> Currently, it is not possible to create an instance of DistributionQueue 
> using DitributionQueueBuilderFactory as the factory is inside an impl package 
> [0]. This should be exposed as an API so that consumers can get a reference 
> of it.
>  
> [0][https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/queue/impl/DistributionQueueProviderFactory.java]



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

[jira] [Assigned] (SLING-8743) Move DistributionQueueBuilderFactory class from impl to api surface

[Timothee Maret (Jira)]

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

Timothee Maret reassigned SLING-8743:
-

Assignee: Timothee Maret

> Move DistributionQueueBuilderFactory class from impl to api surface
> ---
>
> Key: SLING-8743
> URL: https://issues.apache.org/jira/browse/SLING-8743
> Project: Sling
>  Issue Type: Task
>  Components: Content Distribution
>Reporter: Mohit Arora
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.6
>
>
> Currently, it is not possible to create an instance of DistributionQueue 
> using DitributionQueueBuilderFactory as the factory is inside an impl package 
> [0]. This should be exposed as an API so that consumers can get a reference 
> of it.
>  
> [0][https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/queue/impl/DistributionQueueProviderFactory.java]



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

[jira] [Commented] (SLING-8751) Allow to extract arbitrary content packages from the package topic

[Timothee Maret (Jira)]

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

Timothee Maret commented on SLING-8751:
---

[~cschneider] the PR has been merged, can we resolve this issue ?

> Allow to extract arbitrary content packages from the package topic
> --
>
> Key: SLING-8751
> URL: https://issues.apache.org/jira/browse/SLING-8751
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Affects Versions: Content Distribution Journal Core 0.1.4
>Reporter: Christian Schneider
>Assignee: Christian Schneider
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.6
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> To debug some issues it would be very helpful to extract the content package 
> from a package message. 
> As messages are retained for several days we have a nice history present to 
> be used for analysing issues.
> The implementation should offer the service as a web console plugin. The main 
> url of the plugin shows a form to enter the offset of a package. The form 
> will issue a GET request with the offset as parameter. The request will also 
> be handled by the plugin and will return the binary of the package or 404 if 
> none was found.



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

[jira] [Closed] (SLING-8611) Support auto-installation of content packages

[Timothee Maret (Jira)]

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

Timothee Maret closed SLING-8611.
-

> Support auto-installation of content packages
> -
>
> Key: SLING-8611
> URL: https://issues.apache.org/jira/browse/SLING-8611
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Affects Versions: Content Distribution Journal Core 0.1.2
>Reporter: Christian Schneider
>Assignee: Christian Schneider
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.4
>
>
> Some kind of content can not be replicated using the normal distribution 
> packages.
> These cases can be covered by creating the change as a content package, 
> uploading content package to author, distributing it and then on the 
> publisher extracting the package.
> To support this case jorunalled distribution should allow to detect and auto 
> extract replicated content packages.
> To configure this feature a new config attribute packageHandling (Off, 
> Extract,Install) is introduced for SubscriberConfiguration. 
> By default the value Off is used which results in no changes to the current 
> model.
> Extract will call extract on the package and Install will call install on the 
> package.
>  



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

[jira] [Closed] (SLING-8554) Fix sonar issues

[Timothee Maret (Jira)]

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

Timothee Maret closed SLING-8554.
-

> Fix sonar issues
> 
>
> Key: SLING-8554
> URL: https://issues.apache.org/jira/browse/SLING-8554
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Affects Versions: Content Distribution Journal Kafka 0.1.2
>Reporter: Christian Schneider
>Assignee: Christian Schneider
>Priority: Major
> Fix For: Content Distribution Journal Kafka 0.1.4
>
>




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

[jira] [Closed] (SLING-8557) KafkaMessagePoller does not recover in case of exceptions

[Timothee Maret (Jira)]

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

Timothee Maret closed SLING-8557.
-

> KafkaMessagePoller does not recover in case of exceptions
> -
>
> Key: SLING-8557
> URL: https://issues.apache.org/jira/browse/SLING-8557
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Journal Kafka 0.1.2
>Reporter: Christian Schneider
>Assignee: Christian Schneider
>Priority: Major
> Fix For: Content Distribution Journal Kafka 0.1.4
>
>
> Currently  the KafkaMessagePoller simply shuts down on any exception while 
> talking to Kafka. 
> This leads to the system being in a non working state.
> I propose we move the error handling inside the while (running) loop. 
> The javadoc of KafkaConsumer say: "This client transparently handles the 
> failure of Kafka brokers". 
> So I would expect that we can simply log exceptions and KafkaConsumer handles 
> the reconnect.



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

[jira] [Closed] (SLING-8563) Error when building messages bundle with java 11

[Timothee Maret (Jira)]

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

Timothee Maret closed SLING-8563.
-

> Error when building messages bundle with java 11
> 
>
> Key: SLING-8563
> URL: https://issues.apache.org/jira/browse/SLING-8563
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Journal Messages 0.1.0
>Reporter: Christian Schneider
>Assignee: Christian Schneider
>Priority: Major
> Fix For: Content Distribution Journal Messages 0.1.2
>
>
> [*ERROR*] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test *(default-test)* 
> on project org.apache.sling.distribution.journal.messages: *Execution 
> default-test of goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test failed.*: 
> NullPointerException -> [Help 1]
> From the linked discussion it seems the maven-surefire-plugin 2.20.1 is not 
> compatible to Java 11.
>  



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

[jira] [Closed] (SLING-8531) Support JournalAvailabilityChecker exponential backoff

[Timothee Maret (Jira)]

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

Timothee Maret closed SLING-8531.
-

> Support JournalAvailabilityChecker exponential backoff 
> ---
>
> Key: SLING-8531
> URL: https://issues.apache.org/jira/browse/SLING-8531
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Affects Versions: Content Distribution Journal Core 0.1.2
>Reporter: Timothee Maret
>Assignee: Christian Schneider
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.4, Content 
> Distribution Journal Kafka 0.1.4, Content Distribution Journal Messages 0.1.2
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The average load generated by JournalAvailabilityChecker multiplies quickly 
> for multi tenant deployments. The checker can be configured (via Sling 
> Scheduler {{scheduler.period}}) to reduce the polling frequency but doing so 
> also reduces the sensibility to detect availability changes.
> To improve the sensibility we should support an exponential backoff 
> algorithm. The algorithm would divide the rate by two (up to a limit) every 
> time the availability status does not change and reset the rate when the 
> status changes. Steady states (available or unavailable) would eventually 
> yield the least load. In the average case (availability status is steady) the 
> load will be reduced up to the limit. In the worst case (availability changes 
> all the time) the load will not be reduced compared to today. 
> The base rate would be Sling Scheduler {{scheduler.period}}. The rate at time 
> t + 1 would be computed as follow: Rate~t+1~ = Multiplier~t+1~ * Rate~t+1~. 
> The table below summarise how the multiplier would evolve according to the 
> available status change. 
> ||State~t~||State~t+1~||Multiplier~t+1~||
> |unavailable|unavailable|max(2 * Multiplier~t~, limit)|
> |unavailable|available|1|
> |available|unavailable|1|
> |available|available|max(2 * Multiplier~t~, limit)|
> The limit would be hardcoded to 16 which would reduce the load by an order of 
> magnitude, we could expose the limit as a configuration later if needed.
> There should be no need to randomise the multiplier for now as the checker 
> are expected to be started at random time. If we hit a scenario where the 
> checkers start at the same time, we could simply randomise the first 
> scheduled event.
>  



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

[jira] [Closed] (SLING-8533) Send events for errors happening during messaging

[Timothee Maret (Jira)]

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

Timothee Maret closed SLING-8533.
-

> Send events for errors happening during messaging
> -
>
> Key: SLING-8533
> URL: https://issues.apache.org/jira/browse/SLING-8533
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Affects Versions: Content Distribution Journal Kafka 0.1.2, Content 
> Distribution Journal Messages 0.1.0
>Reporter: Christian Schneider
>Assignee: Christian Schneider
>Priority: Major
> Fix For: Content Distribution Journal Kafka 0.1.4, Content 
> Distribution Journal Messages 0.1.2
>
>
> The current JournalAvailableChecker creates too much load on the messaging 
> system as it constantly checks availability.
> The plan is to only check when errors happen during normal processing. To 
> make this work we need to publish the errors so JournalAvailableChecker can 
> see them.
> The idea is to send such errors to EventAdmin to avoid tight coupling.
> So this issue is about defining the events in the api and creating them in 
> the kafka journal impl.



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

[jira] [Updated] (SLING-8846) Successfully handling clear command should be logged

[Timothee Maret (Jira)]

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

Timothee Maret updated SLING-8846:
--
Summary: Successfully handling clear command should be logged  (was: Log 
handling clear command successfully)

> Successfully handling clear command should be logged
> 
>
> Key: SLING-8846
> URL: https://issues.apache.org/jira/browse/SLING-8846
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Journal Core 0.1.2
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.6
>
>
> We don't yet log successful processing of clear commands. We should log a 
> statement at INFO level 
> [here|https://github.com/apache/sling-org-apache-sling-distribution-journal/blob/0b977dbd4782291c14f4173e76ef1451568100a2/src/main/java/org/apache/sling/distribution/journal/impl/subscriber/DistributionSubscriber.java#L712].



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

[jira] [Created] (SLING-8846) Log handling clear command successfully

[Timothee Maret (Jira)]

Timothee Maret created SLING-8846:
-

 Summary: Log handling clear command successfully
 Key: SLING-8846
 URL: https://issues.apache.org/jira/browse/SLING-8846
 Project: Sling
  Issue Type: Bug
  Components: Content Distribution
Affects Versions: Content Distribution Journal Core 0.1.2
Reporter: Timothee Maret
Assignee: Timothee Maret
 Fix For: Content Distribution Journal Core 0.1.6


We don't yet log successful processing of clear commands. We should log a 
statement at INFO level 
[here|https://github.com/apache/sling-org-apache-sling-distribution-journal/blob/0b977dbd4782291c14f4173e76ef1451568100a2/src/main/java/org/apache/sling/distribution/journal/impl/subscriber/DistributionSubscriber.java#L712].



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

RE: issues switching to bnd maven plugin

[Stefan Seifert]

i was able to find a solution for this problem, although the syntax is a bit 
fragile and non-intuitive:
https://github.com/apache/sling-org-apache-sling-caconfig-impl/commit/161ecfc1a1cf6f43e10af76d960283e11b3624fa

the reason it was ignored completely in my first attempts was that i defined a 
 section directly on the plugin element, whereas in the parent 
pom it was defined on an execution element, which always had higher precedence. 
moving it down to the same position in the local POM lead to respecting both 
and merging the configurations.

and putting comments in between the lines of the import statements worked as 
well with a) removing the CDATA around it and b) making sure the comment lines 
also end with "\" (outside the comment). not nice, but works.

stefan


>-Original Message-
>From: Julian Sedding [mailto:jsedd...@gmail.com]
>Sent: Friday, November 1, 2019 12:34 PM
>To: Sling Developers List
>Subject: Re: issues switching to bnd maven plugin
>
>Hi Stefan
>
>I agree with your goals, but I think that *should* be possible with
>the bnd-maven-plugin. Recently I looked into the source of the plugin
>and the documentation suggests that you need to use either bnd
>instructions in the pom or a bnd-file (in my understanding that is per
>maven module). The instructions from a parent pom are then merged
>using custom logic, see [0]. Maybe reading the implementation of
>"loadProperties"[1] helps get you unstuck?
>
>Regards
>Julian
>
>[0] https://github.com/bndtools/bnd/blob/master/maven/bnd-maven-
>plugin/src/main/java/aQute/bnd/maven/plugin/BndMavenPlugin.java#L138-L150
>[1] https://github.com/bndtools/bnd/blob/master/maven/bnd-maven-
>plugin/src/main/java/aQute/bnd/maven/plugin/BndMavenPlugin.java#L479-L488
>
>On Fri, Nov 1, 2019 at 11:49 AM Stefan Seifert 
>wrote:
>>
>> additionally to the problems with the bnd baseline maven plugin I'm a bit
>happy with the way to express project-level bnd instructions with the bnd-
>maven-plugin, encountered on the branch [1].
>>
>> 1. basically the bnd maven plugin supports both bnd.bnd file and
>configuration via bnd config parameter in the POM (although the latter is
>not recommended).
>> - i know the bnd people have their own special view on POM files and XML
>file format and try to put everything outside the POM
>> - i personally prefer to have those instructions all in the POM, e.g.
>they are then easily detectable also for uploaded libraries with their POM
>on maven central (and not only in the source jar)
>> - in general it does not seem to be possible to define a "chain" of parts
>of bnd configurations in multiple parent poms, each contributing some
>aspect
>> - unlike the maven-bundle-plugin there is only a single "bnd"
>configuration parameter (we are using it in sling-bundle-parent), and it
>does not seem to possible to define additional instructions in the local
>POM
>> - or i did something wrong when trying it
>> - especially if there are multiple parent POMs involved this seems to be
>a big restriction for me
>>
>> 2. sometimes a module has some complex instructions which need line-by-
>line comments to know the reason why they are there
>> - see [2] for example in caconfig-impl
>> - this is no longer possible in a bnd file because it breaks the multi
>line syntax with \ in the line endings
>> - so i ended up collecting the comments above the instructions [3], but
>this is not a good replacement
>> - is there a better solution?
>>
>> 3. i would like to have back an XML-structured way of defining bnd
>instructions as it was the case in maven-bundle-plugin in bnd-maven-plugin!
>> - this was easy to document
>> - and it nicely followed the maven-ways of inheriting and overwriting
>individual parameters
>>
>> stefan
>>
>> [1] https://github.com/apache/sling-org-apache-sling-caconfig-
>impl/tree/feature/SLING-8824-parent25
>> [2] https://github.com/apache/sling-org-apache-sling-caconfig-
>impl/blob/67fe5f95fe35665c30d95302264941715dcc8b60/pom.xml#L51-L59
>> [3] https://github.com/apache/sling-org-apache-sling-caconfig-
>impl/blob/5cf6a823255434c323060cf50ec51400d57499cd/bnd.bnd#L1-L8
>>
>>

RE: auto-created PRs from github/dependabot for security-related deps updates

[Stefan Seifert]

well, updating the dependency would not guarantee this, because our bundle 
contains only a dependency to the latest package version of the 3rdparty dep, 
not the bundle version which contains the security fix.
thus the dependency may be fulfilled with an slightly older bundle that is 
still vulnerable.

on the other hand updating to the latest version in such a huge step (2.3 to 
2.9) may lead to more hassle on target systems where only a new update of our 
bundle should be deployed and this forces updating other bundles as well (with 
no really need by the implementation of the bundle).

in my pov the osgi package version dependencies are not the right vehicle to 
enforce deploying 3rdparty bundles without vulnerabilities on the target 
systems.

stefan

>-Original Message-
>From: Eric Norman [mailto:enor...@apache.org]
>Sent: Thursday, November 14, 2019 4:14 PM
>To: Sling Developers List
>Subject: Re: auto-created PRs from github/dependabot for security-related
>deps updates
>
>I think I would prefer that we don't ever depend on any version with known
>security issues .  So for me, it would be appropriate to take these PRs
>seriously and apply the updates as requested.
>
>What would it hurt to have the next release of the affected sling bundle
>depend on the newer minimum version to encourage adoption of the more
>secure version of the dependency?
>
>Regards,
>-Eric
>
>On Thu, Nov 14, 2019 at 2:01 AM Stefan Seifert 
>wrote:
>
>> github started to auto-create PRs like this: [1]
>>
>> this feature is nice for standalone projects keeping their deps up-to-
>date
>> - but in our case it usually means the minimum API version of a
>dependency
>> we compile against, and not the version of the dependency we are running
>in
>> our OSGi container with.
>>
>> so for most our modules (except e.g. maven plugins) i think we do not
>want
>> this. we cannot switch this feature globally off as we have no access to
>> the security area in the github project settings [2]. we could "talk
>back"
>> to the bot telling him to ignore this actual dependency (but not all for
>> the project).
>>
>> WDYT?
>>
>> stefan
>>
>> [1]
>> https://github.com/apache/sling-org-apache-sling-models-
>jacksonexporter/pull/2
>> [2]
>> https://github.com/apache/sling-org-apache-sling-models-
>jacksonexporter/network/alerts
>>
>>
>>

[jira] [Resolved] (SLING-8845) URL query parameter values are double-escaped for cases where namespace mangling has to be performed

[Radu Cotescu (Jira)]

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

Radu Cotescu resolved SLING-8845.
-
Resolution: Fixed

Fixed in [commit 
9927ab0|https://github.com/apache/sling-org-apache-sling-xss/commit/9927ab0].

> URL query parameter values are double-escaped for cases where namespace 
> mangling has to be performed
> 
>
> Key: SLING-8845
> URL: https://issues.apache.org/jira/browse/SLING-8845
> Project: Sling
>  Issue Type: Bug
>  Components: XSS Protection API
>Affects Versions: XSS Protection API 2.0.8
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: XSS Protection API 2.1.12
>
>
> URL query parameter values are double-escaped for cases where namespace 
> mangling has to be performed:
> {code:java}
> xssAPI.getValidHref("/path/to/page?key=%25text"); // -> 
> /path/to/page?key=%25text (which is correct)
> xssAPI.getValidHref("/path/to/page/jcr:content/par?key=%25text"); // -> 
> /path/to/page/_jcr_content/par?key=%2525text (which is wrong)
> {code}



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

Re: auto-created PRs from github/dependabot for security-related deps updates

[Eric Norman]

I think I would prefer that we don't ever depend on any version with known
security issues .  So for me, it would be appropriate to take these PRs
seriously and apply the updates as requested.

What would it hurt to have the next release of the affected sling bundle
depend on the newer minimum version to encourage adoption of the more
secure version of the dependency?

Regards,
-Eric

On Thu, Nov 14, 2019 at 2:01 AM Stefan Seifert 
wrote:

> github started to auto-create PRs like this: [1]
>
> this feature is nice for standalone projects keeping their deps up-to-date
> - but in our case it usually means the minimum API version of a dependency
> we compile against, and not the version of the dependency we are running in
> our OSGi container with.
>
> so for most our modules (except e.g. maven plugins) i think we do not want
> this. we cannot switch this feature globally off as we have no access to
> the security area in the github project settings [2]. we could "talk back"
> to the bot telling him to ignore this actual dependency (but not all for
> the project).
>
> WDYT?
>
> stefan
>
> [1]
> https://github.com/apache/sling-org-apache-sling-models-jacksonexporter/pull/2
> [2]
> https://github.com/apache/sling-org-apache-sling-models-jacksonexporter/network/alerts
>
>
>

[jira] [Resolved] (SLING-8737) Add support for lazily-evaluated bindings

[Radu Cotescu (Jira)]

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

Radu Cotescu resolved SLING-8737.
-
Resolution: Fixed

Fixed in [commit 
0324519|https://github.com/apache/sling-org-apache-sling-api/commit/0324519] 
and [commit 
13a7367|https://github.com/apache/sling-org-apache-sling-scripting-core/commit/13a7367].

> Add support for lazily-evaluated bindings
> -
>
> Key: SLING-8737
> URL: https://issues.apache.org/jira/browse/SLING-8737
> Project: Sling
>  Issue Type: New Feature
>  Components: Scripting
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting Core 2.1.0, API 2.21.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The {{org.apache.sling.scripting.core}} module provides support for passing a 
> {{javax.script.Bindings}} to script engines, through the 
> {{org.apache.sling.scripting.core.impl.DefaultSlingScript}} implementation of 
> the {{org.apache.sling.api.scripting.SlingScript}} interface . 
> {{org.apache.sling.scripting.core.impl.DefaultSlingScript}} relies directly 
> on {{javax.script.SimpleBindings}}, which means that the values with which 
> the map is populated have to be computed before insertion. In some cases 
> these computations are not trivial, however there's no guarantee that the 
> values will actually be used.
> In order to optimise the {{Bindings}} usage, given that Java 8 and above 
> provide the 
> [{{Supplier}}|https://docs.oracle.com/javase/8/docs/api/java/util/function/Supplier.html]
>  functional interface, both the {{org.apache.sling.api}} and 
> {{org.apache.sling.scripting.core}} modules should bring support for pusing 
> {{Suppliers}} into the {{Bindings}} maps, suppliers which would be invoked 
> on-demand.



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

[jira] [Assigned] (SLING-8845) URL query parameter values are double-escaped for cases where namespace mangling has to be performed

[Radu Cotescu (Jira)]

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

Radu Cotescu reassigned SLING-8845:
---

Assignee: Radu Cotescu

> URL query parameter values are double-escaped for cases where namespace 
> mangling has to be performed
> 
>
> Key: SLING-8845
> URL: https://issues.apache.org/jira/browse/SLING-8845
> Project: Sling
>  Issue Type: Bug
>  Components: XSS Protection API
>Affects Versions: XSS Protection API 2.0.8
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: XSS Protection API 2.1.12
>
>
> URL query parameter values are double-escaped for cases where namespace 
> mangling has to be performed:
> {code:java}
> xssAPI.getValidHref("/path/to/page?key=%25text"); // -> 
> /path/to/page?key=%25text (which is correct)
> xssAPI.getValidHref("/path/to/page/jcr:content/par?key=%25text"); // -> 
> /path/to/page/_jcr_content/par?key=%2525text (which is wrong)
> {code}



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

[jira] [Created] (SLING-8845) URL query parameter values are double-escaped for cases where namespace mangling has to be performed

[Radu Cotescu (Jira)]

Radu Cotescu created SLING-8845:
---

 Summary: URL query parameter values are double-escaped for cases 
where namespace mangling has to be performed
 Key: SLING-8845
 URL: https://issues.apache.org/jira/browse/SLING-8845
 Project: Sling
  Issue Type: Bug
  Components: XSS Protection API
Affects Versions: XSS Protection API 2.0.8
Reporter: Radu Cotescu
 Fix For: XSS Protection API 2.1.12


URL query parameter values are double-escaped for cases where namespace 
mangling has to be performed:

{code:java}
xssAPI.getValidHref("/path/to/page?key=%25text"); // -> 
/path/to/page?key=%25text (which is correct)

xssAPI.getValidHref("/path/to/page/jcr:content/par?key=%25text"); // -> 
/path/to/page/_jcr_content/par?key=%2525text (which is wrong)
{code}



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

[Jenkins] Sling » sling-org-apache-sling-launchpad-testing » master #394 is BROKEN

[Apache Jenkins Server]

Please see 
https://builds.apache.org/job/Sling/job/sling-org-apache-sling-launchpad-testing/job/master/394/
 for details.

No further emails will be sent until the status of the build is changed.
Build log follows below:

[...truncated 3449 lines...]
Please provide the jar on your classpath to parse sqlite files.
See tika-parsers/pom.xml for the correct version.
[INFO] 
[INFO] ---
[INFO]  T E S T S
[INFO] ---
[INFO] Running org.apache.sling.launchpad.webapp.jsp.TagFileTest
14:48:29,006 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could 
NOT find resource [logback.groovy]
14:48:29,007 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found 
resource [logback-test.xml] at 
[file:/home/jenkins/jenkins-slave/workspace/e-sling-launchpad-testing_master/target/test-classes/logback-test.xml]
14:48:29,010 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource 
[logback-test.xml] occurs multiple times on the classpath.
14:48:29,010 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource 
[logback-test.xml] occurs at 
[jar:file:/home/jenkins/.m2/repository/org/apache/sling/org.apache.sling.launchpad.integration-tests/12-SNAPSHOT/org.apache.sling.launchpad.integration-tests-12-SNAPSHOT.jar!/logback-test.xml]
14:48:29,010 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource 
[logback-test.xml] occurs at 
[file:/home/jenkins/jenkins-slave/workspace/e-sling-launchpad-testing_master/target/test-classes/logback-test.xml]
14:48:29,477 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction 
- debug attribute not set
14:48:29,480 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About 
to instantiate appender of type [ch.qos.logback.core.FileAppender]
14:48:29,498 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming 
appender as [file]
14:48:29,543 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA 
- Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] 
for [encoder] property
14:48:29,626 |-INFO in ch.qos.logback.core.FileAppender[file] - File property 
is set to [target/sling-tests.log]
14:48:29,629 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About 
to instantiate appender of type [ch.qos.logback.classic.sift.SiftingAppender]
14:48:29,633 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming 
appender as [sift]
14:48:29,652 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA 
- Assuming default type [ch.qos.logback.classic.sift.MDCBasedDiscriminator] for 
[discriminator] property
14:48:29,671 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - 
Setting level of logger [org.apache.sling.launchpad] to DEBUG
14:48:29,671 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - 
Setting level of ROOT logger to INFO
14:48:29,671 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - 
Attaching appender named [file] to Logger[ROOT]
14:48:29,673 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - 
Attaching appender named [sift] to Logger[ROOT]
14:48:29,673 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction 
- End of configuration.
14:48:29,676 |-INFO in ch.qos.logback.classic.joran.JoranConfigurator@1987807b 
- Registering current configuration as safe fallback point

Checking if the required Sling services are started (timeout 60 seconds)...
(base URLs=http://localhost:41000 and http://localhost:41000; servlet context=; 
readiness type=.txt : text/plain
[DEBUG] [ServiceReference 664 from bundle 94 : 
org.apache.sling.jcr.davex:1.3.10 ref=[javax.servlet.Servlet] 
properties={objectClass=[javax.servlet.Servlet], 
osgi.http.whiteboard.context.select=(osgi.http.whiteboard.context.name=DavExAuthHttpContext),
 osgi.http.whiteboard.servlet.pattern=/server/*, service.bundleid=94, 
service.description=Sling JcrRemoting Servlet, service.id=664, 
service.scope=singleton, service.vendor=The Apache Software Foundation, 
servlet.init.createAbsoluteURI=true, servlet.init.csrf-protection=disabled, 
servlet.init.protectedhandlers-config=org.apache.jackrabbit.server.remoting.davex.AclRemoveHandler,
 servlet.init.resource-path-prefix=/server, sling.auth.requirements=-/server}] 
Ignoring unmatching Servlet service
System property [org.owasp.esapi.opsteam] is not set
System property [org.owasp.esapi.devteam] is not set
Attempting to load ESAPI.properties via file I/O.
Attempting to load ESAPI.properties as resource file via file I/O.
Not found in 'org.owasp.esapi.resources' directory or file not readable: 
/home/jenkins/jenkins-slave/workspace/e-sling-launchpad-testing_master/target/_-41000/ESAPI.properties
Not found in SystemResource Directory/resourceDirectory: .esapi/ESAPI.properties
Not found in 'user.home' (/home/jenkins) directory: 
/home/jenkins/esapi/ESAPI.properties
Loading ESAPI.properties via file I/O failed. 

[jira] [Resolved] (SLING-8844) servlet-helpers: Update to Commons Collections 4

[Stefan Seifert (Jira)]

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

Stefan Seifert resolved SLING-8844.
---
Resolution: Fixed

https://github.com/apache/sling-org-apache-sling-servlet-helpers/commit/71ef769e5564cf78e49d6679a3270ba8706ae406

i've also updated the mockito dependency

> servlet-helpers: Update to Commons Collections 4
> 
>
> Key: SLING-8844
> URL: https://issues.apache.org/jira/browse/SLING-8844
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Servlet Helpers 1.3.0
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Minor
> Fix For: Servlet Helpers 1.3.2
>
>




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

[jira] [Commented] (SLING-8706) Injections for java.util.Optional<> should be automatic optional

[Evgeny Tugarev (Jira)]

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

Evgeny Tugarev commented on SLING-8706:
---

Thanks, [~sseifert] this exactly what I meant. I'll check for other tickets :)

> Injections for java.util.Optional<> should be automatic optional 
> -
>
> Key: SLING-8706
> URL: https://issues.apache.org/jira/browse/SLING-8706
> Project: Sling
>  Issue Type: Improvement
>  Components: Sling Models
>Reporter: Jörg Hoh
>Priority: Major
>
> The current approach to support optional injections requires to annotate the 
> field with {{@Optional}} plus proper handling within the javacode (null 
> checks etc), which can be forgotten.
> So instead of
> {code}
> @Inject @Optional
> String fieldname;
> {code}
> it should also be possible to use this
> {code}
> @Inject
> Optional fieldname;
> {code}
> with the very same semantic. But the developer is forced to deal with the 
> case that the value is not present.



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

[jira] [Created] (SLING-8844) servlet-helpers: Update to Commons Collections 4

[Stefan Seifert (Jira)]

Stefan Seifert created SLING-8844:
-

 Summary: servlet-helpers: Update to Commons Collections 4
 Key: SLING-8844
 URL: https://issues.apache.org/jira/browse/SLING-8844
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Servlet Helpers 1.3.0
Reporter: Stefan Seifert
Assignee: Stefan Seifert
 Fix For: Servlet Helpers 1.3.2






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

[GitHub] [sling-org-apache-sling-models-jacksonexporter] dependabot[bot] commented on issue #2: Bump jackson-databind from 2.3.2 to 2.9.10.1

[GitBox]

dependabot[bot] commented on issue #2: Bump jackson-databind from 2.3.2 to 
2.9.10.1
URL: 
https://github.com/apache/sling-org-apache-sling-models-jacksonexporter/pull/2#issuecomment-553914181
 
 
   OK, I won't notify you about com.fasterxml.jackson.core:jackson-databind 
again, unless you re-open this PR or update it yourself. 


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

[GitHub] [sling-org-apache-sling-models-jacksonexporter] stefanseifert closed pull request #2: Bump jackson-databind from 2.3.2 to 2.9.10.1

[GitBox]

stefanseifert closed pull request #2: Bump jackson-databind from 2.3.2 to 
2.9.10.1
URL: 
https://github.com/apache/sling-org-apache-sling-models-jacksonexporter/pull/2
 
 
   


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

[GitHub] [sling-org-apache-sling-models-jacksonexporter] stefanseifert commented on issue #2: Bump jackson-databind from 2.3.2 to 2.9.10.1

[GitBox]

stefanseifert commented on issue #2: Bump jackson-databind from 2.3.2 to 
2.9.10.1
URL: 
https://github.com/apache/sling-org-apache-sling-models-jacksonexporter/pull/2#issuecomment-553914156
 
 
   @dependabot ignore this dependency
   
   this is the minimal version we compile against, not the version which is 
used at runtime


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: issues switching to bnd baseline maven plugin

[Stefan Seifert]

>> 3. no warning in case of "excessive version increase"
>> - unlike the maven-bundle-plugin the bnd-baseline-maven-plugin does not
>seem to any longer output a warning if a package version is increased
>accidentally to a higher number than required (e.g. to 1.0.2 instead of
>1.0.1)
>Please create a bug at bnd for that.

the issue also occurs with bnd-baseline-maven-plugin 4.3.0, i've created a bug 
issue
https://github.com/bndtools/bnd/issues/3563

stefan

[jira] [Resolved] (SLING-8116) ValueMap - implement default methods using OSGI Converter

[Radu Cotescu (Jira)]

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

Radu Cotescu resolved SLING-8116.
-
Resolution: Fixed

> ValueMap - implement default methods using OSGI Converter
> -
>
> Key: SLING-8116
> URL: https://issues.apache.org/jira/browse/SLING-8116
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Reporter: Jason E Bailey
>Assignee: Jason E Bailey
>Priority: Major
> Fix For: API 2.21.0
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> Implement default methods in the ValueMap interface that leverages the OSGi 
> Converter
> see
>  [https://osgi.org/specification/osgi.cmpn/7.0.0/util.converter.html]
> Once this is implemented, custom implementations of the ValueMap interface 
> can start being removed, where appropriate, so that a consistent and 
> comprehensive conversion of properties occur.  We can then add new Rules to 
> the Converter to allow features to be populated to all ValueMap 
> implementations.
>  
> To implement this, the following will also need to happen
>  * The Converter bundle will need to be added as a required bundle
>  ** Various scripts that define the minimum needed set of bundles will need 
> to be updated
>  * Communication on the difference in behaviour between the current ValueMap 
> and the ValueMap with Converter
>  * Although not within the Maven definition. org.osgi.util.Function needs to 
> be available as well for the Converter to initiate correctly.
>  



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

[jira] [Commented] (SLING-8116) ValueMap - implement default methods using OSGI Converter

[Radu Cotescu (Jira)]

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

Radu Cotescu commented on SLING-8116:
-

With [commit 
6362381|https://github.com/apache/sling-org-apache-sling-api/commit/6362381] 
and [commit 
47f1f47|https://github.com/apache/sling-org-apache-sling-api/commit/47f1f47] I 
think this issue can be marked as resolved.

> ValueMap - implement default methods using OSGI Converter
> -
>
> Key: SLING-8116
> URL: https://issues.apache.org/jira/browse/SLING-8116
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Reporter: Jason E Bailey
>Assignee: Jason E Bailey
>Priority: Major
> Fix For: API 2.21.0
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> Implement default methods in the ValueMap interface that leverages the OSGi 
> Converter
> see
>  [https://osgi.org/specification/osgi.cmpn/7.0.0/util.converter.html]
> Once this is implemented, custom implementations of the ValueMap interface 
> can start being removed, where appropriate, so that a consistent and 
> comprehensive conversion of properties occur.  We can then add new Rules to 
> the Converter to allow features to be populated to all ValueMap 
> implementations.
>  
> To implement this, the following will also need to happen
>  * The Converter bundle will need to be added as a required bundle
>  ** Various scripts that define the minimum needed set of bundles will need 
> to be updated
>  * Communication on the difference in behaviour between the current ValueMap 
> and the ValueMap with Converter
>  * Although not within the Maven definition. org.osgi.util.Function needs to 
> be available as well for the Converter to initiate correctly.
>  



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

[jira] [Commented] (SLING-8706) Injections for java.util.Optional<> should be automatic optional

[Stefan Seifert (Jira)]

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

Stefan Seifert commented on SLING-8706:
---

there is an stackoverflow article about "Why java.util.Optional is not 
Serializable" with an answer
https://stackoverflow.com/a/24564612

"... the primary design goal for Optional is to be used as the return value of 
functions when a return value might be absent.  ... It was never intended for 
Optional to be used other ways, such as for optional method arguments or to be 
stored as a field in an object. And by extension, making Optional serializable 
would enable it to be stored persistently or transmitted across a network, both 
of which encourage uses far beyond its original design goal."

so the pattern above would somewhat contradict this design goal, although i 
like the approach as well.

> Injections for java.util.Optional<> should be automatic optional 
> -
>
> Key: SLING-8706
> URL: https://issues.apache.org/jira/browse/SLING-8706
> Project: Sling
>  Issue Type: Improvement
>  Components: Sling Models
>Reporter: Jörg Hoh
>Priority: Major
>
> The current approach to support optional injections requires to annotate the 
> field with {{@Optional}} plus proper handling within the javacode (null 
> checks etc), which can be forgotten.
> So instead of
> {code}
> @Inject @Optional
> String fieldname;
> {code}
> it should also be possible to use this
> {code}
> @Inject
> Optional fieldname;
> {code}
> with the very same semantic. But the developer is forced to deal with the 
> case that the value is not present.



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

[GitHub] [sling-org-apache-sling-dynamic-include] jfmitchell removed a comment on issue #1: Option to disable the URL params check when there is need to process all GET requests

[GitBox]

jfmitchell removed a comment on issue #1: Option to disable the URL params 
check when there is need to process all GET requests
URL: 
https://github.com/apache/sling-org-apache-sling-dynamic-include/pull/1#issuecomment-553872190
 
 
   This is great - but what might be better is if we had a mechanism that 
mirrored the ignoreUrlParams configuration in the dispatcher - so they could 
effectively be kept in sync.


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

[GitHub] [sling-org-apache-sling-dynamic-include] jfmitchell commented on issue #1: Option to disable the URL params check when there is need to process all GET requests

[GitBox]

jfmitchell commented on issue #1: Option to disable the URL params check when 
there is need to process all GET requests
URL: 
https://github.com/apache/sling-org-apache-sling-dynamic-include/pull/1#issuecomment-553872190
 
 
   This is great - but what might be better is if we had a mechanism that 
mirrored the ignoreUrlParams configuration in the dispatcher - so they could 
effectively be kept in sync.


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: auto-created PRs from github/dependabot for security-related deps updates

[Konrad Windszus]

Sounds good.
Konrad

> On 14. Nov 2019, at 11:01, Stefan Seifert  wrote:
> 
> github started to auto-create PRs like this: [1]
> 
> this feature is nice for standalone projects keeping their deps up-to-date - 
> but in our case it usually means the minimum API version of a dependency we 
> compile against, and not the version of the dependency we are running in our 
> OSGi container with.
> 
> so for most our modules (except e.g. maven plugins) i think we do not want 
> this. we cannot switch this feature globally off as we have no access to the 
> security area in the github project settings [2]. we could "talk back" to the 
> bot telling him to ignore this actual dependency (but not all for the 
> project).
> 
> WDYT?
> 
> stefan
> 
> [1] 
> https://github.com/apache/sling-org-apache-sling-models-jacksonexporter/pull/2
> [2] 
> https://github.com/apache/sling-org-apache-sling-models-jacksonexporter/network/alerts
> 
> 

auto-created PRs from github/dependabot for security-related deps updates

[Stefan Seifert]

github started to auto-create PRs like this: [1]

this feature is nice for standalone projects keeping their deps up-to-date - 
but in our case it usually means the minimum API version of a dependency we 
compile against, and not the version of the dependency we are running in our 
OSGi container with.

so for most our modules (except e.g. maven plugins) i think we do not want 
this. we cannot switch this feature globally off as we have no access to the 
security area in the github project settings [2]. we could "talk back" to the 
bot telling him to ignore this actual dependency (but not all for the project).

WDYT?

stefan

[1] 
https://github.com/apache/sling-org-apache-sling-models-jacksonexporter/pull/2
[2] 
https://github.com/apache/sling-org-apache-sling-models-jacksonexporter/network/alerts

Re: Code Styleguide

[Robert Munteanu]

Hi,

On Tue, 2019-11-12 at 11:47 +0100, Konrad Windszus wrote:
> Hi,
> As Angela noticed there is still no official code style guideline for
> Sling. Maybe we can at least document the minimum somewhere below 
> https://sling.apache.org/documentation/development.html <
> https://sling.apache.org/documentation/development.html> and provide
> an Eclipse Formatter Ruleset.
> Such a formatter can not only be applied by Eclipse, but also by
> IntelliJ (
> https://blog.jetbrains.com/idea/2014/01/intellij-idea-13-importing-code-formatter-settings-from-eclipse/
> <
> https://blog.jetbrains.com/idea/2014/01/intellij-idea-13-importing-code-formatter-settings-from-eclipse/>
> ;) and we could even think about optionally applying it with maven (
> https://code.revelc.net/formatter-maven-plugin <
> https://code.revelc.net/formatter-maven-plugin>;).
> 
> Also I would recommend to also reference 
> https://google.github.io/styleguide/javaguide.html <
> https://google.github.io/styleguide/javaguide.html> as the Oracle
> coding conventions are no longer maintained (
> https://www.oracle.com/technetwork/java/codeconventions-150003.pdf <
> https://www.oracle.com/technetwork/java/codeconventions-150003.pdf>;)
> .
> WDYT?

I think a style guide would work well for us.

I am not sure that reformatting whole modules is a worthwhile effort,
due to diffs being less usable, as Bertrand mentioned.

On one hand, whitespace-only changes can be 'absorbed' by git using

  git diff --ignore-all-space

and by GitHub.

  https://github.blog/2018-05-01-ignore-white-space-in-code-review/

On the other hand, if we decide to make changes with more impact, like
moving things on different lines, then we'll lose some of the ability
to check history.

I think there are some open questions at this point:

1. What kind of formatter do we want to apply? We can either go with
something minimalistic like spaces vs tabs, indent size, max line
length or we can go with a comprehensive formatter.

2. How to we enforce this? Ideally this would be IDE, Maven build, and
nicely surfaced in GitHub PRs.

3. What is the impact if applied globally? To put it otherwise, what
percentage of lines would be change if we just applied to the whole
Sling codebase?

At some point I developed [1] to help with configuring preferences in
the IDE, would be happy to enhance it if needed.

Thanks,
Robert

[1]: https://github.com/mojohaus/reusable-ide-preferences

Re: [org.apache.sling.api] new release?

[Robert Munteanu]

On Tue, 2019-11-12 at 12:46 +0100, Radu Cotescu wrote:
> Are you ok with moving SLING-8116, SLING-8493, SLING-8558 to 2.21.0?
> What about moving SLING-7510, SLING-8742 and SLING-8759 to a
> subsequent release, so that we can release 2.21.0 this week?

OK from my part, I have no immediate plans to work on the open issues.

Robert