On 07/03/07, Simon Laws <[EMAIL PROTECTED]> wrote:
On 3/7/07, Pete Robbins <[EMAIL PROTECTED]> wrote: > > On 07/03/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > On 3/7/07, Pete Robbins <[EMAIL PROTECTED]> wrote: > > > > > > On 22/02/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > > > > > On 2/22/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > > > On 2/21/07, Pete Robbins <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > Thanks. The apache mailing list seems sensitive to attachments. > > The > > > > > > Jira is the right place for it anyway. > > > > > > > > > > > > Cheers, > > > > > > > > > > > > On 21/02/07, Caroline Maynard <[EMAIL PROTECTED] > > wrote: > > > > > > > I had attached it to my post, and it appeared to get through > OK > > > for > > > > > > me, but > > > > > > > perhaps not for others. So I've now raised > > > > > > > https://issues.apache.org/jira/browse/TUSCANY-1133 and > attached > > it > > > > to > > > > > > that. > > > > > > > > > > > > > > On 21/02/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > I can't find the JIRA that you attached the patch to. Can > you > > > > point > > > > > > me in > > > > > > > > the right direction? > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Caroline > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Pete > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > Thanks Caroline > > > > > > > > > OK, the patch improves the situation on windows somewhat so it's > > checked > > > > in > > > > now. I need to get it out and re-run on linux. > > > > > > > > Regards > > > > > > > > Simon > > > > > > > > > > I have been working on the PHP Extension on Linux and have got it into > a > > > "working" state but not without some changes in the code from pecl. > Here > > > is > > > what I have done (though this is not yet checked in to svn): > > > > > > a) I have created a separate build for the extesnion with it's own > > > build.sh. > > > It can be packaged and released separately from the rest of Tuscany. > > This > > > is > > > an experiment to see if this model works and whether we should do this > > for > > > other Tuscany Native extensions. I have included PHPCalculator sample > > with > > > the extension rather than in the sca/samples. > > > > > > b) I have simplified the PHPCalcualtor sample. Currently there is no > way > > > for > > > a PHP client to locate and call a Tuscany service as this code in the > > > PHP_SCA code is not yet written. I have replaced the C++ client to a > > > simple > > > Python client. This cleans up the build process significantly! > > > > > > My concern is that this may make life easier for us but still hides a > > problem that I have experienced on linux which means that using a C++ > > client > > doesn't work with the C++ SCA automake system. I just haven't had the > time > > to go back and work out why. I'm not suggesting you have the time either > > btw. > > > I will go back and make this work someday! There should be nothing that a > C++ client will pull in to cause the problem you see. For this simple > sample > though I don't want to have to do all the scagen, compile stuff when I can > use a simple Python or Ruby client. > > > Next I have > > > changed the sample so that it demonstrates: > > > > > > > > > 1. Add and Subtract are simple services in Calculator.php that can > > be > > > called from the client. They do not reference any other service. > > > 2. Multiply service can be called form the client and then uses > > > a PHP_SCA injected reference to the multiply service ( > > > Multiply.php). The resolution and calling of this referenced > > > service does not involve the Tuscany php extension (I think) > > > > 3. Divide service can be called from the client and then uses an > > > injected binding.tuscany that should go via a tuscany > > > proxy/wrapper to invoke the method in Divide.php > > > > > > Not sure without seeing what code you now have. The way it was set up in > > SVN > > is demonstrated in the diagram. > > > > > http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/PHPCalculator/phpcalculator.png > > . > > Only the CPP local client at the bottom was tested due, as you note, to > > PHP > > clients not being implemented yet. So > > > > 1. Add.php > > A basic PHP script that implements the component's "add" function and > > uses PHP SCA to find a PHP logging component. PHP SCA is running > embedded > > here so it should go out via the native runtime, and use the model built > > from SCDL, to find the log comoponent. > > > > 2 Subtract.php > > A basic PHP script with a PHP funtion implementing the component's "sub" > > function. Again finds a PHP logging components via the native runtime. > > > > 3 Multiple.php > > A PHP class which provides a class function to implement the > component's > > "mul" function. Again finds a PHP logging component via the native > > runtime > > > > 4 Divide.php > > A PHP SCA service (uses @services annotation) and provides a class > > function to implement the component's "div" function. Uses the native > > runtime to find a C++ Divide component and passes the message on. > > > > Because we don't have a PHP Client and because the C++ calculator > > component > > does add/subtract/multiply operations internally I also use the divide > > component (4) to call out to add/subtract/multiply temporarily. You will > > see > > some commented out lines in there. > > > > > > Currently 1. works with the Python client invoking locateService which > > > returns a PythonProxy that is wired to the PHPServiceWrapper around > > > Calculator.php. > > > > > > Cool > > > > 2 also works but I had to edit the pecl/sdo/sca/SCA.php > > > createInstanceAndFillInReferences method so that it does not always > > return > > > an SCA_TuscanyProxy if called when php is embedded. I changed this to > > test > > > for the binding type being 'tuscany' so that in case 2 a non-Tuscany > > proxy > > > gets returned. > > > > > > Unfortunately you find the SCA_SDO midst reorganization. The mechanism > for > > developing extensions is being generalized to make it plugable but the > > proxy > > side has not been done yet. creatInstanceAndFillInReferences really > needs > > to > > be removed altogether. Having said this in the long term I think the > > sentiment of your change is correct if you are trying to test whether a > > binding.php goes via PHP SCA while binding.tuscany goes via native SCA. > In > > the short term I decided to make everything to go via tuscany. Clearly > I'm > > really interested in testing whether the integration between PHP SCA and > > Native SCA works. I already know that PHP SCA - PHP SCA integration > buts. > > Maybe its a bit heavy handed to turn this off completely at the moment > so, > > as I say, I can see the logic in what you are trying to do here. > > > The main problem was that the binding.php should not go via Tuscany and it > keels over. Ok, so what's the error it's giving? 3. Does not work as it gets a sementation violation when the > > > PHPServiceWrapper for the divide_service is called. > > > The PHPCalculator sample in svn currently has separate services for > Add, > > > Subtract, Multiply and Divide that show different ways of coding the > PHP > > > service. The only one of these that seems to work are the ones which > > have > > > a > > > class and function in the php. The Add.php is odd in that the code > gets > > > executed when the script is loaded and not when the service is > called??? > > > The > > > Subtract.php has a function with no class and this also failed. In my > > > simplified sample I removed these as components and wrote them as > simple > > > service methods on Calculator.php. > > > > > > By its nature Add.php will get called when it is loaded. Its just a > > script. > > However we already have the parameter information to provide to it with > > the > > correct input and can capture its output. So this should work. Obviously > > it > > doesn't in your case for some reason. > > > I don't think you do have the parameter information as it appeared the > script was loaded while creating the proxy/wrapper and before the call to > the service. The call to the service in this case just goes and gets the results as the script will already have run. I'm not convinced that the strategy of simplyfying the tests until something > > works > > > eh? I'm not trying do do this. I'm trying to simplify the tests to see > what > works rather then the big "it doesn't work" which is it's current state! > is a good justification for including PHP in the release. It seems you > > have changed a few things and are stuggling to get it to work. Doesn't > > that > > mean its not ready? > > > I agree... it's not yet ready ... that's why I'm working on it. Any help > would be appreciated ;-) Ok, what do you need? Can you create a new SimplifiedPHPCalculator in SVN so I can see it. Would be a shame to loose the more complex sample. > I will investigate the segv when calling a tuscany binding from the php > > component. > > > > One more thing that seems to fail, and I'm not sure how it is supposed > to > > work, but the calls from the php components to > > SCA::getService("log_service") can not resolve the reference. I'm not > sure > > how this is supposed to work but as the reference log_service is defined > > in > > the scdl I think the getService code in SCA.php would need to call > > something > > in the tuscany php extension to resolve this and I don't think it does. > As > > I > > say, I'm not sure how this style of call is supposed to work in php. > > > The reference is resolved via the SCA_TuscanyProxy.php. getService also > has > a test in it that forces a tuscany proxy to be created when running > embedded. Again this comes back to my decision to force all calls via > Native > SCA pending the completion of the PHP SCA_SDO reorg and some more thinking > about how best to deal with a model shared between PHP SCA_SDO and Native > SCA. I think we could make a simple change to testing the optional binding > type that you can pass into getService but I don't do this at the moment > (on > purpose:-). > > I made that change to test for the tuscany binding type as well. I'm not > sure I like the name binding.tuscany. It doesn't seem quite right. I think > the "tuscany" binding should probaby be the binding for a named reference. > So... after you determine it's not a php (local) binding, or wsdl, or ??? > then it must be a named reference and if this reference is unknown then > it's > off to find it in the scdl (i.e. via Tuscany). Well this is the kind of thinking that we need to do, i.e. this is the bit about how we share the model between PHP and Native runtimes. It's a matter of expectations and who takes priority. I.e. we have instigated a binding so that you can explicitly say when you cede control to the runtime to go and find a named reference rather than using .php or .wsdl of .smd. Happy to see the name changed to something more sensible but I think we need to do more than this. If you are enabling the PHP SCA bindings in embedded mode then the model is split between PHP SCA and native SCA and so the picture, from a Native SCA model pov, becomes fragmented. This is the least of our worries at the moment but I imagine in the future we would want some way of consistently managing all components and wires regarless of where the meta data is specified (SCDL or annotations). The current solution takes us to the point that we can prove that the integration works technically but it's not a complete solution. Cheers, > > > -- > Pete >
I've checked in the changes I made to the PHP extension (basically adding an interface.php extension). There is a samples folder within the extension source containing the start of a simple Calculator sample. This should not be made over complicated and should test one scenario at a time; single component, 2 components over tuscany binding, 2 components over php binding etc. We need this to verify that the extension works. The original sample is still in the sca/samples folder if a more complex scenario is needed. The instructions to build the extension need a lot of work and verification. e.g. this extension does not need Axis as far as I am aware yet the instructions claim it is needed. The build.sh in the top level of the extension can be used to build it and install it to the SCA installed at $TUSCANY_SCACPP.. make dist in the top level of the extension will create a source package. The Windows build is tbd. I would (and will if I get the time) move the VSExpress project for this extension from the sca/VSExpress folder into the extension source. I will try and get back to look at this after I have sorted the M3 release. Cheers, -- Pete
