Spring OSGi
  1. Spring OSGi
  2. OSGI-810

Error creating application context - Failed to read schema document

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 2.0 M1
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:
      Spring-DM 2.0.0.M1
      Springframework 3.0.2.RELEASE
      OS: WIN XP

      Description

      During start of bundles sometimes creating of some application context failed.
      Reason is the validation of the application context because the xsd-files cannot be found.
      See discussion on forum (http://forum.springsource.org/showthread.php?t=84088).

        Activity

        Hide
        Ed Swierk added a comment -

        I think we're seeing a symptom of this problem:

        We keep running into org.springframework.beans.factory.xml.XmlBeanDefinitionStoreExceptions when starting our app on a machine that's disconnected from the Internet (either deliberately or inadvertently). The failures are intermittent and apparently dependent on the timing and order in which bundles are started.

        It seems that sometimes the org.springframework.osgi.extender bundle starts before anything else, and tries to parse context.xml from another bundle that references either spring-beans-2.5.xsd or blueprint.xsd. Since the bundle providing these isn't yet loaded in the classpath, the XML parser tries to fetch the schema files from the official URL, which hangs.

        I'm able to work around this by setting the start level of the extender bundle to something higher than the default (4), like 6, so it gets loaded last.

        Messing with start levels seems like a fragile workaround. Is there a better fix?

        Show
        Ed Swierk added a comment - I think we're seeing a symptom of this problem: We keep running into org.springframework.beans.factory.xml.XmlBeanDefinitionStoreExceptions when starting our app on a machine that's disconnected from the Internet (either deliberately or inadvertently). The failures are intermittent and apparently dependent on the timing and order in which bundles are started. It seems that sometimes the org.springframework.osgi.extender bundle starts before anything else, and tries to parse context.xml from another bundle that references either spring-beans-2.5.xsd or blueprint.xsd. Since the bundle providing these isn't yet loaded in the classpath, the XML parser tries to fetch the schema files from the official URL, which hangs. I'm able to work around this by setting the start level of the extender bundle to something higher than the default (4), like 6, so it gets loaded last. Messing with start levels seems like a fragile workaround. Is there a better fix?
        Hide
        Roland Hofmann added a comment -

        Hello Ed Swierk,

        thank you for your comment. I'm waiting for so long time and nothing happens at this situation.
        I thought that we are the only ones that has such problems with the new Spring DM version.
        We are still running at the old version of Spring and Spring DM, because the solution with the start order of the bundles doesn't work in our situation.
        @Costin Leau: Can we expect in near future that you will have a look at our problem?

        Thanks, Greetings Roland

        Show
        Roland Hofmann added a comment - Hello Ed Swierk, thank you for your comment. I'm waiting for so long time and nothing happens at this situation. I thought that we are the only ones that has such problems with the new Spring DM version. We are still running at the old version of Spring and Spring DM, because the solution with the start order of the bundles doesn't work in our situation. @Costin Leau: Can we expect in near future that you will have a look at our problem? Thanks, Greetings Roland
        Hide
        Costin Leau added a comment -

        Hi guys,

        First of all, Spring DM loads the local schemas (embedded in the JARs) only from the bundles that are started (not just resolved). This behaviour has changed since the early releases since otherwise a lot of scanning would be involved even in bundles that would should not have been touched.
        Which means that for the most part, the bundles that provide the schemas need to be started first so when the extender starts, the bundles are considered. A solution would be to wait for the other bundles to be available but there's no built in mechanism in OSGi to do this reliably.
        Another alternative would be to revert the behaviour and consider resolved bundles instead of just the started ones.

        Show
        Costin Leau added a comment - Hi guys, First of all, Spring DM loads the local schemas (embedded in the JARs) only from the bundles that are started (not just resolved). This behaviour has changed since the early releases since otherwise a lot of scanning would be involved even in bundles that would should not have been touched. Which means that for the most part, the bundles that provide the schemas need to be started first so when the extender starts, the bundles are considered. A solution would be to wait for the other bundles to be available but there's no built in mechanism in OSGi to do this reliably. Another alternative would be to revert the behaviour and consider resolved bundles instead of just the started ones.
        Hide
        David Erickson added a comment -

        Hi Costin-
        Is this behavior configurable or overridable on the current release?

        Thanks,
        David

        Show
        David Erickson added a comment - Hi Costin- Is this behavior configurable or overridable on the current release? Thanks, David
        Hide
        Costin Leau added a comment -

        No, not out of the box. You could though modify the sources in the intermin.
        As a side note, all future updates on the 2.0.x branch will take place at Eclipse Gemini Blueprint.

        Show
        Costin Leau added a comment - No, not out of the box. You could though modify the sources in the intermin. As a side note, all future updates on the 2.0.x branch will take place at Eclipse Gemini Blueprint.

          People

          • Assignee:
            Costin Leau
            Reporter:
            Roland Hofmann
          • Votes:
            3 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:

              Development