cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: problem of importing/including schemas using relative paths in a schema read by blueprint's namespace handler
Date Mon, 07 Nov 2011 15:02:03 GMT
On Saturday, November 05, 2011 1:26:09 PM Aki Yoshida wrote:
> 2011/11/5 Aki Yoshida <elakito@googlemail.com>:
> > 2011/11/5 Daniel Kulp <dkulp@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
> >> dkulp@apache.org
> >> http://dankulp.com/blog
> >> Talend - http://www.talend.com
-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com

Mime
View raw message