Hi I forgot to mention one more thing about passing a List. In BlazeDS and ColdFusion (for what I know from other users), a server side Collection is passed like an externalized object reference. We solved this for BlazeDS and Coldfusion. I think that should work the same for WebOrb, but since maybe you're the first trying this I don't know for sure at this time. Ad well, in Royale we use ArrayList instead of ArrayCollection like we use to do in Flex. For that reason I encourage you to start with a simple pass of a String and then cover other scenarios progressively.
thanks Carlos 2018-08-10 9:51 GMT+02:00 Carlos Rovira <[email protected]>: > Jose, > > based in your info I could make a working example to try. I think code is > missing, but I can explain what I see so you can see if you need to fix > things in your code or is only information that is missing in your email. > > Looking to the info you give: > > 1) The RO configuration is: > source = "Remoting.Service.Components.RemotingTest" > destination = "GenericDestination > > source is a deprecated property left in RO for > backwards compatibility, since it expose the path to the server object. > It's not needed anymore. Again talking about BlazeDS. Only destination > should be required along "endPoint". If I search for "GenericDestination" > in the config file you posted I don't find it. The same happens for " > Remoting.Service.Components.RemotingTest". IMHO the .Net class should be > exposed in the weborb config file like this one: > > <service> > <name>ExamplesActivationSession</name> > <serviceId>Weborb.Examples.ShoppingCart</serviceId> > </service> > > to have something like: > > <service> > <name>RemotingTest</name> > <serviceId>Remoting.Service.Components.RemotingTest</serviceId> > </service> > > > In our example in BlazeDS we don't do this in config file since we have a > Spring annotation in code. Example: > > @Service("exampleService") > @RemotingDestination > public class ExampleService { > > just guessing and trying to match what I know from BlazeDS and what I see > in your WebOrb config file > > Then remove "source" property from the Royale RO declaration > > Now going to the calling code: I don't see nothing of that in your sample > code. It seems the button calls "initRemoting" but where's the code? > > The code should be something like: > > protected function sendName():void > { > service.send("XXX", []); > } > > Where XXX is the name of the method in the .Net class > Remoting.Service.Components.RemotingTest > second param is the array of params to send to that method. I understand > in this case we don't send anything > > Then managing the result, I don't see again any callback code. But lets > imagine s something like this: > > private function onResult(evt:ResultEvent):void > { > trace("[Client:" + RoyaleClient.getInstance().id + "] > Result= " + evt.data); > > var arr:ArrayList = new ArrayList(evt.data as Array); > list.dataProvider = arr; > > } > > If you run in debug mode (js-debug) in your browser (and here is important > that you left your browser communication within local and external sources > since that security restriction will make this communication not work) > you should see a trace with the "clientId" and the data from server. > clientId will then be shared in each transaction with the server > > then since we are receiving a list of countries for what I understand, you > should get an Array (maybe for the first connection you should start with > only a String, instead this structure since is more complex) > > For the Array, one important thing is to know if each object in the array > are plain Objects or TypedObjects and if the later, you'll need something > like the following example in the Class: > > [RemoteClass(alias="org.apache.royale.amfsamples.valueobjects.Product")] > public class Product > { > > Maybe in WebOrb is needed as well some config, on this point. > > My suggestion is that instead of try for the first time to exchange a > list, you'll try to send a simple string and send back another string from > WebOrb method. That will make a safe point from wich you can evolve to > something more complicated. Then try a Typed object, and then try a List of > typed objects. > > > > > > 2018-08-10 9:15 GMT+02:00 Carlos Rovira <[email protected]>: > >> Hi Joe, >> >> - correlationId is received from server (talking about BlazeDS always, >> since don't know about WebOrb), and is a String if small messages are off >> and a ByteArray if on. >> - operation is send from client and is 5 (client pong operation) in a >> normal RO operation (not SimpleRO) to establish connection with BlazeDS, >> then "operation" is the name of the method your are asking for. >> In SimpleRO instead of 5 is 13 (trigger connect operation) for the first >> connection. >> >> So my guess is that something is wrong in your code >> >> I'll respond to the other email now >> >> >> >> 2018-08-10 1:19 GMT+02:00 JoeBoxer <[email protected]>: >> >>> Hello Carlos and Alex. >>> >>> After digging a bit further i noticed that WebORB is expecting 2 >>> additional >>> properties in the remoting request than what AbstractMessage.as is >>> sending. >>> >>> AbstractMessage.as sends: >>> >>> body >>> clientId >>> destination >>> headers >>> messageId >>> timestamp >>> timeToLive >>> >>> WebORB is expecting... >>> >>> body >>> clientId >>> destination >>> headers >>> messageId >>> timestamp >>> timeToLive >>> >>> AND >>> >>> operation >>> correlationId >>> >>> This could be why the WebORB parser is throwing an exception. Your >>> thoughts? >>> >>> Regards >>> >>> >>> >>> -- >>> Sent from: http://apache-royale-users.20374.n8.nabble.com/ >>> >> >> >> >> -- >> Carlos Rovira >> http://about.me/carlosrovira >> >> > > > -- > > <http://www.codeoscopic.com> > > Carlos Rovira > > Director General > > M: +34 607 22 60 05 > > http://www.codeoscopic.com > > > Conócenos en 1 minuto! <https://avant2.es/#video> > > > AVISO LEGAL: La información contenida en este correo electrónico, y en su > caso en los documentos adjuntos, es información privilegiada para uso > exclusivo de la persona y/o personas a las que va dirigido. No está > permitido el acceso a este mensaje a cualquier otra persona distinta a los > indicados. Si Usted no es uno de los destinatarios, cualquier duplicación, > reproducción, distribución, así como cualquier uso de la información > contenida en él o cualquiera otra acción u omisión tomada en relación con > el mismo, está prohibida y puede ser ilegal. En dicho caso, por favor, > notifíquelo al remitente y proceda a la eliminación de este correo > electrónico, así como de sus adjuntos si los hubiere. En cumplimiento de la > legislación española vigente en materia de protección de datos de carácter > personal y del RGPD 679/2016 le informamos que sus datos están siendo > objeto de tratamiento por parte de CODEOSCOPIC S.A. con CIFA85677342, con > la finalidad del mantenimiento y gestión de relaciones comerciales y > administrativas. La base jurídica del tratamiento es el interés legítimo de > la empresa. No se prevén cesiones de sus datos, salvo que exista una > obligación legal. Para ejercitar sus derechos puede dirigirse a CODEOSCOPIC > S.A., domiciliada enPaseo de la Habana, 9-11, 28036 de Madrid (MADRID), o > bien por email [email protected], con el fin de ejercer sus derechos > de acceso, rectificación, supresión (derecho al olvido), limitación de > tratamiento, portabilidad de los datos, oposición, y a no ser objeto de > decisiones automatizadas, indicando como Asunto: “Derechos Ley Protección > de Datos”, y adjuntando fotocopia de su DNI. Delegado de protección de > datos:[email protected] > > -- Carlos Rovira http://about.me/carlosrovira
