Problem
- Only the
Requestis persisted acrossDrupalKernelrebuilds currently, theRequestStackis lost entirely.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | drupal8.request-stack.8.patch | 3.51 KB | sun |
| #4 | drupal8.request-stack.3.patch | 3.13 KB | sun |
| #2 | drupal8.request-stack.2.patch | 2.54 KB | sun |
| drupal8.request-stack.0.patch | 2.98 KB | sun |
Comments
Comment #1
znerol commentedThere is no need for custom persistence logic for the request stack, we simple can tag the service with the persist tag.
The reason behind special-casing the request service is that we need to cater for the request scope. We do not have this problem with the request stack.
Comment #2
sunReplaced custom persistence code in
DrupalKernelwith 'persist' tag on request_stack service.The other adjustments are still required, since the 'persist' logic only applies to
DrupalKernel::updateModules(), but those instances are replacing theDrupalKernelaltogether with a new instance.Comment #3
dawehnerThis is good for now!
Comment #4
sunGrepping for
'new DrupalKernel'yielded another instance of a custom kernel in update.php, which also doesn't useHttpKernelyet.For completeness, including the grep results:
Comment #8
sunTests for the interactive installer (
InstallerTestBase) are calling intorebuildContainer()to boot into the newly installed site environment after installation, but at that point,$this->containerstill contains the super-minimal container fromTestBase::prepareEnvironment(), which does not have request stack.Attached patch adjusts
TestBase::rebuildContainer()for that, including comment to explain the situation.Comment #9
sunBack to RTBC, I guess. Only difference in latest patch is the compatibility fix for
InstallerTestBase.Comment #10
znerol commentedHa, just was about the RTBC that. The fix for the installer test makes sense.
Comment #11
sunJust to clarify:
@znerol and I briefly discussed whether we could add any sensible tests here.
However, the manual
DrupalKernel(re)builds are not worth to test, because pretty much all of them are caused by legacy code that is slated for removal.If at all, I was thinking about the persistence in
DrupalKernel::updateModules(), but that should be covered by'persist'tag tests already.Thus, what we're fixing here is essentially just a malformed service definition. There's an upper limit of sensible tests, and an incomplete/incompatible/malformed service definition exceeds that limit.
Comment #12
catch