Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-issuemaster opened this Issue Feb 15, 2008 · 6 comments

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

spring-issuemaster commented Feb 15, 2008

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Feb 16, 2008

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Oct 21, 2008

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Nov 10, 2008

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Mar 31, 2009

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Jan 13, 2011

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Jan 12, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.