[phpsoa] Re: Status of issue with SDO scoping of anonymous types with same name
On 11 Feb, 18:35, cdouglas [EMAIL PROTECTED] wrote: Thank you Chris Hi Chris The Tuscany team kindly made a fix for this problem (PECL-13101). I just committed it to the FULMAR branch. Give it a spin and let me know if it works for you. If so I know Matthew wants to do a release so it can go in. 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: Status of issue with SDO scoping of anonymous types with same name
On 31 Jan, 10:33, [EMAIL PROTECTED] wrote: On 30 Jan, 14:05, cdouglas [EMAIL PROTECTED] wrote: I just grabbed the Fulmar branch and tried it and it still happens. The issue is that the items failing are defined as such: xs:element name=attribute nillable=true minOccurs=0 maxOccurs=unbounded xs:annotation xs:documentationset to nill to remove this attribute/ xs:documentation /xs:annotation xs:complexType xs:simpleContent xs:extension base=xs:string xs:attribute name=name type=xs:string use=required/ /xs:extension /xs:simpleContent /xs:complexType /xs:element and the XML looks like this scn:attribute name=ETH_GW xsi:nil=true xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance/ scn:attribute name=ETH_IP xsi:nil=true xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance/ scn:attribute name=ETH_MASK xsi:nil=true xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance/ scn:attribute name=SN xsi:nil=true xmlns:xsi=http://www.w3.org/ 2001/XMLSchema-instance/ ...etc So for each attribute that exists in the XML doc, it throws an error SDO_DAS_XML_ParserException Object ( [message:protected] = SDO_DAS_XML::loadString - Unable to parse the supplied xml string 30 parse error(s) occurred when parsing the string: 1. Parser found unknown element attribute 2. Parser found unknown element attribute 3. Parser found unknown element attribute 4. Parser found unknown element attribute 5. Parser found unknown element attribute 6. Parser found unknown element attribute ..etc I can email you the entire XSD and XML doc if the above isn't sufficient. Thank you Chris OK Chris, I'll try and take a look at the sample you posted. I'll shout if I need more. Regards Simon Chris, A bit of an update on this. It looks like a Tuscany problem so I passed the problem over there. I believe they have found the issue so I hope to see confirmation soon. I raised a bug to track it (http:// pecl.php.net/bugs/bug.php?id=13101) I'll post here again once we have something in the code base. 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: SCA not working on PHP 5.3
So you got there first! Are you exclusively on 5.3 now? 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: .NET and XSD element having a complexType
On 9 Jan, 22:02, Silvano Girardi Jr [EMAIL PROTECTED] wrote: Hi all, I am trying to use many-valued elements. They work fine when using with PHP, but when I try .NET I get the following: -- D:\wsdlwsdl.exehttp://localhost/tests/ContactService.php?wsdl Microsoft (R) Web Services Description Language Utility [Microsoft (R) .NET Framework, Version 2.0.50727.42] Copyright (C) Microsoft Corporation. All rights reserved. Error: Unable to import binding 'ContactServiceBinding' from namespace 'http://ContactService'. - Unable to import operation 'report'. - The datatype 'http://example.org:CustomerPlan'is missing. If you would like more help, please type wsdl /?. -- My XSD looks like: -- ?xml version=1.0 encoding=UTF-8? xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; targetNamespace=http://example.org; xmlns:tns=http://example.org; xs:complexType name=SinglePlan xs:sequence xs:element name=id type=xs:integer / xs:element name=name type=xs:string / /xs:sequence /xs:complexType xs:element name=CustomerPlan xs:complexType xs:sequence xs:element name=CustomerPlans type=tns:SinglePlan maxOccurs=unbounded / /xs:sequence /xs:complexType /xs:element /xs:schema -- I noticed that if I change the XSD to: -- ?xml version=1.0 encoding=UTF-8? xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; targetNamespace=http://example.org; xmlns:tns=http://example.org; xs:complexType name=SinglePlan xs:sequence xs:element name=id type=xs:integer / xs:element name=name type=xs:string / /xs:sequence /xs:complexType xs:complexType name=CustomerPlan xs:sequence xs:element name=CustomerPlans type=tns:SinglePlan maxOccurs=unbounded / /xs:sequence /xs:complexType /xs:schema -- it works fine. What can I do to make the first one work? Thanks Silvano Hi Silvano What does the XSD that uses these types look like? If you have something like xs:element name=someElement type=example:CustomerPlan / Then I would expect you to have to use the second version of the XSD. 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: Returning Data Objects to the client side
On 27 Dec 2007, 14:31, aouriques [EMAIL PROTECTED] wrote:
Hello friends,
How can I return a Data Object to the client side?
I am using the SDO_DAS_XML to create the data object but I cannot send
to the client the correct object.
I have tried this example (and a lot
others):http://www.ibm.com/developerworks/web/library/ws-soa-scasdo/index.html
My service file:
?php
include SCA/SCA.php;
/**
* @service
* @binding.soap
*
* @locationhttp://mydomain.com/SOA/Weather/WeatherService.php
* @typeshttp://Weatherhttp://mydomain.com/SOA/Weather/AreasTypes.xsd
* @typeshttp://Weatherhttp://mydomain.com/SOA/Weather/TemperaturesTypes.xsd
*/
class WeatherService {
/**
* @param Areas $Areashttp://Weather
* @return Temperatureshttp://Weather
*/
public function getTemperature($Areas) {
$Temperatures = SCA::createDataObject('http://Weather',
'Temperatures');
$Pair = $Temperatures-createDataObject('entry');
$Pair-state = 'CA';
$Pair-temperature = 65;
$Pair = $Temperatures-createDataObject('entry');
$Pair-state = 'UT';
$Pair-temperature = 105;
$Pair = $Temperatures-createDataObject('entry');
$Pair-state = 'ND';
$Pair-temperature = -20;
return $Temperatures;
}}
?
My client file:
?php
include SCA/SCA.php;
$weather = SCA::getService('http://mydomain.com/SOA/Weather/
WeatherService.php');
$Areas = $weather-createDataObject('http://Weather','Areas');
$area = $Areas-createDataObject('area');
$area-state = 'CA';
$area = $Areas-createDataObject('area');
$area-state = 'UT';
$area = $Areas-createDataObject('area');
$area-state = 'ND';
$Temperatures = $weather-getTemperature($Areas);
echo Received temperatures from Web service:br;
foreach($Temperatures-entry as $Pair)
echo $Pair-state . : . $Pair-temperature . br;
?
The AreasTypes.xsd:
?xml version=1.0 encoding=UTF-8?
schema xmlns:xs=http://www.w3.org/2001/XMLSchema;
targetNamespace=http://Weather; elementFormDefault=qualified
complexType name=StateType
sequence
element name=state type=string/
/sequence
/complexType
element name=Areas
complexType
sequence
element name=area type=ns1:StateType
maxOccurs=unbounded/
/sequence
/complexType
/element
/schema
The TemperaturesTypes.xsd:
?xml version=1.0 encoding=UTF-8?
schema xmlns:xs=http://www.w3.org/2001/XMLSchema;
targetNamespace=http://Weather; elementFormDefault=qualified
complexType name=PairType
sequence
element name=state type=string/
element name=temperature type=float/
/sequence
/complexType
element name=Temperatures
complexType
sequence
element name=entry type=ns1:PairType
maxOccurs=unbounded/
/sequence
/complexType
/element
/schema
The WSDL file:
?xml version=1.0 encoding=UTF-8?
wsdl:definitions xmlns:tns2=http://WeatherService;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/; xmlns:soap=http://
schemas.xmlsoap.org/wsdl/soap/ xmlns:xsi=http://www.w3.org/2001/
XMLSchema-instance targetNamespace=http://WeatherService;
wsdl:types
xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema;
xmlns:ns0=http://Weather;
xmlns:ns1=http://Weather;
targetNamespace=http://WeatherService;
elementFormDefault=qualified
xs:import schemaLocation=http://mydomain.com/SOA/Weather/
AreasTypes.xsd namespace=http://Weather/
xs:import schemaLocation=http://mydomain.com/SOA/Weather/
TemperaturesTypes.xsd namespace=http://Weather/
xs:element name=getTemperature
xs:complexType
xs:sequence
xs:element name=Areas type=ns1:Areas/
/xs:sequence
/xs:complexType
/xs:element
xs:element name=getTemperatureResponse
xs:complexType
xs:sequence
xs:element name=getTemperatureReturn
type=ns1:Temperatures/
/xs:sequence
/xs:complexType
/xs:element
/xs:schema
/wsdl:types
wsdl:message name=getTemperatureRequest
wsdl:part name=getTemperatureRequest
element=tns2:getTemperature/
/wsdl:message
wsdl:message name=getTemperatureResponse
wsdl:part name=return element=tns2:getTemperatureResponse/
/wsdl:message
wsdl:portType name=WeatherServicePortType
wsdl:operation name=getTemperature
wsdl:input message=tns2:getTemperatureRequest/
wsdl:output message=tns2:getTemperatureResponse/
/wsdl:operation
/wsdl:portType
wsdl:binding name=WeatherServiceBinding
type=tns2:WeatherServicePortType
[phpsoa] Re: Extending the restrpc binding output data
On 22 Nov, 12:57, Tom [EMAIL PROTECTED] wrote: Simon, Great thing you like the idea. Some new thoughts below. On 22 Nov, 11:50, Simon Laws [EMAIL PROTECTED] wrote: Currently the restrpc binding will only return data in XML format. Unless anyone has a better suggestion we will be extending our installation of phosoa to check the Accept header of the client to determine the format of return data. Sounds like a good idea to me. There is the opportunity in restrpc/Server.php to convert the response into the required output format so I think this will work. Using only the header turns out to be impractical when calling the API from a browser based script when not using the XMLHTTPRequest object, since it's then not possible to modify the request header in any way. My suggestion is to, instead of looking at the accept header, or as an override possibility, add an optional parameter after the method name: That would make these calls valid: /MyService.php/myMethod/json?a=bc=a returns JSON /MyService.php/myMethod/xml?a=bc=a returns XML /MyService.php/myMethod?a=bc=a returns XML for backwards compatibility Regards /Tom Hi Tom If you can't manipulate the accept headers can you use the JSONRPC binding which will return JSON formatted messges? Looking at the code it seems that the JSONRPC binding will only handle POST requests in JSON format at the moment. There is a TODO about parsing GETs but the code from the RESTRPC binding could be used here to get the effect I think you are after. I.e. HTTP params in, JSON out. If that isn't a viable alternative then I don't have a particular objection to adding the path info. I'd like to understand a little more about the problem setting accept headers though as that sounded like a neater solution. What mechanism are you using for making the calls from the browser? 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: How can I access a property containing a hyphen (i.e. portfolio-id)
On 9 Nov, 21:21, [EMAIL PROTECTED] wrote:
On 9 Nov, 20:16, Harm Bandstra [EMAIL PROTECTED] wrote:
Hello All,
I'm not sure if this is the right place for my question, but here
goes...
I have an XSD file with properties containing hyphens. I can't get it
to accept any changes to the properties. In part this is because php
doesn't accept hypens in variable names, but I found that Simple-XML
uses some sort of work around. I have the following php code:
===
$xmldas = SDO_DAS_XML::create('xsd/pre_qual_wso.xsd');
$messagebody = $xmldas-createDataObject('','MessagebodyType');
// This gives a syntax error (duh)
$messagebody-portfolio-id = 'BST';
// These 2 give the following error:
// Problem creating an XML document: DataObjectImpl::setSDOValue -
path not found:
$messagebody['portfolio-id'] = 'BST';
$messagebody[0]= 'BST';
// This is the way it's done in simple-xml, but also doesn't work
$messagebody-{'portfolio-id'} = 'BST';
===
Can it be done? Any help will be appreciated.
Kind regards,
Harm Bandstra
Hi Harm
Yep, you found the right place to ask the question. I don't know the
answer off the top of my head and I'm in the middle of rebuilding my
PHP environment today so I'll take a look when I get it sorted. Sorry
about the slight delay. I'll get back to you shortly.
In the mean tim, if anyone else knows the answer feel free to jump
in:-)
Regards
Simon
Hi Harm
Sorry this took me a while to get to. Have just managed to get my dev
environment up on my new machine following the demise of my old one.
The reason that this is failing is that the Tuscany SDO implementation
that we rely on for SDO support doesn't recognize the - character as
a valid character in a name. I think that it should in as much that it
is a valid name character [1]. Can you raise a bug report on this and
I'll log it in Tuscany and make a change. I can make the change
locally on PECL in the first instance. If people have doubts about
this then let me know.
Thanks
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: Finer-grained control over service methods (Pecl Request #11944)
On 8 Sep, 09:30, Graham Charters [EMAIL PROTECTED] wrote:
Just a quick status update...
I've done the code to optionally allow an interface to be specified
and tested this independent of a protocol binding and all works fine.
Unfortunately, when called from a remote invocation, the classexists
tests for the service implementation fails. Get_declared_classes()
confirms that it does not have the definition and
get_declared_interfaces() confirms that it knows about the
interfaces. Removing the interfaces makes everything work as before,
so it appears to be a PHP nit.
I'm going to try to create a little test case to reproduce this
outside SCA. If anyone has heard of anything which might be relevant,
please let me know.
Graham.
On 3 Sep, 13:18, Graham Charters [EMAIL PROTECTED] wrote:
It sounds like we may have consensus. To summarise:
1. We should add the ability to specify an optional interface for the
service on the @service annotation (e.g. @service
MyServiceInterface). This would only be used to limit the methods
exposed by the service, so we would not look for any other metadata in
the interface (we could support this later).
2. We should not include methods in service descriptions which have
not been appropriately documented (this is to avoid generating duff
services descriptions, and is not meant to be used as a means of
controlling the service interface).
Hopefully I'll be able to take a look at 1 sometime towards the end of
this week, unless someone else is itching to do it :-D
Graham.
On 31 Aug, 15:03, Matthew Schultz [EMAIL PROTECTED] wrote: Actually
after a second glance, I see all annotations are still set in
the class. It probably wouldn't make any sense to have SCA parse
annotations in the interface.
Matt
On 31 Aug, 06:20, Graham Charters [EMAIL PROTECTED] wrote: Comments
inlined below...
On 31 Aug, 11:35, [EMAIL PROTECTED] wrote:
Hi Graham
Some more comments in line...
On 31 Aug, 11:26, Graham Charters [EMAIL PROTECTED] wrote:
Hi Simon, thanks for the rapid comments. Here's my thoughts on the
two issues you identified:
1/ What should SCA do if it finds a method without annotations,
i.e.
no type information
This probably depends on the type of service. Service types which
don't have a service description (e.g. local, REST and Atom), don't
require this information to be specified. Service types which do
have
service descriptions (soap, json-rpc, xml-rpc), do (to varying
degrees).
I think if the binding type requires documentation then we should
warn
and not generate (rather than generating something which is of no
use). If the binding type doesn't require documentation then it's
included.
2/ How can methods be omitted from the service interface, i.e. we
just
don't want to expose the method
I don't think the absence of comments should be used as a control
mechanism for the reason you and Matt have already highlighted
(might
want to document something but still not have it on the service
interface).
I quite like the idea of using interfaces to add this level of
control. It would also be consistent with SCA (SCA Java does this
and
also supports the same class implementation approach we use (i.e.
where there is no interface)). How about something like:
/**
* Scaffold implementation for a remote StockQuote Web service.
*
* @service StockQuoteInterface
* @binding.soap
*
*/
StockQuoteImpl implements StockQuoteInterface, ANOtherInterface {
...
}
So I like @service StokeQuoteInterface
If you are suggesting that we can parse the StockQuoteInterface to
pull out the method names which should be provided as service
interfaces (without the need for further annotation on the interface
itself) then this could work. My approach was a contraction of this by
just providing the method names after the interface name in the
annotation but your approach is more forward thinking.
We should be able to update this in SCA_AnnotationReader.php. I
believe all the information is available through Reflection. You can
call getInterfaces() on the ReflectionClass, which returns an array of
ReflectionClass objects, one for each interface. I don't think we
would require further annotations in the interface, but we will need
to decided whether to use annotations/documentation in an interface if
it is provided.
Presumably the default would be to provide all methods if no interface
is described.
Yes, so this would be backwards compatible.
This would be taken to mean that only those methods defined on
StockQuoteInterface are part of the soap service. Those in
[phpsoa] Re: about JMS Binding
On 10 Sep, 15:04, Jack Zai [EMAIL PROTECTED] wrote: Hi Simon i've fixed the tests, and made a new patch against FULMER with all of the changes. Thanks Jack On 31 Aug, 10:01, [EMAIL PROTECTED] wrote: On 25 Jul, 17:02, Jack Zai [EMAIL PROTECTED] wrote: Hi Simon, I checked out the code from EIDER branch, and made some changes. Also I wrote some test cases for the message binding. I've just uploaded a patch file patch.txt, which includes the changes and test cases. Thanks Jack On Jul 24, 9:33 am, [EMAIL PROTECTED] wrote: On 9 Jul, 14:57, Jack Zai [EMAIL PROTECTED] wrote: My binding is not only a proxy to a JMS service, but also for exposing a RPC-style message service. For example, assume we have a SCA file MyService.php with soap binding. We can replace the annotation @binding.soap with @binding.ms plus some config information about the target queue. Now, if we issue command php MyService.php, the service will be started by running a listener to the target queue. then incoming JMS messages at the target queue will be processed by the wrapper and pass on to appropriate operation of the service. So in this case, the message sender could be a non-SCA JMS client. In addition, I am sorry for the wrong link to the spec, which should be as below : [pdf]http://www.osoa.org/download/attachments/35/SCA_JMSBinding_V100.pdf?v... On 6 Jul, 17:04, Caroline Maynard [EMAIL PROTECTED] wrote: Jack Zai wrote: Unlike any of other bindings, where an http server is used for listening to the ports, for the ms binding, a service is started from a console (e.g. php myservice.php). Once the service is started, it will keep trying to get message from the queue, and it can be terminated by pressing Ctrl + C. Can you explain a bit more? In an enterprise environment I would imagine the JMS service being started by some mechanism outside the scope of your binding. So your command-line service, is that just a way to bootstrap a JMS service locally? I'm assuming that your SCA binding is a client only, that is, it provides an SCA proxy to a remote JMS service, but not a wrapper for a local service to be exposed to non-SCA JMS clients. Is that right? Hi Jack Sorry this took such a long time for me to get to. I've just checked your code in. Thank you. I've changed the binding name from ms to message. I think the latter is a little more meaningful. I've fixed up the class names etc but am unable to run/test it as there are no test cases included Based on the checked in code can you construct some test cases fur us? Also I've created a new link on the web site [1] for the documentation for this binding. If would be great if you could write a few words describing how to use the binding and what its various features are. We can then put that up there. Regards Simon [1]http://www.osoa.org/display/PHP/SCA+with+PHP-Hidequotedtext - - Show quoted text - Jack, sorry this took me a month to get to. Heads down doing Java releases. Anyhow I have applied the patch locally and am seeing notices when I run the tests which I assume are because I haven't yet configure SAM in my PHP installation.. ...I...I...PHP Notice: Use of undefined constant SAM_HOST - assumed 'SAM_HOST' in C:\simon\Projects\Tuscany\php\branch-build\pecl\sdo \tests\SCA\php unit\MessageBinding\MSTest.php on line 46 PHP Notice: Use of undefined constant SAM_PORT - assumed 'SAM_PORT' in C:\simon \Projects\Tuscany\php\branch-build\pecl\sdo\tests\SCA\phpunit \MessageBinding\MST est.php on line 46 PHP Notice: Use of undefined constant SAM_BROKER - assumed 'SAM_BROKER' in C:\s imon\Projects\Tuscany\php\branch-build\pecl\sdo\tests\SCA\phpunit \MessageBinding \MSTest.php on line 46 PHP Notice: Use of undefined constant SAM_ENDPOINTS - assumed 'SAM_ENDPOINTS' i n C:\simon\Projects\Tuscany\php\branch-build\pecl\sdo\tests\SCA\phpunit \MessageB inding\MSTest.php on line 46 PHP Notice: Use of undefined constant SAM_TARGETCHAIN - assumed 'SAM_TARGETCHAI N' in C:\simon\Projects\Tuscany\php\branch-build\pecl\sdo\tests\SCA \phpunit\Mess ageBinding\MSTest.php on line 46 PHP Notice: Use of undefined constant SAM_BUS - assumed 'SAM_BUS' in C:\simon\P rojects\Tuscany\php\branch-build\pecl\sdo\tests\SCA\phpunit \MessageBinding\MSTes t.php on line 46 PHP Notice: Use of undefined constant SAM_USERID - assumed 'SAM_USERID' in C:\s imon\Projects\Tuscany\php\branch-build\pecl\sdo\tests\SCA\phpunit \MessageBinding \MSTest.php on line 46 PHP Notice: Use of undefined constant SAM_PASSWORD - assumed 'SAM_PASSWORD' in C:\simon\Projects\Tuscany\php\branch-build\pecl\sdo\tests\SCA\phpunit \MessageBin
[phpsoa] Re: json rpc patch
On 7 Aug, 11:20, [EMAIL PROTECTED] wrote: On 7 Aug, 10:55, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: The patch I have uploaded includes a change to see whether the $content_type variable contains the string application/json-rpc rather than checking whether it is equal to it. The patch will change the file pecl/sdo/SCA/Bindings/jsonrpc/ RequestTester.php Thanks Tom. I'll take a look at it a bit later. Simon Tom, thank you for the patch. I've now applied it to the FULMER branch. 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: Finer-grained control over service methods (Pecl Request #11944)
Hi Graham
Some more comments in line...
On 31 Aug, 11:26, Graham Charters [EMAIL PROTECTED] wrote:
Hi Simon, thanks for the rapid comments. Here's my thoughts on the
two issues you identified:
1/ What should SCA do if it finds a method without annotations, i.e.
no type information
This probably depends on the type of service. Service types which
don't have a service description (e.g. local, REST and Atom), don't
require this information to be specified. Service types which do have
service descriptions (soap, json-rpc, xml-rpc), do (to varying
degrees).
I think if the binding type requires documentation then we should warn
and not generate (rather than generating something which is of no
use). If the binding type doesn't require documentation then it's
included.
2/ How can methods be omitted from the service interface, i.e. we just
don't want to expose the method
I don't think the absence of comments should be used as a control
mechanism for the reason you and Matt have already highlighted (might
want to document something but still not have it on the service
interface).
I quite like the idea of using interfaces to add this level of
control. It would also be consistent with SCA (SCA Java does this and
also supports the same class implementation approach we use (i.e.
where there is no interface)). How about something like:
/**
* Scaffold implementation for a remote StockQuote Web service.
*
* @service StockQuoteInterface
* @binding.soap
*
*/
StockQuoteImpl implements StockQuoteInterface, ANOtherInterface {
...
}
So I like @service StokeQuoteInterface
If you are suggesting that we can parse the StockQuoteInterface to
pull out the method names which should be provided as service
interfaces (without the need for further annotation on the interface
itself) then this could work. My approach was a contraction of this by
just providing the method names after the interface name in the
annotation but your approach is more forward thinking.
Presumably the default would be to provide all methods if no interface
is described.
This would be taken to mean that only those methods defined on
StockQuoteInterface are part of the soap service. Those in
ANOtherInterface or just in StockQuoteImpl would be excluded. I'd
prefer to pursue this approach rather than creating a new annotations
which may go away in the near future.
Does this make sense and seem sensible?
On 31 Aug, 09:30, [EMAIL PROTECTED] wrote:
On 31 Aug, 08:42, Graham Charters [EMAIL PROTECTED] wrote:
Pecl Request #11944 (http://pecl.php.net/bugs/bug.php?id=11944) is
asking for finer-grained control over the methods which are surfaced
on a service interface. We currently just use class visibility (i.e.
all public methods) to control this.
There's a small amount of discussion in the request, but I thought it
would be good to raise it here to get greater visibility and gather
more options/opinions.
Graham.
Following up on the comments made in the feature request...
It is true that in the Java SCA implementation the @Service
information is associated with interfaces so a class will implementat
one, or more, interfaces and this tells the runtime which methods of
the class should be treated as service methods.
This is not currently how the PHP SCA implementation works. All
annotations are placed on the class itself. This leads to a level of
simplicity in service construction but we pay for this in lack of
flexibility, for example, in excluding some methods from the service
interface. At least given the set of annotations we have at the
moment.
Having said this I'm not convinced that the use of unannotated (is
that a word?) methods as part of the service interface makes a lot of
sense give the way that the implementation works at the moment. If you
look at what is actually generated in the WSDL in the case of the
method function foo($bar) in the feature request it doesn't seem to
be that useful. I.e. it defines null input and output types. I assume
this is because there are no annotations for SCA to use for typing the
interface. Fine for PHP but not so great for a service interface.
So there are two issues here
1/ What should SCA do if it finds a method without annotations, i.e.
no type information
2/ How can methods be omitted from the service interface, i.e. we just
don't want to expose the method
As first suggested we could omit methods that don't have comments at
all.. However this is problematic for issue 2 as annotations may have
been included for producing the documentation that the annotations
were originally designed for. However I think we should consider
omitting methods without annotations due to issue 1 so this could be a
short term solution 2.
Following the conversation on for issue 2. Maybe, as an alternative to
@scaExcludeMethod we could defined some new annotation for the
[phpsoa] Re: Real world SDO/SOA examples
On 6 Aug, 02:55, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I've been reading a bit about SDO recently and using it with PHP and have just started trying to put it to use. Apart from building a slightly more complex version of the tutorials/demos I am really stuck. My question really is: Does anyone know of any open source projects that leverage SDO? Or is anyone writing about how SDO can fit into your overall architecture? I really see gaps in how SDO fits into business logic and how object selection works. Maybe this is me not searching hard enough or maybe it's the documentation not being complete enough. Hi To get straight to your specific question about projects using SDO. There are a few people on this list who have been using SDO on its own. However I think the real advantage of SDO isn't clear until you start programming with services. By services I mean any program or script that has a well defined interface/function and that you might want to access remotely or that you might want to provide for others to access (I'm sure that's not the best description of what services are all about but it works for this conversation). If I write a PHP service that talks SOAP then I might fire up the SOAP extension, read in some WSDL and, with simple type parameters I'm good to go. With complex type parameters, e.g. objects and arrays, it's a little harder but not too hard to get it going. Now if I want to do the same thing with, say JSONRPC or XMLRPC, for example, I have to fire up a different set of APIs and work out how to shuffle my data in and out of the the remote method calls. Again not hard but different. We have used SDO in the SCA implementation to abstract this away so that service methods deal in SDOs and service clients call remote methods using SDOs. As we have a common format for data (SDO) a programmer can switch bindings will with very little, if any, change to the actual business logic. The SDOs are converted to the correct format for the protocol in use, e.g. XML for SOAP and JSON for JSONRPC. Both ends of the client/service connection are not forced to both use SDOs but they could. SDO allows us to do this as the concept of the Data Access Service allows the data in memory in an SDO to be converted into the correct format. Now SDO isn't the only way of doing this kind of thing, for example, in the Tuscany Java implementation of SCA users can use several different approaches to representing data depending on what they are most familiar with, for example, SDO, JAXB, XML Beans. I'd like to see a similar flexibility in PHP SCA, for example, by allowing PHP Objects to be used alongside SDO but we haven't had the bandwidth to support that. As SDO is a fairly widely recognized way of representing data another advantage is that implementations are available in various languages, e.g. PHP, Java, C++. This gives some consistency to the way you treat data if you have people who have to work in these different environments. I'd be interested to understand the gaps you talk about and maybe we can fill in some of them. All help is gratefully received of course. Hope that helps 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: ATOMPUB binding
On 17 Jul, 10:08, Matthew Peters [EMAIL PROTECTED] wrote: 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 by +1 checking it into PECL cvs sounds like a good idea to me. 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: about JMS Binding
On 6 Jul, 13:28, Jack Zai [EMAIL PROTECTED] wrote: Unlike any of other bindings, where an http server is used for listening to the ports, for the ms binding, a service is started from a console (e.g. php myservice.php). Once the service is started, it will keep trying to get message from the queue, and it can be terminated by pressing Ctrl + C. Reply to information is provided by the client using the 'scaCallbackQueue' user property or the JMSReplyTo header, in other words the name of the reply-to-queue should be found in the message's header. And the client can change its reply-to-queue at any time by calling setReplyQueue method. $service-setReplyQueue(queue://OrderResponse) However, according to the spec, the reply to information does not contain any information about the message provider (e.g. host, port ...). so I have to assume the reply-to queue is in the same broker of the service queue. At moment, my solution is implemented in a synchronous manner. A reference is expecting the response immediately after a request being sent. I think we have many options to achieve asynchronous communication, but I am not sure how users want it be done, that is one of the points we need to discuss more about. Currently a client or a reference can tell the proxy not to expect response by calling setWaitResponseTimeout(-1) to a negative value. Answer to the last question is no, you can not receive messages from service implementation. Actually I don't see why you need to, as that would cause problems if later you want to expose it as soap or another service. Finally, I singed CLA a few days ago and I am happy to join you as a contributor. Jack On Jul 5, 6:41 pm, Simon Laws [EMAIL PROTECTED] wrote: On 7/5/07, Jack Zai [EMAIL PROTECTED] wrote: Hi, I am developing a JMS binding and would like to discuss some of the work i've done. basically, a message service listens to a queue at some JMS message provider e.g. ActiveMQ or IBM Websphere MQ. And a client or a reference can invoke the service's method by sending message to its destination queue, and receive the response from a call back queue, which can be provided at runtime by the client. I found there is an existing specification for SCA JMS Binding [1] from OSOA. This spec describes stuff like when receiving a request which method should be invoked, and how the data/parameters are packed into a JMS Message. I've already implemented section 1.5 and section 1.7.2 of that spec, and have some thoughts about the conversations (section 1.7.3), but not yet implemented. In addition, my solution requires another pecl extension SAM [2] for connecting to the message providers. The reason of choosing SAM is because that SAM provides one API for different messaging infrastructures, and also provides a generic extension mechanism which makes it easy to add new support. Currently SAM only supports XMS[3] for IBM products and MQTT, but I've also developed a new Stomp support for Active MQ, which will be included to the next release of SAM very shortly. If anyone is interested in the JMS binding or have any questions, please join the discussion here. Jack Zai [1] SCA JMS Binding V1.00 (PDF) http://www.osoa.org/download/attachments/35/SCA_AssemblyModel_V100.pd... [2] SAM - Simple Asynchronous Messaging for PHP (http://pecl.php.net/ package/sam) [3] XMS - http://www.ibm.com/developerworks/websphere/library/techarticles/0509... Hey Jack, that sounds really cool. A couple of questions. - How does a service listen to message queues. I.e. is there really a listener or do you rely on user events before going and reading input queues? - Does the service take notice of the reply to information that can appear in messages? - How does a reference generate reply to information - What does it mean to have a reference defined with a ms binding. Does it mean calls through that reference will be synchronous, asynchronous or do I get to choose. - Is there a way I can programmatically receive messages from within a service implementation. It would be really good to get a look at the code. I'm not sure what the process is for getting it from you. Have you signed a project Contributor License Agreement (CLA) to indicate that you are free to give us the code and are happy for us to use it? If you have we could transfer it via the files section of the group but I notice that it's set at the moment so that only managers can upload files. We could do that via email and have one of the maintainers patch the code into the branch for all to see. But what does everyone think about how we should handle contributions like this. Should we have a separate place where people can put contributions (like the file section of the google group)? Regards Simon- Hide quoted text - - Show quoted text - Thanks for the
[phpsoa] Re: about JMS Binding
...snip On 6 Jul, 16:31, Jack Zai [EMAIL PROTECTED] wrote: I've uploaded my code as an archive file - ms.zip. Jack Thanks Jack, I see it. I'll take a look. 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
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: New article about SCA and SDO
On 5 Jul, 14:15, Matthew Peters [EMAIL PROTECTED] wrote: Thanks for spotting that. What a nice article it is! I am very impressed - it seems no matter how neglectful any of us have been about the documentation (for example I only just got round to changing @binding.ws for @binding.soap in the docs), Tyler Anderson has deciphered what we have been up to and made it all look slick and smooth. Matthew Good spot Caroline, have added it to the places that talk about us list. 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] Service that implement interfaces?
It would seem to be the case that if you implement a service using a
class that implements an interface then SCA doesn't recognize it as a
service. For example, with the service:
/**
* @service
* @binding.restresource
* @types urn::orderNS Orders.xsd
*/
class Orders implements SCA_Bindings_restresource_ResourceTemplate
{
I get the
SCA::initComponent - included by a client script that is not a
component In the log. Am just investigating now but I'm assuming this
is not by design.
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] Release Announcements
I've just been doing a Tuscany blog post about the 1.2.2. release. I notice that the release announce didn't go out on the PECL dev list. There appears to be a problem with the process. Wez is looking into it see [1]. Where else can we make the release annouce so that people see it as they aren't getting the info through PECL dev at the moment? Regards Simon [1] http://www.nabble.com/PECL-release-announcements-tf3996552.html --~--~-~--~~~---~--~~ 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] View this page Contents of Release From EIDER Branch
Created next release contents page Click on http://groups.google.com/group/phpsoa/web/contents-of-release-from-eider-branch - or copy paste it into your browser's address bar if that doesn't 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 -~--~~~~--~~--~--~---
[phpsoa] Tuscany SDO code branch
For information... The Tuscany SDO team have branched the SDO C++ code tree to allow them to start tidying their iterfaces w.r.t to the SDO C++ specification while still supporting the set of interfaces we currently use. See the thread here (http://www.mail-archive.com/tuscany-dev %40ws.apache.org/msg19239.html) for discussion on the branch. I expect we will either have to petition for the specified interface to be extended or change the way that we use Tuscany SDO in order to move back onto the trunk code. 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: DUNLIN RC2
On 21 Jun, 22:40, Graham Charters [EMAIL PROTECTED] wrote:
Hi Matthew,
Thanks for fixing the wsdl schema fetching problem and spinning RC2.
It all looks good to me on Windows. Unit tests all pass (phpt and
phpunit). Service generation for wsdl, xmlrpc and jsonrpc all work.
Json-rpc mail example runs. Ebay soap example runs and caching works.
Regards,
Graham.
On 21 Jun, 16:24, Simon Laws [EMAIL PROTECTED] wrote:
On 6/21/07, Matthew Peters [EMAIL PROTECTED] wrote:
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 following compromise:
if (strstr(file_name,2003-02-11.xsd)) {
xmldas-xsdHelperPtr-defineFile(file_name, false);
} else {
xmldas-xsdHelperPtr-defineFile(file_name, true);
}
i.e., for our soap and wsdl xsds, don't go out, for others, do.
Ok, Matthew, pragmatic as ever. It looks like the real fix is going to
take a little time. Thanks for respinning the RC.
Simon
On FC6 I see 5 unit test failures and 1 phpt failure. They seem to be
to do with modification of the order of namespace definitions on
generated XML, for example,
5) testGETForm(SCA_RestRpcTest)
Failed asserting that text is equal to text.
--- Expected
+++ Actual
@@ -1,2 +1,2 @@
?xml version=1.0 encoding=UTF-8?
-HelloType xsi:type=HelloType xmlns:tns=http://www.example.org/
Hello xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns=http://www.example.org/Hello;namename/namegreetingHello
Fred/greetingreversedderF olleH/reversed/HelloType
+HelloType xmlns=http://www.example.org/Hello; xsi:type=HelloType
xmlns:tns=http://www.example.org/Hello; xmlns:xsi=http://www.w3.org/
2001/XMLSchema-instancenamename/namegreetingHello Fred/
greetingreversedderF olleH/reversed/HelloType
/usr/local/lib/php/test/SCA_SDO/tests/SCA/phpunit/RestRpc/
RestRpcTest.php:95
/usr/local/lib/php/test/SCA_SDO/tests/TestSuite.php:41
/usr/local/lib/php/test/SCA_SDO/tests/TestSuite.php:58
/usr/local/lib/php/test/SCA_SDO/tests/AllTests.php:28
I'm assuming this is to do with the WSDL validation changes but I
thought the test expect results had caught up with this. They don't
stop the samples running though.
I also have a problem running one of the JSONRPC samples which I think
is a configuration problem. Give me a little time to investigate this.
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: DUNLIN RC2
On 22 Jun, 10:13, Graham Charters [EMAIL PROTECTED] wrote:
So there is :-) . Strange this it's just the order in which the
xsi:type and xmlns:tns are written out. Given that, I would say it's
good to go, but we need to get to the bottom of why the order is
different between Windows and Linux to avoid this in future releases.
Agree? Disagree?
Graham.
On 22 Jun, 09:42, [EMAIL PROTECTED] wrote:
On 22 Jun, 09:14, Graham Charters [EMAIL PROTECTED] wrote:
Hi Simon, can you post what you're seeing for one of the failing unit
test for comparison?
Graham.
On 22 Jun, 09:08, [EMAIL PROTECTED] wrote:
On 22 Jun, 08:39, [EMAIL PROTECTED] wrote:
On 21 Jun, 22:40, Graham Charters [EMAIL PROTECTED] wrote:
Hi Matthew,
Thanks for fixing the wsdl schema fetching problem and spinning RC2.
It all looks good to me on Windows. Unit tests all pass (phpt and
phpunit). Service generation for wsdl, xmlrpc and jsonrpc all work.
Json-rpc mail example runs. Ebay soap example runs and caching
works.
Regards,
Graham.
On 21 Jun, 16:24, Simon Laws [EMAIL PROTECTED] wrote:
On 6/21/07, Matthew Peters [EMAIL PROTECTED] wrote:
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 following compromise:
if (strstr(file_name,2003-02-11.xsd)) {
xmldas-xsdHelperPtr-defineFile(file_name, false);
} else {
xmldas-xsdHelperPtr-defineFile(file_name, true);
}
i.e., for our soap and wsdl xsds, don't go out, for others, do.
Ok, Matthew, pragmatic as ever. It looks like the real fix is
going to
take a little time. Thanks for respinning the RC.
Simon
On FC6 I see 5 unit test failures and 1 phpt failure. They seem to be
to do with modification of the order of namespace definitions on
generated XML, for example,
5) testGETForm(SCA_RestRpcTest)
Failed asserting that text is equal to text.
--- Expected
+++ Actual
@@ -1,2 +1,2 @@
?xml version=1.0 encoding=UTF-8?
-HelloType xsi:type=HelloType xmlns:tns=http://www.example.org/
Hello xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns=http://www.example.org/Hello;namename/namegreetingHello
Fred/greetingreversedderF olleH/reversed/HelloType
+HelloType xmlns=http://www.example.org/Hello; xsi:type=HelloType
xmlns:tns=http://www.example.org/Hello; xmlns:xsi=http://www.w3.org/
2001/XMLSchema-instancenamename/namegreetingHello Fred/
greetingreversedderF olleH/reversed/HelloType
/usr/local/lib/php/test/SCA_SDO/tests/SCA/phpunit/RestRpc/
RestRpcTest.php:95
/usr/local/lib/php/test/SCA_SDO/tests/TestSuite.php:41
/usr/local/lib/php/test/SCA_SDO/tests/TestSuite.php:58
/usr/local/lib/php/test/SCA_SDO/tests/AllTests.php:28
I'm assuming this is to do with the WSDL validation changes but I
thought the test expect results had caught up with this. They don't
stop the samples running though.
I also have a problem running one of the JSONRPC samples which I think
is a configuration problem. Give me a little time to investigate this.
Simon
So I have all the examples running ok now (was a curl config issue) so
there can't be much wrong with it. Unit tests still fail. I can't just
go fix the expected output for the tests though if you are not seeing
these failures so I would like to know why our platforms are producing
different output. Here's what I'm running.
Fedora Core 6
PHP 5.2.0
libxml 2.6.29
Simon
Simon
There is one in my original post
I've just tried the code on Windows and it does get a clean bill of
health for me. So I've raised http://pecl.php.net/bugs/bug.php?id=11401
but yes +1 for going with RC2.
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] Results of fixing up the schema loading problem
I have a fix for the extra calls to the network that C++ SDO seems to be making when loading the WSDL schema. I tested the fix with the C++ SDO tests and it's OK. I applied the fix to my local copy of DUNLIN. Test 04 runs fine now. However the testSOAP XML DAS unit test now fails with the same error. I don't remember this failing before I'm guessing that this is the first place that we try and read the schema using the namespace. I have another thread started re. the likely implications of the change for type loading so I'll wait to see what comments come back before committing. 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: DUNLIN RC1 testing
Thanks for trying that Graham. I've fix a few more things.. 1/ I've fixed the case of the Helloworld.php?smd reference 2/ examples/SDO/rss-media missing. I didn't get a response to this so I have removed the example from the examples/SDO/index.htm. 3/ I've put an example of how tests can be skipped into the ebay binding test. This relies on a method in the proxy for that binding which performs the dependency check, so that we only have the check coded in one place. The proxy is not the ideal place for this but it is one of the few classes all bindings have. I'm tempted to create a specific class for this tests that all bindings can implement. Thoughts? So the failing test 4 is the last thing to fix. --~--~-~--~~~---~--~~ 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: DUNLIN RC1 testing
On 19 Jun, 10:47, [EMAIL PROTECTED] wrote: Thanks for trying that Graham. I've fix a few more things.. 1/ I've fixed the case of the Helloworld.php?smd reference 2/ examples/SDO/rss-media missing. I didn't get a response to this so I have removed the example from the examples/SDO/index.htm. 3/ I've put an example of how tests can be skipped into the ebay binding test. This relies on a method in the proxy for that binding which performs the dependency check, so that we only have the check coded in one place. The proxy is not the ideal place for this but it is one of the few classes all bindings have. I'm tempted to create a specific class for this tests that all bindings can implement. Thoughts? So the failing test 4 is the last thing to fix. I've looked close at test 04 and it does only fail when it's run from run-tests. If I use run-tests with -verbose and cut the command out that it says it's using that that works OK. So it looks like it's something about the environment it's creating to run the tests in. As an aside there is a question of why it is apparently (don't really know that it actually is - error message appears to imply this) going out across the network to fetch the WSDL schema in this case. Has there been a regression in the bit of Tuscany that prevents it from doing this when it already knows about the namespace? I've re-run the RC1 tests on Linux and they are fine, this is OK on windows except inside the phpt run-tests. It needs sorting out but I don't think we should delay the next RC for it. Thoughts? 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: DUNLIN RC1 testing
On 19 Jun, 18:11, Matthew Peters [EMAIL PROTECTED] wrote: 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 forhttp://schemas.xmlsoap.org/wsdl/: .br / bWarning/b: SDO_DAS_XML::create(http://schemas.xmlsoap.org/wsdl/) [a href='function.SDO-DAS-XML-create'function.SDO-DAS-XML-create/ a]: failed to open stream: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. in bC:\php\PEAR\SCA\Bindings\soap\ServiceDescriptionGenerator.php/ b on line b65/bbr / br / bWarning/b: SDO_DAS_XML::create() [a href='function.SDO-DAS-XML- create'function.SDO-DAS-XML-create/a]: I/O warning : failed to load external entity quot;http://schemas.xmlsoap.org/wsdl/in bC: \php\PEAR\SCA\Bindings\soap\ServiceDescriptionGenerator.php/b on line b65/bbr / So is this definitive proof that the fix in Tuscany is not preventing SDO from chasing URLs even when it has the types to hand? 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: DUNLIN RC1 testing
On 18 Jun, 10:56, Matthew Peters [EMAIL PROTECTED]
wrote:
SCA_SDO-1.2.2.tgz - the version that Simon has been using above, no
fixes yet - is now in the files section.
OK, I've done the easy fixes in DUNLIN. I've also overhauled the
installation instruction so if people could go and review them that
would be good.
Things left to do If any one fancies taking a look
1/ examples/SCA/helloworldscajsonrpc/ there is a issue with the case
of Helloworld.php. For some reason I can't spot what I thought was
wrong with this one.
2/ examples/SDO/rss-media missing. It's in the branch so we either
need to ship it or remove the example from the examples/SDO/index.htm.
Is there a good reason why we don't ship it?
3/ I haven't done any of the suggested skipping stuff in the unit
tests. Not essential for this release but a nice to have.
4/ phpt tests 4 and 13 fail for me. I'm looking at 4 now.
001+ Warning: SDO_DAS_XML::create(): php_network_getaddresses:
getaddrinfo failed: No such host is known. in C:\simon\Projects
\Tuscany\php\branch-build\pecl\sdo\SCA\Bindings\soap
\ServiceDescriptionGenerator.php on line 65
002+
003+ Warning: SDO_DAS_XML::create(http://schemas.xmlsoap.org/wsdl/):
failed to open stream: No such file or directory in C:\simon\Projects
\Tuscany\php\branch-build\pecl\sdo\SCA\Bindings\soap
\ServiceDescriptionGenerator.php on line 65
004+
005+ Warning: SDO_DAS_XML::create(): I/O warning : failed to load
external entity http://schemas.xmlsoap.org/wsdl/; in C:\simon\Projects
\Tuscany\php\branch-build\pecl\sdo\SCA\Bindings\soap
\ServiceDescriptionGenerator.php on line 65
006+
007+ Fatal error: Uncaught exception 'SDO_DAS_XML_ParserException'
with message 'SDO_DAS_XML::create - Unable to parse the supplied xsd
file
008+ 1 parse error(s) occurred when parsing the file 'C:\simon\Projects
\Tuscany\php\branch-build\pecl\sdo\SCA\Bindings\soap/soap/
2003-02-11.xsd':
009+ 1. xmlSAXUserParseFile returned an error -1
010+ ' in C:\simon\Projects\Tuscany\php\branch-build\pecl\sdo\SCA
\Bindings\soap\ServiceDescriptionGenerator.php:65
011+ Stack trace:
012+ #0 C:\simon\Projects\Tuscany\php\branch-build\pecl\sdo\SCA
\Bindings\soap\ServiceDescriptionGenerator.php(65):
SDO_DAS_XML::create(Array)
013+ #1 C:\simon\Projects\Tuscany\php\branch-build\pecl\sdo\tests\SCA
\phpt\004.php(7):
SCA_Bindings_soap_ServiceDescriptionGenerator::generateDocumentLiteralWrappedWsdl(Object(SCA_ServiceDescription))
014+ #2 {main}
13 (bug 10049) is a memory leak being reported
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: DUNLIN RC1 testing
php04.php works fine if I run it from the command line fbut fails if I run the phpt test case using run-tests? Anyone else seeing this behaviour? 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: DUNLIN RC1 testing
I'm still having problems with my Windows environment. All of my phpt tests fail with empty output files. Anyone any ideas? Anyhow here's what I found... Linux: FC6 PHP 5.2.0 tests/SCA/phpunit/TestSuite.php ln 407 - requires SoapBinding rather than SOapBinding examples/SCA/helloworldscajsonrpc/ There is a issue with the case of Helloworld.php. The index page refers to it as HelloWorld.php. Best to be accurate. examples/SDO/rss-media missing Windows XP SP2 PHP 5.2.0 All of the phpt tests failed (am still investigating - must be something wrong with my environment) General README - sort out reference to DEV_BRANCH - Would be worth noting that we distribute examples and they end up in test/SCA_SDO/examples copying this dir to htdocs gives allows you to read about/try SCA and SDO examples. There is a new dependency, via PHP, on open ssl in the tests (deep joy - that kept me entertained for a while - not SCA-SDOs fault though). It would be useful to note somewhere what extensions we expect to be turned on to get a clear test run. sdo libxml soap json xmlrpc openssl curl pdo + you favourite driver for the DAS tests Having these tests fail because the extension is not enabled in valid but not an SCA_SDO problem. I could add a note to the web site and/or README ? We should have an index.html page in the examples dir point to SDO and SCA index pages. We should have in index.html in examples/DAS for completeness to explain what's going on Remove interop tests from SCA_SDO/tests/AllTests.php We don't ship these test (still useful for local testing though) Can you tell me where I should put fixes? 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: DUNLIN RC1 testing
On 15 Jun, 12:31, Caroline Maynard [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: I'm still having problems with my Windows environment. All of my phpt tests fail with empty output files. Anyone any ideas? What happens if you run the generated php scripts manually? It turned out to be a Release vs Debug thing. There is a new dependency, via PHP, on open ssl in the tests (deep joy - that kept me entertained for a while - not SCA-SDOs fault though). Not sure what you mean by via PHP. I know that the ebaysoap binding has a dependency on openssl - and I did add a check to that binding to make sure openssl is loaded. Are you talking about something else? No, that's it. We require certain things to be loaded into PHP so it would be useful to say in the docs that some tests will fail if you don't have the right things loaded. It's OK that they fail but it's not our fault. Good that the tests bindings are kind enough to tell you. It would be useful to note somewhere what extensions we expect to be turned on to get a clear test run. sdo libxml soap json xmlrpc openssl curl pdo + you favourite driver for the DAS tests A good way to do this is to add a check to the SKIPIF section of the test, so that it outputs an explanatory message if the required extension is not available. Not sure about this. I was specifically thinking about the unit tests which blow up if the right extensions are not available but probably useful to see that as if they don't show an error people might think all of the features are availalble when they aren't. 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: Time for DUNLIN to peck its way out?
On 14 Jun, 11:22, Caroline Maynard [EMAIL PROTECTED] wrote: Matthew Peters wrote: 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 soapscope is using (since the error messages are identical). Matthew, I'm glad you and Pete got this sorted. Some more process stuff: remember to change the status of the Tuscany defect from Resolved to Closed, and make a note of the new Tuscany revision level (seems to be 546761) in the release notes. Also, although I may sound like a rusty worn-out gramophone, please check in regression tests for the php defects. It's not so much that the testcases haven't appeared yet as that you haven't acknowledged either of my requests that's troubling me ... Hi I think that creating the suggested tests is a good idea. I've seen several emails pass by about release process and have to confess that I don't remember the details. While I'm not a big fan of being too process oriented our build and release is sufficiently complicated that it would benefit from having this written down. Caroline, would you be prepared to commit what you think the various important things to get right are to a page up on the web site a osoa.org? If you don't have time to do this I could extract thoughts from the email archive and document but would be good to get a brain dump. A note on the release. I'd like to help test it. Can I get a preview of the release candidate before it gets posted to PECL? 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: Time for DUNLIN to peck its way out?
+1 to this idea. In the context of this thread, if I could encourage you to put you thoughts down about the bug filing and fixing process that would be excellent. 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] DUNLIN RC1 testing
Hi Matthew, Just been giving the release candidate you sent me a spin and having a few small problems. I can easily fix what I've seen but I'm a little confused about where to do it. I thought we released out of head but head doesn't seem to be at 1.2.2. Here are the things I'm seeing so far. Linux: tests/SCA/phpunit/TestSuite.php ln 407 - requires SoapBinding rather than SOapBinding Windows All of the phpt tests failed (am still investigating - must be something wrong with my environment) I think we need to fix the project README as if refers to the DEV- BRANCH file which is not shipped. More later 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] SOA World - New York - Anyone going?
I've managed to wangle a trip to SOA World in New York from 25th to 27th June. If any PHP SOAers out there are going it would be good to meet up. Let me know. 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: rest resource binding?
I agree with Matthew's sentiment. I think we have enough ideas here to have a crack at the simple CRUDE case. I view the second case as being similar to the first case but with more complex URIs. I think it is useful to point out that this extra complexity is required in reall applications (which Joes presentation that Graham references makes clear) but I think it's something we should consider as an extension to the simple case. 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: rest resource binding?
Its a good analogy. We could consider the resource binding to be the parent of other bindings that apply particular sematics or data formats over and above the basic ability to call the CRUD methods at a particular endpoint. Do you think there is a more fundamental binding that this rest.resource binding should inherit from? 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: rest resource binding?
Yes, I had imaginged that it would be a pass through mechanism of sorts. There has been some work on dealing with specific fixed formats, for example, RSS and ATOM, in the REST environment in SCA. So you could consider these to be representative of bindings that deal in concrete and fixed body types. I'm not suggesting that they are repurposed in any way just put them up there as a contrast. I don't know how the path info/body information should be presented. I Assume that there are limited types of data that can arrive in the SCA scenario GET Params on URL POST Form params on URL or Body (x-www-form-urlencoded) XML in body (xml) PUT Form params on URL or Body (x-www-form-urlencoded) XML in body (xml) DELETE We could take take the view that the CRUD interface is generic and that we need to be able to pass this data into each method in a generic way, e.g. parameter arrays, stdclass, generic SDO, simpleXML etc. I'm also interested in allowing people to use SCA to define what type they are expecting. Maybe this sits between being a pass through and a specific encoding. I.e. it's a specific encoding for a particular service but the binding is not restricted in the types on encoding that can be specified. On the return we need to allow either a simple or complext type to be returned. In this case I think we can take the approach we have taking before of allowing simple types or SDOs to be returned. The other thing we need to support is the various HTTP error codes that can be generated. Thoughts? 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: SDO_DAS_Relational + SCA soap binding?
Graham I was just thinking about this part of your issue... snip I wrote an XML schema to match the schema used by the relational DAS (i.e. using the urn:app_namespace, and all primitives were strings). This got me nearly all the way there, but then I hit the main snag which I hadn't foreseen. The XML which was produced did not follow that of the XML schema. It was basically using the default SDO serialization, where all primitives are attributes (the schema defined them as elements). This meant that on the client side the result came back as empty (did not deserialize properly). How about writing your schema so that it matches the default serialization of SDO? I think what is happening is the SDO's type still ties back to the Relational DAS, rather than the XML, during serialization. The equivalent XML type has some additional information which enables it to be serialized according to the XML schema. Because the SDO type is the relational one, this information is not available so the default XML serialization rules are used. This tricky issue you raise here is what the technology specifc schema is going to look like. In your situation what you did is hand generate it. In fact what you did is introduce a transformation based on how you though the output XML should look. There are many ways that XML schema can be constructed to represent, in this case, relational schema. To cater for this variability we would have to introduce some sort of transformation step to ensure that the SDO model can be converted to the required schema and ensure that that it is output in that form. ALternatively we could instigate a default transformation that determines how relational models will be represented in XML. I guess the output you see now is the default rule. 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] PHP docs install instructions lead to wrong SCA_SDO version being installed
I just tried the install instructions we have in the PHP Docs for the SCA_SDO package. pecl install sdo This causes version 1.0.4 of the package to be installed. Can someone who knows how, fix this, so that it reads pecl install SCA_SDO or tell me how to fix the docs and I'll do it. 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: Off Topic. Visual Studio WS Consuming
Hi Mike
I had a go at this a while back so I repeated the simple experiment I
carried out back then. I took the greeting.wsdl from examples/SCA/
helloworldscawsservice/wsdl. I fixed it to remove the xsi:type
attributes ( :-( need to fix this) and then imported it into my
VisualStudio environment. Now I currently have a fairly old 2003 copy
of VS.net so your experience may differ but I imported it as a web
reference.
I then wrote a little bit of C# relying heavily on code completion to
tell me what to do.
using System;
namespace HelloWorld
{
/// summary
/// Summary description for Class1.
/// /summary
class Class1
{
/// summary
/// The main entry point for the application.
/// /summary
[STAThread]
static void Main(string[] args)
{
//
// TODO: Add code to start application here
//
Console.WriteLine(Hello World Test);
WebReference1.GreetingService greetingService = new
WebReference1.GreetingService();
WebReference1.greet request = new
WebReference1.greet();
request.name = Fred;
WebReference1.greetResponse response =
greetingService.greet(request);
Console.WriteLine(response.greetReturn);
}
}
}
I then ran up the PHP SCA samples by copying examples into htdocs.
Then I ran this C# app in a console and got.
C:\simon\Projects\VisualStudio\phpsoa\HelloWorld\bin
\DebugHelloWorld.exe
Hello World Test
hello Fred
Clearly not an exhaustive test but it can be made to work at the very
basic level.
Hope that helps
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: Some problems with the new release
Ok, good spot Jack. I would add a note of the fix to the PECL bug you raise with SAM. 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] 4 phpt test failures
I am getting the following 4 phpt test failure when I run the tests on the code in CURLEW (I also see them in the 1.2.0 released code so It's not specific to CURLEW). SCA 004 SDO bug 10049 SDO bug 10842 SDO bug 8694 Can someone tell me if we are exepcting these to fail? 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: .NET integration and SCA_SDO 1.1.2
Thanks for doing that Mike 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: New eBay Soap binding in HEAD
Nice Graham. Don't have any feedback yet but a quick question. Did you mean to check it into HEAD rather than the branch? 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: Release 1.2.1
Nice one Matthew. I tried it on Fedora Core 6 and Windows XP SP2. It gets a clean bill of health on linux and all is OK on Windows apart from the two phpt problems I have problems with but you don't. SCA php004.phpt. I'll just keep an eye on this one as the same code works in the unit tests SDO bug10049.phpt. Which is the memory leak that cem pointed out. I'll raise a bug for this I've updated the web site front page with the release new. I'll also add a FAQ entry about having to turn the xml-rpc extension on now we have the bindings turned on properly. Thanks 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: nillable
Mike I don't know either. I took a look at the code and you are right that it seems to always apply nillable to the types that it finds. Maybe it's trying to capture some optionality of PHP parameters but I'm not sure. We need to get Matthew's view on it. 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: Wrong parameter count for SDO_DAS_XML::create()??
OK, I did a pecl install SCA_SDO on my linux box and the sample worked. I spotted another problem but not related to this so I'll raise it on another thread. 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] JSON DAS not in 1.2.0 release?
I looks like the JSON DAS is not included in the 1.2.0 release. At least I can't see it. Is this on purpose or a slip? I'll carry on and test the rest of the examples as I know Matthew reported he was having some problems with web services examples on linux. 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: Google Groups are broken
On 27 Apr, 14:24, cem [EMAIL PROTECTED] wrote: .. in deference to the grammar police. It's seems that Google have made a few changes recently (I've seen changes to the interface) and they seem to have introduced instability. 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: Running PHP Unit tests
On 27 Apr, 14:20, cem [EMAIL PROTECTED] wrote: On Apr 26, 5:03 pm, [EMAIL PROTECTED] wrote: In the run.bat file under /tests the command line is phpunit SCA_SDO_TestSuite TestSuite.php Should this be php path/to/phpunit SCA_SDO_TestSuite TestSuite.php Or am I doing something wrong/have the wrong version of something? Simon I'm not sure they should be there at all - they look as if they belong with an older version of phpunit, and they are not present in the MAIN branch. Even if they worked, what advantage would they offer over just: php TestSuite.php ? OK, so shall we dump them? 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: New tests and examples
On 27 Apr, 16:39, Matthew Peters [EMAIL PROTECTED] wrote: I did get some misbehaviour when I run these tests, but I have fixed them both. (1) One stems from the lines like this on in RestRpcTest.php::setUp() as follows: $this-response = file_get_contents(SCA/phpunit/RestRpc/ RestRpcTestService.response); I have fixed them to be like this: $this-response = file_get_contents(dirname(__FILE__) . / RestRpcTestService.response); which makes the tests independent of where they are run from. (2) I have also changed uses of header() to SCA::sendHttpHeader(), which I originally put in so that we could add unit tests for anything coming out of header(); also it means you don't get the Cannot modify header information messages which I otherwise get all the time. I have checked these changes in. There is now only one failure which is the SMD generation test. Shall I mark this as to be skipped? Or raise a defect? Matthew On Apr 27, 2:31 pm, [EMAIL PROTECTED] wrote: I've checked some tests in for JsonRpc and RestRpc Although they run I am getting some warnings. I've taken the approach with the tests of trying to push tests messages through as much of the infrastructure as possible and parts of it are complaining about being run in a test environment. Anyhow I prefer to have the tests with warnings rather than no tests at all. I've also added some more SCA examples base on some of the examples that have been used at recent conferences. Simon Thanks for doing that Matthew. I didn't get a failure with SMD generation so let me try it again wit your changes. 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] Examples index - was: contents of next release
I'm just looking at putting some tests up for JsonRpc and RestRpc and I notice that the index.html under examples/SCA is inaccurate now. Does anyone want to have a crack at fixing it and maybe adding in the complete list of examples (well the ones that will run is a browser)? 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] Running PHP Unit tests
In the run.bat file under /tests the command line is phpunit SCA_SDO_TestSuite TestSuite.php Should this be php path/to/phpunit SCA_SDO_TestSuite TestSuite.php Or am I doing something wrong/have the wrong version of something? 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: SCA and WSDL: what to do when SOAP-ENC is missing ?
On 25 Apr, 16:19, cem [EMAIL PROTECTED] wrote: On 25 Apr, 07:49, [EMAIL PROTECTED] wrote: On 24 Apr, 22:22, cem [EMAIL PROTECTED] wrote: One of our long-running bugs ishttp://pecl.php.net/bugs/bug.php?id=8428, where a remote WSDL depends for its type definitions on an import like so: types xsd:schema targetNamespace=urn:UrbanSearch xsd:import namespace=http://schemas.xmlsoap.org/soap/encoding// ... Well it seems to be a valid XML in the WSDL types section so It would be interesting to know where this is actually going wrong. The xml schema import processing should be following a process (loosely) defined in section 4.3.2 of the xml schema spec [1]. So here, is it the case that the import is being processed by libxml2 and not being translated into SDO types successfully or is it the case that the import is not being picked up at all? libxml2 is not honouring the import, but it's not bothered as I don't think it is being asked to validate the schema, only that it is well- formed (which it is). Then Tuscany also processes the import during its defineTypes() processing - it also does not honour the import but that leaves it with unresolved types. Anyway, I've subsequently found (by reading the code) that an unknown Tuscany developer did actually put the fix back in as optional behaviour but didn't update the defect to say so. So everything is rosy in the xml schema garden. Cool - so does that mean we have it in the branch. Or do we need to take another cut of Tuscany SDO? --~--~-~--~~~---~--~~ 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: hello
On 13 Apr, 14:39, Adler Medrado [EMAIL PROTECTED] wrote: Hello all. My name is adler medrado, from Brasilia, Brazil and i am joining the group to share experiences related with PHP and SOA and to learn more about phpsoa too. Best regards, adler medradohttp://www.neshertech.net/adler Greetings Adler and welcome. Look forward to hearing your experiences. Let us know if you need any help if you get to looking at SCA and SDO. Regards Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups phpsoa group. To post to this group, send email to [EMAIL PROTECTED] 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: Problème with PHP SDO
On 11 Apr, 10:59, WFX [EMAIL PROTECTED] wrote:
Hum, I tried my link, it's working (again ?) now ...
Anyway, I uploaded all the XSD package here
:http://depotnet.free.fr/DDEX_XSD_20061017.zip
It seems that SDO doesn't like ComplexType or something like that.
I don't know if it may be related to bug described here
:http://pecl.php.net/bugs/bug.php?id=8690
WFX
On 10 avr, 17:32, [EMAIL PROTECTED] wrote:
On 10 Apr, 14:52, WFX [EMAIL PROTECTED] wrote:
Hi all !
I found ths extension very usefull. I tried to use it with the
following code :
?php
try {
$xmldas = SDO_DAS_XML::create(./ddex_xsd/dsr.xsd);
print($xmldas);} catch (SDO_Exception $e) {
print($e-getMessage());}
?
but I get this execption :
Cannot add property Namespace of type commonj.sdo#String to this data
typehttp://ddex.net/xml/2006/dsrm/10#CommercialModelType
xsd file can be downloaded here :http://ddex.net/xml/2006/dsrm/10/dsr.xsd
Is it a bug in this SDO release ?
Thanks
WFX
Hi there. Thanks for trying SDO. I tried to go and look at the schema
at the link you provided and I couldn't get to the server. If I google
up ddex it definitely thinks there should be awww.ddex.netbutI
can't ping it at the moment. Is it down?
Regards
Simon- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
Hi, don't know what went wrong yesterday but I can see your schema
now. This looks like the same problem from the bug report that you
reference, i.e. SDO doesn't seem to handle simple types which are
extensions (or restrictions) from complex types. I note that this is
pretty old and clearly nothing has been done about it. Sorry about
that. I took a quick look at the code and the error you are getting is
raised when the infrastructure tries to add a new property (attribute
in your case) to a simple type which in SDO can't have properties.
This is an issue in the SDO implementation from Apache Tuscany that we
use so I will have to investigate further. I expect a special trap
will be needed to test for the case where simple type extends a
complex type and in this case create the type as a data object instead
of a data type.
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: Qualified Elements
On 30 Mar, 19:41, Charlie Moad [EMAIL PROTECTED] wrote: On 3/30/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On 29 Mar, 19:27, Charlie Moad [EMAIL PROTECTED] wrote: On 3/29/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On 29 Mar, 17:30, Charlie Moad [EMAIL PROTECTED] wrote: On 3/29/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On 28 Mar, 20:59, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi all, I just started using SDO_XML and it is proving extremely useful. I just wanted to ask a quick question that someone might know. I have several schemas that use qualified elements, so I have to put a prefix on the element names. Is there anyway I can force the saved xml to have a prefix on the default namespace? Thanks, Charlie Hi Charlie, I don't have a difinitive answer for you but looking at the code it looks like this is the way that libxml2 does things so you may be stuck with it for the time being. This is the line from SDOXMLWriter.cpp that writes out the root element: rc = xmlTextWriterStartElementNS(writer, NULL, elementName, elementURI); So it looks like its down to how libxml2 handles the elementName and namespace URI. There may be a way of changing this so I'm hoping one of the SDO experts will jump in if that is the case. I have found the qualification (or not) of elements to be a bit of a minefield. Can I just check that when you say force the saved xml to have a prefix on the default namespace? I assume you are talking about having: tns:SomeElement xmlns:tn=my namespace/ as opposed to SomeElement xmlns=mynamesapce/ At the root element level. Is that right? That's the gist of it. I should clarify that the validation problems really only pop up when I am required to use qualified attributes. I think a way to address this would be to have a function to bridge to DOM. DOM allows you to control prefixes. How hard would it be to add a new function: DOMDocument SDO_DAS_XML::saveDOM(SDO_XMLDocument $xdoc) Just writing to a string and file can be somewhat limiting. Thanks, Charlie That's an interesting idea. Would we need to go the other way as well? Do you know much about the PHP DOM implementation? I started suggesting the two-way bridge, but I think it would require a lot more work to make a DOM-to-SDOXML function. It would have to make sure the document is a valid schema or schema instance. I only know the DOM api is a cover of libxml. I have not looked at the c-api. Ok, off the top my head, we could look at doing a simple PHP user space conversion from SDO to DOM, I.e. we could do the write side of a DOM DAS (Data Access Service). I made a simple JSON DAS a little while back and that wasn't too hard. It would be more efficient to do it in the C extension but harder to code I guess. If in the future someone wanted to convert it to work at the libxml level I'm sure it could be done. What do you think? If you feel like having a go at it let me know. I can always do the following: DOMDocument::loadXML($xmldas-saveString($doc)); I was just hoping the underlying implementation was using libxml, and it would be trivial to return a DOMDocument instance. I just won't have time in the near future to look at this since it will require me to understand a lot of php/c-api stuff I have never worked with. Hi Charlie The SDO implementation does use libxml under the covers to parse incoming XML using the SAX like interface but I think we would have to create a DOM on the fly from the SDO data tree. This would be more efficient to do in C but not a straight read from the libxml structures. Anyhow I've added it to the wish list (http://www.osoa.org/ display/PHP/SDO+Wish+List). 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] New Bindings
Just back from my Easter hols and I notice that a few new bindings have appeared in the BUZZARD branch. Can someone give me a quick update of what the status is? 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: Writing a transaction service
On 19 Mar, 22:46, [EMAIL PROTECTED] wrote: On 19 Mar, 16:22, jon [EMAIL PROTECTED] wrote: On Mar 19, 6:29 am, [EMAIL PROTECTED] wrote: Hi Jon Sorry this is a rather tardy response. I've been out on a few days leave. You raise some very interesting points here. I have to admit up front that I'm not a distributed transaction expert and also that we haven't thought about this in detail in PHP SCA/SDO yet. First a point of clarification. It seems from your note that you are interested primarily in the ability to share a transaction context amongst distributed applications (as opposed to distributing a transaction spanning multiple transactional resources). Is this the case? If so then I guess you still need to generate a global transaction id in order to share this amongst the client application but that at the data resource there is only one transaction with many clients providing updates to that transaction. Is that right? This seems to fall between you suggested solutions 1) and 2) (maybe I'm missing something?) in that you could rely on an RDBMS with XA capabilities to manage a transaction ID for you but you still need to share that transaction ID between participating clients. You also need to know when the transaction should be committed or rolled back of course. Having said this you still end up having to do some work yourself, I.e. I've not come across any off the shelf PHP transaction coordination implementation. Some work has been done in the web services space, for example, several companies created a set of specs for supporting the coordination of distributed actions at the WS message level (http://www-128.ibm.com/developerworks/library/ specification/ws-tx/). But you would have to provide some kind of implementation. Maybe the Axis PECL extension will start to provide some of this but I haven't seen anything yet. A short term solution might be to provide a service which interacts with the database and accepts the transaction id as a parameter to CRUD operations and provides interfaces for starting, and committing the transaction. It sounds, from your background piece at the end, as if you are starting to think about how to apply SOA principle to your application suite. Maybe some of this thinking will allow you work around the implementation of complex distributed transaction support by pulling the distributed parts into common services. This is not always possible of course.From an SCA point of view clearly we need to provide better support for managing the details of the transports provided. As you may have seen from the mail trail SCA more widely defines a system of policies and intents. In this case we would be interested in understanding how those related to transactions can be applied to PHP SCA. No progress has been made here yet but your experience of trying to do this could be really useful here. Regards Simon Thanks for your response Simon, First a point of clarification. It seems from your note that you are interested primarily in the ability to share a transaction context amongst distributed applications (as opposed to distributing a transaction spanning multiple transactional resources). Is this the case? If so then I guess you still need to generate a global transaction id in order to share this amongst the client application but that at the data resource there is only one transaction with many clients providing updates to that transaction. Is that right? Yes, that's right... The applications (and associated services in a SOA solution here) may or may not have their own transactional resource (some write to their own DB or backend for example, but many services would be dealing with the same shared resource, usually a RDBMS). I have mocked up a transaction coordination service with SCA and a couple of middle tier services that do very granular inserts (my solution number 2). A top-tier script calls the transaction service, gets a global ID and that is passed around to the middle tier services as they do their work. Currently the logic for deciding to commit or rollback resides in the top-tier script and that decision is passed to the transaction service. (each transactional resource would need it's own coordinator and be composable in such a way that they can take part in a more global cross-resource transaction, but at this stage, I'm just trying to deal with one transactional resource within one business process) This all works as an early proof-of-concept, but I have realized that my current implementation is unworkable because of the synchronous nature of the PHP SCA implementation and how I've used it to make calls. To execute only two inserts across these coordinated services, about 6 SOAP messages/responses have to be delivered. Because of
[phpsoa] Re: Status of PHP/SDO/DAS/Relational
On 19 Mar, 00:01, tompaw [EMAIL PROTECTED] wrote: There's one more thing I forgot to ask about: multiple FKs. Currently that's the main reason why I can't use SDO instead of Qcodo's ORM in my projects. I found the thread Many to Many, but it's unable to reply in it (I guess it's too old - Sept 2006). So here's my question: are there plans of implementing multiple FKs in Relational DAS? If not, do you know any hacks to that limitation? Almost all of my db designs use multiple FKs, and since you didn't implement that feature I'm beginning to think there's sth wrong with it. But the real-world objects are also multiple-fk'ed, for example this post has BOTH author and a thread, right? Hi I don't think there is anything wrong with using multiple foreign keys. We just haven't got round to adding support yet. Sorry about that. The relational DAS was put together to show how it could be done but doesn't implement all of the features that you may want when compared, for example, to the relational DAS implementation in Java SCA. A couple of people have asked for this now as well as support for many to many relationships so we should try and bump it up the priority list. If you feel like having a go yourself at adding support you are most welcome of course;-). No idea why Google didn't allow you to post to the original message. Very strange! I don't know of anyone who is using the relational DAS in anger just yet (maybe we will see posts if someone is). We would like to move toward that but as you say not having many to many and multiple foreign key support makes that difficult for people at the moment. If you have time to try it, even if only in your test environment, and feed back that would be great. There is nothing targeted specifically for people in Europe looking at or working on OSOA things as far as I know. There have been people talking about OSOA at a number of European PHP conferences as well as US ones. Is that what you mean? 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: Randomly appearing strings when working with CDATA
On 12 Mar, 15:43, cdouglas [EMAIL PROTECTED] wrote: Is there a way I can email it to you since I can't post it here? Hi Chris If the data is sensitive/confidential it's better not to send it out to me. I'll mail you directly and I'll get you to describe the general shape of the data. 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: Randomly appearing strings when working with CDATA
On 12 Mar, 17:35, cdouglas [EMAIL PROTECTED] wrote: An example XML doc structure pulled from the CDATA section of the parent xml doc is: applicationData parameterSet group name=group1 parameter name=param1Value/parameter /group group name=group2 parameter name=param2value/parameter /group group name=group3 group name=group4 parameter name=param4value/parameter /group /group /parameterSet /applicationData An group section is here that demonstrates the issue. The issue occurs 3 times just in this small section, this is typical. I am currently running the following commands to clean it up before processing. $cdata = str_replace(![CDATA[,,$cdata); $cdata = str_replace(]],,$cdata); gro]]![CDATA[up name=callFlow group name=message parameter name=allowY/parameter /group group name=talk parameter name=maxDuration600/ parameter /group group name=acceptance group name=allowMethods parameter name=DTMFY/ parameter ]]![CDATA[parameter name=VoiceN/parameter parameter name=passiveY/ parameter parameter name=PulseN/ parameter /group group name=cp parameter name=allowY/ parameter /group /group group name=messages parameter name=userDefinedN/ pa]]![CDATA[rameter parameter name=talkOverlayN/ parameter parameter name=talkRandomN/ parameter /group /group Hi Chris Thanks for that. I tried this by creating a document with 20 or so ApplicationData elements in CDATA sections and didn't see the effect you are seeing (am running with the AVOCET branch at the moment). The places you are seeing the CDATA markers are really strange and it lookes like they are valid in as much that the CDATA section is terminated and then started up again. I wonder if this is a buffering thing somewhere. I.e something reads part of a CDATA secton and sends a CDATA event which SDO uses to create a CDATA section. As only part of the CDATA has been read the next part gets put in a separate CDATA section. Anyhow just thinking aloud as I don't see any references to this kind of thing in a quick web search. I need to investigate further! 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: curl and required directories
Hi Rob On 9 Mar, 16:58, Rob [EMAIL PROTECTED] wrote: I was playing around with the json bindings and ran into a couple of issues that imho should be changed. First is the reliance on the directory structure. Originally only the SCA directory was needed. When I tried to call a remote json service, I found out that the top level SDO directory was also needed as there is some pathing looking for a SDO/DAS/Json.php file (So with my layout I added the entire pecl tree to the include_path entry). Either it should be SCA/ and DAS/ OR SDO/. Personally I would prefer not to go the SDO/ route just for the fact that it could contain a lot of other things. Much easier to be copying the SCA and DAS directories somewhere than having playing around cleaning up the SDO directory so only the PHP code is left. Another possibility is to create some other structure that encapsulates all the callable PHP code. In any case consistency here would be good. Yes, I fell for this one again when doing some JSON-RPC tests earlier and I put the wrong path in. DAS is part of SDO because having a DAS on its own without SDO doesn't really make any sense. What you have highlighted though is that when we make the next release, including the JSON-RPC functionality, we need to remember to ship the JSON DAS also. When you do a pecl install SCA_SDO then SCA and SDO directories are created containing just the PHP code from the package. Given the current scheme the json.php would be expected to appear in SDO/DAS On to curl. It would probably be better to use the PHP stream support if possible than relying on curl. For example, I have no curl support on the system because its really not needed anymore - I use PHP streams and like to keep my build lean. One less requirement the better. Good idea. Not tried it but have added it to the wish list. (http:// www.osoa.org/display/PHP/SCA+Wish+List) Rob 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: Randomly appearing strings when working with CDATA
On 9 Mar, 17:26, cdouglas [EMAIL PROTECTED] wrote: Hello, After the fix was put in to handle CDATA in XML docs, I started having garbage strings show up in the CData sections. Its always the same but randomly in the cdata. Is anyone else seeing this? I am just using a str_replace to get rid of it, but I would rather not have to. This is what is getting put in randomly. ]]![CDATA[ Thanks Chris Hi Chris Sounds like the fix is a bit over zealous about putting the CDATA markers in. Due to way that the internals of SDO works it takes them out in the XML read logic and puts them in again when the strings are stored in the SDO properties. So obviously something is going wrong in some cases. I haven't seen this happen. Do you have an example where it always happens or can you describe what sort of document it happens in so I can reproduce it. 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 -~--~~~~--~~--~--~---
