[jira] [Updated] (SLING-10700) Improve TopologyRequestValidator code
[ https://issues.apache.org/jira/browse/SLING-10700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-10700: - Fix Version/s: Discovery Base 2.0.12 > Improve TopologyRequestValidator code > - > > Key: SLING-10700 > URL: https://issues.apache.org/jira/browse/SLING-10700 > Project: Sling > Issue Type: Improvement > Components: Discovery >Affects Versions: Discovery Base 2.0.10 >Reporter: Artem Smotrakov >Priority: Major > Fix For: Discovery Base 2.0.12 > > Attachments: TopologyRequestValidator.patch > > Time Spent: 10m > Remaining Estimate: 0h > > (agreed to open a Jira issue after discussing this on secru...@apache.org) > > I noticed several security problems in TopologyRequestValidator > > [https://github.com/apache/sling-org-apache-sling-discovery-base/blob/df08b0dfa40feaed4f0fd1575d688691a7a0d946/src/main/java/org/apache/sling/discovery/base/connectors/ping/TopologyRequestValidator.java] > > They don't look severe but it may be worth addressing them. > > 1. The class uses String.equals() for validating a MAC. This method doesn't > implement a constant-time algorithm for comparing inputs. As a result, it may > allow an attacker to run a timing attack that can uncover a valid MAC. > Instead, it would be better to use MessageDigest.isEquals() > > [https://github.com/apache/sling-org-apache-sling-discovery-base/blob/df08b0dfa40feaed4f0fd1575d688691a7a0d946/src/main/java/org/apache/sling/discovery/base/connectors/ping/TopologyRequestValidator.java#L367] > > 2. The method getCipherKey() uses PBKDF2 for generating a key for MAC. NIST > recommends to use a higher iteration count > > [https://pages.nist.gov/800-63-3/sp800-63b.html#sec5] > > Furthermore, it might be better to use SHA-256 (or even better SHA-512). That > would increase the cost of an attack. > > 3. It might be better to close GZIPInputStream in a try-finally block to > avoid unreleased streams in case an exception occurs. Unclosed streams may > help to run a DoS attack. I didn't look into the implementation of > GZIPInputStream though. > > At first I thought the the class uses a static IV for a cipher > > [https://github.com/apache/sling-org-apache-sling-discovery-base/blob/df08b0dfa40feaed4f0fd1575d688691a7a0d946/src/main/java/org/apache/sling/discovery/base/connectors/ping/TopologyRequestValidator.java#L466] > > but debugging TopologyRequestValidatorTest showed that the IV is actually > random. Well, at least when you use the latest JDK 8. To be on the safer > side, it may be better to set a random IV explicitly. > > I am attaching a draft patch that addresses most of the points above (except > moving to SHA-512 and setting an explicit IV). > > Please feel free to use this patch, or I can open a pull request if it is > fine. You can also create a private branch and a security advisory on GitHub, > then I can open a pull request against that branch. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-10700) Improve TopologyRequestValidator code
[ https://issues.apache.org/jira/browse/SLING-10700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-10700: - Affects Version/s: Discovery Base 2.0.10 > Improve TopologyRequestValidator code > - > > Key: SLING-10700 > URL: https://issues.apache.org/jira/browse/SLING-10700 > Project: Sling > Issue Type: Improvement > Components: Discovery >Affects Versions: Discovery Base 2.0.10 >Reporter: Artem Smotrakov >Priority: Major > Attachments: TopologyRequestValidator.patch > > Time Spent: 10m > Remaining Estimate: 0h > > (agreed to open a Jira issue after discussing this on secru...@apache.org) > > I noticed several security problems in TopologyRequestValidator > > [https://github.com/apache/sling-org-apache-sling-discovery-base/blob/df08b0dfa40feaed4f0fd1575d688691a7a0d946/src/main/java/org/apache/sling/discovery/base/connectors/ping/TopologyRequestValidator.java] > > They don't look severe but it may be worth addressing them. > > 1. The class uses String.equals() for validating a MAC. This method doesn't > implement a constant-time algorithm for comparing inputs. As a result, it may > allow an attacker to run a timing attack that can uncover a valid MAC. > Instead, it would be better to use MessageDigest.isEquals() > > [https://github.com/apache/sling-org-apache-sling-discovery-base/blob/df08b0dfa40feaed4f0fd1575d688691a7a0d946/src/main/java/org/apache/sling/discovery/base/connectors/ping/TopologyRequestValidator.java#L367] > > 2. The method getCipherKey() uses PBKDF2 for generating a key for MAC. NIST > recommends to use a higher iteration count > > [https://pages.nist.gov/800-63-3/sp800-63b.html#sec5] > > Furthermore, it might be better to use SHA-256 (or even better SHA-512). That > would increase the cost of an attack. > > 3. It might be better to close GZIPInputStream in a try-finally block to > avoid unreleased streams in case an exception occurs. Unclosed streams may > help to run a DoS attack. I didn't look into the implementation of > GZIPInputStream though. > > At first I thought the the class uses a static IV for a cipher > > [https://github.com/apache/sling-org-apache-sling-discovery-base/blob/df08b0dfa40feaed4f0fd1575d688691a7a0d946/src/main/java/org/apache/sling/discovery/base/connectors/ping/TopologyRequestValidator.java#L466] > > but debugging TopologyRequestValidatorTest showed that the IV is actually > random. Well, at least when you use the latest JDK 8. To be on the safer > side, it may be better to set a random IV explicitly. > > I am attaching a draft patch that addresses most of the points above (except > moving to SHA-512 and setting an explicit IV). > > Please feel free to use this patch, or I can open a pull request if it is > fine. You can also create a private branch and a security advisory on GitHub, > then I can open a pull request against that branch. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-10700) Improve TopologyRequestValidator code
[ https://issues.apache.org/jira/browse/SLING-10700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-10700: - Component/s: Discovery > Improve TopologyRequestValidator code > - > > Key: SLING-10700 > URL: https://issues.apache.org/jira/browse/SLING-10700 > Project: Sling > Issue Type: Improvement > Components: Discovery >Reporter: Artem Smotrakov >Priority: Major > Attachments: TopologyRequestValidator.patch > > Time Spent: 10m > Remaining Estimate: 0h > > (agreed to open a Jira issue after discussing this on secru...@apache.org) > > I noticed several security problems in TopologyRequestValidator > > [https://github.com/apache/sling-org-apache-sling-discovery-base/blob/df08b0dfa40feaed4f0fd1575d688691a7a0d946/src/main/java/org/apache/sling/discovery/base/connectors/ping/TopologyRequestValidator.java] > > They don't look severe but it may be worth addressing them. > > 1. The class uses String.equals() for validating a MAC. This method doesn't > implement a constant-time algorithm for comparing inputs. As a result, it may > allow an attacker to run a timing attack that can uncover a valid MAC. > Instead, it would be better to use MessageDigest.isEquals() > > [https://github.com/apache/sling-org-apache-sling-discovery-base/blob/df08b0dfa40feaed4f0fd1575d688691a7a0d946/src/main/java/org/apache/sling/discovery/base/connectors/ping/TopologyRequestValidator.java#L367] > > 2. The method getCipherKey() uses PBKDF2 for generating a key for MAC. NIST > recommends to use a higher iteration count > > [https://pages.nist.gov/800-63-3/sp800-63b.html#sec5] > > Furthermore, it might be better to use SHA-256 (or even better SHA-512). That > would increase the cost of an attack. > > 3. It might be better to close GZIPInputStream in a try-finally block to > avoid unreleased streams in case an exception occurs. Unclosed streams may > help to run a DoS attack. I didn't look into the implementation of > GZIPInputStream though. > > At first I thought the the class uses a static IV for a cipher > > [https://github.com/apache/sling-org-apache-sling-discovery-base/blob/df08b0dfa40feaed4f0fd1575d688691a7a0d946/src/main/java/org/apache/sling/discovery/base/connectors/ping/TopologyRequestValidator.java#L466] > > but debugging TopologyRequestValidatorTest showed that the IV is actually > random. Well, at least when you use the latest JDK 8. To be on the safer > side, it may be better to set a random IV explicitly. > > I am attaching a draft patch that addresses most of the points above (except > moving to SHA-512 and setting an explicit IV). > > Please feel free to use this patch, or I can open a pull request if it is > fine. You can also create a private branch and a security advisory on GitHub, > then I can open a pull request against that branch. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[VOTE] Release Apache Sling Scripting HTL Compiler version 1.2.14-1.4.0, Scripting HTL Runtime version 1.2.6-1.4.0
Hi, We solved 1 issues in the Scripting HTL Compiler 1.2.14-1.4.0 release: https://issues.apache.org/jira/browse/SLING/fixforversion/12350467 Changes: https://github.com/apache/sling-org-apache-sling-scripting-sightly-compiler/compare/org.apache.sling.scripting.sightly.compiler-1.2.12-1.4.0...org.apache.sling.scripting.sightly.compiler-1.2.14-1.4.0 We solved 4 issues in the Scripting HTL Runtime 1.2.6-1.4.0 release: https://issues.apache.org/jira/browse/SLING/fixforversion/12350438 Changes: https://github.com/apache/sling-org-apache-sling-scripting-sightly-runtime/compare/org.apache.sling.scripting.sightly.runtime-1.2.4-1.4.0...org.apache.sling.scripting.sightly.runtime-1.2.6-1.4.0 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2510/ 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 2510 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours.
[jira] [Commented] (SLING-10700) Improve TopologyRequestValidator code
[ https://issues.apache.org/jira/browse/SLING-10700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17392450#comment-17392450 ] Artem Smotrakov commented on SLING-10700: - The following pull request address the issues above https://github.com/apache/sling-org-apache-sling-discovery-base/pull/5 > Improve TopologyRequestValidator code > - > > Key: SLING-10700 > URL: https://issues.apache.org/jira/browse/SLING-10700 > Project: Sling > Issue Type: Improvement >Reporter: Artem Smotrakov >Priority: Major > Attachments: TopologyRequestValidator.patch > > Time Spent: 10m > Remaining Estimate: 0h > > (agreed to open a Jira issue after discussing this on secru...@apache.org) > > I noticed several security problems in TopologyRequestValidator > > [https://github.com/apache/sling-org-apache-sling-discovery-base/blob/df08b0dfa40feaed4f0fd1575d688691a7a0d946/src/main/java/org/apache/sling/discovery/base/connectors/ping/TopologyRequestValidator.java] > > They don't look severe but it may be worth addressing them. > > 1. The class uses String.equals() for validating a MAC. This method doesn't > implement a constant-time algorithm for comparing inputs. As a result, it may > allow an attacker to run a timing attack that can uncover a valid MAC. > Instead, it would be better to use MessageDigest.isEquals() > > [https://github.com/apache/sling-org-apache-sling-discovery-base/blob/df08b0dfa40feaed4f0fd1575d688691a7a0d946/src/main/java/org/apache/sling/discovery/base/connectors/ping/TopologyRequestValidator.java#L367] > > 2. The method getCipherKey() uses PBKDF2 for generating a key for MAC. NIST > recommends to use a higher iteration count > > [https://pages.nist.gov/800-63-3/sp800-63b.html#sec5] > > Furthermore, it might be better to use SHA-256 (or even better SHA-512). That > would increase the cost of an attack. > > 3. It might be better to close GZIPInputStream in a try-finally block to > avoid unreleased streams in case an exception occurs. Unclosed streams may > help to run a DoS attack. I didn't look into the implementation of > GZIPInputStream though. > > At first I thought the the class uses a static IV for a cipher > > [https://github.com/apache/sling-org-apache-sling-discovery-base/blob/df08b0dfa40feaed4f0fd1575d688691a7a0d946/src/main/java/org/apache/sling/discovery/base/connectors/ping/TopologyRequestValidator.java#L466] > > but debugging TopologyRequestValidatorTest showed that the IV is actually > random. Well, at least when you use the latest JDK 8. To be on the safer > side, it may be better to set a random IV explicitly. > > I am attaching a draft patch that addresses most of the points above (except > moving to SHA-512 and setting an explicit IV). > > Please feel free to use this patch, or I can open a pull request if it is > fine. You can also create a private branch and a security advisory on GitHub, > then I can open a pull request against that branch. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [sling-org-apache-sling-discovery-base] artem-smotrakov opened a new pull request #5: SLING-10700: Improve TopologyRequestValidator code
artem-smotrakov opened a new pull request #5: URL: https://github.com/apache/sling-org-apache-sling-discovery-base/pull/5 This addresses https://issues.apache.org/jira/browse/SLING-10700 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (SLING-10700) Improve TopologyRequestValidator code
Artem Smotrakov created SLING-10700: --- Summary: Improve TopologyRequestValidator code Key: SLING-10700 URL: https://issues.apache.org/jira/browse/SLING-10700 Project: Sling Issue Type: Improvement Reporter: Artem Smotrakov Attachments: TopologyRequestValidator.patch (agreed to open a Jira issue after discussing this on secru...@apache.org) I noticed several security problems in TopologyRequestValidator [https://github.com/apache/sling-org-apache-sling-discovery-base/blob/df08b0dfa40feaed4f0fd1575d688691a7a0d946/src/main/java/org/apache/sling/discovery/base/connectors/ping/TopologyRequestValidator.java] They don't look severe but it may be worth addressing them. 1. The class uses String.equals() for validating a MAC. This method doesn't implement a constant-time algorithm for comparing inputs. As a result, it may allow an attacker to run a timing attack that can uncover a valid MAC. Instead, it would be better to use MessageDigest.isEquals() [https://github.com/apache/sling-org-apache-sling-discovery-base/blob/df08b0dfa40feaed4f0fd1575d688691a7a0d946/src/main/java/org/apache/sling/discovery/base/connectors/ping/TopologyRequestValidator.java#L367] 2. The method getCipherKey() uses PBKDF2 for generating a key for MAC. NIST recommends to use a higher iteration count [https://pages.nist.gov/800-63-3/sp800-63b.html#sec5] Furthermore, it might be better to use SHA-256 (or even better SHA-512). That would increase the cost of an attack. 3. It might be better to close GZIPInputStream in a try-finally block to avoid unreleased streams in case an exception occurs. Unclosed streams may help to run a DoS attack. I didn't look into the implementation of GZIPInputStream though. At first I thought the the class uses a static IV for a cipher [https://github.com/apache/sling-org-apache-sling-discovery-base/blob/df08b0dfa40feaed4f0fd1575d688691a7a0d946/src/main/java/org/apache/sling/discovery/base/connectors/ping/TopologyRequestValidator.java#L466] but debugging TopologyRequestValidatorTest showed that the IV is actually random. Well, at least when you use the latest JDK 8. To be on the safer side, it may be better to set a random IV explicitly. I am attaching a draft patch that addresses most of the points above (except moving to SHA-512 and setting an explicit IV). Please feel free to use this patch, or I can open a pull request if it is fine. You can also create a private branch and a security advisory on GitHub, then I can open a pull request against that branch. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (SLING-10699) Incomplete path conversion in VaultPackageAssembler.toRepositoryPaths
[
https://issues.apache.org/jira/browse/SLING-10699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber reassigned SLING-10699:
Assignee: Angela Schreiber
> Incomplete path conversion in VaultPackageAssembler.toRepositoryPaths
> -
>
> Key: SLING-10699
> URL: https://issues.apache.org/jira/browse/SLING-10699
> Project: Sling
> Issue Type: Bug
> Components: Content-Package to Feature Model Converter
>Affects Versions: Content-Package to Feature Model Converter 1.1.6
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.1.8
>
>
> [~kpauls] while testing a fix for SLING-10692 i noticed that
> {{VaultPackageAssembler.toRepositoryPaths}} only removes the _/jcr_root_
> prefix from the fvault paths but doesn't convert the segments. so an path
> that got moved to repo-init like e.g. _/jcr_root/test/_rep_policy.xml_
> doesn't get fully converted to _/test/rep:policy.xml_ before adding it to the
> extra exclude entries.
> and while we take a closer look at it, i am also wondering if there was any
> negative side effect from the .xml extension.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (SLING-10694) CPConverter drops mode from filters
[ https://issues.apache.org/jira/browse/SLING-10694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber reassigned SLING-10694: Assignee: Angela Schreiber > CPConverter drops mode from filters > --- > > Key: SLING-10694 > URL: https://issues.apache.org/jira/browse/SLING-10694 > Project: Sling > Issue Type: Bug > Components: Content-Package to Feature Model Converter >Affects Versions: Content-Package to Feature Model Converter 1.1.6 >Reporter: Niek Raaijmakers >Assignee: Angela Schreiber >Priority: Major > Fix For: Content-Package to Feature Model Converter 1.1.8 > > Original Estimate: 72h > Remaining Estimate: 72h > > The CPConverter, when converting over the all package, drops the mode="merge" > from the subsequent packages' filters. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (SLING-10692) VaultPackageAssembler.mergeFilters drops propertyFilterSets
[
https://issues.apache.org/jira/browse/SLING-10692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber reassigned SLING-10692:
Assignee: Angela Schreiber
> VaultPackageAssembler.mergeFilters drops propertyFilterSets
> ---
>
> Key: SLING-10692
> URL: https://issues.apache.org/jira/browse/SLING-10692
> Project: Sling
> Issue Type: Bug
> Components: Content-Package to Feature Model Converter
>Affects Versions: Content-Package to Feature Model Converter 1.1.6
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.1.8
>
>
> [~kpauls], write providing a fix for
> https://github.com/apache/sling-org-apache-sling-feature-cpconverter/pull/97
> i noticed that if the option 'matchProperties=true' is present with any entry
> of a given {{PathFilterSet}} those entries will be drop from the
> {{WorkspaceFilter}} upon {{mergeFilters}} because the method only transfers
> node-PathFilterSet(s):
> {code}
> public void mergeFilters(@NotNull WorkspaceFilter filter) {
> for (PathFilterSet pathFilterSet : filter.getFilterSets()) {
> if
> (!OSGI_BUNDLE_PATTERN.matcher(pathFilterSet.getRoot()).matches()) {
> this.filter.add(pathFilterSet);
> }
> }
> }
> {code}
> what it should do instead would likely be something along the following lines
> {code}
> public void mergeFilters(@NotNull WorkspaceFilter filter) {
> Map propFilterSets = new LinkedHashMap<>();
> filter.getPropertyFilterSets().forEach(pathFilterSet ->
> propFilterSets.put(pathFilterSet.getRoot(), pathFilterSet));
> for (PathFilterSet pathFilterSet : filter.getFilterSets()) {
> if
> (!OSGI_BUNDLE_PATTERN.matcher(pathFilterSet.getRoot()).matches()) {
> PathFilterSet propSet =
> propFilterSets.remove(pathFilterSet.getRoot());
> if (propSet != null) {
> this.filter.add(pathFilterSet, propSet);
> } else {
> this.filter.add(pathFilterSet);
> }
> }
> }
> }
> {code}
> I didn't yet write extensive tests to verify that this actually works
> property, but I suspect that in addition there might be changes required to
> the {{createAdjustedFilter}} method at a first glance it seems that a
> combination of {{DefaultWorkspaceFilter#addPropertyFilterSet(PathFilterSet
> set)}} and {{#add(PathFilterSet set)}} isn't equivalent of
> {{DefaultWorkspaceFilter#add(PathFilterSet nodeFilter, PathFilterSet
> propFilter)}} which might result in subtle differences when generating the
> new Filter source.
> wdyt? i don't know how common 'matchProperties=true' is in practice but if
> present this issue would lead to a different behavior of the content package.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [sling-org-apache-sling-feature-cpconverter] anchela edited a comment on pull request #98: SLING-10692 : VaultPackageAssembler.mergeFilters drops propertyFilterSets [...]
anchela edited a comment on pull request #98: URL: https://github.com/apache/sling-org-apache-sling-feature-cpconverter/pull/98#issuecomment-891836226 @karlpauls , i would appreciate if you had time to review the proposed fixes. in particular the calculation of the repository-paths in VaultPackageAssembler line 360ff. as outline in SLING-10699 the vault-internal paths end with .xml and include .content.xml that has not equivalent in the the repository. i had a look at a few existing content packages that filter out users and rep:policy nodes and all either just had the real repository path in the include/exclude or made it a reg exp like the following example (slighly modified after an example in Adobe AEM): ``` [...] ``` also: do you seen any special cases that deserve additional testing? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [sling-org-apache-sling-feature-cpconverter] anchela commented on pull request #98: SLING-10692 : VaultPackageAssembler.mergeFilters drops propertyFilterSets [...]
anchela commented on pull request #98: URL: https://github.com/apache/sling-org-apache-sling-feature-cpconverter/pull/98#issuecomment-891836226 @karlpauls , i would appreciate if you had time to review the proposed fixes. in particular the calculation of the repository-paths in VaultPackageAssembler line 360ff. as outline in SLING-10699 the vault-internal paths end with .xml and include .content.xml that has not equivalent in the the repository. i had a look at a few existing content packages that filter out users and rep:policy nodes and all either just had the real repository path in the include/exclude or made it a reg exp like the following example (slighly modified after an example in Adobe AEM): ``` [...] ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [sling-org-apache-sling-feature-cpconverter] sonarcloud[bot] commented on pull request #98: SLING-10692 : VaultPackageAssembler.mergeFilters drops propertyFilterSets [...]
sonarcloud[bot] commented on pull request #98: URL: https://github.com/apache/sling-org-apache-sling-feature-cpconverter/pull/98#issuecomment-891834147 Kudos, SonarCloud Quality Gate passed!  [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=98=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=98=false=BUG) [0 Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=98=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=98=false=VULNERABILITY) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=98=false=VULNERABILITY) [0 Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=98=false=VULNERABILITY) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-feature-cpconverter=98=false=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-feature-cpconverter=98=false=SECURITY_HOTSPOT) [0 Security Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-feature-cpconverter=98=false=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=98=false=CODE_SMELL) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=98=false=CODE_SMELL) [0 Code Smells](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=98=false=CODE_SMELL) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-cpconverter=98=new_coverage=list) [91.2% Coverage](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-cpconverter=98=new_coverage=list) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-cpconverter=98=new_duplicated_lines_density=list) [0.0% Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-cpconverter=98=new_duplicated_lines_density=list) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [sling-org-apache-sling-feature-cpconverter] anchela opened a new pull request #98: SLING-10692 : VaultPackageAssembler.mergeFilters drops propertyFilterSets [...]
anchela opened a new pull request #98: URL: https://github.com/apache/sling-org-apache-sling-feature-cpconverter/pull/98 SLING-10694 : CPConverter drops mode from filters SLING-10699 : Incomplete path conversion in VaultPackageAssembler.toRepositoryPaths -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (SLING-10692) VaultPackageAssembler.mergeFilters drops propertyFilterSets
[
https://issues.apache.org/jira/browse/SLING-10692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber updated SLING-10692:
-
Fix Version/s: Feature Model Converter 1.0.16
> VaultPackageAssembler.mergeFilters drops propertyFilterSets
> ---
>
> Key: SLING-10692
> URL: https://issues.apache.org/jira/browse/SLING-10692
> Project: Sling
> Issue Type: Bug
> Components: Content-Package to Feature Model Converter
>Affects Versions: Content-Package to Feature Model Converter 1.1.6
>Reporter: Angela Schreiber
>Priority: Major
> Fix For: Feature Model Converter 1.0.16
>
>
> [~kpauls], write providing a fix for
> https://github.com/apache/sling-org-apache-sling-feature-cpconverter/pull/97
> i noticed that if the option 'matchProperties=true' is present with any entry
> of a given {{PathFilterSet}} those entries will be drop from the
> {{WorkspaceFilter}} upon {{mergeFilters}} because the method only transfers
> node-PathFilterSet(s):
> {code}
> public void mergeFilters(@NotNull WorkspaceFilter filter) {
> for (PathFilterSet pathFilterSet : filter.getFilterSets()) {
> if
> (!OSGI_BUNDLE_PATTERN.matcher(pathFilterSet.getRoot()).matches()) {
> this.filter.add(pathFilterSet);
> }
> }
> }
> {code}
> what it should do instead would likely be something along the following lines
> {code}
> public void mergeFilters(@NotNull WorkspaceFilter filter) {
> Map propFilterSets = new LinkedHashMap<>();
> filter.getPropertyFilterSets().forEach(pathFilterSet ->
> propFilterSets.put(pathFilterSet.getRoot(), pathFilterSet));
> for (PathFilterSet pathFilterSet : filter.getFilterSets()) {
> if
> (!OSGI_BUNDLE_PATTERN.matcher(pathFilterSet.getRoot()).matches()) {
> PathFilterSet propSet =
> propFilterSets.remove(pathFilterSet.getRoot());
> if (propSet != null) {
> this.filter.add(pathFilterSet, propSet);
> } else {
> this.filter.add(pathFilterSet);
> }
> }
> }
> }
> {code}
> I didn't yet write extensive tests to verify that this actually works
> property, but I suspect that in addition there might be changes required to
> the {{createAdjustedFilter}} method at a first glance it seems that a
> combination of {{DefaultWorkspaceFilter#addPropertyFilterSet(PathFilterSet
> set)}} and {{#add(PathFilterSet set)}} isn't equivalent of
> {{DefaultWorkspaceFilter#add(PathFilterSet nodeFilter, PathFilterSet
> propFilter)}} which might result in subtle differences when generating the
> new Filter source.
> wdyt? i don't know how common 'matchProperties=true' is in practice but if
> present this issue would lead to a different behavior of the content package.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-10699) Incomplete path conversion in VaultPackageAssembler.toRepositoryPaths
[
https://issues.apache.org/jira/browse/SLING-10699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber updated SLING-10699:
-
Fix Version/s: Content-Package to Feature Model Converter 1.1.8
> Incomplete path conversion in VaultPackageAssembler.toRepositoryPaths
> -
>
> Key: SLING-10699
> URL: https://issues.apache.org/jira/browse/SLING-10699
> Project: Sling
> Issue Type: Bug
> Components: Content-Package to Feature Model Converter
>Reporter: Angela Schreiber
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.1.8
>
>
> [~kpauls] while testing a fix for SLING-10692 i noticed that
> {{VaultPackageAssembler.toRepositoryPaths}} only removes the _/jcr_root_
> prefix from the fvault paths but doesn't convert the segments. so an path
> that got moved to repo-init like e.g. _/jcr_root/test/_rep_policy.xml_
> doesn't get fully converted to _/test/rep:policy.xml_ before adding it to the
> extra exclude entries.
> and while we take a closer look at it, i am also wondering if there was any
> negative side effect from the .xml extension.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-10692) VaultPackageAssembler.mergeFilters drops propertyFilterSets
[
https://issues.apache.org/jira/browse/SLING-10692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber updated SLING-10692:
-
Fix Version/s: (was: Feature Model Converter 1.0.16)
Content-Package to Feature Model Converter 1.1.8
> VaultPackageAssembler.mergeFilters drops propertyFilterSets
> ---
>
> Key: SLING-10692
> URL: https://issues.apache.org/jira/browse/SLING-10692
> Project: Sling
> Issue Type: Bug
> Components: Content-Package to Feature Model Converter
>Affects Versions: Content-Package to Feature Model Converter 1.1.6
>Reporter: Angela Schreiber
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.1.8
>
>
> [~kpauls], write providing a fix for
> https://github.com/apache/sling-org-apache-sling-feature-cpconverter/pull/97
> i noticed that if the option 'matchProperties=true' is present with any entry
> of a given {{PathFilterSet}} those entries will be drop from the
> {{WorkspaceFilter}} upon {{mergeFilters}} because the method only transfers
> node-PathFilterSet(s):
> {code}
> public void mergeFilters(@NotNull WorkspaceFilter filter) {
> for (PathFilterSet pathFilterSet : filter.getFilterSets()) {
> if
> (!OSGI_BUNDLE_PATTERN.matcher(pathFilterSet.getRoot()).matches()) {
> this.filter.add(pathFilterSet);
> }
> }
> }
> {code}
> what it should do instead would likely be something along the following lines
> {code}
> public void mergeFilters(@NotNull WorkspaceFilter filter) {
> Map propFilterSets = new LinkedHashMap<>();
> filter.getPropertyFilterSets().forEach(pathFilterSet ->
> propFilterSets.put(pathFilterSet.getRoot(), pathFilterSet));
> for (PathFilterSet pathFilterSet : filter.getFilterSets()) {
> if
> (!OSGI_BUNDLE_PATTERN.matcher(pathFilterSet.getRoot()).matches()) {
> PathFilterSet propSet =
> propFilterSets.remove(pathFilterSet.getRoot());
> if (propSet != null) {
> this.filter.add(pathFilterSet, propSet);
> } else {
> this.filter.add(pathFilterSet);
> }
> }
> }
> }
> {code}
> I didn't yet write extensive tests to verify that this actually works
> property, but I suspect that in addition there might be changes required to
> the {{createAdjustedFilter}} method at a first glance it seems that a
> combination of {{DefaultWorkspaceFilter#addPropertyFilterSet(PathFilterSet
> set)}} and {{#add(PathFilterSet set)}} isn't equivalent of
> {{DefaultWorkspaceFilter#add(PathFilterSet nodeFilter, PathFilterSet
> propFilter)}} which might result in subtle differences when generating the
> new Filter source.
> wdyt? i don't know how common 'matchProperties=true' is in practice but if
> present this issue would lead to a different behavior of the content package.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-10699) Incomplete path conversion in VaultPackageAssembler.toRepositoryPaths
[
https://issues.apache.org/jira/browse/SLING-10699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber updated SLING-10699:
-
Affects Version/s: Content-Package to Feature Model Converter 1.1.6
> Incomplete path conversion in VaultPackageAssembler.toRepositoryPaths
> -
>
> Key: SLING-10699
> URL: https://issues.apache.org/jira/browse/SLING-10699
> Project: Sling
> Issue Type: Bug
> Components: Content-Package to Feature Model Converter
>Affects Versions: Content-Package to Feature Model Converter 1.1.6
>Reporter: Angela Schreiber
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.1.8
>
>
> [~kpauls] while testing a fix for SLING-10692 i noticed that
> {{VaultPackageAssembler.toRepositoryPaths}} only removes the _/jcr_root_
> prefix from the fvault paths but doesn't convert the segments. so an path
> that got moved to repo-init like e.g. _/jcr_root/test/_rep_policy.xml_
> doesn't get fully converted to _/test/rep:policy.xml_ before adding it to the
> extra exclude entries.
> and while we take a closer look at it, i am also wondering if there was any
> negative side effect from the .xml extension.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-10694) CPConverter drops mode from filters
[ https://issues.apache.org/jira/browse/SLING-10694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber updated SLING-10694: - Affects Version/s: Content-Package to Feature Model Converter 1.1.6 > CPConverter drops mode from filters > --- > > Key: SLING-10694 > URL: https://issues.apache.org/jira/browse/SLING-10694 > Project: Sling > Issue Type: Bug > Components: Content-Package to Feature Model Converter >Affects Versions: Content-Package to Feature Model Converter 1.1.6 >Reporter: Niek Raaijmakers >Priority: Major > Fix For: Content-Package to Feature Model Converter 1.1.8 > > Original Estimate: 72h > Remaining Estimate: 72h > > The CPConverter, when converting over the all package, drops the mode="merge" > from the subsequent packages' filters. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-10692) VaultPackageAssembler.mergeFilters drops propertyFilterSets
[
https://issues.apache.org/jira/browse/SLING-10692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber updated SLING-10692:
-
Affects Version/s: Content-Package to Feature Model Converter 1.1.6
> VaultPackageAssembler.mergeFilters drops propertyFilterSets
> ---
>
> Key: SLING-10692
> URL: https://issues.apache.org/jira/browse/SLING-10692
> Project: Sling
> Issue Type: Bug
> Components: Content-Package to Feature Model Converter
>Affects Versions: Content-Package to Feature Model Converter 1.1.6
>Reporter: Angela Schreiber
>Priority: Major
>
> [~kpauls], write providing a fix for
> https://github.com/apache/sling-org-apache-sling-feature-cpconverter/pull/97
> i noticed that if the option 'matchProperties=true' is present with any entry
> of a given {{PathFilterSet}} those entries will be drop from the
> {{WorkspaceFilter}} upon {{mergeFilters}} because the method only transfers
> node-PathFilterSet(s):
> {code}
> public void mergeFilters(@NotNull WorkspaceFilter filter) {
> for (PathFilterSet pathFilterSet : filter.getFilterSets()) {
> if
> (!OSGI_BUNDLE_PATTERN.matcher(pathFilterSet.getRoot()).matches()) {
> this.filter.add(pathFilterSet);
> }
> }
> }
> {code}
> what it should do instead would likely be something along the following lines
> {code}
> public void mergeFilters(@NotNull WorkspaceFilter filter) {
> Map propFilterSets = new LinkedHashMap<>();
> filter.getPropertyFilterSets().forEach(pathFilterSet ->
> propFilterSets.put(pathFilterSet.getRoot(), pathFilterSet));
> for (PathFilterSet pathFilterSet : filter.getFilterSets()) {
> if
> (!OSGI_BUNDLE_PATTERN.matcher(pathFilterSet.getRoot()).matches()) {
> PathFilterSet propSet =
> propFilterSets.remove(pathFilterSet.getRoot());
> if (propSet != null) {
> this.filter.add(pathFilterSet, propSet);
> } else {
> this.filter.add(pathFilterSet);
> }
> }
> }
> }
> {code}
> I didn't yet write extensive tests to verify that this actually works
> property, but I suspect that in addition there might be changes required to
> the {{createAdjustedFilter}} method at a first glance it seems that a
> combination of {{DefaultWorkspaceFilter#addPropertyFilterSet(PathFilterSet
> set)}} and {{#add(PathFilterSet set)}} isn't equivalent of
> {{DefaultWorkspaceFilter#add(PathFilterSet nodeFilter, PathFilterSet
> propFilter)}} which might result in subtle differences when generating the
> new Filter source.
> wdyt? i don't know how common 'matchProperties=true' is in practice but if
> present this issue would lead to a different behavior of the content package.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-10694) CPConverter drops mode from filters
[ https://issues.apache.org/jira/browse/SLING-10694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber updated SLING-10694: - Fix Version/s: Content-Package to Feature Model Converter 1.1.8 > CPConverter drops mode from filters > --- > > Key: SLING-10694 > URL: https://issues.apache.org/jira/browse/SLING-10694 > Project: Sling > Issue Type: Bug > Components: Content-Package to Feature Model Converter >Reporter: Niek Raaijmakers >Priority: Major > Fix For: Content-Package to Feature Model Converter 1.1.8 > > Original Estimate: 72h > Remaining Estimate: 72h > > The CPConverter, when converting over the all package, drops the mode="merge" > from the subsequent packages' filters. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-10694) CPConverter drops mode from filters
[ https://issues.apache.org/jira/browse/SLING-10694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber updated SLING-10694: - Component/s: Content-Package to Feature Model Converter > CPConverter drops mode from filters > --- > > Key: SLING-10694 > URL: https://issues.apache.org/jira/browse/SLING-10694 > Project: Sling > Issue Type: Bug > Components: Content-Package to Feature Model Converter >Reporter: Niek Raaijmakers >Priority: Major > Original Estimate: 72h > Remaining Estimate: 72h > > The CPConverter, when converting over the all package, drops the mode="merge" > from the subsequent packages' filters. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SLING-10699) Incomplete path conversion in VaultPackageAssembler.toRepositoryPaths
Angela Schreiber created SLING-10699:
Summary: Incomplete path conversion in
VaultPackageAssembler.toRepositoryPaths
Key: SLING-10699
URL: https://issues.apache.org/jira/browse/SLING-10699
Project: Sling
Issue Type: Bug
Components: Content-Package to Feature Model Converter
Reporter: Angela Schreiber
[~kpauls] while testing a fix for SLING-10692 i noticed that
{{VaultPackageAssembler.toRepositoryPaths}} only removes the _/jcr_root_ prefix
from the fvault paths but doesn't convert the segments. so an path that got
moved to repo-init like e.g. _/jcr_root/test/_rep_policy.xml_ doesn't get fully
converted to _/test/rep:policy.xml_ before adding it to the extra exclude
entries.
and while we take a closer look at it, i am also wondering if there was any
negative side effect from the .xml extension.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [sling-scriptingbundle-maven-plugin] raducotescu edited a comment on pull request #3: SLING-10689 optionally don't generate require-capabilities header for
raducotescu edited a comment on pull request #3: URL: https://github.com/apache/sling-scriptingbundle-maven-plugin/pull/3#issuecomment-891701174 I think we can enable the stricter parser. The changes are not that big and, to my knowledge, except for the testing examples, nobody uses yet the versioned capabilities. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [sling-scriptingbundle-maven-plugin] raducotescu edited a comment on pull request #3: SLING-10689 optionally don't generate require-capabilities header for
raducotescu edited a comment on pull request #3: URL: https://github.com/apache/sling-scriptingbundle-maven-plugin/pull/3#issuecomment-891701174 I think we can enable the stricter parser. The changes are not that big and, to my knowledge, except for the testing examples, nobody uses the versioned capabilities. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [sling-scriptingbundle-maven-plugin] raducotescu commented on pull request #3: SLING-10689 optionally don't generate require-capabilities header for
raducotescu commented on pull request #3: URL: https://github.com/apache/sling-scriptingbundle-maven-plugin/pull/3#issuecomment-891701174 I think we can enable the stricter parser. The changes are not that big and to my knowledge, except for the testing examples, nobody uses yet the versioned capabilities. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [sling-scriptingbundle-maven-plugin] kwin edited a comment on pull request #3: SLING-10689 optionally don't generate require-capabilities header for
kwin edited a comment on pull request #3: URL: https://github.com/apache/sling-scriptingbundle-maven-plugin/pull/3#issuecomment-891693924 I am fine with using another directive/attribute. The main question is if the stricter parsing is ok (so that the position of the attribute/directive does not matter) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [sling-scriptingbundle-maven-plugin] kwin commented on pull request #3: SLING-10689 optionally don't generate require-capabilities header for
kwin commented on pull request #3: URL: https://github.com/apache/sling-scriptingbundle-maven-plugin/pull/3#issuecomment-891693924 I am fine with using another directive/attribute. The main question is if the stricter parsing is ok (so that the position of the attribute/version does not matter) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [sling-scriptingbundle-maven-plugin] karlpauls commented on pull request #3: SLING-10689 optionally don't generate require-capabilities header for
karlpauls commented on pull request #3: URL: https://github.com/apache/sling-scriptingbundle-maven-plugin/pull/3#issuecomment-891691474 @kwin, wouldn't it be better to just allow extends to be resolution=optional? So, we would still parse it as a header but just add all attributes and directives found to the resulting requirement - that way, one can add a resolution optional and be done with it? (/cc @raducotescu) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [sling-org-apache-sling-scripting-core] bdelacretaz commented on a change in pull request #8: SLING-10584 log an info message if adding bindings takes more than 1 msec
bdelacretaz commented on a change in pull request #8:
URL:
https://github.com/apache/sling-org-apache-sling-scripting-core/pull/8#discussion_r681561784
##
File path:
src/main/java/org/apache/sling/scripting/core/impl/bundled/ScriptContextProvider.java
##
@@ -105,7 +110,16 @@ public ExecutableContext
prepareScriptContext(SlingHttpServletRequest request, S
ProtectedBindings protectedBindings = new ProtectedBindings(bindings,
PROTECTED_BINDINGS);
for (BindingsValuesProvider bindingsValuesProvider :
bvpTracker.getBindingsValuesProviders(scriptEngine.getFactory(),
BindingsValuesProvider.DEFAULT_CONTEXT)) {
+long start = System.nanoTime();
bindingsValuesProvider.addBindings(protectedBindings);
+long stop = System.nanoTime();
+LOG.trace("Invoking addBindings() of {} took {} nanoseconds",
+bindingsValuesProvider.getClass().getName(), stop-start);
+if ((stop-start) > WARN_LIMIT_FOR_BVP_NANOS) {
+LOG.info("Adding the bindings of {} took {} microseconds;"
Review comment:
same nitpick as above, "which is above..."
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [sling-org-apache-sling-scripting-core] bdelacretaz commented on a change in pull request #8: SLING-10584 log an info message if adding bindings takes more than 1 msec
bdelacretaz commented on a change in pull request #8:
URL:
https://github.com/apache/sling-org-apache-sling-scripting-core/pull/8#discussion_r681561449
##
File path:
src/main/java/org/apache/sling/scripting/core/impl/DefaultSlingScript.java
##
@@ -732,7 +735,16 @@ Bindings verifySlingBindings(final SlingBindings
slingBindings) throws IOExcepti
ProtectedBindings protectedBindings = new
ProtectedBindings(bindings, protectedKeys);
for (BindingsValuesProvider provider : bindingsValuesProviders) {
+long start = System.nanoTime();
provider.addBindings(protectedBindings);
+long stop = System.nanoTime();
+LOGGER.trace("Invoking addBindings() of {} took {}
nanoseconds",
+provider.getClass().getName(), stop-start);
+if (stop-start > WARN_LIMIT_FOR_BVP_NANOS) {
+LOGGER.info("Adding the bindings of {} took {}
microseconds; "
Review comment:
nitpick, this message could say "...which is above the built-in limit of
$WARN_LIMIT_FOR_BVP_NANOS"
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (SLING-10689) Extends file must not always generate a Requires-Capability header
[
https://issues.apache.org/jira/browse/SLING-10689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17392170#comment-17392170
]
Radu Cotescu commented on SLING-10689:
--
bq. to support more parameters than just version ... without relying on the
order.
Sure, but my question was more about why should the parser be stricter?
Anyways, I need a bit more time to manage to review your changes - I have some
other pressing things to take care of right now. Are you in a hurry to get this
merged?
> Extends file must not always generate a Requires-Capability header
> --
>
> Key: SLING-10689
> URL: https://issues.apache.org/jira/browse/SLING-10689
> Project: Sling
> Issue Type: Improvement
> Components: Maven Plugins and Archetypes
>Affects Versions: Scripting Bundle Maven Plugin 0.3.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: Scripting Bundle Maven Plugin 0.4.0
>
>
> The {{extends}} file is necessary for bundled scripts as this generates the
> {{extends}} attribute of the {{sling.servlet}} capability (which is the only
> way to express inheritance). Currently the scriptingbundle-maven-plugin
> always also generates an according {{Require-Capability}} header
> (https://sling.apache.org/components/scriptingbundle-maven-plugin/). The
> latter can only be resolved in case the script it extends from is provided as
> bundled script as well, but not if it is a regular resource script. Therefore
> there must be an option in the extends file to not generate the
> Require-Capability header.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [VOTE] Release Apache Sling Feature Analyser 1.3.30
+1 David On Tue, 3 Aug 2021 at 08:42, Karl Pauls wrote: > +1 > > regards, > > Karl > > On Tuesday, August 3, 2021, Carsten Ziegeler wrote: > > > +1 > > > > Carsten > > > > Am 03.08.2021 um 08:16 schrieb Carsten Ziegeler: > > > >> Hi, > >> > >> We solved 1 issue in this release: > >> https://issues.apache.org/jira/browse/SLING-10695 > >> > >> Staging repository: > >> https://repository.apache.org/content/repositories/orgapachesling-2509/ > >> > >> 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 2509 /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 >
Re: [VOTE] Release Apache Sling Feature Analyser 1.3.30
+1 regards, Karl On Tuesday, August 3, 2021, Carsten Ziegeler wrote: > +1 > > Carsten > > Am 03.08.2021 um 08:16 schrieb Carsten Ziegeler: > >> Hi, >> >> We solved 1 issue in this release: >> https://issues.apache.org/jira/browse/SLING-10695 >> >> Staging repository: >> https://repository.apache.org/content/repositories/orgapachesling-2509/ >> >> 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 2509 /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
Re: [VOTE] Release Apache Sling Feature Analyser 1.3.30
+1 Carsten Am 03.08.2021 um 08:16 schrieb Carsten Ziegeler: Hi, We solved 1 issue in this release: https://issues.apache.org/jira/browse/SLING-10695 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2509/ 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 2509 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org -- -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[VOTE] Release Apache Sling Feature Analyser 1.3.30
Hi, We solved 1 issue in this release: https://issues.apache.org/jira/browse/SLING-10695 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2509/ 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 2509 /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
