-
Notifications
You must be signed in to change notification settings - Fork 726
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
Resolving dependencies in activation handler within request scope #820
Comments
@ballwood Did you figure it out? I'm facing something similar and the only thing has worked for me right now is using |
The 'get' methods start a new request so you will receive a new Logger. Using the context.plan.rootRequest.requestScope is the correct way of achieving what you want. |
@notaphplover would it be possible to add a |
Hey @BurningEnlightenment, I need to think about it. I honestly believe it makes sense to make internal subrequests look like the same request for the user, but if we go for this it should be transparent to the user and I would like to avoid some performance issues I am thinking about. Having said that, one workaround in v7 is using resolved values. They don't make subrequests so the request scope would be the same one. As said, I do need to carefully think about it before going for it. |
Hi,
I'm using activation handlers to provide a cross cutting logging concern like in the example below. Is there anything in the context provided to the activation handler that I can use to get a dependency and make sure it respects the scope that has been defined in the original container....using get just creates a new instance which means I'm creating 2 instances of the logger class per request.
Thanks :)
The text was updated successfully, but these errors were encountered: