Upgrading EIDER to latest Tusany code
simon...@googlemail.com
55041 to included the changes to prevent schema being re-read if it is
read via namspace only (TUSCANY-1362). I am seeing some problems now
with the soap mapper unit test. In particular.
PHPUnit Tests
PHPUnit 3.0.0 by Sebastian Bergmann.
...................................S.....
.........................................
..........................S......<?xml version="1.0" encoding="UTF-8"?
>
<BOGUS xmlns="http://TypeHandlerTest2">
<p1>
<tns2:name>William Shakespeare</tns2:name>
<tns2:dob>April 1564, most likely 23rd</tns2:dob>
<tns2:pob>Stratford-upon-Avon, Warwickshire</tns2:pob>
</p1>
</BOGUS>
F.......
...I...........I.........................
.........................................
...
Time: 00:31
There was 1 failure:
1)
testToXmlGeneratesGoodXmlFromSdoWithSdos(SCA_Bindings_soap_MapperTest)
Failed asserting that <text> contains "<name>William Shakespeare</
name>".
C:\simon\Projects\Tuscany\php\branch-build\pecl\sdo\tests\SCA\phpunit
\SoapBindin
g\MapperTest.php:126
C:\simon\Projects\Tuscany\php\branch-build\pecl\sdo\tests
\TestSuite.php:41
C:\simon\Projects\Tuscany\php\branch-build\pecl\sdo\tests
\TestSuite.php:58
C:\simon\Projects\Tuscany\php\branch-build\pecl\sdo\tests\AllTests.php:
28
You will note that I added a line to print out the XML that it is
failing on. It seems that SDO thinks the elements are in a namespace
identified by tns2 but that short name is not defined in the output
document. This is not actually why the test is failing. It's failing
as it's not expecting to see tns2 at all. But I don't believe tns2 is
required.
Needs more investigation but I thought I would post this in case
someone else embarks on the same piece of work.
As an aside I can check the updated SDO implementation into EIDER if
anyone wants to try it. I have updated SDOUserMacros.h to match what
is required for PHP SDO. Is there anything elses I need to fix up
before I check in?
Regards
Simon
Matthew Peters
thanks for putting this up here and saving us all falling over it. I
expect this is related to the answer I got back on
https://issues.apache.org/jira/browse/TUSCANY-1112
which is all about namespaces, and where I know a fix was checked in
recently (a week or so ago, after I took the code for DUNLIN). I
expected when I read the answer on the JIRA that there might be
problems because the answer was telling me something I did not agree
with about what element should be on what namespace. But I know it's
going to need a bit of time for me to load my head up with the rules
about namespaces and answer the JIRA again. I think I had XERCES on my
side when I raised the JIRA in the first place, as it happens.
Anyway, I think there is a chance that the recent namespace change in
the Tuscany code (leaving aside the fact that tns2 is not defined as a
namespace prefix) is wrong, so I suggest that you do not check it in.
I will look at the JIRA and answer it for sure in the next two days,
and also reply back here with what I find.
Matthew
Caroline Maynard
simonslaws-gM/Ye1E23mwN...@public.gmane.org wrote:
> As an aside I can check the updated SDO implementation into EIDER if
> anyone wants to try it. I have updated SDOUserMacros.h to match what
> is required for PHP SDO. Is there anything elses I need to fix up
> before I check in?
As per Matthew's post, best to hold off for now, but for when it's sorted:
Since you should only be merging updated files, you should never need to
touch SDOUserMacros.h, unless Tuscany people make any changes to the
base version, which is unlikely.
Otherwise just copy over the changed files. Only the Tuscany source code
in cpp/sdo/runtime/core/src/commonj/sdo is copied over - no tests, build
files, or similar. It's good practice to eyeball the changes to see what
new behaviour to expect.
If any source files have been added or deleted, then you need to update
both config.m4 and config.w32 accordingly. If you're on Windows, make
sure you've compiled with MS VC++ 6, because this is still the required
compiler for php builds, and unfortunately it has several
inconsistencies with later versions.
simon...@googlemail.com
On 28 Jun, 17:46, Caroline Maynard <c...@php.net> wrote:
Thanks both for the responses. I'll hold off on this for the time
being. As I was away and disconnected I started looking at the rest
resource binding. I'm going to carry on with that for now and come
back to this a little later in the week.
Regards
Simon
Matthew Peters
and am convinced that the recent namespace changes are not right; and
a backward step on what was in there before which was not right
either. I have updated the JIRA - I'll wait another day and then
enquire what the outlook for a fix is. In the meantime, Simon, I'll be
glad if you don't check in the recent changes :-)
Matthew
On Jun 28, 10:46 am, Matthew Peters <matthew.f.pet...@googlemail.com>
wrote:
Matthew Peters
> simonslaws-gM/Ye1E23mwN+BqQ9rB...@public.gmane.org wrote:
simon...@googlemail.com
On 5 Jul, 14:25, Matthew Peters <matthew.f.pet...@googlemail.com>
wrote:
> What happened to Simon's userid?
>
> > simonslaws-gM/Ye1E23mwN+BqQ9rB...@public.gmane.org wrote:
Not sure! It's decided I don't need an alias anymore.
simon...@googlemail.com
Caroline Maynard
I think it happens because you don't have a nickname. This is a bit
confusing, because there are (at least) two distinct places where you
can set your name - one is the Groups profile
http://groups.google.com/groups/profile?myprofile where you have
name=Simon location=Laws (?), the other is per-group at
http://groups.google.com/group/phpsoa/subscribe. It's the latter that
you don't have set, I think.
Matthew Peters
picked up the latest Tuscany and the generated XML now validates with
XERCES. I had to change a few unit tests that relied on the old
behaviour. Everything is checked back in now, so if you pick up a new
EIDER there should be no failures amongst the phpt and phpunit tests.
Matthew
cem
wrote:
> I think the namespace saga (JIRA 1112) is over at last -
I don't believe the namespace saga will ever be over! Still, it's
excellent that we currently have a version that suits everyone so far
as we know.
>I have just
> picked up the latest Tuscany and the generated XML now validates with
> XERCES. I had to change a few unit tests that relied on the old
> behaviour. Everything is checked back in now, so if you pick up a new
> EIDER there should be no failures amongst the phpt and phpunit tests.
Well I do have some failures - SCA phpt tests 002 and 003. I suspect
it may be because these tests were skipped, and you may have
overlooked them. The description of the related bug which caused them
to be skipped says that the problem only occurs with PHP 5.2.3 on
Linux. So I've updated the skip condition accordingly. Having done
that, I am seeing a failure, which I hope is just down to the Tuscany
changes, and that the new output is correct. But I didn't want to just
update the expected results in the test until you'd had a chance to
express an opinion. See the output here:
http://phpsoa.googlegroups.com/web/SCAphpt002-diff.html?gda=oj1XjUUAAAAZj1jRVeAQXthn8kvDWxbE6Ui6Sc9nlHcMywtLU5RaqGG1qiJ7UbTIup-M2XPURDQsmhrtvNcFgMjapEx7FyqM1X6Mhjad6nqcYngosQ3Sew
(that's 002, but the pattern of changes for 003 is the same)
Matthew Peters
have stopped the default namespace being emitted, so the output on the
left hand side of your file compare is the one we want to see. Thank
you for fixing the skip conditions.
Matthew Peters
which were skipped, now fail. You are going to change the expected
output to take out the default namespace, and then they'll work. Is
that right?
Caroline Maynard
Indeed. In the time-honoured manner, I have changed the expected output
of the test to match the actual output :-), so the tests now work (when
they are not skipped).
The pecl bug about the disappearing output on Linux with 5.2.3
(http://pecl.php.net/bugs/bug.php?id=11388) remains open, in the hope
that someone who's seeing the problem will investigate further.
Rob
> The pecl bug about the disappearing output on Linux with 5.2.3
> (http://pecl.php.net/bugs/bug.php?id=11388) remains open, in the hope
> that someone who's seeing the problem will investigate further.
I had looked at this one the other day. ext/soap was changed for 5.2.3
to use SG(request_info).raw_post_data (which doesn't get set running
in CLI mode) instead of pulling HTTP_RAW_POST_DATA from the symbol
table. So, when handle is called there is no input message to process
and the SoapServer doesn't do anything.
I did have to however make some changes to the source to get things
working:
http://www.ctindustries.net/patches/sdo.diff.txt
change in commonj/sdo/SDOSchemaSAX2Parser.h was required to compile
(Fedora 6)
change in SDO_DataObject.cpp was for a memleak (bug10049.phpt was
failing due to leak messages) - though not sure what would happen is
returned if EG(uninitialized_zval_ptr) is passed to compare_function.
Matthew Peters
Unless you also have an idea how to achieve what we wanted, I'll write
to Dmitry and see if he can suggest a way to unit test applications
that use the soap server from the command line.
Matthew
Rob
wrote:
> Rob, thank you very much for the information about HTTP_RAW_POST_DATA.
> Unless you also have an idea how to achieve what we wanted, I'll write
> to Dmitry and see if he can suggest a way to unit test applications
> that use the soap server from the command line.
The only way to do unit tests now with soap server under cli is to
pass the serialized request as the parameter to the handle() call. In
this case though, I don't believe it is possible without internal
changes to the SCA soap binding.
Rob
Matthew Peters
Caroline Maynard
> I did have to however make some changes to the source to get things
> working:
> http://www.ctindustries.net/patches/sdo.diff.txt
> change in commonj/sdo/SDOSchemaSAX2Parser.h was required to compile
> (Fedora 6)
> change in SDO_DataObject.cpp was for a memleak (bug10049.phpt was
> failing due to leak messages) - though not sure what would happen is
> returned if EG(uninitialized_zval_ptr) is passed to compare_function.
Umm, that may work in the contect of bug10049, because the value of the
"customer" property is null ... but in general it's going to leak like
mad, because FREE_ZVAL just frees the container, not the contents.
You're right that this is where the problem lies though - because I'm
expecting that the refcount will be 1 at this point, and it's actually
0, so the contents are not getting cleared. Thanks.
Thanks also for the Fedora report, I've passed it on to the Tuscany
developers.
Rob
> Umm, that may work in the contect of bug10049, because the value of the
> "customer" property is null ... but in general it's going to leak like
> mad, because FREE_ZVAL just frees the container, not the contents.
> You're right that this is where the problem lies though - because I'm
> expecting that the refcount will be 1 at this point, and it's actually
> 0, so the contents are not getting cleared. Thanks.
What's a little leaking between friends :D. Sorry, I wasn't even
thinking about that.
I do have a question about the change though. Is there any possibility
that EG(uninitialized_zval_ptr) would ever be returned for either
value, as its probably not a good idea to be playing around with that.
Conceptual I wouldn't think so if you are comparing 2 SDO objects, but
I'm not fluents in its internal workings to know for sure.
Rob
Rob
> Unless you also have an idea how to achieve what we wanted, I'll write
> to Dmitry and see if he can suggest a way to unit test applications
> that use the soap server from the command line.
I did a little more investigating on this issue and it seems it is
possible to perform the test *BUT* PHP must be built with the cgi
sapi.
On my windows system, I have both cli and cgi built and am
successfully able to run the 002.phpt test with the following
modifications:
http://www.cdatazone.org/files/002.phps
The only thing I am not sure is what previous versions of PHP this
will actually work for.
Rob
Matthew Peters
earlier that it might be possible to change the soap binding so that
it passes the info in on the handle() call. Presumably this would work
in all cases without needing to rely on how php was built?
Matthew
Caroline Maynard
> I do have a question about the change though. Is there any possibility
> that EG(uninitialized_zval_ptr) would ever be returned for either
> value, as its probably not a good idea to be playing around with that.
> Conceptual I wouldn't think so if you are comparing 2 SDO objects, but
> I'm not fluents in its internal workings to know for sure.
I know how you feel - it's like building on a deck of cards - but I'm
not worried in this case, not because I'm certain that that value will
never be returned, but because I believe the internals will do the right
thing if it does happen. It will eventually get down to this:
static inline void safe_free_zval_ptr_rel(zval *p ZEND_FILE_LINE_DC
ZEND_FILE_LINE_ORIG_DC)
{
TSRMLS_FETCH();
if (p!=EG(uninitialized_zval_ptr)) {
FREE_ZVAL_REL(p);
}
}
Rob
wrote:
Matthew,
That is correct. If a SOAP request is passed to the handle() method,
the server will use that rather than trying to pull it from the POST
context.
Nice thing about this is that it allows the server to be tested and
debugged under CLI. It could also be used to grab a request that might
be stored in a message queue for later processing, processed and then
acted upon (maybe pushing the boundaries of the language itself, but
very doable).
Anyways, as long as you can extract the soap request (i.e. from
$HTTP_RAW_POST_DATA, php://input or some other source) you can pass it
as a string to handle(). It might be a good idea to have the binding
work the same way - allow data to be passed, in which case it would
pass it to the handle() method; otherwise it doesn't pass anything and
the SOAP server acts in the same manner as it does now.
Caroline,
Thanks for pointing that out. I had forgotten that it was tested
there.
Rob