Having issues with your BlazeDS/Flex app? Try changing the display-name

This post is more than 2 years old.

For days now (well, days in man hours, today is my first day back from vacation), I've been struggling with an issue concerning Flex and BlazeDS. Specifically an issue with the Flex front end receiving messages being sent by BlazeDS. I finally found the answer today, but before I go on, please note I'm a bit fuzzy on the details here - all I know is that it worked and I'm about as freaking relieved as a developer can get.

Ok, so I as said, the issue involved the use of BlazeDS and an Flex based AIR application. This is for work obviously so you also know that JBoss is running on the back end. For some reason, JBoss has refused to log any errors for me. I can get all kinds of nice console messages, but stack traces and other errors simply go into the void. So while I was sure there was a server side error, I was never ever to actually see it.

I then found this post, and Alex Glosband's suggestion for adding Service.Message.JMS to my services-config.xml file. This helped in that I could now see that when Flex tries to listen to BlazeDS, it was getting an error from the server. Unfortunately, the error was an NPE with no detail as to what was actually wrong. It did confirm though that the error was server side.

After getting a bit desperate, I tried a new search, this time including some of the result I was seeing in my console. My full search term was: jms destination null flex blazeds "There was an unhandled failure on the server. java.lang.NullPointerException"

This returned exactly two results, both on the Adobe forums. Unfortunately, when I clicked on one, I got a JavaScript alert:

ERROR: Sorry, you do not have permissions to access the requested object.

I was then pushed away from the thread. On a whim I thought - let me just disable JavaScript. There is no way that will work. Surprisingly, it does. (Folks, using JavaScript for security is not security.) I don't know if that is considered a hack or not, but the message post revealed something interesting. It mentioned the display-name value in web.xml. It suggested that if something else was using the same name, you could have a conflict. On a whim I edited the name, restarted, and bam, things began to work!

Long story short: If you are working with BlazeDS and finding that things don't seem to work, ensure you have a unique name in your web.xml file. I have zero idea what else is running on my box that could be using that value, but, I don't care. It works!

Raymond Camden's Picture

About Raymond Camden

Raymond is a senior developer evangelist for Adobe. He focuses on document services, JavaScript, and enterprise cat demos. If you like this article, please consider visiting my Amazon Wishlist or donating via PayPal to show your support. You can even buy me a coffee!

Lafayette, LA https://www.raymondcamden.com

Archived Comments

Comment 1 by dbmuse posted on 1/6/2009 at 4:58 AM

and the default display name that you changed was ?

Comment 2 by Raymond Camden posted on 1/6/2009 at 5:28 AM

It was BlazeDS, which I assume is a default.

Comment 3 by David Stockton posted on 1/6/2009 at 2:22 PM

Hi Ray,

Please forgive the marketing angle but I think this is really useful information (for you and others)...

Did you know that FusionReactor the CF server monitor runs on practically any J2EE Server?

"JRun, JBoss, Websphere, Weblogic and can be installed on any servlet or J2EE engine e.g. Tomcat, Jetty"

You can get the same functionality/interface as you do when you're monitoring CF pages (FusionReactor can decode AMF!).

What's more... because FusionReactor licences are per server not per instance if you're running this on a machine that already has FusionReactor installed you get this for no extra cost! If you have the Enterprise version then you don't even need to run the installer - just go to "Enterprise -> Instance Manager" and follow the instructions to add your JBoss instance.

Maybe this will help you get some more debugging info?

Best of luck!
David

Comment 4 by Raymond Camden posted on 1/6/2009 at 5:46 PM

Would it report issues fired by Java code?

Comment 5 by David Stockton posted on 1/6/2009 at 5:56 PM

Yes... Java, JSP... whatever is running you can stack-trace.

Comment 6 by Raj posted on 2/27/2009 at 8:54 AM

Many thanks for posting this fix. It amazes me that something silly like that would cause a fundamental problem with BlazeDS. I was stuck for the entire day because of this stupid issue. Thanks again.

Comment 7 by Corev2 posted on 4/18/2009 at 8:34 PM

Man !
You saved me a lot of time. That really works despite I couldn't believe. Thanks a lot.

Comment 8 by RaviTeja posted on 8/20/2009 at 8:33 PM

Thank you man I was so desperate and almost gave it up before finding out the source of the problem. Seriously, your solution though sounds silly it worked !!!!!!!

Comment 9 by Mike Robinson posted on 9/12/2009 at 8:18 PM

Thanks for the tip. That help me a lot.

Comment 10 by Eric James posted on 12/4/2009 at 4:16 AM

Thank you! This helped me a lot too.

Comment 11 by Rob Huddleston posted on 2/23/2010 at 10:03 AM

Thanks, Ray. Your post here just kept an LCDS class from blowing up. (And yes, this fix works for LCDS as well.)

Comment 12 by Raymond Camden posted on 2/23/2010 at 4:28 PM

Glad to help. :)

Comment 13 by does&aposntMatter posted on 9/17/2010 at 9:48 AM

WOW.... this issue sprang up on Adobe LCDS training session. Did'nt occur it did be so simple yet so subtle. What's the relations/relevance?

Comment 14 by Brett Randall posted on 3/12/2011 at 3:04 PM

If you arrived at this thread having searched for ""There was an unhandled failure on the server. java.lang.NullPointerException" or similar, you might get a result here.

I don't know about display-name, I didn't try changing it. In my case I had the same WAR file deployed as two different contexts, which you might think would be OK, but it isn't. I guess that both contexts share the same display name.

As soon as I undeployed the second context containing the BlazeDS service, the first context started functioning properly.

Thanks for the tip.