Sign Up

Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.

Have an account? Sign In

Have an account? Sign In Now

Sign In

Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.

Sign Up Here

Forgot Password?

Don't have account, Sign Up Here

Forgot Password

Lost your password? Please enter your email address. You will receive a link and will create a new password via email.

Have an account? Sign In Now

You must login to ask a question.

Forgot Password?

Need An Account, Sign Up Here

Please briefly explain why you feel this question should be reported.

Please briefly explain why you feel this answer should be reported.

Please briefly explain why you feel this user should be reported.

Sign InSign Up

The Archive Base

The Archive Base Logo The Archive Base Logo

The Archive Base Navigation

  • Home
  • SEARCH
  • About Us
  • Blog
  • Contact Us
Search
Ask A Question

Mobile menu

Close
Ask a Question
  • Home
  • Add group
  • Groups page
  • Feed
  • User Profile
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Buy Points
  • Users
  • Help
  • Buy Theme
  • SEARCH
Home/ Questions/Q 8434571
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Editorial Team
Asked: June 10, 20262026-06-10T06:41:34+00:00 2026-06-10T06:41:34+00:00

When the new version of app is deployed with changes to the model classes

  • 0

When the new version of app is deployed with changes to the model
classes (for example adding/removing fields ).
Client who has old version running gets
com.google.gwt.user.client.rpc.SerializationException with the RPC
made with the old client code and this is expected behavior.
As a result we expect to see IncompatibleRemoteServiceException on the client side.
However we get StatusCodeException.

StatusCodeException is 500 error and we can’t customize the client
side behavior easily (we don’t want to assume every
StatusCodeException or 500 error is a new version) . What could we
be doing wrong here?

Note: On the server side (log) we get SerializationExcepion obviously since the serialization policy from the old client is no longer valid with the new server. So Why not throwing IncompatibleRemoteServiceException?

Thanks.

  • 1 1 Answer
  • 0 Views
  • 0 Followers
  • 0
Share
  • Facebook
  • Report

Leave an answer
Cancel reply

You must login to add an answer.

Forgot Password?

Need An Account, Sign Up Here

1 Answer

  • Voted
  • Oldest
  • Recent
  • Random
  1. Editorial Team
    Editorial Team
    2026-06-10T06:41:36+00:00Added an answer on June 10, 2026 at 6:41 am

    Here’s my solution facing that issue:

    First extend RemoteServiceServlet (all your service servlets will extend from this new class, remember this is server code). This is the relevant code in there:

    @Override
    protected SerializationPolicy doGetSerializationPolicy(
            HttpServletRequest request, String moduleBaseURL, String strongName) {
        SerializationPolicy sp = super.doGetSerializationPolicy(request,
                                       moduleBaseURL, strongName);
        if(sp == null) { //no policy found, probably wrong client version
            throw new InvalidPolicyException();
        }
        return sp;
    }
    

    and

    @Override
    protected void doUnexpectedFailure(Throwable e) {
        if(e instanceof InvalidPolicyException) { 
            sendError(); //send message to reload client (wrong client version)
            return; //that's it
        }
        super.doUnexpectedFailure(e);
    }
    

    The private method sendError() is basically a customized copy from GWT 500 error code (sorry for the ugly Google indentation)

    private void sendError() {
        ServletContext servletContext = getServletContext();
        HttpServletResponse response = getThreadLocalResponse();
        try {
              response.setContentType("text/plain");
              response.setStatus(HttpServletResponse.SC_CONFLICT);
              try {
                response.getOutputStream().write("wrong client version".getBytes("UTF-8"));
              } catch (IllegalStateException e) {
                // Handle the (unexpected) case where getWriter() was previously used
                response.getWriter().write("wrong client version");
              }
            } catch (IOException ex) {
              servletContext.log(
                  "sendError failed while sending the previous custom failure to the client", ex);
            }
    }
    

    I used HttpServletResponse.SC_CONFLICT (409) but you can probably use a clever error code. The message written is not really important.

    Then in your custom RpcRequestBuilder (this is the client code)

    public class CustomRequestBuilder extends RpcRequestBuilder {
    
     private class RequestCallbackWrapper implements RequestCallback {
    
            private RequestCallback callback;
    
            RequestCallbackWrapper(RequestCallback aCallback) {
                this.callback = aCallback;
            }
    
            @Override
            public void onResponseReceived(Request request, Response response) {
                if(response.getStatusCode() == 409) { //wrong client version
                    Navigator.closeEveryPopUp();
                    Navigator.showUncloseablePopUp("Login again!", 
                                    new ClickHandler() {
    
                        @Override
                        public void onClick(ClickEvent event) {
                            //reload your $#%^ client!!!
                            Window.Location.reload();
                        }
                    });
                } else {
                    //(...)irrelevant security code here(...)
                    callback.onResponseReceived(request, response);
                }
    
            }
    
            @Override
            public void onError(Request request, Throwable exception) {
                callback.onError(request, exception);
            }
    
     }
    
     @Override
     protected void doFinish(RequestBuilder rb) {
        //(...)more irrelevant security code here(...)
        super.doFinish(rb);
        rb.setCallback(new RequestCallbackWrapper(rb.getCallback()));
     }
    }
    

    We use multiple popups, that’s one reason for the Navigator class; of course use your own style there to warn the user.

    EDIT: What’s going on here?

    Until GWT 1.3.3 IsSerializable was the only interface available to mark a class as GWT RPC serializabled. The next version accepted Java standard Serializable interface for the same purpose, but adding the requirement of a security policy for objects implementing this interface. By default GWT generate a policy for each compilation with a unique hash name. An old client trying to transfer object marked as Serializable will throw at server side a serialization policy exception that will be received at client side as a generic runtime error. IsSerializable allows the old clients to still use the new services as long as the signature remains the same. This means that an alternate solution for this question is to mark every object going thru GWT RPC as IsSerializable. But if for some reason you need your objects not to be referenced to a GWT interface, this is a nice solution for old clients connections.

    Check GWT’s guide for more details regarding the 1.3.3 fallback.

    • 0
    • Reply
    • Share
      Share
      • Share on Facebook
      • Share on Twitter
      • Share on LinkedIn
      • Share on WhatsApp
      • Report

Sidebar

Related Questions

I just submitted a new version of our app to the Apple app store,
I've a new version of an App that's ' waiting for review' and when
I'm currently testing a new version of an app of mine on OSX 10.5
I have submitted a new version of my iPhone App and the status is
I need to submit to the Apple app store a new version of my
What is the proper way to redeploy a new version of a running app
The new version of SQLite has the ability to enforce Foreign Key constraints, but
In the new version of Bouncy Castle library there are changes in PKCS10CertificationRequest .
I have a GWT app deployed onto our client's machines. As an ongoing development
I'm pretty new to this whole deployment thing. I've deployed my app once before

Explore

  • Home
  • Add group
  • Groups page
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Users
  • Help
  • SEARCH

Footer

© 2021 The Archive Base. All Rights Reserved
With Love by The Archive Base

Insert/edit link

Enter the destination URL

Or link to existing content

    No search term specified. Showing recent items. Search or use up and down arrow keys to select an item.