WODEN-44 is about creating the XMLElement abstraction to eliminate the need for DOMUtils and OMUtils and refactoring common parsing behaviour into BaseWSDLReader.
The code in the WODEN-44 branch is ready for review, prior to merging it back into Trunk. I would like to merge WODEN-44 to Trunk by end of day Friday 20th October, to minimize divergence of the code streams and the integration effort. If you would like to review WODEN-44, please do so by 4PM GMT on Friday. I have completed the development and testing for WODEN-44. This includes OMXMLElement and OMWSDLReader - Oshani, I didn't hear from you after my last post so I assumed it was OK for me to do this, but please comment if you can see any mistakes or problems. Note that for now I have just commented out the old methods in OMWSDLReader, I have not yet deleted them. I have also merged the latest updates from Trunk into the WODEN-44 branch, including the WODEN-14 updates for URI Resolver...and re-tested with these updates. DESIGN:- ElementSource has been renamed to XMLElement. XMLElement has methods that mirror the relevant behaviour of DOM Element and OMElement and largely replace the need for DOMUtils and OMUtils (although I have not yet removed these classes). Parsing is now mostly based on these XMLElement methods and has been largely refactored from DOMWSDLReader and OMWSDLReader into BaseWSDLReader. The concrete reader classes still implement a few methods where DOM or OM specific functionality is required. XMLElement is implemented by DOMXMLElement and OMXMLElement. TESTING:- Please do not make any changes to Trunk yet to fix these failures, but instead wait until WODEN-44 has been merged back into Trunk. There are 3 failures when running AllWodenTests in the WODEN-44 branch: - SchemaId1G fails for the DOM and OM implementations. - TicketAgent1B fails for the OM implementation. SchemaId1G: This wsdl contains two inlined schemas with fragids. One imports the other. The fragid reference is not being resolved correctly and fails in both implementations - OM and DOM (might be an XmlSchema problem?). Note, this failure occurs for the DOM implementation in Trunk too. It does not occur for the OM implementation in Trunk because the OMWSDLReader.parseTypes method in Trunk only parses the first schema encountered, so parsing never reaches the second schema which contains the xsd:import with the fragid. TicketAgent1B: The wsdl testcase does a schema import of TicketAgent.xsd, but this file does not exist. This testcase does not fail in the DOM implementation because it catches the FileNotFoundException and handles it as a warning. The OM implementation catches the FileNotFoundException but just prints the stack trace and continues on, resulting in a NPE later on. I'll post to the WSDL2 mailing list later about whether this XSD file should exist with the testcase. I have made two corrections to OMSimpleURIResolverTest: 1) To ensure the OMWSDLFactory is used - WSDLFactory factory = OMWSDLFactory.newInstance( "org.apache.woden.internal.OMWSDLFactory"); 2) I changed the assert for imported schemas from expected value of 1 to zero. The testcase WSDL does not contain any <xs:import> elements directly under the <wsdl:types> element. The DOM implementation has a hardcoded schema import of the schema for W3C XML Schema to load the basic types, hence the assert in SimpleURIResolverTest for 1 imported schema. However, the OM implementation does not import this schema in this way so the number of imported schemas is actually zero. regards, John Kaputin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
