javascriptdateserializationgwtgwt-rpc

De-serialize Date and Timestamp from GWT RPC payload for debugging purposes

I am trying to understand the data fields in the payload of my remote procedure calls. And Date together with Timestamp type objects confuse me the most.

The full request payload looks like:

7|0|8|https://myapp.com/myapp/client/|72119BCB4CE5FB8D147EA76E8006F76E|com.myapp.service.MyService|updateTimepoint|java.lang.String/2004016611|java.util.Date/3385151746|554455|java.sql.Timestamp/3040052672|1|2|3|4|2|5|6|7|8|VhGcuow|0|

The interface of this service as it is defined in the code is:

public void updateTimepoint(String myId, Date timepoint,
                    AsyncCallback<Void> async);

From that array of values above, I would tell that bold parts (see below) refer to sent java.util.Date object and "554455" in the middle - is the myId (I know that from the use case). I have no explanation why myId variable was put in the middle:

java.util.Date/3385151746|554455|java.sql.Timestamp/3040052672

Now I'm debugging the obfuscated code, so looking at the Source tab in browser seems like not an option. That won't help a lot though, as you would see weird JS date references. Which I'm not sure how to read either.

So, how would I compile Date+Timestamp from payload vars back into something readable?

Thank you!

P.S. Or - is VhGcuow a Date? As per GWT java.util.Date serialization

Solution

  • As @RobG said, those numbers are not the values, but details about the Date, Timestamp types. The payload is | delimited, those /s are part of the classname string. See Serializing RPC-GWT (an answer by me earlier this year) for more details on the order of the strings and other content in the payload.

    VhGcuow is likely a base64-encoded long. Dates (and possibly Timestamps, though I havent checked) are serialized as a long field, so that value as a long would then represent the number of milliseconds since Jan 1, 1970. See RPC-GWT Serialization/java.util.Date Encoding for more discussion on how that can be understood and decoded, without simply trusting that RPC works.

    Do note though that RPC hasn't changed in years, and is in use by 10s or 100s of thousands of GWT developers, who havent not had issues with Date serializing correctly. More likely something else is afoot (like timezone issues) - asking another question with all of the details of your problem and a "working" test case might get you to your answer more quickly.