Provide a way to mark beans as not lazy without using @Lazy(false)

[mbhave]

This was discussed as part of #16184. Although we have a way to explicitly mark beans as not lazy using @Lazy(false), there are times when we'd need to do that for beans that are not explicitly marked that way. For example, a user cannot mark Spring Integration's internal components as @Lazy(false). @wilkinsona's comment here has some ideas for doing this.

[tkvangorder]

@mbhave

The original issue where we discussed the lazy-loading BFPP has code to exclude certain classes. #9685

It is working for us, but we have to brute force it by sub-classing our post-processor and passing in the classes we wish to exclude from lazy loading.

I think it would be possible to add a new attribute to "spring.factories" that would allow downstream projects to contribute exclusions to lazy-loading.

Then the post-processor can be modified to get its list of exclusions via "spring.factorties"?

[mbhave]

Thanks @tkvangorder. We were originally thinking of going off off some information from the bean definition to decide if a bean should be marked as lazy or not. Being able to contribute exclusions to lazy loading sounds interesting to me. I'll flag for team attention to see what the rest of the team thinks.

[mbhave]

We discussed this on the team call today and before we jump to a solution, we wanted to gather the use-cases where @Lazy(false) wouldn't work. For the Spring integration case, I tried it with our sample app and it seems to work if @Lazy(false) is added to the IntegrationFlow bean.

@tkvangorder Do you think you could provide a sample for which @Lazy(false) wouldn't work?

[tkvangorder]

Just to clarify what you are saying, If a developer is using the IntegrateFlow and are also using lazy-loading they will have to annotate the bean method like this:

	@Bean
	@Lazy(false)
	public IntegrationFlow integrationFlow(SampleEndpoint endpoint) {
		return IntegrationFlows.from(fileReader(), new FixedRatePoller())
				.channel(inputChannel()).handle(endpoint).channel(outputChannel())
				.handle(fileWriter()).get();
	}

This works for me, but I suspect you will want to put a note in there: "hey, if you are using integration flows with lazy-loading, make sure you mark your flows as "eager".

[tkvangorder]

One more suggestion for this (and I know this is a bit of work to remove the requirement of having to explicitly add @Lazy(false) to the flows). I totally understand if this is solved via a release note rather than adding complexity. If interested, I can put a pull request together :

Add a customizer interface:

public interface LazyBeanDefinitionCustomizer {

	public List<Class<?>> getEagerLoadingClasses();
}

Post Processor can optionally be injected with a list of the customizers :

public class LazyInitBeanFactoryPostProcessor implements BeanFactoryPostProcessor {

	private List<Class<?>> exclusionList;

	public LazyInitBeanFactoryPostProcessor(Optional<List<LazyBeanDefinitionCustomizer>> customizers) {
		if (customizers.isPresent()) {
			exclusionList = new ArrayList<>();
			for (LazyBeanDefinitionCustomizer customizer : customizers.get()) {
				exclusionList.addAll(customizer.getEagerLoadingClasses());
			}
		}
	}

	@Override
	public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {

		for (String name : beanFactory.getBeanDefinitionNames()) {
			BeanDefinition beanDefinition = beanFactory.getBeanDefinition(name);
			if (beanDefinition instanceof AbstractBeanDefinition) {
				Boolean lazyInit = ((AbstractBeanDefinition) beanDefinition)
						.getLazyInit();
				if (lazyInit != null && !lazyInit) {
					continue;
				}
			}
			if (isEager(name, beanFactory)) {
				continue;
			}
			beanDefinition.setLazyInit(true);
		}
	}

	private boolean isEager(String beanName, ConfigurableListableBeanFactory beanFactory) {
		if (exclusionList == null || exclusionList.size() == 0) {
			return false;
		}
		for (Class<?> clazz : exclusionList) {
			if (beanFactory.isTypeMatch(beanName,clazz)) {
				return true;
			}
		}
		return false;
	}
}

And finally, in the auto-configuration for Spring Integration DSL:

		@Bean
		static public LazyBeanDefinitionCustomizer springIntegrationLazyBeanCustomizer() {
			return () ->  Arrays.asList(IntegrationFlow.class);
		}

[wilkinsona]

For an app with lots of IntegrationFlow beans, having to annotated every definition with @Lazy(false) feels a little cumbersome. I think it would be interesting to also explore the idea that we had of never marking a Lifecycle or SmartLifecycle bean as lazy.

[tkvangorder]

@wilkinsona @mbhave I had a little time to experiment with adding exclusions to the lazy-loading process. I first tried Andy's suggestion of just using SmartLifecycle and Lifecycle but I ran into a roadblock: The IntegrationFlow interface does not extend either of those interfaces. The concrete bean type that implements the IntegrationFlow does implements the life cycle, but the bean has not been instantiated yet.

I put together a PR that does use a Customizer strategy. It does not use traditional dependency injection but rather takes two passes at the bean definitions; once to find and instantiate JUST the customizers and once to mark the remaining beans as "lazy".

#16615

This code does work if you add the following into the application context.

	@Bean
	public static LazyBeanDefinitionCustomizer springIntegrationLazyBeanCustomizer() {
		return () -> Arrays.asList(IntegrationFlow.class);
	}

The idea is this would be live in the auto-configuration of the Spring Integration DSL project and the customizer is really intended for framework-only projects.

Let me know what you think.

[wilkinsona]

Thanks for this, Tyler. I believe that looking for SmartLifecycle and Lifecycle would work for beans that are defined as StandardIntegrationFlow (which is what IntegrationFlowBuilder.get() returns). However, we can't expect all bean definitions that use the builder to have the return type. We'd also need to accommodate IntegrationFlow beans that are defined without use of the builder. In short, I think you're on the right track with the customizer strategy.

[mbhave]

Closing this in favor of PR #16615.