The advantage of the BonCode connector for me  is that is does away with the need of having ISAPI filters and the jakarta vDir, which is required when using the native tomcat connector.
The problem with the regular connector is that you cannot enable CF on a site simply  via the web.config file, you have to into IIS and do some work, or use ColdFusion's "web server config tool".
As I want to offer ColdFusion 10 on cfmldeveloper.com I need a way for users to be able to enable CF or Railo themselves without having to contact me, the best way to do this currently is with BonCode.

The current Railo installer now includes the BonCode connector as default, so that is covered, but ColdFusion 10 uses the regular connector and still has the above issues, so what if you want to run Railo and ColdFusion together on the same server using BonCode? Well with a bit of help from Bilal (the creator of Boncode) I managed to get this working.

Firstly install Railo as normal but DO NOT install the IIS connector, choose NO for that option.

Now open C:\railo\AJP13 and rename installer.settings to something else so that it is not used, if you know what you are doing with this file then feel free to use it instead, see the docs HERE.

Now run the connector_setup.exe and follow the steps, enabling any options you require, again refer to the docs for more details. For this article I am using only the default settings.

port 8009 is the Tomcat port that Railo uses, for ColdFusion you would use 8012

Make sure you choose "let me choose specific sites"

choose 1 site that you will enable Railo on for reference, I will use the default website.

Railo should now be working on the default website, if not, then just perform the steps below to do it manually.

Manually enabling Railo on additional websites

In your default web site root, you should have a BIN folder, simply copy this folder to any other site on which you wish to enable Railo.
You can also manually create the BIN folder and copy the following files from the C:\railo\AJP13 folder.

BonCodeAJP13.dll
BonCodeIIS.dll

You will also need to create a file named BonCodeAJP13.settings

The contents on this file are are in the aforementioned BonCode docs, but basically it will look like this.

<Settings>

<Server>localhost</Server>

<Port>8009</Port>

<EnableRemoteAdmin>True</EnableRemoteAdmin>

<EnableHeaderDataSupport>True</EnableHeaderDataSupport>

<ForceSecureSession>False</ForceSecureSession>

<AllowEmptyHeaders>False</AllowEmptyHeaders>

</Settings>

In IIS, you now need to create a managed handler for the site like this

The value for type is "BonCodeIIS.BonCodeCallHandler, BonCodeIIS, Version=1.0.0.0, Culture=neutral, PublicKeyToken=ad590a40d40745cf"
You can find this value in  C:\railo\AJP13BonCodeFullHandlerName.txt

Or you can add it to your web.config handlers section like this.

<add name="Boncode CFML" path="*.cfm" verb="*" type="BonCodeIIS.BonCodeCallHandler, BonCodeIIS, Version=1.0.0.0, Culture=neutral, PublicKeyToken=ad590a40d40745cf" resourceType="Unspecified" preCondition="integratedMode" />

Enable Coldfusion 10 on any website

Install ColdFusion 10 in the usual way, but DO NOT enable the built in connector on any websites.

Now simply do as per the Railo instructions above, except change the settings file as follows. Note the port is 8012 and the EnableAdobeMode setting.

<Settings>

<Server>localhost</Server>

<Port>8012</Port>

<EnableRemoteAdmin>True</EnableRemoteAdmin>

<EnableHeaderDataSupport>True</EnableHeaderDataSupport>

<ForceSecureSession>False</ForceSecureSession>

<AllowEmptyHeaders>False</AllowEmptyHeaders>

<EnableAdobeMode>True</EnableAdobeMode>

</Settings>

Some hints and Tips

Verify engine

If you want to test whether you are using Cf or Railo simply do a

<cfdump var="#server#">

If for some reason all your sites are showing Railo and not CF, and you definitely have the port set to 8012 in the settings file, then you probably have the global configuration set in IIS from a previous Railo installation where you chose to install to all sites.
In which case just download the standalone BonCode connector installer from the website and run the uninstaller, and then run the setup again following above instructions.

No default documents

If you use the wildcard handler (which you will need to enable the CF virtual mappings), you will find that default documents no longer work. To fix this you need to add your default docs to the <welcome-file-list> in tomcat.
You do this in the following file:-
C:\ColdFusion10\cfusion\runtime\conf\web.xml

Wildcard handler

The wildcard handler is required for various functionality of CF which replies on virtual mappings (directories which do not really exist). Using a wildcard handler means that *ALL* traffic goes through Tomcat, so css, js and html files too, which can cause other problems. If you do find this to be problematic then to get round this, you can create empty directories for all the virtual mappings, and stick a web.config file in those folders, and enable the wildcard handler *ONLY* on those folders.

the folders are:-

/CFFormGateway
/flex2gateway
/CFFileServlet
/cfform-internal
/flashservices/gateway
/flex-internal
/rest

your web.config entry would look like this

<add name="Boncode CFML Wildcard" path="*" verb="*" type="BonCodeIIS.BonCodeCallHandler, BonCodeIIS, Version=1.0.0.0, Culture=neutral, PublicKeyToken=ad590a40d40745cf" resourceType="Unspecified" preCondition="integratedMode" />

CFDUMP is an invaluable tag, it helps immensely with debugging and viewing your objects, but annoyingly it requires CreateObject(java) to work, which is often disabled on shared hosting for security reasons, or even if you run your own server perhaps you need to keep createObject(java) disabled but still use CFDump.

This alternative custom tag gives you the functionality of CFDUMP using JavaScript instead.

I originally created this for use on cflive.net because createObject(java) is disabled and considering what cflive is intended for cfdump is definitely required. A few people have asked how I did it so I thought I would release it for the benefit of anyone else who may want to use it.

Note that because it uses JavaScript this is only good for generating dumps to the browser. If you wanted to create a CFDump on the server and put it into an email, then this will not help you a sthere is of course no JavaScript there to render the code.

You can try it out at www.cflive.net where I have used it to replace the original cfdump tag, so just use <cfdump var="#cgi#"> for example.

This tag was created using the JavaScript dump code from Net Grow, which I have modified slightly to give the following additional functionality.

• allow multiple dumps on the same page
• new label attribute to emulate the original cfdump
• plus of course to generate dumps via CFML pages.

You can download the tag here.

How to use

• As a custom tag
  simply drop dump.cfm into your global custom Tags folder or into any folder which you have mapped as a customTags folder in your application.cfc
  or just drop into the same folder from which you are calling it, then call it as per any normal custom tag.
  e.g.
  <cf_dump var="#cgi#" label="CGI Scope">
• via CFIMPORT
  If you do not know how to use cfimport, then go here
  e.g.
  <cfimport prefix="" taglib="/customTags">
  <dump var="#cgi#" label="CGI Scope">
• Replace the original CFDUMP tag
  If you want all your existing code to work without any changes then you can simply replace the original cfdump tags with mine.
  Here are example locations where you will find the tag, you can just do a search for "dump.cfm" inside your CF or Railo installation
  • ColdFusion 9 location
    C:\ColdFusion9\wwwroot\WEB-INF\cftags\dump.cfm
  • ColdFusion 10 location
    C:\ColdFusion10\cfusion\wwwroot\WEB-INF\cftags\dump.cfm
  • Railo location
    C:\railo4\railo-server\context\library\tag
    Railo uses a dump.cfc by default, but if you copy dump.cfm into this folder it will take precedence over dump.cfc

One of my Railo sites has a scheduled task which is supposed to run every night at midnight, which I noticed recently had not been running as it usually sends me an email. After an initial bit of head scratching the cause was actually obvious, if you understand how helicon zoo works and how Railo runs inside Zoo, if you don't then I suggest reading THIS ARTICLE.

Because Railo runs as an IIS process using Helicon zoo, this means that the application shuts down after a period of inactivity as defined by your application pool settings, this is good in that it conserves system resources for sites which are not very busy, but it is also bad for Railo for several reasons.

• every time the application pool shuts down, so does Railo/Java.
• every time the application pool restarts, Railo must start up again, this can make initial page load rather slow.
• every time Railo shuts down, you lose anything that was cached, this must be reloaded again when railo restarts.
• scheduled tasks will of course not run when Railo is not running.

for a small site with no scheduled tasks this probably is not an issue, but if you run a site that does a lot of caching and has a slow start up time, such as mango Blog or Mura CMS, then this could be an issue. also if you have any scheduled tasks which you rely on, this also will be an issue.

In my case the problem was I had setup the scheduled task on the default website, which is never used for anything other than accessing the railo admin and running this scheduled task.

In case this is an issue for you then there are several workarounds.

1. you can Increase the application pool idle timeout, this is how long it will wait until it shuts down when idle.
   
2. setup a scheduled task that calls a CFM page on your site every 5 minutes, which in theory should keep it active, although this may not be the most reliable method.
3. RECOMMENDED: setup monitoring for your website which makes a http request every 5 minutes, thus keeping the site active. If you do not have your own monitoring system then you can find plenty of options on Google.
4. There are also plenty of websites out there which offer online cron jobs, many of which are free, you could use one of these to execute your scheduled tasks or just to keep your site active.
5. Use windows scheduler to run any page on your site every five minutes or just use this for your scheduled tasks instead of railo.
   you can do this using powershell, just set the following command to execute, replacing the url with your own. Make sure you have powershell installed of course.
   powershell.exe -command "(new-object system.net.webclient).downloadstring('http://yourdomain/task.cfm)"

I have just published some fixes and updates to my CFMail Respooler project.

Please refer to original post HERE.

Greetings Railo fans,

In this article I will be covering how to setup and configure Railo with the Helicon Zoo module for IIS and then configure various custom settings. I will continue to add to this article as I find out new tricks and learn more about Jetty, so be sure to check back occasionally if you are using Helicon Zoo.

Contents

1. Why Helicon zoo
2. Installing Railo
3. Enable Railo on your website
4. Search engine friendly url's
5. changing the JVM settings
6. How to set the Java Agent
7. Customising the JVM settings on a per site basis

Why Helicon Zoo

While Railo is a brilliant alternative to ColdFusion and has many benefits right out of the box, one of the problems it does suffer from is that like ColdFusion it runs as a service which means that every website is running inside the same instance of Java/tomcat and thus all websites can affect each other.
If you are only running a single website this is not a problem, but if you run multiple websites on the same server then this can present a couple of problems.

1. Security
   While Railo does offer built in sandboxing which restricts file access to the web root, this only applies to CFML code. If you drop in some Java then this completely overrides any Railo security and allows you to do pretty much anything you like. Your code will have the same level of access as the Tomcat service.
   Sure you can disable direct Java access, but doing this will break virtually every modern app or framework, all of which use Java in some fashion.
2. Stability and performance
   If you run multiple websites then you also run the risk that any one of those sites will kill Tomcat by coming all its resources and thus take down all your other sites in the process.
3. Custom configuration
   As all sites share the same JVM settings, there is no way to configure each site separate out of the box, you would need a custom multiple instance Tomcat setup/installation to do this.

Enter Helicon Zoo, which uses Jetty as the Java servlet container for Railo and runs it as a process inside IIS and thus works in the same way that PHP, ASP etc work with all the advantages.
What this basically means is that every single Railo site is by default running a dedicated instance of Java/Jetty, which runs as the application pool identity. As a result you do not have the same security issues as any Java code that is executed runs in the context of your application pool identity, so you can fully control what Railo can and cannot  do with standard windows permissions in the same way as you would with PHP.
Using Helicon Zoo also provides better performance and stability as well, because each site is a completely isolated Java process,  it cannot affect your other Railo sites. Because each site is running as a separate process, this also means that each site has its own memory heap all to itself, which can either be defined globally (e.g. 256mb for every site) or you can create completely a separate JVM config settings for each individual site if you prefer.

One other advantage you get with running Railo as a process is that it shuts down when not in use to conserve system resources, as defined by your application pool settings. 
what this means is that if you have a site that is not very busy then Java/Jetty/Railo will only be loaded when required, if there is no further activity on your site for say 1 hour (depending on what you have defined in your app pool) then the Java process for this site will be unloaded.
The only caveat to this is that initial load time will be considerably slower each time Java has to load again, plus of course you use more memory as each site will require at least 128MB to run Railo.

cont......

Read more...