Andrew Powell

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.