Ok, thanks Raymond. So basically what you are saying it doesn't work over web services hence it won't over the remote SCA binding. A few more comments below.
Simon On 9/2/07, Raymond Feng <[EMAIL PROTECTED]> wrote: > > Hi, > > Please see my comments inline. > > Thanks, > Raymond > > ----- Original Message ----- > From: "Simon Laws" <[EMAIL PROTECTED]> > To: "tuscany-dev" <[email protected]> > Sent: Sunday, September 02, 2007 7:48 AM > Subject: CallableReference servialization > > > > I've been playing around with the new CallableReference support and > > thought > > I would add a test to itest-callablereference to repeat all the tests > but > > using the remote SCA Binding in some cases. > > > > Can I assume that CallableReference serialization is not done yet. I put > a > > test in but it fails as the infrastructure doesn't know how to > deserialize > > a > > callable reference. I looked a little closer and found > > The serialization/deserialization support is done but not fully tested > with > the remote SCA bindings. There is a test case in the > itest-callablereferences where the DComponentImpl serialize and > deserialize > a service reference. I have added a new set of test composite that separate AComponent and DComponent into one node and BComponent and CComponent in another node. The intention being to see the CallableReference sent remotely between AComponent and BComponent. This is not checked in due to the problems with auto generated WSDL and operations with no parameters. It felt like cheating to give all the operations parameters just to get round this :-) > > > - The CallableReference doesn't have a no parameter constructor. Also > can > > someone explain how the infrastructure knows it has to fluff up a > > CallableReferenceImpl if it finds an operation taking a > CallableReference > > interface? It doesn't know at the moment and tries to instantiate the > > interface but how is it intended that it knows? > > There is a no-arg constructor for CallableReferenceImpl() and it's > protected > at this moment. It's good enough for java deserialization to work. The > deserialized CallableReference will get the information on the Thread to > fully resolve the runtime context. Apologies Raymond I was more interested in the remote case which you cover below. > > > - Only a small amount of data is written out when you serialize it in > the > > first place. This was the SOAP message that was produced > > > > POST /BComponent HTTP/1.1 > > Content-Type: text/xml; charset=UTF-8 > > SOAPAction: "urn:fooC" > > User-Agent: Axis2 > > Host: localhost:8086 > > Content-Length: 375 > > > > <?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope xmlns:soapenv=" > > http://schemas.xmlsoap.org/soap/envelope/";><soape > > nv:Body><_ns_:fooC xmlns:_ns_=" > > http://callableref.itest.sca.tuscany.apache.org/xsd";><param0 xmlns=" > > http://callableref.it > > est.sca.tuscany.apache.org/xsd"><conversationID xmlns="" /><callback > > xmlns="" /></param0></_ns_:fooC></soapenv:Body></so > > apenv:Envelope> > > > > How the binding provider propagate the CallableReference/ServiceReference > is > related but a different feature. We have opened TUSCANY-1634 to track > this. > Starting with binding.ws will be a good exercise. In the case of the BComponent method public String fooC(CallableReferenceImpl<CComponent> cReference) { Why would this be any different from passing any other complex types across the SCA remote binding? I see the comments about passing references outside of SCA but not sure I understand all the implications of this yet. > Regards > > > > Simon > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
