cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <elak...@googlemail.com>
Subject Re: problem of importing/including schemas using relative paths in a schema read by blueprint's namespace handler
Date Sat, 05 Nov 2011 12:26:09 GMT
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.

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
>> dkulp@apache.org
>> http://dankulp.com/blog
>> Talend - http://www.talend.com
>>
>

Mime
View raw message