Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork9.7k
[RFC][DependencyInjection][HttpKernel] Kernel as a service#19606
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
GuilhemN commentedAug 13, 2016 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
What about instead removing the concept of obsolete definitions ? Imo it could be considered as a bug fix as this behavior is clearly not expected. |
ro0NL commentedAug 13, 2016 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
Marking a definition as obsolete when the same id is overwritten by a synthetic service object sounds logical to me. I think the "problem" is a synthetic service needs to be tight to a definition id... im not sure we wanna change that, i guess this is by design. But yeah, setting the kernel instance along with a synthetic definition, in early phase could work also for feature 2, now that i think of it. However feature 1 for would still be useful as it allows for non-synthetic definitions + service object to be set. edit: Btw.. it becomes real quirky in edit2: yeah extensions are still an issue 😭 |
| $serviceDefinition =newServiceAwareDefinition($serviceClass,array($this->environment,$this->debug,$bundles)); | ||
| $serviceDefinition->setService(new$serviceClass($this->environment,$this->debug,$bundles)); | ||
| $container =$this->buildContainer(); | ||
| $container->setDefinition('kernel_as_a_service',$serviceDefinition); |
ogizanagiAug 13, 2016 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
edit: Btw.. it becomes real quirky in MergeExtensionConfigurationPass (see my first attempt) where synthetic services are vanished anyway during extension loading ;-)
—#19606 (comment)
If you want to use this service in an extension, you'll still have to do quirky things inMergeExtensionConfigurationPass as in your first attempt to make it available in the$tmpContainer passed to theExtensionInterface::load method, right ?
Or perhaps you're only targeting compiler passes now ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Working on it ;-)... however there are some design choices to be made.
| }catch (ServiceNotFoundException$e) { | ||
| if (ContainerInterface::EXCEPTION_ON_INVALID_REFERENCE !==$invalidBehavior) { | ||
| return; | ||
| if ($this->compiled && ContainerInterface::EXCEPTION_ON_INVALID_REFERENCE ===$invalidBehavior) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
For BC, however i tend to debug unknown id's before state. Just throwing here would be fine by me.
ro0NL commentedAug 13, 2016
This is also highly related to#19192 i guess. |
ro0NL commentedAug 19, 2016
Favoring#19646 |
Uh oh!
There was an error while loading.Please reload this page.
TLDR; This allows for ready to use service objects during container compilation~~.~~, and now also extension loading.
How i did it;
After my firstattempt i think i got a viable solution now that allows to work withsafe service objects during container compilation, basically it introduces a
ServiceAwareDefinition; a service definition aware of its service object, which is allowed for inContainerBuilder::get. It's bulletproof, in a way it's developer responsibility to keep the definition+service in sync. This also plays well with synthetic services perhaps...This is feature 1, which can be a separate PR. Feature 2 is introducing the kernel as a service (aware definition). For now i think it's good mainly because of pragmatic reasons; we can fix bugs in a normal way. In the long run it allows for separation of concerns; kernel/bundles in the ecosystem (booting, building, terminating) and kernel/bundles in userland (paths, names, utility).
The second concept is far from ready, but what about this approach?