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?