Hi mbertazz,
This is a tricky little problem. The essence of the problem is that
config.php only expects to find itself called from the very top level
script, where all variables are global. That is why it does not bother
to do global $CFG itself. However, when we call pippo.php for the
first
it as the target of
a webservice call.
thank you again,
mbertazz
On Mar 14, 6:24 pm, Matthew Peters [EMAIL PROTECTED]
wrote: Hi mbertazz,
This is a tricky little problem. The essence of the problem is that
config.php only expects to find itself called from the very top level
script, where all
Yes, exactly right. The scope is intended to be module init to
shutdown, and across all callers. I don't really know how I could do
otherwise - a per-request cache would be throwing away all the
benefit.
Of course you have worried me now. If the keys are chosen poorly - for
example every call
@googlegroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Matthew Peters
Sent: May 15, 2007 1:47 PM
To: phpsoa
Subject: [phpsoa] Re: nillable
(Joining this thread a week late :-))
Mike, you have done a fantastic job of researching the options.
I'm
puzzled why you say _two_
On May 23, 2:17 pm, [EMAIL PROTECTED] wrote:
or tell me how to fix the docs and I'll do it.
Fixing the docs is a bit of a pig because it is a Linux-based XML-
based (DocBook) compile-style activity. I'll fix this one right now.
Sometime, if you fancy a go, here are some notes on the process:
On May 23, 2:17 pm, [EMAIL PROTECTED] wrote:
or tell me how to fix the docs and I'll do it.
Fixing the docs is a bit of a pig because it is a Linux-based XML-
based (DocBook) compile-style activity. I'll fix this one right now.
Sometime, if you fancy a go, here are some notes on the process:
On May 23, 2:17 pm, [EMAIL PROTECTED] wrote:
or tell me how to fix the docs and I'll do it.
Fixing the docs is a bit of a pig because it is a Linux-based XML-
based (DocBook) compile-style activity. I'll fix this one right now.
Sometime, if you fancy a go, here are some notes on the process:
On May 23, 2:17 pm, [EMAIL PROTECTED] wrote:
or tell me how to fix the docs and I'll do it.
Fixing the docs takes a bit of investment because it is a Linux-based
XML-based (DocBook) compile-style activity. I'll fix this one right
now. Sometime, if you fancy a go, here are some notes on the
Please can we turn it off?
--~--~-~--~~~---~--~~
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]
d) one of the package maintainers, who do receive a stream of info
about defects, could volunteer to produce a weekly digest of
activity.
Who is this user phpsoa who writes to us from behind an alias? Let
them show their face, I say! :-)
Depending on the response, I can:
a) leave it turned
Yes, I'm getting the Could not post when actually the post worked.
Then when I realise that the posts did work, I have to go and delete
all but one. It's topic Thanks, Google in the list below. I don't
know, you use a free service and then complain when you get your
money's worth.
On May 24,
I volunteer to produce a weekly post of defect activity. I will make
that a Friday afternoon task. I will do that until further notice, but
let's say for the next three months for definite. I will try to find a
deputy for when I am not here.
Ok I volunteered, Does that mean I have to follow
I just checked in to DUNLIN a temporary change so that the ebaysoap
binding uses the caching of the data factory. Specifically, what I did
was:
1. enable the caching in the sdo extension when the special two-
argument version of SDO_DAS_XML::create is used
2. make the table of cached data
I'm glad you like the idea, and you ask a good question. It has always
seemed to me that right at the bottom we have service-oriented
components and resource-oriented components, and that the service
oriented ones can all be totally different but that at one level the
resource-oriented ones are
You're right of course, we still need the comment, for the reason you
mention. All the rest still stands.
On Jun 4, 11:44 am, Graham Charters [EMAIL PROTECTED] wrote:
Isn't this used to identify and unwrap the interface of the doc/lit
wrapped service? If this is the case, then we still can't
I wonder what happened to the post I just sent
... forget the words I said last time, since Caroline said it had to
be an object not an array I proposed the following interface:
$key = // calculate this in some way based on the xsd or xsds to be
used.
if (SDO::cache-containsKey($key)) {
I had a look at all these today. The nub of the problem is that both
#11012 and #11004 point at JIRA #1297. I created the confusion in the
first place when I raised Tuscany JIRA 1297 - I raised the original
JIRA with a title that presupposed what the problem was. Really the
problem is that the
I have just checked in some changes to the SDO C++ code (thanks, Pete
Robbins) and a one-liner to one of the classes in the soap binding
which I think fix 11012 and 11004. Both the wsdl and the soap messages
now validate correctly with soapscope and Java Xerces, which I think
must be what
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
Caroline,
Thanks for the reminder, I have changed the Tuscany defect 1297 to
closed.
I have made a note of the Tuscany level in our DUNLIN page here - I'll
remember to add it to the release notes.
I have just answered your post on 24th May - which I never spotted at
the time, apologies. There
Simon,
the place to fix things is in DUNLIN. Once that is right, then I will
move the code across to HEAD, create the release, and make the new
branch.
Please go ahead and fix anything you want to, then when you have
finished let me know what's left. I should have made more effort to
catch the
Simon, the index.php did contain a reference to helloworldscajsonrpc/
Helloworld.php which did not exist - it should have been
helloworld.php. Thanks for spotting - I have fixed.
Matthew
On 18 Jun, 16:12, [EMAIL PROTECTED] wrote:
Things left to do If any one fancies taking a look
1/
Good progress. I will generate another RC
--~--~-~--~~~---~--~~
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
...well, actually. Two things:
1. I moved the dependency test for the ebaysoapbinding into one place
in the setUp method rather than in every test. I hope you would have
done the same...
...but...
2. There are some horrible network delays. I am working at home on a
broadband line and the soap
2. There are some horrible network delays. I am working at home on a
For example I just got a timeout. We can see it is going out on the
web for http://schemas.xmlsoap.org/wsdl/:
.br /
bWarning/b: SDO_DAS_XML::create(http://schemas.xmlsoap.org/wsdl/)
[a
What are we going to do then? Sitting on a broadband connection, each
of the WSDL generation tests takes about a second. That's in the
morning UK time when the US is asleep. The times go up considerably in
the afternoon. Two days running the times have gone above 30 seconds.
It is a one-line
I just uploaded a new release candidate for DUNLIN (1.2.2) into the
files section of this google group. I deleted the previous one, so the
one that is there, and says it was uploaded at 8:10, is the one to
try.
wrt to the going out on the web for no schemalocation problem, I
went for the
I have just committed the DUNLIN branch to HEAD, and built and
released it as release 1.2.2. The release notes are:
* Fixes for PECL bugs:
- PECL#10925 - Don't treat magic PHP methods as service operations
- PECL#10989 - don't automatically make all types in the wsdl nillable
- PECL#10994 -
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
Sorry - In my case silence = I usually only watch the top 7 topics
i.e. the ones that show up on the phpsoa google page, and this one had
risen up and fallen below that threshold before I got round to reading
it.
I think it would be an interesting social experiment to see if we can
evolve some
I am such a bad person. I knew I wasn't doing it and was always half-
expecting someone to call me to account. OK I *_promise_* to do it
this Friday :-)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
phpsoa group.
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.
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
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
We have a first attempt at a ATOMPUB binding sitting on a server here
that has quite made it to the outside world. It was mostly written by
Megan Beynon - she put a lot of work in but then had to move to
another project.
The essential idea is that you can define a proxy for a remote
component
Shame I didn't read it through carefully before posting - that should
be
that has *not* quite made it to the outside world ...
On Jul 17, 10:06 am, Matthew Peters [EMAIL PROTECTED]
wrote:
that has quite made it to the outside world. It was mostly written
Good, I'm pleased :-)
On Jul 17, 4:15 pm, Caroline Maynard [EMAIL PROTECTED] wrote:
Thanks, I enjoyed that. Highly digestible :-)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
phpsoa group.
To post to this
On Aug 20, 12:10 pm, Caroline Maynard [EMAIL PROTECTED] wrote:
Matthew Peters wrote:
Incidentally, could you paste in a little of the code that used to add
the fields to the entry? I am finding it very hard to write the code
that creates an entry - something to do with the weird many
How beastly of it. Now, who wants to be the one to tell Pete...
On Aug 22, 11:33 am, Caroline Maynard [EMAIL PROTECTED] wrote:
However I am still getting the 400 status code (with no error message)
from the atompub server. I think the code in question just can't cope
with not having a
Hi Caroline,
well spotted. There are places in both the wsdl generation and in the
xmlrpc binding that we generate xml by simply sticking strings
together ( I searched for / ).
We should probably edit the variables that we are using to make sure
they don't contain dodgy characters. I think they
Hi Dan,
Thanks for trying SCA and for telling us about the problem. Please
would you put up the Temperatures.xsd as well? I'll look at it
straight away.
Matthew
On Jan 25, 12:28 am, Dalibor Andzakovic [EMAIL PROTECTED]
wrote:
Hi All,
I Have a problem running consuming SCA exposed as a
27, 9:29 pm, Dalibor Andzakovic [EMAIL PROTECTED]
wrote:
On Jan 25, 10:23 pm, Matthew Peters [EMAIL PROTECTED]
wrote:
Thanks for trying SCA and for telling us about the problem. Please
would you put up the Temperatures.xsd as well? I'll look at it
straight away.
Hi Matthew,
thanks
reproduce the error then I will ask you to turn on the
logging inside SCA and we will see what is going on that way, but I'll
tell you how to do that if we need to.
Matthew Peters
I think we're now handling this error in the other thread entitled
Fatal error: Uncaught SCA_RuntimeException
On Feb 6, 12:57 pm, khurrum [EMAIL PROTECTED] wrote:
Try The soap examples is is coming in all soap examples
Fatal error: Uncaught SCA_RuntimeException: The remote service threw
For info, there is an example in the release that does I think what
you want to do. I don't know where it would have been installed on
your machine, but on my Linux machine:
/usr/local/lib/php/test/SCA_SDO/examples/SCA/Soap/
SCAComponentUsingDataStructures
it shows calling a sefvice via SOAP
For info, Khurrum wrote to me to say that this was indeed to do with
the level of the soap extension:
Hey i got it working when i have upgraded my php 5.16 to 5.24 ,oyu
were right it was the Soap version error.
Case closed.
On Feb 7, 4:40 pm, Matthew Peters [EMAIL PROTECTED]
wrote:
Because
I have built and released FULMAR as 1.2.4
The contents are:
# The ability to control the operations on a service interface through
a PHP interface
by specifying the PHP interface on the @service annotation - e.g.
@service MyServiceInterface
# PECL bug 11997 - don't remove xsi:type (except on top
:
SCA_Bindings_message_ServiceDescriptionGenerator::generateMSD($service_description));
we downloaded the SCA_SDO stable version 1.2.3 from
here:http://pecl.php.net/package/SCA_SDO/
Again... thank you for your help
jpuerta
On 3 Mar, 07:04, Matthew Peters [EMAIL PROTECTED]
wrote:
Hi, sorry to hear you are having problems
... the UK's smallest songbird, GOLDCREST.
http://www.rspb.org.uk/wildlife/birdguide/name/g/goldcrest/index.asp
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
phpsoa group.
To post to this group, send email to
are generated
fine...
We are using SCA_SDO version 1.2.4 now...
Any suggestion will be appreciated...
Thank you very much
jpuerta...
On 4 Mar, 07:06, Matthew Peters [EMAIL PROTECTED]
wrote:
Good, that sounds as if that has fixed the problem for you. How about
the second one - a blank
Hi Stefaan,
I see, you are presumably getting nothing back when you ask for the
wsdl with something like
$wsdl = file_get_contents('http://barabas.hogent.be/kariboe/
helloworld.php?wsdl');
What we need to know is what appears in the apache error log on the
server machine barabas.hogent.be (or
127.0.0.1] PHP Notice:
SDO_DataObjectImpl Object\n(\n[getDoubleReturn] = 3210.8765\n)\n
in C:\\php\\PEAR\\SCA\\Bindings\\soap\\Wrapper.php on line 97
I need to look further
On Jun 17, 1:52 pm, Matthew Peters [EMAIL PROTECTED]
wrote:
Hi Silvano,
Indeed, this is not good. I picked up the sample
Hi Caroline, thanks for a very authoritative answer, as always. The
one we are going to need to fix, of course, is the Tuscany behaviour,
and what it does on $xmldas-saveString($xdoc), since that is what we
use to generate the XML for the soap response ... unless we do some
horrid fix up of the
Hi Charlie,
There is no way to alter the xml that gets generated; this is done in
the C code inside the php_sdo extension. However, it might be that it
is not working properly, and that it should be generating the
xsi:type's - if so, we should fix it. It would help if you could point
us at the
The way I _think_ this works (though it is 2 years since I last looked
at this bit of the code) is as follows:
1. the Soap_Proxy calls setWSDLTypes
2. setWSDLTypes calls the SDO_DAS_XML::create (as shown in the message
below)
3. the SDO_DAS_XML code calls the Tuscany SDO code passing the URL
4.
OK so that's useful information and makes sense. How would you go
about connecting to an https URL from PHP? I have never tried it. Is
there a way to give the userid and password to the file wrapper?
Matthew
On 20 Nov, 20:44, Silvano Girardi Jr [EMAIL PROTECTED] wrote:
Nope.
failed to open
I wonder too. I suggest one of us put a question on one of the PHP
mailing lists, or maybe on the page to do with fopen(). Are you happy
to do that, Silvano?
Matthew
On Nov 24, 3:40 pm, Silvano Girardi Jr [EMAIL PROTECTED] wrote:
I wonder if there is any way to specify the certificate to PHP
This looks a great idea. I have just added it and checked it in. I
wasn't sure that WSDL_DIR was quite unique enough - I'd rather have it
in a namespace or an SCA at front or something - but actually I expect
it is good enough so I left it as it was.
I agree we should have a release, especially
58 matches
Mail list logo
