I have some followup to my earlier post. As part of an investigation of technologies for wrapping existing code as web services I have defined a number of services. One represents a simple, synchronous service called JobCreation. The other two represent an alternative asynchronous approach: AsyncJobCreation and JobCreationCallback. The AsyncJobCreation service uses javax.xml.ws.wsaddressing.W3CEndpointReference and its WSDL imports the necessary schema with:
<xsd:import namespace="http://www.w3.org/2005/08/addressing"; schemaLocation="schemas/wsdl/ws-addr.xsd"/> The JobCreation service does not require any references to javax.xml.ws.wsaddressing classes or the corresponding schema. When the AsyncJobCreation service is initialized I can see that org.apache.cxf.common.xmlschema.SchemaCollection.setSchemaResolver(URIResolver schemaResolver) is called with an instance of org.apache.cxf.catalog.CatalogXmlSchemaURIResolver. This causes org.apache.ws.commons.schema.XmlSchemaCollection to look in jar:file:/path/to/cxf-common-schemas-2.1.jar!/schemas/wsdl/ws-addr.xsd for the ws-addr.xsd, which it finds. When JobCreation is initialized, a org.apache.ws.commons.schema.resolver.DefaultURIResolver is used (perhaps because no WSDL with an xsd:import statement of the kind above is implicated?). For some reason it also seems to try to resolve the "http://www.w3.org/2005/08/addressing"; namespace, in this case to "http://www.w3.org/2006/03/addressing/ws-addr.xsd"; which is not reachable from behind the corporate firewall. I believe that this need to resolve "http://www.w3.org/2005/08/addressing";, despite it not being required by JobCreation service (only AsyncJobCreation) may be due to the fact that the org.apache.cxf.jaxb.JAXBDataBinding.context has references to javax.xml.ws.wsaddressing.W3CEndpointReference. This may result from reflection on the AsyncJobCreation service and supporting classes which happen to be in the same package, or because one of those classes has a @WebServiceClient annotation which has a wsdlLocation parameter which refers to the WSDL for the AsyncJobCreation service. If this speculation is correct, it seems some improvements might be made. (If not please tell me what I'm doing wrong and how to fix it.) Either the JAXBDataBinding.context should contain references only to the service being initialized and not to extraneous classes which happen to be in the same package. Or the URIResolver should be set more appropriately, possibly by the user. However I believe this latter, still wouldn't solve my problem, since even if the initialization of the JobCreation service used the CatalogXmlSchemaURIResolver, there would still need to be an xsd:import clause like that above in the associated WSDL. Not only did I use a Java first approach with JobCreation (though not AsyncJobCreation), but even if I had a WSDL I wouldn't want a reference to http://www.w3.org/2005/08/addressing since its not required by that service. Regards, Callum. chaig wrote: > > I'm having some difficulties which are related to failed attempts to > resolve the namespace "http://www.w3.org/2005/08/addressing"; behind a > firewall during initialization of a JAX-WS service. I can see that a > copy of the xsd is located within the cx-common-schemas jar (at > schemas/wsdl/ws-addr.xsd). However, I believe it is not being resolved > because org.apache.ws.commons.schema.XmlSchemaCollection.schemaResolver > has been assigned an instance of type > org.apache.ws.commons.schema.resolver.DefaultURIResolver. > > I believe if I can arrange for a > org.apache.cxf.catalog.CatalogXmlSchemaURIResolver to be used instead > I may be able to resolve the namespace to the file in the CXF jar. Is > it possible to do that declaratively, in Spring config? Or perhaps > there's another approach someone can suggest? > > Regards, > Callum > > -- View this message in context: http://www.nabble.com/Unable-to-resolve-the-namespace-%22http%3A--www.w3.org-2005-08-addressing%22-behind-a-firewall-tp17099652p17117635.html Sent from the cxf-user mailing list archive at Nabble.com.
