Default

Since fixing bugs is not the only thing that is part of our duty when maintaining the Railo source, some new features found their way into the latest patches.

<CFHTTP>

Sometimes it is quite useful to execute a CFHTTP request to a certain server by using the session of the current user. There are some different ways of how to acomplish that:

1. First you of course could just add the cfid and the token to the requested url
   
   <cfhttp url="http://www.myurl.com/index.cfm?#client.urltoken#" resolveurl="no">
   but this code might not work when you use J2EE sessions since these could be not accepted in the url without a ';' by the app server depending on some settings.
2. An other way of how to do it is by passing the id's as parameters of CFHTTP
   
   <cfhttp   url="www.myurl.com/index.cfm">
<cfloop index="item" list="#client.urltoken#" delimiters="&">
<cfhttpparam type="cookie" name="#listFirst(item,"=")#" value="#listLast(item,"=")#">
</cfloop>
</cfhttp>
   
3. Much more elegant (supported in Railo 2.0.0.018) is the addition attribute addtoken which writes the cfid-cftoken/jsessionid into the request's header. In this case it will work for J2EE sessions as well.
   
   <cfhttp url="http://www.myurl.com/index.cfm" addtoken="yes" resolveurl="no">
   

Now CFHTTPPARAM supports type XML as well. So the compatibility to CF8 is closer in this term.

Flushing the cache

Railo offers the powerful posibility of using the trusted cache per mapping or per custom tag directory. It sometimes makes sense to flush all the templates from the trusted cached mappings. This can be easily done with the new function pagePoolClear(). When called all templates from the trusted cache will be flushed and reloaded upon the next request. This is very useful when you release an update of a certain mapping.
Another useful function is the new function pagePoolList() which returns an array of all pages that are in the page pool at the moment. You can easily test it by executing the following code:

<cfdump eval=pagePoolList()>
These functions have been added in the patch 2.0.0.019

Reloading the Admin

In a big clustering environment it sometimes makes sense to distribute the Railo configuration files from one master server across the different slave servers and reload all slave contexts on each server instead of editing the settings on each slave server by using either the slave's local web or server administrator. Hence we introduced in Railo patch 2.0.0.019 a new <CFADMIN> action called reload which allows you to reload the Railo environment from the underlying XML file. You can now call something like follows:

<!--- this reloads the local context from the local railo-web.xml file --->
<cfadmin type="web" action="reload" password="*****">
<!--- this reloads the global context from the local railo-server.xml file and reloads all contexts --->
<cfadmin type="server" action="reload" password="*****">

Custom Tag handling

Although we long hesitated to do so, we finally implemented the recursive search of custom tags in sub directories. This is now part of the administrator as well. You can disable this feature by unchecking the box labelled: Search for custom tags in subdirectories (not supported for archives). This then should improve the performance of your custom tag calls. Be aware that Railo then only scans the local directory and the directories listed in the local administrators.
In addition for performance reasons we added the possibility of turning of the additional scanning of the current local directory for a certain custom tag. This can be disabled in the same place.

Client Storage

Railo offers the possibility of storing client variables in the following three different ways:

1. Cookie
   All client variables are stored in the cookie of the client. Be aware that a cookie can only store up to 1024 bytes of data.
2. File
   This is the default if nothing else is selected. Based on the session id's Railo assigns a certain file (located in the folder {railo-web}/client-scope). In this file all client variables are stored. If no client variable is used, no file is created. Railo deletes all client variable files either older than 90 days or the oldest ones as soon as the size of the client-scope folder surpasses 100MB of disk space.
3. Database
   When you define a datasource in the <cfapplication> tag Railo creates the necessary client variable tables in the assigned datasource database. All variables are stored inside the database. All variables older than 90 days will be deleted.

SES support

Railo now supports SES (search engine secure) formatted URL's. Of course you need to define the particular servlet mapping in the application server (normally found in the app-default.xml) like follows (it might vary between the different appservers):

...
<servlet-mapping url-pattern="*.cfm/*" servlet-name="CFMLServlet"/>
<servlet-mapping url-pattern="*.cfc/*" servlet-name="CFMLServlet"/>
...
When you call an url like: http://www.railo.ch/blog/index.cfm/2007/11/21/Railo-WEBINF-and-roots the CGI variable path_info will be filled by Railo with the string following index.cfm. So in the above case it will contain:
/2007/11/21/Railo-WEBINF-and-roots
Many different Applicatios use SES Url's like Raymond Camden's blog or CFWebstore by Mary Jo Sminkey.