[jira] [Commented] (SLING-8777) Sling activation bundle overrides default CommandMap with wrong type
[ https://issues.apache.org/jira/browse/SLING-8777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17422531#comment-17422531 ] Sagar Miglani commented on SLING-8777: -- Thanks [~cziegeler]! > Sling activation bundle overrides default CommandMap with wrong type > > > Key: SLING-8777 > URL: https://issues.apache.org/jira/browse/SLING-8777 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: javax.activation 0.1.0 >Reporter: Ashok Kumar >Assignee: Carsten Ziegeler >Priority: Major > Fix For: javax.activation 0.2.2 > > Attachments: SLING-8777.patch > > Time Spent: 1h 10m > Remaining Estimate: 0h > > The root cause of the issue is that the bundle > org.apache.sling.javax.activation 0.1.0 overrides the Default > javax.activation.CommandMap extending directly from CommandMap instead of > MailcapCommandMap: > > [https://github.com/apache/sling-org-apache-sling-javax-activation/blob/master/src/main/java/org/apache/sling/javax/activation/internal/OsgiMailcapCommandMap.java#L50] > The call fails due to this, here: > > [https://github.com/samskivert/ikvm-openjdk/blob/master/build/linux-amd64/impsrc/com/sun/xml/internal/messaging/saaj/soap/AttachmentPartImpl.java#L112] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-8777) Sling activation bundle overrides default CommandMap with wrong type
[ https://issues.apache.org/jira/browse/SLING-8777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-8777. - Resolution: Fixed [~sagarmiglani] Thanks for the patch, I've applied it > Sling activation bundle overrides default CommandMap with wrong type > > > Key: SLING-8777 > URL: https://issues.apache.org/jira/browse/SLING-8777 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: javax.activation 0.1.0 >Reporter: Ashok Kumar >Assignee: Carsten Ziegeler >Priority: Major > Fix For: javax.activation 0.2.2 > > Attachments: SLING-8777.patch > > Time Spent: 1h 10m > Remaining Estimate: 0h > > The root cause of the issue is that the bundle > org.apache.sling.javax.activation 0.1.0 overrides the Default > javax.activation.CommandMap extending directly from CommandMap instead of > MailcapCommandMap: > > [https://github.com/apache/sling-org-apache-sling-javax-activation/blob/master/src/main/java/org/apache/sling/javax/activation/internal/OsgiMailcapCommandMap.java#L50] > The call fails due to this, here: > > [https://github.com/samskivert/ikvm-openjdk/blob/master/build/linux-amd64/impsrc/com/sun/xml/internal/messaging/saaj/soap/AttachmentPartImpl.java#L112] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (SLING-8777) Sling activation bundle overrides default CommandMap with wrong type
[ https://issues.apache.org/jira/browse/SLING-8777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-8777: --- Assignee: Carsten Ziegeler > Sling activation bundle overrides default CommandMap with wrong type > > > Key: SLING-8777 > URL: https://issues.apache.org/jira/browse/SLING-8777 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: javax.activation 0.1.0 >Reporter: Ashok Kumar >Assignee: Carsten Ziegeler >Priority: Major > Fix For: javax.activation 0.2.2 > > Attachments: SLING-8777.patch > > Time Spent: 1h 10m > Remaining Estimate: 0h > > The root cause of the issue is that the bundle > org.apache.sling.javax.activation 0.1.0 overrides the Default > javax.activation.CommandMap extending directly from CommandMap instead of > MailcapCommandMap: > > [https://github.com/apache/sling-org-apache-sling-javax-activation/blob/master/src/main/java/org/apache/sling/javax/activation/internal/OsgiMailcapCommandMap.java#L50] > The call fails due to this, here: > > [https://github.com/samskivert/ikvm-openjdk/blob/master/build/linux-amd64/impsrc/com/sun/xml/internal/messaging/saaj/soap/AttachmentPartImpl.java#L112] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [sling-org-apache-sling-javax-activation] cziegeler merged pull request #5: SLING-8777: Changed base class of OsgiMailcapCommandMap from CommandM…
cziegeler merged pull request #5: URL: https://github.com/apache/sling-org-apache-sling-javax-activation/pull/5 -- 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-8777) Sling activation bundle overrides default CommandMap with wrong type
[ https://issues.apache.org/jira/browse/SLING-8777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17422527#comment-17422527 ] Carsten Ziegeler commented on SLING-8777: - Update: it seems the implementation from ServiceMix does not support loading mail map files from bundles which is a feature we have in Sling. So we can't switch to a different implementation > Sling activation bundle overrides default CommandMap with wrong type > > > Key: SLING-8777 > URL: https://issues.apache.org/jira/browse/SLING-8777 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: javax.activation 0.1.0 >Reporter: Ashok Kumar >Priority: Major > Fix For: javax.activation 0.2.2 > > Attachments: SLING-8777.patch > > Time Spent: 1h > Remaining Estimate: 0h > > The root cause of the issue is that the bundle > org.apache.sling.javax.activation 0.1.0 overrides the Default > javax.activation.CommandMap extending directly from CommandMap instead of > MailcapCommandMap: > > [https://github.com/apache/sling-org-apache-sling-javax-activation/blob/master/src/main/java/org/apache/sling/javax/activation/internal/OsgiMailcapCommandMap.java#L50] > The call fails due to this, here: > > [https://github.com/samskivert/ikvm-openjdk/blob/master/build/linux-amd64/impsrc/com/sun/xml/internal/messaging/saaj/soap/AttachmentPartImpl.java#L112] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [sling-org-apache-sling-api] sonarcloud[bot] commented on pull request #33: SLING-8742 : Allow overriding the extension when using the RequestDispatcher
sonarcloud[bot] commented on pull request #33: URL: https://github.com/apache/sling-org-apache-sling-api/pull/33#issuecomment-930339982 Kudos, SonarCloud Quality Gate passed!  [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=33=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=33=false=BUG) [0 Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=33=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=33=false=VULNERABILITY) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=33=false=VULNERABILITY) [0 Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=33=false=VULNERABILITY) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-api=33=false=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-api=33=false=SECURITY_HOTSPOT) [0 Security Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-api=33=false=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=33=false=CODE_SMELL) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=33=false=CODE_SMELL) [1 Code Smell](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=33=false=CODE_SMELL) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-api=33=new_coverage=list) [100.0% Coverage](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-api=33=new_coverage=list) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-api=33=new_duplicated_lines_density=list) [0.0% Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-api=33=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
Add builders to create request/response objects
Hi, in https://issues.apache.org/jira/browse/SLING-10840 we have some lengthy discussion about the servlet helpers bundle, where and how it should be used and the problem with it implementing ProviderType interfaces. The gist of it, is that the main purpose of this bundle is to be used in tests. It provides mocks for several things. Due to it implementing ProviderType it is a little bit more dangerouns to use it in production as it constantly needs to be updated whenever the Sling api changes (the relevant packages have changes). Now, as suggested in that ticket, we should probably have some proper API to create an initial request and response without backing it out or wrapping an existing request / response. The suggestion is to provide two builder classes (similar or same) as in the servlet helpers bundle but make it more prominent. All required implementation classes would be private. We could either move these to the API bundle, where the interfaces are defined. Or to the Engine bundle which contains the processor interface which is probably the most common use case for these. I don't have any real preference, API is probably the better location as this is general purpose functionality which can be used without the processor. WDYT? Regards Carsten -- Carsten Ziegeler Adobe cziege...@apache.org
[GitHub] [sling-org-apache-sling-api] sonarcloud[bot] commented on pull request #33: SLING-8742 : Allow overriding the extension when using the RequestDispatcher
sonarcloud[bot] commented on pull request #33: URL: https://github.com/apache/sling-org-apache-sling-api/pull/33#issuecomment-930339982 Kudos, SonarCloud Quality Gate passed!  [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=33=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=33=false=BUG) [0 Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=33=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=33=false=VULNERABILITY) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=33=false=VULNERABILITY) [0 Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=33=false=VULNERABILITY) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-api=33=false=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-api=33=false=SECURITY_HOTSPOT) [0 Security Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-api=33=false=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=33=false=CODE_SMELL) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=33=false=CODE_SMELL) [1 Code Smell](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-api=33=false=CODE_SMELL) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-api=33=new_coverage=list) [100.0% Coverage](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-api=33=new_coverage=list) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-api=33=new_duplicated_lines_density=list) [0.0% Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-api=33=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-8742) Allow overriding the extension when using the RequestDispatcher
[
https://issues.apache.org/jira/browse/SLING-8742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17422238#comment-17422238
]
Carsten Ziegeler commented on SLING-8742:
-
Created a PR for API
https://github.com/apache/sling-org-apache-sling-api/pull/33
and a PR for Engine
https://github.com/apache/sling-org-apache-sling-engine/pull/21
> Allow overriding the extension when using the RequestDispatcher
> ---
>
> Key: SLING-8742
> URL: https://issues.apache.org/jira/browse/SLING-8742
> Project: Sling
> Issue Type: Improvement
> Components: API, Engine
>Reporter: Robert Munteanu
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: API 2.23.8, Engine 2.7.12
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It is sometimes useful to be able to include another resource and override
> the extension at the same time.
> My scenario is that I am routing all requests through an entry point
> {{/content/maven.html}} and then serving resources based on the suffix.
> If I a binary file is requested, it should be downloaded ( by forcing the
> extension to be null ), but instead the html extension is used, which means
> the HTML Renderer kicks in.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [sling-org-apache-sling-engine] cziegeler opened a new pull request #21: SLING-8742 : Allow overriding the extension when using the RequestDis…
cziegeler opened a new pull request #21: URL: https://github.com/apache/sling-org-apache-sling-engine/pull/21 …patcher -- 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 Sitemap version 1.0.4
+1 Konrad > On 29. Sep 2021, at 16:44, Dirk Rudolph wrote: > > Hi, > > We solved 3 issues in this release: > https://issues.apache.org/jira/projects/SLING/versions/12350370 > > There are no outstanding issues. > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-2534/ > > 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 2534 /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. > > - Dirk
[jira] [Commented] (SLING-10840) Sling Servlet Helpers implements @ProviderType interfaces
[ https://issues.apache.org/jira/browse/SLING-10840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1741#comment-1741 ] Stefan Seifert commented on SLING-10840: +1 the servlet-helpers bundle still fulfills it's initial purpose to back Sling Mocks & Co - but this it not object to any validation as it's only used in unit tests > Sling Servlet Helpers implements @ProviderType interfaces > - > > Key: SLING-10840 > URL: https://issues.apache.org/jira/browse/SLING-10840 > Project: Sling > Issue Type: Bug > Components: General >Affects Versions: Servlet Helpers 1.4.2 >Reporter: David Gonzalez >Priority: Major > > When using the Sling Servlet Helpers bundle/API, code quality scans detect > that implentations in the Sling Servlet Helpers bundle implement > @ProviderType interfaces from OTHER Sling bundles, which is not correct. Here > are some fo the examples (though probably not exhaustive) I found when > attempting to use ths Servlet Helpers library. > > |The product interface org.apache.sling.api.request.RequestParameter > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockRequestParameter contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.request.RequestParameterMap > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockRequestParameterMap contained > in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.request.RequestPathInfo annotated > with @ProviderType should not be implemented by custom code. Detected in > org.apache.sling.servlethelpers.MockRequestPathInfo contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.request.RequestProgressTracker > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockRequestProgressTracker > contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.SlingHttpServletRequest annotated > with @ProviderType should not be implemented by custom code. Detected in > org.apache.sling.servlethelpers.MockSlingHttpServletRequest contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.SlingHttpServletResponse > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockSlingHttpServletResponse > contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.resource.Resource annotated with > @ProviderType should not be implemented by custom code. Detected in > org.apache.sling.servlethelpers.internalrequests.ServletResolutionResource > contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > Perhaps there needs to be Wrappers for all these classes that are > @ConsumerTypes? -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [VOTE] Release Apache Sling Sitemap version 1.0.4
On Wed, 2021-09-29 at 16:44 +0200, Dirk Rudolph wrote: > Please vote to approve this release: +1 Robert signature.asc Description: This is a digitally signed message part
[jira] [Commented] (SLING-10840) Sling Servlet Helpers implements @ProviderType interfaces
[ https://issues.apache.org/jira/browse/SLING-10840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17422194#comment-17422194 ] Carsten Ziegeler commented on SLING-10840: -- So my suggest is that we implement SLING-8742 and move the two builder classes to either API or Engine. Whatever classes those builders need in addition will be private > Sling Servlet Helpers implements @ProviderType interfaces > - > > Key: SLING-10840 > URL: https://issues.apache.org/jira/browse/SLING-10840 > Project: Sling > Issue Type: Bug > Components: General >Affects Versions: Servlet Helpers 1.4.2 >Reporter: David Gonzalez >Priority: Major > > When using the Sling Servlet Helpers bundle/API, code quality scans detect > that implentations in the Sling Servlet Helpers bundle implement > @ProviderType interfaces from OTHER Sling bundles, which is not correct. Here > are some fo the examples (though probably not exhaustive) I found when > attempting to use ths Servlet Helpers library. > > |The product interface org.apache.sling.api.request.RequestParameter > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockRequestParameter contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.request.RequestParameterMap > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockRequestParameterMap contained > in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.request.RequestPathInfo annotated > with @ProviderType should not be implemented by custom code. Detected in > org.apache.sling.servlethelpers.MockRequestPathInfo contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.request.RequestProgressTracker > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockRequestProgressTracker > contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.SlingHttpServletRequest annotated > with @ProviderType should not be implemented by custom code. Detected in > org.apache.sling.servlethelpers.MockSlingHttpServletRequest contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.SlingHttpServletResponse > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockSlingHttpServletResponse > contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.resource.Resource annotated with > @ProviderType should not be implemented by custom code. Detected in > org.apache.sling.servlethelpers.internalrequests.ServletResolutionResource > contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > Perhaps there needs to be Wrappers for all these classes that are > @ConsumerTypes? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (SLING-8742) Allow overriding the extension when using the RequestDispatcher
[
https://issues.apache.org/jira/browse/SLING-8742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler reassigned SLING-8742:
---
Assignee: Carsten Ziegeler
> Allow overriding the extension when using the RequestDispatcher
> ---
>
> Key: SLING-8742
> URL: https://issues.apache.org/jira/browse/SLING-8742
> Project: Sling
> Issue Type: Improvement
> Components: API, Engine
>Reporter: Robert Munteanu
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: API 2.23.8, Engine 2.7.12
>
>
> It is sometimes useful to be able to include another resource and override
> the extension at the same time.
> My scenario is that I am routing all requests through an entry point
> {{/content/maven.html}} and then serving resources based on the suffix.
> If I a binary file is requested, it should be downloaded ( by forcing the
> extension to be null ), but instead the html extension is used, which means
> the HTML Renderer kicks in.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-10840) Sling Servlet Helpers implements @ProviderType interfaces
[ https://issues.apache.org/jira/browse/SLING-10840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17422186#comment-17422186 ] Bertrand Delacretaz commented on SLING-10840: - FWIW you can see an example of the GraphQL core making an internal request to get a schema for the current request using an internal request [in the DefaultSchemaProvider class|https://github.com/apache/sling-org-apache-sling-graphql-core/blob/1ea954e36e626d0c89ddc93655d71b9300f26e88/src/main/java/org/apache/sling/graphql/core/schema/DefaultSchemaProvider.java#L55]. > Sling Servlet Helpers implements @ProviderType interfaces > - > > Key: SLING-10840 > URL: https://issues.apache.org/jira/browse/SLING-10840 > Project: Sling > Issue Type: Bug > Components: General >Affects Versions: Servlet Helpers 1.4.2 >Reporter: David Gonzalez >Priority: Major > > When using the Sling Servlet Helpers bundle/API, code quality scans detect > that implentations in the Sling Servlet Helpers bundle implement > @ProviderType interfaces from OTHER Sling bundles, which is not correct. Here > are some fo the examples (though probably not exhaustive) I found when > attempting to use ths Servlet Helpers library. > > |The product interface org.apache.sling.api.request.RequestParameter > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockRequestParameter contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.request.RequestParameterMap > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockRequestParameterMap contained > in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.request.RequestPathInfo annotated > with @ProviderType should not be implemented by custom code. Detected in > org.apache.sling.servlethelpers.MockRequestPathInfo contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.request.RequestProgressTracker > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockRequestProgressTracker > contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.SlingHttpServletRequest annotated > with @ProviderType should not be implemented by custom code. Detected in > org.apache.sling.servlethelpers.MockSlingHttpServletRequest contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.SlingHttpServletResponse > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockSlingHttpServletResponse > contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.resource.Resource annotated with > @ProviderType should not be implemented by custom code. Detected in > org.apache.sling.servlethelpers.internalrequests.ServletResolutionResource > contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > Perhaps there needs to be Wrappers for all these classes that are > @ConsumerTypes? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-8742) Allow overriding the extension when using the RequestDispatcher
[
https://issues.apache.org/jira/browse/SLING-8742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated SLING-8742:
Component/s: Engine
> Allow overriding the extension when using the RequestDispatcher
> ---
>
> Key: SLING-8742
> URL: https://issues.apache.org/jira/browse/SLING-8742
> Project: Sling
> Issue Type: Improvement
> Components: API, Engine
>Reporter: Robert Munteanu
>Priority: Major
>
> It is sometimes useful to be able to include another resource and override
> the extension at the same time.
> My scenario is that I am routing all requests through an entry point
> {{/content/maven.html}} and then serving resources based on the suffix.
> If I a binary file is requested, it should be downloaded ( by forcing the
> extension to be null ), but instead the html extension is used, which means
> the HTML Renderer kicks in.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-8742) Allow overriding the extension when using the RequestDispatcher
[
https://issues.apache.org/jira/browse/SLING-8742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated SLING-8742:
Fix Version/s: API 2.23.8
Engine 2.7.12
> Allow overriding the extension when using the RequestDispatcher
> ---
>
> Key: SLING-8742
> URL: https://issues.apache.org/jira/browse/SLING-8742
> Project: Sling
> Issue Type: Improvement
> Components: API, Engine
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: API 2.23.8, Engine 2.7.12
>
>
> It is sometimes useful to be able to include another resource and override
> the extension at the same time.
> My scenario is that I am routing all requests through an entry point
> {{/content/maven.html}} and then serving resources based on the suffix.
> If I a binary file is requested, it should be downloaded ( by forcing the
> extension to be null ), but instead the html extension is used, which means
> the HTML Renderer kicks in.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[VOTE] Release Apache Sling Sitemap version 1.0.4
Hi, We solved 3 issues in this release: https://issues.apache.org/jira/projects/SLING/versions/12350370 There are no outstanding issues. Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2534/ 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 2534 /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. - Dirk
[jira] [Commented] (SLING-10840) Sling Servlet Helpers implements @ProviderType interfaces
[ https://issues.apache.org/jira/browse/SLING-10840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17422151#comment-17422151 ] Roy Teeuwen commented on SLING-10840: - I indeed have the same requirement as [~empire29], having requests to internal things and I don't want to use the main Request for this and polute it. Maybe since the changes that [~bdelacretaz] did for the GraphQL, this can be done more easily now, in the past we had to do this based on creating "mock requests" and "mock responses" to then add that to the actual request / response after processing has been done for those request / responses > Sling Servlet Helpers implements @ProviderType interfaces > - > > Key: SLING-10840 > URL: https://issues.apache.org/jira/browse/SLING-10840 > Project: Sling > Issue Type: Bug > Components: General >Affects Versions: Servlet Helpers 1.4.2 >Reporter: David Gonzalez >Priority: Major > > When using the Sling Servlet Helpers bundle/API, code quality scans detect > that implentations in the Sling Servlet Helpers bundle implement > @ProviderType interfaces from OTHER Sling bundles, which is not correct. Here > are some fo the examples (though probably not exhaustive) I found when > attempting to use ths Servlet Helpers library. > > |The product interface org.apache.sling.api.request.RequestParameter > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockRequestParameter contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.request.RequestParameterMap > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockRequestParameterMap contained > in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.request.RequestPathInfo annotated > with @ProviderType should not be implemented by custom code. Detected in > org.apache.sling.servlethelpers.MockRequestPathInfo contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.request.RequestProgressTracker > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockRequestProgressTracker > contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.SlingHttpServletRequest annotated > with @ProviderType should not be implemented by custom code. Detected in > org.apache.sling.servlethelpers.MockSlingHttpServletRequest contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.SlingHttpServletResponse > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockSlingHttpServletResponse > contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.resource.Resource annotated with > @ProviderType should not be implemented by custom code. Detected in > org.apache.sling.servlethelpers.internalrequests.ServletResolutionResource > contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > Perhaps there needs to be Wrappers for all these classes that are > @ConsumerTypes? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-10840) Sling Servlet Helpers implements @ProviderType interfaces
[ https://issues.apache.org/jira/browse/SLING-10840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17422138#comment-17422138 ] Carsten Ziegeler commented on SLING-10840: -- Yes, an update of the api probably also needs an update of the implementation, so that needs to be provided by the product you are using. I guess we can debate a long time about what makes a clean solution in that area :) > Sling Servlet Helpers implements @ProviderType interfaces > - > > Key: SLING-10840 > URL: https://issues.apache.org/jira/browse/SLING-10840 > Project: Sling > Issue Type: Bug > Components: General >Affects Versions: Servlet Helpers 1.4.2 >Reporter: David Gonzalez >Priority: Major > > When using the Sling Servlet Helpers bundle/API, code quality scans detect > that implentations in the Sling Servlet Helpers bundle implement > @ProviderType interfaces from OTHER Sling bundles, which is not correct. Here > are some fo the examples (though probably not exhaustive) I found when > attempting to use ths Servlet Helpers library. > > |The product interface org.apache.sling.api.request.RequestParameter > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockRequestParameter contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.request.RequestParameterMap > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockRequestParameterMap contained > in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.request.RequestPathInfo annotated > with @ProviderType should not be implemented by custom code. Detected in > org.apache.sling.servlethelpers.MockRequestPathInfo contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.request.RequestProgressTracker > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockRequestProgressTracker > contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.SlingHttpServletRequest annotated > with @ProviderType should not be implemented by custom code. Detected in > org.apache.sling.servlethelpers.MockSlingHttpServletRequest contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.SlingHttpServletResponse > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockSlingHttpServletResponse > contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.resource.Resource annotated with > @ProviderType should not be implemented by custom code. Detected in > org.apache.sling.servlethelpers.internalrequests.ServletResolutionResource > contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > Perhaps there needs to be Wrappers for all these classes that are > @ConsumerTypes? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-10840) Sling Servlet Helpers implements @ProviderType interfaces
[ https://issues.apache.org/jira/browse/SLING-10840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17422116#comment-17422116 ] David Gonzalez commented on SLING-10840: [~cziegeler] If the bundle shouldn't be used at runtime then it makes sense to document as such (maybe highlight the change in guidance). SLING-8742 looks like it would suffice for my use-cases (double checked, my 2nd use-case also comes down to having to override RequestPathInfo since I cannot specify (in this case, nullify) the extension attribute. I assume I would need to let the CMS's I'm deploying include (ex. Service Pack, etc.) the new sling bundle containing SLING-8742, rather than "bringing it with me" to support the back compatibility of my application with the earlier product versions? FWIW - The Internal request and responses can certainly be nice for orchestrating multiple calls to Sling resources and then doing merging, transforming, etc. the results. This if often the cleanest way especially when you are making calls to resources/end-points provided by a product, and you otherwise have no real way of invoking/accessing. Obviously, developers always need to be careful about getting too much data (ex. binary) in memory, but (IMO) its cleaner, and simpler code to be able to invoke isolated internal request/responses rather than trying to piggyback on "real" request/response w/ wrappers and hope you don't accidentally mess something up (like something issuing a re-direct that gets flushed before you've finished doing your work). If we (you :)) could figure out a safe way to do this, i think it would be helpful to Sling dev community. (or if you have other established patterns that are as clean/simple that works too) > Sling Servlet Helpers implements @ProviderType interfaces > - > > Key: SLING-10840 > URL: https://issues.apache.org/jira/browse/SLING-10840 > Project: Sling > Issue Type: Bug > Components: General >Affects Versions: Servlet Helpers 1.4.2 >Reporter: David Gonzalez >Priority: Major > > When using the Sling Servlet Helpers bundle/API, code quality scans detect > that implentations in the Sling Servlet Helpers bundle implement > @ProviderType interfaces from OTHER Sling bundles, which is not correct. Here > are some fo the examples (though probably not exhaustive) I found when > attempting to use ths Servlet Helpers library. > > |The product interface org.apache.sling.api.request.RequestParameter > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockRequestParameter contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.request.RequestParameterMap > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockRequestParameterMap contained > in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.request.RequestPathInfo annotated > with @ProviderType should not be implemented by custom code. Detected in > org.apache.sling.servlethelpers.MockRequestPathInfo contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.request.RequestProgressTracker > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockRequestProgressTracker > contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.SlingHttpServletRequest annotated > with @ProviderType should not be implemented by custom code. Detected in > org.apache.sling.servlethelpers.MockSlingHttpServletRequest contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.SlingHttpServletResponse > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockSlingHttpServletResponse > contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.resource.Resource annotated with > @ProviderType should not be implemented by custom code. Detected in > org.apache.sling.servlethelpers.internalrequests.ServletResolutionResource > contained in >
[jira] [Commented] (SLING-10840) Sling Servlet Helpers implements @ProviderType interfaces
[ https://issues.apache.org/jira/browse/SLING-10840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17422003#comment-17422003 ] Carsten Ziegeler commented on SLING-10840: -- Yes, there are different use cases - many use cases I've seen so far could be solved by using the wrapper classes around an existing request/response. However, there seem to be some use cases like the one from David where even that does not help. But that could be solved in the dispatcher implementation. I think remaining are use cases, where you don't have a request/response and need to create an artifical one - this is where this bundle might come into play. We could think about adding a factory (or builder) api to the engine bundle as the engine bundle contains the processor service and locally these belong together. > Sling Servlet Helpers implements @ProviderType interfaces > - > > Key: SLING-10840 > URL: https://issues.apache.org/jira/browse/SLING-10840 > Project: Sling > Issue Type: Bug > Components: General >Affects Versions: Servlet Helpers 1.4.2 >Reporter: David Gonzalez >Priority: Major > > When using the Sling Servlet Helpers bundle/API, code quality scans detect > that implentations in the Sling Servlet Helpers bundle implement > @ProviderType interfaces from OTHER Sling bundles, which is not correct. Here > are some fo the examples (though probably not exhaustive) I found when > attempting to use ths Servlet Helpers library. > > |The product interface org.apache.sling.api.request.RequestParameter > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockRequestParameter contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.request.RequestParameterMap > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockRequestParameterMap contained > in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.request.RequestPathInfo annotated > with @ProviderType should not be implemented by custom code. Detected in > org.apache.sling.servlethelpers.MockRequestPathInfo contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.request.RequestProgressTracker > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockRequestProgressTracker > contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.SlingHttpServletRequest annotated > with @ProviderType should not be implemented by custom code. Detected in > org.apache.sling.servlethelpers.MockSlingHttpServletRequest contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.SlingHttpServletResponse > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockSlingHttpServletResponse > contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.resource.Resource annotated with > @ProviderType should not be implemented by custom code. Detected in > org.apache.sling.servlethelpers.internalrequests.ServletResolutionResource > contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > Perhaps there needs to be Wrappers for all these classes that are > @ConsumerTypes? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (SLING-10840) Sling Servlet Helpers implements @ProviderType interfaces
[
https://issues.apache.org/jira/browse/SLING-10840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17421977#comment-17421977
]
Bertrand Delacretaz edited comment on SLING-10840 at 9/29/21, 7:32 AM:
---
As stated in the docs at
[https://sling.apache.org/documentation/bundles/servlet-helpers.html] I think
one good reason to use the servlet helpers bundle in production is the
{{SlingInternalRequest}} and {{ServletInternalRequest}} helpers, which make
internal requests simple and clean. The {{org.apache.sling.graphql.core}}
bundle for example uses them.
I think these services correctly hide their implementation details, returning a
{{SlingHttpServletResponse}} for example, so changing the underlying
request/response objects should be possible if needed.
Maybe these services should have been implemented in a different bundle which
only exports the package that allows using them. The servlets helpers bundle
also exports the {{org.apache.sling.servlethelpers}} package, which IIUC
contains the problematic classes discussed here.
was (Author: bdelacretaz):
As stated in the docs at
[https://sling.apache.org/documentation/bundles/servlet-helpers.html] I think
one good reason to use the servlet helpers bundle in production is the
{{SlingInternalRequest}} and {{ServletInternalRequest}} helpers, which make
internal requests simple and clean.
I think these services correctly hide their implementation details, returning a
{{SlingHttpServletResponse}} for example, so changing the underlying
request/response objects should be possible if needed.
Maybe these services should have been implemented in a different bundle which
only exports the package that allows using them. The servlets helpers bundle
also exports the {{org.apache.sling.servlethelpers}} package, which IIUC
contains the problematic classes discussed here.
> Sling Servlet Helpers implements @ProviderType interfaces
> -
>
> Key: SLING-10840
> URL: https://issues.apache.org/jira/browse/SLING-10840
> Project: Sling
> Issue Type: Bug
> Components: General
>Affects Versions: Servlet Helpers 1.4.2
>Reporter: David Gonzalez
>Priority: Major
>
> When using the Sling Servlet Helpers bundle/API, code quality scans detect
> that implentations in the Sling Servlet Helpers bundle implement
> @ProviderType interfaces from OTHER Sling bundles, which is not correct. Here
> are some fo the examples (though probably not exhaustive) I found when
> attempting to use ths Servlet Helpers library.
>
> |The product interface org.apache.sling.api.request.RequestParameter
> annotated with @ProviderType should not be implemented by custom code.
> Detected in org.apache.sling.servlethelpers.MockRequestParameter contained in
> /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.|
> |The product interface org.apache.sling.api.request.RequestParameterMap
> annotated with @ProviderType should not be implemented by custom code.
> Detected in org.apache.sling.servlethelpers.MockRequestParameterMap contained
> in
> /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.|
> |The product interface org.apache.sling.api.request.RequestPathInfo annotated
> with @ProviderType should not be implemented by custom code. Detected in
> org.apache.sling.servlethelpers.MockRequestPathInfo contained in
> /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.|
> |The product interface org.apache.sling.api.request.RequestProgressTracker
> annotated with @ProviderType should not be implemented by custom code.
> Detected in org.apache.sling.servlethelpers.MockRequestProgressTracker
> contained in
> /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.|
> |The product interface org.apache.sling.api.SlingHttpServletRequest annotated
> with @ProviderType should not be implemented by custom code. Detected in
> org.apache.sling.servlethelpers.MockSlingHttpServletRequest contained in
> /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.|
> |The product interface org.apache.sling.api.SlingHttpServletResponse
> annotated with @ProviderType should not be implemented by custom code.
> Detected in org.apache.sling.servlethelpers.MockSlingHttpServletResponse
> contained in
> /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.|
> |The product interface org.apache.sling.api.resource.Resource annotated with
> @ProviderType should not be implemented by custom code. Detected in
>
[jira] [Commented] (SLING-10840) Sling Servlet Helpers implements @ProviderType interfaces
[
https://issues.apache.org/jira/browse/SLING-10840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17421977#comment-17421977
]
Bertrand Delacretaz commented on SLING-10840:
-
As stated in the docs at
[https://sling.apache.org/documentation/bundles/servlet-helpers.html] I think
one good reason to use the servlet helpers bundle in production is the
{{SlingInternalRequest}} and {{ServletInternalRequest}} helpers, which make
internal requests simple and clean.
I think these services correctly hide their implementation details, returning a
{{SlingHttpServletResponse}} for example, so changing the underlying
request/response objects should be possible if needed.
Maybe these services should have been implemented in a different bundle which
only exports the package that allows using them. The servlets helpers bundle
also exports the {{org.apache.sling.servlethelpers}} package, which IIUC
contains the problematic classes discussed here.
> Sling Servlet Helpers implements @ProviderType interfaces
> -
>
> Key: SLING-10840
> URL: https://issues.apache.org/jira/browse/SLING-10840
> Project: Sling
> Issue Type: Bug
> Components: General
>Affects Versions: Servlet Helpers 1.4.2
>Reporter: David Gonzalez
>Priority: Major
>
> When using the Sling Servlet Helpers bundle/API, code quality scans detect
> that implentations in the Sling Servlet Helpers bundle implement
> @ProviderType interfaces from OTHER Sling bundles, which is not correct. Here
> are some fo the examples (though probably not exhaustive) I found when
> attempting to use ths Servlet Helpers library.
>
> |The product interface org.apache.sling.api.request.RequestParameter
> annotated with @ProviderType should not be implemented by custom code.
> Detected in org.apache.sling.servlethelpers.MockRequestParameter contained in
> /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.|
> |The product interface org.apache.sling.api.request.RequestParameterMap
> annotated with @ProviderType should not be implemented by custom code.
> Detected in org.apache.sling.servlethelpers.MockRequestParameterMap contained
> in
> /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.|
> |The product interface org.apache.sling.api.request.RequestPathInfo annotated
> with @ProviderType should not be implemented by custom code. Detected in
> org.apache.sling.servlethelpers.MockRequestPathInfo contained in
> /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.|
> |The product interface org.apache.sling.api.request.RequestProgressTracker
> annotated with @ProviderType should not be implemented by custom code.
> Detected in org.apache.sling.servlethelpers.MockRequestProgressTracker
> contained in
> /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.|
> |The product interface org.apache.sling.api.SlingHttpServletRequest annotated
> with @ProviderType should not be implemented by custom code. Detected in
> org.apache.sling.servlethelpers.MockSlingHttpServletRequest contained in
> /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.|
> |The product interface org.apache.sling.api.SlingHttpServletResponse
> annotated with @ProviderType should not be implemented by custom code.
> Detected in org.apache.sling.servlethelpers.MockSlingHttpServletResponse
> contained in
> /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.|
> |The product interface org.apache.sling.api.resource.Resource annotated with
> @ProviderType should not be implemented by custom code. Detected in
> org.apache.sling.servlethelpers.internalrequests.ServletResolutionResource
> contained in
> /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.|
> Perhaps there needs to be Wrappers for all these classes that are
> @ConsumerTypes?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-10840) Sling Servlet Helpers implements @ProviderType interfaces
[ https://issues.apache.org/jira/browse/SLING-10840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17421976#comment-17421976 ] Carsten Ziegeler commented on SLING-10840: -- [~empire29] If any application (large CMS?) is using the bundle, that is fine as that application provides the implementation anyway. However, I would still suggest against doing this, but that's more a question of style then. For users of an application, this is different. As soon as you use this bundle, you are subject to breakage. I'm fine with changing the documentation around the bundle and if SLING-8742 solves the use case, we have a much better solution anyway > Sling Servlet Helpers implements @ProviderType interfaces > - > > Key: SLING-10840 > URL: https://issues.apache.org/jira/browse/SLING-10840 > Project: Sling > Issue Type: Bug > Components: General >Affects Versions: Servlet Helpers 1.4.2 >Reporter: David Gonzalez >Priority: Major > > When using the Sling Servlet Helpers bundle/API, code quality scans detect > that implentations in the Sling Servlet Helpers bundle implement > @ProviderType interfaces from OTHER Sling bundles, which is not correct. Here > are some fo the examples (though probably not exhaustive) I found when > attempting to use ths Servlet Helpers library. > > |The product interface org.apache.sling.api.request.RequestParameter > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockRequestParameter contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.request.RequestParameterMap > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockRequestParameterMap contained > in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.request.RequestPathInfo annotated > with @ProviderType should not be implemented by custom code. Detected in > org.apache.sling.servlethelpers.MockRequestPathInfo contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.request.RequestProgressTracker > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockRequestProgressTracker > contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.SlingHttpServletRequest annotated > with @ProviderType should not be implemented by custom code. Detected in > org.apache.sling.servlethelpers.MockSlingHttpServletRequest contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.SlingHttpServletResponse > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockSlingHttpServletResponse > contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.resource.Resource annotated with > @ProviderType should not be implemented by custom code. Detected in > org.apache.sling.servlethelpers.internalrequests.ServletResolutionResource > contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > Perhaps there needs to be Wrappers for all these classes that are > @ConsumerTypes? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-10840) Sling Servlet Helpers implements @ProviderType interfaces
[ https://issues.apache.org/jira/browse/SLING-10840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17421974#comment-17421974 ] Robert Munteanu commented on SLING-10840: - I guess what you actually want then is SLING-8742 :-) > Sling Servlet Helpers implements @ProviderType interfaces > - > > Key: SLING-10840 > URL: https://issues.apache.org/jira/browse/SLING-10840 > Project: Sling > Issue Type: Bug > Components: General >Affects Versions: Servlet Helpers 1.4.2 >Reporter: David Gonzalez >Priority: Major > > When using the Sling Servlet Helpers bundle/API, code quality scans detect > that implentations in the Sling Servlet Helpers bundle implement > @ProviderType interfaces from OTHER Sling bundles, which is not correct. Here > are some fo the examples (though probably not exhaustive) I found when > attempting to use ths Servlet Helpers library. > > |The product interface org.apache.sling.api.request.RequestParameter > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockRequestParameter contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.request.RequestParameterMap > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockRequestParameterMap contained > in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.request.RequestPathInfo annotated > with @ProviderType should not be implemented by custom code. Detected in > org.apache.sling.servlethelpers.MockRequestPathInfo contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.request.RequestProgressTracker > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockRequestProgressTracker > contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.SlingHttpServletRequest annotated > with @ProviderType should not be implemented by custom code. Detected in > org.apache.sling.servlethelpers.MockSlingHttpServletRequest contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.SlingHttpServletResponse > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockSlingHttpServletResponse > contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.resource.Resource annotated with > @ProviderType should not be implemented by custom code. Detected in > org.apache.sling.servlethelpers.internalrequests.ServletResolutionResource > contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > Perhaps there needs to be Wrappers for all these classes that are > @ConsumerTypes? -- This message was sent by Atlassian Jira (v8.3.4#803005)
