beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daryoush Mehrtash" <dmehr...@bea.com>
Subject RE: [jira] Created: (BEEHIVE-861) Added more service control DRTs / also some DRT cleanup and bug fixes
Date Thu, 21 Jul 2005 23:48:04 GMT
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:chad.schoettger@gmail.com]
> 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 <dmehrtas@bea.com> 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:beehive-dev@incubator.apache.org]
> > > 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
> > >
> >
> >
> >



Mime
View raw message