Spring Framework
  1. Spring Framework
  2. SPR-4466

allow a Spring 2 NamespaceHandler to invoke the Spring registered PropertyPlaceholderConfigurer on the XML Element before processing

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.5.1
    • Fix Version/s: Waiting for Triage
    • Component/s: Core
    • Labels:
      None
    • Last commented by a User:
      true

      Description

      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.

        Activity

        Hide
        Juergen Hoeller added a comment -

        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

        Show
        Juergen Hoeller added a comment - 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
        Hide
        Tuomas Kiviaho added a comment -

        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

        Show
        Tuomas Kiviaho added a comment - 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
        Hide
        Martin Gilday added a comment -
        Show
        Martin Gilday added a comment - Please see the following issues for examples: http://issues.apache.org/activemq/browse/CAMEL-674 http://issues.apache.org/activemq/browse/CAMEL-1066
        Hide
        Leoš Bitto added a comment -

        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 SPR-5627 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...

        Show
        Leoš Bitto added a comment - 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 SPR-5627 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...
        Hide
        Peter Chandler added a comment -

        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

        Show
        Peter Chandler added a comment - 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

          People

          • Assignee:
            Juergen Hoeller
            Reporter:
            James Strachan
            Last updater:
            Juergen Hoeller
          • Votes:
            17 Vote for this issue
            Watchers:
            16 Start watching this issue

            Dates

            • Created:
              Updated:
              Days since last comment:
              3 years, 14 weeks, 6 days ago