Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Response deserialization ClassNotFoundException #36

Closed
GoogleCodeExporter opened this issue Mar 21, 2015 · 8 comments
Closed

Response deserialization ClassNotFoundException #36

GoogleCodeExporter opened this issue Mar 21, 2015 · 8 comments

Comments

@GoogleCodeExporter
Copy link

1. We use gxt  and gwt 2.0.4
2. At response decoding of a heavy complex object we get a 
classnotfoundexception.
3. The application gwt js layer deals fine with this object.


What is the expected output? What do you see instead?
Normal decode of the response 

What version of the product are you using? On what operating system?
We test using 0.3 and 0.4 versions


We have a complex object return in some services , the service call is correct 
but at response deserialization we get a classnotfoundexception. looking in the 
response payload we have this part :

"rO0ABXcEAAAAAA==" and  syncproxy is looking for a class with this name.

I attached the console output that contains the trace and the Response payload.

Thanks

Original issue reported on code.google.com by [email protected] on 16 May 2014 at 7:22

Attachments:

@GoogleCodeExporter
Copy link
Author

Off the top, I can say this library has not been recently tested against GWT 
2.0.4, and I suspect the presence of the "rO0ABXcEAAAAAA==" sequence may have 
been part of the that version of GWT. Since this is a client side library only, 
the sequence in question is definitely being sent back by your version of GWT 
(2.0.4), and as it's not in a typical class/code definition format, I can 
imagine it had some other meaning back in 2.0.4. However, I've been unable to 
find any reference to this type of inclusion. I will keep this issue open with 
the possibility of writing a switch to ignore such a sequence (optionally 
activated), but I won't be able to guarantee proper deserialization without 
understanding it so I'm hesitant to do this unless there is a real need for 
such a work-around.

My primary recommendation is to see if you can upgrade to a more recent version 
of GWT (2.5 or higher) and see if that resolves the issue. Please advise

Original comment by [email protected] on 17 May 2014 at 6:46

@GoogleCodeExporter
Copy link
Author

Hi,

Thanks for your response.

We have tested using GWT 2.1.1 and we get the same issue.
Using the same request over the same service we get the string rO0ABXcEAAAAAA== 
and classnotfoundexception. 

This string changes if we return other object and different data,We have the 
same issue with all our services.

Unfortunately We can´t upgrade our application to a GWT version over 2.1.1 
because We have some incompatibilities with newer versions.



Original comment by [email protected] on 17 May 2014 at 9:28

@GoogleCodeExporter
Copy link
Author

I've moved this status to PatchesWelcome for the time being. If you are able to 
patch and test a viable solution, please submit it and I will integrate it. If 
not, I will work on this issue with the next release to provide a solution as I 
described before. At the moment, I cannot provide a definitive timeline for a 
fix (hoping in the next few months), but I will update this issue when I can.

Original comment by [email protected] on 18 May 2014 at 1:31

  • Changed state: PatchesWelcome

@GoogleCodeExporter
Copy link
Author

Hi,

I found a fix to this issue.
When the objects are serialized gwt first check if there are server fields for 
each object class.
This is evaluated using serializationPolicy.getClientFieldNamesForEnhancedClass 
method, if this method returns something , there is a encoded byte array in the 
string table with those fields. So I ignore that field if there is a return 
value.

I have modified 

SyncClientSerializationStreamReader class

method private void deserializeClass(Class<?> instanceClass, Object instance)

and at the beggining I put this:

        //if there are server fields ignore them
        if(serializationPolicy.getClientFieldNamesForEnhancedClass(instanceClass)!=null){
            int encodedPosition=readInt();
            System.out.println("Encoded server field found for class:"+instanceClass+" with value: "+getString(encodedPosition));
        }


This protocol rule could be found here:

https://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/com/go
ogle/gwt/user/server/rpc/impl/ServerSerializationStreamWriter.java#716

Now our objects are correctly decoded.


Original comment by [email protected] on 20 May 2014 at 2:44

@GoogleCodeExporter
Copy link
Author

Patch recommendation accepted. I will look into incorporating this fix into the 
next release along with appropriate testing. Thank you for the fix!

Original comment by [email protected] on 23 May 2014 at 6:29

  • Changed state: Accepted
  • Added labels: Usability

@GoogleCodeExporter
Copy link
Author

I have applied this patch and it does not seem to affect any of my current 
tests. I would like to put in place some specific testing to this scenario, but 
I'm not specifically familiar with the server-side only fields that are being 
serialized. Can you provide a sample class that would be serialized with such 
fields so that I can put in place some basic testing. I'll be releasing the 0.5 
library this weekend, but I would like to have some testing in place for the 
next version in case there are other changes in the GWT base code. Thanks

Original comment by [email protected] on 9 Jan 2015 at 4:36

  • Changed state: CompletePending
  • Added labels: Milestone-Release0.5

@GoogleCodeExporter
Copy link
Author

Issue 15 has been merged into this issue.

Original comment by [email protected] on 9 Jan 2015 at 9:05

@GoogleCodeExporter
Copy link
Author

SyncProxy library version 0.5 is now available

Original comment by [email protected] on 11 Jan 2015 at 4:33

  • Changed state: Fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant