Andrew Powell

This question has come up to me a number of times lately.   People are concerned that the Spring BlazeDS Integration will mean an end for FlexServerLib.  This couldn't be further from the truth.  There are two main reasons why this is not the end of FlexServerLib:

1. FlexServerLib Extends BlazeDS - The goal of FlexServerLib is to extend BlazeDS. Extending it does not just mean tight integration with Spring.  Yes, we do use Spring for a lot of what's going on under the hood, but that's more of a testament to the power of Spring than an indictment of FlexServerLib.  There are some things that Spring's project just won't do, like a MailDestination for Messaging.  Granted, we may port our solution to both stand alone BlazeDS and the Spring-integrated solution, but it is independent.  We are focused on extending BlazeDS, not just exposing destinations via Spring Beans (although that is nice).
2. Not Everyone Is Using Spring - As much of a shock as this can be, not everyone in the Java world is using Spring.  Some of our functionality that Spring will do easier, is not available to those using...say....EJB.  Well, we provide an easy way to expose EJBs as Flex RO destinations.  There is still a market for extending BlazeDS.

I've been working with the M1 release of Spring BlazeDS Integration for the last few weeks and have decided to share my impressions. There are few things missing, but it's a M1 release, so I'm not expecting the world here. All that's really in place is exposing Spring beans as remote objects. Messaging is not included in any way, shape, or form in this release, but it's planned for the 1.0 release.

I setup my application context files so that the dispatcher servlet only loaded up my BlazeDS related beans. This way, i can test the rest of the application without going through the motions of creating a MockServletContext, etc needed to create a WebApplicationContext so that it won't bitch when running the unit tests. So, my web.xml looks something like this:

...
   
      <context-param>
         <param-name>contextConfigLocation</param-name>
         <param-value>
            /WEB-INF/applicationContext.xml,
    /WEB-INF/timerContext.xml,
    /WEB-INF/securityContext.xml
         </param-value>
      </context-param>

    <listener>
         <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
      </listener>

    <listener>
    <listener-class>flex.messaging.HttpFlexSession</listener-class>
    </listener>

    <!-- The front controller of this Spring Web application -->
    <servlet>
    <servlet-name>BlazeDS Servlet</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>/WEB-INF/blazeDSContext.xml</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
    </servlet>

    <!-- Map all /spring requests to the DispatcherServlet for handling -->
    <servlet-mapping>
    <servlet-name>BlazeDS Servlet</servlet-name>
    <url-pattern>/messagebroker/*</url-pattern>
    </servlet-mapping>
   
      ...

I keep all my custom objects, for the most part, in the applicationContext.xml file.

The approach that seems to have been taken here is just like Spring's integration with Hessian, Burlap, and exporting Web Services. It's pretty simple and straightforward, like it should be. Previously, the Spring integration seemed to be a bit intrusive to BlazeDS, but now it all flows together and you don't have to worry about xml files outside of your Spring configuration files.

As far as integrating Spring Security, it flows seamlessly. If you throw an AccessDeniedException on the server-side, it gets sent to Flex as a FaultEvent. The FaultEvent will let you know that the rootCause is an AccessDeniedException, which you can handle on your client.

Overall, for a M1 release, this is a good, positive, step in the right direction for Spring BlazeDS Integration.

AirFare, developed by Joe Johnston, with the Kayak AS3 API that I wrote, has been announced as a Checkpoint 1 winner of the Ribbit Killer App Challenge.  Joe has put a lot of hard work into this app.  It's a great example of what Universal Mind's new XD team can do with RIA technologies.  Congratulations, Joe, and keep up the good work!

Head over to the Killer App Challenge page if you want to submit your entry and try for one of their cash prizes.

FlexServerLib , the extension project for BlazeDS, is a powerful library that allows you to access functionality on the server, in Flex, as easily as ColdFusion allows developers to access complex server functionality in CFML.  Imagine if sending an email was as easy as sending a message into a destination and receiving an email was as simple as subscribing to the same destination.  This is just some of the functionality FlexServerLib aims to implement.

A topic has been submitted on FlexServerLib for 360|Flex Indianapolis, but if you want to learn more, we need your vote.

Follow this link to vote

Most of us use tools like Charles or Service Capture to help debug our web applications and flex applications.  They show you the AMF data going back and forth between your browser and the server.  It's all very helpful.  However, there's a little trick if you are trying to debug traffic to a local instance of a server.  Say you're running tomcat locally and are trying to debug the calls with one of these tools.  In your browser, you would put:

http://localhost:8080/mycontextroot/myapp.html

This works to test the app, but you don't see anything in your debugger tool. If you want this traffic to show up in your debugger, you need to use the following variation on the url:

http://localhost.:8080/mycontextroot/myapp.html

This will ensure that you do not bypass the proxy settings used to route your web traffic through the debugger.