Skip to content

[Kernel][Container] Scope inconsistency #6985

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.

Sign up for GitHub

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

Jump to bottom
Closed
marcospassos opened this issue Feb 6, 2013 · 3 comments
Closed

[Kernel][Container] Scope inconsistency #6985

marcospassos opened this issue Feb 6, 2013 · 3 comments
Labels
HttpKernel

Comments

@marcospassos
Copy link

Hello,

I'm working on a multitenant application, using a multiple schema database approach. The context of my application is defined by the domain. So, I've a Doctrine listener that changes all entities schemas at runtime. The problem is I'm getting the following exception:

<service id="acme.subscriber.set_schema" class="Path/To/Class" public="false">
    <argument type="service" id="router.request_context"></argument>
    <call method="setContainer">
        <argument type="service" id="service_container" />
    </call>
    <tag name="doctrine.event_subscriber" />
</service>
public function loadClassMetadata(LoadClassMetadataEventArgs $args)
{
     $request = $this->container->get('request');
}

Results in:

InactiveScopeException: You cannot create a service ("request") of an inactive scope ("request").

IMO, it seems like a contradiction. Once it is a http request, the request scope should not always be active? Furthermore, injecting the RouteContext, the returned host is localhost (the default value). I cant understand why the Context have not been initialized yet, once the request is one of the first things that is created:

$kernel = new AppKernel('dev', true);
//$kernel->loadClassCache();
$request = Request::createFromGlobals();
$response = $kernel->handle($request);

Is this a bug or an expected behavior?
@igorw
Copy link
Contributor

igorw commented Feb 6, 2013

The problem is that there can be sub-requests, and any service that depends on the request must be re-created for the scope of the sub-request. Then restored once the sub-request is completed. For this reason, any service that depends on any other request-scoped service must also be scoped to the request.

Long story short, afaik scoping your subscriber to the "request" scope should fix the problem.

@marcospassos
Copy link
Author

I don't think so. I think it happens due services dependencies requested during Kernel->handle call.

@marcospassos marcospassos mentioned this issue Feb 7, 2013
Merged
2 tasks
@fabpot
Copy link
Member

fabpot commented Mar 23, 2013

Now that #7007 has been merged, you can just use a setter to get the request. It should fix your issues (the request context issue you mention should also be fixed now). Can you confirm and close this ticket?

@fabpot fabpot closed this as completed Apr 21, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
HttpKernel
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@fabpot @igorw @marcospassos