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