-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[DI] [6.2] Lazy object generation not working when same class is used for multiple lazy services #48507
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
Comments
the right solution is to generate 2 different proxy classes |
Taking a look at |
We need to vary the name of the generated class by "kind" (ghost/proxy) and generate two of them indeed when needed. |
I fixed this in #48522, thanks for reporting! |
Nice, thanks for the quick fix! 👍 |
… objects and virtual proxies (nicolas-grekas) This PR was merged into the 6.2 branch. Discussion ---------- [DependencyInjection] Generate different classes for ghost objects and virtual proxies | Q | A | ------------- | --- | Branch? | 6.2 | Bug fix? | yes | New feature? | no | Deprecations? | no | Tickets | Fix #48507 | License | MIT | Doc PR | - Commits ------- c5da2eb [DependencyInjection] Generate different classes for ghost objects and virtual proxies
Symfony version(s) affected
6.2
Description
When you have multiple lazy services that use the same class but are configured differently (one without a factory, one with a factory) the lazy object generation is broken.
The reason is that for the class in question only one
ProxyObject
is generated, which either uses theLazyGhostTrait
orLazyProxytTrait
, but not both. This proxy object is used for both services, but as one of those services uses a factory it expects anLazyProxy
, the service that does not use a factory expects theLazyGhost
. That means that one object cannot be instantiated.Our specific use case is that we have several
GuzzleClient
s as different services configured, as they use different middlewares and different configurations. Some of them are marked as lazy which leads to the problems described above.How to reproduce
Having a service declaration like the following:
Will lead to the following proxy class being generated:
Note: This example is greatly simplified, in our case this proxy is generated, i'm not sure but i suppose that it may also happen that a proxy will be generated that uses the
LazyProxyTrait
, but that will lead to the same problem down the line.The generated service container will use the generated proxy in the following way:
Important: You can see that in the getter for the first service (that uses a factory) it is expected that the proxy class is a
LazyProxy
, but for the second service (without a factory) it expects aLazyGhost
, but the auto generated proxy uses only one of those traits. This leads to problems in the creation of on of those services, because in fact the proxy does not implement the called method.Possible Solution
One solution might be that in cases like the one described above the auto generated proxy class for the
GuzzleClient
uses both theLazyGhostTrait
and theLazyProxyTrait
. But i'm not sure if the traits are designed to be used in one class simultaneously or if the traits conflict with each other.If the latter is the case at least two proxies should be generated for the same class in cases like the one above, one implementing the
LazyGhostTrait
and the other implementing theLazyObjectTrait
.Additional Context
No response
The text was updated successfully, but these errors were encountered: