2011/11/5 Aki Yoshida <elak...@googlemail.com>: > 2011/11/5 Daniel Kulp <dk...@apache.org>: >> >> It's a bug in Aries: >> >> https://issues.apache.org/jira/browse/ARIES-626 > > Thanks for this info. I also noticed this issue. The solution will > probably require some kind of catalog files like spring has, I > suppose. I can wait for this fix, as I can look for a wifi spot to > avoid this issue until it's fixed. > > In contrast, the issue that I described is somewhat different (it > could be trivial). It's kind of the opposite problem. Having the > network connection, I can load all remote schemas set in the > includes/imports using their absolute URLs. But I cannot load locally > available schemas using their relative URLs, as sometimes done in some > of the spring versions of cxf schemas.
I read the Aris ticket again and noticed that the relative path problem was also mentioned in the comment section. So, until this relative-path issue is resolved, I could just physically include the included schemas for relative-inlcudes and use the absolute URLs for relative-imports (and refer to this aris ticket). For ws-rm, there is one relative include and one relative import. So, it won't be too much. regards, aki > > regards, aki > > >> >> >> 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 >> >
