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

Question

У меня есть служба 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), но факт в том, что мой метод будетвернуть список пользовательских объектов и базовых объектов (таких как Strings, int ....).

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

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

Answer 1

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

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

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

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

вместо

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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