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 <[EMAIL PROTECTED]>:
> 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.
>


-- 
Venlig hilsen / Kind regards,
Christian Vest Hansen.

Reply via email to