Flex Monkey Patches

This really isn’t that difficult to do, but the docs regarding it are a little hard to find. I thought I’d post the link and then some links to other useful blog entries that have info to add on this topic.

Doc link: http://livedocs.adobe.com/blazeds/1/blazeds_devguide/help.html?content=runtimeconfig_5.html#194376

One of Adobe’s platform evangelists has posted a blog entry that may be more clear:
http://raghuonflex.wordpress.com/2008/06/05/endpointatruntime/

There is also a “Flex cookbook” entry that may be of some use:
http://www.adobe.com/cfusion/communityengine/index.cfm?event=showdetails&productId=2&postId=9703

So, I’ve been lazy and busy and haven’t had a post for a while…hopefully I can get back on track with this post.

I was on vacation last week and missed posting my rubbernecker’s review so here is my top 10 from the passed 2 weeks:

Here are the past week’s top 10 Flex/AIR/LCDS links:

Here are the past week’s top 10 Flex/AIR/LCDS links:

This question seems to come up a lot and there are various answers to it. I am just collecting a few here:

Questions:

*****
The best information I can get from Flex when I get a SOAP fault seems to be “Error #2032: Stream Error” which seems to me to be rubbish - there’s a SOAP fault being sent back to the client which I have verified with Charles, but the header response is a 500 - does Flex use this to decide to give the vague stream error? And if so, can I still retrieve the actual response text?
(http://www.mail-archive.com/flexcoders@yahoogroups.com/msg90996.html)

*****

When an error occurs a web service will typically return a HTTP error
code with the error message in the body. The problem is that Flex does not allow you to access the body and just throws a 2032 error. None of the information from the HTTP response describing the actual error is
available in the fault event.
(http://www.mail-archive.com/flexcoders@yahoogroups.com/msg88599.html)

*****

How can I display SOAP fault messages in Flex? Flex 2 currently seems to be reporting an IO error instead of the SOAP fault details.

*****

I don’t seem to be able to get the Soap fault of a webservice called from a flex client, I just get a generic fault. If I look in a webservice debugging tool I see the specific fault is being returned as a 500 error with the specific message. How can I get the specific error fault in the flex client, or is this a bug?

*****

Responses:

*****

Well there has been a bug logged:

WebService fault details are hidden by Flex SDK - http://bugs.adobe.com/jira/browse/SDK-11841

*****

This is a well known limitation of the various plugin APIs exposed to the Flash Player. For non-200 status code HTTP responses, the body is not exposed to the Flash Player and thus it cannot show you what the SOAP fault was. You’d need to change the server to use a 200 status code despite the SOAP response being a fault.
An alternative is to use the BlazeDS Proxy Service which will handle this situation for you and do the translation.

*****

This is generally a Flash Player/Web Browser limitation. The NPAPI that the plugin player uses in FireFox/Safari/etc does not providing anything useful to a plugin when an HTTP fault response is received. This is an area that the Flash Player team is currently investigating fixes in, but any improvements would depend on rev’ing the NPAPI and working with browser vendors to update their browsers. There are also apparently issues in IE7 that weren’t there in IE6. Using the browser HTTP stack buys the Flash Player team space savings because they didn’t have to implement all that directly, integrated browser/player cookies and basic HTTP auth state, SSL/TLS cert management, etc. but because the APIs exposed to the player by the various browsers differ and in some cases have outright holes there are long-standing, nasty limitations/bugs (like this one).

The way to work around this is to proxy requests either through BlazeDS, LCDS or you can write a simple HTTP proxy in the Server Scripting language of your choice (ColdFusion, JSP, PHP, etc).

*****

You need to make your calls through the BlazeDS or LCDS proxy service. SOAP faults are returned with an HTTP status code of 500 which the browsers don’t pass through into the player.

*****

And this is my favorite:

Here are some debugging tips I provided to a customer this week regarding debugging ant tasks that seemingly compiled a Flex app that used dataservices fine, but the app didn’t seem to get any data. The are generally useful, so I thought I would post them.

1. Try setting fork=”false” in your mxmlc and compc ant task, since forking the compile process will hide the stdout and stderr streams from the compile process and hide any errors or warnings that may be happening in the compile process, setting the fork to false will allow you to see any compile output in your console.

2. In your ant target echo out a formatted statement that would represent the equivalent mxmlc (or compc) commandline statement with all variables and relative paths, etc. resolved. Then you can use this echoed statement to run against mxmlc to help detangle yourself from ant to rule that out as a source of problems or rule out any pathing issues.
(Maybe you are not pointing to correct sevices-config.xml file?)

3. Make sure your dataservice tags and dataservice operations have fault handlers. (Maybe faults are being returned from the dataservice or the operation, but they are not being handled.)

4. Compile the Flex app with and run in the debug Flash Player. This should produce logging info in the flashlog.txt that is helpful for watching the network traffic between your Flex app and a server and may help narrow down the issue.
http://livedocs.adobe.com/flex/201/html/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Book_Parts&file=logging_125_10.html

5. Look in your LCDS install dir under resources/config at the services-config.xml. This file is a sample config file that has comments explaining the various settings. You want to look at the logging tag and enable more verbose serverside logging.

You should probably set the logging tag like this:

(This will log “Debug level” output to your servlet container’s logs.)
The default patterns are probably sufficient to start with, but this sample config file lists all the possible debug patterns. If the debug level does not result in enough info, you may want to try the “All” level.

6. Use a network traffic sniffing tool like Charles: http://xk72.com/charles/ to view traffic between browser and server.

So it is almost February already! Where did January go? I’ve been a bit slow out of the gate this year as far as keeping up a decent pace in posting helpful samples to my blog. Actually, I have been working on things behind the scenes, a few details of which I will reveal now. I have launched a new blog on a new domain. The content is to be all “work” related, so it will be about Flex/Flash Player/Adobe AIR, LiveCycle Data Services/Blaze DS/ColdFusion and other fun technologies. I’ve also been working on an AIR app which I hope to get out at least in a fairly stable beta form around the same time that Flex3/AIR releases. It will most likely be open source and hosted on Google Code. I will also be compiling a library of useful components, extensions to components and monkey patches to the Flex framework. This new blog and content will all be available on:

http://flexmonkeypatches.com

All old posts on http:blog.739SaintLouis.com should link to or redirect to the same content on my new site. I will leave my old site up for an undetermined length of time with the intent of transforming it content-wise into a more personal blog (time permitting.)

Regards,

-Kyle

Adobe Flex sdk beta 3 and Adobe AIR beta 3 just release to Adobe Labs yesterday, so I have updated my version checker AIR application to detect the new SDK and also compiled the app against the new AIR classes targeting the new AIR runtime.

All other blog references will be pointing to this new version

>>>> here <<<<<.

I just recently was made aware that there are actually 3 different “builds” of Flex SDK “hotfix 3″ out there.
1. Originally hotfix 3 was applied to hotfix 2 (updating a few swcs) - version 1
2. Late summer 2007 it was realized this confused some folks so the hotfix kb article was replaced with a full version of the SDK with the fixes applied - version 2
3. Flex Builder 3 beta 2 shipped with the latest/greatest SDK from the 2.0.1 branch which is an equivalent to hotfix 3 SDK - version 3.

These versions should be functionally identical afaik.

I updated my version checker to detect and differentiate these versions. I have updated the original blog entry here and also have links to the update AIR app here.