It seems my trouble continues.
I think I should try to explain the situation again:
We have a CXF web service client (A) that access a CXF web service (S)
through a content switch (CS), such that the client speaks HTTPS with
the content switch, who in turn speak plain HTTP with the web service:
(A) ---HTTPS---> (CS) ---HTTP---> (S)
The web service (S) has a WSDL that refer to a schema much like this:
<wsdl:types>
<xsd:schema targetNamespace="http://ns.com/xsd";>
<xsd:import namespace="http://ns.com/xsd";
schemaLocation="Schema.xsd"/>
</xsd:schema>
</wsdl:types>
The schema is deployed as part of the web application (ie. it's in the .war).
Now, when we deploy this service, CXF modifies the published WSDL so
that the schemaLocation attribute comes up with this value:
<wsdl:types>
<xsd:schema targetNamespace="http://ns.com/xsd";>
<xsd:import namespace="http://ns.com/xsd";
schemaLocation="http://server.com/application/services/Service?xsd=Schema.xsd"/>
</xsd:schema>
</wsdl:types>
Notice how the schemaLocation points to a plain HTTP address.
Initially, we thought that we could just make all HTTP calls to the
server be redirected to their respective HTTPS counterparts - and this
trick does indeed work well with our Ruby clients, however, the CXF
clients does not respond correctly to the redirect
(2.0.3-incubator-SNAPSHOT):
[Fatal Error] :-1:-1: Premature end of file.
Exception in thread "main" javax.xml.ws.WebServiceException:
org.apache.cxf.service.factory.ServiceConstructionException: Failed to
create service.
at org.apache.cxf.jaxws.ServiceImpl.<init>(ServiceImpl.java:109)
at
org.apache.cxf.jaxws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:55)
at javax.xml.ws.Service.<init>(Service.java:57)
at my.client.Main.main(Main.java:125)
Caused by: org.apache.cxf.service.factory.ServiceConstructionException:
Failed to create service.
at
org.apache.cxf.wsdl11.WSDLServiceFactory.<init>(WSDLServiceFactory.java:83)
at
org.apache.cxf.jaxws.ServiceImpl.initializePorts(ServiceImpl.java:115)
at org.apache.cxf.jaxws.ServiceImpl.<init>(ServiceImpl.java:107)
... 8 more
Caused by: javax.wsdl.WSDLException: WSDLException (at
/wsdl:definitions/wsdl:types/xsd:schema): faultCode=PARSER_ERROR:
Problem parsing
'http://server.com/application/services/Service?xsd=Schema.xsd'.:
org.xml.sax.SAXParseException: Premature end of file.
at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.parseSchema(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.parseSchema(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.parseTypes(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.parseDefinitions(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at
org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:199)
at
org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java:163)
at
org.apache.cxf.wsdl11.WSDLServiceFactory.<init>(WSDLServiceFactory.java:81)
... 10 more
Caused by: org.xml.sax.SAXParseException: Premature end of file.
at
com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:264)
at
com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:292)
... 23 more
And I think this is because...
> We just use java's URL to get wsdl not the HTTPConduit.
... which, it seems since I tested it out (1.5.0_07-87), can't handle redirects.
So, I'm at a crossroad: I can (1) make the content switch use HTTPS
when speaking with the service (S), I could (2) further lobby you guys
to add configurations that would let me control the URL generation in
CXF, or (3) I could ask you to handle redirects.
Personally, I'm in a hurry, so I'm rushing ahead with (1), but (3)
kind of seems like a bug in my eyes, and (2) would also be nice though
not that important (to me, personally) if (3) works.
2007/11/1, Willem Jiang <[EMAIL PROTECTED]>:
> AFAIK, HTTPConduit will not take any charge to load WSDL related
> information.
> We just use java's URL to get wsdl not the HTTPConduit.
>
> Willem.
>
> Christian Vest Hansen wrote:
> > I'm not quite sure fixing that jira will solve this particular issue.
> >
> > It seems to me that CXF has trouble connecting to anything HTTP once
> > it has been configured to use HTTPS.
> >
> >
> >
> > 2007/11/1, Willem Jiang <[EMAIL PROTECTED]>:
> >
> >> Hi Christian,
> >>
> >> I think we could achieve you goal by letting service that CXF published
> >> the WSDL with user defined , so you could add what you want https or
> >> http protocol string on the address or the xsd including part.
> >>
> >> Here is a JIRA[1] of trace it, if you have time to write a patch , I can
> >> give your some points from my view.
> >> [1]https://issues.apache.org/jira/browse/CXF-341
> >>
> >> Willem.
> >>
> >> Christian Vest Hansen wrote:
> >>
> >>> We're planning on exposing a number of web services through HTTPS,
> >>> however, many of the WSDLs will refer to and import schema files that
> >>> we have stored in a central repository - and this repository is
> >>> accessed through ordinary HTTP.
> >>>
> >>> In other words, our clients access a WSDL through HTTPS - this WSDL
> >>> has references to a schema that the client has to access through plain
> >>> HTTP.
> >>>
> >>> Will this cause any problems with HTTPConduits and other
> >>> configurations that clients will have in order to access the otherwise
> >>> HTTPS enabled web service?
> >>>
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
>
--
Venlig hilsen / Kind regards,
Christian Vest Hansen.
