beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chad Schoettger <chad.schoett...@gmail.com>
Subject Re: [jira] Created: (BEEHIVE-861) Added more service control DRTs / also some DRT cleanup and bug fixes
Date Thu, 21 Jul 2005 22:50:13 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message