The SWF is executed directly by the Flash player, via the loadMovie() call. The flow of control in the rpc implementation for the Flash runtime is this:
[1] a request is made from the client to the LPS server, as XML text data, using the Flash player "loadMovie()" call, which expects a swf file to be returned which, when executed, will build the response data values as structures in memory. [2] the LPS server passes that XML-RPC request to the apache "axis" RPC library, which sends it to the specified back-end data server. [3] The XML response from the back-end service is received by the apache axis library. [4] The apache library parses the XML response into data types, and there are hooks to call the LPS SWF "data-compiler", to convert the data into a sequence of SWF instructions, packaged as a SWF format file. [5] The SWF "movie" is returned to the flash player, which executes it as part of the loadMovie() call. So it is the Flash player which executes the swf data "movie", not any OpenLaszlo code. The place where you can add instrumentation to the LPS server would be where it calls the apache axis library, and where the data which is returned from apache axis calls the OpenLaszlo "DataCompiler" library. At that point you could see what data it is encoding. On Wed, Mar 26, 2008 at 12:04 AM, Gilad Parann-Nissany < [EMAIL PROTECTED]> wrote: > Hi > > Does anyone have a piece of javascript (or Java) that will actually do > this decoding? I mean turn the SWF binary format back into the original data > - in our case an xml string ? > > Let me explain our use case: > > - we are creating a JMeter test, we make requests and record the > responses > - we need to look into the response for various reasons (check them > for validity, extract IDs and keys used later in the test) > - JMeter has built-in facilities for understanding strings and XML, > but not SWF > - However JMeter also has a *general* facility to run javascript on > the response (its a "BeanShell") > - Essentially we can do a getBytes or getResponseAsString and feed > that into whatever javascript you give us > > We need a js code snippet that will take the SWF bytes and turn them back > to XML string, in the JMeter BeanShell. > > I am sure OL has this code somewhere because OL is decoding this format > already today. Question is - can you give us a clean code snippet that will > do it in the JMeter BeanShell ? > > (or any other ideas on how to achieve this goal in JMeter) > > Thanks > > Gilad > > > > Gilad Parann-Nissany > > ----- Original Message ----- > From: "Henry Minsky" <[EMAIL PROTECTED]> > To: "Gilad Parann-Nissany" <[EMAIL PROTECTED]> > Cc: "laszlo-user" <[email protected]>, "Yazan Ghandour" < > [EMAIL PROTECTED]>, "Rami Khalayleh" < > [EMAIL PROTECTED]>, "Anas Jadallah" <[EMAIL PROTECTED]>, > "Elias Khalil" <[EMAIL PROTECTED]> > Sent: Tuesday, March 25, 2008 4:27:52 PM (GMT+0200) Auto-Detected > Subject: Re: [Laszlo-user] XML RPC requests return a > "application/x-shockwave-flash" data type > > Yes, the javascript data is compiled down to swf byte codes which, when > executed, recreate that data. > > For example, a list of numbers [1,2,3] compiles to something like > > push 1 > push 2 > push 3 > push 3 > new Array > > > or whatever the equivalent is in the SWF instruction set > > > > On Tue, Mar 25, 2008 at 10:23 AM, Gilad Parann-Nissany < > [EMAIL PROTECTED]> wrote: > > > Hi > > > > In our case it can be pretty big, we do need the performance. > > > > So the actual response format is truly binary (SWF) and not XML at all? > > in that case the content-type is correct I guess. > > > > or is it text wtih just the encoding set to SWF? in that case I guess we > > could figure a workaround? > > > > Thank you! > > > > Gilad > > > > > > > > Gilad Parann-Nissany > > > > > > ----- Original Message ----- > > From: "Henry Minsky" <[EMAIL PROTECTED]> > > To: "Gilad Parann-Nissany" <[EMAIL PROTECTED]> > > Cc: "laszlo-user" <[email protected]>, "Yazan Ghandour" < > > [EMAIL PROTECTED]>, "Rami Khalayleh" < > > [EMAIL PROTECTED]>, "Anas Jadallah" < > > [EMAIL PROTECTED]>, "Elias Khalil" <[EMAIL PROTECTED]> > > Sent: Tuesday, March 25, 2008 3:53:16 PM (GMT+0200) Auto-Detected > > Subject: Re: [Laszlo-user] XML RPC requests return a > > "application/x-shockwave-flash" data type > > > > The issue is that the implementation in swf was written to compile the > > return data as a Flash swf binary file. The implementation for DHTML uses a > > JSON encoding. The fix for this would need to be to switch to using the JSON > > encoding with the swf runtime. We do have a JSON parser for SWF7/8, it would > > be somewhat slower than the direct-to-swf transport being used now, but that > > might be acceptable if the amount of data you are sending in each request is > > not very large. > > > > > > On Tue, Mar 25, 2008 at 9:33 AM, Gilad Parann-Nissany < > > [EMAIL PROTECTED]> wrote: > > > > > Hi all > > > > > > We have an app using Laszlo XML RPC rather heaviliy, our version is > > > 4.0.8. > > > > > > Looking at the logs one sees that the REQUESTS produced by our client > > > for XML-RPC are of type "application/x-www-form-urlencoded" > > > > > > (which makes sense - it is the correct content-type for a POST > > > request). > > > > > > However the RESPONSEs are of type "application/x-shockwave-flash" > > > which is strange. > > > > > > We would expect the reponse type to be text/xml or something like > > > that. This is creating a real-world problem for us on various consumers > > > e.g. JMeter - which expect the text/xml to function correctly. > > > > > > Do you have any experience with this issue? Suggestions or > > > workarounds? > > > > > > Detailed info from the logs is below. > > > > > > Thanks > > > > > > Gilad > > > > > > P.S. For example: something like the following response headers > > > > > > ---------------- > > > > > > HTTP/1.1 200 OK > > > Expires: Fri, 05 Oct 2001 00:00:00 GMT > > > Date: Tue, 25 Mar 2008 11:51:13 GMT > > > Server: Apache-Coyote/1.1 > > > Cache-Control: no-store > > > Content-Type: application/x-shockwave-flash > > > Content-Length: 437 > > > Server: Apache-Coyote/1.1 > > > > > > ---------------- > > > > > > is returned from the following request: > > > > > > ---------------- > > > > > > POST > > > http://localhost/lps/workspace/VC/client/welcomei.lzx?__lzbc__=1205615513625 > > > > > > POST data: > > > > > > fpv=9%2E115&lzr=swf8&proxied=true&lzpostbody=%3C%3Fxml+version%3D%221%2E0%22%3F%3E%0A%3CmethodCall%3E%0A%3CmethodName%3EClientInfo%2EgetGhostInitInfo%3C%2FmethodName%3E%0A%3Cparams%3E%0A%3Cparam%3E%0A%3Cvalue%3E%3Cstring%3E%3C%2Fstring%3E%3C%2Fvalue%3E%0A%3C%2Fparam%3E%0A%3C%2Fparams%3E%0A%3C%2FmethodCall%3E&headers=Content%2DType%3A+text%2Fxml&url=xmlrpc%3A%2F%2Flocalhost%2Fvcweb%2FGhostXmlrpc&reqtype=POST&lzt=data&ccache=false&cache=false&sendheaders=false > > > > > > Cookie Data: > > > JSESSIONID=2FEEB2B9C6B91302795CD62AD3D274A6 > > > > > > Request Headers: > > > User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET > > > CLR 1.1.4322; .NET CLR 2.0.50727) > > > Host: localhost > > > Accept-Encoding: gzip, deflate > > > Accept-Language: he-IL > > > Pragma: no-cache > > > Content-Type: application/x-www-form-urlencoded > > > UA-CPU: x86 > > > Accept: */* > > > Content-Length: 462 > > > Connection: keep-alive > > > Referer: > > > http://localhost/lps/workspace/VC/client/welcomei.lzx?lzt=swf&lzr=swf8 > > > x-flash-version: 9,0,115,0 > > > > > > > > > Gilad Parann-Nissany > > > > > > > > > > > -- > > Henry Minsky > > Software Architect > > [EMAIL PROTECTED] > > > > > > > -- > Henry Minsky > Software Architect > [EMAIL PROTECTED] > > -- Henry Minsky Software Architect [EMAIL PROTECTED]
