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

Skip to content

[6.3] non-existent resolver Symfony\Bridge\Doctrine\ArgumentResolver\EntityValueResolver #50081

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
PhilETaylor opened this issue Apr 20, 2023 · 13 comments · Fixed by #50088
Closed

[6.3] non-existent resolver Symfony\Bridge\Doctrine\ArgumentResolver\EntityValueResolver #50081

PhilETaylor opened this issue Apr 20, 2023 · 13 comments · Fixed by #50088
Labels
Bug DoctrineBridge Status: Needs Review

Comments

@PhilETaylor
Copy link
Contributor

PhilETaylor commented Apr 20, 2023 •
edited
Loading

Symfony version(s) affected

6.3.x-dev

Description

I had a fully working 6.2 app and I upgraded to 6.3.x-dev as a test.

My controller has some new (and working in 6.2) MapEntity attributes like

 #[MapEntity(mapping: [
            'location_id' => 'id',
        ])] Locations $location,

Since [HttpKernel] Introduce pinnable value resolvers with #[ValueResolver] and #[AsPinnedValueResolver] #48992 was merged I now get this error

ScreenShot-2023-04-20-18 06 50

Sorry way beyond me...

Ping @MatTheCat

How to reproduce

Here is a reproducer - https://github.com/PhilETaylor/mapentity_reproducer

To create this reproducer I did

  • composer create-project symfony/skeleton bug_app
  • change composer.json to allow 6.3.x and dev stability
  • composer require orm
  • composer require symfony/maker-bundle --dev
  • use maker bundle to create a controller - edit the controller to add the MapEntity
  • use maker bundle to create an entity
  • symfony serve
  • go to http://127.0.0.1:8000/bug - you can see the error there

Possible Solution

Pay @MatTheCat some sponsorship... incoming.... Edit: No sponsor button :-(

Additional Context

I can "fix" this for my own purposes with this in services.php so maybe its a tagging issue?

$services->set(\Symfony\Bridge\Doctrine\ArgumentResolver\EntityValueResolver::class)
        ->tag('doctrine.orm.entity_value_resolver');
@MatTheCat
Copy link
Contributor

Maybe your DoctrineBundle does not include doctrine/DoctrineBundle#1624? It was added in the 2.9.0 version.

@PhilETaylor
Copy link
Contributor Author

PhilETaylor commented Apr 20, 2023 •
edited
Loading

I can confirm that the file at: vendor/doctrine/doctrine-bundle/Resources/config/orm.xml in the reproducer

contains

        <service id="doctrine.orm.entity_value_resolver" class="Symfony\Bridge\Doctrine\ArgumentResolver\EntityValueResolver">
            <argument type="service" id="doctrine" />
            <argument type="service" id="doctrine.orm.entity_value_resolver.expression_language" on-invalid="ignore" />
            <tag name="Symfony\Bridge\Doctrine\ArgumentResolver\EntityValueResolver" priority="110">controller.argument_value_resolver</tag>
        </service>

The composer.json having contained "doctrine/doctrine-bundle": "2.10.x-dev",

@MatTheCat
Copy link
Contributor

Okay it seems it has to do with #36586 as the name attribute of XML defined tags is not returned by Definition::getTag. Does it ring a bell @nicolas-grekas?

@MatTheCat
Copy link
Contributor

MatTheCat commented Apr 21, 2023 •
edited
Loading

It seems the right syntax for adding attributes to tags using XML is not the one mentioned in #36586

The syntax mentioned in #36586 does no longer work, but the following does:

<tag name="controller.argument_value_resolver" priority="110">
    <attribute name="name">Symfony\Bridge\Doctrine\ArgumentResolver\EntityValueResolver</attribute>
</tag>

Also the documentation is wrong because an attribute tag without a name attribute would trigger an exception…

@stof
Copy link
Member

stof commented Apr 21, 2023

The documentation is not wrong actually. There is only a special case when wanting to add an attribute named name in XML to avoid conflicts with the tag name.

@stof
Copy link
Member

stof commented Apr 21, 2023

however, the documentation should probably cover that special case, which is not the case right now.

@MatTheCat
Copy link
Contributor

Given

symfony/src/Symfony/Component/DependencyInjection/Loader/XmlFileLoader.php

Lines 658 to 663 in 24b1b02

$children = $this->getChildren($node, 'attribute');
foreach ($children as $childNode) {
if ('' === $name = $childNode->getAttribute('name')) {
throw new InvalidArgumentException($missingName);
}
wouldn’t the documentation code crash?

<tag name="app.mail_transport">
    <attribute>sendmail</attribute>
    <attribute>anotherAlias</attribute>
</tag>

I thought #36586 allowed to have a name attribute as long as the tag name was the tag tag text content 🤔

@stof
Copy link
Member

stof commented Apr 21, 2023

Ok, apparently, the documentation was updated in the wrong way after #36586 (contrary to the comment on symfony/symfony-docs#13613 saying that the doc did not needed any update)

@MatTheCat
Copy link
Contributor

Seems #36586 is broken for XML since 6.2, probably because of #47364

@MatTheCat MatTheCat mentioned this issue Apr 21, 2023
Merged
@MatTheCat
Copy link
Contributor

I opened #50088 to illustrate the cause of this bug.

The actual state of the documentation is another issue (<attribute> tags are missing a name XML attribute).

@PhilETaylor
Copy link
Contributor Author

PhilETaylor commented Apr 21, 2023 •
edited
Loading

Thanks for your time investigating this. Really appreciate it personally, but seems like it could have been a bigger issue if it had not been caught now.

@PhilETaylor
Copy link
Contributor Author

Closing as fixed by proposed PR #50088

@MatTheCat MatTheCat mentioned this issue Apr 21, 2023
Merged
@MatTheCat
Copy link
Contributor

I don’t think the issue would have been bigger (one patch version away?), but it’s indeed better if features added in 6.3 work when it is released 😁

So thanks for testing!

nicolas-grekas added a commit that referenced this issue Apr 21, 2023
@nicolas-grekas
bug #50088 [DependencyInjection] Do not ignore tags name attribute …
6f77fa0 
…when it does not define their name (MatTheCat)

This PR was squashed before being merged into the 6.2 branch.

Discussion
----------

[DependencyInjection] Do not ignore tags `name` attribute when it does not define their name

| Q             | A
| ------------- | ---
| Branch?       | 6.2
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Tickets       | Fix #50081
| License       | MIT
| Doc PR        | N/A

Tags `name` attribute is ignored using XML if the tag name is its node content. That means `<tag name="name_attribute">tag_name</tag>` will return a `tag_name` tag without any attribute.

This seems to be a regression from #36586.

Commits
-------

4c9c688 [DependencyInjection] Do not ignore tags `name` attribute when it does not define their name
OskarStark added a commit to symfony/symfony-docs that referenced this issue Apr 26, 2023
@OskarStark
bug #18240 [DependencyInjection] Fix XML tag array attribute example …
9a65a6c 
…(MatTheCat)

This PR was merged into the 6.2 branch.

Discussion
----------

[DependencyInjection] Fix XML tag array attribute example

Fixes #17932 (and closes #17395)

Spotted in symfony/symfony#50081 (comment)

The syntax is a bit awkward but it is how it works for now.

Commits
-------

7ccec46 Fix XML tag array attribute example
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug DoctrineBridge Status: Needs Review
Projects
None yet
Milestone
No milestone
5 participants
@PhilETaylor @stof @MatTheCat @xabbuh @carsonbot