Artur Souza

Hi @javageek79 , I have created a pull request to address your ask to make mocking easier for ActorClient. See PR how it can be used: https://github.com/dapr/java-sdk/pull/606/commits/4a47177005f7e93758f2f7f7d95c0db0f50e9876#diff-e59f8f865998bb2c375fe9e23fd64df4fb3b0c9b2b89e0e5926cbcb423e19b2a The actor’s DaprClient...

CloudEvent is a JSOn object in Dapr. So, this feature would only be applicable for the `data` part of the pubsub event.

I think this issue can be solved if we remove CloudEvent from the equation. For example, if the subscriber receives the object directly - similar to how is done in...

This work seems to be about using grpc_asyncio for all gRPC communication in the SDK.

The supported versions based on release are here: https://docs.dapr.io/operations/support/support-release-policy/. The SDK can work with newer or older versions of the runtime unless there is a documented deprecation that was later...

I would, first, have it as its own command: `dapr resiliency init` and `dapr resilency init -k`. Since resiliency is not a stable feature yet, having it on the main...

It is possible to run Dapr sidecar in a different host than the application. On the other hand, it is not possible to configure the sidecar to callback into another...

Yes, the Java SDK should match the expectation in runtime.

I agree with the builder pattern proposed above.

This is not applicable anymore since we do not require stable candidates.