Repository navigation
Allow to add custom TaskOrchestrationFactory and TaskActivityFactory factories #1629
Description
Activity
/assign
This kinda makes sense in a way, but here is how we do it in Spring -> https://github.com/dapr/java-sdk/blob/master/dapr-spring/dapr-spring-workflows/src/main/java/io/dapr/spring/workflows/config/DaprWorkflowsConfiguration.java#L51C7-L51C46
Notice that we as Spring DI to get the beans by type (Beans that implements the Workflow and WorkflowActivity interfaces) and then we register those beans in the workflow runtime. What this does, is instantiate the beans so if they are doing any injection inside this is already resolved by Spring. We didn't needed any new factories or way to register new factories.
So my question would be, instead of registering the factories that are CDI enabled, why not registering CDI beans to the runtime? (as these beans should already have all their dependencies injected).
Does this makes sense?
I trust your Quarkus experience, so if you think registering the factories is the way to go, I am happy to accept these changes, but I wanted to check with you about how do we do it in Spring first.ey @mcruzdev not sure what you mean with
The current API does not allow a custom TaskOrchestrationFactory and TaskActivityFactory, when creating a DurableTaskGrpcWorker through: public DurableTaskGrpcWorker build() { return new DurableTaskGrpcWorker(this); }The
DurableTaskGrpcWorkerBuilderalready contains this methodspublic DurableTaskGrpcWorkerBuilder addOrchestration(TaskOrchestrationFactory factory)and
public DurableTaskGrpcWorkerBuilder addActivity(TaskActivityFactory factory)as @salaboy says, we may be missing something
It is a better approach for Quarkus Dapr extension. Dapr works a bit different like Spring. I can solve this problem with a similar approach that @salaboy mentioned, but the user experience on Quarkus side will be affected. I will share with you three approaches that I tried to implement Dapr Workflow in a Quarkus extension.
Note: I need to create a synthetic bean to do it.
- The first one was a similar way that Spring does, getting the beans at RUNTIME and registering workflows and activities as instance.
The problem: When the user wants to inject a Microprofile RestClient
@RestClientin aWorkflowActivitythe application do not build, due to a Quarkus particularity,a synthetic bean initialized during RUNTIME_INIT must not be accessed during STATIC_INIT. REST Clients are initialized atSTATIC_INIT.- Recording the registration of workflows and activities at
STATIC_INITthrough a bean listener.
The problem: It works nicely, but the user experience is impacted:
With this approach, the user needs to inject the REST Clients in a lazy way:
@RestClient @Inject Instace<UserClient> userClient;, it is necessary due the boot proceduce, at which time the REST Client can't be created.- Recording the registration of workflows and activities at
STATIC_INITusing aTaskOrchestrationFactoryandTaskActivityFactoryin a lazy load way. It is a runtime lazy, but depends of this pull request to be merged.
@javier-aliaga I agree with you. However, the WorkflowRuntimeBuilder does not support this out of the box. I need to create everything manually (DurableTaskGrpcWorker, WorkflowRuntime).
Gotcha, but I would recommend you to wait to this implementation, I am working in the versioning and it is quite possible things change to support it
We need to get this asap, to unblock other initiatives . @javier-aliaga we need to find an alternative that works until we can merge with your approach
Context
The current API does not allow a custom
TaskOrchestrationFactoryandTaskActivityFactory, when creating aDurableTaskGrpcWorkerthrough:Proposal
It would be great, if we have a way to add custom factories to load
WorkflowActivityorWorkflowimplementations through other mechanism, like CDI, by example.Possible implementation
To change the
WorkflowRuntimeBuilderbuilder adding a new method that adds a custom factories.For example: