gwt - Использование списка <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, которое реализует Serializ способный интерфейс), но факт в том, что мой метод вернет список пользовательских объектов И основных объектов (таких как Строки, 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 расширений. Benifit - это более быстрое время компиляции и меньшие скомпилированные файлы javascript, следовательно, более быстрая загрузка вашего приложения.

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

Answer 2

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

Quote from GWT documentation:

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

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

Answer 3

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

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