Artur Souza
Artur Souza
We got too busy with many other things. We still have interest in supporting this.
This should be fixed. Probably without "unescaping" the String but by correctly handling the datacontenttype attribute.
If the user passes a String, we should skip serialization and pass it as-is and use text as content-type.
You can still use Subscribe if you implement the request handler directly on the app.
> > This proto is a part of unreleased Dapr, right? We should wait for the next release before changing this here. Thoughts? > > /cc @XavierGeerinck > > Yes....
> I am not in favor of removing HTTP support. Dapr [advertises the HTTP API](https://docs.dapr.io/getting-started/get-started-api/) quite prominently in the Getting Started Guide. As a result, I think it is something...
I responded. I see 2 options: SLF4J or System.out.Println() because this is just for giving warnings for deprecation and not for other use cases (yet).
> Out of curiosity: why is spring-boot-starter-web included and not spring-boot-starter-webflux, as all methods seem to be non-blocking? Great point, I think we should offer webflux but it should probably...