Isn't this missingAbstractController support?

IMO it should be the role of the DI component to call thesetContainer method, maybe by adding this magic method call behind theautoconfigure option.

Why doesn'tAbstractController implementContainerAwareInterface?

Because PSR 11 isn't compatible with it.

The PR now handles theAbstractController class too now.

Have you already tried with the DI Extra Bundle ?
I doubt it'll work (for those using the bundle. I don't really get other broken cases), unless I missed something, as itreplaces the controller resolver used and theimplementation does not make use of the parent. Perhaps@bogdaniel or@trappar could confirm.

Why do we need to inject container if the controller is autowired? If one is changing the controllers to new autowired way it should expect to remove the direct access to the container along the way.
IMO it this should be marked as deprecated since 3.4 and removed in 4.0

I agree. It also feels weird injecting it at runtime in a service. In#23200 (comment) I suggested another fix allowing thesetContainer call to be properly autowired, which I guess should also work for those using the JMSDIExtraBundle. Having a controller as service with the whole container injection kind of defeat the purpose of defining it as a service. Still, there are real issues which needs to be fixed, as proven in the related issues.

I think the container can still be useful in a controller even with autowiring. For instance autowiring cannot be used when the service to be called is only known at runtime (from the db for instance):

public function myAction(){$dynamicServiceName = ... $dynamicService = $this->container->get($dynamicServiceName)...}

Of course, using the container that way is not usually a good practice, but I believe that in some situations it can help reduce code size...

I just checked again and this is only an issue I was able to reproduce with routes registered by FOSRestBundle. The routes that are being registered then reference the controller with a pattern likeAppBundle\Controller\UserController:getAction while routes registered with Symfony's annotation loader have two colons (and only in this caseinstantiateController() will be called and thus injecting the container).

@ogizanagi I am 99% sure you're right about this not fixing the issues with the DI Extra Bundle, but that's probably something that needs to be addressed in that bundle, not here.

yeah, if JMSDIExtraBundle replaces the whole resolver without reusing the Symfony implementation through decoration or inheritance, it means they have to update their bundle each time Symfony adds a new feature. This is their issue.

But the same goes for fos rest: is it normal to use the single colon notation usually used for controller as services ?

@ogizanagi IIRC, maybe they wanted to define the route for container as a service.

@ogizanagi Actually it's one colon for services and two for controller classes that must be instantiated by the controller resolver.

@xabbuh no. 2 colons is not for services. It is for normal callables (as it is the syntax used for callables in PHP)

seeFriendsOfSymfony/FOSRestBundle#1721 whichcould also be a fix

However, I still think that the main inconsistency is that theControllerResolver from the FrameworkBundle is sometimes callingsetContainer() even if the controller is registered as a service, but that whether or not this is done depends on the notation of the_controller attribute.

@stof good catch, I fixed my comment accordingly

hmm, actually, can we have a test covering this case to prevent regressions ?

I'll check

tests added

Thank you@xabbuh.