Re: [ecf-dev] ECF not serializing changed method arguments (generic serv

[Konrad Bielak <konrad.bielak@xxxxxxxxx>]

Hi Scott,

Thank you for your reply.

Unfortunately I'm bound to interface generated by external tool and
can't change anything :( All I can do is subclass, Holder class is
forced by this tool [1]

The design here is Server (form of proxy) <----ECF----> Client, where
proxy is automatically generated from WSDL file.

What if I use r-OSGi? Would this help? I'm already using OSGI environment.

 [1] http://cxf.apache.org/docs/wsdl-to-java.html

Konrad Bielak

2012/4/12 Scott Lewis <slewis@xxxxxxxxxxxxx>:
> Hi Konrad,
>
>
> On 4/12/2012 11:38 AM, Konrad Bielak wrote:
>>
>> Hello,
>>
>> Suppose `person` is an ECF proxy object implementing Person interface
>> with getPerson() method. getPerson() has some parameters, and these
>> parameters are Holder [1] class (which means there is another object
>> reference inside).
>>
>> Now, consider following Consumer endpoint code:
>>
>>  Holder<String>  personId = new Holder<String>("Person from OSGi bundle");
>>  Holder<String>  ssn = new Holder<String>("1");
>>  Holder<String>  name = new Holder<String>("1");
>>
>>  logger.info("--->  SENDING data: personId=" + personId.value + "
>> ssn=" + ssn.value + " name=" + name.value);
>>  person.getPerson(personId, ssn, name);
>>  logger.info("<--- Returned data: personId=" + personId.value + "
>> ssn=" + ssn.value + " name=" + name.value);
>>
>> on Provider endpoint on another OSGi container `ssn` and `name` inside
>> values are changed. But consumer wont know about this, because ECF
>> does not serialize these objects again when returning from method
>> getPerson(). Log:
>> --->  SENDING data: personId=Person from OSGi bundle ssn=1 name=1
>> <--- Returned data: personId=Person from OSGi bundle ssn=1 name=1
>>
>> Is there any way to serialize these objects again on Provider endpoint?
>
>
> Well...if I'm understanding you correctly, then you could implement
> Person.getPerson(String,String,String) like this:
>
> public Person getPerson(String personId, String ssn, String value) {
>      return new SerializablePerson(personId,ssn,value);
> }
>
> And assuming that Person was Serializable, then I think this would do what
> you want to do.
>
> But this seems a little unnatural to me...so have you considered that rather
> than trying to reference the members in Person (person.ssn, person.name,
> etc)...it might be simpler/clearer to have a structure where the top-level
> service interface was something like:
>
> // This is the (remote) service interface
> public interface PersonManager {
>
> public Person getPerson(String personId);
> public Person createPerson(String personId, String ssn, String name);
> etc.
>
> }
>
> with the Person param being...
>
> public class Person implements Serializable {
>
> private String id;
> private String ssn;
> private String name;
>
> public Person(String id, String ssn, String name) {
>   this.id = id;
>   this.ssn = ssn;
>   this.value = name;
> }
>
> public String getId() {
>   return id;
> }
>
> public String getSSN() {
>   return ssn;
> }
>
> public String getName() {
> }
>   return name;
> }
>
> And then consumers of the PersonManager remote service would call:
>
> Person person = person.createPerson("1","333-33-3333","howdy");
> // work with Person fields locally
> // However...host (db?) instance of Person changes (by some other usage,
> etc), then
> // the remote service consumer would need to get a refresh:
> updatedPerson = personManager.getPerson(newPerson.getId());
>
> If...alternatively...you are asking if there is some way that the local
> values of Person (id, ssn, value) could be updated *automatically* on the
> remote service consumer process when they change on the host process...then
> the answer is 'no'...unless you are using a remoting system that supports
> pass-by-reference rather than pass-by value.  Most remoting systems these
> days only do pass-by-value...since pass-by-reference has lots of
> complications (e.g. garbage collection, failure handling, remote references,
> etc) that are extremely thorny.  None of the current ECF providers...except
> the RMI provider...do only pass-by-value.  And all the REST-based
> approaches, etc are all pass-by-value.
>
> <stuff deleted>
>
>
> BTW Pax-Runner script for ECF4Felix [2] is outdated.
>
>  [1] http://docs.oracle.com/javase/6/docs/api/javax/xml/ws/Holder.html
>  [2] https://github.com/ECF/ECF4Felix
>
> [Scott]  Ok...Markus would be able to take a look at updating this?
>
> Thanks,
>
> Scott
>
>
>
> _______________________________________________
> ecf-dev mailing list
> ecf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ecf-dev



-- 
Konrad Bielak