Spring OSGi
  1. Spring OSGi
  2. OSGI-364

Ability to disable XML validation when loading context files

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Incomplete
    • Affects Version/s: 1.0
    • Fix Version/s: 1.1 RC1
    • Component/s: CORE
    • Labels:
      None

      Description

      We are using Spring OSGi on a platform that has limited resources ("embedded"). Going from "plain" OSGi to Spring-OSGi we found that startup time of our application (framework + bundles) has increased significantly (from 1m30s to 4m10s). After tracing we found that the biggest slowdown comes from the XML validation that the XmlBeanDefinitionReader performs.

      As a test we patched

      org.springframework.osgi.context.supportOsgiBundleXmlApplicationContext

      to configure the XmlBeanDefinitionReader to set validation mode to NONE, with the addition of 2 lines of code to the "loadBeanDefinitions" method:

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

      The setNamespaceAware(true) was an unexpected necessity to make Spring understand alternate namespaces (e.g. "osgi:") within the context files.

      With this patch to spring-osgi-core our startup time went from 4m10s to 1m40s on our hardware which has a poor CPU (300Mhz Intel Celeron).

      This improvement request is to evaluate whether mainline Spring OSGI could not be enhanced with a configuration property that defaults to doing XML validation as it does now but allows users to turn off validation for production use.

      1. context.xml
        0.6 kB
        Boris Terzic
      2. spring-beans-2.5.xsd
        40 kB
        Boris Terzic
      3. ValidationTest.java
        5 kB
        Boris Terzic

        Issue Links

          Activity

          Hide
          Costin Leau added a comment -

          > That looks very promising, are there any examples of what this will look like? Then I could try to see how we could put in our "toggleable validation" requirement.

          Take a look at the javadocs from the nightly build:
          http://static.springframework.org/spring-osgi/snapshot-site/apidocs/org/springframework/osgi/extender/package-summary.html

          and

          http://static.springframework.org/spring-osgi/snapshot-site/apidocs/index.html

          The documentation also explains how to attach new things to the extender configuration through a fragment
          (http://static.springframework.org/osgi/docs/current/reference/html/web.html#web:configuration).

          Show
          Costin Leau added a comment - > That looks very promising, are there any examples of what this will look like? Then I could try to see how we could put in our "toggleable validation" requirement. Take a look at the javadocs from the nightly build: http://static.springframework.org/spring-osgi/snapshot-site/apidocs/org/springframework/osgi/extender/package-summary.html and http://static.springframework.org/spring-osgi/snapshot-site/apidocs/index.html The documentation also explains how to attach new things to the extender configuration through a fragment ( http://static.springframework.org/osgi/docs/current/reference/html/web.html#web:configuration ).
          Hide
          Boris Terzic added a comment -

          I've reviewed the docs, if I understand correctly we'll be able to create a custom application context that modifies the bean creator to disable validation (based on a toggle).

          Show
          Boris Terzic added a comment - I've reviewed the docs, if I understand correctly we'll be able to create a custom application context that modifies the bean creator to disable validation (based on a toggle).
          Hide
          Costin Leau added a comment -

          > I've reviewed the docs, if I understand correctly we'll be able to create a custom application context that modifies the bean creator to disable validation (based on a toggle).

          Yes, that's the idea. There isn't any other declarative way, that I'm aware of. Let me know how this goes.
          Cheers,

          Show
          Costin Leau added a comment - > I've reviewed the docs, if I understand correctly we'll be able to create a custom application context that modifies the bean creator to disable validation (based on a toggle). Yes, that's the idea. There isn't any other declarative way, that I'm aware of. Let me know how this goes. Cheers,
          Hide
          Costin Leau added a comment -

          Boris, I'm closing this issue since I believe the mechanisms added in M2 can help you (not entirely though) with your problem. Reopen the issue or even better, start a discussion on the forums if you need more hooks in Spring-DM.

          Cheers,

          Show
          Costin Leau added a comment - Boris, I'm closing this issue since I believe the mechanisms added in M2 can help you (not entirely though) with your problem. Reopen the issue or even better, start a discussion on the forums if you need more hooks in Spring-DM. Cheers,
          Hide
          Boris Terzic added a comment -

          Fine by me Costin, thanks for being so receptive on this issue. Could you elaborate to what extent you think the new 1.1 functionality will not be sufficient? On first glance it seemed possible to use it to instantiate application contexts that have non-validating XML Bean processors.

          Show
          Boris Terzic added a comment - Fine by me Costin, thanks for being so receptive on this issue. Could you elaborate to what extent you think the new 1.1 functionality will not be sufficient? On first glance it seemed possible to use it to instantiate application contexts that have non-validating XML Bean processors.

            People

            • Assignee:
              Costin Leau
              Reporter:
              Boris Terzic
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development