Lookup available JobRegistry from context for JobOperatorFactoryBean

[quaff]

No description provided.

[fmbenhassine]

Thank you for the PR! However, as mentioned in #5229 (comment) , this introduces a breaking change and is not consistent with how other optional components are customized (why would we use an ObjectProvider for the registry but not the for task executor or the job parameters converter?)

The way to fix the issue is by looking for a registry from the context before creating a default one (similar to what we do for the datasource and the transaction manager in the JDBC config. Can you please update the PR accordingly? Thank you upfront.

As a side note, regarding spring-projects/spring-boot#48992 (comment), this is not an oversight. The class is designed to accept mandatory dependencies as constructor parameters, while optional dependencies can be customized by overriding getters (the registry is optional starting from v6).

[quaff]

Updated.

[quaff]

Another question, is registry job the responsibility of JobRegistry implementation or DefaultBatchConfiguration ?

I suggest latter, and remove logic from MapJobRegistry:

spring-batch/spring-batch-core/src/main/java/org/springframework/batch/core/configuration/support/MapJobRegistry.java

Lines 64 to 74 in a3a517f

	public void afterSingletonsInstantiated() {
	Map<String, Job> jobBeans = this.applicationContext.getBeansOfType(Job.class);
	for (Job job : jobBeans.values()) {
	try {
	register(job);
	}
	catch (DuplicateJobException e) {
	throw new IllegalStateException("Unable to register job " + job.getName(), e);
	}
	}
	}

[fmbenhassine]

Job registration is typically the responsibility of a configuration class (like DefaultBatchConfiguration). The reason is it currently done in the MapJobRegistry implementation is for people who do not use DefaultBatchConfiguration and still want to get a populated registry by default when defined as a bean (this actually eliminate the need for a JobRegistryBeanPostProcessor or a JobRegistrySmartInitializingSingleton as we had in v5, see #4855).

The PR LGTM 👍 Thank you for the updates! I will merge it for the upcoming 6.0.3.

[fmbenhassine]

Rebased and merged as ac73b3a. Thank you for your contribution!