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!
Archived Comments
and the default display name that you changed was ?
It was BlazeDS, which I assume is a default.
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
Would it report issues fired by Java code?
Yes... Java, JSP... whatever is running you can stack-trace.
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.
Man !
You saved me a lot of time. That really works despite I couldn't believe. Thanks a lot.
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 !!!!!!!
Thanks for the tip. That help me a lot.
Thank you! This helped me a lot too.
Thanks, Ray. Your post here just kept an LCDS class from blowing up. (And yes, this fix works for LCDS as well.)
Glad to help. :)
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?
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.