cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Liu, Jervis" <>
Subject RE: CXF Bug 448: Imported XSD Update
Date Thu, 22 Mar 2007 03:25:16 GMT
Good catch, Bharath. Actually there are two cases this xsd stuff wont work properly. One is
when multiple endpoints deployed in Servlet, what you have suggested sounds a good fix, shall
work. Another case is when endpoint is published under standalone mood, we don't have any
support for xsd access yet in this case, a fix might look similar to org.apache.cxf.transport.http.WSDLQueryHandler.
 I have filed JIRA and
to track these issues. Also please feel free to submit a patch if you are interested in contributing
more :-) 


> -----Original Message-----
> From: Bharath Ganesh []
> Sent: 2007?3?21? 19:46
> To:
> Subject: CXF Bug 448: Imported XSD Update
> Hi
> Looks like the recently checked-in fix for Bug: CXF 448 wont 
> work in certain
> cases.
> The wsdllocation is stored in the ServletController while the 
> endpoint is
> built from the CXFServlet (CXFServlet#buildEndpoint). Assume 
> I have multiple
> endpoints deployed(which would have different wsdllocations).
> I could have a single WAR app deployed in the web server, and publish
> multiple services to it.
> I could programatically publish an endpoint without going through the
> CXFServlet. In such cases this solution would fail.
> I could think of one probable solution to this issue:
> 1. Currently, while publishing we store the Server with the 
> ServerRegistry.
> 2. Later when a request comes for an XSD, we get the 
> corresponding Endpoint
> from the ServerRegistry. (Using the Endpoint's address field)
> 3. Add a method to Endpoint API to get the wsdlLocation from Endpoint.
> Thus we can get hold of the user supplied wsdl location, 
> later resolve the
> xsd location relative to it.
> Please tell me if there is a better solution.
> Thanks
> Bharath

View raw message