Placeholders in context:component-scan's base-package attribute [SPR-4351]

[spring-projects-issues]

Mike Youngstrom opened SPR-4351 and commented

<context:component-scan base-package="${base.package}"/>

The ${base.package} never get's resolved when ComponentScanBeanDefinitionParser pulls it from the attribute.

I realize this is probably a much larger issue potentially involving certain attributes of many NamespaceHandlers. However, I thought I'd create an issue for it since I didn't see any other mention of how it can be difficult identifying which attributes of a NamespaceHandler can accept property placeholders and which cannot. Perhaps for the time being simply documenting in the XSD if the attribute can accept a property placeholder or not might help?

Mike

---

Affects: 2.5.1

Issue Links:

• make context:exclude-filter expression supports placeholder like context:component-scan base-package [SPR-10424] #15057 make context:exclude-filter expression supports placeholder like context:component-scan base-package
• please let context:component-scan base-package eval placeholder then split by comma [SPR-10425] #15058 please let context:component-scan base-package eval placeholder then split by comma

[spring-projects-issues]

Juergen Hoeller commented

The general rule is that placeholders are only supported for bean definition metadata. So for any XML element attributes that get translated into bean definition metadata such as property values, placeholders will take effect.

However, placeholders are not supported for configuration element settings which are relevant for deciding whether/how to build bean definitions in the first place. This affects import locations and the names of scanned packages.

Admittedly, this isn't properly documented anywhere. I'll turn this into a documentation issue for the time being, as you suggested...

Juergen

[spring-projects-issues]

Mike Youngstrom commented

I'd like to note that I think the general rule of property placeholders not working in XML element attributes is a poor general rule. :) However, I understand that this is not small issue. Perhaps for Spring 3.0 something can be done to make a property placeholder type of mechanism more of a first class citizen with the BeanFactory? I think the concept of a property placeholder has been proven useful and having no way to do a placeholder replacement of an XML element can lead to some confusion and frustration to users as NamespaceHandlers become more and more prevalent in Spring.

Mike

[spring-projects-issues]

Juergen Hoeller commented

This doesn't actually have as much to do with NamespaceHandlers as you imply: Almost all NamespaceHandlers do a straight translation into bean definitions, in which case placeholders can be used in virtually all attributes of the namespace element, since they'll end up as bean definition metadata - which will get post-processed before it becomes active.

The problem is rather a lifecycle issue: Component scanning happens during the bean definition reading phase, since it results in the creation of new bean definitions. Then the ApplicationContext lifecycle kicks in, searching for post-processors among those beans and invoking them. For that reason, a PropertyPlaceholderConfigurer will apply to those bean definitions just like to regular bean definitions, but it won't apply to the component scan settings themselves.

So technically, this is not so much about properly placeholder parsing being a first-class feature of the core BeanFactory or not. It's about the configurability through bean definitions and post-processors. Custom placeholder configurer beans could override or post-process placeholders in custom ways; such post-processor beans could even be detected through component scanning! It's a chicken-and-egg problem that is pretty hard to resolve without losing that customization power.

What we do for standard resource locations (all properties / attributes that take a Spring resource location, be it file system or classpath) is that we resolve "${...}" placeholders there against system properties. I've applied this to component-scan base packages as well now, for consistency with resource locations. Admittedly, system properties don't help much for typical scanning in web application environments... but it's better than nothing.

Juergen