Flex4, RemoteObject, ArrayCollection ошибка десериализации.

[Gubber]

Всем доброго дня.

Я тут наткнулся на одну очень неприятную фишку при передачи данных со стороны сервера (Java) на клиент (Flex 4).

На стороне клиента есть два класса со следующей сигнаторуй

PHP код:

public class A {
public String prostoSvoystvo;
public List<B> moyMassiv;
}
public class B {
public String drugoeProstoeSvoystvo;
} 


На стороне клиента так же есть два класса

[RemoteClass(alias="A")]
public class A {
public var prostoSvoystvo : String;
public var moyMassiv : ArrayCollection;
}
 
[RemoteClass(alias="A")]
public class B {
public var drugoeProstoeSvoystvo : String;
}

Так вот, когда делаю вызов, то происходит следующее: класс А десериализуется нормально, а вот в свойство moyMassiv попадает коллекция не объектов типа B, а просто коллекция объектов Object с нужными полями.
Кто-нибудь сталкивался с таким странным поведением? Может есть варианты лечения?
На стороне сервера используется BlazeDS, но есть подозрения, что проблема на стороне флекса. Sdk Flex = 4.1.0.15646

[Dimitry_II]

У меня практически такая же загвоздка, только с точностью до наоборот - все зависимые объекты и коллекции сериализовались, а "главная" коллекция объектов пришла как ArrayCollection объектов типа Object. Правда, банальное item[i] as B легко их переводит. Но недоразумение осталось. Да и во флешевских логах хватает строк типа:

warning: unable to bind to property 'label' on class 'Object' (class is not an IEventDispatcher)

Тоже с большим удовольствием узнал бы решение.

[wvxvw]

Gubber: с явовской сериализацией не работал, но с другой стороны - а почему вы решили, что ArrayCollection должна сериализоваться в List<T>? Как бы нет к тому никаких явных предпосылок. ArrayCollection - просто какой-то левый класс из флексового фреймворка, и если уже на что-то в яве похожа, так скорее на ArrayList (без параметра типа, как в jdk <1.5) и то очень отдаленно, т.как это по-настоящему не коллекция, разработчики просто забыли "view" к имени класса дописать, - такой себе мутант / суррогат чего-то непонятного.
На стороне AS3 ArrayCollection сериализуется так же, как и массив, только с той разницей, что дописывается алиас на класс. По аналогии с PHP могу предположить, что в яве, в AMF пакете должен быть какой-нибудь класс, который ей соответствует, или нужно самому такой дописывать.

Dimitry_II: В AS3 нет существует конвертирования типов для не-ECMAScript классов, т.е. если as сработало, значит объекты и были нужного типа. Это значит, что только типы вроде int, String и т.п можно конвертировать друг в друга, сложные типы таким образом не конвертируются.

[Gubber]

Сообщение от wvxvw

Gubber: с явовской сериализацией не работал, но с другой стороны - а почему вы решили, что ArrayCollection должна сериализоваться в List<T>? Как бы нет к тому никаких явных предпосылок. ArrayCollection - просто какой-то левый класс из флексового фреймворка, и если уже на что-то в яве похожа, так скорее на ArrayList (без параметра типа, как в jdk <1.5) и то очень отдаленно, т.как это по-настоящему не коллекция, разработчики просто забыли "view" к имени класса дописать, - такой себе мутант / суррогат чего-то непонятного.

List - это интерфейс, одной из реализацией которого является ArrayList. При сериализации любого List на флексе он преобразуется в ArrayCollection.
Но вопрос не в этом, а втом, что не десериализуются внутренности этой коллекции - сама коллекция нормально десериализуется. Т.е. я получаю ArrayCollection, внутри которого набор объектов типа Object, а хотелось бы, чтобы это была коллекция объектов типа В.
Одельно объекты типа В нормально десериализуются.

P.S. при компиляции Generic'и<T> удбираются из кода.

[wvxvw]

Ну тогда вам не повезло с AMF библиотекой т.как ArrayCollection - просто бесполезная чушь. Но смысл не в этом, а в том, что это значит, что либо алиас не зарегистрирован, либо как-то не правильно зарегистрирован. Проще всего проверить, зарегистрирован ли на стороне флеша - записать и прочитать из ByteArray, если прочитался как нужный класс, а не как динамический объект, тогда на стороне флеша все ОК - как проверить в (по всей видимости BlazeDS?) - чесно не знаю.
По поводу путаницы с интерфейсами - сорри, я не ахти знаю явовские коллекции, но имелось в виду, что ArrayCollection - это просто пользовательский класс, примечательный только исключительным уродством задумки и отсутствием всякого смысла / назначения. Как бы нет в нем ничего общего с коллекциями кроме случайной созвучности в названии.

[Gubber]

Сообщение от wvxvw

Ну тогда вам не повезло с AMF библиотекой т.как ArrayCollection - просто бесполезная чушь. Но смысл не в этом, а в том, что это значит, что либо алиас не зарегистрирован, либо как-то не правильно зарегистрирован.

Зарегистрировано всё правильно, т.к. по отдельности классы десериализуются нормально, а внутри коллекции, которая является свойтсвом другого объекта - не хочет.

[wvxvw]

Показывайте код тогда. Т.как так как вы говорите в принципе быть не может. Все, что делает ArrayCollection когда сериализуется выглядит так:

output.writeObject(this.source);

Т.е. она просто массив объектов записывает.

[Dimitry_II]

Ну да, это может показать и дебаггер, что ArrayCollection - это фактически массив в обертке. Правда, я не очень понял предвзятости к этому объекту, так как а) именно его выбрали для сериализации практически любого (!) списочного объекта Java (а их там ой как много!) и б) он реализует с помощью курсоров автоматическую сортировку, что немаловажно. Правда, слегонца бесит невозможность получить индекс объекта простой функцией, приходится перебирать ... это есть неправильно.

А что касается сериализации, то в получаемой коллекции объектов наблюдается порядочная вложенность (сервер извлекает данные в одну структуру из 2 десятков таблиц) и везде (!), где есть набор (коллекция ArrayCollection), там находится коллекция именно нужных типов объектов (на клиенте зеркальная структура POJO/BOJO(?) объектов), кроме "главной" коллекции.

Кстати, на сайте оффдоки есть таблицы сериализации/десериализации между Flex и Java (BlazeDS/LCDS) и все сделано в точности с ней, хотя и сложно ошибиться. А "не-ECMAScript" классы великолепно сериализуются, если на клиенте есть AS-класс с [RemoteClass(alias="myproject.myclass")]. Хотя большого опыта нет, но работает все как часики.

Еще пару слов о сериализации/десериализации с сервера на клиент: как-то писал, но решения не нашел, пришлось обходить. На Java есть тип boolean и класс Boolean. Первый имеет только 2 возможных значения: true и false, класс же может иметь и null-значение. У AS есть класс Boolean, в которое сериализируется и boolean, и Boolean (согласно таблицам в оффдоке). Но реально если на сервере было свойство объекта типа Boolean со значением null, то на клиенте мы все равно получим false, как будто передаем boolean, а не Boolean.

[wvxvw]

ОК, почему предвзятость:
ArrayCollection называется не правильно, это представление коллекции. Это не коллекция. Он не работает с векторами. Он очень медленный. Но самое плохое, что в нем есть это механизм IPE - ItemPendingError этот механизм якобы обеспечивает пейджинг. Т.е. гипотетически можно переслать только часть данных / заполнить коллекцию частично, но оперировать ею так, как будто она заполнена целиком. Этот механизм написан очень плохо, и от него только проблем больше. Например, с какого-то перепуга ArrayCollection считает себя в праве самостоятельно заменять элементы в массиве, который обороачивает или просто дублировать массив. Представьте на секунду, что у вас в массиве находятся ссылки на файлы, а тут какой-то, не побоюсь этого слова, идиот, взял и сдублировал этот массив - попытался создать копию файлов... Кроме того, в ситуациях, когда эта дрянь работает с Object'ами или Proxy, оно создает им дополнительное свойство по которому оно их распознает, типа uid / mx_internal_uid а потом пытается исходя из этого заменять объекты, что неминуемо приводит к ошибка / ситуации когда не возможно понять с каким именно объектом вы работаете и т.п. Вообще, можно долго этот класс ругать, вам это не поможет, т.как Адоби писали фреймворк который вы используете, и просто хотели пропихнуть свою ахинею / сделать так, чтобы вам пришлось использовать их AS3 фреймворк...
В конце концов, если хочется использовать флексовые представления коллекций, то есть смысл использовать их интерфейсы, а имплементации писать самому, ну и лучше использовать IList, а не ICollectionView, у последнего еще и багов немеряно. Смысл будет в том, что после танцов с бубном это можно будет прикрутить к флексовым GUI компонентам. Не то, чтобы эти компоненты были чем-то лучше остальной части фреймворка, но это просто много работы их с нуля писать.

Вы не поняли про не-ECMAScript классы. Речь была о том, что можно коневерировать var i:int = int("1"); но нельзя var m:MovieClip = MovieClip(new BitmapData()); например.

Про Boolean в яве - знаете анекдот про програмиста и два стакана? Когда програмист ложится спать, то ставит рядом с кроватью два стакана - один с водой, другой пустой, первый - на случай если проснется ночью и захочется пить, а вротой на случай если не захочется. К сожалению флексовый фреймоврк написан ява програмистами, и я бы не удивился, если бы в нем была бы возможность как-то протащить этот бред из явы и похожее ООП спинного мозга, но, ради бога, зачем вам этот бред?

[Dimitry_II]

Ну, за ArrayCollection ничего говорить не буду - просто склоняю шляпу перед опытом, пока сам его не набрал.
Хотя для того использования, где он применяется для сериализации, не вижу (по крайней мере пока) его "неполноценности". Возможно, это отношение со временем изменится.

Про Boolean ты не прав: если мы говорим про int, long или boolean, мы говорим не про Объект, а про тип данных и было бы глупо, чтобы они были равны null или не были равны "ничему". Однако типы-классы Integer, Long, Boolean обязаны это поддерживать, так как они объекты; и это находит отличное подтверждение для связи БД - когда поля просто не имеют значений вне зависимости от типа. И хотя то же булевское свойство вроде как должно иметь только значение "правда" и "ложь", но на самом деле имеет еще значение "не указано" или "не введено" или "неизвестно". И эту функциональность я хочу иметь и при сериализации. Спрашивается, почему я обязан переходить на Integer с состояниями 0, 1 и null только из-за этой "недоработки"?

Думаю, насчет Java и его ООП спор совершенно бессмысленный, так как а) ты в этом вопросе явно предвзятый; и б) ты сильно ошибаешься - это задумывали фактически как самый совершенный язык и он пока таким и остается ... по крайней мере в этом вопросе. (извини, если несколько твоих выпадов я принял именно за недовольство этим Языком)