Hi Oshani,
No problem about any delayed repsonse - I saw your earlier post about San
Diego and travel so I assumed you were pretty busy. I'll delete the
commented out methods in OMWSDLReader as you suggest before merging
WODEN-44 back into trunk. I didn't bother with parseProperty because as you
point out, it is likely that Property and Feature will be removed from the
WSDL 2.0 spec - at that time, we can remove the related code completely
from Woden.
thanks,
John Kaputin
"Oshani
Seneviratne"
<[EMAIL PROTECTED] To
m> [email protected]
cc
20/10/2006 02:55
Subject
Re: Please review WODEN-44 branch
Please respond to before merge back to Trunk
[EMAIL PROTECTED]
he.org
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]
