Dali, I am glad you told us about this in the first place as you had
uncovered a bad bug.

First of all, I made a silly mistake - I  had forgotten that I too had
removed the @types annotation and that was why it had now started
working for me. As soon as I put the @types annotation back in it
started to fail again.

It is caused a rather brittle bit of code where we have to scan a bit
of human-readable output deep inside SCA. I am not sure how long it
has been broken for, nor exactly in which cases the error occurs - it
depends on the order in which something is printed.

Anyway, I have a fix for this which I have checked in to the FULMAR
branch. I include the two changes here in case you want to apply them;

1. Fix Bindings/soap/Mapper.php by replacing the last method,
getAllTypes with this:
        public function getAllTypes()
        {
            $str   = $this->xmldas->__toString();
            $types = array();
            $line  = strtok($str, self::EOL);
            $line = strtok(self::EOL); // skip line that says this is
an SDO
            $line = strtok(self::EOL); // skip line that says nn types
have been defined

            while ($line !== false && strpos($line,'commonj.sdo')) {
                $line = strtok(self::EOL);
            }
            while ($line !== false && $line != '}') {
                $trimmed_line = trim($line);
                $words        = explode(' ', $trimmed_line);
                if ($words[0] == '-') {
                    $line = strtok(self::EOL);
                    continue;
                }
                $namespace_and_type = $words[1];
                $pos_last_hash      = strrpos($namespace_and_type,
'#');
                $namespace          = substr($namespace_and_type, 0,
$pos_last_hash);
                $type               = substr($namespace_and_type,
$pos_last_hash+1);
                if ($type != 'RootType') {
                    $types[]        = array($namespace, $type);
                }
                $line               = strtok(self::EOL);
            }
            return $types;
        }

2. In Bindings/soap/Wrapper.php
  2.1 Add an instance variable
        private $class_name                 = null;

  2.2 Initalise it in the constructor
        $this->class_name = $class_name;

  2.3 Use it inside the __call method at the bottom...replace
            $xdoc = $this->xmldas->createDocument($method_name .
"Response");
      with
            $namespace = 'http://' . $this->class_name;
            $xdoc = $this->xmldas->createDocument($namespace,
$method_name . "Response");

We will make a release with FULMAR soon. I can just zip up the SCA
directory and send it to you if you like.

We also have the fix for <wsdl:types> that you saw.

Matthew


On Jan 30, 8:29 pm, Dalibor Andzakovic <[EMAIL PROTECTED]>
wrote:
> I managed to get it going at my end too. It seemed to be the @types
> annotation that was causing grief.
>
> In the process we've had to change SCA/Bindings/soap/
> ServiceDescriptionGenerator.php to output <wsdl:types> tags instead of
> <types>, but that could just be interop issues.
>
> dali
>
> On Jan 30, 3:31 am, Matthew Peters <[EMAIL PROTECTED]>
> wrote:
>
> > Hmmm. I tried this out, started putting in a few debug lines, saw
> > exactly the same message you did, and then it went away and won't come
> > back :-). Here is what is currently working for me:
>
> > <?
> > include "SCA/SCA.php";
> > $weather = SCA::getService('servicetest.php');
> > var_dump($weather->sayHello('dali'));
>
> > //$wsdl = file_get_contents('http://localhost/bugs/bug/servicetest.php?
> > wsdl');
> > //file_put_contents('./servicetest.wsdl',$wsdl);
> > //$weather = SCA::getService('./servicetest.wsdl');
>
> > $weather = SCA::getService('http://localhost/bugs/bug/servicetest.php?
> > wsdl','soap',array('location' => 'http://localhost/bugs/bug/
> > servicetest.php'));
> > var_dump($weather->sayHello('dali'));
> > ?>
>
> > where I have renamed your servicetest4 to servicetest and as you can
> > see I have the files under htdocs at bugs/bug rather than ihug.
>
> > You'll see the three lines I have commented out where I get the wsdl
> > explicitly in one step, and write it into the directory where both the
> > test script and the server script are located. This is what I always
> > do and always works for me - write the wsdl out to a file. I suspect
> > there is something vulnerable about using http://... in the getService
> > call itself that we have never pinned down - it ought to work but
> > sometimes doesn't. The server end writes out wsdl itself if it finds
> > that there is none in the directory beside itself, and I think it's
> > possible for the wsdl at either end to get out of step if you don't
> > write it out explicitly.
>
> > Let me know how you get on.
>
> > Matthew
>
> > On Jan 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 for looking at this.
>
> > > XSD below:
>
> > > <?xml version="1.0" encoding="UTF-8"?>
> > > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";
> > >            targetNamespace="http://Weather";
> > >            elementFormDefault="qualified">
>
> > >   <xs:complexType name="PairType">
> > >     <xs:sequence>
> > >       <xs:element name="state" type="xs:string"/>
> > >       <xs:element name="temperature" type="xs:float"/>
> > >     </xs:sequence>
> > >   </xs:complexType>
>
> > >   <xs:element name="Temperatures">
> > >     <xs:complexType>
> > >       <xs:sequence>
> > >         <xs:element name="entry" type="ns1:PairType"
> > >                     maxOccurs="unbounded"/>
> > >       </xs:sequence>
> > >     </xs:complexType>
> > >   </xs:element>
>
> > > </xs:schema>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to