Some more followup: It seems likely that the bloating of the JAXB context with extraneous classes during the initalialization of my JobCreation service was due to the lack of application of the @XmlSeeAlso annotation. In its absense (and the absence of a jaxb.index file, which wouldn't have helped anyway due to lack of service-specificity) it seems as though the context was filled with all classes in the same package, and classes referred to by those classes. Once I added the annotation and an appropriate ObjectFactory for the JobCreation service no attempts were made to resolve the problematic namespace.
Regards, Callum. On Thu, May 8, 2008 at 11:35 AM, chaig <[EMAIL PROTECTED]> wrote: > > 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. > >
