How to organize application contexts to avoid naming conflicts?

[quaff]

Original issue: spring-projects/spring-boot#36202 (comment)

[fmbenhassine]

Thank you for opening this discussion. Please share the complete code example that you are trying to modularize with @EnableBatchProcessing(modular = true). This will serve as a base for our discussion here.

[quaff]

I want to migrate my legacy application to spring boot and use JavaConfig instead of xml.
Here is xml configuration:

<?xml version="1.0" encoding="UTF-8"?>
<beans default-autowire="byName"
	xmlns="http://www.springframework.org/schema/beans"
	xmlns:context="http://www.springframework.org/schema/context"
	xmlns:batch="http://www.springframework.org/schema/batch"
	xmlns:p="http://www.springframework.org/schema/p"
	xmlns:c="http://www.springframework.org/schema/c"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://www.springframework.org/schema/beans
	https://www.springframework.org/schema/beans/spring-beans.xsd
	http://www.springframework.org/schema/context 
	https://www.springframework.org/schema/context/spring-context.xsd
	http://www.springframework.org/schema/batch
	https://www.springframework.org/schema/batch/spring-batch.xsd">
	<bean id="batchTaskExecutor" class="org.springframework.core.task.SimpleAsyncTaskExecutor" c:threadNamePrefix="batch-"/>
	<batch:job-repository />
	<bean id="jobLauncher" class="org.springframework.batch.core.launch.support.SimpleJobLauncher" p:taskExecutor-ref="batchTaskExecutor"/>
	<bean id="jobExplorer" class="org.springframework.batch.core.explore.support.JobExplorerFactoryBean"/>
	<bean id="jobOperator" class="org.springframework.batch.core.launch.support.SimpleJobOperator"/>
	<bean id="jobRegistry" class="org.springframework.batch.core.configuration.support.MapJobRegistry"/>
	<bean id="stepRegistry" class="org.springframework.batch.core.configuration.support.MapStepRegistry"/>
	<bean id="jobLoader" class="org.springframework.batch.core.configuration.support.DefaultJobLoader"/>
	<bean id="automaticJobRegistrar" class="org.springframework.batch.core.configuration.support.AutomaticJobRegistrar">
		<property name="applicationContextFactories">
			<bean class="org.springframework.batch.core.configuration.support.ClasspathXmlApplicationContextsFactoryBean">
				<property name="resources" value="${jobRegistrar.resources:classpath*:resources/batch/*.xml}" />
			</bean>
		</property>
	</bean>
</beans>

[fmbenhassine]

How is that related to @EnableBatchProcessing(modular = true)? Those are regular Spring beans defined in XML that you can change to Java configuration. If it is the automatic job registrar that is concerning, here is one way to define it in Java config:

@Bean
public ClasspathXmlApplicationContextsFactoryBean classpathXmlApplicationContextsFactoryBean(@Value("${jobRegistrar.resources:classpath*:resources/batch/*.xml}") Resource[] resources){
	ClasspathXmlApplicationContextsFactoryBean factoryBean = new ClasspathXmlApplicationContextsFactoryBean();
	factoryBean.setResources(resources);
	return factoryBean;
}

@Bean
public AutomaticJobRegistrar automaticJobRegistrar(ClasspathXmlApplicationContextsFactoryBean factoryBean) throws Exception {
	AutomaticJobRegistrar registrar = new AutomaticJobRegistrar();
	registrar.setApplicationContextFactories(factoryBean.getObject());
	return registrar;
}

My understanding from the Boot discussion is that you are using @EnableBatchProcessing(modular = true) and looking for a way to achieve the same result without that annotation, which is not the case here.

[quaff]

I'm tend to use @EnableBatchProcessing(modular = true) to achieve modularizing, but @EnableBatchProcessing is not recommended by Boot, and Boot doesn't support modular, that's why I create that PR.
from the Boot discussion, child application contexts is considered as harmful, but your suggestion here still using the same thing, now I'm a bit confused.

[fmbenhassine]

I am not suggesting to use child contexts, what I am suggesting is to convert the XML configuration you shared in Java. Basically translating the 9 XML bean definitions into 9 bean definitions in Java. That's it. Apologies for the confusion.

Now the fact that one of the beans (the automaticJobRegistrar ) is referring to other XML configuration files is another story. This how the AutomaticJobRegistrar is designed to work, which is documented here: https://docs.spring.io/spring-batch/docs/current/reference/html/job.html#automaticjobregistrar. So the way to modularize Spring Batch configurations without @EnableBatchProcessing(modular = true) is by manually defining the AutomaticJobRegistrar as shown above and in the docs, which is compatible with Spring Boot.

Please let me know if you need more support on this, I would be happy to help. Otherwise, please close the discussion. Thank you.

[quaff]

Please review my PR https://github.com/spring-projects/spring-boot/pull/36202/files , I think I'm doing the right way as you suggested, so the question is that PR worthy be merged into Spring Boot or not.

[fmbenhassine]

I reviewed your PR. The change you are suggesting in that PR is to make Spring Boot add a AutomaticJobRegistrar in the application context. What I am saying is do we really need a new property and a new feature in Spring Boot to add a single bean? That's what I meant in my previous comment:

the way to modularize Spring Batch configurations without @EnableBatchProcessing(modular = true) is by manually defining the AutomaticJobRegistrar as shown above and in the docs, which is compatible with Spring Boot.

What I understood from your initial request against Boot is to add support for modularized configs in Boot itself (ie writing the equivalent code currently in Batch with context hierarchies, etc but in Boot), which I discourage. But now after discussing with you what you are looking for (ie translating an XML config into a Java config for a AutomaticJobRegistrar), it is really about making Spring Boot automatically configure such a bean based on a property. I believe there is no need to add this feature to Boot. This is similar to #4245, for which I don't think we need a Boot feature neither to automatically add a JobRegistryBeanPostProcessor.

Moreover, I would personally recommend modulazing configs by having a single Batch job per Boot app, rather than relying on a "feature" of Spring Batch or Spring Boot. This architecture removes a whole category of problems (naming clashes, job-scoped beans, etc) by design. This approach is also inline with Spring Boot 3, see https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Migration-Guide#multiple-batch-jobs.

I am closing this ticket for now as I believe I answered your question, but feel free to add a comment if you still need help on this.