Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
[DependencyInjection] deprecated synchronized services #13289
… (fabpot) This PR was merged into the 2.7 branch. Discussion ---------- [DependencyInjection] deprecated synchronized services | Q | A | ------------- | --- | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | yes | Tests pass? | yes | Fixed tickets | n/a | License | MIT | Doc PR | n/a Commits ------- 82db9c2 [DependencyInjection] deprecated synchronized services
@tkleinhakisa what is your use case for the synchronized service ?
The benefit of removal is that this feature is quite complex for something which is not really needed and was the wrong way to solve our problem. We were not really satisfied when introducing it, but we needed a way to fix the handling of requests. We then figured out that it was not even fixing all our cases, so we continued searching for a better architecture, which is when we introduced the RequestStack in 2.6.
Hi @stof and thank you for the explanations. I will have a look at the request stack (we are not using 2.6 yet)
Our application can be accessed from multiples domain, if you access it from www.site1.com you're a "site1" user, www.site2.com "site2" user ...
Exemple: user1 from site1 take action on user2 from site2, i can swich the site, generate the good urls and messages for user2, then rollback the site to its original value and redirect user1 to the correct url with his domain.
Do you think a similar design to the RequestStack could be applied ?
…definitions (ogizanagi) This PR was merged into the 3.1 branch. Discussion ---------- [DependencyInjection] ContainerBuilder: Remove obsolete definitions | Q | A | ------------- | --- | Branch? | 3.1 | Bug fix? | yes | New feature? |no | BC breaks? | may be considered | Deprecations? | may be considered | Tests pass? | yes | Fixed tickets | - | License | MIT | Doc PR | - IIUC, [the obsolete definitions thing was tied to scoped & sync services](#7007). Thus, this code [is not meant to be used since 3.0 and can be removed](#13289). However, it may be considered as a BC break and would require introducing a new deprecation instead, because the current code allows to set a service on a frozen container if it has an obsolete synthetic definition...which is weird, isn't it ? (I doubt this feature was explicitly intended to allow setting a synthetic service more than once, and it wasn't before sync services introduction) I suggest this as a patch for 3.1, under the pretext of forgotten code tied to a previous deprecation & feature removal, but let me know if it should be considered differently. Commits ------- daa7d00 [DependencyInjection] ContainerBuilder: Remove obsolete definitions