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 Oshani Seneviratne <os...@gmail.com> on 2006/07/07 09:27:06 UTC
Tests for the StAX/OM parser
Hi devs,
I have added some tests which are similar to the tests that are there
in the DOM implementation.
These include
org.apache.woden.tests.AllWodenTestsOM
org.apache.woden.OMWSDLFactoryTest
org.apache.woden.OMWSDLReaderTest
org.apache.woden.tests.OMW3CTestSuiteTest
org.apache.woden.wsdl20.xml.OMServiceElementTest
org.apache.woden.wsdl20.xml.OMEndpointElementTest
"WeathSvc-1G W3C test" - see [1], would fail if you do not have the
latest XMLSchema jars. So, I have commented it out.
(FYI:There was a fault in the way XMLSchema handled schema elements,
that have references to other schema elements. So, pretty strangely it
showed up for the OM parser, whereas it was okay with the DOM version.
But it has been fixed now, so all the tests should be working fine
with the latest jars)
I have attached the patch for all these tests at [2].
Also, I made some modifications to the OMWSDLReader. The changes include:
1. Addition of the methods readWSDL(uri, errorHandler), parseImport,
parseInclude, and getWSDLFromLocation
&
2.Changes to the way schema is handled with OM in the parseSchemaInline method.
This patch is attached at [3]. You would need to have this in order to
run all the tests successfully.
And to share some statistics with you... I was able to run the
OMW3CTestSuiteTest in under 90s most of the time, whereas its
counterpart for the DOM implementation - the W3CTestSuiteTest, took
between 900s - 2000s! Pretty impressive ha? :)
So, I would really appreciate if someone can review and apply these 2 patches.
Thanks and regards,
Oshani.
[1]org.apache.woden.tests.AllWodenTestsOM#testWeathSvc1G()
[2]http://issues.apache.org/jira/secure/attachment/12336436/TestsForOMParser.patch
[3]http://issues.apache.org/jira/secure/attachment/12336440/OMWSDLReader-additions.patch
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Tests for the StAX/OM parser
Posted by Jeremy Hughes <hu...@apache.org>.
+1 to that. Lets change the readWSDL methods so they take a URL instead of a
String. StringUtils in Woden has its history in StringUtils from WSDL4J
which had a nasty platform-dependent problem recently!
Was there anywhere else you feel changes need to be made? On the whole I
think this type-safe approach is better than the so-called 'user-friendly'
approach of just allowing a String and we do the rest.
Cheers,
Jeremy
On 7/11/06, Lawrence Mandel <lm...@ca.ibm.com> wrote:
>
>
> I think it's a bad idea for Woden to start trying to correct input strings
> to form valid URLs. We should rather just require that a valid URL is passed
> in. (This means Woden will likely choke on c:\somefile.wsdl as it requires
> the file:///.)
>
> The justification for my suggestion comes from the Xerces team, who have a
> lot of experience with parsers. I spoke with the Xerces team about this a
> while back and they told their story of bug report after bug report being
> filed from users that expected their entry to be resolved correctly. Let's
> learn from the Xerces experience and leave this logic up to the Woden
> consumer.
>
> Lawrence
>
>
>
> *"Jeremy Hughes" <hu...@apache.org>*
> Sent by: jpjhughes@gmail.com
>
> 07/11/2006 07:16 AM Please respond to
> woden-dev@ws.apache.org
>
> To
> woden-dev@ws.apache.org cc
>
> Subject
> Re: Tests for the StAX/OM parser
>
>
>
>
>
>
> Thanks very much for your recent patch. I have applied it in revision
> 420800 with some small changes:
>
> I had a problem at OMWSDLReader line 76. This assumes if there is a :
> in the input string then it is a URL. However, on windows c:\foo.wsdl
> is a file and not a URL. So this logic:
>
> int index = wsdlURI.indexOf(':');
> String wsdlURL = (index != -1)
> ? wsdlURI
> : ("file://"+wsdlURI);
>
> yeilds c:\foo.wsdl instead of file://c:\foo.wsdl. The problem showed
> up because W3CFileRepository.getFilePath() was returning a file path
> instead of a URL - so I fixed that. However the problem remains in
> readWSDL() should someone pass in the local string path of a WSDL on a
> Windows machine - would be good to fix.
>
> Looking a bit further: line 91 of OMWSDLReader.readWSDL() declares the
> url variable and is set at line 93 but never read. I think you copied
> this method from DOMWSDLReader() and added the above code for some
> reason - perhaps you had a problem with local files? There was a
> recent problem with StringUtils.getURL() in WSDL4J which I don't think
> is fixed in Woden.
>
> Eclipse tells me there are some other places where local variables are
> never read. There's also one in DOMWSDLReader so I'll open a JIRA for
> fixing those.
>
> Just something that might slightly speed things up is the number of
> times the EndpointElementTest.wsdl file is read by multiple calls to
> the OMEndpointElementTest.setUp() method. I don't think every test
> case needs to re-read and test the WSDL - only the
>
> testSetAndGetBindingNameFromOM
> testSetAndGetNameFromOM
>
> methods change the parsed WSDL in object form.
>
> And a small thing - we have been specifying implicit imports rather
> than use * in import statements. This makes it easier to see which
> package a class comes from if you're using a dumb editor like vi or
> notepad.
>
> Thanks again.
> Jeremy
>
> On 7/10/06, Oshani Seneviratne <os...@gmail.com> wrote:
> > Hi Jeremy,
> >
> > I'm terribly sorry for the trouble that you had to undergo in applying
> > my 2 previous patches! And also, thanks a lot for pointing out the
> > correct way of submitting patches.
> >
> > I have attached a new patch at [1], which you could apply at the Woden
> > root. Please disregard those 2 earlier patches, i.e.
> > 'TestsForOMParser.patch' and 'OMWSDLReader-additions.patch' that I
> > have attached with WODEN-37.
> >
> > I documented all the changes that are there with the new patch at [2].
> > Basically I have modified the classpath, project.properties and
> > changed the code & the ant scripts so that you would be able to run
> > tests for both DOM and StAX/OM parsers.
> >
> > So, after applying the patch you can run:
> > 'ant runTestsDOM' to see tests for DOM,
> > 'ant runTestsOM' to see tests for StAX/OM, and
> > 'ant runTests' to see tests for both.
> >
> > [1]
> http://issues.apache.org/jira/secure/attachment/12336594/TestsAndAdditions.patch
> > [2]
> > http://issues.apache.org/jira/browse/WODEN-37#action_12420090
> >
> > Thanks and Regards,
> > Oshani.
> >
> >
> >
> > On 7/8/06, Jeremy Hughes <hu...@apache.org> wrote:
> > > Hi Oshani, thanks for your patches. I started to apply them, but I
> > > came up against a few problems. Firstly the TestsForOMParser.patch was
> > > created when you were in the test/org/apache/woden directory. This I
> > > could workaround - it is normal (although I have to admit we haven't
> > > documented this on the Woden site) to create the patch while in the
> > > project root dir. The OMWSDLReader-additions.patch had a similar
> > > problem. Anyway, I worked around this.
> > >
> > > The main issue is that I can't run the tests without making changes to
> > > the classpath and I ran out of time here figuring it out. It would be
> > > great if I could take your patch and just like the in the
> > > contributors' FAQ [1], run the 'patch' command from the command line
> > > in the root dir of Woden. Then if I do 'ant runTests' all the new
> > > tests should get run as well as the old ones - and of course for all
> > > the tests to pass :-)
> > >
> > > [1] http://www.apache.org/dev/contributors.html#patches
> > >
> > > Many thanks,
> > > Jeremy
> >
> > ---------------------------------------------------------------------
> > 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: Tests for the StAX/OM parser
Posted by Jeremy Hughes <hu...@apache.org>.
Hi Oshani ...
On 7/12/06, Oshani Seneviratne <os...@gmail.com> wrote:
> if the readWSDL method is
> changed to accept URLs, this file path problem can be completely
> eliminated from the OM parser. Also from Axis2 point of view, if we
> can directly accept InputStreams it would be even more great :).
+1. If that helps Axis2 lets do it.
> From
> a previous discussion I've learnt it is necessary for the WSDL that's
> read into Woden to have a base URI in order to interpret the relative
> URLs. But at the moment, Axis2 seems to be setting the base URI to the
> parent service archive. So, IMO it's just a matter of the user setting
> the base URI in order to resolve relative URIs.
We can use the jar URL [1] to refer to files within an aar file. This
allows us to set the base URI to be the top level WSDL file in the aar
(described by a jar URL). Then the usual rules for creating relative
URLs for imports apply. So the base URI should be the jar URL of the
top level WSDL and not the aar filename.
[1] http://java.sun.com/j2se/1.4.2/docs/api/java/net/JarURLConnection.html
>
> > Looking a bit further: line 91 of OMWSDLReader.readWSDL() declares the
> > url variable and is set at line 93 but never read. I think you copied
> > this method from DOMWSDLReader() and added the above code for some
> > reason - perhaps you had a problem with local files? There was a
> > recent problem with StringUtils.getURL() in WSDL4J which I don't think
> > is fixed in Woden.
> >
>
> I will remove the code for checking the ":" in the String URI, and
> modify the readWSDL signature to take in a URL. I should also probably
> check validity of this URL and not try to correct the URL to form a
> valid URL as Lawrence has pointed out.
>
> > Eclipse tells me there are some other places where local variables are
> > never read. There's also one in DOMWSDLReader so I'll open a JIRA for
> > fixing those.
> >
>
> Yes, there are unused variables. I'll fix those.
Ah sorry, I just went ahead and corrected DOMWSDLReader. There are
other similar warnings throughout the Woden.
>
> > Just something that might slightly speed things up is the number of
> > times the EndpointElementTest.wsdl file is read by multiple calls to
> > the OMEndpointElementTest.setUp() method. I don't think every test
> > case needs to re-read and test the WSDL - only the
> >
> > testSetAndGetBindingNameFromOM
> > testSetAndGetNameFromOM
> >
> > methods change the parsed WSDL in object form.
>
> Yes again! I think this should be changed in the EndpointElementTest as well.
Sure - please open a JIRA - and add a patch (until you get your Woden Karma :-)
>
> >
> > And a small thing - we have been specifying implicit imports rather
> > than use * in import statements. This makes it easier to see which
> > package a class comes from if you're using a dumb editor like vi or
> > notepad.
> >
>
> Hmm.., I took some effort to make the code as clean as possible. But I
> see that 2 import *s, has slipped from my radar in the
> AllWodenTestsOM. So, my apologies.. Anyway, as a rule I have been
> following the coding conventions John proposed some time back [1]
Great thanks! We're not so good ourselves on this and the whole code
probably needs reformatting with something like jalopy [2]. (there's a
maven plugin for jalopy which is why I mention it).
[2] http://jalopy.sourceforge.net/
> .IMHO, it would be a good idea to document these in the project site.
> I'm willing to help, if required.
Great! We probably need to document how to update the project site too :-D
>
> Please share if you have any other comments/concerns regarding the OM parser.
There seems to be a lot of common code between DOMWSDLReader and
OMWSDLReader and probably other classes too. It would be great to
refactor the common pieces out either using inheritance or delegation
patterns.
Also, from the test point of view we have AllWodenTestsDOM and
AllWodenTestsOM but in fact the DOM tests include tests not specific
to DOM. From the name of the classes it would easy to assume that
comparing the performance of the two test cases is a valid thing to
do. Perhaps we could split them out into DOM, OM and no-parse tests.
>
> Thanks and Regards,
> Oshani.
>
Thanks again,
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Tests for the StAX/OM parser
Posted by Oshani Seneviratne <os...@gmail.com>.
Hi Jeremy,
First of all, thanks a lot for reviewing and applying my patch. Also,
I really appreciate the feedback on the code.
Please see my comments in line for the problems you had discovered.
On 7/11/06, Jeremy Hughes <hu...@apache.org> wrote:
> Thanks very much for your recent patch. I have applied it in revision
> 420800 with some small changes:
>
> I had a problem at OMWSDLReader line 76. This assumes if there is a :
> in the input string then it is a URL. However, on windows c:\foo.wsdl
> is a file and not a URL. So this logic:
>
> int index = wsdlURI.indexOf(':');
> String wsdlURL = (index != -1)
> ? wsdlURI
> : ("file://"+wsdlURI);
>
> yeilds c:\foo.wsdl instead of file://c:\foo.wsdl. The problem showed
> up because W3CFileRepository.getFilePath() was returning a file path
> instead of a URL - so I fixed that. However the problem remains in
> readWSDL() should someone pass in the local string path of a WSDL on a
> Windows machine - would be good to fix.
>
I admit that this is an ugly hack, and I didn't consider windows file
paths when thinking of the above logic! So, this will be definitely
fixed.
Actually, the fact that Woden takes a String argument to the readWSDL
method was my one of my initial points of confusion. I think you may
have noticed that I'm doing this in o.a.w.internal.util.om (line 54)
in order to read a WSDL into OM:
URI uri = new URI(strUri);
URL url = uri.toURL();
InputStream in = url.openStream();
builder = new StAXOMBuilder(in);
I was under the impression that it was a requirement from Woden to
accept only String URIs as arguments. So, I tried the above code to
work around the problem I had. As a result, as you have discovered, a
problem arises whenever non-absolute URIs are given as arguments.
But, as was suggested in this thread, if the readWSDL method is
changed to accept URLs, this file path problem can be completely
eliminated from the OM parser. Also from Axis2 point of view, if we
can directly accept InputStreams it would be even more great :). From
a previous discussion I've learnt it is necessary for the WSDL that's
read into Woden to have a base URI in order to interpret the relative
URLs. But at the moment, Axis2 seems to be setting the base URI to the
parent service archive. So, IMO it's just a matter of the user setting
the base URI in order to resolve relative URIs.
> Looking a bit further: line 91 of OMWSDLReader.readWSDL() declares the
> url variable and is set at line 93 but never read. I think you copied
> this method from DOMWSDLReader() and added the above code for some
> reason - perhaps you had a problem with local files? There was a
> recent problem with StringUtils.getURL() in WSDL4J which I don't think
> is fixed in Woden.
>
I will remove the code for checking the ":" in the String URI, and
modify the readWSDL signature to take in a URL. I should also probably
check validity of this URL and not try to correct the URL to form a
valid URL as Lawrence has pointed out.
> Eclipse tells me there are some other places where local variables are
> never read. There's also one in DOMWSDLReader so I'll open a JIRA for
> fixing those.
>
Yes, there are unused variables. I'll fix those.
> Just something that might slightly speed things up is the number of
> times the EndpointElementTest.wsdl file is read by multiple calls to
> the OMEndpointElementTest.setUp() method. I don't think every test
> case needs to re-read and test the WSDL - only the
>
> testSetAndGetBindingNameFromOM
> testSetAndGetNameFromOM
>
> methods change the parsed WSDL in object form.
Yes again! I think this should be changed in the EndpointElementTest as well.
>
> And a small thing - we have been specifying implicit imports rather
> than use * in import statements. This makes it easier to see which
> package a class comes from if you're using a dumb editor like vi or
> notepad.
>
Hmm.., I took some effort to make the code as clean as possible. But I
see that 2 import *s, has slipped from my radar in the
AllWodenTestsOM. So, my apologies.. Anyway, as a rule I have been
following the coding conventions John proposed some time back [1]
.IMHO, it would be a good idea to document these in the project site.
I'm willing to help, if required.
Please share if you have any other comments/concerns regarding the OM parser.
Thanks and Regards,
Oshani.
[1] http://mail-archives.apache.org/mod_mbox/ws-woden-dev/200606.mbox/%3cOFAF63CCA0.3B1BCA96-ON8025718C.004EB990-8025718C.0051F13A@uk.ibm.com%3e
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Tests for the StAX/OM parser
Posted by Lawrence Mandel <lm...@ca.ibm.com>.
I think it's a bad idea for Woden to start trying to correct input strings
to form valid URLs. We should rather just require that a valid URL is
passed in. (This means Woden will likely choke on c:\somefile.wsdl as it
requires the file:///.)
The justification for my suggestion comes from the Xerces team, who have a
lot of experience with parsers. I spoke with the Xerces team about this a
while back and they told their story of bug report after bug report being
filed from users that expected their entry to be resolved correctly. Let's
learn from the Xerces experience and leave this logic up to the Woden
consumer.
Lawrence
"Jeremy Hughes" <hu...@apache.org>
Sent by: jpjhughes@gmail.com
07/11/2006 07:16 AM
Please respond to
woden-dev@ws.apache.org
To
woden-dev@ws.apache.org
cc
Subject
Re: Tests for the StAX/OM parser
Thanks very much for your recent patch. I have applied it in revision
420800 with some small changes:
I had a problem at OMWSDLReader line 76. This assumes if there is a :
in the input string then it is a URL. However, on windows c:\foo.wsdl
is a file and not a URL. So this logic:
int index = wsdlURI.indexOf(':');
String wsdlURL = (index != -1)
? wsdlURI
: ("file://"+wsdlURI);
yeilds c:\foo.wsdl instead of file://c:\foo.wsdl. The problem showed
up because W3CFileRepository.getFilePath() was returning a file path
instead of a URL - so I fixed that. However the problem remains in
readWSDL() should someone pass in the local string path of a WSDL on a
Windows machine - would be good to fix.
Looking a bit further: line 91 of OMWSDLReader.readWSDL() declares the
url variable and is set at line 93 but never read. I think you copied
this method from DOMWSDLReader() and added the above code for some
reason - perhaps you had a problem with local files? There was a
recent problem with StringUtils.getURL() in WSDL4J which I don't think
is fixed in Woden.
Eclipse tells me there are some other places where local variables are
never read. There's also one in DOMWSDLReader so I'll open a JIRA for
fixing those.
Just something that might slightly speed things up is the number of
times the EndpointElementTest.wsdl file is read by multiple calls to
the OMEndpointElementTest.setUp() method. I don't think every test
case needs to re-read and test the WSDL - only the
testSetAndGetBindingNameFromOM
testSetAndGetNameFromOM
methods change the parsed WSDL in object form.
And a small thing - we have been specifying implicit imports rather
than use * in import statements. This makes it easier to see which
package a class comes from if you're using a dumb editor like vi or
notepad.
Thanks again.
Jeremy
On 7/10/06, Oshani Seneviratne <os...@gmail.com> wrote:
> Hi Jeremy,
>
> I'm terribly sorry for the trouble that you had to undergo in applying
> my 2 previous patches! And also, thanks a lot for pointing out the
> correct way of submitting patches.
>
> I have attached a new patch at [1], which you could apply at the Woden
> root. Please disregard those 2 earlier patches, i.e.
> 'TestsForOMParser.patch' and 'OMWSDLReader-additions.patch' that I
> have attached with WODEN-37.
>
> I documented all the changes that are there with the new patch at [2].
> Basically I have modified the classpath, project.properties and
> changed the code & the ant scripts so that you would be able to run
> tests for both DOM and StAX/OM parsers.
>
> So, after applying the patch you can run:
> 'ant runTestsDOM' to see tests for DOM,
> 'ant runTestsOM' to see tests for StAX/OM, and
> 'ant runTests' to see tests for both.
>
> [1]
http://issues.apache.org/jira/secure/attachment/12336594/TestsAndAdditions.patch
> [2]
> http://issues.apache.org/jira/browse/WODEN-37#action_12420090
>
> Thanks and Regards,
> Oshani.
>
>
>
> On 7/8/06, Jeremy Hughes <hu...@apache.org> wrote:
> > Hi Oshani, thanks for your patches. I started to apply them, but I
> > came up against a few problems. Firstly the TestsForOMParser.patch was
> > created when you were in the test/org/apache/woden directory. This I
> > could workaround - it is normal (although I have to admit we haven't
> > documented this on the Woden site) to create the patch while in the
> > project root dir. The OMWSDLReader-additions.patch had a similar
> > problem. Anyway, I worked around this.
> >
> > The main issue is that I can't run the tests without making changes to
> > the classpath and I ran out of time here figuring it out. It would be
> > great if I could take your patch and just like the in the
> > contributors' FAQ [1], run the 'patch' command from the command line
> > in the root dir of Woden. Then if I do 'ant runTests' all the new
> > tests should get run as well as the old ones - and of course for all
> > the tests to pass :-)
> >
> > [1] http://www.apache.org/dev/contributors.html#patches
> >
> > Many thanks,
> > Jeremy
>
> ---------------------------------------------------------------------
> 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: Tests for the StAX/OM parser
Posted by Jeremy Hughes <hu...@apache.org>.
Thanks very much for your recent patch. I have applied it in revision
420800 with some small changes:
I had a problem at OMWSDLReader line 76. This assumes if there is a :
in the input string then it is a URL. However, on windows c:\foo.wsdl
is a file and not a URL. So this logic:
int index = wsdlURI.indexOf(':');
String wsdlURL = (index != -1)
? wsdlURI
: ("file://"+wsdlURI);
yeilds c:\foo.wsdl instead of file://c:\foo.wsdl. The problem showed
up because W3CFileRepository.getFilePath() was returning a file path
instead of a URL - so I fixed that. However the problem remains in
readWSDL() should someone pass in the local string path of a WSDL on a
Windows machine - would be good to fix.
Looking a bit further: line 91 of OMWSDLReader.readWSDL() declares the
url variable and is set at line 93 but never read. I think you copied
this method from DOMWSDLReader() and added the above code for some
reason - perhaps you had a problem with local files? There was a
recent problem with StringUtils.getURL() in WSDL4J which I don't think
is fixed in Woden.
Eclipse tells me there are some other places where local variables are
never read. There's also one in DOMWSDLReader so I'll open a JIRA for
fixing those.
Just something that might slightly speed things up is the number of
times the EndpointElementTest.wsdl file is read by multiple calls to
the OMEndpointElementTest.setUp() method. I don't think every test
case needs to re-read and test the WSDL - only the
testSetAndGetBindingNameFromOM
testSetAndGetNameFromOM
methods change the parsed WSDL in object form.
And a small thing - we have been specifying implicit imports rather
than use * in import statements. This makes it easier to see which
package a class comes from if you're using a dumb editor like vi or
notepad.
Thanks again.
Jeremy
On 7/10/06, Oshani Seneviratne <os...@gmail.com> wrote:
> Hi Jeremy,
>
> I'm terribly sorry for the trouble that you had to undergo in applying
> my 2 previous patches! And also, thanks a lot for pointing out the
> correct way of submitting patches.
>
> I have attached a new patch at [1], which you could apply at the Woden
> root. Please disregard those 2 earlier patches, i.e.
> 'TestsForOMParser.patch' and 'OMWSDLReader-additions.patch' that I
> have attached with WODEN-37.
>
> I documented all the changes that are there with the new patch at [2].
> Basically I have modified the classpath, project.properties and
> changed the code & the ant scripts so that you would be able to run
> tests for both DOM and StAX/OM parsers.
>
> So, after applying the patch you can run:
> 'ant runTestsDOM' to see tests for DOM,
> 'ant runTestsOM' to see tests for StAX/OM, and
> 'ant runTests' to see tests for both.
>
> [1] http://issues.apache.org/jira/secure/attachment/12336594/TestsAndAdditions.patch
> [2]
> http://issues.apache.org/jira/browse/WODEN-37#action_12420090
>
> Thanks and Regards,
> Oshani.
>
>
>
> On 7/8/06, Jeremy Hughes <hu...@apache.org> wrote:
> > Hi Oshani, thanks for your patches. I started to apply them, but I
> > came up against a few problems. Firstly the TestsForOMParser.patch was
> > created when you were in the test/org/apache/woden directory. This I
> > could workaround - it is normal (although I have to admit we haven't
> > documented this on the Woden site) to create the patch while in the
> > project root dir. The OMWSDLReader-additions.patch had a similar
> > problem. Anyway, I worked around this.
> >
> > The main issue is that I can't run the tests without making changes to
> > the classpath and I ran out of time here figuring it out. It would be
> > great if I could take your patch and just like the in the
> > contributors' FAQ [1], run the 'patch' command from the command line
> > in the root dir of Woden. Then if I do 'ant runTests' all the new
> > tests should get run as well as the old ones - and of course for all
> > the tests to pass :-)
> >
> > [1] http://www.apache.org/dev/contributors.html#patches
> >
> > Many thanks,
> > Jeremy
>
> ---------------------------------------------------------------------
> 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: Tests for the StAX/OM parser
Posted by Oshani Seneviratne <os...@gmail.com>.
Hi Jeremy,
I'm terribly sorry for the trouble that you had to undergo in applying
my 2 previous patches! And also, thanks a lot for pointing out the
correct way of submitting patches.
I have attached a new patch at [1], which you could apply at the Woden
root. Please disregard those 2 earlier patches, i.e.
'TestsForOMParser.patch' and 'OMWSDLReader-additions.patch' that I
have attached with WODEN-37.
I documented all the changes that are there with the new patch at [2].
Basically I have modified the classpath, project.properties and
changed the code & the ant scripts so that you would be able to run
tests for both DOM and StAX/OM parsers.
So, after applying the patch you can run:
'ant runTestsDOM' to see tests for DOM,
'ant runTestsOM' to see tests for StAX/OM, and
'ant runTests' to see tests for both.
[1] http://issues.apache.org/jira/secure/attachment/12336594/TestsAndAdditions.patch
[2]
http://issues.apache.org/jira/browse/WODEN-37#action_12420090
Thanks and Regards,
Oshani.
On 7/8/06, Jeremy Hughes <hu...@apache.org> wrote:
> Hi Oshani, thanks for your patches. I started to apply them, but I
> came up against a few problems. Firstly the TestsForOMParser.patch was
> created when you were in the test/org/apache/woden directory. This I
> could workaround - it is normal (although I have to admit we haven't
> documented this on the Woden site) to create the patch while in the
> project root dir. The OMWSDLReader-additions.patch had a similar
> problem. Anyway, I worked around this.
>
> The main issue is that I can't run the tests without making changes to
> the classpath and I ran out of time here figuring it out. It would be
> great if I could take your patch and just like the in the
> contributors' FAQ [1], run the 'patch' command from the command line
> in the root dir of Woden. Then if I do 'ant runTests' all the new
> tests should get run as well as the old ones - and of course for all
> the tests to pass :-)
>
> [1] http://www.apache.org/dev/contributors.html#patches
>
> Many thanks,
> Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Tests for the StAX/OM parser
Posted by Jeremy Hughes <hu...@apache.org>.
Hi Oshani, thanks for your patches. I started to apply them, but I
came up against a few problems. Firstly the TestsForOMParser.patch was
created when you were in the test/org/apache/woden directory. This I
could workaround - it is normal (although I have to admit we haven't
documented this on the Woden site) to create the patch while in the
project root dir. The OMWSDLReader-additions.patch had a similar
problem. Anyway, I worked around this.
The main issue is that I can't run the tests without making changes to
the classpath and I ran out of time here figuring it out. It would be
great if I could take your patch and just like the in the
contributors' FAQ [1], run the 'patch' command from the command line
in the root dir of Woden. Then if I do 'ant runTests' all the new
tests should get run as well as the old ones - and of course for all
the tests to pass :-)
[1] http://www.apache.org/dev/contributors.html#patches
Many thanks,
Jeremy
On 7/7/06, Oshani Seneviratne <os...@gmail.com> wrote:
> Hi devs,
>
> I have added some tests which are similar to the tests that are there
> in the DOM implementation.
>
> These include
> org.apache.woden.tests.AllWodenTestsOM
> org.apache.woden.OMWSDLFactoryTest
> org.apache.woden.OMWSDLReaderTest
> org.apache.woden.tests.OMW3CTestSuiteTest
> org.apache.woden.wsdl20.xml.OMServiceElementTest
> org.apache.woden.wsdl20.xml.OMEndpointElementTest
>
> "WeathSvc-1G W3C test" - see [1], would fail if you do not have the
> latest XMLSchema jars. So, I have commented it out.
> (FYI:There was a fault in the way XMLSchema handled schema elements,
> that have references to other schema elements. So, pretty strangely it
> showed up for the OM parser, whereas it was okay with the DOM version.
> But it has been fixed now, so all the tests should be working fine
> with the latest jars)
> I have attached the patch for all these tests at [2].
>
> Also, I made some modifications to the OMWSDLReader. The changes include:
> 1. Addition of the methods readWSDL(uri, errorHandler), parseImport,
> parseInclude, and getWSDLFromLocation
> &
> 2.Changes to the way schema is handled with OM in the parseSchemaInline method.
>
> This patch is attached at [3]. You would need to have this in order to
> run all the tests successfully.
>
> And to share some statistics with you... I was able to run the
> OMW3CTestSuiteTest in under 90s most of the time, whereas its
> counterpart for the DOM implementation - the W3CTestSuiteTest, took
> between 900s - 2000s! Pretty impressive ha? :)
>
> So, I would really appreciate if someone can review and apply these 2 patches.
>
> Thanks and regards,
> Oshani.
>
> [1]org.apache.woden.tests.AllWodenTestsOM#testWeathSvc1G()
>
> [2]http://issues.apache.org/jira/secure/attachment/12336436/TestsForOMParser.patch
>
> [3]http://issues.apache.org/jira/secure/attachment/12336440/OMWSDLReader-additions.patch
>
> ---------------------------------------------------------------------
> 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: Tests for the StAX/OM parser
Posted by Jeremy Hughes <hu...@apache.org>.
Hi Oshani, I actually committed the changes you need to the WODEN-40
branch I'm working on. I've just been looking at the trunk and there
is a unit test failing there. Despite this I will apply the 'speedup'
changes to trunk anyway.
Cheers,
Jeremy
On 7/7/06, Jeremy Hughes <hu...@apache.org> wrote:
> On 7/7/06, Oshani Seneviratne <os...@gmail.com> wrote:
> > Hmm.. I still get those figures. By the way I'm working on a P4, 2GHz,
> > 512MB Ubuntu box. Network speed could also be a culprit here.
> > Actually, I was wondering why these test cases are not included as
> > 'offline' resources in the test folder or somewhere.
>
> The real solution to this is for Woden to support an entity resolver
> and for that to use an XML catalog. However, I have an admission to
> make ... I have an interim workaround which may improve the download
> speed somewhat. I achieved the 40 sec value using the code out of
> Woden SVN. I have a modification which will use a local CVS checkout
> of the W3C test suite. I did this because I thought *40* secs was too
> much. However it only really saved me a few secs. The change may work
> better for you. Until now I didn't think it worth committing, but
> maybe it will be useful to you so I will.
>
> > That would make
> > it easy for anybody who is trying to test it offline or has a very
> > poor network speed like me:).
>
> When you see the commit message do an svn update and let me know
> whether it improves things for DOM. It should actually improve StAX/OM
> too.
>
> >
> > Anyway, the StAX/OM version should run much faster than the DOM
> > version, and I would like to hear the results you get on this too.
>
> Sure will do.
>
> Cheers,
> Jeremy
>
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Tests for the StAX/OM parser
Posted by Jeremy Hughes <hu...@apache.org>.
On 7/10/06, Oshani Seneviratne <os...@gmail.com> wrote:
> Hi,
>
> I tried out the W3CFileRepository (wfr) with the W3CTestSuiteTest, and
> I could see some improvement, but unfortunately, it's not that much of
> an improvement for me too.
>
> FYI in the latest run I had:
> For DOM, it took 746.381s (without wfr) and 703.988s (with wfr) &
> For OM, it took 49.901s (without wfr) and 43.161s (with wfr).
>
> Thanks and Regards,
> Oshani.
Ah well, I back it out when we have the XML catalog support.
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Tests for the StAX/OM parser
Posted by Oshani Seneviratne <os...@gmail.com>.
Hi,
I tried out the W3CFileRepository (wfr) with the W3CTestSuiteTest, and
I could see some improvement, but unfortunately, it's not that much of
an improvement for me too.
FYI in the latest run I had:
For DOM, it took 746.381s (without wfr) and 703.988s (with wfr) &
For OM, it took 49.901s (without wfr) and 43.161s (with wfr).
Thanks and Regards,
Oshani.
On 7/7/06, Jeremy Hughes <hu...@apache.org> wrote:
> On 7/7/06, Oshani Seneviratne <os...@gmail.com> wrote:
> > Hmm.. I still get those figures. By the way I'm working on a P4, 2GHz,
> > 512MB Ubuntu box. Network speed could also be a culprit here.
> > Actually, I was wondering why these test cases are not included as
> > 'offline' resources in the test folder or somewhere.
>
> The real solution to this is for Woden to support an entity resolver
> and for that to use an XML catalog. However, I have an admission to
> make ... I have an interim workaround which may improve the download
> speed somewhat. I achieved the 40 sec value using the code out of
> Woden SVN. I have a modification which will use a local CVS checkout
> of the W3C test suite. I did this because I thought *40* secs was too
> much. However it only really saved me a few secs. The change may work
> better for you. Until now I didn't think it worth committing, but
> maybe it will be useful to you so I will.
>
> > That would make
> > it easy for anybody who is trying to test it offline or has a very
> > poor network speed like me:).
>
> When you see the commit message do an svn update and let me know
> whether it improves things for DOM. It should actually improve StAX/OM
> too.
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Tests for the StAX/OM parser
Posted by Jeremy Hughes <hu...@apache.org>.
On 7/7/06, Oshani Seneviratne <os...@gmail.com> wrote:
> Hmm.. I still get those figures. By the way I'm working on a P4, 2GHz,
> 512MB Ubuntu box. Network speed could also be a culprit here.
> Actually, I was wondering why these test cases are not included as
> 'offline' resources in the test folder or somewhere.
The real solution to this is for Woden to support an entity resolver
and for that to use an XML catalog. However, I have an admission to
make ... I have an interim workaround which may improve the download
speed somewhat. I achieved the 40 sec value using the code out of
Woden SVN. I have a modification which will use a local CVS checkout
of the W3C test suite. I did this because I thought *40* secs was too
much. However it only really saved me a few secs. The change may work
better for you. Until now I didn't think it worth committing, but
maybe it will be useful to you so I will.
> That would make
> it easy for anybody who is trying to test it offline or has a very
> poor network speed like me:).
When you see the commit message do an svn update and let me know
whether it improves things for DOM. It should actually improve StAX/OM
too.
>
> Anyway, the StAX/OM version should run much faster than the DOM
> version, and I would like to hear the results you get on this too.
Sure will do.
Cheers,
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Tests for the StAX/OM parser
Posted by Oshani Seneviratne <os...@gmail.com>.
Hi Jeremy,
>
> > "WeathSvc-1G W3C test" - see [1], would fail if you do not have the
> > latest XMLSchema jars. So, I have commented it out.
>
> I've updated Woden to 1.0.3, is that good enough?
Unfortunately, no. You would have to get the latest SNAPSHOT jars,
since it was only fixed yesterday.
> >
> > And to share some statistics with you... I was able to run the
> > OMW3CTestSuiteTest in under 90s most of the time, whereas its
> > counterpart for the DOM implementation - the W3CTestSuiteTest, took
> > between 900s - 2000s! Pretty impressive ha? :)
>
> Wow that sounds cool. But it only takes me 40 secs or so to run
> W3CTestSuiteTest today. How many times were you running the test suite
> to get these figures? If only once then perhaps there is another
> factor involved - perhaps network speed?
>
Hmm.. I still get those figures. By the way I'm working on a P4, 2GHz,
512MB Ubuntu box. Network speed could also be a culprit here.
Actually, I was wondering why these test cases are not included as
'offline' resources in the test folder or somewhere. That would make
it easy for anybody who is trying to test it offline or has a very
poor network speed like me:).
Anyway, the StAX/OM version should run much faster than the DOM
version, and I would like to hear the results you get on this too.
> >
> > So, I would really appreciate if someone can review and apply these 2 patches.
>
> I'll take a look today. Thanks for this!!
>
Thanks
--
Oshani Seneviratne
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Tests for the StAX/OM parser
Posted by Jeremy Hughes <hu...@apache.org>.
Hi, comments in-line.
On 7/7/06, Oshani Seneviratne <os...@gmail.com> wrote:
> Hi devs,
>
> I have added some tests which are similar to the tests that are there
> in the DOM implementation.
>
> These include
> org.apache.woden.tests.AllWodenTestsOM
> org.apache.woden.OMWSDLFactoryTest
> org.apache.woden.OMWSDLReaderTest
> org.apache.woden.tests.OMW3CTestSuiteTest
> org.apache.woden.wsdl20.xml.OMServiceElementTest
> org.apache.woden.wsdl20.xml.OMEndpointElementTest
>
> "WeathSvc-1G W3C test" - see [1], would fail if you do not have the
> latest XMLSchema jars. So, I have commented it out.
I've updated Woden to 1.0.3, is that good enough?
> (FYI:There was a fault in the way XMLSchema handled schema elements,
> that have references to other schema elements. So, pretty strangely it
> showed up for the OM parser, whereas it was okay with the DOM version.
> But it has been fixed now, so all the tests should be working fine
> with the latest jars)
> I have attached the patch for all these tests at [2].
>
> Also, I made some modifications to the OMWSDLReader. The changes include:
> 1. Addition of the methods readWSDL(uri, errorHandler), parseImport,
> parseInclude, and getWSDLFromLocation
> &
> 2.Changes to the way schema is handled with OM in the parseSchemaInline method.
>
> This patch is attached at [3]. You would need to have this in order to
> run all the tests successfully.
>
> And to share some statistics with you... I was able to run the
> OMW3CTestSuiteTest in under 90s most of the time, whereas its
> counterpart for the DOM implementation - the W3CTestSuiteTest, took
> between 900s - 2000s! Pretty impressive ha? :)
Wow that sounds cool. But it only takes me 40 secs or so to run
W3CTestSuiteTest today. How many times were you running the test suite
to get these figures? If only once then perhaps there is another
factor involved - perhaps network speed?
>
> So, I would really appreciate if someone can review and apply these 2 patches.
I'll take a look today. Thanks for this!!
>
> Thanks and regards,
> Oshani.
>
> [1]org.apache.woden.tests.AllWodenTestsOM#testWeathSvc1G()
>
> [2]http://issues.apache.org/jira/secure/attachment/12336436/TestsForOMParser.patch
>
> [3]http://issues.apache.org/jira/secure/attachment/12336440/OMWSDLReader-additions.patch
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org