Apparently Flex apps contain an “embedded” portion of BlazeDS config files that they are compiled against. This means that a recompile is necessary whenever you choose to change BlazeDS config files like messaging-config.xml etc. If this is the case, what is the point of separating confi information externally if it is compiled into the application anyway?
Direct quote from Adobe:
“The destination and channel information is available to the client as a result of compile-time access to the XML configuration, which the server uses to manage services at runtime and the compiler uses to embed a portion of the configuration into the client.”
Here is a link on how to get a new Flex Builder project up and running with BlazeDS support:
The key insight to take away is that BlazeDS is basically just a couple of JAR files that need to be stored in your WEB-INF directory. Up until now, I had been creating separate flex web-apps via command line (generating WAR files) that each respectively contained their own WEB-INF directory and services-config.xml etc. Flex Builder requires you to either have an unpackaged WAR file already set up inside your web server containing BlazeDS JAR files, or to use a centralized model where your downloaded BlazeDS (expanded) WAR file is your central web-application that contains all your BlazeDS apps inside of it.
Wow I’m proud of myself today! So I had this problem where my generic Flex ‘chat’ client was able to SEND JMS messages to FioranoMQ but not RECEIVE them. After days of reviewing my configuration and my code, I realized the problem wasn’t with me, it was with BlazeDS. So I downloaded the BlazeDS source code, did some investigation, and “fixed” the problem.
What I did:
I found out that within the BlazeDS source code, the outgoing ‘Message’ objects had null ‘message ids’ and this was throwing an exception that was never handled. The method where the problem originated was called “pushMessageToClient” in the class “MessageService.java”. This method was passed a Message object, and the method basically cloned the given message in order to send it to each client (to keep each message to each client unique). My analysis revealed that the message that was passed to this method had a null message id, and therefore, each cloned message had a null message id as well. After cloning the original message, the method “pushMessageToClient” called a method “routeMessageToMessageClient” and this is where the exception was thrown. At the beginning of the “routeMessageToMessageClient” method, the code checked to see if the message had a unique id, and if it did not, a “MessageException” was thrown. This exception was propagated back to the “pushMessageToClient” method but was there was no code to handle the exception. In other words, the exception was definitely caught, but no log entries were written so this is why the Tomcat server did not know what was going on. Anyways, it turns out that the BlazeDS developers had commented out a line of code within the method “pushMessageToClient” which, by default, assigned a ‘message id’ to outgoing messages. They might have done this because they assumed that the cloning process would ensure an assigned message id; however, in my particular case, the original message itself had no message id! I still need to investigate why this was the case, but uncommenting this line (and including the proper import) fixed the problem and made sure that, by default, a unique message id is always assigned to the outgoing message.
The source files in question:
- contains method “pushMessageToClient”
- contains method “getMessageBroker”
- contains method “routeMessageToMessageClient”
- Uncomment line ~629 in method pushMessageToClient within class MessageService.java
- Include UUIDUtils import in MessageService.java
- import flex.messaging.util.UUIDUtils;