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

http 500/serialization policy issues #13

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

http 500/serialization policy issues #13

GoogleCodeExporter opened this issue Mar 21, 2015 · 8 comments

Comments

@GoogleCodeExporter
Copy link

I'm trying to use gwt-syncproxy for integration testing.  

One of the challenges is that I will not have the policy file of the selected 
system available in the test classpath.  (in addition, it's a lot of 
organizing/tracing/copying to do this, and in some cases a lot of policy files)

Attached is an attempt to retrieve the policy name from the server, instead of 
just trying to guess.  It works 80% of the time, but not 100%. I'm hoping 
someone with better knowledge can help cleanup and automate the 
detecting/using/retrieval of the policy file so it does not have to be in the 
test classpath (and can instead be retrieved from the test system/server).

Original issue reported on code.google.com by [email protected] on 17 Feb 2011 at 4:13

Attachments:

@GoogleCodeExporter
Copy link
Author

hmm...the reason I had to do the above/find the policy is I could not get the 
non-policyname-paramater to work.

newProxyInstance(class, url, service)  

I've always had to add the policyname as the 4th param before it would work, 
and it was clunky at best.

I think I found the issue: For some reason, the setRequestProperty was not 
quite working right:

RemoteServiceSyncProxy.doInvoke

In between the RpcRequestBuilder.STRONG_NAME_HEADER property set, and the 
Content-Type set, I added a buffer RequestProperty ("na", "na"), which although 
it sounds silly, seems to have corrected the HTTP headers going to the server 
so it now works fine for me.


Original comment by [email protected] on 17 Feb 2011 at 5:39

@GoogleCodeExporter
Copy link
Author

tested with syncproxy 0.2 codebase

Original comment by [email protected] on 17 Feb 2011 at 5:40

@GoogleCodeExporter
Copy link
Author

spoke too soon, still serialization issues, but the above Content-Type was 
still an issue anyway, just not what is stopping this from becoming easier to 
use.

Original comment by [email protected] on 17 Feb 2011 at 5:44

@GoogleCodeExporter
Copy link
Author

Usecase:  multiple modules for one application, leading to multiple 
serialization policy files for the same application that is getting tested.

Original comment by [email protected] on 17 Feb 2011 at 7:56

@GoogleCodeExporter
Copy link
Author

removed GuessMyGwt attachment, replacing with 'AutoSyncProxy' patch.

Minor, non-invasive changes to DefaultSessionManager and 
RemoveServiceSyncProxy, new classes 'AutoSynchProxy' and 'RpcFinderUtil'.

Instead of SyncProxy, use:

AutoSyncProxy.newProxyInstance(MyService.class, baseurl, "MyService");

This will remove the need to have a local copy of the .gwt.rpc files
in the classpath, and instead pull them from the tested server (based on the 
url)
and put in-memory the SerializationPolicy object.  Little heavier memory/cpu 
wise,
but a lot more convenient.


Original comment by [email protected] on 18 Feb 2011 at 9:14

Attachments:

@GoogleCodeExporter
Copy link
Author

Thanks for your patch.

Base on your patch, I make a new class RpcPolicyFinder which try to find the 
policy files in classpath and also auto fetch from server.

Download the version 0.3 and make a try.

Original comment by [email protected] on 20 Aug 2011 at 4:03

@GoogleCodeExporter
Copy link
Author

Enhanced in version 0.3

Original comment by [email protected] on 23 Aug 2011 at 2:29

  • Changed state: Fixed

@GoogleCodeExporter
Copy link
Author

Sorry for the late response - in my test scenario where I built the 
AutoSyncProxy it does not appear to be behaving correctly (version number 
incompatible, even when in it's own project without any other local RPC files 
around).

I checked out of source 1/31/2012, and similar issues.  When I comment out the 
SERIALIZATION_STREAM_MIN_VERSION block in prepareToRead of 
SynClientSerializationStreamReader, get a little farther but none of the 
complex datatypes can be deserialized (and one of my other methods is failing 
that was working with AutoSyncProxy, need some more time to research that one).

Original comment by [email protected] on 31 Jan 2012 at 4:10

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