Hi,
just pushed and two examples of sending objects in our current MX
RemoteObject example.
Both are failing even for the most simple case (a typed object with an id).
I must say that I thought we have this working.
This the fault event log
[Log] [onFault] (Language.js, line 237)
FaultEvent
bubbles: false
cancelable: true
currentTarget: RemoteObject
{mx_rpc_remoting_mxml_RemoteObject_resourceManager: ResourceManagerImpl,
mx_rpc_AbstractService_resourceManager: ResourceManagerImpl, disposed_:
false, onDisposeCallbacks_: undefined, eventTargetListeners_: ListenerMap,
…}
defaultPrevented: false
message: ErrorMessage {mx_messaging_messages_AbstractMessage__body: null,
mx_messaging_messages_AsyncMessage__correlationId: null,
mx_messaging_messages_AsyncMessage_correlationIdBytes: null,
mx_messaging_messages_AbstractMessage__headers: {},
mx_messaging_messages_AbstractMessage__clientId: null, …}
mx_rpc_events_AbstractEvent__token: null
mx_rpc_events_FaultEvent__fault: Fault
_faultCode: "Client.Message.Encoding"
_faultDetail: null
_faultString: "Creation validation for class
'org.apache.royale.amfsamples.valueobjects.ServerCustomType' failed."
content: null
rootCause: null
Prototipo de Fault
mx_rpc_events_FaultEvent__headers: undefined
mx_rpc_events_FaultEvent__statusCode: null
propagationStopped_: false
returnValue_: true
target: RemoteObject {mx_rpc_remoting_mxml_RemoteObject_resourceManager:
ResourceManagerImpl, mx_rpc_AbstractService_resourceManager:
ResourceManagerImpl, disposed_: false, onDisposeCallbacks_: undefined,
eventTargetListeners_: ListenerMap, …}
type: "fault"
Prototipo de FaultEvent
El mar., 20 nov. 2018 a las 13:40, Carlos Rovira (<carlosrov...@apache.org>)
escribió:
> Hi Andrew,
>
> many thanks for the thoughts and links in your email. I think that could
> be of great help.
> Maybe I could prepare some example in our Royale repo (as part of the
> current MX RemoteObject and Java examples) to help see the problem under
> some real circumstances. I'll try it and report here as I get it so we all
> can have it as a reference or showcase of the problem.
>
> thanks
>
> El mar., 20 nov. 2018 a las 12:48, Frost, Andrew (<andrew.fr...@harman.com>)
> escribió:
>
>> Hi guys
>>
>> I'm not 100% sure whether this will help, but if I'm right in thinking
>> that what you're trying to do is to mimic the Flash object serialisation,
>> then I think that this information is actually in the public domain
>> already..
>>
>> Carlos, you wrote:
>> "ArrayCollection uses IExternalizable and that part is our main problem
>> since we don’t have references, just simple docs but no real
>> implementation, guides or notes about it."
>>
>> The IExternalizable.as implementation is part of avmplus:
>> https://github.com/adobe/avmplus/blob/master/core/IExternalizable.as
>> ArrayCollection is of course part of Flex:
>> https://github.com/apache/flex-sdk/blob/master/frameworks/projects/framework/src/mx/collections/ArrayCollection.as
>> and you can then follow through what's happening.
>>
>> And, having just done that, I'm guessing you're looking at how
>> "readObject" works. Presumably you're serialising into a ByteArray, which
>> means ultimately you'll end up in the heart of the avmplus code:
>> https://github.com/adobe/avmplus/blob/master/core/Toplevel.cpp#L1504
>> and
>> https://github.com/adobe/avmplus/blob/master/core/AvmSerializer.cpp
>> which is quite complex...!
>>
>> Not sure if those help at all but it looks to me like it should be
>> possible to have some JavaScript code to do all this. If this is the sort
>> of area that you're looking at then let me know, I've got extensive
>> experience with the avmplus code and have builds of it that I can
>> tweak/play with to debug what happens in various scenarios! but I don't
>> have any experience with using RemoteObject hence this may all be
>> completely irrelevant..
>>
>> thanks
>>
>> Andrew
>>
>>
>> -----Original Message-----
>> From: Greg Dove [mailto:greg.d...@gmail.com]
>> Sent: 20 November 2018 09:47
>> To: dev@royale.apache.org
>> Subject: [EXTERNAL] Re: Problems sending MX ArrayCollections with MX
>> RemoteObject
>>
>> Hi Alex,
>>
>> To follow on from what Carlos explained... your initial implementation
>> with AMFBinaryData was working quite well for smaller object graphs.
>>
>> And I was able to make some changes to get it to special-case
>> ArrayCollection for now on the reading side (it's not a proper
>> implementation, but it was to get things working for now).
>>
>> What I am missing is some good implementation notes ('conforming readers
>> and writers must do this'). For example, I'm not sure what the object table
>> (rememberObject/traitsByReference) rules are for Externalizables, and
>> it's really hard to 'discover' through comparisons with things like
>> ByteArray or BlazeDS responses partly because the undefined output order of
>> the fields in a large graph which makes direct comparison of byte sequences
>> from the 2 sources not so easy.
>>
>> In the end I will be happy to keep working on getting AMFBinaryData fully
>> featured in my own time to help with the general MX effort, but Carlos
>> needs certain things working for his project, which are our current
>> priorities.
>>
>> I do have some improvements that I can get in for AMFBinaryData in the
>> next few days (I'm still refining things):
>> I have some code that avoids inappropriate field data for serialization:
>> only accessors with readwrite access (not getter only or setter only) no
>> static accessors or variables excludes any field with 'Transient' metadata
>>
>>
>> But I'm still actively trying to figure out how to get the AC writing
>> correctly in a complex graph, and I really need to understand what the
>> rules are supposed to be. In terms of 'Externalizable' AC seems quite
>> simple, so I thought it would be easy... but I think I am messing up the
>> object reference table when I do this... I was hoping there might be
>> something documented for implentation notes that is 'public' but 'not well
>> publicized' that you might be aware of, perhaps through some of your
>> internal connections. if we can get this fully fledged as quickly as
>> possible, even if it just focused on AC for now on the 'Externalizable'
>> side then that will help Alina and others as well, I think. I've had my
>> head in this for a bit now, so if I have the info, I will find the time.
>>
>> Hopefully you can provide some insight!
>> -Greg
>>
>>
>>
>>
>> On Tue, Nov 20, 2018 at 10:19 PM Carlos Rovira <carlosrov...@apache.org>
>> wrote:
>>
>> > Hi Alex,
>> >
>> > Greg and I are working this days in sending MX ArrayCollection with MX
>> > RemoteObject to BlazeDS. We found that part is not working.
>> > This is huge problem since without solving this we can't progress in
>> > our migration, so hope you could take care of this issue and help us
>> > to find the solution.
>> >
>> > The main problem is that we don't have or find a good reference of the
>> > way it should be implemented and the format makes it difficult to
>> discover.
>> > ArrayCollection uses IExternalizable and that part is our main problem
>> > since we don’t have references, just simple docs but no real
>> > implementation, guides or notes about it.
>> >
>> > Our better bet is that you could get some help at Adobe internally
>> > since I don't think this info is in internet (at least we search
>> > heavily to try to find).
>> >
>> > I think with out this problem fixed no application using MX
>> > RemoteObject for communication could be migrated from Flex to Royale,
>> > since as soon they want to send and complex graph that uses MX
>> ArrayCollection it will fail.
>> >
>> > Greg can comment more about this problem since he was working hard on
>> > the issue this days.
>> >
>> > Thanks in advance for your help
>> >
>> >
>> > --
>> > Carlos Rovira
>> > https://clicktime.symantec.com/a/1/fECozPwEKwcw-Ikf3a3HC4wIeBurGWwaEzA
>> > E2QRfLRk=?d=ezg34mnblPal5Fyvz8kFGVPZYWSwgwTIshTP4R6ZZBwOU_9DnOO0vulBQk
>> > WMjrartx1QiEcmaQF0W-s21xYUmmwd8VZI2paWYczV2yv9_RGOX7HvcYTbT5-boGyLZsXs
>> > i81oDbXjP_kE8HOHv-CO0RmzekCJ4IXZ1dfI4iczGVVKJlFs3Z9QfZKPIsqL8bfsOPw83b
>> > 72ng2yLuRO4g252wF9TWPtu2CAYr-VXOzqqiXrKi2Zrk9wM3FFEc9hUJ9dpb5b4bflw_r8
>> > nj8z30JVYIfUlmah923Rr-8mDPJO0JvmMDiSEWJojxBQAi_wWktydSWyDvGSDJidxjtFsq
>> > UpjRFuCNjuBFxim5GH2bZCj-0Gra3yfagBCVNYiT95Zq5loJN_-kHI8W8-jEOaVK-3Hgd4
>> > iAgxK7oB4xr5-PopRVTJDHsb3OeOqtd9_rjFDbCq0EtWEowCy2xcWbcBzo0IiQhRTv3Mrs
>> > x48H3qjmo%3D&u=http%3A%2F%2Fabout.me%2Fcarlosrovira
>> >
>>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
