[HttpKernel][HttpFoundation] Prototype: Service reset as middleware #24697
Conversation
|
Wondering a bit about this, I think we should just provide a (private) service that just calls the reset methods. |
| <argument key="$services" /> <!-- ResettableServicePass will inject an iterator of initialized services here ($serviceId => $serviceInstance) --> | ||
| <argument key="$resetMethods" type="collection" /> <!-- ResettableServicePass will inject an array of reset methods here ($serviceId => $method) --> | ||
| </service> | ||
| <service id="http_kernel" alias="Symfony\Component\HttpKernel\Middleware\ServiceResetMiddleware" public="true" /> |
There was a problem hiding this comment.
Rather than doing this (which makes the HttpKernel typehint autowirable btw), I would rather keep the http_kernel as it is currently, and then use service decoration when the reset middleware is needed
There was a problem hiding this comment.
Since we do not implement a switch for turning off that feature (which was the whole point of moving the reset to the beginning), the middleware would technically be always present.
There was a problem hiding this comment.
But I agree that enabling HttpKernel for autowiring could cause accidents. ;-)
|
Introducing the concept of middlewares between betas is probably not a good idea. @nicolas-grekas as I had a little chat and we agreed on providing the service resetter as a service, so PHP-PM and whoever else would want to fire multiple requests against For Symfony 4.1, I will look into generalizing middlewares, as I think they could be a helpful extension point. And maybe we can reenable the automatism again, then. |
|
See alternative in #24709 |
|
Closing in favor of #24709 |
…) (nicolas-grekas) This PR was merged into the 3.4 branch. Discussion ---------- [HttpKernel] Move services reset to Kernel::handle()+boot() | Q | A | ------------- | --- | Branch? | 3.4 | Bug fix? | yes | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #24552 | License | MIT | Doc PR | - This is an alternative to #24697 (which uses middlewares). This PR adds a new `services_resetter` service that the Kernel calls on 2nd root requests to reset services. Instead of #24697 which plans for optional enabling of the services reset, this approach moves the responsibility of calling the services resetter to the core Kernel class, so that no configuration/middleware/etc. is required at all, and no overhead exists at all for regular requests. Commits ------- 4501a36 [HttpKernel] Move services reset to Kernel
This PR drafts an alternative approach to #24689.
Problem
The problem of #24552 is that #24155 introduced a behavior change of the
kernel.terminateevent because services were reset after a request has been processed. This caused issues with existing tests written withWebTestCasethat tried to assert the state of certain services after a request.Approach
The idea behind the approach of this PR is that the affected services could very well be reset at the very beginning of a new request. Because we reset the profiler that collects data from the event dispatcher, we need to perform the reset before the event dispatcher is used for the first time.
Since Symfony does not have a proper extension point for this kind of functionality, I propose to add the service reset as a middleware between
KernelandHttpKernel, making it transparent to both of them.Alternatives
RequestStackwhich so far only was a plain and simple data structure. That PR would introduce a somewhat unexpected side effect.ServiceResetListenerinto a regular public service that is directly being called byKernel::handle(). This would avoid the middleware, but would allow us to easily refactor the feature into a middleware if we decide to introduce that concept later.