You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Callum Haig <ca...@googlemail.com> on 2008/05/07 10:07:49 UTC
Unable to resolve the namespace "http://www.w3.org/2005/08/addressing" behind a firewall
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
Re: Unable to resolve the namespace "http://www.w3.org/2005/08/addressing" behind a firewall
Posted by Callum Haig <ca...@googlemail.com>.
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 <ca...@googlemail.com> 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.
>
>
Re: Unable to resolve the namespace
"http://www.w3.org/2005/08/addressing" behind a firewall
Posted by chaig <ca...@googlemail.com>.
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.