Archie Cobbs opened SPR-8703 and commented

AbstractSingleBeanDefinitionParser has support for setting bean name and aliases (via superclass), parent name, and bean class, but not depends-on, lazy-init, scope etc.

This seems arbitrarily incomplete. Ideally, this class would include support and default handling for all of the settable properties of the BeanDefinition interface.

A nice design would be for the superclass AbstractBeanDefinitionParser to have methods like this:

protected void parseDependsOn(BeanDefinition beanDefinition, String value, ParserContext parserContext) {
    ...
}
protected void parseScope(BeanDefinition beanDefinition, String value, ParserContext parserContext) {
    ...
}

so the subclass could easily use different attributes (or other sources) for these settings.

AbstractSingleBeanDefinitionParser could then invoke these helper methods by default with the usual attributes, but in an easily overridable way.

Affects: 3.0.6

1 votes, 1 watchers

Comment From: spring-projects-issues

Archie Cobbs commented

I see now that this functionality lives in a combined form in the method BeanDefinitionParserDelegate.parseBeanDefinitionAttributes().

Perhaps the parsing logic in that method could be split out into separate methods which would then be individually available.

At minimum, should the BeanDefinitionParserDelegate class be referenced in the Abstract*BeanDefinitionParser Javadocs?

Comment From: spring-projects-issues

Archie Cobbs commented

For what it's worth, here is what I came up to address this issue for my own use:

http://dellroad-stuff.googlecode.com/svn/trunk/src/java/org/dellroad/stuff/spring/AbstractBeanDefinitionParser.java

Comment From: spring-projects-issues

Tjad Clark commented

I am in full agreement, it's rather silly that when an abstract bean depends on another bean, the bean dependency isn't loaded.

As I've built a framework, within a number of my projects that I use this framework, I have this issue where I am having to place depends-on on all of the children beans of the abstract bean, further, it causes issues within my development team for new members as they are unaware that they should add this bean dependency, and needless to mention that if one of the beans that is dependent on the bean dependency loads first, the system fails.

Outside of my development team, developers are required to read the documentation carefully, it seems a bit rediculous to expect them to add this dependency to each of there bean definitions.

Abstract beans are required to parse depends-on and load the bean dependencies - or at least when the children load, that bean should be initialized already.

Comment From: spring-projects-issues

Bulk closing outdated, unresolved issues. Please, reopen if still relevant.

Comment From: archiecobbs

Bulk closing outdated, unresolved issues. Please, reopen if still relevant.

... except Github won't let me reopen it...

Comment From: jhoeller

We have no plans to revisit the XML namespace handlers at this late stage, given that the entire XML bean definition model is in a feature-frozen maintenance mode. Anything we add there at this point is not likely to get traction anymore before being phased out even further.