Hi, I've taken a look at the code changes in WODEN-44 ... I'm +1 for merging into trunk. Looks like the new failures are actually failures that were being masked ... are there JIRAs for them now?
Thanks, Jeremy On 10/20/06, Oshani Seneviratne <[EMAIL PROTECTED]> wrote:
Hi John, I'm really sorry I couldn't reply to your previous post any sooner! I was checking woden-44 before replying to you, but guess I ran out of time. I suppose the commented out methods in the OMWSDLReader can be removed for good. Also, just to clarify, I would like to know why you have not moved the parseProperty method in to the BaseWSDLReader. As far as I can see, that method too has a similar behaviour across the two implementations. But come to think of it, I vaguely remember reading somewhere that wsdl2.0 not going to include features and properties (I may be wrong). Is that why you have left it out? Also, thanks for the update on SchemaId1G. It's a bug that OMWSDLReader only looked at the first schema. I didn't notice it when I reported the test failure. Thanks and Regards, Oshani On 10/20/06, John Kaputin < [EMAIL PROTECTED]> wrote: > > 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] > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
