Skip to content

Overwriting ObjectManager's $sharedResources leads to strange DI behaviour #3835

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.

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

Closed
adragus-inviqa opened this issue Mar 18, 2016 · 4 comments

Comments

@adragus-inviqa
Copy link
Contributor

Steps to reproduce

  1. M2 2.0.2
  2. In developer mode (don't think it matters though), inject \Psr\Log\LoggerInterface into any constructor.

Expected result

  1. Logging using \Psr\Log\LoggerInterface should produce lines in system.log, debug.log, exception.log or support_report.log, depending on level etc.

Actual result

  1. Everything gets logged into support_report.log, including exceptions, layout debug info etc.

More info

We've recently upgraded to 2.0.2 and it dawned to me that nothing but a few lines were logged into system.xml, exception.log was empty even though I had one, my debugging logging wasn't working etc.

Investigating the problem, I saw that \Magento\Framework\Logger\Monolog (thus \Monolog\Logger) was instantiated 2 times: firstly, with 2 handlers: system and debug (normal handlers), secondly, with only one handler: Magento\Support\Model\Logger\Handler\Report. I would expect those three handlers to be merged.

I originally thought some error had slipped when upgrading, and the ObjectManager got instantiated twice, as when searching for \Psr\Log\LoggerInterface, the manager couldn't find it, so it created it again, but this time with the second handler.

But that wasn't the case: the manager was instantiated only once. The reason it couldn't find the original logger (with the 2 handlers) was that the $sharedInstances was being replaced:

.

The conclusion is that the original $sharedInstances which contains a logger instance is getting replaced with another instance with different handlers.

Maybe it's something in our app, but it's worth some investigation, maybe? I also find this a little flaky, as between grabbing the original resources and up until the new ones are loaded, various other instances are created, which will eventually be replaced.

@antonkril
Copy link
Contributor

It looks like main reason for such behavior is the way how di.xml is merged between stages.
system & debug handlers are registered in initial configuration (app/etc/di.xml)

But in global configuration of Support Module (Support/etc/di.xml) Support logger is registered. It overrides previous configuration, because arguments defined at later stages of configuration override arguments defined on previous stage of configuration. I can see, that system & debug handlers are already added in etc/di.xml of latest version of Support module.

Quick fix for you is to register them in /etc/di.xml of your module.

@adragus-inviqa
Copy link
Contributor Author

Thanks for the quick reply, @antonkril; I'll try your suggestion.

I can see, that system & debug handlers are already added in etc/di.xml of latest version of Support module.

Are you saying that the system and debug handlers are added once again in the Support module, besides the main app/etc/di.xml file?

@katmoon katmoon added the PS label Mar 22, 2016
@antonkril
Copy link
Contributor

Yes, because global configuration overrides arguments configuration of primary configuration.

@adragus-inviqa
Copy link
Contributor Author

Seems a bit duplicating.
But if Support is the module which declares the logging handlers, so be it.
Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants