Spring Framework
  1. Spring Framework
  2. SPR-5014

Provide options in ClassPathXmlApplicationContext to disable XSD Validation

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: 2.5.5
    • Fix Version/s: None
    • Component/s: Core
    • Labels:
      None
    • Last commented by a User:
      true

      Description

      Disabling XSD validation provides a significant speed boost when the container starts up. Currently, ClassPathXmlApplicationContext does not provide a facility to disable XSD validation in a straight forward manner. Even though it is possible to do so by subclassing ClassPathXmlApplicationContext, it would be better to allow users to enable / disable XSD validation through the ClassPathXmlApplicationContext itself.

      As of Spring 2.5, XSD validation is not required to the framework to function properly. [Ref: SPR-3894]

      This can be done with a minor code change in ClassPathXmlApplicationContext as follows:

      public class ClassPathXmlApplicationContext extends AbstractXmlApplicationContext {

      private Resource[] configResources;
      private boolean validation = true; // validation is enabled by default

      protected void initBeanDefinitionReader(XmlBeanDefinitionReader beanDefinitionReader) {

      // If XSD validation is disabled
      if (! validation)

      { beanDefinitionReader.setValidationMode(XmlBeanDefinitionReader.VALIDATION_NONE); beanDefinitionReader.setNamespaceAware(true); }

      }

      // Provide overloaded constructors to enable / disable validation
      public ClassPathXmlApplicationContext(String configLocation, boolean validation) throws BeansException {
      this(new String[]

      {configLocation}

      , true, null);
      this.validation = validation;
      }

      // < REST OF CODE OMMITED>
      }

        Activity

        Hide
        Chris A Mattmann added a comment -

        Hi:

        Has this issue been resolved as of yet? I'm running into the issue where I want to disable XSD schema validation since I use Spring to configure a file crawler we've written, and I use the crawler in offline mode for testing, which causes an Exception to be thrown (due to the lack of Internet access).

        It would be really nice to have a system property or some sort of property to disable this validation as well.

        I appreciate your help.

        Cheers,
        Chris

        Show
        Chris A Mattmann added a comment - Hi: Has this issue been resolved as of yet? I'm running into the issue where I want to disable XSD schema validation since I use Spring to configure a file crawler we've written, and I use the crawler in offline mode for testing, which causes an Exception to be thrown (due to the lack of Internet access). It would be really nice to have a system property or some sort of property to disable this validation as well. I appreciate your help. Cheers, Chris
        Hide
        Juergen Hoeller added a comment -

        We don't plan to add further constructors to ClassPathXmlApplicationContext anymore, since there are too many of those already... We rather recommend subclassing - or the use of GenericApplicationContext with an explicit XmlBeanDefinitionReader, like as follows:

        GenericApplicationContext context = new GenericApplicationContext();
        XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(context);
        reader.setValidationMode(XmlBeanDefinitionReader.VALIDATION_NONE);
        reader.loadBeanDefinitions(...);
        context.refresh();

        This is much more flexible and configurable, and definitely preferable to ClassPathXmlApplicationContext/FileSystemXmlApplicationContext for non-trivial bootstrapping needs.

        Juergen

        Show
        Juergen Hoeller added a comment - We don't plan to add further constructors to ClassPathXmlApplicationContext anymore, since there are too many of those already... We rather recommend subclassing - or the use of GenericApplicationContext with an explicit XmlBeanDefinitionReader, like as follows: GenericApplicationContext context = new GenericApplicationContext(); XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(context); reader.setValidationMode(XmlBeanDefinitionReader.VALIDATION_NONE); reader.loadBeanDefinitions(...); context.refresh(); This is much more flexible and configurable, and definitely preferable to ClassPathXmlApplicationContext/FileSystemXmlApplicationContext for non-trivial bootstrapping needs. Juergen
        Hide
        Chris A Mattmann added a comment -

        Hi Juergen,

        Thanks, based on your feedback, would it make sense then to create a static factory method, or better yet, subclass (e.g., NonValidatingApplicationContext), that performs what you mentioned above? I would be happy to put together a patch, but it seems if the above is useful (and I agree it is), why not provide it as a utility out of the box?

        Cheers,
        Chris

        Show
        Chris A Mattmann added a comment - Hi Juergen, Thanks, based on your feedback, would it make sense then to create a static factory method, or better yet, subclass (e.g., NonValidatingApplicationContext), that performs what you mentioned above? I would be happy to put together a patch, but it seems if the above is useful (and I agree it is), why not provide it as a utility out of the box? Cheers, Chris
        Hide
        Juergen Hoeller added a comment -

        A convenient setValidating flag is available on our new GenericXmlApplicationContext now which should preferably be used over ClassPath/FileSystemXmlApplicationContext. The typical usage model looks like as follows, with refresh called explicitly:

        GenericXmlApplicationContext context = new GenericXmlApplicationContext();
        context.setValidating(false);
        context.load("myResource.xml", "otherResource.xml");
        context.refresh();

        I recommend creating custom ApplicationContext subclasses if you're always expecting specific settings, simply pre-populating those flags in the subclass constructor: not only setValidating but e.g. also setAllowCircularReferences and setAllowBeanDefinitionOverriding.

        Providing such specific subclasses out of the box, or even factory methods for specific settings, seems overkill since there is a whole set of candidate settings. The best concrete choice can still be made by yourself through a custom subclass (or custom factory method).

        Juergen

        Show
        Juergen Hoeller added a comment - A convenient setValidating flag is available on our new GenericXmlApplicationContext now which should preferably be used over ClassPath/FileSystemXmlApplicationContext. The typical usage model looks like as follows, with refresh called explicitly: GenericXmlApplicationContext context = new GenericXmlApplicationContext(); context.setValidating(false); context.load("myResource.xml", "otherResource.xml"); context.refresh(); I recommend creating custom ApplicationContext subclasses if you're always expecting specific settings, simply pre-populating those flags in the subclass constructor: not only setValidating but e.g. also setAllowCircularReferences and setAllowBeanDefinitionOverriding. Providing such specific subclasses out of the box, or even factory methods for specific settings, seems overkill since there is a whole set of candidate settings. The best concrete choice can still be made by yourself through a custom subclass (or custom factory method). Juergen
        Hide
        Chris A Mattmann added a comment -

        Providing such specific subclasses out of the box, or even factory methods for specific settings, seems overkill since there is a whole set of candidate settings. The best concrete choice can still be made by yourself through a custom subclass (or custom factory method)

        I'm not sure my use case is an isolated use case as is the implication above. I know many people in my organization that use Spring, who have mentioned similar problems related to using Spring with no internet connection (which causes the validation to choke) if validation is enabled on the application context.

        The code you provided above:

        GenericXmlApplicationContext context = new GenericXmlApplicationContext();
        context.setValidating(false);
        context.load("myResource.xml", "otherResource.xml");
        context.refresh();
        

        seems simple enough, and I'll happily use it. Still though, my +1 to have an explicit object, NonValidatingApplicationContext...

        Show
        Chris A Mattmann added a comment - Providing such specific subclasses out of the box, or even factory methods for specific settings, seems overkill since there is a whole set of candidate settings. The best concrete choice can still be made by yourself through a custom subclass (or custom factory method) I'm not sure my use case is an isolated use case as is the implication above. I know many people in my organization that use Spring, who have mentioned similar problems related to using Spring with no internet connection (which causes the validation to choke) if validation is enabled on the application context. The code you provided above: GenericXmlApplicationContext context = new GenericXmlApplicationContext(); context.setValidating( false ); context.load( "myResource.xml" , "otherResource.xml" ); context.refresh(); seems simple enough, and I'll happily use it. Still though, my +1 to have an explicit object, NonValidatingApplicationContext...
        Hide
        Gaetan Pitteloud added a comment -

        There's another use case where validation needs to be turned off, which is the usage of placeholders in configuration.

        When a Spring schema enforces the type of some XML attribute, a placeholder ($

        {...}

        ) cannot be set for that attribute.

        In most situations, application code cannot choose the application context class, as it is determined by Spring strategies in separate places (ContextLoaderListener, DispatcherServlet, Webflow code, etc). Although it is possible to override these strategies, I don't feel comfortable with this.

        Show
        Gaetan Pitteloud added a comment - There's another use case where validation needs to be turned off, which is the usage of placeholders in configuration. When a Spring schema enforces the type of some XML attribute, a placeholder ($ {...} ) cannot be set for that attribute. In most situations, application code cannot choose the application context class, as it is determined by Spring strategies in separate places (ContextLoaderListener, DispatcherServlet, Webflow code, etc). Although it is possible to override these strategies, I don't feel comfortable with this.

          People

          • Assignee:
            Juergen Hoeller
            Reporter:
            Yohan Liyanage
            Last updater:
            Trevor Marshall
          • Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Days since last comment:
              4 years, 12 weeks, 6 days ago