Oh it's that simple! Yes I just took a look, that does appear to go through it all and set everything up...
Thank you! that saved us a bit of effort trying to update the compiler ;-) -----Original Message----- From: Greg Dove <greg.d...@gmail.com> Sent: 11 July 2019 23:27 To: dev@royale.apache.org Subject: [EXTERNAL] Re: AMF and class aliases Hi Andrew, 'but I can't see anywhere that this list is accessed/used.' I think you need ClassAliasBead on your Application level, which will process all the definitions. On Fri, Jul 12, 2019 at 10:22 AM Frost, Andrew <andrew.fr...@harman.com> wrote: > Hi all > > We're trying to get a connection to work from our Royale-based code to > a LiveCycle back-end, and having to debug why the AMF message is > different between the Flex version and the Royale version (and trying > to work out why the server is rejecting our initial ping message..) > > One thing that's cropped up is that Flex embeds the name of the class > - or rather, the alias of this - when it writes the object: > [RemoteClass(alias="flex.messaging.messages.CommandMessage")] > > In Royale, this capability exists in the > AMFBinaryData.writeObjectVariant() method where it's using the > "localTraits", and we have: > var alias:String = classInfo.alias;// > getAliasByClass(instance.constructor > as Class); //<- @todo possible optimization: registerClassAlias > implementation stores in the classInfo Object, access directly > > The commented-out code does exactly what the new code does, which is > that it accesses the ROYALE_CLASS_INFO structure: > var classInfo:Object = > instance.ROYALE_CLASS_INFO; so to make this work, we've added an extra > section at the end of the ROYALE_CLASS_INFO for the CommandMessage (in > the generated JavaScript, so this is not a proper solution!): > > mx.messaging.messages.CommandMessage.prototype.ROYALE_CLASS_INFO = { > names: [{ name: 'CommandMessage', qName: > 'mx.messaging.messages.CommandMessage', kind: 'class' }] , alias: > 'flex.messaging.messages.CommandMessage' }; > > > Interestingly, the compiler looks at all the [RemoteClass(alias="")] > tags, and outputs a list of these in the main application's .js file: > TestBackend.prototype.info = function() { > return { "mixins": [mx.messaging.config.LoaderConfig, > mx.styles.StyleManagerImpl], > "remoteClassAliases": {"mx.messaging.messages.CommandMessage": > "flex.messaging.messages.CommandMessage", > "org.apache.royale.net.remoting.messages.ActionMessage": > "flex.messaging.io.amf.ActionMessage", ... etc }, > "compiledLocales": ["en_US"]}}; > > but I can't see anywhere that this list is accessed/used. > > > So it looks to me like there's a discrepancy between how the compiler > is trying to make this work, and how the framework is expecting it to > be set up by the compiler. I was wondering if anyone know what had > been going on here and whether we should go for one way or another .. > and by preference I think, getting the compiler to add the alias > directly into the ROYALE_CLASS_INFO as that seems to be a better way of doing > it I think..? > > > thanks > > Andrew > > p.s. we've had a few other issues with the AMF format, e.g. using > 'unknown length' and having this as +1 rather than -1; plus a single > message was being packaged as an array, whereas Flex/Flash Player > doesn't do that.. I'm wondering whether anyone has a problem if we try > to make the AMF messages generated from a Royale app to be as similar > as possible to how the Flash Player does it..?! > >