[phpsoa] Re: Upgrading EIDER to latest Tusany code
On 16 Jul, 05:29, Matthew Peters <[EMAIL PROTECTED]> wrote: > Rob, thank you very much for your investigations. You suggested > 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, 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Upgrading EIDER to latest Tusany code
Rob wrote: > 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); } } --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Upgrading EIDER to latest Tusany code
Rob, thank you very much for your investigations. You suggested 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Upgrading EIDER to latest Tusany code
On 12 Jul, 06:09, Matthew Peters <[EMAIL PROTECTED]> 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. 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Upgrading EIDER to latest Tusany code
On 12 Jul, 12:31, Caroline Maynard <[EMAIL PROTECTED]> wrote: > 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Upgrading EIDER to latest Tusany code
Rob wrote: > 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. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Upgrading EIDER to latest Tusany code
That sounds a good way to go. Good suggestion. On Jul 12, 12:10 pm, Rob <[EMAIL PROTECTED]> wrote: > pass the serialized request as the parameter to the handle() call. In --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Upgrading EIDER to latest Tusany code
On 12 Jul, 06:09, Matthew Peters <[EMAIL PROTECTED]> 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Upgrading EIDER to latest Tusany code
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. Matthew On Jul 11, 4:40 pm, Rob <[EMAIL PROTECTED]> wrote: > 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. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Upgrading EIDER to latest Tusany code
On 11 Jul, 11:02, Caroline Maynard <[EMAIL PROTECTED]> wrote: > 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. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Upgrading EIDER to latest Tusany code
Matthew Peters wrote: > P.S. Just checking - you've changed the skips so that 002 and 003, > 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? 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. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Upgrading EIDER to latest Tusany code
P.S. Just checking - you've changed the skips so that 002 and 003, 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? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Upgrading EIDER to latest Tusany code
Yes, I think the new behaviour is correct. The recent Tuscany changes 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. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Upgrading EIDER to latest Tusany code
On Jul 9, 5:25 pm, Matthew Peters <[EMAIL PROTECTED]> 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=oj1XjUUZj1jRVeAQXthn8kvDWxbE6Ui6Sc9nlHcMywtLU5RaqGG1qiJ7UbTIup-M2XPURDQsmhrtvNcFgMjapEx7FyqM1X6Mhjad6nqcYngosQ3Sew (that's 002, but the pattern of changes for 003 is the same) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Upgrading EIDER to latest Tusany code
I think the namespace saga (JIRA 1112) is over at last - 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. Matthew --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Upgrading EIDER to latest Tusany code
[EMAIL PROTECTED] wrote: > > On 5 Jul, 14:25, Matthew Peters <[EMAIL PROTECTED]> wrote: >> What happened to Simon's userid? >> >>> simonslaws-gM/[EMAIL PROTECTED] wrote: > > Not sure! It's decided I don't need an alias anymore. 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. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Upgrading EIDER to latest Tusany code
On 5 Jul, 14:23, Matthew Peters <[EMAIL PROTECTED]> wrote: > For info, I took a look at Tuscany JIRA 1112 again last week on Friday > 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 <[EMAIL PROTECTED]> > wrote: > > > 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. No problem --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Upgrading EIDER to latest Tusany code
On 5 Jul, 14:25, Matthew Peters <[EMAIL PROTECTED]> wrote: > What happened to Simon's userid? > > > simonslaws-gM/[EMAIL PROTECTED] wrote: Not sure! It's decided I don't need an alias anymore. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Upgrading EIDER to latest Tusany code
What happened to Simon's userid? > simonslaws-gM/[EMAIL PROTECTED] wrote: --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Upgrading EIDER to latest Tusany code
For info, I took a look at Tuscany JIRA 1112 again last week on Friday 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 <[EMAIL PROTECTED]> wrote: > 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. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Upgrading EIDER to latest Tusany code
On 28 Jun, 17:46, Caroline Maynard <[EMAIL PROTECTED]> wrote: > simonslaws-gM/[EMAIL PROTECTED] 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. 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Upgrading EIDER to latest Tusany code
simonslaws-gM/[EMAIL PROTECTED] 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. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Upgrading EIDER to latest Tusany code
Simon, 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 On Jun 25, 1:12 pm, [EMAIL PROTECTED] wrote: > Needs more investigation but I thought I would post this in case > someone else embarks on the same piece of work. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---