Gwt - Использование списка <Serializable> в вызове RPC?

У меня есть служба RPC со следующим методом:

public List<Serializable> myMethod(TransactionCall call) {...}

Но я получаю предупреждение, когда этот метод анализируется, а затем вызов rpc терпит неудачу

Analyzing 'my.project.package.myService' for serializable types
Analyzing methods:
public abstract java.util.List<java.io.Serializable> myMethod(my.project.package.TransactionCall call)
Return type: java.util.List<java.io.Serializable>
[...]
java.io.Serializable
Verifying instantiability
(!) Checking all subtypes of Object wich qualify for serialization

Кажется, я не могу использовать Serializable для моего списка... Вместо этого я мог бы использовать свой собственный интерфейс (что-то вроде AsyncDataInterface, которое реализует интерфейс Serializable), но факт в том, что мой метод вернет список пользовательских объектов AND basic объектов (таких как строки, int....).

Итак, мои вопросы:

  • Это стандартное поведение? (Я не могу понять, почему я не могу использовать этот интерфейс в этом случае)
  • Есть ли у кого-нибудь обходные пути для такого рода ситуаций?

Ответы

Ответ 1

При передаче объектов через RPC вызывается хорошая практика объявления конкретных типов параметров в интерфейсе RPC. Если по какой-то причине вы не можете использовать конкретный класс в интерфейсе RPC, попробуйте быть как можно более конкретным.

Это связано с тем, что компилятор GWT при выпуске javascript должен учитывать все возможные варианты List в блоке компиляции. Сюда входят все классы, расширяющие интерфейс List и Serializable в пути к классу. Перестановки могут быть огромными, что повлияет на время компиляции, а также размер загружаемого приложения.

Итак, лучший подход - определить ваш интерфейс как

public ArrayList<YourType> myMethod(TransactionCall call) {...}

а не

public List<Serializable> myMethod(TransactionCall call) {...}

Таким образом, компилятор должен генерировать единицы компиляции только для расширений ArrayList и YourType. Benifit - это более быстрое время компиляции и меньшие скомпилированные файлы javascript, следовательно, более быстрая загрузка вашего приложения.

Если вам нужно вернуть в свой RPC широкий диапазон несвязанных объектов, попробуйте создать класс-оболочку и вернуть объект класса-оболочки с возвращаемым значением. Используйте класс оболочки в определении метода RPC. Сопротивляйтесь стремлению объявить обернутое поле как Object или Serializable, вы отмените все преимущества сериализации, полученные с помощью обертки. Вместо этого вы можете определить интерфейс Wrapper и небольшой набор реализаций Wrapper для каждого конкретного типа, который вы хотите вернуть через ваш вызов RPC.

Ответ 2

Возможно, вы захотите проверить, что файл политики сериализации не является источником проблемы.

Цитата из документации GWT:

Однако есть одно условие для поддержки поддержки java.io.Serializable в новой системе RPC GWT.

RPC теперь генерирует файл политики сериализации во время компиляции GWT. Файл политики сериализации содержит белый список разрешенных типов, который может быть сериализован. Его имя - сильное имя хэша, за которым следует .gwt.rpc. Чтобы включить поддержку java.io.Serializable, типы, которые ваше приложение будет отправлять по проводу, должны быть включены в белый список политики сериализации. Кроме того, файл политики сериализации должен быть развернут на ваш веб-сервер в качестве общего ресурса, доступного из RemoteServiceServlet через ServletContext.getResource(). Если он не развернут должным образом, RPC будет работать в режиме совместимости 1.3.3 и отказаться от сериализации типов, реализующих java.io.Serializable.

Ответ 3

Я не вижу смысла определять List <Serializable> как возвращаемое значение. Тип Serializable не содержит дополнительной информации в декларации API сервиса. В любом случае GWT проведет проверку сериализации во время выполнения.

В вашем случае, когда элементы списка не имеют общего предка, отличного от Object, я бы использовал List <? > .