I agree that long term we want to find a better solution for diffing the WSDLs -- this makes two places in Beehive that are in need of an XML diff.
But, we've only rarely taken new loads of Axis, and we are in need of the test coverage right now. If the tests prove to be problematic, we can certainly disable them or run them less frequently as BVTs. But, I'm going to go ahead and add these and we can adjust as needed. Sound good? Eddie On 7/21/05, Daryoush Mehrtash <[EMAIL PROTECTED]> wrote: > I was not concern about WSDL changing as much as the ramification of > comparing two XML documents by diffing the files. > > For instance, axis puts this comment on the WSDL files: > > <!--WSDL created by Apache Axis version: 1.2 > Built on May 26, 2005 (06:14:06 PDT)--> > > So this means every time we update the new version of Axis we have to > update all the DRT test files. Even though all that is changed is a > comment line. > > > Daryoush > > > -----Original Message----- > > From: Chad Schoettger [mailto:[EMAIL PROTECTED] > > Sent: Thursday, July 21, 2005 3:50 PM > > To: Beehive Developers > > Subject: Re: [jira] Created: (BEEHIVE-861) Added more service control > DRTs > > / also some DRT cleanup and bug fixes > > > > I agree with your points. > > > > My main concern was to find a way to keep the WSDLs in the DRT area > > exactly > > the same as those being generated from the webservice so we know what > > we're > > testing. > > > > If the WSDLs generated by WSM change a lot WSDL diffing would become > an > > issue. At this point I don't really have a feel for how often then > will > > change (daily, weekly, monthly, etc)? I'm sure you have a better idea > of > > the > > frequency than I. > > > > The WSDL diffing is sometimes also useful for developers working on > WSM, > > in > > that it can alert a developer to possibly inadvertant changes to the > WSDLs > > being generated. > > > > My thought was that if the DRTs failed due to a difference in what the > > webservice is generating the first step would always be to replace the > DRT > > WSDL with the one generated from the webservice. Then run the tests > again > > and if they pass check in the updated WSDL and call it good. > > > > Perhaps another option is to display warnings if the DRTs do not match > > instead of failing the DRTs due to a mismatch if this really becomes a > > pain > > for everyone. > > > > -Chad > > > > > > > > > > > > > > > > > > On 7/21/05, Daryoush Mehrtash <[EMAIL PROTECTED]> wrote: > > > > > > > The DRT framework has been modified to now verify that the WSDL's > for > > > the > > > > DRTs are what we excpect by starting tomcat and getting the WSDLs > for > > > the > > > > services we are testing against and comparing them to the ones in > the > > > DRT > > > > area. If this check fails, the DRTs will fail. I found that this > was > > > > quite helpful in diagnosing DRT issues when they failed. > > > > > > It looks as if you are doing a straight file comparison for the > WSDLs > > > (after fixing the CRLF). I am wondering if this is a viable long > term > > > solution. > > > > > > I understand wanting to compare WSDLs when debugging a given DRT > > > problem. But I am not sure about straight file comparison as means > to > > > determine a problem with the server, as minimum we can get false > alarms. > > > > > > > > > IF there is a real difference in the WSDL I would expect it to cause > > > failure when compiling the DRT test case. If for some reason there > is > > > a "real" change in the service's WSDL form the excepted WSDL, I > would > > > expect the interfaces of the control that is generated to be > different > > > than the expect one. Since the test cases are written based on the > > > expected interfaces of the control, this would cause compile > problems. > > > So if there is "real" difference in the WSDL we would detect it and > fail > > > in the DRT without needing to compare files. On the other hand > > > "non-real" changes are ignored. > > > > > > I am afraid this may give false failure alarms and too many false > alarms > > > are almost as bad as no alarm. > > > > > > Daryoush > > > > > > > > > > -----Original Message----- > > > > From: Chad Schoettger (JIRA) > [mailto:[EMAIL PROTECTED] > > > > Sent: Thursday, July 21, 2005 9:51 AM > > > > To: beehive-dev@incubator.apache.org > > > > Subject: [jira] Created: (BEEHIVE-861) Added more service control > DRTs > > > / > > > > also some DRT cleanup and bug fixes > > > > > > > > Added more service control DRTs / also some DRT cleanup and bug > fixes > > > > > --------------------------------------------------------------------- > > > > > > > > Key: BEEHIVE-861 > > > > URL: http://issues.apache.org/jira/browse/BEEHIVE-861 > > > > Project: Beehive > > > > Type: Test > > > > Components: System Controls > > > > Versions: TBD > > > > Reporter: Chad Schoettger > > > > > > > > > > > > I've finished a first pass for system control DRTs. In this patch > > > > includes new DRTs for RPC literal and encoded style services and > well > > > as a > > > > number of fixes for DOC style services/tests. I have also added a > DRT > > > > suite for testing headers. > > > > > > > > The DRT framework has been modified to now verify that the WSDL's > for > > > the > > > > DRTs are what we excpect by starting tomcat and getting the WSDLs > for > > > the > > > > services we are testing against and comparing them to the ones in > the > > > DRT > > > > area. If this check fails, the DRTs will fail. I found that this > was > > > > quite helpful in diagnosing DRT issues when they failed. > > > > > > > > This patch also includes fixes for the following JIRA issues: > > > > > > > > BEEHIVE-817 > > > > BEEHIVE-837 > > > > BEEHIVE-852 > > > > BEEHIVE-853 > > > > BEEHIVE-854 > > > > BEEHIVE-855 > > > > BEEHIVE-856 > > > > BEEHIVE-857 > > > > BEEHIVE-858 > > > > BEEHIVE-859 > > > > > > > > > > > > > > > > -- > > > > This message is automatically generated by JIRA. > > > > - > > > > If you think it was sent incorrectly contact one of the > > > administrators: > > > > http://issues.apache.org/jira/secure/Administrators.jspa > > > > - > > > > For more information on JIRA, see: > > > > http://www.atlassian.com/software/jira > > > > > > > > > > > > > > > >
