Java Objects only make sense inside a JVM, the only way to export one is serialization.
If you want to stick to the standard industry understanding of what SOAP is, you will extract variables as SOAP standard data types.
What is your problem that you think this is necessary?
Joined: Apr 06, 2010
My problem is little complicated, Here's my problem:
3rd party class: (unserialized- Not Open source)
Another Class: Gateway.java.
Service expose this method of Gateway.java. This will query database gets results in form of 3rd party API's instance
I want to capture all the properties of QueryResult class, plus additional properties for SubclassDAO set by Gateway.java and pass to the client.
I just want to transfer unserilazed object as SOAP response. One way is to get all properties of QueryResult and assign it to SubclassDAO (which can implement serialization) and send that instance back to client. But the processing of QueryResult object is very expensive and client can not wait that long.
So if I want to transfer the QueryResult instance to client then I can start background thread to get its properties and my GUI wont be freezed.
How can I do that.
Author and all-around good cowpoke
Joined: Mar 22, 2000
I just want to transfer unserilazed object as SOAP response.
How is the SOAP client supposed to interpret this "unserialized object"??
Those "result" objects sound like they are tied to a particular database query and tie up database resources - a sure potential for hard to debug crashes if they use up database connections or other resources.
Just to repeat my advice - extract the data to standard variable types that SOAP toolkits understand.