allow a Spring 2 NamespaceHandler to invoke the Spring registered PropertyPlaceholderConfigurer on the XML Element before processing [SPR-4466]

[spring-projects-issues]

James Strachan opened SPR-4466 and commented

If someone implemented the NamespaceHandler using some XML marshalling framework (xstream / jaxb or whatever) then they loose the ability to use ${foo} notation within the XML attributes/text values.

It would be nice if from the ParserContext or some other place we could invoke Spring with the Element and ask it to invoke the PropertyPlaceholderConfigurer (or whatever) is configured there to expand any uses of ${foo} in the XML before processing.

Looking at the code, I don't see any easy way to reuse that. We'd have to basically cut n paste the code from PropertyPlaceholderConfigurer to do the interpolation and would have no idea how the user has configured the property resolution etc.

---

Affects: 2.5.1

18 votes, 17 watchers

[spring-projects-issues]

Juergen Hoeller commented

The problem there is that NamespaceHandlers are processed in a pre-bean-initialization phase, with bean bootstrapping - and hence PropertyPlaceholderConfigurer bootstrapping - kicking in one phase later. The main reason for this is that NamespaceHandlers may register further beans, which may even turn out to be further BeanFactoryPostProcessors... hence all those NamespaceHandlers have to be fully processed before the bean post-processing phase begins.

We'll revisit this for Spring 3.0.

Juergen

[spring-projects-issues]

Tuomas Kiviaho commented

I was planning myself to use javax.el (JUEL, https://jsp.dev.java.net, etc.) for parsing purposes leveraging BeanDefinitionVisitor similar to PropertyPlaceholderConfigurer .

I noticed from missing RuntimeBeanNameReference support that org.springframework.beans.factory.support.BeanDefinitionValueResolver doesn't make use of org.springframework.beans.factory.config.BeanDefinitionVisitor which is key part of PropertyPlaceholderConfigurer.

For namespace handler purposes I could imagine xpath suiting better than expressions when referencing XML itself instead of bean definitions. At least with JAXB annotation one could implement unmarshalling based on existence of @XmlID and @XmlIDREF or dig out the information from schema (http://www.w3.org/TR/xslt#key ID, IDFREF, IDREFS). I don't know if it is encouraged to use BeanDefinitionVisitor at that phase but instead TypedStringValue combined with TypeConverter could be used to postpone the resolving of xpath expressions.

Tuomas

[spring-projects-issues]

Martin Gilday commented

Please see the following issues for examples:

http://issues.apache.org/activemq/browse/CAMEL-674
http://issues.apache.org/activemq/browse/CAMEL-1066

[spring-projects-issues]

Leoš Bitto commented

I think that the problem with PropertyPlaceholderConfigurer which is a BeanFactoryPostProcessor is that currently the Spring Framework is not flexible enough with ordering of the BeanFactoryPostProcessors. Check my issue #10298 to see another result of this inflexibility and a suggestion for an improvement - I hope that the NamespaceHandlers could be rewriten to be BeanFactoryPostProcessors, given the proper ordering of the BeanFactoryPostProcessors...

[spring-projects-issues]

Peter Chandler commented

Maybe related to my Apache Camel issue using PropertyPlaceholderConfigurer:

Caused by: java.lang.IllegalArgumentException: Invalid directory: ${atis.in.directory}. Dynamic expressions with ${ } placeholders is not allowed. Use the fileName option to set the dynamic expression.
at org.apache.camel.component.file.FileComponent.buildFileEndpoint(FileComponent.java:40)
at org.apache.camel.component.file.GenericFileComponent.createEndpoint(GenericFileComponent.java:53)
at org.apache.camel.component.file.GenericFileComponent.createEndpoint(GenericFileComponent.java:36)
at org.apache.camel.impl.DefaultComponent.createEndpoint(DefaultComponent.java:80)
at org.apache.camel.impl.DefaultCamelContext.getEndpoint(DefaultCamelContext.java:425)
... 28 more

[spring-projects-issues]

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