composer create-project --repository=https://repo.magento.com/ magento/project-community-edition magento2
php bin/magento setup:install --base-url=http://241.loc/ --db-host=mysql --db-name=241 --db-user=root --db-password= --admin-firstname=Magento --admin-lastname=User [email protected] --admin-user=admin --admin-password=admin123 --language=en_US --currency=USD --timezone=America/Chicago --use-rewrites=1 --search-engine=elasticsearch7 --elasticsearch-host=elastic --elasticsearch-port=9200
Fatal error: Declaration of Psr\Log\LoggerInterface\Proxy::emergency($message, array $context) must be compatible with Psr\Log\LoggerInterface::emergency($message, array $context = NULL) in /shared/httpd/24/htdocs/magento2/generated/code/Psr/Log/LoggerInterface/Proxy.php on line 93
public function alert($message, array $context)
However, if you change them directly to:
public function alert($message, array $context = array())
The command will then run successfully, however it will break all bin/magento setup:xxx commands the next time the code is regenerated.
Hi @msyhr. Thank you for your report.
To help us process this issue please make sure that you provided the following information:
Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:
@magento give me 2.4-develop instance
- upcoming 2.4.x release
For more details, please, review the Magento Contributor Assistant documentation.
Please, add a comment to assign the issue: @magento I am working on this
Join Magento Community Engineering Slack and ask your questions in #github channel.
:warning: According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.
:clock10: You can find the schedule on the Magento Community Calendar page.
:telephone_receiver: The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, please join the Community Contributions Triage session to discuss the appropriate ticket.
:movie_camera: You can find the recording of the previous Community Contributions Triage on the Magento Youtube Channel
:pencil2: Feel free to post questions/proposals/feedback related to the Community Contributions Triage process to the corresponding Slack Channel
As a side note, repeating this above process in the identical environment, but specifying:
composer create-project --repository=https://repo.magento.com/ magento/project-community-edition=2.4.0 magento2
successfully install the software. Then updating the composer.json entry to
"magento/product-community-edition": "2.4.1"
will cause the same issue.
experiencing the same issue
Hi @sdzhepa. Thank you for working on this issue.
In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:
Issue: Format is valid
will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid
appears.[ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description
label to the issue by yourself.
[ ] 3. Add Component: XXXXX
label(s) to the ticket, indicating the components it may be related to.
[ ] 4. Verify that the issue is reproducible on 2.4-develop
branchDetails
- Add the comment @magento give me 2.4-develop instance
to deploy test instance on Magento infrastructure.
- If the issue is reproducible on 2.4-develop
branch, please, add the label Reproduced on 2.4.x
.
- If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and _stop verification process here_!
[ ] 5. Add label Issue: Confirmed
once verification is complete.
[ ] 6. Make sure that automatic system confirms that report has been added to the backlog.
Hello @msyhr qsolutions-pl
@ihor-sviziev @lbajsarowicz
Thank you for collaboration!
After multiple attempts on different envs and sked different people to check it on their envs
We are not able to reproduce this issue by the provided steps.
At this point, I suppose some important steps/configuration/etc. information is missed in the description.
As possible advice, I would propose to clean composer caches
composer clearcache
Tested on next envs configurations:
Tested using the next steps
composer create-project --repository=https://repo.magento.com/ magento/project-community-edition magento2
composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition=2.4.1 magento2_2
Install magento using CLI script from the description
Result: Magento sucessfuly installed. No Fatal errors. Sorefront is available
Hi @sdzhepa, I have the same bug with PHP 7.4.11. But if I use PHP 7.3 , The class Proxy created correctly.
bin/magento setup:di:compile
PHP Fatal error: Declaration of Psr\Log\LoggerInterface\Proxy::emergency($message, array $context) must be compatible with Psr\Log\LoggerInterface::emergency($message, array $context = NULL) in m2/generated/code/Psr/Log/LoggerInterface/Proxy.php on line 93
/usr/bin/php7.3 bin/magento setup:di:compile
- This works without the bugs.
Hi @Knase,
Question 1: there might be incorrect php version used. what is php -v shows for you with php 7.4?
Question 2: are you using some extensions that adds plug-in to the logger? If so - could you provide some sample module in order to be able to reproduce the issue?
I am using php 7.4.11
php -v
PHP 7.4.11 (cli) (built: Oct 18 2020 19:39:42) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Zend OPcache v7.4.11, Copyright (c), by Zend Technologies
with Xdebug v2.9.8, Copyright (c) 2002-2020, by Derick Rethans
I installed magento 2.4.1
composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition=2.4.1 m2
bin/magento setup:install \
--base-url=http://magento.ll \
--backend-frontname=admin \
--db-host=localhost \
--db-name=magento \
--db-user=magento \
--db-password=magento \
--admin-firstname=admin \
--admin-lastname=admin \
[email protected] \
--admin-user=magento \
--admin-password=magento \
--language=en_US \
--currency=USD \
--timezone=America/Chicago \
--search-engine=elasticsearch7 \
--elasticsearch-host=localhost \
--elasticsearch-port=9200 \
--use-rewrites=1;
I got the fatal error during bin/magento setup:install
. I fixed the file generated/code/Psr/Log/LoggerInterface/Proxy.php
. But if I run the command bin/magento setup:di:compile
or remove the file generated/code/Psr/Log/LoggerInterface/Proxy.php
, Magento 2 will create this file with errors.
@Knase could you provide your composer.lock file?
Probably with exact the same package versions we'll be able to reproduce this issue
@ihor-sviziev
There is my the composer.lock file
composer.lock.txt
I have same issue on after upgrading Magento Cloud 2.3.6 to 2.4.1 version with PHP 7.3.23.
This error happens on setup:upgrade
and any other commands of bin/magento
$ php -v
PHP 7.3.23 (cli) (built: Oct 13 2020 10:38:39) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.23, Copyright (c) 1998-2018 Zend Technologies
with Zend OPcache v7.3.23, Copyright (c) 1999-2018, by Zend Technologies
with Xdebug v2.9.8, Copyright (c) 2002-2020, by Derick Rethans
with blackfire v1.42.0~linux-x64-non_zts73, https://blackfire.io, by Blackfire
UPD:
After downgrade Magento to 2.4.0 this error didn't show anymore.
I'm using Docker LAMP stack "Devilbox"
Re-opening since other people seem to be running into this issue now.
Some Information from me about my setup:
I'm using https://github.com/cytopia/devilbox for local development
OS 20.04.1 LTS (Focal Fossa)
Docker version 19.03.13, build 4484c46d9d
`[email protected] in /shared/httpd/magento2/htdocs $ php -v
PHP 7.4.9 (cli) (built: Aug 6 2020 19:20:05) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Zend OPcache v7.4.9, Copyright (c), by Zend Technologies
Virtual Host Below:
magento2.txt
`
Composer Lock Below:
composer.lock.txt
Still fails every time for me. Using a version in the composer command (2.4.0) works flawlessly. Upgrade will create the issue, create-project with no version will create the issue.
@sdzhepa @sidolov could you try to reproduce this issue again? Seems like more people getting this issue. This is quite critical issue
Same issue with the upgrade from 2.3.x to 2.4.0 / 2.4.1
@ihor-sviziev @qsolutions-pl @Knase @msyhr
Thank you for the details
I asked my team to review and investigate it one more time.
Previously we investigated it quite deeply and 4 persons tested it no different envs....
Seems some important precondition or condition or step is missed
I guess, for me that was a file permissions problem. These steps help me, when I upgrading from 2.4.0 to 2.4.1:
sudo chown -R :apache .
(for Devilbox I used my user as owner - sudo chown -R 1000:1000 .
)rm -rf generated/code/*
UPD: No, that ^ worked when I up project on the Magento Docker. But when I back to the Devilbox LAMP stack again (PHP 7.3.23 and 7.4.11) - error still persists. It seems to be an environment problem
Hi @msyhr @qsolutions-pl,
Could you try to remove the generated/ folder? Does the issue reproducing after that?
@msyhr Have you found any solution?
Hi @engcom-Delta. Thank you for working on this issue.
In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:
Issue: Format is valid
will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid
appears.[ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description
label to the issue by yourself.
[ ] 3. Add Component: XXXXX
label(s) to the ticket, indicating the components it may be related to.
[ ] 4. Verify that the issue is reproducible on 2.4-develop
branchDetails
- Add the comment @magento give me 2.4-develop instance
to deploy test instance on Magento infrastructure.
- If the issue is reproducible on 2.4-develop
branch, please, add the label Reproduced on 2.4.x
.
- If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and _stop verification process here_!
[ ] 5. Add label Issue: Confirmed
once verification is complete.
[ ] 6. Make sure that automatic system confirms that report has been added to the backlog.
@msyhr @qsolutions-pl Unfortunately I am not able to reproduce issue with clean magento installation on my enviroment
Could you please clarify again:
Is this clean magento installation on clean database?
Or it is magento upgrade?
I was not able to reproduce the issue on my machine.
Server version: Apache/2.4.29 (Ubuntu)
PHP 7.4.11
@msyhr @qsolutions-pl Unfortunately I am not able to reproduce issue with clean magento installation on my enviroment
Could you please clarify again:
Is this clean magento installation on clean database?
Or it is magento upgrade?
Clean install clean DB (environment information in my last post)
Installing 2.4.0 works successfully (specifying the version in the composer create-project)
Installing with no version or upgrading via changing version in composer.json after a working 2.4.0 install causes the issue. I'm going to try to replicate this on one of our Dev servers instead of via local dev (docker) and report back.
Hi @msyhr @qsolutions-pl,
Could you try to remove the generated/ folder? Does the issue reproducing after that?
Same result, command fails as soon as the broken proxy is created. The only way I've gotten past this step is by manually changing the functions. However, this fails again as soon as generated/ is cleared again.
@ihor-sviziev
No sure if this would be of any help. Zip of my generated folder. This is what is created when I run the setup:install CLI after composer create-project has finished.
@msyhr I tried fresh magento installation without version on the composer create-project step - installation successfully
Env:
Testing scenario 1:
composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition .
php bin/magento setup:install --base-url=http://magento2dev.loc/ --db-host=localhost --db-name=magento2dev --db-user=root --db-password="123123q" --admin-firstname=Magento --admin-lastname=User [email protected] --admin-user=admin --admin-password=123123q --language=en_US --currency=USD --timezone=America/Chicago --use-rewrites=1 --search-engine=elasticsearch7 --elasticsearch-host=localhost --elasticsearch-port=9200
Testing scenario 2:
composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition=2.4.0 .
php bin/magento setup:install --base-url=http://magento2dev.loc/ --db-host=localhost --db-name=magento2dev --db-user=root --db-password="123123q" --admin-firstname=Magento --admin-lastname=User [email protected] --admin-user=admin --admin-password=123123q --language=en_US --currency=USD --timezone=America/Chicago --use-rewrites=1 --search-engine=elasticsearch7 --elasticsearch-host=localhost --elasticsearch-port=9200
cp composer.json composer.json.bak
composer remove magento/product-community-edition --no-update
composer require magento/product-community-edition=2.4.1 --no-update
composer update
rm -rf var/cache/*
rm -rf var/page_cache/*
rm -rf generated/code/*
bin/magento setup:upgrade
@engcom-Bravo @engcom-Dash could either of you provide your phpinfo(); for you setups. I'd like to compare with my docker instance as this now has to be an ENV issue on my end (devilbox)
same issue upgrading from 2.3.5 to 2.4.1, downgraded to 2.4.0 solved
PHP 7.3.23
@msyhr sure.
Clean install 2.4.1, php 7.3.23
composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition .
Question - are you using composer 1.x or composer 2? Version 2 is not currently supported
Hi Team,
I am facing this issue with vanilla installation
PHP Fatal error: Declaration of PsrLogLoggerInterfaceProxy::emergency($message, array $context) must be compatible with PsrLogLoggerInterface::emergency($message, array $context = NULL) in /var/www/html/m241/generated/code/Psr/Log/LoggerInterface/Proxy.php on line 93
My environment:
OS : Linux Mint 18.2 Sonya
PHP: 7.4.11
Composer: 1.10.13
Magento: 2.4.1
With PHP 7.3, it is not working for me either !
Hi @ihor-sviziev, I'm using Composer version 1.10.16
Interesting... I just tried to do the same on php 7.4 and php 7.3 - issue isn't reproducing for me as well.
Could someone who have this issue post those two files?
generated/code/Psr/Log/LoggerInterface/Proxy.php
vendor/psr/log/Psr/Log/LoggerInterface.php
Or even full project (clean installation, w/o any custom extensions)?
Hi @ihor-sviziev
here are mines
Archive.zip
Interesting... files vendor/psr/log/Psr/Log/LoggerInterface.php are equal, but in your generated/code/Psr/Log/LoggerInterface/Proxy.php
we have
/**
* {@inheritdoc}
*/
public function emergency($message, array $context)
{
return $this->_getSubject()->emergency($message, $context);
}
while in my I have
/**
* {@inheritdoc}
*/
public function emergency($message, array $context = [])
{
return $this->_getSubject()->emergency($message, $context);
}
Default value is not defined. Checking...
Hi @ihor-sviziev, I'm using Composer version 1.10.16
Even i have issue with this composer version as well
Interesting... I just tried to do the same on php 7.4 and php 7.3 - issue isn't reproducing for me as well.
Could someone who have this issue post those two files?
generated/code/Psr/Log/LoggerInterface/Proxy.php vendor/psr/log/Psr/Log/LoggerInterface.php
Or even full project (clean installation, w/o any custom extensions)?
PFA files for your reference, i am facing this in vanilla installation as well !
@textarea @krisdass still don't have any valid idea.
I just looked that code actually generated from
https://github.com/magento/magento2/blob/170425c4ddf139ceda21288452ef06e0e464afa1/lib/internal/Magento/Framework/ObjectManager/Code/Generator/Proxy.php#L86 ->
https://github.com/magento/magento2/blob/170425c4ddf139ceda21288452ef06e0e464afa1/lib/internal/Magento/Framework/ObjectManager/Code/Generator/Proxy.php#L122 ->
https://github.com/magento/magento2/blob/170425c4ddf139ceda21288452ef06e0e464afa1/lib/internal/Magento/Framework/ObjectManager/Code/Generator/Proxy.php#L169 ->
https://github.com/magento/magento2/blob/5a836abef542dffa23bd131f74d9f9afc9860c17/lib/internal/Magento/Framework/Code/Generator/EntityAbstract.php#L380-L395 ->
https://github.com/magento/magento2/blob/5a836abef542dffa23bd131f74d9f9afc9860c17/lib/internal/Magento/Framework/Code/Generator/EntityAbstract.php#L356-L371
And basically in this method it goes ValueGenerator is actually LaminasCodeGeneratorValueGenerator.
I just looked - seems like all these places weren't changed since magento 2.3 (except switching from Zend to Laminas, but no real changes were there), also the latest Laminas code package version was released on December 2019 https://github.com/laminas/laminas-code/releases/tag/3.4.1
Now I have following ideas:
In order to process further investigation, could someone from you provide following things?
php -v
php -i
Hi @ihor-sviziev. Thank you for working on this issue.
In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:
Issue: Format is valid
will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid
appears.[ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description
label to the issue by yourself.
[ ] 3. Add Component: XXXXX
label(s) to the ticket, indicating the components it may be related to.
[ ] 4. Verify that the issue is reproducible on 2.4-develop
branchDetails
- Add the comment @magento give me 2.4-develop instance
to deploy test instance on Magento infrastructure.
- If the issue is reproducible on 2.4-develop
branch, please, add the label Reproduced on 2.4.x
.
- If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and _stop verification process here_!
[ ] 5. Add label Issue: Confirmed
once verification is complete.
[ ] 6. Make sure that automatic system confirms that report has been added to the backlog.
@ihor-sviziev
magento full code in https://we.tl/t-I5WRn8yUvM, php -i info in attached phpinfo.txt and php version in attached phpversion.txt
phpinfo.txt
phpversion.txt
@textarea I see you have installed psr pecl extension. I believe it might cause such issues. Could you try to remove/disable it, remove all files from generated/code/
folder and try again?
I have the same issue. I upgraded Magento via composer.json from 2.3.5-p2 to 2.4.1.
PHP version is: 7.3.20
If I manually modify the file (generated/code/Psr/Log/LoggerInterface/Proxy.php to has a default value of $context to NULL, then Magento starts working again.
Oddly the exact same files are working fine when I use them on an instance with PHP 7.3.22 (with Docker container) but have the issue with using 7.3.20 without Docker.
@ihor-sviziev I followed your advice and removed the PSR extension. It worked! I checked with my docker container and it doesn't have it installed. So it makes sense why it was working there but not on the environment without docker. I had the extension installed because I also have Phalcon based site on that machine too.
Thanks! ... now I have to remove Phalcon :D
@ihor-sviziev yes it works after psr pecl remove.
Also for me now phalcon has to be removed ;)
Thanks!
For everyone who will have the same issue:
please check if you have installed psr
php extension (you could check it with php -m
).
In case if it's installed - please uninstall or disable it and remove all files from the generated/code/
folder.
✔ Issue should be solved.
I'm closing this issue.
As the issue is inside psr
php extension - I just reported issue to github repo https://github.com/jbboehr/php-psr/issues/78.
Any Idea why we need remove extension instead fix code generated ?
@pusachev I strongly believe this is the issue in the psr pecl extension. I'm going to report it soon to their issue tracker
@textarea @krisdass still don't have any valid idea.
I just looked that code actually generated from
https://github.com/magento/magento2/blob/170425c4ddf139ceda21288452ef06e0e464afa1/lib/internal/Magento/Framework/ObjectManager/Code/Generator/Proxy.php#L86And basically in this method it goes ValueGenerator is actually LaminasCodeGeneratorValueGenerator.
I just looked - seems like all these places weren't changed since magento 2.3 (except switching from Zend to Laminas, but no real changes were there), also the latest Laminas code package version was released on December 2019 https://github.com/laminas/laminas-code/releases/tag/3.4.1
Now I have following ideas:
- you have somehow different version of some package than me
- you have some different php settings than me.
In order to process further investigation, could someone from you provide following things?
- full zip of the code for clean magento installation that fails for you
- php version in the CLI - run following comand:
php -v
- php configuration in the CLI - run following comand:
php -i
Hi @ihor-sviziev
PHP Version
PHP 7.4.11 (cli) (built: Oct 10 2020 19:44:32) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Zend OPcache v7.4.11, Copyright (c), by Zend Technologies
with Xdebug v2.9.8, Copyright (c) 2002-2020, by Derick Rethans
PHP Info attached
php_details.txt
Hi @krisdass,
Please review my comment https://github.com/magento/magento2/issues/30575#issuecomment-721704953, seems like you just need to remove psr php extension.
Hi @ihor-sviziev,
Actually i need to run code scanning with magento2 PSR standards. I use codesniffer and code beautifier cbf to do this.
For this PSR module is required i think.
Let me try and update you.
@krisdass I think it shouldn't be required, but definitely let us know if it is
@ihor-sviziev : since this was reported by many people, I think we need to do something properly about this.
Could we maybe add the following to the composer.json
file?
"conflict": {
"ext-psr": "*"
},
@hostep good point, but I hope it will be fixed on the php extension side soon, so it will not be correct. Let's wait at least for some response.
PS: issue already reported https://github.com/jbboehr/php-psr/issues/78
@ihor-sviziev Even if it is fixed on the extension level, there will be instances that could not/will not upgrade that easily. Could we at least update documentation (https://devdocs.magento.com/guides/v2.4/install-gde/system-requirements-tech.html) and add another note that "specific version XX.XX of extension PSR can caused issue"?
Hi @ihor-sviziev,
I was able to set the project and run commands after disabling php psr module.
I will check & update about codesiffer & code beautifier tool output !
Thanks @ihor-sviziev
:white_check_mark: Confirmed by @ihor-sviziev
Thank you for verifying the issue. Based on the provided information internal tickets MC-38918
were created
Issue Available: @ihor-sviziev, _You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself._
I created PR for updating docs in order to highlight that psr
php extension might cause such issues.
https://github.com/magento/devdocs/pull/8185
Hi @ihor-sviziev. Thank you for working on this issue.
Looks like this issue is already verified and confirmed. But if you want to validate it one more time, please, go though the following instruction:
Component: XXXXX
label(s) to the ticket, indicating the components it may be related to.2.4-develop
branch@magento give me 2.4-develop instance
to deploy test instance on Magento infrastructure. 2.4-develop
branch, please, add the label Reproduced on 2.4.x
.Ok... we got responce from the author of psr
extension, seems like PHP 7 API isn't supporting default values, so it can't be fixed for php 7.3 and php 7.4, but could be fixed for php 8.0, and it will be done in https://github.com/jbboehr/php-psr/pull/79.
So currently we have three options:
psr
php extension with Magento 2 to the docs - I already did in https://github.com/magento/devdocs/pull/8185, hope someone will review it soonpsr
extension in the magento2For now I think adding just a warning to the docs should be enough, I still thinking about implementation of 2nd or maybe 3rd option.
@zenfork and any others using Devilbox running into this issue, I can confirm disabling the psr extension solves the issue.
You'll need to edit the entry to add "psr" in the .env of your devilbox root.
PHP_MODULES_DISABLE=oci8,PDO_OCI,pdo_sqlsrv,sqlsrv,rdkafka,swoole,psr,phalcon
Hey. I have a question. Why we need create proxy for LoggerInterface object? What this profit we have from this "optimization"?
Maybe make sense remove proxy from DI class and this is fix problem in install.
@pusachev TBH I don't really know. Feel free to investigate it 😃
This issue is also related to an upgrade
:
2.3.4 -> 2.4.0
2.3.5 -> 2.4.0
2.3.6 -> 2.4.0
and the same with upgrade to 2.4.1
@qsolutions-pl FYI we added info that psr
extension causing issue to the docs in https://github.com/magento/devdocs/pull/8185:
https://devdocs.magento.com/guides/v2.4/install-gde/system-requirements.html
@pusachev @ihor-sviziev I bumped into this same issue and was able to solve it by removing the PSR extension (Ubuntu with PHP 7.3: apt-get remove php7.3-psr
).
However, the question of @pusachev intrigued me: Why is the proxy needed in the first place?
I tried it and this gave the error Circular dependency: Magento\Framework\Logger\Monolog depends on Magento\Framework\Interception\PluginListGenerator
. In other words, the reason why a DI proxy is needed is to fix the circular dependency at constructor time, while at the moment a method of PluginListGenerator
is called where logging is needed, this issue is fixed already. So, there is no (easy) way to remove the proxy itself.
@jissereitsma I believe the only one valid fix will be introducing some not dynamically created logger proxy with the same logic inside
Most helpful comment
Hey. I have a question. Why we need create proxy for LoggerInterface object? What this profit we have from this "optimization"?
Maybe make sense remove proxy from DI class and this is fix problem in install.