Repository navigation
Springboot NexusClient and NexusServiceClient<T> support for easier, correct SANO usage #3122
Description
Is your feature request related to a problem? Please describe.
Guidance in javadoc for NexusClient is Client for managing standalone Nexus operation executions. Obtain an instance via newInstance(WorkflowServiceStubs) or newInstance(WorkflowServiceStubs, NexusClientOptions). Do not create this object per request; share it for the lifetime of the process.
[here])https://www.javadoc.io/doc/io.temporal/temporal-sdk/latest/io/temporal/client/NexusClient.html).
Describe the solution you'd like
First improvement
Lifestyle correctness guidance like that should be made simpler with Spring so I can nexusClient in my controller just like I can workflowClient.
We should support this across all namespaces though using the nice "non-root" namespace config support. It is Nexus, after all, so let me call across Namespaces :) .
spring.temporal:
namespaces:
# I have a couple services inside my `apps` Namespace I want to use
- namespace: apps
alias: apps
nexus-service-clients:
- alias: apps-v1
endpoint: oms-apps-v1
service: com.acme.oms.services.AppsService
- alias: support-v1
endpoint: oms-support-v1
service: com.acme.oms.services.SupportService
// my REST Controller
// Use @Qualifier since non-root referencing alias
public AppsController(@Qualifier("apps-v1NexusClient") NexusClient appsNexusClient) {
this.appsNC = appsNexusClient;
}Customization for options (interceptors,dataconverter, etc) can follow the existing path for doing such things with workflow client...ideally we could do this in configuration directly but the requirement to code those a shortcoming that already exists in our SB integration so not necessarily part of this.
Second improvement
We can do better than this though I think and support a nexus-service-clients per client so I can do something like :
spring.temporal:
namespaces:
# I have a couple services inside my `apps` Namespace I want to use
- namespace: apps
alias: apps
nexus-service-clients:
- alias: apps-v1
endpoint: oms-apps-v1
service: com.acme.oms.services.AppsService
- alias: support-v1
endpoint: oms-support-v1
service: com.acme.oms.services.SupportService
// my REST Controller
// No @Qualifier needed but I could do it with `alias` I guess
public SupportController(NexusServiceClient<SupportService> supportSvc) {
this.supportSvc = supportSvc;
}Describe alternatives you've considered
Roll my own @Bean but I want it to be more approachable!
Additional context
SANO is here, let's make it dead simple to integrate All The Things!
Activity
AndreiSulyz commentedon Oct 19, 2026
Hi @mnichols! Is anyone working on this? If not, I'd like to pick it up.
Proposal
Expose
NexusClientas a Spring bean, same asWorkflowClient/ScheduleClient:temporalNexusClientfor the root namespace<alias>NexusClientfor non-root namespaces (e.g.appsNexusClient)TemporalOptionsCustomizer<NexusClientOptions.Builder>for customizationWhy per namespace: the client's namespace is the caller namespace. Routing is done by the endpoint, but the caller namespace defines where operations are recorded, which connection/credentials are used (per-namespace in Cloud or with namespace-scoped auth), and which endpoints the caller may access where endpoint access policies are enforced (e.g. Cloud). A client per service or several per namespace add nothing.
Out of scope (for my opinion)
Config-driven
NexusServiceClient<T>beans. OnceNexusClientis a bean, this is a trivial@Bean:Doing it via YAML means generic-typed bean definitions (
registerSingletonloses the type, so injection by type gets ambiguous with 2+ services) and new config surface on an experimental API. I'd add the snippet to the README instead.Happy to open a PR if this sounds good.
Quinn-With-Two-Ns commentedon Oct 19, 2026
@AndreiSulyz Is this something you are interested in using or are you just looking to contribute to the Java SDK?
AndreiSulyz commentedon Oct 19, 2026
@Quinn-With-Two-Ns We're starting to build a platform on top of Temporal Nexus and Spring AI, so Nexus support in the Spring Boot integration is directly relevant to us. Having
NexusClientavailable as a Spring bean is exactly what we'd use to call Nexus operations from our Spring services.Per-namespace support matters for us in particular. We're on Temporal Cloud and manage access per namespace with Terraform.
I'd be happy to implement it while I have the bandwidth, following the proposal above, or adjusted to whatever direction you prefer.