You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2007/02/02 14:33:23 UTC
[C++] SCA PHP Extension patches
I've attached patches to add reference support to the PHP Extension (
https://issues.apache.org/jira/browse/TUSCANY-1089). This is a fairly major
change and there have been several build problems in getting this to work.
As it's been a bit of a struggle I'm keen to get someone else to help me try
in on other boxes because I'm still having problems on my configuration and
its not clear if it's me or if there are rela problems. Sharing via svn is
the best way to do this but I should mention that this won't work without
some changes to the SCA_SDO PECL extension which I'm in the process of
making at the moment. They aren't there just yet.
Simon
Re: [C++] SCA PHP Extension patches
Posted by Pete Robbins <ro...@googlemail.com>.
On 07/03/07, Simon Laws <si...@googlemail.com> wrote:
>
> On 3/7/07, Pete Robbins <ro...@googlemail.com> wrote:
> >
> > On 07/03/07, Simon Laws <si...@googlemail.com> wrote:
> > >
> > > On 3/7/07, Pete Robbins <ro...@googlemail.com> wrote:
> > > >
> > > > On 22/02/07, Simon Laws <si...@googlemail.com> wrote:
> > > > >
> > > > > On 2/22/07, Simon Laws <si...@googlemail.com> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 2/21/07, Pete Robbins <ro...@googlemail.com> 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 <caroline.maynard@gmail.com >
> > 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 <si...@googlemail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> > > > > > > For additional commands, e-mail:
> tuscany-dev-help@ws.apache.org
> > > > > > >
> > > > > > > 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
Re: [C++] SCA PHP Extension patches
Posted by Simon Laws <si...@googlemail.com>.
On 3/7/07, Pete Robbins <ro...@googlemail.com> wrote:
>
> On 07/03/07, Simon Laws <si...@googlemail.com> wrote:
> >
> > On 3/7/07, Pete Robbins <ro...@googlemail.com> wrote:
> > >
> > > On 22/02/07, Simon Laws <si...@googlemail.com> wrote:
> > > >
> > > > On 2/22/07, Simon Laws <si...@googlemail.com> wrote:
> > > > >
> > > > >
> > > > >
> > > > > On 2/21/07, Pete Robbins <ro...@googlemail.com> 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 <caroline.maynard@gmail.com >
> 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 <si...@googlemail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > > >
> > > > > > 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
>
Re: [C++] SCA PHP Extension patches
Posted by Pete Robbins <ro...@googlemail.com>.
On 07/03/07, Simon Laws <si...@googlemail.com> wrote:
>
> On 3/7/07, Pete Robbins <ro...@googlemail.com> wrote:
> >
> > On 22/02/07, Simon Laws <si...@googlemail.com> wrote:
> > >
> > > On 2/22/07, Simon Laws <si...@googlemail.com> wrote:
> > > >
> > > >
> > > >
> > > > On 2/21/07, Pete Robbins <ro...@googlemail.com> 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 <caroline.maynard@gmail.com > 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 <si...@googlemail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > >
> > > > > 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.
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.
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 ;-)
> 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).
Cheers,
--
Pete
Re: [C++] SCA PHP Extension patches
Posted by Simon Laws <si...@googlemail.com>.
On 3/7/07, Pete Robbins <ro...@googlemail.com> wrote:
>
> On 22/02/07, Simon Laws <si...@googlemail.com> wrote:
> >
> > On 2/22/07, Simon Laws <si...@googlemail.com> wrote:
> > >
> > >
> > >
> > > On 2/21/07, Pete Robbins <ro...@googlemail.com> 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 <caroline.maynard@gmail.com > 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 <si...@googlemail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > > 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.
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.
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'm not convinced that the strategy of simplyfying the tests until something
works 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 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:-).
Cheers,
>
> --
> Pete
>
Re: [C++] SCA PHP Extension patches
Posted by Pete Robbins <ro...@googlemail.com>.
On 22/02/07, Simon Laws <si...@googlemail.com> wrote:
>
> On 2/22/07, Simon Laws <si...@googlemail.com> wrote:
> >
> >
> >
> > On 2/21/07, Pete Robbins <ro...@googlemail.com> 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 <caroline.maynard@gmail.com > 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 <si...@googlemail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > > 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! 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
Currently 1. works with the Python client invoking locateService which
returns a PythonProxy that is wired to the PHPServiceWrapper around
Calculator.php.
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.
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.
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.
Cheers,
--
Pete
Re: [C++] SCA PHP Extension patches
Posted by Simon Laws <si...@googlemail.com>.
On 2/22/07, Simon Laws <si...@googlemail.com> wrote:
>
>
>
> On 2/21/07, Pete Robbins <ro...@googlemail.com> 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 <caroline.maynard@gmail.com > 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 <si...@googlemail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> > 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
Re: [C++] SCA PHP Extension patches
Posted by Simon Laws <si...@googlemail.com>.
On 2/21/07, Pete Robbins <ro...@googlemail.com> 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 <ca...@gmail.com> 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 <si...@googlemail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> Thanks Caroline
Re: [C++] SCA PHP Extension patches
Posted by Pete Robbins <ro...@googlemail.com>.
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 <ca...@gmail.com> 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 <si...@googlemail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] SCA PHP Extension patches
Posted by Caroline Maynard <ca...@gmail.com>.
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 <si...@googlemail.com> wrote:
>
>
> I can't find the JIRA that you attached the patch to. Can you point me in
> the right direction?
>
--
Caroline
Re: [C++] SCA PHP Extension patches
Posted by Simon Laws <si...@googlemail.com>.
On 2/21/07, Simon Laws <si...@googlemail.com> wrote:
>
>
>
> On 2/21/07, Caroline Maynard <ca...@gmail.com> wrote:
>
> > I've been battling with getting this working under Windows, and attach a
> > patch with my latest efforts. Note that these changes work hand-in-hand with
> > corresponding changes to the Tuscany bindings for PHP SCA, which are already
> > in place in the AVOCET branch in the PECL repository.
> >
> > On my Windows box with the patch installed, the PHP Calculator sample
> > runs clean, with no crashes on shutdown and no reported leaks of PHP memory.
> >
> >
> > I've also done quite a bit of tidying up, to make the inner workings a
> > more standard use of the PHP engine. In particular, I've broken out the big
> > php_eval_script() into its component parts, which makes it much easier to
> > debug. Unfortunately I haven't had time to refactor
> > SCA_TuscanyWrapper::invoke() subsequently, so it is rather a long sprawl at
> > present and could do with further prettying. I also hid the SCA_Tuscany
> > object handle from user space, because exporting the handle as a reference
> > was rather dangerous code.
> >
> > One thing I haven't yet tackled is getting the thread context right for
> > reentrant paths through the extension. I've been investigating this, and I
> > think it's going to require saving a thread context in each of the mediator
> > objects, and restoring the correct one on invoke(). However what's there
> > seems to work OK in the simple environment of the PHP Calculator sample.
> >
> > I'm out for a few days now - could someone give it a spin on *IX and
> > make sure that's still OK?
> >
> > On 07/02/07, Simon Laws < simonslaws@googlemail.com> wrote:
> >
> > > I've just checked in some changes to the VC project on windows which
> > > will
> > > hopefully work for you now. I've also
> > > updated the build for the PHP Calculator sample. Having said this I
> > > can't
> > > get it to run on my windows box. As I've said before I'm a bit
> > > suspicious of
> > > my windows configuration but I'm not getting the same error as before
> > > so
> > > it's likely that ithis is a real problem with the PHP Extension code.
> > > Would
> > > still be useful to know if you see a failure in the PHP engine code
> > > also.
> >
> >
> > --
> > Caroline
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> Great, thanks Caroline. I'll give it a spin.
>
> Simon
>
Hi Caroline.
I can't find the JIRA that you attached the patch to. Can you point me in
the right direction?
Thanks
Simon
Re: [C++] SCA PHP Extension patches
Posted by Simon Laws <si...@googlemail.com>.
On 2/21/07, Caroline Maynard <ca...@gmail.com> wrote:
>
> I've been battling with getting this working under Windows, and attach a
> patch with my latest efforts. Note that these changes work hand-in-hand with
> corresponding changes to the Tuscany bindings for PHP SCA, which are already
> in place in the AVOCET branch in the PECL repository.
>
> On my Windows box with the patch installed, the PHP Calculator sample runs
> clean, with no crashes on shutdown and no reported leaks of PHP memory.
>
> I've also done quite a bit of tidying up, to make the inner workings a
> more standard use of the PHP engine. In particular, I've broken out the big
> php_eval_script() into its component parts, which makes it much easier to
> debug. Unfortunately I haven't had time to refactor
> SCA_TuscanyWrapper::invoke() subsequently, so it is rather a long sprawl at
> present and could do with further prettying. I also hid the SCA_Tuscany
> object handle from user space, because exporting the handle as a reference
> was rather dangerous code.
>
> One thing I haven't yet tackled is getting the thread context right for
> reentrant paths through the extension. I've been investigating this, and I
> think it's going to require saving a thread context in each of the mediator
> objects, and restoring the correct one on invoke(). However what's there
> seems to work OK in the simple environment of the PHP Calculator sample.
>
> I'm out for a few days now - could someone give it a spin on *IX and make
> sure that's still OK?
>
> On 07/02/07, Simon Laws < simonslaws@googlemail.com> wrote:
>
> > I've just checked in some changes to the VC project on windows which
> > will
> > hopefully work for you now. I've also
> > updated the build for the PHP Calculator sample. Having said this I
> > can't
> > get it to run on my windows box. As I've said before I'm a bit
> > suspicious of
> > my windows configuration but I'm not getting the same error as before so
> >
> > it's likely that ithis is a real problem with the PHP Extension code.
> > Would
> > still be useful to know if you see a failure in the PHP engine code
> > also.
>
>
> --
> Caroline
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
Great, thanks Caroline. I'll give it a spin.
Simon
Re: [C++] SCA PHP Extension patches
Posted by Caroline Maynard <ca...@gmail.com>.
I've been battling with getting this working under Windows, and attach a
patch with my latest efforts. Note that these changes work hand-in-hand with
corresponding changes to the Tuscany bindings for PHP SCA, which are already
in place in the AVOCET branch in the PECL repository.
On my Windows box with the patch installed, the PHP Calculator sample runs
clean, with no crashes on shutdown and no reported leaks of PHP memory.
I've also done quite a bit of tidying up, to make the inner workings a more
standard use of the PHP engine. In particular, I've broken out the big
php_eval_script() into its component parts, which makes it much easier to
debug. Unfortunately I haven't had time to refactor
SCA_TuscanyWrapper::invoke() subsequently, so it is rather a long sprawl at
present and could do with further prettying. I also hid the SCA_Tuscany
object handle from user space, because exporting the handle as a reference
was rather dangerous code.
One thing I haven't yet tackled is getting the thread context right for
reentrant paths through the extension. I've been investigating this, and I
think it's going to require saving a thread context in each of the mediator
objects, and restoring the correct one on invoke(). However what's there
seems to work OK in the simple environment of the PHP Calculator sample.
I'm out for a few days now - could someone give it a spin on *IX and make
sure that's still OK?
On 07/02/07, Simon Laws <si...@googlemail.com> wrote:
> I've just checked in some changes to the VC project on windows which will
> hopefully work for you now. I've also
> updated the build for the PHP Calculator sample. Having said this I can't
> get it to run on my windows box. As I've said before I'm a bit suspicious
> of
> my windows configuration but I'm not getting the same error as before so
> it's likely that ithis is a real problem with the PHP Extension code.
> Would
> still be useful to know if you see a failure in the PHP engine code also.
--
Caroline
Re: [C++] SCA PHP Extension patches
Posted by Simon Laws <si...@googlemail.com>.
On 2/2/07, Simon Laws <si...@googlemail.com> wrote:
>
>
>
> On 2/2/07, Andrew Borley <aj...@gmail.com> wrote:
> >
> > On 2/2/07, Simon Laws <si...@googlemail.com> wrote:
> > > On 2/2/07, Andrew Borley <aj...@gmail.com> wrote:
> > > >
> > > > Hi Simon,
> > > > I'm taking a look at them now. I'll let you know how I get on.
> > > >
> > > > Cheers
> > > > Andy
> > > >
> > > > On 2/2/07, Simon Laws < simonslaws@googlemail.com> wrote:
> > > > > I've attached patches to add reference support to the PHP
> > Extension (
> > > > > https://issues.apache.org/jira/browse/TUSCANY-1089 ). This is a
> > fairly
> > > > major
> > > > > change and there have been several build problems in getting this
> > to
> > > > work.
> > > > > As it's been a bit of a struggle I'm keen to get someone else to
> > help me
> > > > try
> > > > > in on other boxes because I'm still having problems on my
> > configuration
> > > > and
> > > > > its not clear if it's me or if there are rela problems. Sharing
> > via svn
> > > > is
> > > > > the best way to do this but I should mention that this won't work
> > > > without
> > > > > some changes to the SCA_SDO PECL extension which I'm in the
> > process of
> > > > > making at the moment. They aren't there just yet.
> > > > >
> > > > >
> > > > > Simon
> > > > >
> > > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > > Andy, just thinking that by defauly we may want to disable the
> > automake
> > > link to the PHP Extension and PHP Calculator sub projects because of
> > course
> > > they won't generally build unless you have your environment set up
> > just so.
> > > In the patches I left them enabled :-(
> > >
> > > Simon
> > >
> > >
> > Hi Simon,
> > The PHP extension & sample are by default disabled at the moment - you
> > need to run "configure --enable-php" to build them on Linux. I've
> > committed the patches (& aslo updated the windows vcproj file), but
> > currently I'm failing to build on windows due to not having the PECL
> > SCA_SDO stuff that you mentioned and also getting some weird DLL
> > import and Winsock error messages... any ideas?
> >
> > Cheers
> > Andy
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> > yes - if you look at the top of the PHPServiceWrapper you will see a
> #define you have to uncomment to make it work on windows. This needs to be
> in a #ifdef win32 or similar but I've been working on UNIX for the last 3
> weeks so didn't go back to fixing it. Sorry
>
> Simon
>
I've just checked in some changes to the VC project on windows which will
hopefully work for you now. I've also
updated the build for the PHP Calculator sample. Having said this I can't
get it to run on my windows box. As I've said before I'm a bit suspicious of
my windows configuration but I'm not getting the same error as before so
it's likely that ithis is a real problem with the PHP Extension code. Would
still be useful to know if you see a failure in the PHP engine code also.
Regards
Simon
Re: [C++] SCA PHP Extension patches
Posted by Simon Laws <si...@googlemail.com>.
On 2/2/07, Andrew Borley <aj...@gmail.com> wrote:
>
> On 2/2/07, Simon Laws <si...@googlemail.com> wrote:
> > On 2/2/07, Andrew Borley <aj...@gmail.com> wrote:
> > >
> > > Hi Simon,
> > > I'm taking a look at them now. I'll let you know how I get on.
> > >
> > > Cheers
> > > Andy
> > >
> > > On 2/2/07, Simon Laws <si...@googlemail.com> wrote:
> > > > I've attached patches to add reference support to the PHP Extension
> (
> > > > https://issues.apache.org/jira/browse/TUSCANY-1089). This is a
> fairly
> > > major
> > > > change and there have been several build problems in getting this to
> > > work.
> > > > As it's been a bit of a struggle I'm keen to get someone else to
> help me
> > > try
> > > > in on other boxes because I'm still having problems on my
> configuration
> > > and
> > > > its not clear if it's me or if there are rela problems. Sharing via
> svn
> > > is
> > > > the best way to do this but I should mention that this won't work
> > > without
> > > > some changes to the SCA_SDO PECL extension which I'm in the process
> of
> > > > making at the moment. They aren't there just yet.
> > > >
> > > >
> > > > Simon
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > > Andy, just thinking that by defauly we may want to disable the
> automake
> > link to the PHP Extension and PHP Calculator sub projects because of
> course
> > they won't generally build unless you have your environment set up just
> so.
> > In the patches I left them enabled :-(
> >
> > Simon
> >
> >
> Hi Simon,
> The PHP extension & sample are by default disabled at the moment - you
> need to run "configure --enable-php" to build them on Linux. I've
> committed the patches (& aslo updated the windows vcproj file), but
> currently I'm failing to build on windows due to not having the PECL
> SCA_SDO stuff that you mentioned and also getting some weird DLL
> import and Winsock error messages... any ideas?
>
> Cheers
> Andy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> yes - if you look at the top of the PHPServiceWrapper you will see a
#define you have to uncomment to make it work on windows. This needs to be
in a #ifdef win32 or similar but I've been working on UNIX for the last 3
weeks so didn't go back to fixing it. Sorry
Simon
Re: [C++] SCA PHP Extension patches
Posted by Andrew Borley <aj...@gmail.com>.
On 2/2/07, Simon Laws <si...@googlemail.com> wrote:
> On 2/2/07, Andrew Borley <aj...@gmail.com> wrote:
> >
> > Hi Simon,
> > I'm taking a look at them now. I'll let you know how I get on.
> >
> > Cheers
> > Andy
> >
> > On 2/2/07, Simon Laws <si...@googlemail.com> wrote:
> > > I've attached patches to add reference support to the PHP Extension (
> > > https://issues.apache.org/jira/browse/TUSCANY-1089). This is a fairly
> > major
> > > change and there have been several build problems in getting this to
> > work.
> > > As it's been a bit of a struggle I'm keen to get someone else to help me
> > try
> > > in on other boxes because I'm still having problems on my configuration
> > and
> > > its not clear if it's me or if there are rela problems. Sharing via svn
> > is
> > > the best way to do this but I should mention that this won't work
> > without
> > > some changes to the SCA_SDO PECL extension which I'm in the process of
> > > making at the moment. They aren't there just yet.
> > >
> > >
> > > Simon
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> > Andy, just thinking that by defauly we may want to disable the automake
> link to the PHP Extension and PHP Calculator sub projects because of course
> they won't generally build unless you have your environment set up just so.
> In the patches I left them enabled :-(
>
> Simon
>
>
Hi Simon,
The PHP extension & sample are by default disabled at the moment - you
need to run "configure --enable-php" to build them on Linux. I've
committed the patches (& aslo updated the windows vcproj file), but
currently I'm failing to build on windows due to not having the PECL
SCA_SDO stuff that you mentioned and also getting some weird DLL
import and Winsock error messages... any ideas?
Cheers
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] SCA PHP Extension patches
Posted by Simon Laws <si...@googlemail.com>.
On 2/2/07, Andrew Borley <aj...@gmail.com> wrote:
>
> Hi Simon,
> I'm taking a look at them now. I'll let you know how I get on.
>
> Cheers
> Andy
>
> On 2/2/07, Simon Laws <si...@googlemail.com> wrote:
> > I've attached patches to add reference support to the PHP Extension (
> > https://issues.apache.org/jira/browse/TUSCANY-1089). This is a fairly
> major
> > change and there have been several build problems in getting this to
> work.
> > As it's been a bit of a struggle I'm keen to get someone else to help me
> try
> > in on other boxes because I'm still having problems on my configuration
> and
> > its not clear if it's me or if there are rela problems. Sharing via svn
> is
> > the best way to do this but I should mention that this won't work
> without
> > some changes to the SCA_SDO PECL extension which I'm in the process of
> > making at the moment. They aren't there just yet.
> >
> >
> > Simon
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> Andy, just thinking that by defauly we may want to disable the automake
link to the PHP Extension and PHP Calculator sub projects because of course
they won't generally build unless you have your environment set up just so.
In the patches I left them enabled :-(
Simon
Re: [C++] SCA PHP Extension patches
Posted by Andrew Borley <aj...@gmail.com>.
Hi Simon,
I'm taking a look at them now. I'll let you know how I get on.
Cheers
Andy
On 2/2/07, Simon Laws <si...@googlemail.com> wrote:
> I've attached patches to add reference support to the PHP Extension (
> https://issues.apache.org/jira/browse/TUSCANY-1089). This is a fairly major
> change and there have been several build problems in getting this to work.
> As it's been a bit of a struggle I'm keen to get someone else to help me try
> in on other boxes because I'm still having problems on my configuration and
> its not clear if it's me or if there are rela problems. Sharing via svn is
> the best way to do this but I should mention that this won't work without
> some changes to the SCA_SDO PECL extension which I'm in the process of
> making at the moment. They aren't there just yet.
>
>
> Simon
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org