You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Christian Vest Hansen <ka...@gmail.com> on 2007/10/31 15:10:58 UTC
possible problems in imxing https and http?
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.
Re: possible problems in mixing https and http?
Posted by Christian Vest Hansen <ka...@gmail.com>.
Now we've implemented HTTPS between the content switch and our services like so:
(A) ---HTTPS---> (CS) ---HTTPS---> (S)
And CXF generates the correct URLs, however, all is still not good.
Now, the CXF clients gives the following error message:
log4j:WARN No appenders could be found for logger
(org.apache.cxf.bus.spring.BusApplicationContext).
log4j:WARN Please initialize the log4j system properly.
Nov 6, 2007 1:09:07 PM org.apache.cxf.configuration.spring.ConfigurerImpl <init>
INFO: Could not find the configuration file cxf.xml on the classpath.
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.create(WSDLServiceFactory.java:119)
at org.apache.cxf.jaxws.ServiceImpl.initializePorts(ServiceImpl.java:116)
at org.apache.cxf.jaxws.ServiceImpl.<init>(ServiceImpl.java:107)
... 8 more
Caused by: org.apache.ws.commons.schema.XmlSchemaException: Unable to
locate imported document at
'https://server.com/application/services/Service?xsd=Schema.xsd'',
relative to 'https://server.com/application/services/Service?wsdl'.
at org.apache.cxf.catalog.CatalogXmlSchemaURIResolver.resolveEntity(CatalogXmlSchemaURIResolver.java:71)
at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1872)
at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1902)
at org.apache.ws.commons.schema.SchemaBuilder.handleImport(SchemaBuilder.java:1627)
at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:175)
at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:364)
at org.apache.cxf.wsdl11.SchemaUtil.extractSchema(SchemaUtil.java:106)
at org.apache.cxf.wsdl11.SchemaUtil.getSchemas(SchemaUtil.java:66)
at org.apache.cxf.wsdl11.WSDLServiceBuilder.getSchemas(WSDLServiceBuilder.java:263)
at org.apache.cxf.wsdl11.WSDLServiceBuilder.buildServices(WSDLServiceBuilder.java:238)
at org.apache.cxf.wsdl11.WSDLServiceBuilder.buildServices(WSDLServiceBuilder.java:150)
at org.apache.cxf.wsdl11.WSDLServiceFactory.create(WSDLServiceFactory.java:117)
... 10 more
Any help? This is still version 2.0.3-incubator-SNAPSHOT.
2007/11/5, Christian Vest Hansen <ka...@gmail.com>:
> 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 <ni...@iona.com>:
> > 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 <ni...@iona.com>:
> > >
> > >> 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.
>
--
Venlig hilsen / Kind regards,
Christian Vest Hansen.
Re: possible problems in mixing https and http?
Posted by Christian Vest Hansen <ka...@gmail.com>.
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 <ni...@iona.com>:
> 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 <ni...@iona.com>:
> >
> >> 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.
Re: possible problems in mixing https and http?
Posted by Willem Jiang <ni...@iona.com>.
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 <ni...@iona.com>:
>
>> 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?
>>>
>>>
>>>
>>>
>>>
>
>
>
Re: possible problems in mixing https and http?
Posted by Christian Vest Hansen <ka...@gmail.com>.
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 <ni...@iona.com>:
> 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.
Re: possible problems in mixing https and http?
Posted by Willem Jiang <ni...@iona.com>.
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?
>
>
>
>