[PECL-BUG] Bug #11004 [Opn]: WSDL Generated Does Not Validate

[m***@public.gmane.org]

Edit report at http://pecl.php.net/bugs/bug.php?id=11004&edit=1

ID: 11004
Updated by: mfp-***@public.gmane.org
Reported By: michael dot caplan at henryschein dot com
Status: Open
Id: 11004
Type: Bug
Package: SCA_SDO
Operating System: CentOS 4
PHP Version: 5.2.1
New Comment:

Mike, this is overkill. We think that the second binding element (the
one in the tns3 namespace, which is really the soap namespace) is
required (we see lots of examples of this for web services on
www.xmethods.net) and we are even more sure that we must have the second
binding element.



Are you able to get any more information about why the wsdl does not
validate? I suspect that it might be to do with the xsi:type elements.
Could you try just taking out those elements? If that is the problem we
could do a quick fix where we suppress them. In fact we do not want SDO
to generate them at all, and it would be useful for us to know that they
cause validation errors for you. After a quick fix, I could raise a
defect report on the SDO code.


Previous Comments:
------------------------------------------------------------------------

[2007-05-10 15:34:11] michael dot caplan at henryschein dot com

Description:
------------
My WSDL generated does not validate (ran against the oXygen editor and
Mindreef SOAPscope). The bindings elements appears to be adding bogus
child elements (operation contains a child of operation & binding
contains a child of binding).





The following diff fixed these issues:





Index:
Z:/michael/labnet_online/api/lib/SCA/Bindings/soap/ServiceDescriptionGenerator.php

===================================================================

---
Z:/michael/labnet_online/api/lib/SCA/Bindings/soap/ServiceDescriptionGenerator.php (revision
195)

+++
Z:/michael/labnet_online/api/lib/SCA/Bindings/soap/ServiceDescriptionGenerator.php (working
copy)

@@ -120,18 +120,10 @@

$binding =
$wsdl->createDataObject('binding');

$binding->name = "{$class_name}Binding";

$binding->type =
"{$wsdl->targetNamespace}#{$class_name}PortType";

- $soap_binding =
$xmldas->createDataObject(self::SOAP_NAMESPACE, 'tBinding');

- $soap_binding->style = 'document';

- $soap_binding->transport =
'http://schemas.xmlsoap.org/soap/http';

- $binding->binding = $soap_binding;

foreach ($service_desc->operations as $op_name => $params)
{

$binding_operation =
$binding->createDataObject('operation');

$binding_operation->name = $op_name;



- $soap_operation =
$xmldas->createDataObject(self::SOAP_NAMESPACE, 'tOperation');

- $soap_operation->soapAction = "";

- $binding_operation->operation = $soap_operation;

-

$bo_input =
$binding_operation->createDataObject('input');

$soap_body =
$xmldas->createDataObject(self::SOAP_NAMESPACE, 'tBody');

$bo_input->body = $soap_body;



Expected result:
----------------
<binding name="Labnet_API_LabnetOnline_001_ImplementationBinding"
type="tns2:Labnet_API_LabnetOnline_001_ImplementationPortType">

<operation name="getRestorations">

<input>

<tns3:body xsi:type="tns3:tBody" use="literal"/>

</input>

<output>

<tns3:body xsi:type="tns3:tBody" use="literal"/>

</output>

</operation>

</binding>

Actual result:
--------------
<binding name="Labnet_API_LabnetOnline_001_ImplementationBinding"
type="tns2:Labnet_API_LabnetOnline_001_ImplementationPortType">

<operation name="getRestorations">

<input>

<tns3:body xsi:type="tns3:tBody" use="literal"/>

</input>

<output>

<tns3:body xsi:type="tns3:tBody" use="literal"/>

</output>



<tns3:operation xsi:type="tns3:tOperation" soapAction=""/>

</operation>

<tns3:binding xsi:type="tns3:tBinding"
transport="http://schemas.xmlsoap.org/soap/http" style="document"/>

</binding>

------------------------------------------------------------------------
--
Edit this bug report at http://pecl.php.net/bugs/bug.php?id=11004&edit=1


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[m***@public.gmane.org]

Edit report at http://pecl.php.net/bugs/bug.php?id=11004&edit=1

ID: 11004
Updated by: mfp-***@public.gmane.org
Reported By: michael dot caplan at henryschein dot com
Status: Open
Id: 11004
Type: Bug
Package: SCA_SDO
Operating System: CentOS 4
PHP Version: 5.2.1
New Comment:

I just realised that when I said 'the second binding element (the one
in the tns3 namespace...' I meant the second _operation_ element (i.e.
the one with the soapAction). Sorry about that.


Previous Comments:
------------------------------------------------------------------------

[2007-05-17 08:32:13] mfp at php dot net

Mike, this is overkill. We think that the second binding element (the
one in the tns3 namespace, which is really the soap namespace) is
required (we see lots of examples of this for web services on
www.xmethods.net) and we are even more sure that we must have the second
binding element.



Are you able to get any more information about why the wsdl does not
validate? I suspect that it might be to do with the xsi:type elements.
Could you try just taking out those elements? If that is the problem we
could do a quick fix where we suppress them. In fact we do not want SDO
to generate them at all, and it would be useful for us to know that they
cause validation errors for you. After a quick fix, I could raise a
defect report on the SDO code.

------------------------------------------------------------------------

[2007-05-10 15:34:11] michael dot caplan at henryschein dot com

Description:
------------
My WSDL generated does not validate (ran against the oXygen editor and
Mindreef SOAPscope). The bindings elements appears to be adding bogus
child elements (operation contains a child of operation & binding
contains a child of binding).





The following diff fixed these issues:





Index:
Z:/michael/labnet_online/api/lib/SCA/Bindings/soap/ServiceDescriptionGenerator.php

===================================================================

---
Z:/michael/labnet_online/api/lib/SCA/Bindings/soap/ServiceDescriptionGenerator.php (revision
195)

+++
Z:/michael/labnet_online/api/lib/SCA/Bindings/soap/ServiceDescriptionGenerator.php (working
copy)

@@ -120,18 +120,10 @@

$binding =
$wsdl->createDataObject('binding');

$binding->name = "{$class_name}Binding";

$binding->type =
"{$wsdl->targetNamespace}#{$class_name}PortType";

- $soap_binding =
$xmldas->createDataObject(self::SOAP_NAMESPACE, 'tBinding');

- $soap_binding->style = 'document';

- $soap_binding->transport =
'http://schemas.xmlsoap.org/soap/http';

- $binding->binding = $soap_binding;

foreach ($service_desc->operations as $op_name => $params)
{

$binding_operation =
$binding->createDataObject('operation');

$binding_operation->name = $op_name;



- $soap_operation =
$xmldas->createDataObject(self::SOAP_NAMESPACE, 'tOperation');

- $soap_operation->soapAction = "";

- $binding_operation->operation = $soap_operation;

-

$bo_input =
$binding_operation->createDataObject('input');

$soap_body =
$xmldas->createDataObject(self::SOAP_NAMESPACE, 'tBody');

$bo_input->body = $soap_body;



Expected result:
----------------
<binding name="Labnet_API_LabnetOnline_001_ImplementationBinding"
type="tns2:Labnet_API_LabnetOnline_001_ImplementationPortType">

<operation name="getRestorations">

<input>

<tns3:body xsi:type="tns3:tBody" use="literal"/>

</input>

<output>

<tns3:body xsi:type="tns3:tBody" use="literal"/>

</output>

</operation>

</binding>

Actual result:
--------------
<binding name="Labnet_API_LabnetOnline_001_ImplementationBinding"
type="tns2:Labnet_API_LabnetOnline_001_ImplementationPortType">

<operation name="getRestorations">

<input>

<tns3:body xsi:type="tns3:tBody" use="literal"/>

</input>

<output>

<tns3:body xsi:type="tns3:tBody" use="literal"/>

</output>



<tns3:operation xsi:type="tns3:tOperation" soapAction=""/>

</operation>

<tns3:binding xsi:type="tns3:tBinding"
transport="http://schemas.xmlsoap.org/soap/http" style="document"/>

</binding>

------------------------------------------------------------------------
--
Edit this bug report at http://pecl.php.net/bugs/bug.php?id=11004&edit=1


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[m***@public.gmane.org]

Edit report at http://pecl.php.net/bugs/bug.php?id=11004&edit=1

ID: 11004
Updated by: mfp-***@public.gmane.org
Reported By: michael dot caplan at henryschein dot com
-Status: Open
+Status: Feedback
Id: 11004
Type: Bug
Package: SCA_SDO
Operating System: CentOS 4
PHP Version: 5.2.1
New Comment:

Can you say why the wsdl does not validate? Is it the xsi:type
attributes?


Previous Comments:
------------------------------------------------------------------------

[2007-05-17 09:03:12] mfp at php dot net

I just realised that when I said 'the second binding element (the one
in the tns3 namespace...' I meant the second _operation_ element (i.e.
the one with the soapAction). Sorry about that.

------------------------------------------------------------------------

[2007-05-17 08:32:13] mfp at php dot net

Mike, this is overkill. We think that the second binding element (the
one in the tns3 namespace, which is really the soap namespace) is
required (we see lots of examples of this for web services on
www.xmethods.net) and we are even more sure that we must have the second
binding element.



Are you able to get any more information about why the wsdl does not
validate? I suspect that it might be to do with the xsi:type elements.
Could you try just taking out those elements? If that is the problem we
could do a quick fix where we suppress them. In fact we do not want SDO
to generate them at all, and it would be useful for us to know that they
cause validation errors for you. After a quick fix, I could raise a
defect report on the SDO code.

------------------------------------------------------------------------

[2007-05-10 15:34:11] michael dot caplan at henryschein dot com

Description:
------------
My WSDL generated does not validate (ran against the oXygen editor and
Mindreef SOAPscope). The bindings elements appears to be adding bogus
child elements (operation contains a child of operation & binding
contains a child of binding).





The following diff fixed these issues:





Index:
Z:/michael/labnet_online/api/lib/SCA/Bindings/soap/ServiceDescriptionGenerator.php

===================================================================

---
Z:/michael/labnet_online/api/lib/SCA/Bindings/soap/ServiceDescriptionGenerator.php (revision
195)

+++
Z:/michael/labnet_online/api/lib/SCA/Bindings/soap/ServiceDescriptionGenerator.php (working
copy)

@@ -120,18 +120,10 @@

$binding =
$wsdl->createDataObject('binding');

$binding->name = "{$class_name}Binding";

$binding->type =
"{$wsdl->targetNamespace}#{$class_name}PortType";

- $soap_binding =
$xmldas->createDataObject(self::SOAP_NAMESPACE, 'tBinding');

- $soap_binding->style = 'document';

- $soap_binding->transport =
'http://schemas.xmlsoap.org/soap/http';

- $binding->binding = $soap_binding;

foreach ($service_desc->operations as $op_name => $params)
{

$binding_operation =
$binding->createDataObject('operation');

$binding_operation->name = $op_name;



- $soap_operation =
$xmldas->createDataObject(self::SOAP_NAMESPACE, 'tOperation');

- $soap_operation->soapAction = "";

- $binding_operation->operation = $soap_operation;

-

$bo_input =
$binding_operation->createDataObject('input');

$soap_body =
$xmldas->createDataObject(self::SOAP_NAMESPACE, 'tBody');

$bo_input->body = $soap_body;



Expected result:
----------------
<binding name="Labnet_API_LabnetOnline_001_ImplementationBinding"
type="tns2:Labnet_API_LabnetOnline_001_ImplementationPortType">

<operation name="getRestorations">

<input>

<tns3:body xsi:type="tns3:tBody" use="literal"/>

</input>

<output>

<tns3:body xsi:type="tns3:tBody" use="literal"/>

</output>

</operation>

</binding>

Actual result:
--------------
<binding name="Labnet_API_LabnetOnline_001_ImplementationBinding"
type="tns2:Labnet_API_LabnetOnline_001_ImplementationPortType">

<operation name="getRestorations">

<input>

<tns3:body xsi:type="tns3:tBody" use="literal"/>

</input>

<output>

<tns3:body xsi:type="tns3:tBody" use="literal"/>

</output>



<tns3:operation xsi:type="tns3:tOperation" soapAction=""/>

</operation>

<tns3:binding xsi:type="tns3:tBinding"
transport="http://schemas.xmlsoap.org/soap/http" style="document"/>

</binding>

------------------------------------------------------------------------
--
Edit this bug report at http://pecl.php.net/bugs/bug.php?id=11004&edit=1


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[m***@public.gmane.org]

Edit report at http://pecl.php.net/bugs/bug.php?id=11004&edit=1

ID: 11004
Updated by: mfp-***@public.gmane.org
Reported By: michael dot caplan at henryschein dot com
Status: Feedback
Id: 11004
Type: Bug
Package: SCA_SDO
Operating System: CentOS 4
PHP Version: 5.2.1
New Comment:

I just raised a defect report against the underlying C++ code that is
in the sdo extension.



https://issues.apache.org/jira/browse/TUSCANY-1297


Previous Comments:
------------------------------------------------------------------------

[2007-05-23 11:47:35] mfp at php dot net

Can you say why the wsdl does not validate? Is it the xsi:type
attributes?

------------------------------------------------------------------------

[2007-05-17 09:03:12] mfp at php dot net

I just realised that when I said 'the second binding element (the one
in the tns3 namespace...' I meant the second _operation_ element (i.e.
the one with the soapAction). Sorry about that.

------------------------------------------------------------------------

[2007-05-17 08:32:13] mfp at php dot net

Mike, this is overkill. We think that the second binding element (the
one in the tns3 namespace, which is really the soap namespace) is
required (we see lots of examples of this for web services on
www.xmethods.net) and we are even more sure that we must have the second
binding element.



Are you able to get any more information about why the wsdl does not
validate? I suspect that it might be to do with the xsi:type elements.
Could you try just taking out those elements? If that is the problem we
could do a quick fix where we suppress them. In fact we do not want SDO
to generate them at all, and it would be useful for us to know that they
cause validation errors for you. After a quick fix, I could raise a
defect report on the SDO code.

------------------------------------------------------------------------

[2007-05-10 15:34:11] michael dot caplan at henryschein dot com

Description:
------------
My WSDL generated does not validate (ran against the oXygen editor and
Mindreef SOAPscope). The bindings elements appears to be adding bogus
child elements (operation contains a child of operation & binding
contains a child of binding).





The following diff fixed these issues:





Index:
Z:/michael/labnet_online/api/lib/SCA/Bindings/soap/ServiceDescriptionGenerator.php

===================================================================

---
Z:/michael/labnet_online/api/lib/SCA/Bindings/soap/ServiceDescriptionGenerator.php (revision
195)

+++
Z:/michael/labnet_online/api/lib/SCA/Bindings/soap/ServiceDescriptionGenerator.php (working
copy)

@@ -120,18 +120,10 @@

$binding =
$wsdl->createDataObject('binding');

$binding->name = "{$class_name}Binding";

$binding->type =
"{$wsdl->targetNamespace}#{$class_name}PortType";

- $soap_binding =
$xmldas->createDataObject(self::SOAP_NAMESPACE, 'tBinding');

- $soap_binding->style = 'document';

- $soap_binding->transport =
'http://schemas.xmlsoap.org/soap/http';

- $binding->binding = $soap_binding;

foreach ($service_desc->operations as $op_name => $params)
{

$binding_operation =
$binding->createDataObject('operation');

$binding_operation->name = $op_name;



- $soap_operation =
$xmldas->createDataObject(self::SOAP_NAMESPACE, 'tOperation');

- $soap_operation->soapAction = "";

- $binding_operation->operation = $soap_operation;

-

$bo_input =
$binding_operation->createDataObject('input');

$soap_body =
$xmldas->createDataObject(self::SOAP_NAMESPACE, 'tBody');

$bo_input->body = $soap_body;



Expected result:
----------------
<binding name="Labnet_API_LabnetOnline_001_ImplementationBinding"
type="tns2:Labnet_API_LabnetOnline_001_ImplementationPortType">

<operation name="getRestorations">

<input>

<tns3:body xsi:type="tns3:tBody" use="literal"/>

</input>

<output>

<tns3:body xsi:type="tns3:tBody" use="literal"/>

</output>

</operation>

</binding>

Actual result:
--------------
<binding name="Labnet_API_LabnetOnline_001_ImplementationBinding"
type="tns2:Labnet_API_LabnetOnline_001_ImplementationPortType">

<operation name="getRestorations">

<input>

<tns3:body xsi:type="tns3:tBody" use="literal"/>

</input>

<output>

<tns3:body xsi:type="tns3:tBody" use="literal"/>

</output>



<tns3:operation xsi:type="tns3:tOperation" soapAction=""/>

</operation>

<tns3:binding xsi:type="tns3:tBinding"
transport="http://schemas.xmlsoap.org/soap/http" style="document"/>

</binding>

------------------------------------------------------------------------
--
Edit this bug report at http://pecl.php.net/bugs/bug.php?id=11004&edit=1


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Caroline Maynard]

Hi Matthew, thanks for helping administer the SDO defects. A few points
of process:

a) in Tuscany-land, the XML support is not a DAS, it's core code (the
XMLHelper). I realise why it's tempting to assign the jira to "C++ DAS",
but those are the people working on a C++ Relational DAS. The component
you want is "C++ SDO". I've transferred this one for you.

b) When a defect is assigned to Tuscany, we assign it to "tuscany". This
one was left in feedback state, which means that we're waiting for the
originator to do something. We also add a link to the Tuscany defect -
which you did - but it wasn't clickable because the peclweb code only
does that for http, not https (doh). So I added another one.

c) Since I last overhauled the defects, I have been operating a more
test-driven development process. Sometimes these Tuscany defects take a
long time to fix, and it's not always easy to recreate the original
problem when you've forgotten the details. Plus we need to keep building
a good regression suite for real problems that people have encountered.
So part of the act of transferring a defect should be to create a
testcase while the details are clear in your mind, and add it to the
test suite, skipped so that it doesn't make the test suite fail. See,
for example,
http://cvs.php.net/viewvc.cgi/pecl/sdo/tests/SDO/phpt/bug8694.phpt?view=markup&sortby=date
though of course you may choose a phpunit test if you prefer. Please
would you add a test for this bug too?

Post by m***@public.gmane.org
Edit report at http://pecl.php.net/bugs/bug.php?id=11004&edit=1
ID: 11004
Reported By: michael dot caplan at henryschein dot com
Status: Feedback
Id: 11004
Type: Bug
Package: SCA_SDO
Operating System: CentOS 4
PHP Version: 5.2.1
I just raised a defect report against the underlying C++ code that is
in the sdo extension.
https://issues.apache.org/jira/browse/TUSCANY-1297

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Matthew Peters]

Caroline,

a) Thanks, I have made a note on a postit and stuck on the top sheet
of my SCA for PHP todo - assign defects we find in XML parsing to C++
SDO *not* C++ DAS.

b) I am not sure if you are telling me that I need to do something
here. Is there something I need to do in future that I have not been
doing?

c) Difficult in this particular case, especially because we did not
know what we wanted the valid output to be. We just knew that we
wanted it to validate with soapscope, oXygen and visual studio. Now
that I know more about what the problems were I think the thing to do
is to write a Java program to run both the generated WSDL and
generated soap messages through XERCES. I will put this alongside the
phpunit and phpt tests. I don't think I can do it in PHP since we
never caught any of these problems with the PHP code.



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Caroline Maynard]

Post by Matthew Peters
b) I am not sure if you are telling me that I need to do something
here. Is there something I need to do in future that I have not been
doing?

It's fine now. It was something you didn't do for this particular bug -
which was in "feedback" (harsh turquoise) state at the time of this
discussion - but I can see you are doing it now, as all the relevant
bugs I can see are nicely assigned to "tuscany nnnn" in that fetching
lilac.

Don't 10989 and 10994 need closing in the PECL tracker now?

Post by Matthew Peters
c) Difficult in this particular case, especially because we did not
know what we wanted the valid output to be. We just knew that we
wanted it to validate with soapscope, oXygen and visual studio. Now
that I know more about what the problems were I think the thing to do
is to write a Java program to run both the generated WSDL and
generated soap messages through XERCES. I will put this alongside the
phpunit and phpt tests. I don't think I can do it in PHP since we
never caught any of these problems with the PHP code.

I agree this is tough when we don't know the desired output. But I do
believe it's still worth creating a testcase - the testcase must be
skipped anyway until the solution is implemented, so the fact that it

Post by Matthew Peters
may< not be in its final form need not be an impediment.

For these particular defects, you are looking at the big picture and
saying that the user requirement is that the WSDL validates with these
external programs and we cannot develop php unit tests which will verify
this. Of course you're right, and your Java test will be a valuable
addition, I'm sure. But I don't agree with your conclusion that this
means there is no meaningful regression test for these defects. For
example, if a problem was that Tuscany generated two XML elements in the
wrong order, then it's a SMOP to test that Tuscany now generates them in
the right order - and (at least at this stage) the more of these tests
we have the better, because such tests have a habit of finding other
unexpected side-effects of changes that go into the code. If we make a
habit of growing the test suite bottom-up in this way, we'll improve the
test coverage in the parts of the code that get most used.

--
Caroline


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Caroline Maynard]

Hi Matthew, thanks for helping administer the SDO defects. A few points
of process:

a) in Tuscany-land, the XML support is not a DAS, it's core code (the
XMLHelper). I realise why it's tempting to assign the jira to "C++ DAS",
but those are the people working on a C++ Relational DAS. The component
you want is "C++ SDO". I've transferred this one for you.

b) When a defect is assigned to Tuscany, we assign it to "tuscany". This
one was left in feedback state, which means that we're waiting for the
originator to do something. We also add a link to the Tuscany defect -
which you did - but it wasn't clickable because the peclweb code only
does that for http, not https (doh). So I added another one.

c) Since I last overhauled the defects, I have been operating a more
test-driven development process. Sometimes these Tuscany defects take a
long time to fix, and it's not always easy to recreate the original
problem when you've forgotten the details. Plus we need to keep building
a good regression suite for real problems that people have encountered.
So part of the act of transferring a defect should be to create a
testcase while the details are clear in your mind, and add it to the
test suite, skipped so that it doesn't make the test suite fail. See,
for example,
http://cvs.php.net/viewvc.cgi/pecl/sdo/tests/SDO/phpt/bug8694.phpt?view=markup&sortby=date
though of course you may choose a phpunit test if you prefer. Please
would you add a test for this bug too?

Post by m***@public.gmane.org
Edit report at http://pecl.php.net/bugs/bug.php?id=11004&edit=1
ID: 11004
Reported By: michael dot caplan at henryschein dot com
Status: Feedback
Id: 11004
Type: Bug
Package: SCA_SDO
Operating System: CentOS 4
PHP Version: 5.2.1
I just raised a defect report against the underlying C++ code that is
in the sdo extension.
https://issues.apache.org/jira/browse/TUSCANY-1297

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Caroline Maynard]

Hi Matthew, thanks for helping administer the SDO defects. A few points
of process:

a) in Tuscany-land, the XML support is not a DAS, it's core code (the
XMLHelper). I realise why it's tempting to assign the jira to "C++ DAS",
but those are the people working on a C++ Relational DAS. The component
you want is "C++ SDO". I've transferred this one for you.

b) When a defect is assigned to Tuscany, we assign it to "tuscany". This
one was left in feedback state, which means that we're waiting for the
originator to do something. We also add a link to the Tuscany defect -
which you did - but it wasn't clickable because the peclweb code only
does that for http, not https (doh). So I added another one.

c) Since I last overhauled the defects, I have been operating a more
test-driven development process. Sometimes these Tuscany defects take a
long time to fix, and it's not always easy to recreate the original
problem when you've forgotten the details. Plus we need to keep building
a good regression suite for real problems that people have encountered.
So part of the act of transferring a defect should be to create a
testcase while the details are clear in your mind, and add it to the
test suite, skipped so that it doesn't make the test suite fail. See,
for example,
http://cvs.php.net/viewvc.cgi/pecl/sdo/tests/SDO/phpt/bug8694.phpt?view=markup&sortby=date
though of course you may choose a phpunit test if you prefer. Please
would you add a test for this bug too?

Post by m***@public.gmane.org
Edit report at http://pecl.php.net/bugs/bug.php?id=11004&edit=1
ID: 11004
Reported By: michael dot caplan at henryschein dot com
Status: Feedback
Id: 11004
Type: Bug
Package: SCA_SDO
Operating System: CentOS 4
PHP Version: 5.2.1
I just raised a defect report against the underlying C++ code that is
in the sdo extension.
https://issues.apache.org/jira/browse/TUSCANY-1297

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---