Fork Symfony's ContainerAwareTrait and ContainerAwareInterface into core

Not quite sure what to do, the actual status would be PP-2, since this is waiting on the commit of both children of 📌 [META] Reduce use of ContainerAware classes where possible Active to get rid of all the deprecation warnings.

But maybe someone wants to review the current state, so leave it on NW on my name for now.

Adding what this is postponed on to the remaining tasks per Remining tasks → .

Changing parent to the S7 compatibility issue, so we find all the related issues.

But maybe someone wants to review the current state, so leave it on NW on my name for now.

Hmm. This looks like a situation where the new tag "Needs architectural review" can help. Adding tag and setting to NR.

The event dispatcher just receives the entire container as an argument:

  event_dispatcher:
    class: Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher
    arguments: ['@service_container']

Can we just do this for the services that need it instead of copying the ContainerAware feature?

Can we just do this for the services that need it instead of copying the ContainerAware feature?

Since I have no clue what this means, I'm quickly un-assigning myself so somebody else can pick this up.

It just means injecting the whole container as a service via a constructor argument, instead of using the ContainerAwareTrait/Interface helpers.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Spokje → closed merge request !5182

This is the best I could do. I think I've changed all non-factory services to use the container in their constructor and deprecated all the (previously inherited) setContainer methods.

Started working on some Factories, but I fear these will not work with constructors having a service container argument, since the container might not be ready yet?

It passes tests, but I would like some confirmation from somebody who actually knows what she/he is doing before continuing.

As I see in the MR5181 is the trait is removed but not replaced with fork, so summary needs update

Issue title said we gonna fork but MR doing replacement which is better to do as rector's rule to be reusable for contrib/custom code

IMO fixing just a namespace is preferable way, with follow-up to remove usage as the change very disruptive

Believe #13 is enough for NW? If not feel free to put back.

I've already hit this as in our project we're rejecting code triggering deprecations. It happened when some dependency updated Symfony from 6.3.5 to 6.4.1. Not sure whether to apply this patch or to pin Symfony

Here's a small patch to remove the deprecation from Symfony because you can't pin to 6.3.5 and use Drupal 10.2.1

So it looks like in many of these cases we should be using service locators instead of injecting the entire container.

CacheFactory, CacheTagsInvalidator, CheckProvider, StreamWrapperManager, KernelDestructionSubscriber all look like they could use this technique.

EntityTypeManager and ClassResolver are more tricky and need access to the entire container, but I think we could just inject the container as a service in these cases.

Actually, KernelDestructionSubscriber can't use this because a service locator is a separate mini-container, and the destructor needs to know if each individual service was actually used in the main container.

Opened 📌 Convert KernelDestructionSubscriber to use configurators Active for a slightly hacky way of dealing with KernelDestructionSubscriber.

Opened 📌 Convert StreamWrapperManager to use a service locator Needs review to try out using a service locator in StreamWrapperManager.

📌 Allow needs_destruction services to run on page cache hits Needs review removes KernelDestructionSubscriber entirely, so 📌 Convert KernelDestructionSubscriber to use configurators Active can be closed if that lands.

Opened 📌 Notify downstream users that ContainerAware is going away Needs review which would mean this can be closed as won't fix.

📌 Notify downstream users that ContainerAware is going away Needs review landed and we should be able to remove ContainerAware support entirely from Drupal 11 in 📌 [PP-2] Remove support for ContainerAwareInterface Postponed .

quietone → closed merge request !5181