Announcement Announcement Module
Collapse

Spring Dynamic Modules forum decommissioned in favor of Eclipse Gemini Blueprint

With the official first release of Eclipse Gemini Blueprint shipped, the migration of the Spring Dynamic Modules code base to the Eclipse Foundation, as part of the Gemini project, has been completed.

As such, this forum has been decommissioned in favour of the Eclipse Gemini forums.
See more
See less
Random namespace schema validation error Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Random namespace schema validation error

    We're sometimes seeing the following when we start our (Blueprint-enabled) Felix-based OSGi runtime:

    Caused by: org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'si:gateway'.
    at com.sun.org.apache.xerces.internal.util.ErrorHandl erWrapper.createSAXParseException(ErrorHandlerWrap per.java:195)
    at com.sun.org.apache.xerces.internal.util.ErrorHandl erWrapper.error(ErrorHandlerWrapper.java:131)
    at com.sun.org.apache.xerces.internal.impl.XMLErrorRe porter.reportError(XMLErrorReporter.java:384)
    at com.sun.org.apache.xerces.internal.impl.XMLErrorRe porter.reportError(XMLErrorReporter.java:318)
    at com.sun.org.apache.xerces.internal.impl.xs.XMLSche maValidator$XSIErrorReporter.reportError(XMLSchema Validator.java:417)
    at com.sun.org.apache.xerces.internal.impl.xs.XMLSche maValidator.reportSchemaError(XMLSchemaValidator.j ava:3182)
    at com.sun.org.apache.xerces.internal.impl.xs.XMLSche maValidator.handleStartElement(XMLSchemaValidator. java:1927)
    at com.sun.org.apache.xerces.internal.impl.xs.XMLSche maValidator.emptyElement(XMLSchemaValidator.java:7 25)
    at com.sun.org.apache.xerces.internal.impl.XMLNSDocum entScannerImpl.scanStartElement(XMLNSDocumentScann erImpl.java:377)
    at com.sun.org.apache.xerces.internal.impl.XMLDocumen tFragmentScannerImpl$FragmentContentDriver.next(XM LDocumentFragmentScannerImpl.java:2755)
    at com.sun.org.apache.xerces.internal.impl.XMLDocumen tScannerImpl.next(XMLDocumentScannerImpl.java:648)
    at com.sun.org.apache.xerces.internal.impl.XMLNSDocum entScannerImpl.next(XMLNSDocumentScannerImpl.java: 140)
    at com.sun.org.apache.xerces.internal.impl.XMLDocumen tFragmentScannerImpl.scanDocument(XMLDocumentFragm entScannerImpl.java:511)
    at com.sun.org.apache.xerces.internal.parsers.XML11Co nfiguration.parse(XML11Configuration.java:808)
    at com.sun.org.apache.xerces.internal.parsers.XML11Co nfiguration.parse(XML11Configuration.java:737)
    at com.sun.org.apache.xerces.internal.parsers.XMLPars er.parse(XMLParser.java:119)
    at com.sun.org.apache.xerces.internal.parsers.DOMPars er.parse(DOMParser.java:235)
    at com.sun.org.apache.xerces.internal.jaxp.DocumentBu ilderImpl.parse(DocumentBuilderImpl.java:284)
    at org.springframework.beans.factory.xml.DefaultDocum entLoader.loadDocument(DefaultDocumentLoader.java: 75)
    at org.springframework.beans.factory.xml.XmlBeanDefin itionReader.doLoadBeanDefinitions(XmlBeanDefinitio nReader.java:388)
    ... 18 more


    We think we know what's going on but we're unsure of the best solution.

    Some background: one of our bundles depends on Spring Integration. That bundle uses the standard SI namespace:

    <?xml version="1.0" encoding="UTF-8"?>
    <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:si="http://www.springframework.org/schema/integration"
    xmlns:spring="http://www.springframework.org/schema/beans"
    xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
    http://www.osgi.org/xmlns/blueprint
    http://www.springframework.org/schema/beans
    http://www.springframework.org/schem...-beans-3.0.xsd
    http://www.springframework.org/schema/integration
    http://www.springframework.org/schema/integration/spring-integration-2.0.xsd">

    .
    .
    .

    </blueprint>

    Based on the debug logging it looks like this bundle is getting started and parsed by Spring-DM before the Spring Integration bundle has fully started, so the schema embedded inside the spring integration jar isn't found.

    The question is, how can/should we work around this? One way would be to use start levels such that our system bundles (Spring-DM, Integration, etc.) are started before our application bundles.

    Could it actually be that the blueprint extender is a little too agressive in waiting for bundle STARTING events instead of STARTED events before looking for and parsing the blueprint.xml?
Working...
X