Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

HypeMC
Copy link
Member

@HypeMC HypeMC commented Aug 25, 2025

Q A
Branch? 7.4
Bug fix? no
New feature? yes
Deprecations? no
Issues -
License MIT

When configuring services like normalizers for a named serializer or Monolog processors for specific channels/handlers, autoconfiguration can get in the way.

For example, the NormalizerInterface is registered for autoconfiguration.
If I try to register a custom normalizer for a specific named serializer, it also gets registered with the default serializer because of autoconfiguration:

#[AutoconfigureTag(
    name: 'serializer.normalizer',
    attributes: [
        'serializer' => 'my_named_serializer',
    ],
)]
class MyNormalizer implements NormalizerInterface {}

Currently, the only way around this is to disable autoconfiguration entirely:

services:
    App\MyNormalizer:
        autoconfigure: false
        tags:
            - serializer.normalizer: { serializer: 'my_named_serializer' }

This PR introduces a new inherit_configuration option for service definitions and a #[WithoutInheritedConfiguration] attribute.
Both allow skipping the inheritance of instanceof conditionals from parent classes or interfaces:

#[AutoconfigureTag(
    name: 'serializer.normalizer',
    attributes: [
        'serializer' => 'my_named_serializer',
    ],
)]
#[WithoutInheritedConfiguration]
class MyNormalizer implements NormalizerInterface {}

It can also be used to exclude specific services from inheriting _instanceof configurations:

services:
    _defaults:
        autowire: true
        autoconfigure: true

    _instanceof:
        App\SomeInterface:
            tags: ['some.tag']

    App\SomeInterfaceImplementation:
        inherit_configuration: false # This implementation won't inherit instanceof config

Why a new attribute?

I initially tried adding a new argument to the existing #[Autoconfigure] attribute.
However, this attribute itself is resolved via instanceof conditionals.
I could try something like $conditionals[$class], but since the attribute is repeatable, it’s unclear how to handle cases like:

#[Autoconfigure(inheritConfiguration: false)]
#[Autoconfigure(inheritConfiguration: true)]
class MyClass {}

@HypeMC HypeMC force-pushed the without-inheritance branch from ddf1359 to 3fb5849 Compare August 25, 2025 01:27
@nicolas-grekas
Copy link
Member

Thanks for the detailed description.
I'd prefer not adding this, because it means more exceptions to the rules of autoconfiguration.
But I do understand why it might be needed :)

Before, let me challenge the proposal:

  • What about not ignoring a serializer.normalizer tag with no name when another one exists with a name? that'd be something to deal with in the compiler pass
  • Please expand on Monolog channels/handlers so that we can wonder about similar more specific rules?

@HypeMC
Copy link
Member Author

HypeMC commented Aug 25, 2025

@nicolas-grekas Hi. Yeah, I see your point about exceptions. I'm not sure how many cases like this there actually are.

What about not ignoring a serializer.normalizer tag with no name when another one exists with a name? that'd be something to deal with in the compiler pass

I'm assuming you meant ignore the one without a name. I agree, that would solve the serializer case. However, there might be other cases besides this and the Monolog one.

Please expand on Monolog channels/handlers so that we can wonder about similar more specific rules?

Here's a simple example:

#[AsMonologProcessor('my_channel')]
final class MyProcessor implements ProcessorInterface
{
    public function __invoke(LogRecord $record) {}
}

You'd expect this processor to be registered only for my_channel, but because ProcessorInterface is registered for autoconfiguration, the processor is added to all channels.

The workaround is the same, disable autoconfiguration and add an explicit tag.

services:
    App\MyProcessor:
        autoconfigure: false
        tags:
            - monolog.processor: { channel: 'my_channel' }

@nicolas-grekas
Copy link
Member

nicolas-grekas commented Aug 25, 2025

I'd like to see how my proposal fits before looking for a more generic solution, to lower the overall complexity of things...

@HypeMC
Copy link
Member Author

HypeMC commented Aug 26, 2025

@nicolas-grekas Please see #61526. I've opened it as a bug fix cause it seems like one, if need I'll switch to 7.4.

fabpot added a commit that referenced this pull request Aug 26, 2025
…specify a named one (HypeMC)

This PR was merged into the 7.3 branch.

Discussion
----------

[Serializer] Don't fallback to default serializer if tags specify a named one

| Q             | A
| ------------- | ---
| Branch?       | 7.3
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Issues        | -
| License       | MIT

An alternative to #61511.

Commits
-------

e442a38 [Serializer] Don't fallback to default serializer if tags specify a named one
@fabpot
Copy link
Member

fabpot commented Aug 26, 2025

Closing in favor of #61526

@fabpot fabpot closed this Aug 26, 2025
@HypeMC HypeMC deleted the without-inheritance branch August 26, 2025 07:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants