Tuesday, October 9, 2007

ColdFusion 8 flex2gateway Error 500 java.lang.NullPointerException

I recently upgraded to CF8 and experienced a small problem when i went to configure my AMF end points and channels. First I must say that I like the new method of keeping the channel definitions in the services-config while breaking out the destination settings into separate files like remoting-config. Now all that being said I encountered the following error when going to http://localhost/flex2gateway/ after copying over my old settings into these files.
500
java.lang.NullPointerException at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java:283) at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java:543) at jrun.servlet.jrpp.JRunProxyService.invokeRunnable(JRunProxyService.java:203) at jrunx.scheduler.ThreadPool$DownstreamMetrics.invokeRunnable(ThreadPool.java:320) at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java:428) at jrunx.scheduler.ThreadPool$UpstreamMetrics.invokeRunnable(ThreadPool.java:266) at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)
The problem occurs because apparently while it was ok to have two channels share the same endpoint uri URL in CF7...

in CF8 it doesn't work. The solution is to simply change the endpoint uri for the new channel. (You should leave the class definition the same for the uri.)
I doubt a lot of people are going to have this problem as it seems that most people are not using custom channels or destinations.
At any rate.... once you make this change, stop and restart the cf server you should be able to hit the uri in a browser window and get .... nothing (a blank page) which is good, it means it is working.

Thursday, November 9, 2006

Flex Problem : Datechooser control not displaying number digits for days of month



I recently had the following problem:

I have had this completely stylized application that I had been working on for quite some time. I went to add a simple date chooser control to the application. And this is what I got...

The solution was not obvious. (Well at least not to an idiot like me.) 




Now as you can see this wasn’t going to work. At first, I assumed that my style for the control was messed up; however it was ok.


[DATE CHOOSER STYLE DEFINITION]
DateChooser {
headerColors: #fab000, #ff6600;
todayColor: #666666;
rollOverColor: #ffff00;
selectionColor: #ff9900;
color: #000000;
backgroundColor: #ffffff;
}

I messed around with the thing for a about half an hour. In that time I was able to determine that the error occurred whenever I would embed the date control inside of any container that was at any level inside of an accordion container. If the date chooser is not contained inside of an accordion, or any container that is at some level inside of an accordion, then the date chooser renders correctly. What I wondered was the problem. At first, I thought maybe this was some Flex bug, some incompatibility problem with the accordion, and the date chooser. I couldn’t figure out why it only occurred with the accordion container. After all, it is just another container. Then I decided to look at something that makes the accordion container different... something that I did to make it different.

[ACCORDION STYLE DEFINITION] 

Accordion {
headerHeight: 20;
dropShadowEnabled: true;
shadowDistance: 3;
backgroundAlpha: 1;
highlightAlphas: 0.36, 0.02;
llColors: #6633, #0033, #cc00, #9900;
selectedFillColors: #fab000, #3300; 
themeColor: #6600;
backgroundColor: #fab000;
borderColor: #9900;
textIndent: 18;
openDuration: 441;
}

At first, I didn’t notice what was causing the problem I wasn’t even positive that the style was causing the problem. I started by commenting out the entire style definition for the accordion. That worked... the date chooser rendered correctly. Of course, that wasn’t going to work. I then went and commented out different sections in the style until I figured out what was causing the problem......



There it was, in the end, a rather simple solution.

Tuesday, October 24, 2006

Referencing the 'this' scope inside of a CFC


When calling the functions of a CFC it is important to note the difference between the way Java uses the “this” scope and the way ColdFusion references it.
 
In Java, a call to this.someMethod() makes the request “inside” the instance. Just as if you had simply called someMethod(). Within a CFC a call to this.someFunction() applies the function call from “outside” the object instance as if you had instantiated another instance of the class and are now calling the function on it. (Similar to the way the CFINVOKE tag works.) The key problem with this is that if someFunction() is a private function a call to this.someFuntion() will fail as the caller is not in a part of the same scope. The solution is to never call a local function from inside of a CFC using “this.” as you might be inclined to if you come from a Java background but instead to call the function directly. e.g. x=someFunction() not x=this.someFunction().