> > The case is what we discussed in [1]. There we came to the
> conclusion
> > to use a RequestEventListener. Otherwise we have to add a lifecycle
> > method like close or similar to the resource resolver or even to the
> > CredentialValidator where it definitly makes no sense.
> > So what's about using RequestEventListener?
> To my mind, two key things need to happen:
> 1) Felix's patch to FELIX-1962 should be applied.
> 2) Felix HttpService 2.0.6 is released
>
> But I'm not sure we should be depending on a Felix-specific interface
> (ExtHttpService) in such a key piece of code. What really should be
> happening is to merge Felix HttpService's ExtHttpService
> interface into
> OSGi's HttpService interface (as HttpService version 2.0).
>
> Justin
I agree, we shouldn't depend on a specific implementation.
Another solution would be to provide a new Sling specific "white
board pattern listener service":
We could allow services to register as SlingRequestListener.
SlingMainServlet then could call all registered Services while
dispatching the request.
The interface for this service could be similar to
ServletRequestListener:
public interface SlingRequestListener
{
void requestDestroyed ( SlingRequestEvent sre )
void requestInitialized ( SlingRequestEvent sre )
}
SlingRequestEvent should return the request itself (either
SlingHttpServletRequest if possible or HttpServletRequest).
Or we could do it in a more generic way and define a few events.
for every or all events a SlingRequestListener could register
to, which I would prefer. To start there's only the RequestInitEvent
and the RequestDestroyedEvent. The interface could look something
like
public interface SlingRequestListener
{
void onEvent ( SlingRequestEvent sre )
}
With this solution we could avoid to depend on a specific implementation
of HttpService at all and the effort to implement this feature
isn't that big I think.
WDYT?
best regards
mike
