Tag: Railo

Today I needed to use JConsole to connect up to a JBoss instance running ColdFusion and Railo. I wanted to see thread usage etc. when starting the application I’m working on.

In the past when I’ve used JConsole, it used to automatically detect the running JVMs and show them in the startup dialog box. However, today I wasn’t seeing the running JVMs.

I could connect using the Advanced option in JConsole and by putting in the JMX Connector URI. But connecting like that means that JConsole does not provide information on threads/memory etc. — stuff I wanted to see.

After a bit of digging around I found that you need to pass the following arguments to the JVM that you want to monitor in JConsole:

-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.authenticate=false

Once I added these JVM arguments and restart my JBoss instance, JConsole automatically detected running JVMs.

Normally JConsole should automatically detect running JVMs. But I believe this has to do with the fact that I was using Java version 1.5.0_16. If you are using Java 6, you shouldn’t need to do this.

In JBoss, if you deploy Railo jars in server/servername/lib folder (basically if you do a global Railo install), then you would have have noticed that JSP pages stop working. It appears that a global install of Railo seems to overwrite the servlet that handles JSP pages. As a result, each time you try and access JSP pages in any other application that is running on the same JBoss instance, you get a message like:

HTTP Status 405 – HTTP method GET is not supported by this URL type
Status report
message HTTP method GET is not supported by this URL
description The specified HTTP method is not allowed for the requested
resource (HTTP method GET is not supported by this URL).

And this is quite irritating as other applications like jmx-console (which rely on JSP pages) stop working.

The way to fix this is to not do a global install of Railo jars. Normally there is no compelling reason to do such an install.

So basically deploy Railo as a EAR/WAR application, with the WEB-INF/lib folder containing all the Railo jar files (instead of server/servername/lib folder), and follow instructions on my earlier blog entry on Fixing Classloader Conflicts in Railo on JBoss.

Since Railo libs are not installed for all apps on the server instance, JSPs start working, and chance of other such conflicts are reduced.

If you’ve been working with Railo on JBoss, I’m sure you’d have run into an issue where the class loader throws error when the JBoss instance is started. These errors are caused due to conflicts between classes that are being loaded up by different applications in the JBoss server instance.

Some have suggested removing a few jar files from the Railo lib folder to get around this issue. Some others have suggested putting all the Railo jar files in the server/servername/lib folder instead of the usual server/servername/railo.war/lib folder. While both approaches work in that Railo starts up without any errors, but both are a ways to get around the problem rather than actually addressing it.

The correct way to fix this issue is to make JBoss isloate classes loaded for different applications, thereby removing the possibiiity of conflicts. On JBoss 5 you can do this if you add a file in WEB-INF/jboss-classloading.xml that contains:

<?xml version="1.0" encoding="UTF-8"?>
<classloading xmlns="urn:jboss:classloading:1.0"
name="mywar.war"
domain="DefaultDomain"
export-all="NON_EMPTY"
             import-all="true">
</classloading>

This defines how an application’s classloader is setup and how the classes loaded for an application are share with other applications in the JBoss instance.

After you add this file into railo.war/WEB-INF, restart the server with all the jars that ship with Railo, and all classes should load up without any issue.

I might have missed this earlier, but I just noticed that Railo is now formally available on JBoss.org.

http://jboss.org/projects/matrix

The link to Railo is under the category “Programming Model”. The links for direct download and documentation are not yet there (as they are for other projects).

Also, it is accessible through the main nav: Projects > Programming Model > Railo.

Over the last few weeks I’ve been working quite intensively with Railo. And over that period I’ve been migrating a lot of my current applications to Railo. The migration process has been relatively painless and that is really impressive. There are two things to look out for: compile-time errors and runtime errors in the code that you migrate.

Railo makes it really easy to uncover compile-time errors. It provides a setting in the Web Administrator that goes off and compiles all the cfm and cfc pages in your application. Imagine if your application has a lot of cfm and cfc files. How complex would it be to test if all of them work ok or not.

Checking for compile-time errors is important as Railo is slightly less forgiving than the Adobe ColdFusion compiler. The Railo compiler verifies tags, attributes, arguments in a little more strict manner — which I think is a positive thing. Not only does it help to keep the code sharp, but also leads to gains in performance.

So to test for compile-time errors, without having to physically click through each cfm page in your application or instantiating each cfc, you can simply setup a mapping in the Server Administrator to the folder where your application lives. Once the mapping is setup, simply go to edit the mapping and hit the compile button. Railo goes through all the cfm and cfc files, compiles them, and reports on any errors it finds.

Here are some screenshots of what needs to be done to check for compile errors: