views:

428

answers:

2

We have been using Spring Remoting in our project for sometime. It is used with some other systems to access our web-services. We are currently evolving in terms of what parameters web service takes; but at the same time we are trying to be independent of our consumers.

So, currently my question is around how serialization and deserialization works in spring remoting. Here are the details:

I have a web-service exposed through spring remoting which has following parameters in a class

  1. name
  2. age
  3. address

Currently all consumers use the respective stubs and serialization and deserialization happens accordingly.

As I mentioned we evolved our web service and class respectively to contain following fields now"

  1. name
  2. age
  3. address
  4. country
  5. dateOfBirth

However consumers still have old stubs or rather stub-jar to access the web service. We did a spike and it seems that irrespective of newly added fields at our ends the remoting service continues to work fine. I was expecting it to bomb at consumers' end since the number of fields have been added. "PLEASE NOTE NO FIELDS HAVE BEEN DELETED/REMOVED FROM CLASS". Only additions have been made.

Does spring remoting handles additional fields gracefully or I should expect it to crib?

Let me know if my question is not clear at any point. The ultimate question that I am trying to put forward is, should I be expecting my program to bomb? And it's not failing currently as I am not testing something correctly? How does spring remoting serialize and deserialize the objects that are being exchanged?

+1  A: 

I thought Spring remoting was based on HTTP, not Java serialization. If that's the case, these are parameter name/value pairs, and as long as you haven't taken away parameters that existing clients expect it should continue to work.

Please check on this, skaffman. Your knowledge of Spring is excellent, and I'm on vacation right now. I'd be rude to stay longer on my friend's computer and research the topic. Sorry I can't be more helpful.

duffymo
Spring's HTTP invoker still uses standard Java serialization at the bottom. I have been deep in its guts as I needed to fix the de-serialization for use in OSGi.
hbunny
This is correct, Spring's HttpInvoker delivers java-serialized objects over an HTTP transport.
skaffman
Thanks guys for all the inputs. It did indeed pointed me in right direction.
Priyank
+1  A: 

Spring serialisation obeys the rules of Java serialisation.

Verify that change did indeed affect the serialVersionUID and that you're not providing one yourself, which has not changed.

Robert Munteanu
Thank you. I did kept the serialVersionUID unchanged and that clearly explains why my remoting stubs and classes continue to work still. Cheers
Priyank