Force lazy loading listeners during container compilation #822
Comments
|
Well, the way to enforce lazy-loading is to mark the listener as lazy. But here, the actual issue I see is that some service is doing an HTTP request in its constructor. That's the service being bad in a DI environment (the Doctrine listener is one of its consumers, but you could have others with the same kind of issues) |
|
Yes, you're right. But we could never expect all classes being designed to cater to a container compilation kind of scenario. The reason why I ask if we could force lazy loading during container compilation is because it'll be an easy win. (Think the 80/20 rule.) And actually, it wouldn't be a problem what classes do in their constructors as they usually should not get instantiated during container compilation. It is Doctrine that is causing them to get instantiated at this point, so... |
|
Listeners need to be instantiated because compiler passes may rely on
metadata. On their own, no initialisation is really performed.
If anything in your system uses metadata or any ORM information at
compile-time, you will get this sort of call.
Can you check which one caused this one, specifically?
…On Thu, 24 May 2018, 09:18 Teoh Han Hui, ***@***.***> wrote:
Yes, you're right. But we could never expect all classes being designed to
cater to a container compilation kind of scenario.
The reason why I ask if we could force lazy loading during container
compilation is because it'll be an easy win. (Think the 80/20 rule.) And
actually, it wouldn't be a problem what classes do in their constructors as
they usually should get instantiated during container compilation. It is
Doctrine that is causing them to get instantiated at this point, so...
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#822 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAJakIX3YqBoUA2ZmXdyzpQLQ6VCO9Miks5t1l6xgaJpZM4ULEQO>
.
|
|
It's not caused by listeners using this event, right? So it has to be something that explicitly requests for Doctrine metadata... I'll look into it. |
|
Yeah, this will surely cause loading: |
|
Do you see a way forward? Is it possible to defer loading other event listeners other than for the loadClassMetadata event? |
|
@teohhanhui make the service that is failing lazy, rather than the entire listener chain. |
|
Yes, that avoids the problem. But what I'm trying to address here is a way for there not to be such a problem in the first place. If there is no reason for the listeners to be loaded during compile time, it'd be best if their instantiation could be made lazy. It'll prevent a lot of other future problems for the users. |
|
It is much better to keep it as-is and have users:
Closing as |
Is there a way to always use lazy loaded listeners during the container compilation phase? It will prevent lots of errors caused by trying to instantiate the listeners and also recursively their parent dependencies (which is of course really bad).
For example:
In thise case
getSylius_Listener_ImagesRemoveService()should never have been called during container compilation, even when itsdoctrine.event_listenertag does not havelazyset totrue.The text was updated successfully, but these errors were encountered: