Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Autowiring in abstract classes with DI in Symfony 3.3, is it possible? #23998

Copy link
Copy link
Closed
@reypm

Description

@reypm
Issue body actions
Q A
Bug report? yes
Feature request? no
BC Break report? no
RFC? no
Symfony version 3.6.6

I am moving a Symfony 3.2 project to Symfony 3.3 and I would like to use DI new features. I have read the docs but so far I can make this to work. See the following class definition:

    use Http\Adapter\Guzzle6\Client;
    use Http\Message\MessageFactory;

    abstract class AParent
    {
        protected $message;
        protected $client;
        protected $api_count_url;
    
        public function __construct(MessageFactory $message, Client $client, string $api_count_url)
        {
            $this->message       = $message;
            $this->client        = $client;
            $this->api_count_url = $api_count_url;
        }
    
        public function getCount(string $source, string $object, MessageFactory $messageFactory, Client $client): ?array
        {
            // .....
        }
    
        abstract public function execute(string $source, string $object, int $qty, int $company_id): array;
        abstract protected function processDataFromApi(array $entities, int $company_id): array;
        abstract protected function executeResponse(array $rows = [], int $company_id): array;
    }
    
    class AChildren extends AParent
    {
        protected $qty;
    
        public function execute(string $source, string $object, int $qty, int $company_id): array
        {
            $url      = $this->api_count_url . "src={$source}&obj={$object}";
            $request  = $this->message->createRequest('GET', $url);
            $response = $this->client->sendRequest($request);
        }
    
        protected function processDataFromApi(array $entities, int $company_id): array
        {
            // ....
        }
    
        protected function executeResponse(array $rows = [], int $company_id): array
        {
            // ....
        }
    }

This is how my app/config/services.yml file looks like:

    parameters:
        serv_api_base_url: 'https://url.com/api/'
    
    services:
        _defaults:
            autowire: true
            autoconfigure: true
            public: false
        
        CommonBundle\:
            resource: '../../src/CommonBundle/*'
            exclude: '../../src/CommonBundle/{Entity,Repository}'
        
        CommonBundle\Controller\:
            resource: '../../src/CommonBundle/Controller'
            public: true
            tags: ['controller.service_arguments']
        
        # Services that need manually wiring: API related
        CommonBundle\API\AParent:
            arguments:
                $api_count_url: '%serv_api_base_url%'

But I am getting the following error:

AutowiringFailedException Cannot autowire service
"CommonBundle\API\AChildren": argument "$api_count_url" of method
"__construct()" must have a type-hint or be given a value explicitly.

Certainly I am missing something here or simply this is not possible which leads me to the next question: is this a poor OOP design or it's a missing functionality from the Symfony 3.3 DI features?

Of course I don't want to make the AParent class an interface since I do not want to redefine the methods on the classes implementing such interface.

Also I do not want to repeat myself and copy/paste the same functions all over the children.

After read "How to Manage Common Dependencies with Parent Services" I have tried the following in my scenario:

    CommonBundle\API\AParent:
        abstract: true
        arguments:
            $api_count_url: '%serv_api_base_url%'

    CommonBundle\API\AChildren:
        parent: CommonBundle\API\AParent
        arguments:
            $base_url: '%serv_api_base_url%'
            $base_response_url: '%serv_api_base_response_url%' 

But the error turns into:

Attribute "autowire" on service "CommonBundle\API\AChildren" cannot be
inherited from "_defaults" when a "parent" is set. Move your child
definitions to a separate file or define this attribute explicitly in
/var/www/html/oneview_symfony/app/config/services.yml (which is being
imported from "/var/www/html/oneview_symfony/app/config/config.yml").

However I could make it to work with the following setup:

    CommonBundle\API\AParent:
        arguments:
            $api_count_url: '%serv_api_base_url%'

    CommonBundle\API\AChildren:
        arguments:
            $api_count_url: '%serv_api_base_url%'
            $base_url: '%serv_api_base_url%'
            $base_response_url: '%serv_api_base_response_url%'

I have tried this third way to achieve this but it didn't work either since the objects arrive NULL to the child class:

// services.yml
services:
    CommonBundle\EventListener\EntitySuscriber:
        tags:
            - { name: doctrine.event_subscriber, connection: default}

    CommonBundle\API\AParent:
        abstract: true
        arguments:
            - '@httplug.message_factory'
            - '@httplug.client.myclient'
            - '%ser_api_base_url%'

// services_api.yml
services:
    CommonBundle\API\AChildren:
        parent: CommonBundle\API\AParent
        arguments:
            $base_url: '%serv_api_base_url%'
            $base_response_url: '%serv_api_base_response_url%'

// config.yml
imports:
    - { resource: parameters.yml }
    - { resource: security.yml }
    - { resource: services.yml }
    - { resource: services_api.yml }

Why the objects are NULL in the child class?

What is the right way to achieve this inheritance from DI? Advice? Is this possible? Is this a bug?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      Morty Proxy This is a proxified and sanitized view of the page, visit original site.