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 http://issues.apache.org/jira/browse/CXF-482 and http://issues.apache.org/jira/browse/CXF-483 to track these issues. Also please feel free to submit a patch if you are interested in contributing more :-)
Cheers, Jervis > -----Original Message----- > From: Bharath Ganesh [mailto:[EMAIL PROTECTED] > Sent: 2007?3?21? 19:46 > To: [email protected] > 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 >
