Expose more AbstractBeanDefinition methods in BeanDefinition [SPR-17275]

[spring-projects-issues]

Sébastien Deleuze opened SPR-17275 and commented

When using functional bean registration, BeanDefinitionCustomizer lambda gives access to a BeanDefinition lambda parameter that does not give access to various AbstractBeanDefinition methods, requiring a cast to AbstractBeanDefinition which is not elegant and make our API not very discoverable for those use cases.

I think it could be useful to expose those methods in BeanDefinition interface:  

• setAbstract
• setAutowireMode
• getAutowireMode
• setDependencyCheck
• getDependencyCheck
• setInitMethodName
• getInitMethodName
• getDestroyMethodName
• setDestroyMethodName
• setRole
• getRole
• setDescription
• getDescription

Those ones are candidates as well, but I have no real use case in mind for them for the moment, so they are not mandatory to expose:

• addQualifier
• getQualifiers
• hasQualifier
• getQualifier
• setLenientConstructorResolution
• isLenientConstructorResolution
• setResourceDescription
• getResourceDescription

---

Issue Links:

• GenericApplicationContext.registerBean should support non-default constructors [SPR-17292] #21825 GenericApplicationContext.registerBean should support non-default constructors

Referenced from: commits f783967, c4aea62, 97cea7f

[spring-projects-issues]

Juergen Hoeller commented

The BeanDefinition interface exposes initMethodName and destroyMethodName now, and includes setters for role and description (for which it previously only had getters).

As for abstract, autowireMode and dependencyCheck, those are really quite specific to somewhat outdated concepts such as parent/child bean definitions and XML-driven autowiring by convention. For that reason, I'd rather leave them on AbstractBeanDefinition.

[spring-projects-issues]

Sébastien Deleuze commented

Thanks!

[spring-projects-issues]

Sébastien Deleuze commented

Juergen Hoeller While doing a review of the Kotlin BeanDefinitionDsl to take care of these new API, I found that autowireMode is actually needed and exposed. I currently define it to AUTOWIRE_CONSTRUCTOR here in order to get contructor args injected (since this is the pattern I promote with Kotlin which is using a lot immutable constructor parameters) with a regular GenericApplicationContext and I allow users to change that optionally via the DSL. So I am wondering if autowireMode should be exposed in BeanDefinition? Or maybe it should not and we shold advise user to setup a AutowiredAnnotationBeanPostProcessor that will do that instead (which I am not sure partially because in functional mode we do not use annotation so the class name could be confusing)?

 

[spring-projects-issues]

Sébastien Deleuze commented

Solved via #21825.