It's a bug in Aries: https://issues.apache.org/jira/browse/ARIES-626
Something on my todo list to fix once things calm down a bit for me with other work related things. Dan On Friday, November 04, 2011 8:00:06 PM Aki Yoshida wrote: > Hi, > Sorry for the long subject. I didn't know how to describe the problem > better. > > I was wondering if you need to do something extra to be able to import > or include a schema located at some relative path when you let the > blueprint namespace handler fetch the parent schema. > > I wanted to make the ws-rm component also blueprint-ready. It is > working fine except that I cannot seem to be able to use a relative > path in the schemaLocation attribute of the blueprint version of the > schema. > > Concretely, I am having this problem with the following two lines in > the blueprint version of wsrm-manager.xsd. > > <xs:include schemaLocation="wsrm-manager-types.xsd"/> > <xs:import namespace="http://schemas.xmlsoap.org/ws/2005/02/rm/policy"; > schemaLocation="wsrm-policy.xsd"/> > > I am getting the following exception when I start a blueprint bundle > using this feature: > > 2011-11-04 19:33:01,550 | ERROR | rint Extender: 1 | > BlueprintContainerImpl | container.BlueprintContainerImpl > 358 | 9 - org.apache.aries.blueprint - 0.3.1 | Unable to start > blueprint container for bundle tmp.test-cxf-wsrm-provider-bp > org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name > 'tns:deliveryAssurance' to a(n) 'element declaration' component. > at > com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseE > xception(ErrorHandlerWrapper.java: 195)[:1.6.0_24] > at > com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHand > lerWrapper.java:131)[:1.6.0_24] at > com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErr > orReporter.java:384)[:1.6.0_24] at > com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.reportSche > maErr(XSDHandler.java:2537)[:1.6.0_24] at > com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.reportSche > maError(XSDHandler.java:2528)[:1.6.0_24] at > com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.getGlobalD > ecl(XSDHandler.java:1472)[:1.6.0_24] at > com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDElementTraverser.t > raverseLocal(XSDElementTraverser.java:160)[:1.6.0_24] at > com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.traverseLo > calElements(XSDHandler.java:2049)[ > :1.6.0_24] > > at > com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.parseSchem > a(XSDHandler.java:582)[:1.6.0_24] at > com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadSchema(XMLSc > hemaLoader.java:552)[:1.6.0_24] at > com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLS > chemaLoader.java:519)[:1.6.0_24] at > com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLS > chemaLoader.java:485)[:1.6.0_24] at > com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory.newSche > ma(XMLSchemaFactory.java:211)[:1.6.0_24] at > org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.getSchema > (NamespaceHandlerRegistryImpl.java > :243)[9:org.apache.aries.blueprint:0.3.1] > > at > org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$Namespace > HandlerSetImpl.getSchema(NamespaceHandlerRegistryImpl.java:329)[9:org.apache > .aries.blueprint:0.3.1] at > org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(Blueprint > ContainerImpl.java:275)[9:org.apache.aries.blueprint:0.3.1] at > org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintCo > ntainerImpl.java:227)[9:org.apache.aries.blueprint:0.3.1] ... > > > When I inline the included schema and also replace the rm-policy > schema's relative path with the external rm-policy location > "http://schemas.xmlsoap.org/ws/2005/02/rm/wsrm-policy.xsd";, it is > working fine. > > This problem has probably something to do with the parser setting. > Maybe, it is a simple thing. But I was not able to figure it out. The > same problem is not happening with spring, maybe because spring uses > its catalog files to read all the schemas (but for the include's, it > should be relying on the same parser mechanism, so this is strange.). > > If someone has some idea to resolve this problem, that would be very > appreciated. > > Thanks. > > regards, aki -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
