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/01/21 20:00:24 UTC
[C++] C++ Proxy assumes C++ Service implementation?
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
Re: [C++] C++ Proxy assumes C++ Service implementation?
Posted by Simon Laws <si...@googlemail.com>.
On 1/22/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Pete Robbins wrote:
> > On 22/01/07, Simon Laws <si...@googlemail.com> wrote:
> >>
> >> On 1/21/07, Pete Robbins <ro...@googlemail.com> 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 <si...@googlemail.com> 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,
> >
>
> Connecting the C++ ServiceProxy to a ServiceWrapper wrappering a non-C++
> component implementation is easy, but the real issue is that the SCA C++
> C&I spec does not define an attribute to specify which DLL contains the
> (generated) C++ proxy outside of of a <implementation.cpp>, which you
> don't have when your component is not written in C++.
>
> I suggest to raise an SCA spec issue for this, and in the meantime,
> package these proxies in a library with a name derived from the name of
> the composite or the name of the target component, or as Pete suggested
> continue to use an intermediate C++ component as an entry point from the
> C++ client.
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> Pete, Jean-Sebastien, thanks, I think I understand the issue now. I'm
happy with the intermediate for what I'm doing at the moment. If a proxy is
absolutely required for use in C++, i.e. you are not using some dynamic
invocation based on direct access to the "operation" structure, then I guess
it could either be generated into a component DLL (don't have one for PHP at
the moment but we could) in the off chance that a C++ component will want to
call it or into a special DLL that collects all the scripting C++ proxies
together. Can't we infer what the DLL will be called in this case as the DLL
should be something generated automatically by the systems.
In the case that we rely on annotations in the script to define the
interface we also need a feasible mechanism whereby C++ proxies can be
generated in the absence of compile time ".h" information. We could, of
course, extend scagen to scan the script for the information. This extra
proxy generation and compile step feels at odds with the way people write
scripts so this certainly needs some deeper though.
Regards
Simon
Re: [C++] C++ Proxy assumes C++ Service implementation?
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Pete Robbins wrote:
> On 22/01/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>
>> Pete Robbins wrote:
>> > On 22/01/07, Simon Laws <si...@googlemail.com> wrote:
>> >>
>> >> On 1/21/07, Pete Robbins <ro...@googlemail.com> 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 <si...@googlemail.com> 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,
>> >
>>
>> Connecting the C++ ServiceProxy to a ServiceWrapper wrappering a non-C++
>> component implementation is easy, but the real issue is that the SCA C++
>> C&I spec does not define an attribute to specify which DLL contains the
>> (generated) C++ proxy outside of of a <implementation.cpp>, which you
>> don't have when your component is not written in C++.
>>
>> I suggest to raise an SCA spec issue for this, and in the meantime,
>> package these proxies in a library with a name derived from the name of
>> the composite or the name of the target component, or as Pete suggested
>> continue to use an intermediate C++ component as an entry point from the
>> C++ client.
>>
>> --
>> Jean-Sebastien
>
>
> I do not think this is a spec isue. The spec does not mention
> proxies/wrappers, that is just our Tuscany implementation.
>
> I never liked the client story in the SCA specs, it seems like a hack,
> but
> we followed the Java model. To me a more logical client interface
> would have
> been to define a service in the composite with a binding.cpp to be the
> entry
> point in to SCA from a C++ client, similar to how we expose a service
> as a
> ws binding.
> Cheers,
>
Independent of runtime specific proxies/wrappers,
CompositeContext.locateService(...) returns an implementation of a C++
class. If it was a Java interface, the SCA spec would have to specify
how the interface class is resolved (or state that it's runtime specific
or specific to how you're packaging your application for example, but at
least say something about it). I think that it's the same for C++ and
that the spec needs to address the resolution of that class, even if
it's just to say that the resolution algorithm is runtime specific.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] C++ Proxy assumes C++ Service implementation?
Posted by Pete Robbins <ro...@googlemail.com>.
On 22/01/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Pete Robbins wrote:
> > On 22/01/07, Simon Laws <si...@googlemail.com> wrote:
> >>
> >> On 1/21/07, Pete Robbins <ro...@googlemail.com> 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 <si...@googlemail.com> 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,
> >
>
> Connecting the C++ ServiceProxy to a ServiceWrapper wrappering a non-C++
> component implementation is easy, but the real issue is that the SCA C++
> C&I spec does not define an attribute to specify which DLL contains the
> (generated) C++ proxy outside of of a <implementation.cpp>, which you
> don't have when your component is not written in C++.
>
> I suggest to raise an SCA spec issue for this, and in the meantime,
> package these proxies in a library with a name derived from the name of
> the composite or the name of the target component, or as Pete suggested
> continue to use an intermediate C++ component as an entry point from the
> C++ client.
>
> --
> Jean-Sebastien
I do not think this is a spec isue. The spec does not mention
proxies/wrappers, that is just our Tuscany implementation.
I never liked the client story in the SCA specs, it seems like a hack, but
we followed the Java model. To me a more logical client interface would have
been to define a service in the composite with a binding.cpp to be the entry
point in to SCA from a C++ client, similar to how we expose a service as a
ws binding.
Cheers,
--
Pete
Re: [C++] C++ Proxy assumes C++ Service implementation?
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Pete Robbins wrote:
> On 22/01/07, Simon Laws <si...@googlemail.com> wrote:
>>
>> On 1/21/07, Pete Robbins <ro...@googlemail.com> 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 <si...@googlemail.com> 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,
>
Connecting the C++ ServiceProxy to a ServiceWrapper wrappering a non-C++
component implementation is easy, but the real issue is that the SCA C++
C&I spec does not define an attribute to specify which DLL contains the
(generated) C++ proxy outside of of a <implementation.cpp>, which you
don't have when your component is not written in C++.
I suggest to raise an SCA spec issue for this, and in the meantime,
package these proxies in a library with a name derived from the name of
the composite or the name of the target component, or as Pete suggested
continue to use an intermediate C++ component as an entry point from the
C++ client.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] C++ Proxy assumes C++ Service implementation?
Posted by Pete Robbins <ro...@googlemail.com>.
On 22/01/07, Simon Laws <si...@googlemail.com> wrote:
>
> On 1/21/07, Pete Robbins <ro...@googlemail.com> 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 <si...@googlemail.com> 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
Re: [C++] C++ Proxy assumes C++ Service implementation?
Posted by Simon Laws <si...@googlemail.com>.
On 1/21/07, Pete Robbins <ro...@googlemail.com> 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 <si...@googlemail.com> 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
Re: [C++] C++ Proxy assumes C++ Service implementation?
Posted by Pete Robbins <ro...@googlemail.com>.
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 <si...@googlemail.com> 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