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.
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
