-
Notifications
You must be signed in to change notification settings - Fork 171
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
Added Server.Unwrap function #162
base: main
Are you sure you want to change the base?
Conversation
@skyao please review this |
This function exposures the underlying implementation details, it is realy NOT a clean way as you say. It breaks the design, can we find a better way? |
I don't know, for this specific case it would be a good idea to implement adding middlewares on top of the internal handler, while not exposing the values like i did in my commit. Or it should be possible to start treating the returned values as public, while also making sure that you cannot use the |
@skyao what do you think? |
I have given my comments: I understand the requirement from , but I think we need find a better way, which won't break the design. |
This is a tiny commit, mostly for internal use.
I did it to support adding middlewares (such as logging, which is my case) over the http.ServeMux generated by the Dapr SDK.
It is probably not the cleanest way to do that though, as you still need to cast the
daprd.NewServiceWithMux()
output withs.(*daprd.Server)