As of today, Railo 3.1 is now available at CFMLdeveloper.com.

If you already have an account then simply login to HELM and go to Packages -> add new and choose one of the new Railo Plans. Please note that the SETUP fee still applies for all new packages, but is still a one-time fee for fraud validation purposes and your hosting is then FREE forever. For more info please refer to the HELP pages.

If you do not yet have an account then simply SIGNUP from the hosting page.

Please don't forget to check the Hosting support pages if you get stuck, most common questions can be found there.

l have recently decided to try out MangBlog for the new cfmldeveloper.com site and I have to say I really like it much better than BlogCFC (sorry Ray).

Because MangoBlog allows you to add custom pages you can pretty much use it to create your entire web site with a basic CMS as long you don't need to do anything complex on your pages, at which point you may find the tinyMCE editor too restrictive.

When you add a custom page to MangoBlog the "title" is used not only on the page but also on the navigation menu, which I didn't find too useful as I did not want the menu text and page title to be the same. So I was instantly thrown in at the deep end with a requirement to customise MangoBlog, which thankfully turned out to be very easy as it is very well written and easy to understand.

MangoBlog is written in classic CFML style using imported tag libraries and <mango: mytag attributes> syntax as apposed to using the OO style frameworks that are popular these days.

Adding a custom page title is a snip.

When adding a new page, simply add a new custom field like this

label:    page title
key:      pagetitle
Value:   My Page Title

 

Now edit the page.cfm file in your skin folder and edit the code that displays the <mango:Blog title />, it will look something like this depending on your skin.

<h1 id="banner-header"><a href="<mango:Blog url />" accesskey="1"><mango:Blog title /></a></h1>

and change it to this

   <mango:PageProperty ifHasCustomField="pageTitle" customField="pageTitle" />
     <mango:PageProperty ifNOTHasCustomField="pageTitle"><mango:PageProperty title />
   </mango:PageProperty>

This checks for the existance of the "pageTitle" custom field on each page, it is exists then it will display that value, otherwise it will display the title.

You can use the same method to insert any custom field values on any page.

It has been a well known fact for many years (to some of us at least) that ColdFusion (or rather the JRE) caches DNS look-ups forever until the service is next restarted.

The caveat of this is that if any domain name you are connecting to from CFML has had a DNS change such as a change of IP address then code will suddenly stop working until you next restart CF.

Areas that will affect include:-

• SMTP servers in the CFADMIN
• Database Servers in your Datasources
• CFHTTP calls
• Web Services
• CFFTP, CFPOP, CFEXCHANGEMAIL, CFIMAP, CFMAIL

Plus any other tag, CFX tag, java class that allows you to connect to a remote server.

This has never really caused us any major issues, occasionally we had had a customer complain that CFHTTP calls have mysteriously stopped working, or that they could no longer connect to their payment gateway after the provider made some updates, but it has been so rare that restarting CF was an acceptable solution.

Recently we got a notice from our payment gateway provider (SagePay formerly ProtX) telling us that their IP addresses would change. Knowing this would affect CF and that we have several customers who also used SagePay I knew we would have to restart CF on every server to make sure their ecommerce stores did not break.

This prompted me to look into this problem, find out why the JRE cached DNS look-ups and see if I could change it.

After some investigation I learned that the class used to lookup host names for HTTP operation is the Java InetAddress class

If You read the above page you can see that the result of positive host name resolutions is cached forever, it also advises how to override the default behaviour with the following property.

networkaddress.cache.ttl 
Indicates the caching policy for successful name lookups from the name service. The value is specified as as integer to indicate the number of seconds to cache the successful lookup. The default setting is to cache for an implementation specific period of time. 

In a standard ColdFusion installation you would find this in the following file:-

C:\ColdFusion8\runtime\jre\lib\security\java.security

If you are using a custom JRE in a J2EE type installation then the path may be something like:-

C:\Program Files\Java\jdk1.6.0_12\jre\lib\security\java.security

In a CF multi-server installation:-

C:\JRun4\jre\lib\security\java.security

Find the following line

#networkaddress.cache.ttl=-1 

and change it to

networkaddress.cache.ttl=14400

This sets the TTL to 14400 seconds (4 hours).

Now you will note that there are various warnings about DNS cache poisoning and the security manager which may scare you. So also note that InetAddress by default resolves against localhost, so if there was a cache poisoning problem then the problem is with your local machine or DNS server thus any application that resolves DNS lookup-up against localhost will be affected, which includes ASP, PHP, local services etc, so ColdFusion/Java is really not where you area of concern should be when it comes to DNS, but rather that your local machine is secure and that your DNS server is protected against cache  poisoning. Plus the problem would still exist when you restart CF anyway, and this is probably a fairly common occurrence  for most people, so I personally would not worry about it and I think this is a pretty daft and pointless reason for this default setting. Some may disagree, but hey that's their prerogative.

I upgraded a CF8 server to CF9 the other day and thought everything had gone fine, but today I received an email from a user saying his Microsoft Access DSN was no longer working.

The error was:

[Macromedia][SequeLink JDBC Driver]TCP/IP error, connection refused

First course of action was to google the error as usual, which turned up nothing useful, so then started my own investigations using a bit of common sense.

I checked the SequeLink ODBC services and they were running, so I tried to restart and they would not.

It was at this point that I noticed all the CF8 services were still running, which was odd, because while CF9 leaves CF8 intact it should disable and stop all the services. This has been the case since CF7 in fact that the previous version is left intact.

Thinking back on my install I remembered CF informing me that it had detected CF8 was installed and had changed a couple of ports for some reason, I thought nothing of it at the time as I presumed it would not cause a problem, but in hindsight I should have known better as whenever CF has ever used alternative ports for anything in the past it has always caused issues.

I also did not stop all the CF8 services prior to installing CF9, as the installer always does this for you anyway, but I guess in this case it did not and thus detected a conflict. So a lesson learned there, always stop all services prior to an upgrade.

So anyway I was sure the problem was with the ODBC service, so the next step was to hunt for the tcp settings, this actually proved to be quite simple in the end.

I first checked the windows service and see where the exe file is located, which pointed me to
D:\ColdFusion9\db\slserver54\bin\swagent.exe "ColdFusion 9 ODBC Agent"

Ah now my memory was starting to clear, this is where the SeqeuLink drivers are.

1. Look for config files that may contain tcp port settings.
   This led me to the following file

   
   D:\ColdFusion9\db\slserver54\cfg\swandm.ini

2. Now look for TCP port references, which led me the following lines in this file
   ServiceConnectInfo=tcp://LOCALHOST.19999
   ServiceConnectInfo=tcp://LOCALHOST.20000

   
   

3. I then compared this to the CF8 settings, which showed
   ServiceConnectInfo=tcp://LOCALHOST.19997
   ServiceConnectInfo=tcp://LOCALHOST.19998

   
   

4. So clearly CF had indeed changed the ports due to a conflict. So I simply set the ports back to 19997 and 19998 in that order, stopped and disabled all the CF8 services, and started the CF9 ODBC services and voila everything was fixed.

So what initially seemed like it was going to be PITA problem actually only me less and 1 hour to resolve, and most of that was spent googling for a solution and finding nothing. Once I actually started my own investigation it actually took less than 30 minutes to diagnose and resolve, sods law.

If you are having some other type of SequeLink ODBC service errors that are not fixed by my solution then the following TechNote may also help you out.
http://kb2.adobe.com/cps/188/tn_18800.html