Nathan Mische's AMF Explorer is a nice add-on for Firefox which allows to seamlessly debug AMF traffic from within Firefox. Looks very promising, especially as the capturing of the AMF packets seems to be written in JS (not sure, though).

https://addons.mozilla.org/en-US/firefox/addon/78928

Update: Nathan confirmed that the add-on uses an JS to deserialize the data. The implementation is based on the BlazeDS java code. Nice job!

Dirk.

In case you missed this year's W-JAX conference, here are the slides for my session "Flex and Spring integration". I'll post the demo files later. Enjoy!

Dirk.

My article "Spring trifft Flex" (Spring meets Flex) for the German Java Magazin is now available online for free. Check it out here!

Dirk.

After a lot of Flex and Java coding I'm currently doing a CF/Flex project again. I haven't really touched CF for quite some time and decided to use ColdSpring in this project just for getting an idea of it. I've used Spring in my past Java projects and wanted to get a feeling for ColdSpring - and it really rocks! Make sure to check it out!

One thing I remembered from my past Flex/CF projects was that it always was not that easy to build a CF backend that can both serve Flex clients with AMF over HTTP (i.e. Remoting) and "normal" HTTP clients (standard-browser-HTML-you-know-what-I-mean). For example, the error handling is a bit difficult as you want CF runtime exceptions to get transported back to Flex clients as FaultEvents but for HTML clients you want a nice HTML output with error information. I never found a decent solution for this... until now :) Sometimes it is good to change perspectives (or to switch languages).

In the past Java projects we either used BlazeDS or LC on the backend side. The server side API offers a broad set of ways to access the incoming HTTP requests and the AMF payload. A main class in the BlazeDS and LCDS API to access all that information is the flex.messaging.FlexContext class. The idea is quite simle: in your server side Java code you can use the FlexContext class to get the current client (wrapped in a FlexClient object), the sessions (wrappers around the HTTPSession) and so on. So to check if a method was called from a Flex client you just have to check if FlexContext.getFlexClient() is != null.

Thanks to the fact that CF8 uses the same (or parts of) server side Flex API to implement the Flex <-> CF Remoting infrastructure you can also use the same method in your CFCs making it *much* easier to distinguish between Flex and HTML-client requests. A simple example goes like this - it could be used inside your Application.cfc's onError method:

Dirk.

Springsource just announced the availability of RC1 of the Spring BlazeDS Integration project.

Some of the interesting new features are the option to export Remoting Destinations by using Java 5 Annotations instead of classic XML-wiring and full support for custom JavaAdapters like those provided by dpHibernate or Gilead.

Dirk.

In the recent issue 05/09 of the German Java Magazin you'll find my article "Spring trifft Flex" (translation: "Spring meets Flex") where I show how to use Flex, BlazeDS and Spring together by using Spring BlazeDS Integration.

Btw, it is a print magazine so you'll have to buy it - and no, I don't get money if you buy it :)

Dirk.

Update: the link does not work anymore :(

While browsing the Adobe Open Source web page base I stumbled across the "BlazeDS for .NET" page - it's a bit early for April Fool's Day Joke so it seems as if Adobe finally brings AMF to the .NET platform. Still, it seems a bit odd that all the links on that page point to the Java version... so maybe someone from Adobe can clarify?

Anyway, a .NET implementation of BlazeDS would be huge!

Dirk.

I found a very subtle behaviour in BlazeDS yesterday. I assume that this also applies to LCDS, haven't tested it though.

BlazeDS comes with a proxy service that allows you to solve the crossdomain data loading restrictions of Flash Player (i.e. a SWF on server A may not load data from a different domain B, unless domain B allows the SWF explicitely). To proxy the requests, BlazeDS uses the famous HTTPClient library. I used the proxy in several projects so far and never had any issues with it - until yesterday...

In a current project BlazeDS is used to proxy between a Flex client application and a hosted Adobe Connect account that lives on the admin.emea.acrobat.com sub-domain. When a user logs in to the Connect system, the Connect server sends back a Cookie with the domain set to .acrobat.com (notice the leading dot). However, this Cookie is ignored by the BlazeDS proxy service and you'll get a warning message in the server logs similar to: "Cookie rejected: "$Version=0; BREEZESESSION=Sbreez8chuv13an7trwkon; $Path=/; $Domain=.acrobat.com". Domain attribute ".acrobat.com" violates RFC 2109: host minus domain may not contain any dots" - this means subsequent calls made by BlazeDS will not send any Cookies with the request which mixes up things badly as you can imagine.

So - the Cookie returned by acrobat.com is not RFC 2109 compliant because the RFC does not allow compliant clients to accept Cookies which domain attribute is set to value starting with a dot (i.e. .acrobat.com) when the Cookie itself was set by a domain with a subdomain that contains a dot (i.e. admin.emea is the subdomain)... everyone got that?

The underlying HTTPClient library used by BlazeDS by default uses a Cookie policy that only accepts RFC 2109 compliant Cookies (which is a rather strict setting). In contrast, all modern browsers use a somewhat lax Cookie interpretation to maximize compability with existing web sites. So while everything works nicely in a browser it does not with BlazeDS' proxy service.

I was able to solve this issue by extending the default HTTPProxyAdapter that comes with BlazeDS. This custom Adapter sets the CookiePolicy used by the HTTPClient to BROWSER_COMPATIBILITY and this actually ensures that the Cookie returned by admin.emea.acrobat.com is accepted - puh :)

I also logged a bug for this in the BlazeDS bugbase and attached my workaround for it. So if you want to see this fixed in BlazeDS feel free to vote for it.

Dirk.