[GitHub] [sling-org-apache-sling-jms] sonarcloud[bot] commented on pull request #3: SLING-11382: Sling update to 47
sonarcloud[bot] commented on PR #3: URL: https://github.com/apache/sling-org-apache-sling-jms/pull/3#issuecomment-1546475553 Kudos, SonarCloud Quality Gate passed! [](https://sonarcloud.io/dashboard?id=apache_sling-org-apache-sling-jms=3) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-jms=3=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-jms=3=false=BUG) [0 Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-jms=3=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-jms=3=false=VULNERABILITY) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-jms=3=false=VULNERABILITY) [0 Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-jms=3=false=VULNERABILITY) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-jms=3=false=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-jms=3=false=SECURITY_HOTSPOT) [0 Security Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-jms=3=false=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-jms=3=false=CODE_SMELL) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-jms=3=false=CODE_SMELL) [0 Code Smells](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-jms=3=false=CODE_SMELL) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-jms=3=coverage=list) No Coverage information [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-jms=3=new_duplicated_lines_density=list) [0.0% Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-jms=3=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-caconfig-integration-tests] sonarcloud[bot] commented on pull request #1: SLING-11114 update SLING API to 2.21.0
sonarcloud[bot] commented on PR #1: URL: https://github.com/apache/sling-org-apache-sling-caconfig-integration-tests/pull/1#issuecomment-1546468438 Kudos, SonarCloud Quality Gate passed! [](https://sonarcloud.io/dashboard?id=apache_sling-org-apache-sling-caconfig-integration-tests=1) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-caconfig-integration-tests=1=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-caconfig-integration-tests=1=false=BUG) [0 Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-caconfig-integration-tests=1=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-caconfig-integration-tests=1=false=VULNERABILITY) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-caconfig-integration-tests=1=false=VULNERABILITY) [0 Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-caconfig-integration-tests=1=false=VULNERABILITY) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-caconfig-integration-tests=1=false=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-caconfig-integration-tests=1=false=SECURITY_HOTSPOT) [0 Security Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-caconfig-integration-tests=1=false=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-caconfig-integration-tests=1=false=CODE_SMELL) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-caconfig-integration-tests=1=false=CODE_SMELL) [0 Code Smells](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-caconfig-integration-tests=1=false=CODE_SMELL) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-caconfig-integration-tests=1) No Coverage information [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-caconfig-integration-tests=1=new_duplicated_lines_density=list) [0.0% Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-caconfig-integration-tests=1=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
[jira] [Commented] (SLING-11871) Referrer Filter - Enable Bypass for Requests with Origin Header
[ https://issues.apache.org/jira/browse/SLING-11871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722287#comment-17722287 ] Dan Klco commented on SLING-11871: -- Correct [~cziegeler], this would only apply for modification requests. [~kwin] Good question. Reviewing the issue, I think SLING-9061 makes more sense than this change with an addition of a service factory for ReferrerFilter configuration amendments. The reason being conflicts between vendor provided base configurations and end-users need to customize the allowed hosts. Since this configuration is a singleton, it's not possible for an end user to customize this component without overriding the default configuration. Here's another PR with this: https://github.com/apache/sling-org-apache-sling-security/pull/9 > Referrer Filter - Enable Bypass for Requests with Origin Header > --- > > Key: SLING-11871 > URL: https://issues.apache.org/jira/browse/SLING-11871 > Project: Sling > Issue Type: Improvement > Components: Sling Security >Affects Versions: Security 1.1.24 >Reporter: Dan Klco >Assignee: Dan Klco >Priority: Major > Fix For: Security 1.1.26 > > > The Referrer Filter in Apache Sling Security blocks requests without a > Referrer or a non-allow listed Referrer. Therefore Referrer filter will also > block external CORS requests which rather than using the Referrer, like > standard browser requests, use the Origin header. > We should therefore enable bypassing the ReferrerFilter for requests > containing an Origin header. These requests would need to be separately > validated by something else to ensure the Origin is valid. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-9061) Evaluate ORIGIN header in addition to Referer header in ReferrerFilter
[ https://issues.apache.org/jira/browse/SLING-9061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722288#comment-17722288 ] Dan Klco commented on SLING-9061: - Potential PR https://github.com/apache/sling-org-apache-sling-security/pull/9 > Evaluate ORIGIN header in addition to Referer header in ReferrerFilter > -- > > Key: SLING-9061 > URL: https://issues.apache.org/jira/browse/SLING-9061 > Project: Sling > Issue Type: Improvement > Components: Extensions >Affects Versions: Security 1.1.16 >Reporter: Konrad Windszus >Priority: Major > > As discussed in > https://issues.apache.org/jira/browse/SLING-9043?focusedCommentId=17031442=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17031442 > the origin header should be used to implement some CSRF protection. See also > https://owasp.org/www-project-cheat-sheets/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#verifying-origin-with-standard-headers, > https://seclab.stanford.edu/websec/csrf/csrf.pdf and > https://www.sjoerdlangkemper.nl/2019/02/27/prevent-csrf-with-the-origin-http-request-header/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [sling-org-apache-sling-security] sonarcloud[bot] commented on pull request #9: SLING-9061 - Adding support for evaluating the origin as well as the referrer and pluggable referrer configura
sonarcloud[bot] commented on PR #9: URL: https://github.com/apache/sling-org-apache-sling-security/pull/9#issuecomment-1546300954 Kudos, SonarCloud Quality Gate passed! [](https://sonarcloud.io/dashboard?id=apache_sling-org-apache-sling-security=9) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-security=9=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-security=9=false=BUG) [0 Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-security=9=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-security=9=false=VULNERABILITY) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-security=9=false=VULNERABILITY) [0 Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-security=9=false=VULNERABILITY) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-security=9=false=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-security=9=false=SECURITY_HOTSPOT) [0 Security Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-security=9=false=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-security=9=false=CODE_SMELL) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-security=9=false=CODE_SMELL) [0 Code Smells](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-security=9=false=CODE_SMELL) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-security=9=new_coverage=list) [93.8% Coverage](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-security=9=new_coverage=list) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-security=9=new_duplicated_lines_density=list) [0.0% Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-security=9=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-testing-jcr-mock] sonarcloud[bot] commented on pull request #23: SLING-11874 auto-set created/lastModified prop values when appropriate
sonarcloud[bot] commented on PR #23: URL: https://github.com/apache/sling-org-apache-sling-testing-jcr-mock/pull/23#issuecomment-1546282585 Kudos, SonarCloud Quality Gate passed! [](https://sonarcloud.io/dashboard?id=apache_sling-org-apache-sling-testing-jcr-mock=23) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-testing-jcr-mock=23=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-testing-jcr-mock=23=false=BUG) [0 Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-testing-jcr-mock=23=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-testing-jcr-mock=23=false=VULNERABILITY) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-testing-jcr-mock=23=false=VULNERABILITY) [0 Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-testing-jcr-mock=23=false=VULNERABILITY) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-testing-jcr-mock=23=false=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-testing-jcr-mock=23=false=SECURITY_HOTSPOT) [0 Security Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-testing-jcr-mock=23=false=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-testing-jcr-mock=23=false=CODE_SMELL) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-testing-jcr-mock=23=false=CODE_SMELL) [0 Code Smells](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-testing-jcr-mock=23=false=CODE_SMELL) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-testing-jcr-mock=23=new_coverage=list) [87.9% Coverage](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-testing-jcr-mock=23=new_coverage=list) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-testing-jcr-mock=23=new_duplicated_lines_density=list) [0.0% Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-testing-jcr-mock=23=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-testing-jcr-mock] enapps-enorman opened a new pull request, #23: SLING-11874 auto-set created/lastModified prop values when appropriate
enapps-enorman opened a new pull request, #23: URL: https://github.com/apache/sling-org-apache-sling-testing-jcr-mock/pull/23 MockNode should auto-set system generated value if the specified property definition is known to expect it. This should happen in the addNode and the addMixin methods. Specifically the jcr:created, jcr:createdBy, jcr:lastModified and jcr:lastModifiedBy properties should be assign generated values when appropriate. -- 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-11874) MockNode should auto-set created/lastModified prop values when appropriate
Eric Norman created SLING-11874: --- Summary: MockNode should auto-set created/lastModified prop values when appropriate Key: SLING-11874 URL: https://issues.apache.org/jira/browse/SLING-11874 Project: Sling Issue Type: Improvement Components: Testing Reporter: Eric Norman Assignee: Eric Norman Fix For: Testing JCR Mock 1.6.10 MockNode should auto-set system generated value if the specified property definition is known to expect it. This should happen in the addNode and the addMixin methods. Specifically the jcr:created, jcr:createdBy, jcr:lastModified and jcr:lastModifiedBy properties should be assign generated values when appropriate. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [sling-org-apache-sling-api] sonarcloud[bot] commented on pull request #40: SLING-11067 extend URIProvider by method returning Optional
sonarcloud[bot] commented on PR #40: URL: https://github.com/apache/sling-org-apache-sling-api/pull/40#issuecomment-1545977904 SonarCloud Quality Gate failed. [](https://sonarcloud.io/dashboard?id=apache_sling-org-apache-sling-api=40) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=40=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=40=false=BUG) [0 Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=40=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=40=false=VULNERABILITY) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=40=false=VULNERABILITY) [0 Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=40=false=VULNERABILITY) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-api=40=false=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-api=40=false=SECURITY_HOTSPOT) [0 Security Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-api=40=false=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=40=false=CODE_SMELL) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=40=false=CODE_SMELL) [2 Code Smells](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=40=false=CODE_SMELL) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-api=40=new_coverage=list) [0.0% Coverage](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-api=40=new_coverage=list) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-api=40=new_duplicated_lines_density=list) [0.0% Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-api=40=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
[jira] [Commented] (SLING-11871) Referrer Filter - Enable Bypass for Requests with Origin Header
[ https://issues.apache.org/jira/browse/SLING-11871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1773#comment-1773 ] Konrad Windszus commented on SLING-11871: - Why not implementing a real validation instead of just skipping as proposed in SLING-9061? > Referrer Filter - Enable Bypass for Requests with Origin Header > --- > > Key: SLING-11871 > URL: https://issues.apache.org/jira/browse/SLING-11871 > Project: Sling > Issue Type: Improvement > Components: Sling Security >Affects Versions: Security 1.1.24 >Reporter: Dan Klco >Assignee: Dan Klco >Priority: Major > Fix For: Security 1.1.26 > > > The Referrer Filter in Apache Sling Security blocks requests without a > Referrer or a non-allow listed Referrer. Therefore Referrer filter will also > block external CORS requests which rather than using the Referrer, like > standard browser requests, use the Origin header. > We should therefore enable bypassing the ReferrerFilter for requests > containing an Origin header. These requests would need to be separately > validated by something else to ensure the Origin is valid. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-11865) Conversion fails when initial content document does not include namespace declaration
[
https://issues.apache.org/jira/browse/SLING-11865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu resolved SLING-11865.
-
Fix Version/s: (was: Content-Package to Feature Model Converter 1.3.4)
Resolution: Won't Fix
Not going ahead with this for now. It is indeed possible to provide default
mappings, in case the bundle does not have them. An example (when embedding the
converter via the Java API) is at
https://github.com/adobe/aemanalyser-maven-plugin/pull/205/commits/7454c25f0360624e8bcd72c740785ed55b49d94a
.
> Conversion fails when initial content document does not include namespace
> declaration
> -
>
> Key: SLING-11865
> URL: https://issues.apache.org/jira/browse/SLING-11865
> Project: Sling
> Issue Type: Bug
> Components: Content-Package to Feature Model Converter
>Affects Versions: Content-Package to Feature Model Converter 1.3.2
>Reporter: Robert Munteanu
>Priority: Critical
>
> I tried upgrading the AEM Analyser project to version 1.3.2 of the CP
> Converter, but that detected a regression ( see
> [https://github.com/adobe/aemanalyser-maven-plugin/pull/205] ). The failure
> message is
> > Failed to execute goal
> > com.adobe.aem:aemanalyser-maven-plugin:1.5.9-SNAPSHOT:project-analyse
> > (aem-analyser) on project
> > aemanalyser-maven-plugin-it-content-package-files-test: Content Package
> > Converter Exception Can not convert
> > /tmp/cp2fm-converter16836453237918368470/SLING-INF/apps/my-first-node.xml
> > to enhanced DocView format: javax.jcr.NamespaceException: No URI for prefix
> > 'cq' declared. -> [Help 1]
> The file, as extracted from the bundle, is
> {code:xml}
>
>
>
>
> nt:unstructured
>
> title
> String
> My first node
>
>
> description
> String
> This node has been created by a sling bundle.
>
>
>
> cq:EditConfig
> cq:EditConfig
>
> description
> String
> Some dummy data from sling initial content.
>
>
>
> cq:listeners
> cq:EditListenersConfig
>
> description
> String
> Some dummy data from sling initial content.
>
>
>
>
>
>
>
> graniteComponent
> granite:Component
> sling:Folder
>
> granite:data
> nt:unstructured
>
> description
> String
> Some dummy data from sling initial content.
>
>
>
> my:subnode
> nt:unstructured
>
> description
> String
> Some dummy data from sling initial content.
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11871) Referrer Filter - Enable Bypass for Requests with Origin Header
[ https://issues.apache.org/jira/browse/SLING-11871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722210#comment-17722210 ] Carsten Ziegeler commented on SLING-11871: -- I might be misreading the code in the filter, but doesn't the filter only block if it a modification request? > Referrer Filter - Enable Bypass for Requests with Origin Header > --- > > Key: SLING-11871 > URL: https://issues.apache.org/jira/browse/SLING-11871 > Project: Sling > Issue Type: Improvement > Components: Sling Security >Affects Versions: Security 1.1.24 >Reporter: Dan Klco >Assignee: Dan Klco >Priority: Major > Fix For: Security 1.1.26 > > > The Referrer Filter in Apache Sling Security blocks requests without a > Referrer or a non-allow listed Referrer. Therefore Referrer filter will also > block external CORS requests which rather than using the Referrer, like > standard browser requests, use the Origin header. > We should therefore enable bypassing the ReferrerFilter for requests > containing an Origin header. These requests would need to be separately > validated by something else to ensure the Origin is valid. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (SLING-11871) Referrer Filter - Enable Bypass for Requests with Origin Header
[ https://issues.apache.org/jira/browse/SLING-11871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722210#comment-17722210 ] Carsten Ziegeler edited comment on SLING-11871 at 5/12/23 3:28 PM: --- I might be misreading the code in the filter, but doesn't the filter only block if it is a modification request? was (Author: cziegeler): I might be misreading the code in the filter, but doesn't the filter only block if it a modification request? > Referrer Filter - Enable Bypass for Requests with Origin Header > --- > > Key: SLING-11871 > URL: https://issues.apache.org/jira/browse/SLING-11871 > Project: Sling > Issue Type: Improvement > Components: Sling Security >Affects Versions: Security 1.1.24 >Reporter: Dan Klco >Assignee: Dan Klco >Priority: Major > Fix For: Security 1.1.26 > > > The Referrer Filter in Apache Sling Security blocks requests without a > Referrer or a non-allow listed Referrer. Therefore Referrer filter will also > block external CORS requests which rather than using the Referrer, like > standard browser requests, use the Origin header. > We should therefore enable bypassing the ReferrerFilter for requests > containing an Origin header. These requests would need to be separately > validated by something else to ensure the Origin is valid. -- This message was sent by Atlassian Jira (v8.20.10#820010)
RE: Automatically build on ASF Jenkins with Java 11/17 on Linux/Windows
robert detected a bigger number of builds failing with those new defaults (~90) - but after looking on the list of failures it seems to me that most of them affect modules not touched for some years, and likely on completely outdated sling-parent pom. only a few current ones have issues with Java 17. in my POV it's fine to switch the defaults now, and afterwards look into the failing tests and fix the relevant ones. stefan > -Original Message- > From: Konrad Windszus > Sent: Friday, May 12, 2023 2:24 PM > To: dev@sling.apache.org > Subject: Automatically build on ASF Jenkins with Java 11/17 on > Linux/Windows > > Hi, > Currently we still build by default all our modules with Java 8 on Linux > only [1]. > In SLING-11843 I proposed to change the default to Java 11 and 17 with > Linux and Windows. > The default build (i.e. the one which deploys the Snapshot) would be Java > 11 on Linux. > > As there were some concerns raised that multiple builds may break due to > this change I would like to hear if there are any objections to raise the > default CI build in the proposed way. > In my opinion every maintained Sling module should build nowadays with > Java 11 and 17 on both Linux and Windows (to ease contributions). > All other failing modules either need to be fixes accordingly or > deprecated. > > Thanks in advance for your opinions, > Konrad > > > [1] - > https://cwiki.apache.org/confluence/display/SLING/Sling+module+descriptor# > Slingmoduledescriptor-DefaultValues > [2] - https://issues.apache.org/jira/browse/SLING-11843
Re: SLING-11865 - Conversion fails when initial content document does not include namespace declaration
On 12.05.2023 15:48, Robert Munteanu wrote:
On Mon, 2023-05-08 at 18:27 +0200, Konrad Windszus wrote:
Another option would probably be to pass parameters to cp2fm for
declaring additional namespaces.
Then downstream consumers could declare additional ones like “cq” and
those would have known URLs then which would be taken into account
for FileVault serialisation.
Right, I'll give this a shot. With no one being enthusiastic about the
workaround I would at least try and keep the fix clean.
In case anyone is curious, the downstream work for this is at
https://github.com/adobe/aemanalyser-maven-plugin/pull/205
Thanks,
Robert
If this covers most of the use cases this really seems like a good
approach ("fix early").
Thanks for picking this up, Robert.
Best regards, Julian
Re: SLING-11865 - Conversion fails when initial content document does not include namespace declaration
On Mon, 2023-05-08 at 18:27 +0200, Konrad Windszus wrote: > Another option would probably be to pass parameters to cp2fm for > declaring additional namespaces. > Then downstream consumers could declare additional ones like “cq” and > those would have known URLs then which would be taken into account > for FileVault serialisation. Right, I'll give this a shot. With no one being enthusiastic about the workaround I would at least try and keep the fix clean. In case anyone is curious, the downstream work for this is at https://github.com/adobe/aemanalyser-maven-plugin/pull/205 Thanks, Robert
Re: [VOTE] Release Apache Sling API 2.27.2
+1 On Fri, May 12, 2023 at 6:14 AM Robert Munteanu wrote: > > On Fri, 2023-05-12 at 09:41 +0300, Jörg Hoh wrote: > > Please vote to approve this release: > > +1 > Robert
[jira] [Updated] (SLING-11843) Change Default JDK/OS for Jenkins Builds to JDK11/17 on Linux/Windows
[ https://issues.apache.org/jira/browse/SLING-11843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated SLING-11843: Summary: Change Default JDK/OS for Jenkins Builds to JDK11/17 on Linux/Windows (was: Change Default JDK/OS for Jenkins Builds to JDK11/17 on Unix/Windows) > Change Default JDK/OS for Jenkins Builds to JDK11/17 on Linux/Windows > - > > Key: SLING-11843 > URL: https://issues.apache.org/jira/browse/SLING-11843 > Project: Sling > Issue Type: Improvement > Components: CI >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Attachments: java11-install-build.log > > > Currently our Jenkins jobs by default only run on JDK8 with Linux. > I would propose to change the default (mentioned in > https://cwiki.apache.org/confluence/display/SLING/Sling+module+descriptor#Slingmoduledescriptor-DefaultValues) > to > * Build with JDK 11 and 17 on > * Windows and Linux > Although this might break some builds, I think it is time now to make all > modules compatible with it once we touch it for whatever reason. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-11843) Change Default JDK/OS for Jenkins Builds to JDK11/17 on Unix/Windows
[ https://issues.apache.org/jira/browse/SLING-11843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722153#comment-17722153 ] Konrad Windszus commented on SLING-11843: - I raised this on the mailing list in https://lists.apache.org/thread/6tgoq2995vhlonrww21n73xpw6gpg4q6. > Change Default JDK/OS for Jenkins Builds to JDK11/17 on Unix/Windows > > > Key: SLING-11843 > URL: https://issues.apache.org/jira/browse/SLING-11843 > Project: Sling > Issue Type: Improvement > Components: CI >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Attachments: java11-install-build.log > > > Currently our Jenkins jobs by default only run on JDK8 with Linux. > I would propose to change the default (mentioned in > https://cwiki.apache.org/confluence/display/SLING/Sling+module+descriptor#Slingmoduledescriptor-DefaultValues) > to > * Build with JDK 11 and 17 on > * Windows and Linux > Although this might break some builds, I think it is time now to make all > modules compatible with it once we touch it for whatever reason. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Automatically build on ASF Jenkins with Java 11/17 on Linux/Windows
Hi, Currently we still build by default all our modules with Java 8 on Linux only [1]. In SLING-11843 I proposed to change the default to Java 11 and 17 with Linux and Windows. The default build (i.e. the one which deploys the Snapshot) would be Java 11 on Linux. As there were some concerns raised that multiple builds may break due to this change I would like to hear if there are any objections to raise the default CI build in the proposed way. In my opinion every maintained Sling module should build nowadays with Java 11 and 17 on both Linux and Windows (to ease contributions). All other failing modules either need to be fixes accordingly or deprecated. Thanks in advance for your opinions, Konrad [1] - https://cwiki.apache.org/confluence/display/SLING/Sling+module+descriptor#Slingmoduledescriptor-DefaultValues [2] - https://issues.apache.org/jira/browse/SLING-11843
[jira] [Commented] (SLING-11843) Change Default JDK/OS for Jenkins Builds to JDK11/17 on Unix/Windows
[ https://issues.apache.org/jira/browse/SLING-11843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722143#comment-17722143 ] Robert Munteanu commented on SLING-11843: - Sounds good to me. [~kwin], do you want to start the discussion, since you've down all the work for this initiative? > Change Default JDK/OS for Jenkins Builds to JDK11/17 on Unix/Windows > > > Key: SLING-11843 > URL: https://issues.apache.org/jira/browse/SLING-11843 > Project: Sling > Issue Type: Improvement > Components: CI >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Attachments: java11-install-build.log > > > Currently our Jenkins jobs by default only run on JDK8 with Linux. > I would propose to change the default (mentioned in > https://cwiki.apache.org/confluence/display/SLING/Sling+module+descriptor#Slingmoduledescriptor-DefaultValues) > to > * Build with JDK 11 and 17 on > * Windows and Linux > Although this might break some builds, I think it is time now to make all > modules compatible with it once we touch it for whatever reason. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-11843) Change Default JDK/OS for Jenkins Builds to JDK11/17 on Unix/Windows
[ https://issues.apache.org/jira/browse/SLING-11843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722140#comment-17722140 ] Stefan Seifert commented on SLING-11843: according to the log the build failed for * sling-org-apache-sling-testing-osgi-mock * sling-org-apache-sling-testing-sling-mock * sling-org-apache-sling-contentparser-testutils by they compile nicely with java 11 on my machine. some of them fail with java 17, though. lof of the others that failed look like modules not touched for a longer time, so likely they use a too old sling-parent. i still would propose to switch the defaults to make this failures easily visible, but of course should discuss this on the list first. > Change Default JDK/OS for Jenkins Builds to JDK11/17 on Unix/Windows > > > Key: SLING-11843 > URL: https://issues.apache.org/jira/browse/SLING-11843 > Project: Sling > Issue Type: Improvement > Components: CI >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Attachments: java11-install-build.log > > > Currently our Jenkins jobs by default only run on JDK8 with Linux. > I would propose to change the default (mentioned in > https://cwiki.apache.org/confluence/display/SLING/Sling+module+descriptor#Slingmoduledescriptor-DefaultValues) > to > * Build with JDK 11 and 17 on > * Windows and Linux > Although this might break some builds, I think it is time now to make all > modules compatible with it once we touch it for whatever reason. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-11843) Change Default JDK/OS for Jenkins Builds to JDK11/17 on Unix/Windows
[ https://issues.apache.org/jira/browse/SLING-11843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722132#comment-17722132 ] Robert Munteanu commented on SLING-11843: - [~sseifert] - I created a reactor pom, for simplicity. Perhaps that leads to additional instability. To find the exact results, search for 'Reactor Summary' in the log file. > Change Default JDK/OS for Jenkins Builds to JDK11/17 on Unix/Windows > > > Key: SLING-11843 > URL: https://issues.apache.org/jira/browse/SLING-11843 > Project: Sling > Issue Type: Improvement > Components: CI >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Attachments: java11-install-build.log > > > Currently our Jenkins jobs by default only run on JDK8 with Linux. > I would propose to change the default (mentioned in > https://cwiki.apache.org/confluence/display/SLING/Sling+module+descriptor#Slingmoduledescriptor-DefaultValues) > to > * Build with JDK 11 and 17 on > * Windows and Linux > Although this might break some builds, I think it is time now to make all > modules compatible with it once we touch it for whatever reason. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-11843) Change Default JDK/OS for Jenkins Builds to JDK11/17 on Unix/Windows
[ https://issues.apache.org/jira/browse/SLING-11843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722130#comment-17722130 ] Stefan Seifert commented on SLING-11843: yes, of course, let's start a discussion on the mailing list. i looked into [^java11-install-build.log] and found only one actual occurrence on "BUILD FAILURE" (and one for the reactor build itself) but nothing abou the other 89 builds - is the logfile incomplete? > Change Default JDK/OS for Jenkins Builds to JDK11/17 on Unix/Windows > > > Key: SLING-11843 > URL: https://issues.apache.org/jira/browse/SLING-11843 > Project: Sling > Issue Type: Improvement > Components: CI >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Attachments: java11-install-build.log > > > Currently our Jenkins jobs by default only run on JDK8 with Linux. > I would propose to change the default (mentioned in > https://cwiki.apache.org/confluence/display/SLING/Sling+module+descriptor#Slingmoduledescriptor-DefaultValues) > to > * Build with JDK 11 and 17 on > * Windows and Linux > Although this might break some builds, I think it is time now to make all > modules compatible with it once we touch it for whatever reason. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[Jenkins] Sling » Modules » sling-org-apache-sling-starter » master #814 is BROKEN
Please see https://ci-builds.apache.org/job/Sling/job/modules/job/sling-org-apache-sling-starter/job/master/814/ for details. No further emails will be sent until the status of the build is changed. Build log follows below: [...truncated 10254 lines...] [INFO] Running org.apache.sling.launchpad.webapp.integrationtest.servlets.post.PostServletAtMoveTest [INFO] Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.56 s - in org.apache.sling.launchpad.webapp.integrationtest.servlets.post.PostServletAtMoveTest [INFO] Running org.apache.sling.launchpad.webapp.integrationtest.teleporter.LdapFilterTeleporterTest [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.474 s - in org.apache.sling.launchpad.webapp.integrationtest.teleporter.LdapFilterTeleporterTest [INFO] Running org.apache.sling.launchpad.webapp.integrationtest.ServletResolverConfigTest [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 s - in org.apache.sling.launchpad.webapp.integrationtest.ServletResolverConfigTest [INFO] Running org.apache.sling.launchpad.webapp.integrationtest.RedirectTest [INFO] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.176 s - in org.apache.sling.launchpad.webapp.integrationtest.RedirectTest [INFO] Running org.apache.sling.launchpad.webapp.integrationtest.EventsCounterTest [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.046 s - in org.apache.sling.launchpad.webapp.integrationtest.EventsCounterTest [INFO] Running org.apache.sling.launchpad.webapp.integrationtest.ExecuteScriptTest [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.38 s - in org.apache.sling.launchpad.webapp.integrationtest.ExecuteScriptTest [INFO] Running org.apache.sling.launchpad.webapp.integrationtest.JavascriptWrappersTest [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.208 s - in org.apache.sling.launchpad.webapp.integrationtest.JavascriptWrappersTest [INFO] Running org.apache.sling.launchpad.webapp.integrationtest.BundleContentTest [INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.041 s - in org.apache.sling.launchpad.webapp.integrationtest.BundleContentTest [INFO] Running org.apache.sling.launchpad.webapp.integrationtest.MkdirTest [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.232 s - in org.apache.sling.launchpad.webapp.integrationtest.MkdirTest [INFO] Running org.apache.sling.launchpad.webapp.integrationtest.servlets.post.PostServletAtDeleteTest [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.155 s - in org.apache.sling.launchpad.webapp.integrationtest.servlets.post.PostServletAtDeleteTest [INFO] Running org.apache.sling.launchpad.webapp.integrationtest.StaticContentTest [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.017 s - in org.apache.sling.launchpad.webapp.integrationtest.StaticContentTest [INFO] Running org.apache.sling.launchpad.webapp.integrationtest.PropertyRenderingTest [INFO] Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.289 s - in org.apache.sling.launchpad.webapp.integrationtest.PropertyRenderingTest [INFO] Running org.apache.sling.launchpad.webapp.integrationtest.VersionParameterTest [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.191 s - in org.apache.sling.launchpad.webapp.integrationtest.VersionParameterTest [INFO] Running org.apache.sling.launchpad.webapp.integrationtest.servlets.resolution.PutMethodServletTest [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.361 s - in org.apache.sling.launchpad.webapp.integrationtest.servlets.resolution.PutMethodServletTest [INFO] Running org.apache.sling.launchpad.webapp.integrationtest.FiltersTest [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 s - in org.apache.sling.launchpad.webapp.integrationtest.FiltersTest [INFO] Running org.apache.sling.launchpad.webapp.integrationtest.repository.RepositoryInitializersTest [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 s - in org.apache.sling.launchpad.webapp.integrationtest.repository.RepositoryInitializersTest [INFO] Running org.apache.sling.launchpad.webapp.integrationtest.repository.RepoinitPathTest [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.216 s - in org.apache.sling.launchpad.webapp.integrationtest.repository.RepoinitPathTest [INFO] Running org.apache.sling.launchpad.webapp.integrationtest.MiscUnsafeTest [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 s - in org.apache.sling.launchpad.webapp.integrationtest.MiscUnsafeTest [INFO] Running org.apache.sling.launchpad.webapp.integrationtest.login.RedirectOnLogoutTest [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 s - in org.apache.sling.launchpad.webapp.integrationtest.login.RedirectOnLogoutTest [INFO]
[jira] [Comment Edited] (SLING-11843) Change Default JDK/OS for Jenkins Builds to JDK11/17 on Unix/Windows
[
https://issues.apache.org/jira/browse/SLING-11843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17717502#comment-17717502
]
Robert Munteanu edited comment on SLING-11843 at 5/12/23 11:16 AM:
---
Later edit: I ran the full Java 11 build with
{{JAVA_HOME=/usr/lib64/jvm/java-11 mvn clean install clean --fail-at-end | tee
java11-install-build.log}} ( clean/install/clean to keep the disk usage sane ).
I've attached it as [^java11-install-build.log] .
After the full build, I see 90 failures and 240 successful builds. I think a
25% failure rate is too high to 'just' enable it. To be sure I didn't miss
anything, I will run the full build with Java 8 as well. But I think we should
at least give a heads-up on dev@sling to allow maintainaners to fix builds in
advance, should they desire to do so.
was (Author: rombert):
Later edit: I ran the full Java 11 build with
{{JAVA_HOME=/usr/lib64/jvm/java-11 mvn clean install clean --fail-at-end | tee
java11-install-build.log}} ( clean/install/clean to keep the disk usage sane ).
I've attached it as [^java11-install-build.log] .
After the full build, I see 90 failures and 240 successful builds. I think a
25% failure rate is too high to 'just' enable it. To be sure I didn't miss
anything, I will run the full build with Java 8 as well. But I think twe should
at least give a heads-up on dev@sling to allow maintainaners to fix builds in
advance, should they desire to do so.
> Change Default JDK/OS for Jenkins Builds to JDK11/17 on Unix/Windows
>
>
> Key: SLING-11843
> URL: https://issues.apache.org/jira/browse/SLING-11843
> Project: Sling
> Issue Type: Improvement
> Components: CI
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Attachments: java11-install-build.log
>
>
> Currently our Jenkins jobs by default only run on JDK8 with Linux.
> I would propose to change the default (mentioned in
> https://cwiki.apache.org/confluence/display/SLING/Sling+module+descriptor#Slingmoduledescriptor-DefaultValues)
> to
> * Build with JDK 11 and 17 on
> * Windows and Linux
> Although this might break some builds, I think it is time now to make all
> modules compatible with it once we touch it for whatever reason.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [sling-org-apache-sling-installer-factory-configuration] sonarcloud[bot] commented on pull request #10: SLING-11864 Move web console plugin
sonarcloud[bot] commented on PR #10: URL: https://github.com/apache/sling-org-apache-sling-installer-factory-configuration/pull/10#issuecomment-1545548018 SonarCloud Quality Gate failed. [](https://sonarcloud.io/dashboard?id=apache_sling-org-apache-sling-installer-factory-configuration=10) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-installer-factory-configuration=10=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-installer-factory-configuration=10=false=BUG) [0 Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-installer-factory-configuration=10=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-installer-factory-configuration=10=false=VULNERABILITY) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-installer-factory-configuration=10=false=VULNERABILITY) [0 Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-installer-factory-configuration=10=false=VULNERABILITY) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-installer-factory-configuration=10=false=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-installer-factory-configuration=10=false=SECURITY_HOTSPOT) [0 Security Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-installer-factory-configuration=10=false=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-installer-factory-configuration=10=false=CODE_SMELL) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-installer-factory-configuration=10=false=CODE_SMELL) [0 Code Smells](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-installer-factory-configuration=10=false=CODE_SMELL) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-installer-factory-configuration=10=new_coverage=list) [2.4% Coverage](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-installer-factory-configuration=10=new_coverage=list) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-installer-factory-configuration=10=new_duplicated_lines_density=list) [0.0% Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-installer-factory-configuration=10=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
[jira] [Commented] (SLING-11864) Configuration merge/default values not considered in OSGi Installer Configuration Printer Web Console
[
https://issues.apache.org/jira/browse/SLING-11864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722111#comment-17722111
]
Konrad Windszus commented on SLING-11864:
-
The new UI looks like this:
!Screenshot 2023-05-12 at 12.42.14.png!
> Configuration merge/default values not considered in OSGi Installer
> Configuration Printer Web Console
> -
>
> Key: SLING-11864
> URL: https://issues.apache.org/jira/browse/SLING-11864
> Project: Sling
> Issue Type: New Feature
> Components: Installer
>Affects Versions: Installer Console 1.1.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: Installer Console 1.1.2, Installer Configuration Factory
> 1.4.4
>
> Attachments: Screenshot 2023-05-10 at 17.34.44.png, Screenshot
> 2023-05-12 at 12.42.14.png
>
>
> Despite
> https://sling.apache.org/documentation/bundles/configuration-installer-factory.html#merging-of-configurations
> stating that
> bq. Similar, for write back and the OSGi Installer Configuration Printer Web
> Console only the properties with different configuration values than the
> default configuration are written back/exposed.
> I still see all values which differ from the metatype default value being
> exposed at {{/system/console/osgi-installer-config-printer}}. I tried with a
> distribution which has two configurations
> {code}
> * org.apache.jackrabbit.vault.packaging.impl.PackagingImpl:
> 2a425da9bfe3907800abf828d7dba911/200,
> jcrinstall:/apps/system/config/org.apache.jackrabbit.vault.packaging.impl.PackagingImpl.cfg.json,
> INSTALLED,
> - 311121c892dc31cecae4b5844a5855e9/50,
> launchpad:resources/config/org.apache.jackrabbit.vault.packaging.impl.PackagingImpl.config,
> INSTALL, Another resource with the same entity id but a higher version or
> priority or digest found (in that order, the latter only in case the version
> is a SNAPSHOT)!
> {code}
> and framework property {{sling.installer.config.mergeSchemes = launchpad}}.
> Still values from both sources are exposed at
> {{/system/console/osgi-installer-config-printer?pid=org.apache.jackrabbit.vault.packaging.impl.PackagingImpl=JSON}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-11864) Configuration merge/default values not considered in OSGi Installer Configuration Printer Web Console
[
https://issues.apache.org/jira/browse/SLING-11864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-11864:
Attachment: Screenshot 2023-05-12 at 12.42.14.png
> Configuration merge/default values not considered in OSGi Installer
> Configuration Printer Web Console
> -
>
> Key: SLING-11864
> URL: https://issues.apache.org/jira/browse/SLING-11864
> Project: Sling
> Issue Type: New Feature
> Components: Installer
>Affects Versions: Installer Console 1.1.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: Installer Console 1.1.2, Installer Configuration Factory
> 1.4.4
>
> Attachments: Screenshot 2023-05-10 at 17.34.44.png, Screenshot
> 2023-05-12 at 12.42.14.png
>
>
> Despite
> https://sling.apache.org/documentation/bundles/configuration-installer-factory.html#merging-of-configurations
> stating that
> bq. Similar, for write back and the OSGi Installer Configuration Printer Web
> Console only the properties with different configuration values than the
> default configuration are written back/exposed.
> I still see all values which differ from the metatype default value being
> exposed at {{/system/console/osgi-installer-config-printer}}. I tried with a
> distribution which has two configurations
> {code}
> * org.apache.jackrabbit.vault.packaging.impl.PackagingImpl:
> 2a425da9bfe3907800abf828d7dba911/200,
> jcrinstall:/apps/system/config/org.apache.jackrabbit.vault.packaging.impl.PackagingImpl.cfg.json,
> INSTALLED,
> - 311121c892dc31cecae4b5844a5855e9/50,
> launchpad:resources/config/org.apache.jackrabbit.vault.packaging.impl.PackagingImpl.config,
> INSTALL, Another resource with the same entity id but a higher version or
> priority or digest found (in that order, the latter only in case the version
> is a SNAPSHOT)!
> {code}
> and framework property {{sling.installer.config.mergeSchemes = launchpad}}.
> Still values from both sources are exposed at
> {{/system/console/osgi-installer-config-printer?pid=org.apache.jackrabbit.vault.packaging.impl.PackagingImpl=JSON}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [sling-org-apache-sling-installer-factory-configuration] sonarcloud[bot] commented on pull request #10: SLING-11864 Move web console plugin
sonarcloud[bot] commented on PR #10: URL: https://github.com/apache/sling-org-apache-sling-installer-factory-configuration/pull/10#issuecomment-1545544337 SonarCloud Quality Gate failed. [](https://sonarcloud.io/dashboard?id=apache_sling-org-apache-sling-installer-factory-configuration=10) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-installer-factory-configuration=10=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-installer-factory-configuration=10=false=BUG) [0 Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-installer-factory-configuration=10=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-installer-factory-configuration=10=false=VULNERABILITY) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-installer-factory-configuration=10=false=VULNERABILITY) [0 Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-installer-factory-configuration=10=false=VULNERABILITY) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-installer-factory-configuration=10=false=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-installer-factory-configuration=10=false=SECURITY_HOTSPOT) [0 Security Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-installer-factory-configuration=10=false=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-installer-factory-configuration=10=false=CODE_SMELL) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-installer-factory-configuration=10=false=CODE_SMELL) [0 Code Smells](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-installer-factory-configuration=10=false=CODE_SMELL) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-installer-factory-configuration=10=new_coverage=list) [2.4% Coverage](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-installer-factory-configuration=10=new_coverage=list) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-installer-factory-configuration=10=new_duplicated_lines_density=list) [0.0% Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-installer-factory-configuration=10=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-testing-sling-mock-oak] sonarcloud[bot] commented on pull request #8: SLING-11873 sling-mock-oak: Improve oak-jcr dependency exclusions
sonarcloud[bot] commented on PR #8: URL: https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/pull/8#issuecomment-1545531669 Kudos, SonarCloud Quality Gate passed! [](https://sonarcloud.io/dashboard?id=apache_sling-org-apache-sling-testing-sling-mock-oak=8) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-testing-sling-mock-oak=8=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-testing-sling-mock-oak=8=false=BUG) [0 Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-testing-sling-mock-oak=8=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-testing-sling-mock-oak=8=false=VULNERABILITY) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-testing-sling-mock-oak=8=false=VULNERABILITY) [0 Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-testing-sling-mock-oak=8=false=VULNERABILITY) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-testing-sling-mock-oak=8=false=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-testing-sling-mock-oak=8=false=SECURITY_HOTSPOT) [0 Security Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-testing-sling-mock-oak=8=false=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-testing-sling-mock-oak=8=false=CODE_SMELL) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-testing-sling-mock-oak=8=false=CODE_SMELL) [0 Code Smells](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-testing-sling-mock-oak=8=false=CODE_SMELL) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-testing-sling-mock-oak=8=coverage=list) No Coverage information [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-testing-sling-mock-oak=8=new_duplicated_lines_density=list) [0.0% Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-testing-sling-mock-oak=8=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
[jira] [Created] (SLING-11873) sling-mock-oak: Improve oak-jcr dependency exclusions
Stefan Seifert created SLING-11873:
--
Summary: sling-mock-oak: Improve oak-jcr dependency exclusions
Key: SLING-11873
URL: https://issues.apache.org/jira/browse/SLING-11873
Project: Sling
Issue Type: Improvement
Components: Testing
Reporter: Stefan Seifert
Assignee: Stefan Seifert
Fix For: Testing Sling Mock Oak 3.1.10-1.44.0
* we do no longer need to exclude {{org.apache.jackrabbit:jackrabbit-api}} as
the oak-jcr we are using is no longer pulling that in
* instead, we should exclude a couple of OSGi annotation and similar
dependencies which should not be compile dependencies
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [VOTE] Release Apache Sling API 2.27.2
On Fri, 2023-05-12 at 09:41 +0300, Jörg Hoh wrote: > Please vote to approve this release: +1 Robert signature.asc Description: This is a digitally signed message part
Re: Starter ITs failing when updating to the latest Apache Felix HTTP 4.x
Thanks for the context, Carsten. I've filed https://issues.apache.org/jira/browse/SLING-11872 so that the information is located in a single place, whenever someone has the time to look into it. I was hoping this would be more of a quick fix, but it looks like it needs a bit more attention. Thanks, Robert On Fri, 2023-05-12 at 10:49 +0200, Carsten Ziegeler wrote: > I think the solution here is to do the same in Sling Engine as Apache > Felix is doing: instead of setting the attributes on the request, > overwriting the getAttribute method. This avoids leakage of > information > as well. > > Regards > Carsten > > On 04.05.2023 12:45, Carsten Ziegeler wrote: > > My best guess is that it is due to this new code in 4.2.0: > > > > https://github.com/apache/felix-dev/blob/http-4.x/http/base/src/main/java/org/apache/felix/http/base/internal/dispatch/ServletRequestWrapper.java#L166 > > > > Regards > > Carsten > > > > On 04.05.2023 10:46, Carsten Ziegeler wrote: > > > I don't really have a very helpful reply. I'm not aware of > > > changes in > > > this area. As far as I remember, the attributes are set by the > > > http > > > base implementation. I'm also not sure what the IncludeTest is > > > actually testing; is it testing a Sling include or a servlet > > > include? > > > Http base has tests for the includes andh whether the attribute > > > is set. > > > > > > I fear the only way to figure out what is going on is debugging > > > the > > > test run and see what happens (or not happens). > > > > > > Regards > > > Carsten > > > > > > On 04.05.2023 09:50, Robert Munteanu wrote: > > > > Hi, > > > > > > > > I am looking at a renovate PR [1] that updates > > > > org.apache.felix:org.apache.felix.http.jetty from 4.1.14 to > > > > 4.2.10 and > > > > org.apache.felix:org.apache.felix.http.servlet-api from 1.1.4 > > > > to 1.2.0 > > > > . > > > > > > > > There are 3 failures in the IncludeIT that show that the > > > > javax.servlet.include.request_uri attribute is no longer > > > > present: > > > > > > > > [ERROR] Failures: > > > > [ERROR] > > > > IncludeTest.testForcedResourceType:149- > > > > >assertIncludeRequestAttributes:154- > > > > >assertIncludeRequestAttributes:167->assertRequestAttribute:189 > > > > Expected content contains '--javax.servlet.include.request_uri- > > > > ' > > > > [ERROR] > > > > IncludeTest.testWithInclude:114- > > > > >assertIncludeRequestAttributes:154- > > > > >assertIncludeRequestAttributes:167->assertRequestAttribute:189 > > > > Expected content contains '--javax.servlet.include.request_uri- > > > > ' > > > > [ERROR] > > > > IncludeTest.testWithIncludeAndExtension:123- > > > > >assertIncludeRequestAttributes:154- > > > > >assertIncludeRequestAttributes:167->assertRequestAttribute:189 > > > > Expected content contains '--javax.servlet.include.request_uri- > > > > ' > > > > > > > > The test failures happen with version 4.2.0 as well, so this > > > > has > > > > something to do with the minor version bump. Looking at the > > > > Felix > > > > changelog [2] this could be related to supporting the Servlet > > > > API 4.0 > > > > [3], but I didn't manage to figure out what is going on. > > > > > > > > If anyone has an idea about how to make this progress, please > > > > share, > > > > I'm out of ideas at the moment. > > > > > > > > Thanks, > > > > Robert > > > > > > > > [1]: > > > > https://github.com/apache/sling-org-apache-sling-starter/pull/142 > > > > [2]: > > > > https://issues.apache.org/jira/projects/FELIX/versions/12351176 > > > > [3]: https://issues.apache.org/jira/browse/FELIX-6498 > > > > > > > > > >
[jira] [Updated] (SLING-11872) Some request attributes not set when running with Felix Jetty 4.2.x
[ https://issues.apache.org/jira/browse/SLING-11872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-11872: Description: When updating the Sling Starter org.apache.felix:org.apache.felix.http.jetty from 4.1.14 to 4.2.10 and org.apache.felix:org.apache.felix.http.servlet-api from 1.1.4 to 1.2.0 . There are 3 failures in the IncludeIT that show that the javax.servlet.include.request_uri attribute is no longer present: [ERROR] Failures: [ERROR] IncludeTest.testForcedResourceType:149->assertIncludeRequestAttributes:154->assertIncludeRequestAttributes:167->assertRequestAttribute:189 Expected content contains '--javax.servlet.include.request_uri-' [ERROR] IncludeTest.testWithInclude:114->assertIncludeRequestAttributes:154->assertIncludeRequestAttributes:167->assertRequestAttribute:189 Expected content contains '--javax.servlet.include.request_uri-' [ERROR] IncludeTest.testWithIncludeAndExtension:123->assertIncludeRequestAttributes:154->assertIncludeRequestAttributes:167->assertRequestAttribute:189 Expected content contains '--javax.servlet.include.request_uri-' [~cziegeler] thinks this is due to new code in 4.2.0 https://github.com/apache/felix-dev/blob/http-4.x/http/base/src/main/java/org/apache/felix/http/base/internal/dispatch/ServletRequestWrapper.java#L166 and that the solution here is to do the same in Sling Engine as Apache Felix is doing: instead of setting the attributes on the request, overwriting the getAttribute method. This avoids leakage of information as well. See also the dev@sling.apache.org discussion at https://lists.apache.org/thread/wbfs0bvv0yk8nhggtx969nxwjyxs3c1o . was: When updating the Sling Starter org.apache.felix:org.apache.felix.http.jetty from 4.1.14 to 4.2.10 and org.apache.felix:org.apache.felix.http.servlet-api from 1.1.4 to 1.2.0 . There are 3 failures in the IncludeIT that show that the javax.servlet.include.request_uri attribute is no longer present: [ERROR] Failures: [ERROR] IncludeTest.testForcedResourceType:149->assertIncludeRequestAttributes:154->assertIncludeRequestAttributes:167->assertRequestAttribute:189 Expected content contains '--javax.servlet.include.request_uri-' [ERROR] IncludeTest.testWithInclude:114->assertIncludeRequestAttributes:154->assertIncludeRequestAttributes:167->assertRequestAttribute:189 Expected content contains '--javax.servlet.include.request_uri-' [ERROR] IncludeTest.testWithIncludeAndExtension:123->assertIncludeRequestAttributes:154->assertIncludeRequestAttributes:167->assertRequestAttribute:189 Expected content contains '--javax.servlet.include.request_uri-' [~cziegeler] thinks this is due to new code in 4.2.0 https://github.com/apache/felix-dev/blob/http-4.x/http/base/src/main/java/org/apache/felix/http/base/internal/dispatch/ServletRequestWrapper.java#L166 and that the solution here is to do the same in Sling Engine as Apache Felix is doing: instead of setting the attributes on the request, overwriting the getAttribute method. This avoids leakage of information as well. > Some request attributes not set when running with Felix Jetty 4.2.x > --- > > Key: SLING-11872 > URL: https://issues.apache.org/jira/browse/SLING-11872 > Project: Sling > Issue Type: Bug > Components: Engine >Reporter: Robert Munteanu >Priority: Major > Fix For: Engine 2.15.0 > > > When updating the Sling Starter > org.apache.felix:org.apache.felix.http.jetty from 4.1.14 to 4.2.10 and > org.apache.felix:org.apache.felix.http.servlet-api from 1.1.4 to 1.2.0 > . > There are 3 failures in the IncludeIT that show that the > javax.servlet.include.request_uri attribute is no longer present: > [ERROR] Failures: > [ERROR] > IncludeTest.testForcedResourceType:149->assertIncludeRequestAttributes:154->assertIncludeRequestAttributes:167->assertRequestAttribute:189 > Expected content contains '--javax.servlet.include.request_uri-' > [ERROR] > IncludeTest.testWithInclude:114->assertIncludeRequestAttributes:154->assertIncludeRequestAttributes:167->assertRequestAttribute:189 > Expected content contains '--javax.servlet.include.request_uri-' > [ERROR] > IncludeTest.testWithIncludeAndExtension:123->assertIncludeRequestAttributes:154->assertIncludeRequestAttributes:167->assertRequestAttribute:189 > Expected content contains '--javax.servlet.include.request_uri-' > [~cziegeler] thinks this is due to new code in 4.2.0 > https://github.com/apache/felix-dev/blob/http-4.x/http/base/src/main/java/org/apache/felix/http/base/internal/dispatch/ServletRequestWrapper.java#L166 > and that the solution here is to do the same in Sling Engine as Apache > Felix is doing: instead of setting the attributes on the request, > overwriting the getAttribute method. This avoids
[jira] [Created] (SLING-11872) Some request attributes not set when running with Felix Jetty 4.2.x
Robert Munteanu created SLING-11872: --- Summary: Some request attributes not set when running with Felix Jetty 4.2.x Key: SLING-11872 URL: https://issues.apache.org/jira/browse/SLING-11872 Project: Sling Issue Type: Bug Components: Engine Reporter: Robert Munteanu Fix For: Engine 2.15.0 When updating the Sling Starter org.apache.felix:org.apache.felix.http.jetty from 4.1.14 to 4.2.10 and org.apache.felix:org.apache.felix.http.servlet-api from 1.1.4 to 1.2.0 . There are 3 failures in the IncludeIT that show that the javax.servlet.include.request_uri attribute is no longer present: [ERROR] Failures: [ERROR] IncludeTest.testForcedResourceType:149->assertIncludeRequestAttributes:154->assertIncludeRequestAttributes:167->assertRequestAttribute:189 Expected content contains '--javax.servlet.include.request_uri-' [ERROR] IncludeTest.testWithInclude:114->assertIncludeRequestAttributes:154->assertIncludeRequestAttributes:167->assertRequestAttribute:189 Expected content contains '--javax.servlet.include.request_uri-' [ERROR] IncludeTest.testWithIncludeAndExtension:123->assertIncludeRequestAttributes:154->assertIncludeRequestAttributes:167->assertRequestAttribute:189 Expected content contains '--javax.servlet.include.request_uri-' [~cziegeler] thinks this is due to new code in 4.2.0 https://github.com/apache/felix-dev/blob/http-4.x/http/base/src/main/java/org/apache/felix/http/base/internal/dispatch/ServletRequestWrapper.java#L166 and that the solution here is to do the same in Sling Engine as Apache Felix is doing: instead of setting the attributes on the request, overwriting the getAttribute method. This avoids leakage of information as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [sling-org-apache-sling-starter] rombert commented on pull request #142: chore(deps): update apache felix http
rombert commented on PR #142: URL: https://github.com/apache/sling-org-apache-sling-starter/pull/142#issuecomment-1545509744 This is blocked on SLING-11872 . -- 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
RE: [VOTE] Release Apache Sling API 2.27.2
+1 stefan
[jira] [Commented] (SLING-11864) Configuration merge/default values not considered in OSGi Installer Configuration Printer Web Console
[
https://issues.apache.org/jira/browse/SLING-11864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722092#comment-17722092
]
Carsten Ziegeler commented on SLING-11864:
--
I think that makes sense to also exclude them
> Configuration merge/default values not considered in OSGi Installer
> Configuration Printer Web Console
> -
>
> Key: SLING-11864
> URL: https://issues.apache.org/jira/browse/SLING-11864
> Project: Sling
> Issue Type: New Feature
> Components: Installer
>Affects Versions: Installer Console 1.1.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: Installer Console 1.1.2, Installer Configuration Factory
> 1.4.4
>
> Attachments: Screenshot 2023-05-10 at 17.34.44.png
>
>
> Despite
> https://sling.apache.org/documentation/bundles/configuration-installer-factory.html#merging-of-configurations
> stating that
> bq. Similar, for write back and the OSGi Installer Configuration Printer Web
> Console only the properties with different configuration values than the
> default configuration are written back/exposed.
> I still see all values which differ from the metatype default value being
> exposed at {{/system/console/osgi-installer-config-printer}}. I tried with a
> distribution which has two configurations
> {code}
> * org.apache.jackrabbit.vault.packaging.impl.PackagingImpl:
> 2a425da9bfe3907800abf828d7dba911/200,
> jcrinstall:/apps/system/config/org.apache.jackrabbit.vault.packaging.impl.PackagingImpl.cfg.json,
> INSTALLED,
> - 311121c892dc31cecae4b5844a5855e9/50,
> launchpad:resources/config/org.apache.jackrabbit.vault.packaging.impl.PackagingImpl.config,
> INSTALL, Another resource with the same entity id but a higher version or
> priority or digest found (in that order, the latter only in case the version
> is a SNAPSHOT)!
> {code}
> and framework property {{sling.installer.config.mergeSchemes = launchpad}}.
> Still values from both sources are exposed at
> {{/system/console/osgi-installer-config-printer?pid=org.apache.jackrabbit.vault.packaging.impl.PackagingImpl=JSON}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: Starter ITs failing when updating to the latest Apache Felix HTTP 4.x
I think the solution here is to do the same in Sling Engine as Apache Felix is doing: instead of setting the attributes on the request, overwriting the getAttribute method. This avoids leakage of information as well. Regards Carsten On 04.05.2023 12:45, Carsten Ziegeler wrote: My best guess is that it is due to this new code in 4.2.0: https://github.com/apache/felix-dev/blob/http-4.x/http/base/src/main/java/org/apache/felix/http/base/internal/dispatch/ServletRequestWrapper.java#L166 Regards Carsten On 04.05.2023 10:46, Carsten Ziegeler wrote: I don't really have a very helpful reply. I'm not aware of changes in this area. As far as I remember, the attributes are set by the http base implementation. I'm also not sure what the IncludeTest is actually testing; is it testing a Sling include or a servlet include? Http base has tests for the includes andh whether the attribute is set. I fear the only way to figure out what is going on is debugging the test run and see what happens (or not happens). Regards Carsten On 04.05.2023 09:50, Robert Munteanu wrote: Hi, I am looking at a renovate PR [1] that updates org.apache.felix:org.apache.felix.http.jetty from 4.1.14 to 4.2.10 and org.apache.felix:org.apache.felix.http.servlet-api from 1.1.4 to 1.2.0 . There are 3 failures in the IncludeIT that show that the javax.servlet.include.request_uri attribute is no longer present: [ERROR] Failures: [ERROR] IncludeTest.testForcedResourceType:149->assertIncludeRequestAttributes:154->assertIncludeRequestAttributes:167->assertRequestAttribute:189 Expected content contains '--javax.servlet.include.request_uri-' [ERROR] IncludeTest.testWithInclude:114->assertIncludeRequestAttributes:154->assertIncludeRequestAttributes:167->assertRequestAttribute:189 Expected content contains '--javax.servlet.include.request_uri-' [ERROR] IncludeTest.testWithIncludeAndExtension:123->assertIncludeRequestAttributes:154->assertIncludeRequestAttributes:167->assertRequestAttribute:189 Expected content contains '--javax.servlet.include.request_uri-' The test failures happen with version 4.2.0 as well, so this has something to do with the minor version bump. Looking at the Felix changelog [2] this could be related to supporting the Servlet API 4.0 [3], but I didn't manage to figure out what is going on. If anyone has an idea about how to make this progress, please share, I'm out of ideas at the moment. Thanks, Robert [1]: https://github.com/apache/sling-org-apache-sling-starter/pull/142 [2]: https://issues.apache.org/jira/projects/FELIX/versions/12351176 [3]: https://issues.apache.org/jira/browse/FELIX-6498 -- Carsten Ziegeler Adobe cziege...@apache.org
[jira] [Commented] (SLING-11867) Empty mapping from ResourceMapper breaks authentication requirement updates
[
https://issues.apache.org/jira/browse/SLING-11867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722071#comment-17722071
]
Carsten Ziegeler commented on SLING-11867:
--
There are two options to fix this issue, one is to change the path logic as
done in the provided PR; the other one is to just ignore empty/null values in
AuthenticationRequirementHolder.fromConfig
I have the feeling we should do the latter; this would also avoid breaking the
system with an accidental empty configuration.
> Empty mapping from ResourceMapper breaks authentication requirement updates
> ---
>
> Key: SLING-11867
> URL: https://issues.apache.org/jira/browse/SLING-11867
> Project: Sling
> Issue Type: Bug
> Components: Authentication
>Affects Versions: Auth Core 1.6.0
>Reporter: Sagar Miglani
>Priority: Major
>
> When a resource has a path less url as vanity path (eg:
> "http://www.example.com;) ResourceMapper.getAllMappings returns mappings
> consisting of an empty path "".
> This "" mapping can make {{AuthenticationRequirementsManager}} stop listening
> to further authentication requirements [0]:
> {code:xml}
> Exception in thread "pool-14-thread-1" java.lang.IllegalArgumentException:
> Configuration must not be null or empty
> at
> org.apache.sling.auth.core.impl.AuthenticationRequirementHolder.fromConfig(AuthenticationRequirementHolder.java:30)
> at
> org.apache.sling.auth.core.impl.AuthenticationRequirementsManager.addService(AuthenticationRequirementsManager.java:374)
> at
> org.apache.sling.auth.core.impl.AuthenticationRequirementsManager.process(AuthenticationRequirementsManager.java:300)
> at
> org.apache.sling.auth.core.impl.AuthenticationRequirementsManager.processQueue(AuthenticationRequirementsManager.java:281)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
> In SLING-11861 and [0], it was suggested to make changes in caller's code
> instead of changing the behaviour of ResoucreMapper.
> [0]: https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/96
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11864) Configuration merge/default values not considered in OSGi Installer Configuration Printer Web Console
[
https://issues.apache.org/jira/browse/SLING-11864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722052#comment-17722052
]
Konrad Windszus commented on SLING-11864:
-
[~cziegeler] Should we also optionally filter metatype default values or is
this getting too complicated then?
> Configuration merge/default values not considered in OSGi Installer
> Configuration Printer Web Console
> -
>
> Key: SLING-11864
> URL: https://issues.apache.org/jira/browse/SLING-11864
> Project: Sling
> Issue Type: New Feature
> Components: Installer
>Affects Versions: Installer Console 1.1.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: Installer Console 1.1.2, Installer Configuration Factory
> 1.4.4
>
> Attachments: Screenshot 2023-05-10 at 17.34.44.png
>
>
> Despite
> https://sling.apache.org/documentation/bundles/configuration-installer-factory.html#merging-of-configurations
> stating that
> bq. Similar, for write back and the OSGi Installer Configuration Printer Web
> Console only the properties with different configuration values than the
> default configuration are written back/exposed.
> I still see all values which differ from the metatype default value being
> exposed at {{/system/console/osgi-installer-config-printer}}. I tried with a
> distribution which has two configurations
> {code}
> * org.apache.jackrabbit.vault.packaging.impl.PackagingImpl:
> 2a425da9bfe3907800abf828d7dba911/200,
> jcrinstall:/apps/system/config/org.apache.jackrabbit.vault.packaging.impl.PackagingImpl.cfg.json,
> INSTALLED,
> - 311121c892dc31cecae4b5844a5855e9/50,
> launchpad:resources/config/org.apache.jackrabbit.vault.packaging.impl.PackagingImpl.config,
> INSTALL, Another resource with the same entity id but a higher version or
> priority or digest found (in that order, the latter only in case the version
> is a SNAPSHOT)!
> {code}
> and framework property {{sling.installer.config.mergeSchemes = launchpad}}.
> Still values from both sources are exposed at
> {{/system/console/osgi-installer-config-printer?pid=org.apache.jackrabbit.vault.packaging.impl.PackagingImpl=JSON}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [sling-org-apache-sling-installer-console] sonarcloud[bot] commented on pull request #4: SLING-11864 Remove config serializer console
sonarcloud[bot] commented on PR #4: URL: https://github.com/apache/sling-org-apache-sling-installer-console/pull/4#issuecomment-1545298693 Kudos, SonarCloud Quality Gate passed! [](https://sonarcloud.io/dashboard?id=apache_sling-org-apache-sling-installer-console=4) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-installer-console=4=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-installer-console=4=false=BUG) [0 Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-installer-console=4=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-installer-console=4=false=VULNERABILITY) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-installer-console=4=false=VULNERABILITY) [0 Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-installer-console=4=false=VULNERABILITY) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-installer-console=4=false=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-installer-console=4=false=SECURITY_HOTSPOT) [0 Security Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-installer-console=4=false=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-installer-console=4=false=CODE_SMELL) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-installer-console=4=false=CODE_SMELL) [0 Code Smells](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-installer-console=4=false=CODE_SMELL) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-installer-console=4) No Coverage information [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-installer-console=4=new_duplicated_lines_density=list) [0.0% Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-installer-console=4=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-installer-factory-configuration] kwin commented on pull request #8: SLING-11866 add failing test case to show that not all default
kwin commented on PR #8: URL: https://github.com/apache/sling-org-apache-sling-installer-factory-configuration/pull/8#issuecomment-1545290389 Clarified meanwhile in https://issues.apache.org/jira/browse/SLING-10771. -- 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] [Resolved] (SLING-11866) WebconsoleConfigurationHandler does not filter out default values coming from ConfigTaskCreator.getDefaultProperties
[
https://issues.apache.org/jira/browse/SLING-11866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved SLING-11866.
-
Resolution: Invalid
As clarified in SLING-10771 the merged configurations are orthogonal and not
supposed to be filtered in this SPI.
> WebconsoleConfigurationHandler does not filter out default values coming from
> ConfigTaskCreator.getDefaultProperties
> -
>
> Key: SLING-11866
> URL: https://issues.apache.org/jira/browse/SLING-11866
> Project: Sling
> Issue Type: Bug
> Components: Installer
>Affects Versions: Installer Configuration Factory 1.4.2
>Reporter: Konrad Windszus
>Priority: Major
>
> Although {{MetatypeHandler.updateConfiguration}} takes the default
> configurations identified via {{ConfigTaskCreator.getDefaultProperties(...)}}
> as fourth argument it will never strip those properties from the props to
> update. Therefore {{WebconsoleConfigurationHandler.updateConfiguration(...)}}
> will only ever strip properties which have
> a) a default which is equal to the value to be set and
> b) which are not contained in {{ConfigTaskCreator.getDefaultProperties(...)}}
> b) just seem to be wrong as the logic should rather be:
> strip all properties whose value is either equal to the metatype default
> value or the default value coming from the same named property of the the
> configuration provided by any of the MERGE_SCHEME configs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [sling-org-apache-sling-installer-factory-configuration] kwin closed pull request #8: SLING-11866 add failing test case to show that not all default
kwin closed pull request #8: SLING-11866 add failing test case to show that not all default URL: https://github.com/apache/sling-org-apache-sling-installer-factory-configuration/pull/8 -- 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-testing-jcr-mock] sonarcloud[bot] commented on pull request #22: SLING-11870 Use org.apache.jackrabbit:oak-jcr as only oak dependency
sonarcloud[bot] commented on PR #22: URL: https://github.com/apache/sling-org-apache-sling-testing-jcr-mock/pull/22#issuecomment-1545288312 Kudos, SonarCloud Quality Gate passed! [](https://sonarcloud.io/dashboard?id=apache_sling-org-apache-sling-testing-jcr-mock=22) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-testing-jcr-mock=22=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-testing-jcr-mock=22=false=BUG) [0 Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-testing-jcr-mock=22=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-testing-jcr-mock=22=false=VULNERABILITY) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-testing-jcr-mock=22=false=VULNERABILITY) [0 Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-testing-jcr-mock=22=false=VULNERABILITY) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-testing-jcr-mock=22=false=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-testing-jcr-mock=22=false=SECURITY_HOTSPOT) [0 Security Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-testing-jcr-mock=22=false=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-testing-jcr-mock=22=false=CODE_SMELL) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-testing-jcr-mock=22=false=CODE_SMELL) [0 Code Smells](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-testing-jcr-mock=22=false=CODE_SMELL) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-testing-jcr-mock=22=coverage=list) No Coverage information [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-testing-jcr-mock=22=new_duplicated_lines_density=list) [0.0% Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-testing-jcr-mock=22=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
[jira] [Commented] (SLING-10771) Support handling of metatype info when merging configurations
[ https://issues.apache.org/jira/browse/SLING-10771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722040#comment-17722040 ] Carsten Ziegeler commented on SLING-10771: -- there is no right or wrong here. component property default values being different than the metatype default value is an edge case and I would also argue that this is a bug. Setting a default value in a configuration is problematic once the default value changes - which is also not that common; but still happens from time to time. If you don't want this behaviour, simply disable (or do not enable) the component that implements the web console SPI > Support handling of metatype info when merging configurations > - > > Key: SLING-10771 > URL: https://issues.apache.org/jira/browse/SLING-10771 > Project: Sling > Issue Type: New Feature > Components: Installer >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: Installer Configuration Factory 1.4.2 > > > With SLING-10538 we have a mechanism to handle default values and merging for > configurations, for example to separate between platform and application > configurations. > In addition we should also handle default values from metatype and not store > properties in a configuration which has default values. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [sling-org-apache-sling-testing-jcr-mock] stefanseifert opened a new pull request, #22: SLING-11870 Use org.apache.jackrabbit:oak-jcr as only oak dependency
stefanseifert opened a new pull request, #22: URL: https://github.com/apache/sling-org-apache-sling-testing-jcr-mock/pull/22 (no comment) -- 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] [Comment Edited] (SLING-10771) Support handling of metatype info when merging configurations
[ https://issues.apache.org/jira/browse/SLING-10771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721045#comment-17721045 ] Konrad Windszus edited comment on SLING-10771 at 5/12/23 7:08 AM: -- bq. Does this imply that Felix internally never persists configuration values which are equal to the metatype default? I had a closer look at the source in https://github.com/apache/felix-dev/blob/fd722d1c1914e4758f34604fd19d84fcac697af7/webconsole/src/main/java/org/apache/felix/webconsole/internal/configuration/ConfigAdminSupport.java#L273 and I think this indeed prevents configuration properties to be set from the ConfigAdmin Web Console which are equal to the metatype default. I would argue that this is wrong, because as you correctly said ConfigAdmin and Metatype are separate specs. The Metatype default is usually not evaluated when leveraging configuration properties from ConfigAdmin, therefore even properties having a value = metatype default value should IMHO be set in the ConfigAdmin from the Web Console UI. This is particularly crucial for DS components which use merged configurations from ConfigAdmin + Component Descriptions. For edge cases the same configuration property key can have a different default value in metatype than in the component description. When adjusting its config now in the Felix Web Console Plugin the default metatype value will never be written and therefore never overwrite the component property default value (although they are different). Also it feels weird to have this functionality in the OSGi installer configuration factory bundle as it is not really related to the OSGi installer. Even the configuration factory does not consider metatype default values when installing configurations through the ConfigAdmin. was (Author: kwin): bq. Does this imply that Felix internally never persists configuration values which are equal to the metatype default? I had a closer look at the source in https://github.com/apache/felix-dev/blob/fd722d1c1914e4758f34604fd19d84fcac697af7/webconsole/src/main/java/org/apache/felix/webconsole/internal/configuration/ConfigAdminSupport.java#L273 and I think this indeed prevents configuration properties to be set from the ConfigAdmin Web Console which are equal to the metatype default. I would argue that this is wrong, because as you correctly said ConfigAdmin and Metatype are separate specs. The Metatype default is usually not evaluated when leveraging configuration properties from ConfigAdmin, therefore even properties having a value = metatype default value should IMHO be set in the ConfigAdmin from the Web Console UI. This is particularly crucial for DS components which use merged configurations from ConfigAdmin + Component Descriptions. For edge cases the same configuration property key can have a different default value in metatype than in the component description. When adjusting its config now in the Felix Web Console Plugin the default metatype value will never be written and therefore never overwrite the component property default value (although they are different). Also it feels weird to have this functionality in the OSGi installer configuration factory bundle as it is not really related to the OSGi installer. > Support handling of metatype info when merging configurations > - > > Key: SLING-10771 > URL: https://issues.apache.org/jira/browse/SLING-10771 > Project: Sling > Issue Type: New Feature > Components: Installer >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: Installer Configuration Factory 1.4.2 > > > With SLING-10538 we have a mechanism to handle default values and merging for > configurations, for example to separate between platform and application > configurations. > In addition we should also handle default values from metatype and not store > properties in a configuration which has default values. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (SLING-10771) Support handling of metatype info when merging configurations
[ https://issues.apache.org/jira/browse/SLING-10771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721045#comment-17721045 ] Konrad Windszus edited comment on SLING-10771 at 5/12/23 7:07 AM: -- bq. Does this imply that Felix internally never persists configuration values which are equal to the metatype default? I had a closer look at the source in https://github.com/apache/felix-dev/blob/fd722d1c1914e4758f34604fd19d84fcac697af7/webconsole/src/main/java/org/apache/felix/webconsole/internal/configuration/ConfigAdminSupport.java#L273 and I think this indeed prevents configuration properties to be set from the ConfigAdmin Web Console which are equal to the metatype default. I would argue that this is wrong, because as you correctly said ConfigAdmin and Metatype are separate specs. The Metatype default is usually not evaluated when leveraging configuration properties from ConfigAdmin, therefore even properties having a value = metatype default value should IMHO be set in the ConfigAdmin from the Web Console UI. This is particularly crucial for DS components which use merged configurations from ConfigAdmin + Component Descriptions. For edge cases the same configuration property key can have a different default value in metatype than in the component description. When adjusting its config now in the Felix Web Console Plugin the default metatype value will never be written and therefore never overwrite the component property default value (although they are different). Also it feels weird to have this functionality in the OSGi installer configuration factory bundle as it is not really related to the OSGi installer. was (Author: kwin): bq. Does this imply that Felix internally never persists configuration values which are equal to the metatype default? I had a closer look at the source in https://github.com/apache/felix-dev/blob/fd722d1c1914e4758f34604fd19d84fcac697af7/webconsole/src/main/java/org/apache/felix/webconsole/internal/configuration/ConfigAdminSupport.java#L273 and I think this indeed prevents configuration properties to be set from the ConfigAdmin Web Console which are equal to the metatype default. I would argue that this is wrong, because as you correctly said ConfigAdmin and Metatype are separate specs. The Metatype default is usually not evaluated when leveraging configuration properties from ConfigAdmin, therefore even properties having a value = metatype default value should IMHO be set in the ConfigAdmin from the Web Console UI. This is particularly crucial for DS components which use merged configurations from ConfigAdmin + Component Descriptions. For edge cases the same configuration property key can have a different default value in metatype than in the component description. When adjusting its config now in the Felix Web Console Plugin the default metatype value will never be written and therefore never overwrite the component property default value (although they are different). > Support handling of metatype info when merging configurations > - > > Key: SLING-10771 > URL: https://issues.apache.org/jira/browse/SLING-10771 > Project: Sling > Issue Type: New Feature > Components: Installer >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: Installer Configuration Factory 1.4.2 > > > With SLING-10538 we have a mechanism to handle default values and merging for > configurations, for example to separate between platform and application > configurations. > In addition we should also handle default values from metatype and not store > properties in a configuration which has default values. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (SLING-10771) Support handling of metatype info when merging configurations
[ https://issues.apache.org/jira/browse/SLING-10771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721045#comment-17721045 ] Konrad Windszus edited comment on SLING-10771 at 5/12/23 7:05 AM: -- bq. Does this imply that Felix internally never persists configuration values which are equal to the metatype default? I had a closer look at the source in https://github.com/apache/felix-dev/blob/fd722d1c1914e4758f34604fd19d84fcac697af7/webconsole/src/main/java/org/apache/felix/webconsole/internal/configuration/ConfigAdminSupport.java#L273 and I think this indeed prevents configuration properties to be set from the ConfigAdmin Web Console which are equal to the metatype default. I would argue that this is wrong, because as you correctly said ConfigAdmin and Metatype are separate specs. The Metatype default is usually not evaluated when leveraging configuration properties from ConfigAdmin, therefore even properties having a value = metatype default value should IMHO be set in the ConfigAdmin from the Web Console UI. This is particularly crucial for DS components which use merged configurations from ConfigAdmin + Component Descriptions. For edge cases the same configuration property key can have a different default value in metatype than in the component description. When adjusting its config now in the Felix Web Console Plugin the default metatype value will never be written and therefore never overwrite the component property default value (although they are different). was (Author: kwin): bq. Does this imply that Felix internally never persists configuration values which are equal to the metatype default? I had a closer look at the source in https://github.com/apache/felix-dev/blob/fd722d1c1914e4758f34604fd19d84fcac697af7/webconsole/src/main/java/org/apache/felix/webconsole/internal/configuration/ConfigAdminSupport.java#L273 and I think this indeed prevents configuration properties to be set from the ConfigAdmin Web Console which are equal to the metatype default. I would argue that this is wrong, because as you correctly said ConfigAdmin and Metatype are separate specs. The Metatype default is usually not evaluated when leveraging configuration properties from ConfigAdmin, therefore even properties having a value = metatype default value should IMHO be set in the ConfigAdmin. This is particularly crucial for DS components which use merged configurations from ConfigAdmin + Component Descriptions. For edge cases the same configuration property key can have a different default value in metatype than in the component description. When adjusting its config now in the Felix Web Console Plugin the default metatype value will never be written and therefore never overwrite the component property default value (although they are different). > Support handling of metatype info when merging configurations > - > > Key: SLING-10771 > URL: https://issues.apache.org/jira/browse/SLING-10771 > Project: Sling > Issue Type: New Feature > Components: Installer >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: Installer Configuration Factory 1.4.2 > > > With SLING-10538 we have a mechanism to handle default values and merging for > configurations, for example to separate between platform and application > configurations. > In addition we should also handle default values from metatype and not store > properties in a configuration which has default values. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (SLING-10771) Support handling of metatype info when merging configurations
[ https://issues.apache.org/jira/browse/SLING-10771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721045#comment-17721045 ] Konrad Windszus edited comment on SLING-10771 at 5/12/23 7:02 AM: -- bq. Does this imply that Felix internally never persists configuration values which are equal to the metatype default? I had a closer look at the source in https://github.com/apache/felix-dev/blob/fd722d1c1914e4758f34604fd19d84fcac697af7/webconsole/src/main/java/org/apache/felix/webconsole/internal/configuration/ConfigAdminSupport.java#L273 and I think this indeed prevents configuration properties to be set from the ConfigAdmin Web Console which are equal to the metatype default. I would argue that this is wrong, because as you correctly said ConfigAdmin and Metatype are separate specs. The Metatype default is usually not evaluated when leveraging configuration properties from ConfigAdmin, therefore even properties having a value = metatype default value should IMHO be set in the ConfigAdmin. This is particularly crucial for DS components which use merged configurations from ConfigAdmin + Component Descriptions. For edge cases the same configuration property key can have a different default value in metatype than in the component description. When adjusting its config now in the Felix Web Console Plugin the default metatype value will never be written and therefore never overwrite the component property default value (although they are different). was (Author: kwin): How is this used in the WebConsole? When exactly does the filtering happen? > Support handling of metatype info when merging configurations > - > > Key: SLING-10771 > URL: https://issues.apache.org/jira/browse/SLING-10771 > Project: Sling > Issue Type: New Feature > Components: Installer >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: Installer Configuration Factory 1.4.2 > > > With SLING-10538 we have a mechanism to handle default values and merging for > configurations, for example to separate between platform and application > configurations. > In addition we should also handle default values from metatype and not store > properties in a configuration which has default values. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-11868) jcr-mock: MockAuthorizable must not use java.nio.file.Paths
[ https://issues.apache.org/jira/browse/SLING-11868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-11868. Resolution: Fixed https://github.com/apache/sling-org-apache-sling-testing-jcr-mock/commit/ea08010516b8827430487adf3010976f3d1ac5cd > jcr-mock: MockAuthorizable must not use java.nio.file.Paths > --- > > Key: SLING-11868 > URL: https://issues.apache.org/jira/browse/SLING-11868 > Project: Sling > Issue Type: Bug > Components: Testing >Affects Versions: Testing JCR Mock 1.6.8 >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Testing JCR Mock 1.6.10 > > > MockAuthorizable must not use java.nio.file.Paths to build JCR paths, as it > fails utterly on OS where the file separator is not "/" (windows). -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [VOTE] Release Apache Sling API 2.27.2
+1 Am Fr., 12. Mai 2023 um 09:41 Uhr schrieb Jörg Hoh : > Hi, > > We solved 1 issue in this > release:https://issues.apache.org/jira/projects/SLING/versions/12352229 > > > Staging > repository:https://repository.apache.org/content/repositories/orgapachesling-2746/ > > 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 2746 /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. > > > -- > Cheers, > Jörg Hoh, > > https://cqdump.joerghoh.de > Twitter: @joerghoh > -- Cheers, Jörg Hoh, https://cqdump.joerghoh.de Twitter: @joerghoh
[VOTE] Release Apache Sling API 2.27.2
Hi, We solved 1 issue in this release:https://issues.apache.org/jira/projects/SLING/versions/12352229 Staging repository:https://repository.apache.org/content/repositories/orgapachesling-2746/ 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 2746 /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. -- Cheers, Jörg Hoh, https://cqdump.joerghoh.de Twitter: @joerghoh
