EZP-30546: Cache service has wrong instance on command line

[andrerom]

Question	Answer
JIRA issue	EZP-30546
Bug/Improvement	yes
Target version	7.5
BC breaks	no
Tests pass	yes
Doc needed	no

Cache service being in wrong instance seems to be caused by a few things:

• Changes in 2.5 where ezplublish.cache_pool.inner service was introduced ( 8baa4f4) seems to cause it to no longer be lazy loaded.
  • I'm actually a bit unsure why, however opted to move lazy definition to same as had this before: ezpublish.cache_pool.
• The loading was caused by command services that rely on repo services, these are loaded long before console event is triggered and siteaccess is set. To avoid similar issues like this in the future, take advantage of Symfony 3.4 feature to lazy load command services by setting name on tag.

TODO:

• Implement feature / fix a bug.
• Implement tests.
• Fix new code according to Coding Standards ($ composer fix-cs).
• Ask for Code Review.

[andrerom]

PR is ready for Review, failure on AppVeyor is unrelated.

[alongosz]

Uh, I rather aimed to autowire and autoconfigure commands at some point :(
+1 anyway.

[andrerom]

Uh, I rather aimed to autowire and autoconfigure commands at some point :(

And there is no way to make them lazy then unless you change to make them container aware instead then right? ... :P

[alongosz]

Uh, I rather aimed to autowire and autoconfigure commands at some point :(

And there is no way to make them lazy then unless you change to make them container aware instead then right? ... :P

Yeah, I know, just complaining to complain ;) Seems we have no other choice for now.

[andrerom]

Well, lazy commands is not an option for 6.7 and 6.13 as it's Symfony 3.4+ only. So if you dislike them we can skip them.

The solution is then always 1. Use Config Resolver 2. For services made with factory that depends on SA config, opt for using lazy service.

And of course somehow figure out to detect when loaded to early as is WIP on the other PR.