Add explicit opt-in flags for activity/nexus bean auto-discovery in Spring Boot

[mjameswh]

Fixes #2780.

Problem

@ActivityImpl- and @NexusServiceImpl-annotated Spring beans were silently not registered with Temporal workers unless spring.temporal.workers-auto-discovery.packages was configured — even though that setting is only supposed to control workflow classpath scanning. The entire auto-discovery block (activities, nexus services, and workflows) was gated on packages != null in WorkersTemplate.createWorkers().

Solution

Separate the concerns with explicit opt-in flags under spring.temporal.workers-auto-discovery:

Property	Type	Default	Description
register-activity-beans	boolean	false	Register @ActivityImpl-annotated Spring beans with matching workers
register-nexus-service-beans	boolean	false	Register @NexusServiceImpl-annotated Spring beans with matching workers
workflow-packages	list	—	Packages to scan for @WorkflowImpl classes (replaces packages)
enable	boolean	false	Convenience flag: registers all @WorkflowImpl, @ActivityImpl, and @NexusServiceImpl Spring-managed beans without package scanning

The enable: true flag covers the common case where all implementations are Spring-managed beans. For more control, register-activities and register-nexus-operations can be set independently, and workflow-packages handles classpath scanning for workflow classes that are not Spring beans.

Backward compatibility

The existing packages property is deprecated but fully preserved:

• If set and non-empty, it implies register-activities: true, register-nexus-operations: true, and its entries are treated as workflow-packages.
• Combining packages with any of the new properties throws IllegalStateException at startup with a clear migration message.

Changes

• WorkersAutoDiscoveryProperties — new fields, deprecation logic, validation, computed accessors (isRegisterActivities(), isRegisterNexusOperations(), isRegisterWorkflowBeans(), getEffectiveWorkflowPackages())
• WorkersTemplate — auto-discovery block rewritten to use the new property accessors independently; added autoDiscoverWorkflowBeans() for bean-based workflow discovery
• WorkersPresentCondition — binds WorkersAutoDiscoveryProperties as a whole (was binding only packages), so the condition fires for any workers-auto-discovery configuration
• application.yml (tests) — existing profiles migrated from packages: to workflow-packages: + explicit flags; legacy packages behavior tested via the new auto-discovery-by-task-queue-legacy profile
• New tests: AutoDiscoveryActivitiesOnlyTest, AutoDiscoveryEnableTest, AutoDiscoveryByTaskQueueLegacyTest, AutoDiscoveryMixedPropertiesRejectedTest

[Quinn-With-Two-Ns]

For manual config the properties are like

spring.temporal:
  workers:
    - task-queue: your-task-queue-name
      name: your-worker-name # unique name of the Worker. If not specified, Task Queue is used as the Worker name.
      workflow-classes:
        - your.package.YourWorkflowImpl
      activity-beans:
        - activity-bean-name1

Given that I might change some of the names here like register-activities -> register-activitiy-beans

[Quinn-With-Two-Ns]

How will a user know packages is deprecated? Could we log a warning to let users know?

[mjameswh]

How will a user know packages is deprecated? Could we log a warning to let users know?

Turns out Spring Boot as its own annotation for that purpose. I added it.

[robzienert]

nit: Should probably choose enabled instead of enable to follow more closely to general Spring ecosystem convention. This is just my Spring exposure, so if you've seen it more commonly expressed enable that'd be interesting to learn!

[mjameswh]

Thanks a lot for your input! After some search, enabled indeed seems more idiomatic to the Spring Boot community.