[
https://issues.apache.org/jira/browse/SLING-10840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
> /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)
