@stof can you please check this. (typos and posible mistakes)

@mayeco Can you do the same for all bundles?

@fabpot yes

Done@fabpot.

@fabpot What should I do with this tests?

$this->assertSame('Symfony\Component\Validator\Validator\ValidatorInterface', $container->getParameter('validator.class'));

@mayeco assert the service class instead

@stof the Validator2.4/2.5/2.5_BC workaround is going to be removed in 3.0, so that test should be remove also, right?.

@mayeco only when the 2.4 API is removed. Until then, you need to keep it

And as I commented in some diff which has been hidden, you need to update the FrameworkExtension so that it updates the service class directly instead of setting the parameter

@stof for now lets keep the validator.class in this PR and I do other for the validator with the change in the parameter depending the api version, is that ok?

@mayeco you can already remove the validator.class parameter in this PR (making the work of this PR complete). The only requirement is that you update other places setting this parameter, not only the XML file (and check for other parameters as well to see whether we have some code setting them elsewhere)

@fabpot is done, but%validator.class% remain invalidator.xml sincechange in runtime and I don't know internally the proper method to do it, and using decorator since is a veryundocumented feature, is that ok with you@stof, can we leave this as it is and do a new PR for the proper way to change a container class.

@mayeco As I said previously, you should change the FrameworkExtension to get the service definition and change its class directly. This will let you get rid of the parameter. the class is not changed at runtime. It is changed at configuration time.

Decorators have nothing to do with this case.

and can you rebase your PR to fix conflicts (the master branch has changed since last month)

Rebasing is near to impossible, so I've created a new PR from scratch#14070