[ http://issues.apache.org/jira/browse/AXIS-1984?page=comments#action_65280 ] Ellis Pritchard commented on AXIS-1984: ---------------------------------------
I think I'm going to have to put this on ice externally (I need to use it internally) :( The reason is that I need to modify the WSDL4J API/implementation slightly to support using a WSDLLocator when 'reading' a WSDL passed in as a Document object; currently the API only allows specification of a WSDLLocator (which I can then use to resolve the import URIs) when reading a document solely through the readWSDL(WSDLLocator) method, it doesn't allow for setting one for Document based readWSDL() calls. With this API change (which involves simply adding a setLocator() method to javax.wsdl.xml.WSDLReader and its implementation), the solution works perfectly. The patch I submitted earlier, which relied solely on replacing the SymbolTable.getURL() method, was insufficient since, in my test case, I was mis-using the WSDL and specifying an xs:import element directly inside the wsdl:types element, rather than embedding it in an xs:schema element; this caused WSDL4J to ignore the schema, and the SymbolTable to import it itself, which then used all the resolution stuff. The correct use of wsdl:types resulted in WSDL4J processing the imports itself, without the benefit of any resolver. For your interest only (and the record), I'll submit the new patches to both axis and wsdl4j, but I don't expect them to be moved on. I've commented on JSR-110 asking for the new API call (both on SourceForge and via [EMAIL PROTECTED]), so who knows? ;) > WSDL2Java should use xml commons resolver to resolve xs:import/include URIs > --------------------------------------------------------------------------- > > Key: AXIS-1984 > URL: http://issues.apache.org/jira/browse/AXIS-1984 > Project: Axis > Type: Improvement > Components: WSDL processing > Versions: 1.2 > Environment: General (tested on Windows, Solaris) > Reporter: Ellis Pritchard > Attachments: xml-catalog.pch > > Currently WSDL2Java assumes that the schemaLocation URI specified in an XML > Schema <xs:import> or <xs:include> element is either a URL or a file path; it > would be a vast improvement if it could use the Apache XML Commons project's > Catalog based Resolver instead > (http://xml.apache.org/commons/components/resolver/). > It is not always possible to specify a file or URL location which is constant > and useable across development, test and live systems, so the ability that > XML Catalogs give to map arbitrary URIs or URI prefixes to alternative paths > is invaluable when creating portable and authoritative XML Schema/WSDL > service definitions. > The functionality could also be usefully (but in practice less importantly) > employed in <wsdl:import> elements. > Implementation should allow a root catalog to be specified on the command > line (WSDL2Java), and should pick up the configured catalog(s) (<xmlcatalog> > elements) from the Ant environment (axis-wsdl2java Ant task). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
