Во-первых, я не думаю, что этот «рецепт» хорош.RemoteServiceServlet дает вам ловушки для загрузки соответствующей политики сериализации для запроса, которая предназначена для того, чтобы "старые клиенты" могли общаться с "новыми серверами", и по умолчанию она должна работать правильно: просто разверните новый код вдоль стороныстарый (вы можете оставить старые * .cache.html и * .cache.js на некоторое время перед их удалением, чтобы облегчить миграцию клиентов без проблем с GWT.runAsync; важно то, что вы сохраняете старый *.gwt.rpc файлы на сервере).
Обратите внимание, однако, что с помощью RequestFactory гораздо проще выполнять такие обновления, чем с GWT-RPC, поскольку RF генерирует стабильные запутанные имена между сборками, которые зависят только от интерфейса илиимя метода, а не его сигнатура или тип и количество полей в классе (как в GWT-RPC).
Даже если вы переименуете интерфейсы или методы, вы сможете указать путь перехода, добавив ServiceLayerDecorator чтобы перевести со старого имени на новое.
Чтобы помочь в диагностике вашего вопросаэээ, хотя: где находится IncompatibleRemoteServiceException на стороне сервера?где это обрабатывается там?и что появляется в журнале вашего сервера?
Отказ от ответственности: я никогда не развертывал ничего с GWT-RPC, кроме прототипов, где не требовалось бесшовных обновлений, поэтому вышеприведенное больше похоже на предположение после прочтениякод для внутренних компонентов GWT-RPC.