Implementation of ExceptionListener prevents decoration possibility of Symfonys ErrorListener

[masonen]

API Platform version(s) affected: ^2.5.x

Description
Current implementation of ExceptionListener prevents the possibility to decorate the Symfony\Component\HttpKernel\EventListener\ErrorListener.

The ErrorListener is autowired for the API-Platform ExceptionListener with the use of its concrete implementation. When decorating the Symfony ErrorListner the decorated class is passed to the API-Platform ExceptionListener. This will cause an issue as the decorated service is not an instance of Symfony\Component\HttpKernel\EventListener\ErrorListener. This will fail with an exception while loading the application.

How to reproduce
Decorate the Symfony\Component\HttpKernel\EventListener\ErrorListener following the SF-Guidelines https://symfony.com/doc/current/service_container/service_decoration.html

Possible Solution
One obvious solution would presume change in Symfony: If the Symfony\Component\HttpKernel\EventListener\ErrorListener would implement a dedicated interface this interface could be autowired instead of the concrete service implementation. This interface could than be implemented by the decorated service and should cause no issues.

Additional Context
Although one pretty straight forward approach to fix this is at hand I'd like to discuss further options here first before initiating a feature request on Symfonys end.

[alanpoulain]

Why not decorating the ExceptionListener of API Platform itself?

[masonen]

Wouldnt it then still need an instance of ExceptionListener when autowiring the inner Service

[alanpoulain]

You will receive the API Platform ExceptionListener as the inner service, yes. Like any decoration.

[masonen]

my point beeing that this inner ExceptionListener (API-Platform) would then still need a instance of Symfony ErrorListener which is not availiable as it was already decorated.

[alanpoulain]

The inner ExceptionListener service will receive the ErrorListener without issue (if the ErrorListener service is not decorated of course).
Try it, you shouldn't have any issue 🙂

[masonen]

Yes that of course, aggreed. But my requirement here was that I need to be able to decorate only the Symfony listener as I needed to extend the functionality of the protected function logException() inside the Symfony service in order to fufill some requirements dictated by our lagacy application we build uppon.

This could not be achieved with a decoration of the API-Platform service as this is not implementing this function and just forwarding the handling to the symfony listener.

I needed this change to be in this listener in order to have available in (all) other listeners that also build on this listners (yes there are multiple :D)

My current workaround would be to go for a non decorating aproach and extend the Symfony listener completly. This would then be an instance of the Symfony listener causing no problems with the API-Platform listener.

I was just thinking that this might be an adressable issue in the first place to avoid API-Platform hinderinge one to decorate the symfony listener.

[alanpoulain]

Decorating the Symfony service means that you can access only the public methods, isn't it?

[masonen]

pardon me i mixed that up ofc. I decorated the onKernelException function.

The log exception function was extended with the override aproach as it would fufill my requirement.

[alanpoulain]

OK I understand your issue. Very specific one though.
We could always replace the ErrorListener by the EventSubscriberInterface but we would be not sure about receiving a service with the onKernelException method.

[masonen]

its very specific indeed. and you are right. you cant be sure to have this function if using that Interaface. Thats why i wanted it to be discussed. As there is a workaround with replacing this by a override approach thats also not pressing for me.

If it is considered to specific to be an general issue im totally fine with that. But i would be still much interested in other opinions.

Thank you for taking your time so far :)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[soyuka]

I think we fixed this since that in #4861