Comment From: wilkinsona

Thanks for the suggestion, @quaff.

Generally speaking, I don't like the additional complexity of application context hierarchies and I suspect it's going to cause problems with AOT as well. WDYT, @fmbenhassine? Is this something that we should try to support out of the box in Boot?

Comment From: quaff

Modularizing is useful for batch applications, It's not rare that batch jobs are using similar structure, Job configuration have to be isolated to avoid naming conflict. Hope modularizing can be used in boot without @EnableBatchProcessing.

Comment From: fmbenhassine

@EnableBatchProcessing(modular = true) is already causing a lot of complexity in Spring Batch itself (with a lot of interfaces and classes like ApplicationContextFactory, JobFactory, ApplicationContextJobFactory, ClasspathXmlApplicationContextsFactoryBean, and many other related APIs). This complexity is probably accidental, but is definitely causing a lot of issues in Spring Batch for no real added value. We are considering to deprecate this feature in Spring Batch. Spring Framework already provides several ways to organize application contexts to avoid naming conflicts, and users should not rely on Spring Batch's @EnableBatchProcessing(modular = true) or Spring Boot for that. I don't even see how Spring Boot could help here.

@quaff Please open a discussion on Spring Batch's side and I can show you how to modularize your app without @EnableBatchProcessing(modular = true)

@wilkinsona

Generally speaking, I don't like the additional complexity of application context hierarchies and I suspect it's going to cause problems with AOT as well. WDYT, @fmbenhassine? Is this something that we should try to support out of the box in Boot?

I defer the decision to the Boot team here, but I would not add this to Spring Boot for the same reasons you mentioned and for the reasons I listed above.

Comment From: quaff

to organize application contexts to avoid naming conflicts

I've created https://github.com/spring-projects/spring-batch/issues/4409

Comment From: wilkinsona

Thanks, @fmbenhassine. Thanks again for the suggestion, @quaff, but based on the above I'm going to decline this one.