Re: [VOTE] Release Apache Sling Launchpad Base 7.0.0-2.7.0
+1 regards, Karl On Wed, Dec 30, 2020 at 6:24 PM wrote: > > +1 > > David > > On Wednesday, 30 December 2020, Carsten Ziegeler > wrote: > > > +1 > > > > Carsten > > > > Am 28.12.2020 um 12:13 schrieb Karl Pauls: > > > >> We solved 1 issue in this release: > >> https://issues.apache.org/jira/projects/SLING/versions/12349525 > >> > >> Staging repository: > >> https://repository.apache.org/content/repositories/orgapachesling-2389 > >> > >> 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 2389 /tmp/sling-staging > >> > >> Please vote to approve these releases: > >> > >> [ ] +1 Approve the releases > >>[ ] 0 Don't care > >>[ ] -1 Don't release, because ... > >> > >> > > -- > > -- > > Carsten Ziegeler > > Adobe Research Switzerland > > cziege...@apache.org > > -- Karl Pauls karlpa...@gmail.com
[VOTE] Release Apache Sling Launchpad Base 7.0.0-2.7.0
We solved 1 issue in this release: https://issues.apache.org/jira/projects/SLING/versions/12349525 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2389 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 2389 /tmp/sling-staging Please vote to approve these releases: [ ] +1 Approve the releases [ ] 0 Don't care [ ] -1 Don't release, because ...
[jira] [Resolved] (SLING-10023) Update launchpad to Apache Felix Framework 7.0.0
[ https://issues.apache.org/jira/browse/SLING-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls resolved SLING-10023. Resolution: Fixed Done in https://github.com/apache/sling-org-apache-sling-launchpad-base/commit/1fa7e38af1c5438a5f9e7b10eaae851d8774e5ac > Update launchpad to Apache Felix Framework 7.0.0 > > > Key: SLING-10023 > URL: https://issues.apache.org/jira/browse/SLING-10023 > Project: Sling > Issue Type: Improvement > Components: Launchpad >Affects Versions: Launchpad Base 2.6.38 > Reporter: Karl Pauls >Assignee: Karl Pauls >Priority: Major > Fix For: Launchpad Base 2.7.0 > > Time Spent: 1h > Remaining Estimate: 0h > > We should update the launchpad base to Felix framework 7.0.0. As that will > require java8 now and implements the R8 core spec we should bump the minor > version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SLING-10023) Update launchpad to Apache Felix Framework 7.0.0
Karl Pauls created SLING-10023: -- Summary: Update launchpad to Apache Felix Framework 7.0.0 Key: SLING-10023 URL: https://issues.apache.org/jira/browse/SLING-10023 Project: Sling Issue Type: Improvement Components: Launchpad Affects Versions: Launchpad Base 2.6.38 Reporter: Karl Pauls Assignee: Karl Pauls Fix For: Launchpad Base 2.7.0 We should update the launchpad base to Felix framework 7.0.0. As that will require java8 now and implements the R8 core spec we should bump the minor version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SLING-10007) Update launchpad to Apache Felix Framework 6.0.4
[ https://issues.apache.org/jira/browse/SLING-10007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls closed SLING-10007. -- > Update launchpad to Apache Felix Framework 6.0.4 > > > Key: SLING-10007 > URL: https://issues.apache.org/jira/browse/SLING-10007 > Project: Sling > Issue Type: Improvement > Components: Launchpad >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: Launchpad Base 2.6.38 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [RESULT][VOTE] Release Apache Sling Launchpad Base 6.0.4-2.6.38
Time to call the vote on the Apache Sling Launchpad Base 6.0.4-2.6.38 release. * +1 votes from David Bosschaert, Carsten Ziegeler, and Karl Pauls. * No other votes. The vote is successful. I will make the artifacts available as soon as possible.
Re: [VOTE] Release Apache Sling Launchpad Base 6.0.4-2.6.38
+1 regards, Karl On Fri, Dec 18, 2020 at 7:04 AM Carsten Ziegeler wrote: > > +1 > > Carsten > > Am 17.12.2020 um 22:44 schrieb Karl Pauls: > > We solved 1 issue in this release: > > https://issues.apache.org/jira/projects/SLING/versions/12346661 > > > > Staging repository: > > https://repository.apache.org/content/repositories/orgapachesling-2387 > > > > 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 2387 /tmp/sling-staging > > > > Please vote to approve these releases: > > > >[ ] +1 Approve the releases > >[ ] 0 Don't care > >[ ] -1 Don't release, because ... > > > > -- > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org -- Karl Pauls karlpa...@gmail.com
Re: [VOTE] Release Apache Sling Feature Model 1.2.18, Feature Model Analyser 1.3.16, Feature Model API Regions Extension 1.1.16, slingfeature-maven-plugin 1.4.20
+ 1 regards, Karl On Friday, December 18, 2020, wrote: > Hi all, > > Forgot to complete the subject header on the intial email. Now with > subject. > > Here's my +1 > > David > > On Fri, 18 Dec 2020 at 10:09, wrote: > > > Hi all, > > > > I would like to call the release on the following Apache Sling Feature > > Model related components: > > > > Feature Model 1.2.18 > > https://issues.apache.org/jira/browse/SLING/fixforversion/12349438 > > > > Feature Model Analyser 1.3.16 > > https://issues.apache.org/jira/browse/SLING/fixforversion/12349439 > > > > Feature Model API Regions Extension 1.1.16 > > https://issues.apache.org/jira/browse/SLING/fixforversion/12349441 > > > > slingfeature-maven-plugin 1.4.20 > > https://issues.apache.org/jira/browse/SLING/fixforversion/12349444 > > > > Staging repository: > > https://repository.apache.org/content/repositories/orgapachesling-2388 > > > > 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 2388 /tmp/sling-staging > > > > Please vote to approve this release: > > > >[ ] +1 Approve the release > >[ ] -1 Don't release, because ... > > > > This majority vote is open for at least 72 hours. > > > > Best regards, > > > > David > > > -- Karl Pauls karlpa...@gmail.com
[VOTE] Release Apache Sling Launchpad Base 6.0.4-2.6.38
We solved 1 issue in this release: https://issues.apache.org/jira/projects/SLING/versions/12346661 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2387 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 2387 /tmp/sling-staging Please vote to approve these releases: [ ] +1 Approve the releases [ ] 0 Don't care [ ] -1 Don't release, because ...
[jira] [Closed] (SLING-9949) Speed-up bundled scripts resolution
[ https://issues.apache.org/jira/browse/SLING-9949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls closed SLING-9949. - > Speed-up bundled scripts resolution > --- > > Key: SLING-9949 > URL: https://issues.apache.org/jira/browse/SLING-9949 > Project: Sling > Issue Type: Improvement > Components: Scripting >Affects Versions: Servlets Resolver 2.7.10 > Reporter: Karl Pauls >Assignee: Karl Pauls >Priority: Major > Fix For: Servlets Resolver 2.7.12 > > Time Spent: 50m > Remaining Estimate: 0h > > When resolving bundled scripts the resolver is currently parsing the metadata > several times. That can be avoided using caching the parsed result. > Furthermore, the bundled script servlet is currently calculating the > providers on each request. That can be avoided by doing the calculation one > time when it is created. Additionally, it should unroll servlet exceptions > instead of wrapping them again in a servlet exception. > Finally, the MergingResourceProvider does right now construct its resource > tree completely from scratch every time a servlet is added - that can be > avoided by just adding the servlet to the existing tree. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [RESULT][VOTE] Release Apache Sling Servlets Resolver 2.7.12
Time to call the vote on the Apache Sling Servlets Resolver 2.7.12 release. * +1 votes from Daniellas Klco, Carsten Ziegeler, Radu Cotescu, Nicolas Peltier, and Karl Pauls. * No other votes. The vote is successful. I will make the artifacts available as soon as possible.
Re: [VOTE] Release Apache Sling Servlets Resolver 2.7.12
+1 regards, Karl On Mon, Dec 14, 2020 at 5:02 PM Nicolas Peltier wrote: > > +1 > > Le lun. 14 déc. 2020 à 16:53, Radu Cotescu a écrit : > > > +1 > > > > > On 11 Dec 2020, at 16:31, Karl Pauls wrote: > > > > > > Please vote to approve this release: > > > > > > [ ] +1 Approve the release > > > [ ] 0 Don't care > > > [ ] -1 Don't release, because ... > > > > -- Karl Pauls karlpa...@gmail.com
[VOTE] Release Apache Sling Servlets Resolver 2.7.12
We solved 1 issues in this release: https://issues.apache.org/jira/projects/SLING/versions/12349447 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2386/ 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 2386 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ...
[jira] [Closed] (SLING-9926) Wrong PID if configuration is in a nested folder
[ https://issues.apache.org/jira/browse/SLING-9926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls closed SLING-9926. - > Wrong PID if configuration is in a nested folder > > > Key: SLING-9926 > URL: https://issues.apache.org/jira/browse/SLING-9926 > Project: Sling > Issue Type: Bug > Components: Content-Package to Feature Model Converter >Affects Versions: Content-Package to Feature Model Converter 1.0.18 >Reporter: Carsten Ziegeler >Assignee: Karl Pauls >Priority: Major > Fix For: Content-Package to Feature Model Converter 1.0.24 > > > If a configuration is contained in a subfolder like > /apps/config/foo/myconfig.xml the resulting PID is currently foo/myconfig > instead of just myconfig > This is probably due to how the PID is derived from the patch using the regex -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SLING-9966) Update dependency to org.apache.sling.repoinit.parser
[ https://issues.apache.org/jira/browse/SLING-9966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls closed SLING-9966. - > Update dependency to org.apache.sling.repoinit.parser > - > > Key: SLING-9966 > URL: https://issues.apache.org/jira/browse/SLING-9966 > Project: Sling > Issue Type: Task > Components: Content-Package to Feature Model Converter >Reporter: Angela Schreiber >Assignee: Carsten Ziegeler >Priority: Major > Fix For: Content-Package to Feature Model Converter 1.0.24 > > > the module depends on an old version of _org.apache.sling.repoinit.parser_ > which probably doesn't support recent improvements. latest version is _1.6.2_ > afaik. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SLING-9955) misleading class name: Acl should be Ace
[
https://issues.apache.org/jira/browse/SLING-9955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls closed SLING-9955.
-
> misleading class name: Acl should be Ace
>
>
> Key: SLING-9955
> URL: https://issues.apache.org/jira/browse/SLING-9955
> Project: Sling
> Issue Type: Bug
> Components: Content-Package to Feature Model Converter
>Reporter: Angela Schreiber
>Assignee: Carsten Ziegeler
>Priority: Minor
> Fix For: Content-Package to Feature Model Converter 1.0.24
>
>
> The access control part of the {{Content-Package to Feature Model Converter}}
> is a bit confusing to read one reason for this: class and method names
> are misleading.
> {{ACL}} stands for _Access Control List_ but the class
> _org.apache.sling.feature.cpconverter.acl.Acl_ actually captures the
> information that is stored in a singular _Access Control Entry_ (aka ACE),
> which is the type of objects that go into an ACL.
> btw: i am also not sure the usage of _acl_ in the package name is correct
> what was probably intended was _accesscontrol_ in general.
> [~cziegeler], [~dsuess], [~karlpauls]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SLING-9963) AccessControlEntry: refactor 'operation' string to boolean/enum
[
https://issues.apache.org/jira/browse/SLING-9963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls closed SLING-9963.
-
> AccessControlEntry: refactor 'operation' string to boolean/enum
> ---
>
> Key: SLING-9963
> URL: https://issues.apache.org/jira/browse/SLING-9963
> Project: Sling
> Issue Type: Improvement
> Components: Content-Package to Feature Model Converter
>Reporter: Angela Schreiber
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.0.24
>
>
> the {{AccessControlEntry} takes an 'operation' as param to the constructor
> which can only have 2 values: 'allow' or 'false' in expected to ultimately
> form valid repo-init statements later.
> i would find it a lot cleared if a boolean 'isAllow' would be used instead
> and hardcoding the corresponding repo-init values 'allow' and 'deny' would be
> located in the {{AccessControlEntry}} class instead of being defined in
> {{RepPolicyEntryHandler}}. i spotted it while doing some initial work for
> SLING-9692 and found myself hardcoding the string "allow" again in the
> handler used for principal-based access control.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [RESULT][VOTE] Release Apache Sling Content-Package to Feature Model Converter 1.0.24
Time to call the vote on the Apache Sling Content-Package to Feature Model Converter 1.0.24 release. * +1 votes from David Bosschaert, Carsten Ziegeler, Daniel Klco, and Karl Pauls. * No other votes. The vote is successful. I will make the artifacts available as soon as possible.
Re: [VOTE] Release Apache Sling Content-Package to Feature Model Converter 1.0.24
+1 regards, Karl On Mon, Dec 7, 2020 at 5:03 PM Daniel Klco wrote: > > +1 > > On Mon, Dec 7, 2020 at 5:06 AM Carsten Ziegeler wrote: > > > > +1 > > > > Carsten > > > > Am 07.12.2020 um 09:27 schrieb Karl Pauls: > > > Hi all, > > > > > > I would like to call the release on the Content-Package to Feature > > > Model Converter 1.0.24 > > > https://issues.apache.org/jira/projects/SLING/versions/12349442 > > > > > > Staging repository: > > > https://repository.apache.org/content/repositories/orgapachesling-2385 > > > > > > 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 2385 /tmp/sling-staging > > > > > > Please vote to approve this release: > > > > > > [ ] +1 Approve the release > > > [ ] -1 Don't release, because ... > > > > > > This majority vote is open for at least 72 hours. > > > > > > > -- > > -- > > Carsten Ziegeler > > Adobe Research Switzerland > > cziege...@apache.org -- Karl Pauls karlpa...@gmail.com
[jira] [Resolved] (SLING-9971) AclManagerTest/RepPolicyEntryHandlerTest : no tests for 'deny' entries
[ https://issues.apache.org/jira/browse/SLING-9971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls resolved SLING-9971. --- Resolution: Fixed I added some deny entries in: https://github.com/apache/sling-org-apache-sling-feature-cpconverter/pull/44 > AclManagerTest/RepPolicyEntryHandlerTest : no tests for 'deny' entries > -- > > Key: SLING-9971 > URL: https://issues.apache.org/jira/browse/SLING-9971 > Project: Sling > Issue Type: Improvement > Components: Content-Package to Feature Model Converter >Reporter: Angela Schreiber > Assignee: Karl Pauls >Priority: Minor > Fix For: Content-Package to Feature Model Converter 1.0.26 > > > from what i can see there exists not a single test case for 'deny' access > control entries. while i agree that creating deny-entries for system users > should be considered bad practice, it's it possible with resource-based > access control setup (note though that principal-based access control setup > only allows for 'allow' entries, see > http://jackrabbit.apache.org/api/2.18/org/apache/jackrabbit/api/security/authorization/PrincipalAccessControlList.html#addEntry-java.lang.String-javax.jcr.security.Privilege:A- > and > http://jackrabbit.apache.org/oak/docs/security/authorization/principalbased.html#Implementation_Details). > unless the converter intended to prevent 'deny' entries from being used > (currently not the case), i think there should be at least 1 test that > verifies that deny entries will be properly converted. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (SLING-9971) AclManagerTest/RepPolicyEntryHandlerTest : no tests for 'deny' entries
[ https://issues.apache.org/jira/browse/SLING-9971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls reassigned SLING-9971: - Assignee: Karl Pauls > AclManagerTest/RepPolicyEntryHandlerTest : no tests for 'deny' entries > -- > > Key: SLING-9971 > URL: https://issues.apache.org/jira/browse/SLING-9971 > Project: Sling > Issue Type: Improvement > Components: Content-Package to Feature Model Converter >Reporter: Angela Schreiber > Assignee: Karl Pauls >Priority: Minor > Fix For: Content-Package to Feature Model Converter 1.0.26 > > > from what i can see there exists not a single test case for 'deny' access > control entries. while i agree that creating deny-entries for system users > should be considered bad practice, it's it possible with resource-based > access control setup (note though that principal-based access control setup > only allows for 'allow' entries, see > http://jackrabbit.apache.org/api/2.18/org/apache/jackrabbit/api/security/authorization/PrincipalAccessControlList.html#addEntry-java.lang.String-javax.jcr.security.Privilege:A- > and > http://jackrabbit.apache.org/oak/docs/security/authorization/principalbased.html#Implementation_Details). > unless the converter intended to prevent 'deny' entries from being used > (currently not the case), i think there should be at least 1 test that > verifies that deny entries will be properly converted. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-9967) AclManagerTest.makeSureAclsAreCreatedOnlyoutsideSytemUsersPaths covers too many different scenarios
[
https://issues.apache.org/jira/browse/SLING-9967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls resolved SLING-9967.
---
Resolution: Fixed
Done in
https://github.com/apache/sling-org-apache-sling-feature-cpconverter/pull/43
[~angela], thanks again for the review and the report!
> AclManagerTest.makeSureAclsAreCreatedOnlyoutsideSytemUsersPaths covers too
> many different scenarios
> ---
>
> Key: SLING-9967
> URL: https://issues.apache.org/jira/browse/SLING-9967
> Project: Sling
> Issue Type: Improvement
> Components: Content-Package to Feature Model Converter
>Reporter: Angela Schreiber
>Assignee: Karl Pauls
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.0.26
>
>
> {{AclManagerTest.makeSureAclsAreCreatedOnlyoutsideSytemUsersPaths}} should be
> refactored to cover just a single test scenario (matching the name of the
> method)
> despite the name of the test method it not only asserts that entries
> effective below/at the user home node are ignored (see SLING-9953 for the
> corresponding bug), but also covers entries at arbitrary paths as well as
> quote {{// add an ACL for unknown user}}, which IMHO doesn't belong here.
> to make things more confusing it additional add quote {{// emulate a second
> iteration of conversion}}, which IMHO is not clear why this is relevant for
> the original intended scenario.
> this just make any kind of bug fix or improvement of the code base extra hard
> as the test has too many different ways of failing. also, if SLING-9953 is
> fixed and the test gets removed, the other (legitimate) test-scenarios will
> also be gone without replacement.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (SLING-9967) AclManagerTest.makeSureAclsAreCreatedOnlyoutsideSytemUsersPaths covers too many different scenarios
[
https://issues.apache.org/jira/browse/SLING-9967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls reassigned SLING-9967:
-
Assignee: Karl Pauls
> AclManagerTest.makeSureAclsAreCreatedOnlyoutsideSytemUsersPaths covers too
> many different scenarios
> ---
>
> Key: SLING-9967
> URL: https://issues.apache.org/jira/browse/SLING-9967
> Project: Sling
> Issue Type: Improvement
> Components: Content-Package to Feature Model Converter
>Reporter: Angela Schreiber
>Assignee: Karl Pauls
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.0.26
>
>
> {{AclManagerTest.makeSureAclsAreCreatedOnlyoutsideSytemUsersPaths}} should be
> refactored to cover just a single test scenario (matching the name of the
> method)
> despite the name of the test method it not only asserts that entries
> effective below/at the user home node are ignored (see SLING-9953 for the
> corresponding bug), but also covers entries at arbitrary paths as well as
> quote {{// add an ACL for unknown user}}, which IMHO doesn't belong here.
> to make things more confusing it additional add quote {{// emulate a second
> iteration of conversion}}, which IMHO is not clear why this is relevant for
> the original intended scenario.
> this just make any kind of bug fix or improvement of the code base extra hard
> as the test has too many different ways of failing. also, if SLING-9953 is
> fixed and the test gets removed, the other (legitimate) test-scenarios will
> also be gone without replacement.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SLING-9960) AclManagerTest/RepPolicyEntryHandlerTest should use realistic service user path
[
https://issues.apache.org/jira/browse/SLING-9960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls resolved SLING-9960.
---
Resolution: Fixed
Done in
https://github.com/apache/sling-org-apache-sling-feature-cpconverter/pull/42
Thanks [~Angela] for the review!
> AclManagerTest/RepPolicyEntryHandlerTest should use realistic service user
> path
> ---
>
> Key: SLING-9960
> URL: https://issues.apache.org/jira/browse/SLING-9960
> Project: Sling
> Issue Type: Bug
> Components: Content-Package to Feature Model Converter
>Reporter: Angela Schreiber
>Assignee: Karl Pauls
>Priority: Minor
> Fix For: Content-Package to Feature Model Converter 1.0.26
>
>
> the code lines to add service users in {{AclManagerTest}} like
> https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/master/src/test/java/org/apache/sling/feature/cpconverter/acl/AclManagerTest.java#L74
> or
> https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/master/src/test/java/org/apache/sling/feature/cpconverter/acl/AclManagerTest.java#L79
> are a bit confusing to read. the path {{"/asd/public"}} would neither with a
> default jackrabbit/oak repository nor with Adobe AEM represent a valid path
> for a service user this makes it hard to understand the intention behind
> the code (see also SLING-9959 for why this matters).
> i would suggest to either use an absolute path starting with
> "/home/users/system" or the corresponding default path in Jackrabbit Oak
> concatenated with some arbitrary node name for the user node itself.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (SLING-9960) AclManagerTest/RepPolicyEntryHandlerTest should use realistic service user path
[
https://issues.apache.org/jira/browse/SLING-9960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls reassigned SLING-9960:
-
Assignee: Karl Pauls
> AclManagerTest/RepPolicyEntryHandlerTest should use realistic service user
> path
> ---
>
> Key: SLING-9960
> URL: https://issues.apache.org/jira/browse/SLING-9960
> Project: Sling
> Issue Type: Bug
> Components: Content-Package to Feature Model Converter
>Reporter: Angela Schreiber
>Assignee: Karl Pauls
>Priority: Minor
> Fix For: Content-Package to Feature Model Converter 1.0.26
>
>
> the code lines to add service users in {{AclManagerTest}} like
> https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/master/src/test/java/org/apache/sling/feature/cpconverter/acl/AclManagerTest.java#L74
> or
> https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/master/src/test/java/org/apache/sling/feature/cpconverter/acl/AclManagerTest.java#L79
> are a bit confusing to read. the path {{"/asd/public"}} would neither with a
> default jackrabbit/oak repository nor with Adobe AEM represent a valid path
> for a service user this makes it hard to understand the intention behind
> the code (see also SLING-9959 for why this matters).
> i would suggest to either use an absolute path starting with
> "/home/users/system" or the corresponding default path in Jackrabbit Oak
> concatenated with some arbitrary node name for the user node itself.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SLING-9976) Refactor RepPolicyEntryHandler to allow for other types of access control lists
[
https://issues.apache.org/jira/browse/SLING-9976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls resolved SLING-9976.
---
Resolution: Fixed
I merged the PR - thanks!
> Refactor RepPolicyEntryHandler to allow for other types of access control
> lists
> ---
>
> Key: SLING-9976
> URL: https://issues.apache.org/jira/browse/SLING-9976
> Project: Sling
> Issue Type: Task
> Components: Content-Package to Feature Model Converter
>Reporter: Angela Schreiber
>Assignee: Karl Pauls
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.0.26
>
> Attachments: SLING-9976.patch
>
>
> to deal with other types of access control lists namely
> - repository-level entries defined for the 'null' path SLING-9956 and
> - principal-based access control policies SLING-9692)
> it would be desirable to refactor the common parts of
> {{RepPolicyEntryHandler}} into an abstract base class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (SLING-9976) Refactor RepPolicyEntryHandler to allow for other types of access control lists
[
https://issues.apache.org/jira/browse/SLING-9976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls reassigned SLING-9976:
-
Assignee: Karl Pauls
> Refactor RepPolicyEntryHandler to allow for other types of access control
> lists
> ---
>
> Key: SLING-9976
> URL: https://issues.apache.org/jira/browse/SLING-9976
> Project: Sling
> Issue Type: Task
> Components: Content-Package to Feature Model Converter
>Reporter: Angela Schreiber
>Assignee: Karl Pauls
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.0.26
>
> Attachments: SLING-9976.patch
>
>
> to deal with other types of access control lists namely
> - repository-level entries defined for the 'null' path SLING-9956 and
> - principal-based access control policies SLING-9692)
> it would be desirable to refactor the common parts of
> {{RepPolicyEntryHandler}} into an abstract base class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SLING-9959) SystemUser.getPath must reveal the path of the original user node
[
https://issues.apache.org/jira/browse/SLING-9959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls resolved SLING-9959.
---
Resolution: Fixed
> SystemUser.getPath must reveal the path of the original user node
> -
>
> Key: SLING-9959
> URL: https://issues.apache.org/jira/browse/SLING-9959
> Project: Sling
> Issue Type: Bug
> Components: Content-Package to Feature Model Converter
>Reporter: Angela Schreiber
> Assignee: Karl Pauls
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.0.26
>
>
> -found the following repo-init statement to create system users:-
> -[https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/master/src/main/java/org/apache/sling/feature/cpconverter/acl/DefaultAclManager.java#L109]-
> -which states:-
> {code:java}
> formatter.format("create service user %s with path %s%n", systemUser.getId(),
> systemUser.getPath());
> {code}
> -now i might be mistaken, but if my reading of the {{SystemUserParser}}
> is correct, the path defined with the {{SystemUser}} instance actually
> reflects the path of the system user node itself:-
> -[https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/master/src/main/java/org/apache/sling/feature/cpconverter/handlers/SystemUsersEntryHandler.java#L70-L75]-
> -if that was true the repo-init statements would be wrong, because the path
> argument doesn't specify that path of the user node itself but rather the
> intermediate path to be used.-
> -so the statement should probably read:-
> {code:java}
> formatter.format("create service user %s with path %s%n", systemUser.getId(),
> systemUser.getParent().getPath());
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-9959) SystemUser.getPath must reveal the path of the original user node
[
https://issues.apache.org/jira/browse/SLING-9959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17246682#comment-17246682
]
Karl Pauls commented on SLING-9959:
---
Done in
https://github.com/apache/sling-org-apache-sling-feature-cpconverter/pull/40 -
thanks a lot for the review [~angela]
> SystemUser.getPath must reveal the path of the original user node
> -
>
> Key: SLING-9959
> URL: https://issues.apache.org/jira/browse/SLING-9959
> Project: Sling
> Issue Type: Bug
> Components: Content-Package to Feature Model Converter
>Reporter: Angela Schreiber
> Assignee: Karl Pauls
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.0.26
>
>
> -found the following repo-init statement to create system users:-
> -[https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/master/src/main/java/org/apache/sling/feature/cpconverter/acl/DefaultAclManager.java#L109]-
> -which states:-
> {code:java}
> formatter.format("create service user %s with path %s%n", systemUser.getId(),
> systemUser.getPath());
> {code}
> -now i might be mistaken, but if my reading of the {{SystemUserParser}}
> is correct, the path defined with the {{SystemUser}} instance actually
> reflects the path of the system user node itself:-
> -[https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/master/src/main/java/org/apache/sling/feature/cpconverter/handlers/SystemUsersEntryHandler.java#L70-L75]-
> -if that was true the repo-init statements would be wrong, because the path
> argument doesn't specify that path of the user node itself but rather the
> intermediate path to be used.-
> -so the statement should probably read:-
> {code:java}
> formatter.format("create service user %s with path %s%n", systemUser.getId(),
> systemUser.getParent().getPath());
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-9959) SystemUser.getPath must reveal the path of the original user node
[
https://issues.apache.org/jira/browse/SLING-9959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17246584#comment-17246584
]
Karl Pauls commented on SLING-9959:
---
I created a PR of what I understand the proposal is:
https://github.com/apache/sling-org-apache-sling-feature-cpconverter/pull/40
> SystemUser.getPath must reveal the path of the original user node
> -
>
> Key: SLING-9959
> URL: https://issues.apache.org/jira/browse/SLING-9959
> Project: Sling
> Issue Type: Bug
> Components: Content-Package to Feature Model Converter
>Reporter: Angela Schreiber
> Assignee: Karl Pauls
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.0.26
>
>
> -found the following repo-init statement to create system users:-
> -[https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/master/src/main/java/org/apache/sling/feature/cpconverter/acl/DefaultAclManager.java#L109]-
> -which states:-
> {code:java}
> formatter.format("create service user %s with path %s%n", systemUser.getId(),
> systemUser.getPath());
> {code}
> -now i might be mistaken, but if my reading of the {{SystemUserParser}}
> is correct, the path defined with the {{SystemUser}} instance actually
> reflects the path of the system user node itself:-
> -[https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/master/src/main/java/org/apache/sling/feature/cpconverter/handlers/SystemUsersEntryHandler.java#L70-L75]-
> -if that was true the repo-init statements would be wrong, because the path
> argument doesn't specify that path of the user node itself but rather the
> intermediate path to be used.-
> -so the statement should probably read:-
> {code:java}
> formatter.format("create service user %s with path %s%n", systemUser.getId(),
> systemUser.getParent().getPath());
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SLING-9970) SystemUser.getPath doesn't reflect the repository path
[
https://issues.apache.org/jira/browse/SLING-9970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls resolved SLING-9970.
---
Resolution: Fixed
Thanks [~Angela] - I merged your patch.
> SystemUser.getPath doesn't reflect the repository path
> --
>
> Key: SLING-9970
> URL: https://issues.apache.org/jira/browse/SLING-9970
> Project: Sling
> Issue Type: Bug
> Components: Content-Package to Feature Model Converter
>Reporter: Angela Schreiber
> Assignee: Karl Pauls
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.0.26
>
>
> I tried to find out why {{AccessControlEntry}} is constructed with 2
> different {{RepoPath}}s one reflecting the path as obtained from the parser
> and one containing the path converted to 'repository path' using
> {{PlatformNameFormat.getRepositoryPath(resourcePath)}}.
> from what i see the 'repository' path contained in the entry is later used to
> create the hierarchy down to access controlled nodes that hold the
> resource-based access control policy with the entries.
> but looking at the usages of the 'path' field i found that it is only used in
> https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/master/src/main/java/org/apache/sling/feature/cpconverter/accesscontrol/DefaultAclManager.java#L152
> (see also SLING-9953)
> {code}
> // clean the unneeded ACLs, see SLING-8561
> if (authorizations != null) {
> Iterator authorizationsIterator =
> authorizations.iterator();
> while (authorizationsIterator.hasNext()) {
> AccessControlEntry acl = authorizationsIterator.next();
> if (acl.getPath().startsWith(systemUser.getPath())) {
> authorizationsIterator.remove();
> }
> }
> }
> {code}
> this finding lead me to the conclusion that the {{SystemUser}} object is in
> fact created with a path that doesn't actually represent the JCR path as
> found in the repository.
> so, all usages of {{SystemUser.getPath}} used to create the system user will
> potentially use the 'wrong' path. for example:
> https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/master/src/main/java/org/apache/sling/feature/cpconverter/accesscontrol/DefaultAclManager.java#L105
> {code}
> // TODO does it harm?!?
> addSystemUserPath(formatter, systemUser.getPath());
> {code}
> which the issues the following repo-init statement
> {code}
> formatter.format("create path (rep:AuthorizableFolder) %s%n", path);
> {code}
> and
> https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/master/src/main/java/org/apache/sling/feature/cpconverter/accesscontrol/DefaultAclManager.java#L109
> {code}
> formatter.format("create service user %s with path %s%n", systemUser.getId(),
> systemUser.getPath());
> {code}
> upon a quick (but maybe incomplete) search I didn't find any usage of
> {{SystemUser.getPath()}} that would require it to reflect the path as
> extracted from the content package if that was true, the method should be
> renamed to 'getRepositoryPath' and should return the converted path (see
> above).
> Having this addressed would IMO subsequently allow to drop the duplicated
> path argument from the {{AccessControlEntry}} and drop the {{getPath}} method
> altogether. which anyway seems a bit confusing to have. let me know if i
> should create a separate issue for this follow up clean up.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (SLING-9959) SystemUser.getPath must reveal the path of the original user node
[
https://issues.apache.org/jira/browse/SLING-9959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls reassigned SLING-9959:
-
Assignee: Karl Pauls
> SystemUser.getPath must reveal the path of the original user node
> -
>
> Key: SLING-9959
> URL: https://issues.apache.org/jira/browse/SLING-9959
> Project: Sling
> Issue Type: Bug
> Components: Content-Package to Feature Model Converter
>Reporter: Angela Schreiber
> Assignee: Karl Pauls
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.0.26
>
>
> -found the following repo-init statement to create system users:-
> -[https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/master/src/main/java/org/apache/sling/feature/cpconverter/acl/DefaultAclManager.java#L109]-
> -which states:-
> {code:java}
> formatter.format("create service user %s with path %s%n", systemUser.getId(),
> systemUser.getPath());
> {code}
> -now i might be mistaken, but if my reading of the {{SystemUserParser}}
> is correct, the path defined with the {{SystemUser}} instance actually
> reflects the path of the system user node itself:-
> -[https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/master/src/main/java/org/apache/sling/feature/cpconverter/handlers/SystemUsersEntryHandler.java#L70-L75]-
> -if that was true the repo-init statements would be wrong, because the path
> argument doesn't specify that path of the user node itself but rather the
> intermediate path to be used.-
> -so the statement should probably read:-
> {code:java}
> formatter.format("create service user %s with path %s%n", systemUser.getId(),
> systemUser.getParent().getPath());
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (SLING-9970) SystemUser.getPath doesn't reflect the repository path
[
https://issues.apache.org/jira/browse/SLING-9970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls reassigned SLING-9970:
-
Assignee: Karl Pauls
> SystemUser.getPath doesn't reflect the repository path
> --
>
> Key: SLING-9970
> URL: https://issues.apache.org/jira/browse/SLING-9970
> Project: Sling
> Issue Type: Bug
> Components: Content-Package to Feature Model Converter
>Reporter: Angela Schreiber
> Assignee: Karl Pauls
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.0.26
>
>
> I tried to find out why {{AccessControlEntry}} is constructed with 2
> different {{RepoPath}}s one reflecting the path as obtained from the parser
> and one containing the path converted to 'repository path' using
> {{PlatformNameFormat.getRepositoryPath(resourcePath)}}.
> from what i see the 'repository' path contained in the entry is later used to
> create the hierarchy down to access controlled nodes that hold the
> resource-based access control policy with the entries.
> but looking at the usages of the 'path' field i found that it is only used in
> https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/master/src/main/java/org/apache/sling/feature/cpconverter/accesscontrol/DefaultAclManager.java#L152
> (see also SLING-9953)
> {code}
> // clean the unneeded ACLs, see SLING-8561
> if (authorizations != null) {
> Iterator authorizationsIterator =
> authorizations.iterator();
> while (authorizationsIterator.hasNext()) {
> AccessControlEntry acl = authorizationsIterator.next();
> if (acl.getPath().startsWith(systemUser.getPath())) {
> authorizationsIterator.remove();
> }
> }
> }
> {code}
> this finding lead me to the conclusion that the {{SystemUser}} object is in
> fact created with a path that doesn't actually represent the JCR path as
> found in the repository.
> so, all usages of {{SystemUser.getPath}} used to create the system user will
> potentially use the 'wrong' path. for example:
> https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/master/src/main/java/org/apache/sling/feature/cpconverter/accesscontrol/DefaultAclManager.java#L105
> {code}
> // TODO does it harm?!?
> addSystemUserPath(formatter, systemUser.getPath());
> {code}
> which the issues the following repo-init statement
> {code}
> formatter.format("create path (rep:AuthorizableFolder) %s%n", path);
> {code}
> and
> https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/master/src/main/java/org/apache/sling/feature/cpconverter/accesscontrol/DefaultAclManager.java#L109
> {code}
> formatter.format("create service user %s with path %s%n", systemUser.getId(),
> systemUser.getPath());
> {code}
> upon a quick (but maybe incomplete) search I didn't find any usage of
> {{SystemUser.getPath()}} that would require it to reflect the path as
> extracted from the content package if that was true, the method should be
> renamed to 'getRepositoryPath' and should return the converted path (see
> above).
> Having this addressed would IMO subsequently allow to drop the duplicated
> path argument from the {{AccessControlEntry}} and drop the {{getPath}} method
> altogether. which anyway seems a bit confusing to have. let me know if i
> should create a separate issue for this follow up clean up.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[VOTE] Release Apache Sling Content-Package to Feature Model Converter 1.0.24
Hi all, I would like to call the release on the Content-Package to Feature Model Converter 1.0.24 https://issues.apache.org/jira/projects/SLING/versions/12349442 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2385 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 2385 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours.
[jira] [Resolved] (SLING-9926) Wrong PID if configuration is in a nested folder
[ https://issues.apache.org/jira/browse/SLING-9926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls resolved SLING-9926. --- Resolution: Fixed > Wrong PID if configuration is in a nested folder > > > Key: SLING-9926 > URL: https://issues.apache.org/jira/browse/SLING-9926 > Project: Sling > Issue Type: Bug > Components: Content-Package to Feature Model Converter >Affects Versions: Content-Package to Feature Model Converter 1.0.18 >Reporter: Carsten Ziegeler >Assignee: Karl Pauls >Priority: Major > Fix For: Content-Package to Feature Model Converter 1.0.24 > > > If a configuration is contained in a subfolder like > /apps/config/foo/myconfig.xml the resulting PID is currently foo/myconfig > instead of just myconfig > This is probably due to how the PID is derived from the patch using the regex -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-9949) Speed-up bundled scripts resolution
[ https://issues.apache.org/jira/browse/SLING-9949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls resolved SLING-9949. --- Resolution: Fixed > Speed-up bundled scripts resolution > --- > > Key: SLING-9949 > URL: https://issues.apache.org/jira/browse/SLING-9949 > Project: Sling > Issue Type: Improvement > Components: Scripting >Affects Versions: Servlets Resolver 2.7.10 > Reporter: Karl Pauls >Assignee: Karl Pauls >Priority: Major > Fix For: Servlets Resolver 2.7.12 > > Time Spent: 50m > Remaining Estimate: 0h > > When resolving bundled scripts the resolver is currently parsing the metadata > several times. That can be avoided using caching the parsed result. > Furthermore, the bundled script servlet is currently calculating the > providers on each request. That can be avoided by doing the calculation one > time when it is created. Additionally, it should unroll servlet exceptions > instead of wrapping them again in a servlet exception. > Finally, the MergingResourceProvider does right now construct its resource > tree completely from scratch every time a servlet is added - that can be > avoided by just adding the servlet to the existing tree. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-8942) Support aggregate and abstract privileges
[ https://issues.apache.org/jira/browse/SLING-8942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls updated SLING-8942: -- Fix Version/s: Content-Package to Feature Model Converter 1.0.24 > Support aggregate and abstract privileges > - > > Key: SLING-8942 > URL: https://issues.apache.org/jira/browse/SLING-8942 > Project: Sling > Issue Type: Improvement > Components: Content-Package to Feature Model Converter >Affects Versions: Content-Package to Feature Model Converter 1.0.2 >Reporter: Konrad Windszus >Priority: Major > Fix For: Content-Package to Feature Model Converter 1.0.24 > > > Currently only simple privileges are supported via > https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/ffc6bb990dfaf82c477a28ad4b87b0c12859b743/src/main/java/org/apache/sling/feature/cpconverter/handlers/PrivilegesHandler.java#L65. > Aggregate and abstract privileges should be supported as well. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (SLING-9926) Wrong PID if configuration is in a nested folder
[ https://issues.apache.org/jira/browse/SLING-9926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls reassigned SLING-9926: - Assignee: Karl Pauls > Wrong PID if configuration is in a nested folder > > > Key: SLING-9926 > URL: https://issues.apache.org/jira/browse/SLING-9926 > Project: Sling > Issue Type: Bug > Components: Content-Package to Feature Model Converter >Affects Versions: Content-Package to Feature Model Converter 1.0.18 >Reporter: Carsten Ziegeler >Assignee: Karl Pauls >Priority: Major > Fix For: Content-Package to Feature Model Converter 1.0.24 > > > If a configuration is contained in a subfolder like > /apps/config/foo/myconfig.xml the resulting PID is currently foo/myconfig > instead of just myconfig > This is probably due to how the PID is derived from the patch using the regex -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SLING-9949) Speed bundled scripts resolution
Karl Pauls created SLING-9949: - Summary: Speed bundled scripts resolution Key: SLING-9949 URL: https://issues.apache.org/jira/browse/SLING-9949 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Servlets Resolver 2.7.10 Reporter: Karl Pauls Assignee: Karl Pauls Fix For: Servlets Resolver 2.7.12 When resolving bundled scripts the resolver is currently parsing the metadata several times. That can be avoided using caching the parsed result. Furthermore, the bundled script servlet is currently calculating the providers on each request. That can be avoided by doing the calculation one time when it is created. Additionally, it should unroll servlet exceptions instead of wrapping them again in a servlet exception. Finally, the MergingResourceProvider does right now construct its resource tree completely from scratch every time a servlet is added - that can be avoided by just adding the servlet to the existing tree. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-9949) Speed-up bundled scripts resolution
[ https://issues.apache.org/jira/browse/SLING-9949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls updated SLING-9949: -- Summary: Speed-up bundled scripts resolution (was: Speed bundled scripts resolution) > Speed-up bundled scripts resolution > --- > > Key: SLING-9949 > URL: https://issues.apache.org/jira/browse/SLING-9949 > Project: Sling > Issue Type: Improvement > Components: Scripting >Affects Versions: Servlets Resolver 2.7.10 > Reporter: Karl Pauls >Assignee: Karl Pauls >Priority: Major > Fix For: Servlets Resolver 2.7.12 > > > When resolving bundled scripts the resolver is currently parsing the metadata > several times. That can be avoided using caching the parsed result. > Furthermore, the bundled script servlet is currently calculating the > providers on each request. That can be avoided by doing the calculation one > time when it is created. Additionally, it should unroll servlet exceptions > instead of wrapping them again in a servlet exception. > Finally, the MergingResourceProvider does right now construct its resource > tree completely from scratch every time a servlet is added - that can be > avoided by just adding the servlet to the existing tree. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [VOTE] Release Apache Sling Feature Model 1.2.16, Feature Model Analyser 1.3.14, Feature Model Launcher 1.1.14, Feature Model API Regions Extension 1.1.14, Content-Package to Feature Model Convert
+1 regards, Karl On Fri, Nov 27, 2020 at 4:34 PM wrote: > > Hi all, > > I would like to call the release on the following Apache Sling Feature > Model related components: > > Feature Model 1.2.16 > https://issues.apache.org/jira/projects/SLING/versions/12349385 > > Feature Model Analyser 1.3.14 > https://issues.apache.org/jira/projects/SLING/versions/12349386 > > Feature Model Launcher 1.1.14 > https://issues.apache.org/jira/projects/SLING/versions/12349396 > > Feature Model API Regions Extension 1.1.14 > https://issues.apache.org/jira/projects/SLING/versions/12349384 > > Content-Package to Feature Model Converter 1.0.22 > https://issues.apache.org/jira/projects/SLING/versions/12349402 > > slingfeature-maven-plugin 1.4.18 > https://issues.apache.org/jira/projects/SLING/versions/12349399 > > Feature Model Converter Plugin 1.0.10 > https://issues.apache.org/jira/projects/SLING/versions/12349389 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-2382 > > 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 2382 /tmp/sling-staging > > Please vote to approve this release: > >[ ] +1 Approve the release >[ ] -1 Don't release, because ... > > This majority vote is open for at least 72 hours. > > Best regards, > > David -- Karl Pauls karlpa...@gmail.com
[jira] [Closed] (SLING-9916) Content package converter produces broken configs for typed configuration entries.
[ https://issues.apache.org/jira/browse/SLING-9916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls closed SLING-9916. - > Content package converter produces broken configs for typed configuration > entries. > -- > > Key: SLING-9916 > URL: https://issues.apache.org/jira/browse/SLING-9916 > Project: Sling > Issue Type: Bug > Components: Feature Model >Affects Versions: Content-Package to Feature Model Converter 1.0.18 >Reporter: Karl Pauls >Assignee: Carsten Ziegeler >Priority: Major > Fix For: Content-Package to Feature Model Converter 1.0.20 > > > The converter converts configurations from jcr trying to respect their types > but in doing so it (unnecessarily) adds the type information to the keys. > That wouldn't be a problem, however, it doesn't do it correctly for multiple > of type String. In that case, it ends up adding just "[]" to the key - which > changes the keyname. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [RESULT] [VOTE] Release Apache Sling Content-Package to Feature Model Converter 1.0.20
Time to call the vote on the Apache Sling Content-Package to Feature Model Converter 1.0.20 release. * +1 votes from Carsten Ziegeler, David Bosschaert, Daniel Klco, and Karl Pauls. * No other votes. The vote is successful. I will make the artifacts available as soon as possible.
Re: [VOTE] Release Apache Sling Content-Package to Feature Model Converter 1.0.20
+1 regards, Karl On Tue, Nov 17, 2020 at 5:01 PM Daniel Klco wrote: > > +1 > > On Tue, Nov 17, 2020 at 10:51 AM wrote: > > > > +1 > > > > David > > > > On Tue, 17 Nov 2020 at 15:44, Carsten Ziegeler wrote: > > > > > +1 > > > > > > Carsten > > > > > > Am 17.11.2020 um 16:41 schrieb Karl Pauls: > > > > Hi all, > > > > > > > > I would like to call the release on the Content-Package to Feature Model > > > > Converter 1.0.20 > > > > https://issues.apache.org/jira/projects/SLING/versions/12349401 > > > > > > > > Staging repository: > > > > https://repository.apache.org/content/repositories/orgapachesling-2380 > > > > > > > > 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 2380 /tmp/sling-staging > > > > > > > > Please vote to approve this release: > > > > > > > > [ ] +1 Approve the release > > > > [ ] -1 Don't release, because ... > > > > > > > > This majority vote is open for at least 72 hours. > > > > > > > > > > -- > > > -- > > > Carsten Ziegeler > > > Adobe Research Switzerland > > > cziege...@apache.org > > > -- Karl Pauls karlpa...@gmail.com
[jira] [Resolved] (SLING-9925) ArrayIndexOutOfBoundsException in AbstractSlingFilterChain
[
https://issues.apache.org/jira/browse/SLING-9925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls resolved SLING-9925.
---
Resolution: Invalid
> ArrayIndexOutOfBoundsException in AbstractSlingFilterChain
> --
>
> Key: SLING-9925
> URL: https://issues.apache.org/jira/browse/SLING-9925
> Project: Sling
> Issue Type: Bug
> Components: Engine
>Affects Versions: Engine 2.7.2
> Reporter: Karl Pauls
>Priority: Major
> Fix For: Engine 2.7.4
>
>
> Apparently, it is possible for an AIOOB Exception to happen in the
> AbstractSlingFilterChain. Unclear to me why but it looks like this:
> {code:java}
> rg.apache.sling.engine.impl.SlingRequestProcessorImpl service: Uncaught
> Throwable
> java.lang.ArrayIndexOutOfBoundsException: Index 29 out of bounds for length 29
> at
> org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:86)
> [org.apache.sling.engine:2.7.2]
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-9927) Allow java.* imports to be defined, in line with OSGi R7
[
https://issues.apache.org/jira/browse/SLING-9927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17237442#comment-17237442
]
Karl Pauls commented on SLING-9927:
---
[~bosschaert], the problem is in the used Felix util ResourceBuilder:
[https://github.com/apache/felix-dev/blob/master/utils/src/main/java/org/apache/felix/utils/resource/ResourceBuilder.java#L316]
It needs to be dragged into the post R6 world :)
> Allow java.* imports to be defined, in line with OSGi R7
>
>
> Key: SLING-9927
> URL: https://issues.apache.org/jira/browse/SLING-9927
> Project: Sling
> Issue Type: Bug
> Components: Feature Model Analyser
>Affects Versions: Feature Model Analyser 1.3.12
>Reporter: Radu Cotescu
>Assignee: David Bosschaert
>Priority: Major
>
> The default Sling analysers seem to not allow {{java.*}} imports:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.sling:slingfeature-maven-plugin:1.4.16:analyse-features (analyze)
> on project : Exception during analysing feature :
> org.osgi.framework.BundleException: Unable to build resource for null:
> Importing java.* packages not allowed: java.awt -> [Help 1] {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SLING-9925) ArrayIndexOutOfBoundsException in AbstractSlingFilterChain
Karl Pauls created SLING-9925:
-
Summary: ArrayIndexOutOfBoundsException in AbstractSlingFilterChain
Key: SLING-9925
URL: https://issues.apache.org/jira/browse/SLING-9925
Project: Sling
Issue Type: Bug
Components: Engine
Affects Versions: Engine 2.7.2
Reporter: Karl Pauls
Fix For: Engine 2.7.3
Apparently, it is possible for an AIOOB Exception to happen in the
AbstractSlingFilterChain. Unclear to me why but it looks like this:
{code:java}
rg.apache.sling.engine.impl.SlingRequestProcessorImpl service: Uncaught
Throwable
java.lang.ArrayIndexOutOfBoundsException: Index 29 out of bounds for length 29
at
org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:86)
[org.apache.sling.engine:2.7.2]
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[VOTE] Release Apache Sling Content-Package to Feature Model Converter 1.0.20
Hi all, I would like to call the release on the Content-Package to Feature Model Converter 1.0.20 https://issues.apache.org/jira/projects/SLING/versions/12349401 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2380 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 2380 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours.
[jira] [Updated] (SLING-9692) Add support for principal-based access control entries
[ https://issues.apache.org/jira/browse/SLING-9692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls updated SLING-9692: -- Fix Version/s: (was: Content-Package to Feature Model Converter 1.1.2) Content-Package to Feature Model Converter 1.0.22 > Add support for principal-based access control entries > -- > > Key: SLING-9692 > URL: https://issues.apache.org/jira/browse/SLING-9692 > Project: Sling > Issue Type: Improvement > Components: Content-Package to Feature Model Converter >Reporter: Robert Munteanu >Priority: Major > Fix For: Content-Package to Feature Model Converter 1.0.22 > > > When passed a content package that contains principal-based access control > entries, the converter ignores them. It should instead generate the proper > repoinit statements. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SLING-9916) Content package converter produces broken configs for typed configuration entries.
Karl Pauls created SLING-9916: - Summary: Content package converter produces broken configs for typed configuration entries. Key: SLING-9916 URL: https://issues.apache.org/jira/browse/SLING-9916 Project: Sling Issue Type: Bug Components: Feature Model Affects Versions: Content-Package to Feature Model Converter 1.1.0 Reporter: Karl Pauls Assignee: Carsten Ziegeler Fix For: Content-Package to Feature Model Converter 1.0.18 The converter converts configurations from jcr trying to respect their types but in doing so it (unnecessarily) adds the type information to the keys. That wouldn't be a problem, however, it doesn't do it correctly for multiple of type String. In that case, it ends up adding just "[]" to the key - which changes the keyname. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [VOTE] Release Apache Sling slingfeature-maven-plugin 1.4.16
+1 regards, Karl On Tue, Nov 17, 2020 at 11:43 AM wrote: > > +1 > > David > > On Mon, 16 Nov 2020 at 20:23, Carsten Ziegeler wrote: > > > +1 > > > > Carsten > > > > Am 16.11.2020 um 18:58 schrieb dav...@apache.org: > > > Hi all, > > > > > > I would like to call the release on the slingfeature-maven-plugin 1.4.16 > > > https://issues.apache.org/jira/projects/SLING/versions/12349397 > > > > > > Staging repository: > > > https://repository.apache.org/content/repositories/orgapachesling-2379 > > > > > > 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 2379 /tmp/sling-staging > > > > > > Please vote to approve this release: > > > > > > [ ] +1 Approve the release > > > [ ] -1 Don't release, because ... > > > > > > This majority vote is open for at least 72 hours. > > > > > > Best regards, > > > > > > David > > > > > > > -- > > -- > > Carsten Ziegeler > > Adobe Research Switzerland > > cziege...@apache.org > > -- Karl Pauls karlpa...@gmail.com
Re: [VOTE] Release Apache Sling slingfeature-maven-plugin 1.4.14
+1 regards, Karl On Mon, Nov 16, 2020 at 4:19 PM wrote: > > Hi all, > > I would like to call the release on the slingfeature-maven-plugin 1.4.14 > https://issues.apache.org/jira/projects/SLING/versions/12349388 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-2378 > > 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 2378 /tmp/sling-staging > > Please vote to approve this release: > >[ ] +1 Approve the release >[ ] -1 Don't release, because ... > > This majority vote is open for at least 72 hours. > > Best regards, > > David -- Karl Pauls karlpa...@gmail.com
[jira] [Resolved] (SLING-9912) ApiMojo is not checking out the right tag for source lookup
[ https://issues.apache.org/jira/browse/SLING-9912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls resolved SLING-9912. --- Resolution: Fixed Fixed in https://github.com/apache/sling-slingfeature-maven-plugin/commit/b71b02b91d336106de1b9355e6923c4f5b0c1ff2 > ApiMojo is not checking out the right tag for source lookup > > > Key: SLING-9912 > URL: https://issues.apache.org/jira/browse/SLING-9912 > Project: Sling > Issue Type: Bug > Components: Maven Plugins and Archetypes >Affects Versions: slingfeature-maven-plugin 1.4.12 > Reporter: Karl Pauls >Assignee: Karl Pauls >Priority: Major > Fix For: slingfeature-maven-plugin 1.4.14 > > > The ApiMojo in the Sling Feature Maven Plugin needs to get the source for > artifacts. If it can't get it from maven, it is trying to check it out from > scm. However, if there is a tag given in the scm info it is right now > ignoring that info due to a bug. It should not. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SLING-9912) ApiMojo is not checking out the right tag for source lookup
Karl Pauls created SLING-9912: - Summary: ApiMojo is not checking out the right tag for source lookup Key: SLING-9912 URL: https://issues.apache.org/jira/browse/SLING-9912 Project: Sling Issue Type: Bug Components: Maven Plugins and Archetypes Affects Versions: slingfeature-maven-plugin 1.4.12 Reporter: Karl Pauls Assignee: Karl Pauls Fix For: slingfeature-maven-plugin 1.4.14 The ApiMojo in the Sling Feature Maven Plugin needs to get the source for artifacts. If it can't get it from maven, it is trying to check it out from scm. However, if there is a tag given in the scm info it is right now ignoring that info due to a bug. It should not. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [VOTE] Release Apache Sling Feature Model Launcher 1.1.12
+1 regards, Karl On Mon, Nov 16, 2020 at 1:45 PM wrote: > > +1 > > David > > On Mon, 16 Nov 2020 at 12:44, Carsten Ziegeler wrote: > > > +1 > > > > Carsten > > > > Am 16.11.2020 um 13:38 schrieb dav...@apache.org: > > > Hi all, > > > > > > I would like to call the release on the Feature Model Launcher 1.1.12 > > > https://issues.apache.org/jira/projects/SLING/versions/12349332 > > > > > > Staging repository: > > > https://repository.apache.org/content/repositories/orgapachesling-2377 > > > > > > 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 2377 /tmp/sling-staging > > > > > > Please vote to approve this release: > > > > > > [ ] +1 Approve the release > > > [ ] -1 Don't release, because ... > > > > > > This majority vote is open for at least 72 hours. > > > > > > Best regards, > > > > > > David > > > > > > > -- > > -- > > Carsten Ziegeler > > Adobe Research Switzerland > > cziege...@apache.org > > -- Karl Pauls karlpa...@gmail.com
Re: [VOTE] Release Apache Sling Feature Model 1.2.14, Feature Model Analyser 1.3.12, Feature Model API Regions Extension 1.1.12, Feature Model Content Extension 1.0.8, slingfeature-maven-plugin 1.4.12
+1 regards, Karl On Fri, Nov 13, 2020 at 4:43 PM wrote: > > +1 > > David > > On Fri, 13 Nov 2020 at 15:12, wrote: > > > Hi all, > > > > I would like to call the release on the following Apache Sling Feature > > Model related components: > > > > Feature Model 1.2.14 > > https://issues.apache.org/jira/projects/SLING/versions/12349330 > > > > Feature Model Analyser 1.3.12 > > https://issues.apache.org/jira/projects/SLING/versions/12349331 > > > > Feature Model API Regions Extension 1.1.12 > > https://issues.apache.org/jira/projects/SLING/versions/12349328 > > > > Feature Model Content Extension 1.0.8 > > https://issues.apache.org/jira/projects/SLING/versions/12346856 > > > > slingfeature-maven-plugin 1.4.12 > > https://issues.apache.org/jira/projects/SLING/versions/12349333 > > > > Feature Model Converter Plugin 1.0.8 > > https://issues.apache.org/jira/projects/SLING/versions/12349334 > > > > Staging repository: > > https://repository.apache.org/content/repositories/orgapachesling-2376 > > > > 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 2376 /tmp/sling-staging > > > > Please vote to approve this release: > > > >[ ] +1 Approve the release > >[ ] -1 Don't release, because ... > > > > This majority vote is open for at least 72 hours. > > > > Best regards, > > > > David > > -- Karl Pauls karlpa...@gmail.com
[jira] [Resolved] (SLING-9908) Remove ContentOrderMergeProcessor
[ https://issues.apache.org/jira/browse/SLING-9908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls resolved SLING-9908. --- Resolution: Fixed Done in 49fa2e7..791d50c > Remove ContentOrderMergeProcessor > - > > Key: SLING-9908 > URL: https://issues.apache.org/jira/browse/SLING-9908 > Project: Sling > Issue Type: Improvement > Components: Feature Model >Affects Versions: Feature Model Content Extension 1.0.6 > Reporter: Karl Pauls >Assignee: Karl Pauls >Priority: Major > Fix For: Feature Model Content Extension 1.0.8 > > > We should remove the ContentOrderMergeProcessor as we can handle that with > the slingfeature-maven-plugin and it is problematic in its current form as it > doesn't take the merge policies into account. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SLING-9908) Remove ContentOrderMergeProcessor
Karl Pauls created SLING-9908: - Summary: Remove ContentOrderMergeProcessor Key: SLING-9908 URL: https://issues.apache.org/jira/browse/SLING-9908 Project: Sling Issue Type: Improvement Components: Feature Model Affects Versions: Feature Model Content Extension 1.0.6 Reporter: Karl Pauls Assignee: Karl Pauls Fix For: Feature Model Content Extension 1.0.8 We should remove the ContentOrderMergeProcessor as we can handle that with the slingfeature-maven-plugin and it is problematic in its current form as it doesn't take the merge policies into account. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-9902) Merging with policy HIGHEST should take alias version into account.
[ https://issues.apache.org/jira/browse/SLING-9902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls resolved SLING-9902. --- Resolution: Fixed Done in f5cfdfb..b8833b5 > Merging with policy HIGHEST should take alias version into account. > --- > > Key: SLING-9902 > URL: https://issues.apache.org/jira/browse/SLING-9902 > Project: Sling > Issue Type: Bug > Components: Feature Model >Affects Versions: Feature Model 1.2.12 > Reporter: Karl Pauls >Assignee: Karl Pauls >Priority: Major > Fix For: Feature Model 1.2.14 > > > When an artifact has an alias and that alias is clashing with a different > artifact the merge policy should take the version of the alias for the > selection of the highest version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SLING-9902) Merging with policy HIGHEST should take alias version into account.
Karl Pauls created SLING-9902: - Summary: Merging with policy HIGHEST should take alias version into account. Key: SLING-9902 URL: https://issues.apache.org/jira/browse/SLING-9902 Project: Sling Issue Type: Bug Components: Feature Model Affects Versions: Feature Model 1.2.12 Reporter: Karl Pauls Assignee: Karl Pauls Fix For: Feature Model 1.2.14 When an artifact has an alias and that alias is clashing with a different artifact the merge policy should take the version of the alias for the selection of the highest version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [VOTE] Release Apache Sling Content-Package to Feature Model Converter 1.0.18
+1 regards, Karl On Wed, Nov 11, 2020 at 11:36 AM wrote: > > +1 > > David > > On Wed, 11 Nov 2020 at 09:38, wrote: > > > Hi all, > > > > I would like to call the release on the Content-Package to Feature Model > > Converter 1.0.18 > > https://issues.apache.org/jira/projects/SLING/versions/12349329 > > > > Staging repository: > > https://repository.apache.org/content/repositories/orgapachesling-2375 > > > > 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 2375 /tmp/sling-staging > > > > Please vote to approve this release: > > > >[ ] +1 Approve the release > > [ ] -1 Don't release, because ... > > > > This majority vote is open for at least 72 hours. > > > > Best regards, > > > > David > > -- Karl Pauls karlpa...@gmail.com
[jira] [Resolved] (SLING-9884) Feature Analyser Requirement/Capabilities check should log warnings on artifact level
[ https://issues.apache.org/jira/browse/SLING-9884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls resolved SLING-9884. --- Resolution: Fixed Done in 49269b7..659a698 > Feature Analyser Requirement/Capabilities check should log warnings on > artifact level > - > > Key: SLING-9884 > URL: https://issues.apache.org/jira/browse/SLING-9884 > Project: Sling > Issue Type: Improvement > Components: Feature Model Analyser >Affects Versions: Feature Model Analyser 1.3.10 >Reporter: Karl Pauls >Assignee: Karl Pauls >Priority: Major > Fix For: Feature Model Analyser 1.3.12 > > > The introduction of artifact level errors/warnings missed to convert the > requirements/capabilities check to use the artifact level for warnings. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SLING-9884) Feature Analyser Requirement/Capabilities check should log warnings on artifact level
Karl Pauls created SLING-9884: - Summary: Feature Analyser Requirement/Capabilities check should log warnings on artifact level Key: SLING-9884 URL: https://issues.apache.org/jira/browse/SLING-9884 Project: Sling Issue Type: Improvement Components: Feature Model Analyser Affects Versions: Feature Model Analyser 1.3.10 Reporter: Karl Pauls Assignee: Karl Pauls Fix For: Feature Model Analyser 1.3.12 The introduction of artifact level errors/warnings missed to convert the requirements/capabilities check to use the artifact level for warnings. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [VOTE] Release Apache Sling Feature Model 1.2.12, Feature Model Analyser 1.3.10, Feature Model Launcher 1.1.10, Content-Package to Feature Model Converter 1.0.16, slingfeature-maven-plugin 1.4.6,
+1 regards, Karl On Thursday, October 29, 2020, wrote: > Hi all, > > I would like to call the release on the following Apache Sling Feature > Model related components: > > Feature Model 1.2.12 > https://issues.apache.org/jira/projects/SLING/versions/12348830 > > Feature Model Analyser 1.3.10 > https://issues.apache.org/jira/projects/SLING/versions/12348762 > > Feature Model Launcher 1.1.10 > https://issues.apache.org/jira/projects/SLING/versions/12349327 > > Content-Package to Feature Model Converter 1.0.16 > https://issues.apache.org/jira/projects/SLING/versions/12348790 > > slingfeature-maven-plugin 1.4.6 > https://issues.apache.org/jira/projects/SLING/versions/12349275 > > Feature Model Converter Plugin 1.0.6 > https://issues.apache.org/jira/projects/SLING/versions/12346782 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-2365 > > 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 2365 /tmp/sling-staging > > Please vote to approve this release: > >[ ] +1 Approve the release >[ ] -1 Don't release, because ... > > This majority vote is open for at least 72 hours. > > Best regards, > > David > -- Karl Pauls karlpa...@gmail.com
[jira] [Commented] (SLING-9860) Merging artifacts with the ALL strategy should keep the origins for clashing bundles and their origins only
[ https://issues.apache.org/jira/browse/SLING-9860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17222841#comment-17222841 ] Karl Pauls commented on SLING-9860: --- An example where the above becomes problematic is when you have a bundle that has problematic meta-data which makes the substitution go wrong e.g.: the org.yaml:snakeyaml bundles have meta-data that is somewhat problematic. They import what they export for some packages but not for all - unfortunately, some of the packages they import have dependencies on the packages they don't import (and they don't capture that with uses-constraints). Consequently, one can get LinkageErrors if e.g. org.yaml:snakeyaml:1.27 and org.yaml:snakeyaml:1.24 are used side-by-side. When using the current ALL merge, the result would be that org.yaml:snakeyaml:1.24 is in both features - which would not allow e.g. the api-regions to force it to wire to itself for the broken imports. If we do the change proposed here, it would only be in the original feature - allowing the api-regions to force the right resolution. > Merging artifacts with the ALL strategy should keep the origins for clashing > bundles and their origins only > > > Key: SLING-9860 > URL: https://issues.apache.org/jira/browse/SLING-9860 > Project: Sling > Issue Type: Improvement > Components: Feature Model >Affects Versions: Feature Model 1.2.10 >Reporter: A. J. David Bosschaert >Assignee: A. J. David Bosschaert >Priority: Major > Fix For: Feature Model 1.2.12 > > > When merging 2 features that both contain the same artifact, but in different > versions, both artifacts are preserved, however, the feature-origins of one > of the artifact contains both features instead of just its own feature. > For example Feature A contains: > * bundle org.foo:bar:1.2 > And Feature B contains > * bundle org.foo:bar:1.3 > Then once merged with the ALL strategy the resulting feature contains the > artifact with (origins A,B). > While this allows for package substitution to work between the bundles it can > be problematic in cases where that is not desired for isolation purposes. As > the interpretation of the origins is up to extensions, it seems better to not > make the union decision in this place but leave it up to merge extensions and > handlers later. > In other words, we should change this so that the origins for version 1.2 > should be just A, not both A and B. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-9860) Merging artifacts with the ALL strategy should keep the origins for clashing bundles and their origins only
[ https://issues.apache.org/jira/browse/SLING-9860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls updated SLING-9860: -- Description: When merging 2 features that both contain the same artifact, but in different versions, both artifacts are preserved, however, the feature-origins of one of the artifact contains both features instead of just its own feature. For example Feature A contains: * bundle org.foo:bar:1.2 And Feature B contains * bundle org.foo:bar:1.3 Then once merged with the ALL strategy the resulting feature contains the artifact with (origins A,B). While this allows for package substitution to work between the bundles it can be problematic in cases where that is not desired for isolation purposes. As the interpretation of the origins is up to extensions, it seems better to not make the union decision in this place but leave it up to merge extensions and handlers later. In other words, we should change this so that the origins for version 1.2 should be just A, not both A and B. was: When merging 2 features that both contain the same artifact, but in different versions, both artifacts are preserved, however, the feature-origins of one of the artifact contains both features instead of just its own feature. For example Feature A contains: * bundle org.foo:bar:1.2 And Feature B contains * bundle org.foo:bar:1.3 Then once merged with the ALL strategy the resulting feature contains: * bundle org.foo:bar:1.2 (origins A,B) * bundle org.foo:bar:1.3 (origins B) this is incorrect, the origins for version 1.2 should be just A, not both A and B. Issue Type: Improvement (was: Bug) Summary: Merging artifacts with the ALL strategy should keep the origins for clashing bundles and their origins only (was: When merging artifacts with the ALL strategy, incorrect feature-origin metadata is recorded) > Merging artifacts with the ALL strategy should keep the origins for clashing > bundles and their origins only > > > Key: SLING-9860 > URL: https://issues.apache.org/jira/browse/SLING-9860 > Project: Sling > Issue Type: Improvement > Components: Feature Model >Affects Versions: Feature Model 1.2.10 >Reporter: A. J. David Bosschaert >Assignee: A. J. David Bosschaert >Priority: Major > Fix For: Feature Model 1.2.12 > > > When merging 2 features that both contain the same artifact, but in different > versions, both artifacts are preserved, however, the feature-origins of one > of the artifact contains both features instead of just its own feature. > For example Feature A contains: > * bundle org.foo:bar:1.2 > And Feature B contains > * bundle org.foo:bar:1.3 > Then once merged with the ALL strategy the resulting feature contains the > artifact with (origins A,B). > While this allows for package substitution to work between the bundles it can > be problematic in cases where that is not desired for isolation purposes. As > the interpretation of the origins is up to extensions, it seems better to not > make the union decision in this place but leave it up to merge extensions and > handlers later. > In other words, we should change this so that the origins for version 1.2 > should be just A, not both A and B. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-9805) Add a method to create the metadata cache extension
[ https://issues.apache.org/jira/browse/SLING-9805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls resolved SLING-9805. --- Resolution: Fixed Done in https://github.com/apache/sling-org-apache-sling-feature-analyser/commit/c07ea118a54999c4a38796ebf6c31c964dee13dc We now have an org.apache.sling.feature.analyser.extensions.AnalyserMetaDataExtension that does the parsing and can optionally be used to create the extension as well. > Add a method to create the metadata cache extension > --- > > Key: SLING-9805 > URL: https://issues.apache.org/jira/browse/SLING-9805 > Project: Sling > Issue Type: Improvement > Components: Feature Model Analyser >Reporter: Carsten Ziegeler > Assignee: Karl Pauls >Priority: Major > Fix For: Feature Model Analyser 1.3.10 > > > With SLING-8481 and SLING-9804 implemented, an utility method could be added > to the scanner api package, creating an extension with the cached artifact > metadata (taking a feature descriptor and framework descriptor as input) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-9822) Make artifact retrieval lazy for cached artifacts
[ https://issues.apache.org/jira/browse/SLING-9822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls resolved SLING-9822. --- Resolution: Fixed Done in https://github.com/apache/sling-org-apache-sling-feature-analyser/commit/c07ea118a54999c4a38796ebf6c31c964dee13dc Bundles are now lazy until they needed (and the existing checks take that into account). Content packages will not scan but report errors that can be ignored. > Make artifact retrieval lazy for cached artifacts > - > > Key: SLING-9822 > URL: https://issues.apache.org/jira/browse/SLING-9822 > Project: Sling > Issue Type: Improvement > Components: Feature Model Analyser >Affects Versions: Feature Model Analyser 1.3.8 > Reporter: Karl Pauls >Assignee: Karl Pauls >Priority: Major > Fix For: Feature Model Analyser 1.3.10 > > > With SLING-9805, we made it possible to have artifacts from the cache > extension that don't need to be present via maven - however, we are currently > requesting them AOT. It would be better to make that JIT and have the > analyzers be able to deal with artifacts not present in a better way. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-9823) Make analyzers report more context about issues and make it possible to filter reports.
[ https://issues.apache.org/jira/browse/SLING-9823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls resolved SLING-9823. --- Resolution: Fixed Done in https://github.com/apache/sling-org-apache-sling-feature-analyser/commit/c07ea118a54999c4a38796ebf6c31c964dee13dc I added report/get methods for warnings/errors for global/artifact/extension and added a report object to the analyses-metadata extension that can be used to set reporting to true/false for errors/warnings based on artifactid/featureid. > Make analyzers report more context about issues and make it possible to > filter reports. > --- > > Key: SLING-9823 > URL: https://issues.apache.org/jira/browse/SLING-9823 > Project: Sling > Issue Type: Improvement > Components: Feature Model Analyser >Affects Versions: Feature Model Analyser 1.3.8 >Reporter: Karl Pauls >Assignee: Karl Pauls >Priority: Major > Fix For: Feature Model Analyser 1.3.10 > > > Currently, an analyser task just reports a string (either as error or > warning) - we should add new methods to AnalyserTaskContext for reporting > error/warning. > These methods should take an ArtifactId and a string or an extension name and > a string (something like reportArtifactError(ArtifactId, > String)...reportExtensionError(String, String) ) > This way the analysers can provide more context about a warning/error and we > can display them later per artifact instead of a long list. With that we have > three types of errors: global (just the string), per artifact id, per > extension name - the analyser tasks could be updated to use the new methods > where appropriate. Similar, we add new methods to AnalyserResult getting > those three types of errors/warnings - and deprecate the two existing ones. > They would be changed to return all errors/warnings - so everything would be > compatible. > The final piece is ignoring errors/warnings for certain artifacts. If we do > the changes as mentioned above - the scanner/analyser does not need to know > anything about whether something is ignored. We can handle this in the maven > plugin. > We have two options here: either we make this a configuration of the plugin - > or we allow that metadata property is added to an artifact in the feature > model telling the plugin to not report errors/warnings for this artifact. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-9848) The ArtifactManager should handle SNAPSHOT dependencies exactly like Maven
[
https://issues.apache.org/jira/browse/SLING-9848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219724#comment-17219724
]
Karl Pauls commented on SLING-9848:
---
The problem is that we use "SNAPSHOT" as the key to start looking for a
snapshot. Apparently, maven does look at the meta-data first to see if the
given version is a snapshot by chance. If it is, it changes the directory it is
in from the version to "SNAPSHOT". Strange, yes, but that is apparently what
maven is doing...
> The ArtifactManager should handle SNAPSHOT dependencies exactly like Maven
> --
>
> Key: SLING-9848
> URL: https://issues.apache.org/jira/browse/SLING-9848
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model
>Affects Versions: Feature Model 1.2.10
>Reporter: Radu Cotescu
>Priority: Major
>
> When a feature provides a SNAPSHOT dependency by using the artifact's
> specific version generated by Nexus (e.g. 1.0.0-SNAPSHOT ->
> 1.0.0-20201021.121222-1), then the {{ArtifactManager}} fails to correctly
> find the dependency.
> Assuming a definition like:
> {code}
> {
> "id":"org.myorg:mybundle:1.0.0-20201021.121222-1",
> "start-order":"20"
> }
> {code}
> Maven would download / solve
> {{org/myorg/mybundle/1.0.0-SNAPSHOT/mybundle-1.0.0-20201021.121222-1.jar}},
> whereas the {{ArtifactManager}} would try to download / solve
> {{org/myorg/mybundle/1.0.0-20201021.121222-1/mybundle-1.0.0-20201021.121222-1.jar}}.
> IMO, when working with Maven Repositories / Artifacts, the
> {{ArtifactManager}} should use Maven components for correctly resolving the
> artifacts the same way Maven would.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [VOTE] Release Apache Sling Models Implementation 1.4.16
+1 regards, Karl On Thursday, October 22, 2020, Robert Munteanu wrote: > On Tue, 2020-10-20 at 15:45 +, Radu Cotescu wrote: > > Please vote to approve this release: > > +1 > Robert > -- Karl Pauls karlpa...@gmail.com
[jira] [Closed] (SLING-9802) Launcher Classloader is not synchronizing loadClass correctly
[ https://issues.apache.org/jira/browse/SLING-9802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls closed SLING-9802. - > Launcher Classloader is not synchronizing loadClass correctly > - > > Key: SLING-9802 > URL: https://issues.apache.org/jira/browse/SLING-9802 > Project: Sling > Issue Type: Bug > Components: Feature Model >Affects Versions: Feature Model Launcher 1.1.6 > Reporter: Karl Pauls >Assignee: Karl Pauls >Priority: Major > Fix For: Feature Model Launcher 1.1.8 > > > The default LauncherClassloader is not synchronizing its loadClass method > correctly. As it just delegates to the findClass of the URLClassloader it > extends, it needs to at a minimum lock on the classname it is trying to load > - otherwise, it is possible that it will catch a LinkageError if the same > class load is happening concurrently. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SLING-9798) Don't expose OSGi / Apache Felix JMX MBeans from the feature launcher
[ https://issues.apache.org/jira/browse/SLING-9798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls closed SLING-9798. - > Don't expose OSGi / Apache Felix JMX MBeans from the feature launcher > - > > Key: SLING-9798 > URL: https://issues.apache.org/jira/browse/SLING-9798 > Project: Sling > Issue Type: Bug > Components: Feature Model >Affects Versions: Feature Model Launcher 1.1.6 > Reporter: Karl Pauls >Assignee: Karl Pauls >Priority: Major > Fix For: Feature Model Launcher 1.1.8 > > > In SLING-9621 the JMX Means have been added to the feature launcher. I think > that is a mistake. The goal of the feature launcher was to keep the > dependencies minimal and do as much as possible from the outside. > We already have the mechanism to expose the MBeans via the: > org-apache-sling-launchpad-startupmanager bundle [0]. If somebody needs the > MBeans as part of their features they can just add that bundle to their > features. > At a minimum, we would need to make the exposing configurable (in such a way > that if the config is off, it will not even need the javax.management classes > on the class path) but preferably I would really like to revert the commit in > question [1]. > [~klcodanr], would it work for if I revert the commit in favor of [0] or is > there another reasons to keep it (in which case I would make it configurable)? > [0] > https://github.com/apache/sling-org-apache-sling-launchpad-startupmanager/blob/master/src/main/java/org/apache/sling/launchpad/startupmanager/Activator.java > [1] > https://github.com/apache/sling-org-apache-sling-feature-launcher/commit/89d2a4806b09051e95b16074d853f1d83b643172 -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [RESULT][VOTE] Release Apache Sling Feature Model Launcher 1.1.8
Time to call the vote on the ApacheSling Feature Model Launcher 1.1.8 release. * +1 votes from Carsten Ziegeler, David Bosschaert, Robert Munteanu, and Karl Pauls. * No other votes. The vote is successful. I will make the artifacts available as soon as possible.
Re: [VOTE] Release Apache Sling Feature Model Launcher 1.1.8
Yes, I forgot about it - sorry about that. Here is my +1. regards, Karl On Wed, Oct 21, 2020 at 10:30 PM Daniel Klco wrote: > > Was this release completed? Looks like it was never finished in Nexus and > I'm not seeing it on Maven Central. > > On Mon, Oct 12, 2020 at 6:01 AM Robert Munteanu wrote: > > > On Thu, 2020-10-08 at 11:48 +0200, Karl Pauls wrote: > > > Please vote to approve this release: > > > > +1 > > Robert > > -- Karl Pauls karlpa...@gmail.com
[jira] [Commented] (SLING-9824) sun.misc.Unsafe accessible in Sling Starter 12
[
https://issues.apache.org/jira/browse/SLING-9824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214570#comment-17214570
]
Karl Pauls commented on SLING-9824:
---
[~kwin], not for the boot delegation. To be precise: Felix doesn't bootdelegate
by default - hence, if we don't add boot delegation to sun.* and com.sun.* it
will not be there. That might be fine, as users like [~hanspeterstoerr] in this
case (but others in general) could then add the required delegation via -D
properties. However, for sun.* and com.sun.* it might be a very common case...
> sun.misc.Unsafe accessible in Sling Starter 12
> --
>
> Key: SLING-9824
> URL: https://issues.apache.org/jira/browse/SLING-9824
> Project: Sling
> Issue Type: Bug
> Components: Starter
>Affects Versions: Starter 12
> Environment: Sling-Starter 12-SNAPSHOT (commit addb8f7b) with JDK 11
> and 13 on MacOS, JDK 11 on an x86_64 Linux
>Reporter: Hans-Peter Stoerr
>Priority: Minor
>
> We are having some trouble running our application on [the current Sling
> Starter 12
> snapshot|https://github.com/apache/sling-org-apache-sling-starter/tree/addb8f7ba16dfb2ab6cda1a70f98a461a7cacb7a]
> since we are using ehache 3, which uses sun.misc.Unsafe internally. This
> works with Sling Starter 11, but since Sling Starter changed to the feature
> launcher, this class seems to have disappeared from the classpath: the class
> loading of ehcache classes fails with a java.lang.NoClassDefFoundError:
> sun/misc/Unsafe
> I tried to add command line arguments
> --add-modules=jdk.unsupported
> and
> --add-opens=jdk.unsupported/sun.misc=ALL-UNNAMED
> to the launcher command line, as I've seen that suggested on the net for
> similar problems, but it didn't help.
> In fact, this doesn't seem to be the problem: even without those flags the
> jdk.unsupported module does export sun.misc:
> module
> { name: jdk.unsupported@11.0.6, [mandated java.base], exports:
> [com.sun.nio.file, sun.misc, sun.reflect], opens: [sun.misc, sun.reflect] }
> So it seems the module is loaded, but not used to load the class.
> The easiest way to reproduce the problem is to add this to some JSP:
> <%
> Class clazz = sun.misc.Unsafe.class;
> %>
> In case that matters: I tried JDK 11 and 13 on MacOS, as well as JDK 11 on
> an x86_64 Linux.
> This works on Sling Starter 11, but not the current 12 snapshot.
> The workaround to add
> {{-D org.osgi.framework.system.packages.extra=sun.misc}}
> to the command line, which was thankfully suggested [in the mailing
> list|https://www.mail-archive.com/users@sling.apache.org/msg05423.html], does
> work. But I feel it is not a particularily clean solution. It also does
> something else than what happens on Sling Starter 11 : now the sun.misc
> package is listed in the exports list of the felix framework bundle
> [http://localhost:9090/system/console/bundles/0] . Not sure whether this is
> good or bad.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-9824) sun.misc.Unsafe accessible in Sling Starter 12
[
https://issues.apache.org/jira/browse/SLING-9824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214561#comment-17214561
]
Karl Pauls commented on SLING-9824:
---
[~rombert], yes indeed - the launchpad.base generated a sling.properties that
has bootdelegation for sun.* and com.sun.* in it by default. With the feature
launcher, we don't get this kind of implicit defaults anymore - hence, they
would need to be added to the framework properties via the feature model. I
think we should add boot delegation at least for sun.* and com.sun.*.
> sun.misc.Unsafe accessible in Sling Starter 12
> --
>
> Key: SLING-9824
> URL: https://issues.apache.org/jira/browse/SLING-9824
> Project: Sling
> Issue Type: Bug
> Components: Starter
>Affects Versions: Starter 12
> Environment: Sling-Starter 12-SNAPSHOT (commit addb8f7b) with JDK 11
> and 13 on MacOS, JDK 11 on an x86_64 Linux
>Reporter: Hans-Peter Stoerr
>Priority: Minor
>
> We are having some trouble running our application on [the current Sling
> Starter 12
> snapshot|https://github.com/apache/sling-org-apache-sling-starter/tree/addb8f7ba16dfb2ab6cda1a70f98a461a7cacb7a]
> since we are using ehache 3, which uses sun.misc.Unsafe internally. This
> works with Sling Starter 11, but since Sling Starter changed to the feature
> launcher, this class seems to have disappeared from the classpath: the class
> loading of ehcache classes fails with a java.lang.NoClassDefFoundError:
> sun/misc/Unsafe
> I tried to add command line arguments
> --add-modules=jdk.unsupported
> and
> --add-opens=jdk.unsupported/sun.misc=ALL-UNNAMED
> to the launcher command line, as I've seen that suggested on the net for
> similar problems, but it didn't help.
> In fact, this doesn't seem to be the problem: even without those flags the
> jdk.unsupported module does export sun.misc:
> module
> { name: jdk.unsupported@11.0.6, [mandated java.base], exports:
> [com.sun.nio.file, sun.misc, sun.reflect], opens: [sun.misc, sun.reflect] }
> So it seems the module is loaded, but not used to load the class.
> The easiest way to reproduce the problem is to add this to some JSP:
> <%
> Class clazz = sun.misc.Unsafe.class;
> %>
> In case that matters: I tried JDK 11 and 13 on MacOS, as well as JDK 11 on
> an x86_64 Linux.
> This works on Sling Starter 11, but not the current 12 snapshot.
> The workaround to add
> {{-D org.osgi.framework.system.packages.extra=sun.misc}}
> to the command line, which was thankfully suggested [in the mailing
> list|https://www.mail-archive.com/users@sling.apache.org/msg05423.html], does
> work. But I feel it is not a particularily clean solution. It also does
> something else than what happens on Sling Starter 11 : now the sun.misc
> package is listed in the exports list of the felix framework bundle
> [http://localhost:9090/system/console/bundles/0] . Not sure whether this is
> good or bad.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-9824) sun.misc.Unsafe accessible in Sling Starter 12
[
https://issues.apache.org/jira/browse/SLING-9824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214557#comment-17214557
]
Karl Pauls commented on SLING-9824:
---
It sounds to me like sun.misc should be boot delegated instead of being added
to the framework exports. Was that maybe the case in the old provisioning
models but isn't the case in current feature models?
> sun.misc.Unsafe accessible in Sling Starter 12
> --
>
> Key: SLING-9824
> URL: https://issues.apache.org/jira/browse/SLING-9824
> Project: Sling
> Issue Type: Bug
> Components: Starter
>Affects Versions: Starter 12
> Environment: Sling-Starter 12-SNAPSHOT (commit addb8f7b) with JDK 11
> and 13 on MacOS, JDK 11 on an x86_64 Linux
>Reporter: Hans-Peter Stoerr
>Priority: Minor
>
> We are having some trouble running our application on [the current Sling
> Starter 12
> snapshot|https://github.com/apache/sling-org-apache-sling-starter/tree/addb8f7ba16dfb2ab6cda1a70f98a461a7cacb7a]
> since we are using ehache 3, which uses sun.misc.Unsafe internally. This
> works with Sling Starter 11, but since Sling Starter changed to the feature
> launcher, this class seems to have disappeared from the classpath: the class
> loading of ehcache classes fails with a java.lang.NoClassDefFoundError:
> sun/misc/Unsafe
> I tried to add command line arguments
> --add-modules=jdk.unsupported
> and
> --add-opens=jdk.unsupported/sun.misc=ALL-UNNAMED
> to the launcher command line, as I've seen that suggested on the net for
> similar problems, but it didn't help.
> In fact, this doesn't seem to be the problem: even without those flags the
> jdk.unsupported module does export sun.misc:
> module
> { name: jdk.unsupported@11.0.6, [mandated java.base], exports:
> [com.sun.nio.file, sun.misc, sun.reflect], opens: [sun.misc, sun.reflect] }
> So it seems the module is loaded, but not used to load the class.
> The easiest way to reproduce the problem is to add this to some JSP:
> <%
> Class clazz = sun.misc.Unsafe.class;
> %>
> In case that matters: I tried JDK 11 and 13 on MacOS, as well as JDK 11 on
> an x86_64 Linux.
> This works on Sling Starter 11, but not the current 12 snapshot.
> The workaround to add
> {{-D org.osgi.framework.system.packages.extra=sun.misc}}
> to the command line, which was thankfully suggested [in the mailing
> list|https://www.mail-archive.com/users@sling.apache.org/msg05423.html], does
> work. But I feel it is not a particularily clean solution. It also does
> something else than what happens on Sling Starter 11 : now the sun.misc
> package is listed in the exports list of the felix framework bundle
> [http://localhost:9090/system/console/bundles/0] . Not sure whether this is
> good or bad.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [VOTE] Release Apache Sling slingfeature-maven-plugin 1.4.4
+1 regards, Karl On Thursday, October 15, 2020, wrote: > +1 > > David > > On Thu, 15 Oct 2020 at 07:01, Carsten Ziegeler > wrote: > > > Hi, > > > > We solved 1 issue in this release: > > https://issues.apache.org/jira/browse/SLING-9828 > > > > Staging repository: > > https://repository.apache.org/content/repositories/orgapachesling-2355/ > > > > 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 2355 /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 > > > -- Karl Pauls karlpa...@gmail.com
[jira] [Created] (SLING-9823) Make analyzers report more context about issues and make it possible to filter reports.
Karl Pauls created SLING-9823: - Summary: Make analyzers report more context about issues and make it possible to filter reports. Key: SLING-9823 URL: https://issues.apache.org/jira/browse/SLING-9823 Project: Sling Issue Type: Improvement Components: Feature Model Analyser Affects Versions: Feature Model Analyser 1.3.8 Reporter: Karl Pauls Assignee: Karl Pauls Fix For: Feature Model Analyser 1.3.10 Currently, an analyser task just reports a string (either as error or warning) - we should add new methods to AnalyserTaskContext for reporting error/warning. These methods should take an ArtifactId and a string or an extension name and a string (something like reportArtifactError(ArtifactId, String)...reportExtensionError(String, String) ) This way the analysers can provide more context about a warning/error and we can display them later per artifact instead of a long list. With that we have three types of errors: global (just the string), per artifact id, per extension name - the analyser tasks could be updated to use the new methods where appropriate. Similar, we add new methods to AnalyserResult getting those three types of errors/warnings - and deprecate the two existing ones. They would be changed to return all errors/warnings - so everything would be compatible. The final piece is ignoring errors/warnings for certain artifacts. If we do the changes as mentioned above - the scanner/analyser does not need to know anything about whether something is ignored. We can handle this in the maven plugin. We have two options here: either we make this a configuration of the plugin - or we allow that metadata property is added to an artifact in the feature model telling the plugin to not report errors/warnings for this artifact. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SLING-9822) Make artifact retrieval lazy for cached artifacts
Karl Pauls created SLING-9822: - Summary: Make artifact retrieval lazy for cached artifacts Key: SLING-9822 URL: https://issues.apache.org/jira/browse/SLING-9822 Project: Sling Issue Type: Improvement Components: Feature Model Analyser Affects Versions: Feature Model Analyser 1.3.8 Reporter: Karl Pauls Assignee: Karl Pauls Fix For: Feature Model Analyser 1.3.10 With SLING-9805, we made it possible to have artifacts from the cache extension that don't need to be present via maven - however, we are currently requesting them AOT. It would be better to make that JIT and have the analyzers be able to deal with artifacts not present in a better way. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SLING-9816) Lookup jsp includes from the class path if not found locally
Karl Pauls created SLING-9816: - Summary: Lookup jsp includes from the class path if not found locally Key: SLING-9816 URL: https://issues.apache.org/jira/browse/SLING-9816 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: JSPC Maven Plugin 2.2.2 Reporter: Karl Pauls Assignee: Radu Cotescu Fix For: JSPC Maven Plugin 2.2.4 When compiling a jsp that has an include it would be good if the jspc could try to find the included jsp from the class path if it doesn't exist locally (similar to what happens with taglibs). This way, it would be possible to include jsps coming from a different project just by adding a dependency. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [VOTE] Release Apache Sling Parent 40, Apache Sling Bundle Parent 40
+1 regards, Karl On Friday, October 9, 2020, Daniel Klco wrote: > +1 > > On Fri, Oct 9, 2020 at 12:58 PM Andreas Schaefer > > wrote: > > > +1 (non-binding) > > > > - Andy > > > > > On Oct 9, 2020, at 7:28 AM, Radu Cotescu wrote: > > > > > > Hi, > > > > > > We solved 4 issues in these releases: > > > https://issues.apache.org/jira/browse/SLING/fixforversion/12348259 < > > https://issues.apache.org/jira/browse/SLING/fixforversion/12348259> > > > https://issues.apache.org/jira/browse/SLING/fixforversion/12348260 < > > https://issues.apache.org/jira/browse/SLING/fixforversion/12348260> > > > > > > Staging repository: > > > https://repository.apache.org/content/repositories/orgapachesling-2353 > < > > https://repository.apache.org/content/repositories/orgapachesling-2353> > > > > > > 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 > > < > > 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 2353 /tmp/sling-staging > > > > > > Please vote to approve this release: > > > > > > [ ] +1 Approve the release > > > [ ] 0 Don't care > > > [ ] -1 Don't release, because ... > > > > > > This majority vote is open for at least 72 hours. > > > > > > Regards, > > > Radu Cotescu > > > > > -- Karl Pauls karlpa...@gmail.com
[jira] [Commented] (SLING-8481) Caching of Feature Model Analyser Metadata
[ https://issues.apache.org/jira/browse/SLING-8481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17210258#comment-17210258 ] Karl Pauls commented on SLING-8481: --- I added an "analyser-metadata" extension. That one can be used to pass the manifest of bundle artifacts for now (and in the future for more metadata for other kind of artifacts). > Caching of Feature Model Analyser Metadata > -- > > Key: SLING-8481 > URL: https://issues.apache.org/jira/browse/SLING-8481 > Project: Sling > Issue Type: Improvement > Components: Feature Model >Reporter: Dominik Süß >Assignee: Karl Pauls >Priority: Major > > The feature model analyser is currently acting on the information of the > feature model files as well as the metadata of artifacts. While feature > models have a small footprint the extraction of the metadata from binaries is > costly. > Caching of this metadata should be improved in 2 ways: > a) metadata should only be extracted once and be cached in process to avoid > repetitive reading of binaries to access the same metadta > b) it should be possible to store a "sidecar" artifact to a feature model to > contain the extracted metadata from the binaries it references to eliminate > the need for full binaries to be parsed or potentially even to have to be > present for the analyser to run. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-8481) Caching of Feature Model Analyser Metadata
[ https://issues.apache.org/jira/browse/SLING-8481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls resolved SLING-8481. --- Resolution: Fixed > Caching of Feature Model Analyser Metadata > -- > > Key: SLING-8481 > URL: https://issues.apache.org/jira/browse/SLING-8481 > Project: Sling > Issue Type: Improvement > Components: Feature Model >Reporter: Dominik Süß > Assignee: Karl Pauls >Priority: Major > > The feature model analyser is currently acting on the information of the > feature model files as well as the metadata of artifacts. While feature > models have a small footprint the extraction of the metadata from binaries is > costly. > Caching of this metadata should be improved in 2 ways: > a) metadata should only be extracted once and be cached in process to avoid > repetitive reading of binaries to access the same metadta > b) it should be possible to store a "sidecar" artifact to a feature model to > contain the extracted metadata from the binaries it references to eliminate > the need for full binaries to be parsed or potentially even to have to be > present for the analyser to run. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[VOTE] Release Apache Sling Feature Model Launcher 1.1.8
We solved 2 issues in this release: https://issues.apache.org/jira/projects/SLING/versions/12348778 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2350/ 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 2350 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ...
[jira] [Assigned] (SLING-8481) Caching of Feature Model Analyser Metadata
[ https://issues.apache.org/jira/browse/SLING-8481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls reassigned SLING-8481: - Assignee: Karl Pauls > Caching of Feature Model Analyser Metadata > -- > > Key: SLING-8481 > URL: https://issues.apache.org/jira/browse/SLING-8481 > Project: Sling > Issue Type: Improvement > Components: Feature Model >Reporter: Dominik Süß > Assignee: Karl Pauls >Priority: Major > > The feature model analyser is currently acting on the information of the > feature model files as well as the metadata of artifacts. While feature > models have a small footprint the extraction of the metadata from binaries is > costly. > Caching of this metadata should be improved in 2 ways: > a) metadata should only be extracted once and be cached in process to avoid > repetitive reading of binaries to access the same metadta > b) it should be possible to store a "sidecar" artifact to a feature model to > contain the extracted metadata from the binaries it references to eliminate > the need for full binaries to be parsed or potentially even to have to be > present for the analyser to run. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-9802) Launcher Classloader is not synchronizing loadClass correctly
[ https://issues.apache.org/jira/browse/SLING-9802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls resolved SLING-9802. --- Resolution: Fixed Fixed in https://github.com/apache/sling-org-apache-sling-feature-launcher/commit/f24d08bfd28c65908e113a3cf78a9a64c0d69d65 We now use the class loader lock and in turn, register the class loader to be parallel to not make that to heavy. > Launcher Classloader is not synchronizing loadClass correctly > - > > Key: SLING-9802 > URL: https://issues.apache.org/jira/browse/SLING-9802 > Project: Sling > Issue Type: Bug > Components: Feature Model >Affects Versions: Feature Model Launcher 1.1.6 > Reporter: Karl Pauls >Assignee: Karl Pauls >Priority: Major > Fix For: Feature Model Launcher 1.1.8 > > > The default LauncherClassloader is not synchronizing its loadClass method > correctly. As it just delegates to the findClass of the URLClassloader it > extends, it needs to at a minimum lock on the classname it is trying to load > - otherwise, it is possible that it will catch a LinkageError if the same > class load is happening concurrently. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SLING-9802) Launcher Classloader is not synchronizing loadClass correctly
Karl Pauls created SLING-9802: - Summary: Launcher Classloader is not synchronizing loadClass correctly Key: SLING-9802 URL: https://issues.apache.org/jira/browse/SLING-9802 Project: Sling Issue Type: Bug Components: Feature Model Affects Versions: Feature Model Launcher 1.1.6 Reporter: Karl Pauls Assignee: Karl Pauls Fix For: Feature Model Launcher 1.1.8 The default LauncherClassloader is not synchronizing its loadClass method correctly. As it just delegates to the findClass of the URLClassloader it extends, it needs to at a minimum lock on the classname it is trying to load - otherwise, it is possible that it will catch a LinkageError if the same class load is happening concurrently. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [VOTE] Release slingfeature-maven-plugin 1.4.2
+1 regards, Karl On Wed, Oct 7, 2020 at 5:59 PM Daniel Klco wrote: > > +1 > > On Wed, Oct 7, 2020 at 11:48 AM Carsten Ziegeler > wrote: > > > +1 > > > > Carsten > > > > Am 07.10.2020 um 16:22 schrieb Carsten Ziegeler: > > > Hi, > > > > > > We solved 6 issues in this release: > > > > > https://issues.apache.org/jira/browse/SLING-9779?jql=project%20%3D%20SLING%20AND%20fixVersion%20%3D%20%22OSGi%20Feature%20Maven%20Plugin%201.4.2%22 > > > > > > > > > Staging repository: > > > https://repository.apache.org/content/repositories/orgapachesling-2349/ > > > > > > 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 2349 /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 > > -- Karl Pauls karlpa...@gmail.com
[jira] [Resolved] (SLING-9798) Don't expose OSGi / Apache Felix JMX MBeans from the feature launcher
[ https://issues.apache.org/jira/browse/SLING-9798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls resolved SLING-9798. --- Resolution: Fixed Thanks [~dklco]. Revert done in https://github.com/apache/sling-org-apache-sling-feature-launcher/commit/14fd3f7476214baf2ee114e71d50f6518fd75fd8 > Don't expose OSGi / Apache Felix JMX MBeans from the feature launcher > - > > Key: SLING-9798 > URL: https://issues.apache.org/jira/browse/SLING-9798 > Project: Sling > Issue Type: Bug > Components: Feature Model >Affects Versions: Feature Model Launcher 1.1.6 > Reporter: Karl Pauls >Assignee: Karl Pauls >Priority: Major > Fix For: Feature Model Launcher 1.1.8 > > > In SLING-9621 the JMX Means have been added to the feature launcher. I think > that is a mistake. The goal of the feature launcher was to keep the > dependencies minimal and do as much as possible from the outside. > We already have the mechanism to expose the MBeans via the: > org-apache-sling-launchpad-startupmanager bundle [0]. If somebody needs the > MBeans as part of their features they can just add that bundle to their > features. > At a minimum, we would need to make the exposing configurable (in such a way > that if the config is off, it will not even need the javax.management classes > on the class path) but preferably I would really like to revert the commit in > question [1]. > [~klcodanr], would it work for if I revert the commit in favor of [0] or is > there another reasons to keep it (in which case I would make it configurable)? > [0] > https://github.com/apache/sling-org-apache-sling-launchpad-startupmanager/blob/master/src/main/java/org/apache/sling/launchpad/startupmanager/Activator.java > [1] > https://github.com/apache/sling-org-apache-sling-feature-launcher/commit/89d2a4806b09051e95b16074d853f1d83b643172 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SLING-9798) Don't expose OSGi / Apache Felix JMX MBeans from the feature launcher
Karl Pauls created SLING-9798: - Summary: Don't expose OSGi / Apache Felix JMX MBeans from the feature launcher Key: SLING-9798 URL: https://issues.apache.org/jira/browse/SLING-9798 Project: Sling Issue Type: Bug Components: Feature Model Affects Versions: Feature Model Launcher 1.1.6 Reporter: Karl Pauls Assignee: Karl Pauls Fix For: Feature Model Launcher 1.1.8 In SLING-9621 the JMX Means have been added to the feature launcher. I think that is a mistake. The goal of the feature launcher was to keep the dependencies minimal and do as much as possible from the outside. We already have the mechanism to expose the MBeans via the: org-apache-sling-launchpad-startupmanager bundle [0]. If somebody needs the MBeans as part of their features they can just add that bundle to their features. At a minimum, we would need to make the exposing configurable (in such a way that if the config is off, it will not even need the javax.management classes on the class path) but preferably I would really like to revert the commit in question [1]. [~klcodanr], would it work for if I revert the commit in favor of [0] or is there another reasons to keep it (in which case I would make it configurable)? [0] https://github.com/apache/sling-org-apache-sling-launchpad-startupmanager/blob/master/src/main/java/org/apache/sling/launchpad/startupmanager/Activator.java [1] https://github.com/apache/sling-org-apache-sling-feature-launcher/commit/89d2a4806b09051e95b16074d853f1d83b643172 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SLING-9731) Update quartz to 2.3.2
[ https://issues.apache.org/jira/browse/SLING-9731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls closed SLING-9731. - > Update quartz to 2.3.2 > -- > > Key: SLING-9731 > URL: https://issues.apache.org/jira/browse/SLING-9731 > Project: Sling > Issue Type: Improvement >Affects Versions: Commons Scheduler 2.7.6 > Reporter: Karl Pauls > Assignee: Karl Pauls >Priority: Major > Fix For: Commons Scheduler 2.7.12 > > Time Spent: 0.5h > Remaining Estimate: 0h > > We should update the quartz version used by the scheduler to 2.3.2. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SLING-7820) Scheduler's WhiteboardHandler impl not in sync with Scheduler's Javadoc
[
https://issues.apache.org/jira/browse/SLING-7820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls closed SLING-7820.
-
> Scheduler's WhiteboardHandler impl not in sync with Scheduler's Javadoc
> ---
>
> Key: SLING-7820
> URL: https://issues.apache.org/jira/browse/SLING-7820
> Project: Sling
> Issue Type: Bug
> Components: Commons
>Affects Versions: Commons Scheduler 2.7.2
>Reporter: Ashish Chopra
>Assignee: Karl Pauls
>Priority: Major
> Fix For: Commons Scheduler 2.7.12
>
>
> [Sling Commons Scheduler's
> Javadoc|https://github.com/apache/sling-org-apache-sling-commons-scheduler/blob/d954255a750113c024a9323ed0d5d85d1ee69a5a/src/main/java/org/apache/sling/commons/scheduler/Scheduler.java#L26-L48]
> asserts that:
> {quote} A job can be scheduled either by creating a {{ScheduleOptions}}
> instance through one of the scheduler methods and then calling
> {{schedule(Object, ScheduleOptions)}} or by using the whiteboard pattern and
> registering a Runnable service with either the
> {{PROPERTY_SCHEDULER_EXPRESSION}} or {{PROPERTY_SCHEDULER_PERIOD}} property.
> *If both properties are specified, only {{PROPERTY_SCHEDULER_PERIOD}} is
> considered for scheduling.*{quote}
> The part in *bold* above suggests that {{PROPERTY_SCHEDULER_PERIOD}} has a
> higher precedence than {{PROPERTY_SCHEDULER_EXPRESSION}} in case both are
> present for a component.
> However, the implementation in
> [{{WhiteboardHandler#register}}|https://github.com/apache/sling-org-apache-sling-commons-scheduler/blame/d954255a750113c024a9323ed0d5d85d1ee69a5a/src/main/java/org/apache/sling/commons/scheduler/impl/WhiteboardHandler.java#L189]
> does the opposite. It gives {{PROPERTY_SCHEDULER_EXPRESSION}} a higher
> precedence by evaluating it first.
> Either the Javadoc, or the implementation must be modified to keep both in
> sync.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SLING-9730) Scheduler job mapping doesn't work correctly for lambdas.
[ https://issues.apache.org/jira/browse/SLING-9730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls closed SLING-9730. - > Scheduler job mapping doesn't work correctly for lambdas. > - > > Key: SLING-9730 > URL: https://issues.apache.org/jira/browse/SLING-9730 > Project: Sling > Issue Type: Bug > Components: Commons >Affects Versions: Commons Scheduler 2.7.6 > Reporter: Karl Pauls >Assignee: Karl Pauls >Priority: Major > Fix For: Commons Scheduler 2.7.12 > > > When scheduling a job that is a Runnable the mapping from job to instance is > done based on the class name. That is problematic in case of lambdas as the > class name is not stable. We should use a key that is stable for all cases. > As we only have the object itself and the mapping needs to be stable across > JVMs, the easiest mapping key seems to be the package name. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [RESULT][VOTE] Release Apache Sling Commons Scheduler 2.7.12
Time to call the vote on the Apache Sling Commons Scheduler 2.7.12 release. * +1 votes from Daniel Klco, David Bosschaert, Carsten Ziegeler, Georg Henzler, and Karl Pauls. * No other votes. The vote is successful. I will make the artifacts available as soon as possible.
Re: [VOTE] Release Apache Sling Commons Scheduler 2.7.12
+1 regards, Karl On Tue, Sep 15, 2020 at 11:50 AM Georg Henzler wrote: > > +1 > > -Georg > > > On 2020-09-14 19:02, Karl Pauls wrote: > > We solved 3 issues in this release: > > https://issues.apache.org/jira/projects/SLING/versions/12348801 > > > > Staging repository: > > https://repository.apache.org/content/repositories/orgapachesling-2335/ > > > > 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 2335 /tmp/sling-staging > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] 0 Don't care > > [ ] -1 Don't release, because ... -- Karl Pauls karlpa...@gmail.com
Re: [VOTE] Release Apache Sling Models Impl Version 1.4.14
+1 regards, Karl On Mon, Oct 5, 2020 at 2:24 PM Radu Cotescu wrote: > > +1 > > > On 5 Oct 2020, at 13:33, Justin Edelson wrote: > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] 0 Don't care > > [ ] -1 Don't release, because ... > -- Karl Pauls karlpa...@gmail.com
Re: [VOTE] Release Apache Sling Scripting FreeMarker 1.0.4
+1 regards, Karl On Monday, October 5, 2020, Radu Cotescu wrote: > +1 > > > On 3 Oct 2020, at 15:49, Oliver Lietz wrote: > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] 0 Don't care > > [ ] -1 Don't release, because ... > > -- Karl Pauls karlpa...@gmail.com
Re: [VOTE] Release Apache Sling Scripting HTL Testing 1.0.26-1.4.0, Apache Sling Scripting HTL Testing Content 1.0.24-1.4.0, Apache Sling Scripting HTL Compiler 1.2.10-1.4.0
+1 regards, Karl On Thursday, October 1, 2020, Daniel Klco wrote: > +1 > > On Thu, Oct 1, 2020 at 4:07 PM Radu Cotescu wrote: > > > Hi, > > > > We solved 1 issue in these releases: > > https://issues.apache.org/jira/browse/SLING/fixforversion/12348858 > > https://issues.apache.org/jira/browse/SLING/fixforversion/12348857 > > https://issues.apache.org/jira/browse/SLING/fixforversion/12348855 > > > > Staging repository: > > https://repository.apache.org/content/repositories/orgapachesling-2346/ > > > > 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 2346 /tmp/sling-staging > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] 0 Don't care > > [ ] -1 Don't release, because ... > > > > This majority vote is open for at least 72 hours. > > > > Regards, > > Radu Cotescu > > > -- Karl Pauls karlpa...@gmail.com
