On Saturday, November 05, 2011 1:26:09 PM Aki Yoshida wrote: > 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.
I talked to Johan a bit on Friday night and discovered the relative path thing is likely easy to fix. There is a call in Aries of: schemaSources.add(new StreamSource(url.openStream())); which likely just needs to be updated to add the systemId to the StreamSource. That said, putting a full LSResolver in the schema factory is really what's needed as well. Again, after ApacheCon.... Dan > > 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.createSA > >>> XParseE xception(ErrorHandlerWrapper.java: 195)[:1.6.0_24] > >>> at > >>> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(Er > >>> rorHand 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.rep > >>> ortSche maErr(XSDHandler.java:2537)[:1.6.0_24] at > >>> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.rep > >>> ortSche maError(XSDHandler.java:2528)[:1.6.0_24] at > >>> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.get > >>> GlobalD ecl(XSDHandler.java:1472)[:1.6.0_24] at > >>> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDElementTrav > >>> erser.t raverseLocal(XSDElementTraverser.java:160)[:1.6.0_24] at > >>> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.tra > >>> verseLo calElements(XSDHandler.java:2049)[ > >>> > >>> :1.6.0_24] > >>> > >>> at > >>> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.par > >>> seSchem a(XSDHandler.java:582)[:1.6.0_24] at > >>> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadSchem > >>> a(XMLSc hemaLoader.java:552)[:1.6.0_24] at > >>> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGramm > >>> ar(XMLS chemaLoader.java:519)[:1.6.0_24] at > >>> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGramm > >>> ar(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.ge > >>> tSchema (NamespaceHandlerRegistryImpl.java > >>> > >>> :243)[9:org.apache.aries.blueprint:0.3.1] > >>> > >>> at > >>> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$Na > >>> mespace > >>> HandlerSetImpl.getSchema(NamespaceHandlerRegistryImpl.java:329)[9:o > >>> rg.apache .aries.blueprint:0.3.1] at > >>> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(Bl > >>> ueprint ContainerImpl.java:275)[9:org.apache.aries.blueprint:0.3.1] > >>> at > >>> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(Blu > >>> eprintCo 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 -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
