Posts Tagged ‘BlazeDS’

Flex, BlazeDS, ActiveMQ, Spring application context gotchas.

Thursday, April 15th, 2010

In one of my current projects I have been fighting a lot getting BlazeDS, ActiveMQ and Spring to dance together.

We are using the Spring BlazeDS integration project to connect our Flex frontend with our Java backend.

The project uses remoting AMF and messaging in the communication and the backend consists of three independent Java applications.

One of the toughest things is configuring ActiveMQ to work with BlazeDS.

Lately I had to build a session listener, that detects when users are logging in and logging out. This proved extra hard, as the the session listener is configured in the web.xml and doesn’t have access to the beans in the application context directly.

Inside the session listener I need to get the application context, to get the beans from the Spring context.

Unfortunately with ActiveMQ and BlazeDS, we need a separate context file, than the default applicationContext.xml, else there will be problems with the Flex message broker and ActiveMQ.

I solved this by getting the messaging context, instead of the application context inside the session listener. Here is an example:

public void attributeAdded(HttpSessionBindingEvent e)
{
  logger.info("Attribute added to session: " + e.getSession().getId());
e.getSession();
ServletContext servletContext = session.getServletContext();
WebApplicationContext appContext = (WebApplicationContext) servletContext.getAttribute(WEB_APPLICATION_CONTEXT_MESSAGING);
UserBrokerAccountManager userBrokerAccountManager = (UserBrokerAccountManager) appContext.getBean(USER_BROKER_ACCOUNT_MANAGER_BEAN_ID);
userBrokerAccountManager.doSomething();
}

Basically this shows how to get access to specific beans inside a specific application context.

Another useful method is getting all contexts from the servlet context. Here is a method to do exactly that:

/**
* Show servlet attributes.
*
* @param servletContext the servlet context
*/
@SuppressWarnings({ "unused", "unchecked" })
private void showServletAttributes(ServletContext servletContext)
{
  Enumeration<String> en = servletContext.getAttributeNames();
while (en.hasMoreElements())
  {
    logger.info("Servlet attribute - Enum: " + en.nextElement());
  }
}

Post to Twitter

BlazeDS and Weborb

Thursday, April 1st, 2010

In the last few projects we have been working on, I had the chance to work on two competing Flex messaging technologies: BlazeDS and Weborb.

Here are a few of my observations and comparisons:

Weborb returns Array, while BlazeDS returns ArrayCollection, when returning a List (from Java).

Weborb seems to need less configuration than BlazeDS, while BlazeDS is more strict. For example, in Weborb we can use the GenericDestination and it will catch all requests for services, while BlazeDS needs a configuration for each service in the remoting-config.xml like this:

    <destination id="applicationService">
        <channels>
            <channel ref="normal-amf"/>
        </channels>
        <properties>
            <source>*</source>
        </properties>
    </destination>

BlazeDS has infinite more online documentation, while Weborb relies on paid support from Midnight Coders.

BlazeDS has better (easier to control) logging:

Place the following inside: WEB-INF/flex/services-config.xml

    <logging>
        <target class="flex.messaging.log.ConsoleTarget" level="Debug">
            <properties>
                <prefix>[TradeNovaFX]</prefix>
                <includeDate>true</includeDate>
                <includeTime>true</includeTime>
                <includeLevel>true</includeLevel>
                <includeCategory>true</includeCategory>
            </properties>
            <filters>
                <pattern>Endpoint.*</pattern>
                <pattern>Service.*</pattern>
                <pattern>Configuration</pattern>
            </filters>
        </target>
    </logging>

A little hint with BlazeDS: DON’T add remoting-config.xml and messaging-config.xml on the backend. It will only give problems!

BlazeDS has what I consider a huge bug when serializing/converting a Number with the value NaN to a Java value. Basically NaN is converted to 0, instead of null. This can break code that relies on null values, which is very commonplace in backend programming.

Luckily the guys at Farata has a couple of solutions for this.

Post to Twitter