On 22/01/07, Simon Laws <[EMAIL PROTECTED]> wrote:
On 1/21/07, Pete Robbins <[EMAIL PROTECTED]> wrote: > > Simon, > > this code is in the extension that handles C++ components so we expect the > implementation to be C++. This is not the "default" proxy. This code will > be > invoked because the definition of the component is an implementation.cpp . > There is similar code in e.g. the ruby RubyServiceProxy that will handle > implementation.rb. > > Hope this helps. > > Cheers, > > > On 21/01/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > The default C++ proxy currently seems to assume that its always trying > to > > talk to a C++ service. Line 104 of CPPServiceProxy looks like > > > > // If we got here we have a CPP implementation > > CPPImplementation* impl = (CPPImplementation > > *)componentType; > > > > Did I understand this correctly? If so why is this the case? > > > > Regards > > > > Simon > > > > > > > -- > Pete > > Thanks for the reply Pete. I'm still not sure I understand this. What is the role of the CPPServiceProxy intended to be. I would guess, just going on the name, that it is intended to be the CPP proxy for services as opposed to a proxy for CPP services. But I guess I'm missing something. The reason I'm asking the question is that I wanted to set up a local CPP client for my PHP component. I couldn't get SCA to do this directly, i.e. CPP Client --> PHP Component I had to put a CPP component in the way to make it work CPP Client --> CPP Component --> PHP Component Which struck me as a little strange. I expect my error lies in the way that I get hold of the context, locate the service or something else. Clearly there is a proxy somewhere that is able to talk to my PHP component from CPP. How do I get an instance of this one in the CPP client? Regards Simon
Ah. I see. The client interface using CompositeContext is not great. It feels to me like a hack to allow non-SCA code to be logically part of a composite. It is only for accessing a C++ component from a client. For a component implementation the proxies are generated for each reference and wrappers are generated for each service (using scagen) and are compiled in to the component implementation. For a c++ client this is not possible so a proxy is generated for each service and this becomes part of the component implementation. This is why the client has to get a C++ proxy from the component implementation... which means it has to be a C++ implementation first! Maybe we can re-think this and find a way to return a service proxy for a non-C++ component via CompositeContext (the proxy itself will still have to be a generate C++ proxy and we do not want to have to link this with the client code so where will it live?) Something to think about but for now you will have to have you CPP Component as the entry point from the CPP client. Cheers, -- Pete
