Flex Monkey Patches

OK…so I guess I kind of passed over these yesterday in my announcements. To me, the fact that there would be new releases timed with MAX was known and to anyone in the community there was probably a strong suspicion that there would at least be a new point release at MAX 2008. But in an effort to correct my oversight, here are links to the announcements by the product managers:

Matt Chotin (PM for Flex SDK) announces Flex Builder 3.0.2 and Flex SDK 3.2 (with support for AIR 1.5 and Flash Player 10).

Anil Channappa (PM for LCDS and BlazeDS) announces LCDS 2.6.1 and BlazeDS 3.2.

Kind of related to an earlier post: Deploying Multiple LCDS wars to the same servlet container

I found out that you can specify config file tokens as JVM args. This makes deploying the same war file to various deployments that have slight variations for certain parameters easier, since you can deploy the same war, but “tokenize” (and/or use some of the default tokens).

http://livedocs.adobe.com/livecycle/8.2/programLC/programmer/lcds/help.html?content=lcarch_4.html

“You can also use custom run-time tokens in service configuration files; for example, {messaging-channel} and {my.token}. You specify values for these tokens in Java Virtual Machine (JVM) options. The server reads these JVM options to determine what values are defined for them, and replaces the tokens with the specified values. If you have a custom token for which a value cannot be found, an error is thrown. Because {server.name}, {server.port}, and {context.root} are special tokens, no errors occur when these tokens are not specified in JVM options.”

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:

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