You are viewing a plain text version of this content. The canonical link for it is here.
Posted to woden-dev@ws.apache.org by John Kaputin <KA...@uk.ibm.com> on 2006/10/19 23:44:55 UTC
Please review WODEN-44 branch before merge back to Trunk
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: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Please review WODEN-44 branch before merge back to Trunk
Posted by Jeremy Hughes <hu...@apache.org>.
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 <os...@gmail.com> 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 < KAPUTIN@uk.ibm.com> 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:
> woden-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: woden-dev-help@ws.apache.org
> >
> >
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Please review WODEN-44 branch before merge back to Trunk
Posted by John Kaputin <KA...@uk.ibm.com>.
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"
<oshanis@gmail.co To
m> woden-dev@ws.apache.org
cc
20/10/2006 02:55
Subject
Re: Please review WODEN-44 branch
Please respond to before merge back to Trunk
woden-dev@ws.apac
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 < KAPUTIN@uk.ibm.com> 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: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Please review WODEN-44 branch before merge back to Trunk
Posted by Oshani Seneviratne <os...@gmail.com>.
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 < KAPUTIN@uk.ibm.com> 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: woden-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: woden-dev-help@ws.apache.org
>
>