gwt - Используя Список <сериализуемый> в вызове 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
Кажется, что я не могу использовать сериализуемый для моего Списка... Я мог использовать свой собственный интерфейс вместо этого (что-то как AsyncDataInterface, который реализует сериализуемый интерфейс), но факт - то, что мой метод возвратит список пользовательские объекты И основные объекты (такие как Строки, интервал....).
Таким образом, мои вопросы:
- Действительно ли это - стандартное поведение? (Я не могу выяснить, почему я не могу использовать этот интерфейс в этом случае),
- У кого-либо есть обходное решение для такой ситуации?
3 ответа
При передаче объектов через вызовы 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.
Я не вижу смысла определять List
В вашем случае, когда элементы списка не имеют общего предка, кроме Object, я бы использовал List .
Возможно, вы захотите проверить, что файл политики сериализации не является источником проблемы.
Однако, есть одно условие для включения поддержки java.io.Serializable в новой системе GWT RPC.
RPC теперь генерирует файл политики сериализации во время компиляции GWT. Файл политики сериализации содержит белый список разрешенных типов, которые могут быть сериализованы. Его имя представляет собой сильное хэш-имя, за которым следует .gwt.rpc. Чтобы включить поддержку java.io.Serializable, типы, которые ваше приложение будет передавать по проводам, должны быть включены в белый список политики сериализации. Кроме того, файл политики сериализации должен быть развернут на вашем веб-сервере как публичный ресурс, доступный из RemoteServiceServlet через ServletContext.getResource(). Если он не развернут должным образом, RPC будет работать в режиме совместимости с версией 1.3.3 и откажется сериализовать типы, реализующие java.io.Serializable.