Provide alternatives to using FactoryBean types within @Bean methods [SPR-7418]

[spring-projects-issues]

Chris Beams opened SPR-7418 and commented

Consolidating the following issues related to using FactoryBean implementations within @Bean methods:

• JavaConfig - provide more tooling when working with a FactoryBean implementation [SPR-6474] #11140
• Mixing PersistenceExceptionTranslator logic into FactoryBeans prevents using PersistenceExeptionTranslationPostProcessor with @Configuration classes [SPR-7387] #12045
• Support of class ConfigurationSupport in Spring 3.0.x framework [SPR-6018] #10687

---

Affects: 3.0 GA

Sub-tasks:

• Review EarlyBeanReferenceProxyCreator behavior wrt FactoryBean.getObject [SPR-8043] #12698 Review EarlyBeanReferenceProxyCreator behavior wrt FactoryBean.getObject
• Introduce (Annotation)SessionFactoryBuilder types [SPR-8066] #12721 Introduce (Annotation)SessionFactoryBuilder types
• Test *SessionFactoryBean compatibility with earlier versions of Spring [SPR-8112] #12766 Test *SessionFactoryBean compatibility with earlier versions of Spring
• Introduce EntityManagerFactoryBuilder types [SPR-8128] #12779 Introduce EntityManagerFactoryBuilder types
• Document @Bean alternatives to JndiObjectFactoryBean [SPR-8129] #12780 Document @Bean alternatives to JndiObjectFactoryBean
• Introduce QuartzSchedulerBuilder as @Bean alternative to SchedulerFactoryBean [SPR-8130] #12781 Introduce QuartzSchedulerBuilder as @Bean alternative to SchedulerFactoryBean
• Document @Bean alternatives to ScheduledExecutor and ThreadPoolExecutor FactoryBean types [SPR-8131] #12782 Document @Bean alternatives to ScheduledExecutor and ThreadPoolExecutor FactoryBean types
• Introduce RmiRegistryBuilder as @Bean alternative to RmiRegistryFactoryBean [SPR-8132] #12783 Introduce RmiRegistryBuilder as @Bean alternative to RmiRegistryFactoryBean
• Introduce RmiProxyBuilder as @Bean alternative to RmiProxyFactoryBean [SPR-8133] #12784 Introduce RmiProxyBuilder as @Bean alternative to RmiProxyFactoryBean
• Introduce HessianProxyBuilder as @Bean alternative to HessianProxyFactoryBean [SPR-8134] #12785 Introduce HessianProxyBuilder as @Bean alternative to HessianProxyFactoryBean
• Introduce BurlapProxyBuilder as @Bean alternative to BurlapProxyFactoryBean [SPR-8135] #12786 Introduce BurlapProxyBuilder as @Bean alternative to BurlapProxyFactoryBean
• Introduce HttpInvokerProxyBuilder as @Bean alternative to HttpInvokerProxyFactoryBean [SPR-8136] #12787 Introduce HttpInvokerProxyBuilder as @Bean alternative to HttpInvokerProxyFactoryBean

Issue Links:

• Support automatic detection of close methods [SPR-8114] #12768 Support automatic detection of close methods
• Support injection against setter methods with non-void return types [SPR-8079] #12734 Support injection against setter methods with non-void return types
• Mixing PersistenceExceptionTranslator logic into FactoryBeans prevents using PersistenceExeptionTranslationPostProcessor with @Configuration classes [SPR-7387] #12045 Mixing PersistenceExceptionTranslator logic into FactoryBeans prevents using PersistenceExeptionTranslationPostProcessor with @Configuration classes ("supersedes")
• Support of class ConfigurationSupport in Spring 3.0.x framework [SPR-6018] #10687 Support of class ConfigurationSupport in Spring 3.0.x framework ("supersedes")
• JavaConfig - provide more tooling when working with a FactoryBean implementation [SPR-6474] #11140 JavaConfig - provide more tooling when working with a FactoryBean implementation ("supersedes")

4 votes, 4 watchers

[spring-projects-issues]

Chris Beams commented

After consideration, the goal is not to provide support for using FactoryBean instances within @Bean methods, but rather to eliminate the need to do so altogether.

It is fundamentally awkward to use a FactoryBean in a @Configuration class context; they were designed specifically as a mechanism to work around limitations of XML-based configuration. Rather, what's needed is a more fundamental, possibly builder-style API instead of a FactoryBean API. In many cases, today's current FactoryBeans may be refactored to delegate to simpler builder-style APIs that can be used in a @Bean method as well.

In other cases, it may be sufficient to simply use an existing native API such as Hibernate's Configuration class.

Or it may be beneficial to provide a Spring-specific subclass of a native API in order to ensure certain container lifecycle hooks are invoked, etc. (e.g. a Hibernate Configuration subclass that implements Spring's DisposableBean).

This is a high-priority issue for Spring 3.1 M2, as 100% convenient code-based configuration cannot be fully realized without addressing it.

[spring-projects-issues]

Chris Beams commented

Users should not, in most cases need to use FactoryBean types within @Bean methods. There are certain exceptions, such as LocalEntityManagerFactoryBean, and for reasons documented in #12779. There are other exceptions, but we will consider implementing alternatives for them on a case-by-case basis going forward, based on user demand.