We could extend the contract for SlingRequestListener - which is called
for the main request already from Sling Engine and let it call those
listeners for internal requests as well (with new types).
If we want to be on the save side, we could require a special
registration property to opt-in for listeners.
Regards
Carsten
On 27.05.2023 11:40, Carsten Ziegeler wrote:
Hi,
I fear this will not work :) the fake/internal request might be within
the context of a real request or outside of it. However, if it is within
the context of a real request, it might share the request attributes. In
that case, for example the servlet request listener from the auth core
bundle will close the resource resolver. Sling Models might also not be
prepared for it. Other listeners might do the wrong thing, too.
In other words, I don't think we can find a way that magically does the
right thing.
The problem that seems to need fixing is clean up of resources when
Sling Models are used. So maybe it is better/safer to concentrate on
just that.
Regards
Carsten
On 26.05.2023 18:33, Konrad Windszus wrote:
I added a draft in
https://github.com/apache/sling-org-apache-sling-engine/pull/35/files#.
Feel free to have a look and take over if you deem that useful.
Haven’t tested it yet…
Konrad
On 26. May 2023, at 17:32, Konrad Windszus <[email protected]> wrote:
I think this can be implemented with the
HttpServiceRuntime.getRuntimeDRO[1] which should return all
registered event listeners [2] through its ServletContextDTO (also
the ServletRequestListener registered by ModelAdapterFactory).
The question is though when to call the according events, as the
synthetic SlingHttpServletRequest has no explicit close method.
This probably needs to be done by the SlingProcessor which needs to
distinguish between requests created by the servlet container and
these virtual requests.
Don’t know how to distinguish those properly to check that, maybe by
evaluating the requests getServletContext() return value to check if
this is a fake context or a real one…
Konrad
[1]
https://docs.osgi.org/javadoc/r6/cmpn/org/osgi/service/http/runtime/HttpServiceRuntime.html#getRuntimeDTO()
[2]
https://docs.osgi.org/javadoc/r6/cmpn/org/osgi/service/http/runtime/dto/ListenerDTO.html
On 26. May 2023, at 16:41, Jörg Hoh <[email protected]>
wrote:
Hi,
In AEM we have for quite some time "fake" implementations of
SlingHttpServletRequest and SlingHttpServletResponse, which are used as
parameters for the SlingProcessor to render content.
We came across issues when SlingModels are involved in the rendering
process. We found that this approach can create memory leaks when OSGI
services are injected into sling models, and these are created
during the
rendering process of such a "fake request". The problem is that the
unregistering of these OSGI references is triggered by a
ServletRequestEvent which the ModelAdapterFactory receives as it
registers
as a ServletRequestListener. But these fake classes do not implement
these
methods at all.
Checking the sling equivalents in [1] I don't see them implementing
these
functionality as well, thus they show the same problem. Would there
be some
interest to have this functionality implemented in Sling? (I am not an
expert in the servlet spec, so don't expect anything soon from my
side...)
Jörg
[1]
https://github.com/apache/sling-org-apache-sling-api/tree/master/src/main/java/org/apache/sling/api/request/builder
--
Cheers,
Jörg Hoh,
https://cqdump.joerghoh.de
Twitter: @joerghoh
--
Carsten Ziegeler
Adobe
[email protected]
