DougHughes.net

CF7, CF8, Jrun and the JVM

As I mentioned in this post, I described, briefly how my development environment is set up, and how I installed ColdFusion 8 onto the same JRun server where I have ColdFusion 7 installed. A reader inquired about the JVM and if there are any conflicts. Well, the answer is no, there are not. Why? Well, becasue when you deploy ColdFusion 8 as a .ear file onto a server running ColdFusion 7, JRun will use the JRE specified in the java.home variable in {jRun root}/bin/jvm.config, which in my case was 1.4.2_09.

Now, I have been running this configuration since the public beta and have not run into any issues with performance, or even errors occurring when running ColdFusion 8 code. However, I wanted to set-up my ColdFusion 8 to use the same JRE it would if I had done a different install (stand alone, or multi-server). This was easy enough as you can create custom jvm.config files and use them to run your JRun ‘servers’.

Here’s to do it.

Disclaimer: This is for Windows only. I assume the procedure would be similar in a different environment.

1. Download the latest Java SDK and install it. (You may be able to use the JRE alone, but I didn’t test this)
2. Make a copy of jvm.config (located in {JRun root}/bin } and name it jvm_cf8.config. (You can name it whatever you would like, but the rest of the instructions assume you use this name)
3. Change the java.home variable from “C:/JRun4/jre” (It may be different for you) to {new SDK Install path}/jre and save the file.
4. If its running, stop the ColdFusion 8 service.
5. Open a command window and “cd” to {JRun Root}/bin
6. Test the new config by typing jrun -config jvm_cf8.config -start {the name of your ColdFusion 8 server in Jrun}. If you don’t get any errors, you can now set up your Windows service to use this config file.
7. Pressing crtl+c should shut down the JRun server you just started.
8. Type the following to remove the windows service jrunsvc -remove {the name of your ColdFusion 8 server in JRun}
9. Now you need to reinstall the Windows service and tell it to use the new config jrunsvc -install {the name of your ColdFusion 8 server in JRun} -config jvm_cf8.config.
10. You should now be able to start ColdFusion 8 from the Services MMC in Windows.

To verify you are using the updated JVM, log into the ColdFusion Administrator for ColdFusion 8 and go to ‘System Information’ (It’s the blue icon on the top right side of the page) and check the JRE and JVM values.

UPDATED: As noted by Andy Allan in a comment below, when you copy jvm.config and update the java.home variable, you also need to update the java.library.path variable as well. This variable should point to you new instance of ColdFusion. He also warns to be careful with pathing to the new instance as there may be some subtle differences between the new instance, and the ‘default’ instance.

Allow myself to.. uh… introduce myself

My name is Critter Gewlas and I have recently joined the Alagad. In my short time here, I have already had the opportunity to work on several projects. Coldspring, Model-Glue, Mach II, Reactor… you name it. If it’s a framework, I get to work with it in enterprise environments. Seriously, how great is that? It’s much more rewarding than just cataloging my CD collection in the various frameworks :).

I have been working with ColdFusion since 1998 and have been loving it ever since. I also dabble with C#, and another favorite of mine, Delphi.

It’s a great feeling to actually enjoy going into walking downstairs to work. I am very excited about the future of ColdFusion. The introduction of Flex and and Adobe’s new AIR is just icing on the cake, in my eyes. I am also very excited about working with Doug and the rest of the brilliant minds at Alagad. I can already tell that it will be a great and learning full experience.

Running CF8 & CF 7 on JRun with Apache

On my development machine, I run ColdFusion 7 in ‘multi-server’ mode. This comes in handy if you need to create a separate instance of ColdFusion because of needs of a project or client. I also run Apache as my web server. While I am not a big fan of the httpd.conf file (mostly out of lack of familiarity), it makes it a lot easier to run multiple web sites on Windows XP. (Yes, I know there are tools that allow you to do this with IIS, but all the ones I have tried have been buggy and made messing with httpd.conf a pleasant experience). I also add sites to my HOSTS file and give them a ‘domain’ of ‘dev’ (boyzoid.dev, for example). This makes it easier for me to keep track of which environment I am in, and in a lot of cases, save some typing as I usually abbreviate the project (mic.dev, for example).

Like most ColdFusion developers, I wanted to play with ColdFusion 8 when it went into public beta. I wanted to be able to use ColdFusion 8 and not have to deviate much from my development practices. I wound up installing ColdFusion 8 as a .ear file and deploying it to the same instance of JRun on which ColdFusion 7 is running. This way I could manage all my ColdFusion instances in one place. I ran into one small problem though, how do I get a site configured in Apache to use the ColdFusion 8 server rather than the ColdFusion 7 server? For those who may not know, when you are using IIS and multiserver install of ColdFusion, when you add news ‘sites’ to IIS, you ccan specify what instance of ColdFusion to use for the site. The answer was surprisingly simple.

First, keep in mind these instructions pick up AFTER ColdFusion 8 has been installed and deployed to your JRun server and the server is running. It also assumes that Apache has already been configured to work with ColdFusion

1. Go into your JRun Admin and find the ‘server’ you specified when you deployed ColdFusion 8, and click the link. In my case, its named ‘cf8’.
   
2. In the resulting screen, click the ‘Services’ link in the navigation bar.
   
3. In the next screen, click the ‘Start’button next to the ‘Proxy Service’. Take note of the ‘proxy port’, we will need that in a bit.
   
4. Create a directory, with whatever name you woud like) under {Jrun}/lib/wsconfig (In my case, I named it ‘cf8’…original, I know)
5. Open up httpd.conf and create a <virtualHost> to use, or you can use an existing one.
6. In httpd.confand look for a block of code that looks like:

   # JRun Settings
   LoadModule jrun_module "C:/JRun4/lib/wsconfig/1/mod_jrun20.so"
   <IfModule mod_jrun20.c>
   JRunConfig Verbose false
   JRunConfig Apialloc false
   JRunConfig Ssl false
   JRunConfig Ignoresuffixmap false
   JRunConfig Serverstore "C:/JRun4/lib/wsconfig/1/jrunserver.store"
   JRunConfig Bootstrap 127.0.0.1:51020
   #JRunConfig Errorurl <optionally redirect to this URL on errors>
   #JRunConfig ProxyRetryInterval 600
   #JRunConfig ConnectTimeout 15
   #JRunConfig RecvTimeout 300
   #JRunConfig SendTimeout 15
   AddHandler jrun-handler .jsp .jws .cfm .cfml .cfc .cfr .cfswf
   </IfModule>
   

   This information is what Apache uses to pass off requests to ColdFusion.

7. Copy the following lines:

   JRunConfig Apialloc false
   JRunConfig Serverstore "C:/JRun4/lib/wsconfig/1/jrunserver.store"
   JRunConfig Bootstrap 127.0.0.1:51020
   

8. Paste the above lines inside the <virtualHost> block you created, or chose, in step 6.
9. In the line: JRunConfig Serverstore “C:/JRun4/lib/wsconfig/1/jrunserver.store”, change the path so it matches the path of the directory you created in step 4. Make sure you keep the ‘/jrunserver.store‘ on the end. Don;t worry about the file not being there, it will get added auto-magiaclly.
10. In the line JRunConfig Bootstrap 127.0.0.1:51020, replace the port number (the number after the colon) with the ‘proxy port’ number we noted in step 3.
11. Restart Apache.

The <virtualHost> you created will now use ColdFusion 8 instead of the default server (which in my case was ColdFusion 7).

How do we know its using ColdFusion 8? Easy, just create a test page with <cfdump var=”#server#” />, you’ll see a version number that begins with ‘8’.

You can also use this method for pointing Apache to different instances of the same version of ColdFusion, since, as far as JRun cares, they are all just servers.

I am an Alagad-ian.

As of yesterday, I am the newest member of the Alagad team.Doug asked that I make a brief introduction as one of my first official acts (and then dumped some work on me, hence the delay).

Unlike Jeff Chastain, I am old enough to claim having a Commodore 64.Also, unlike Jeff, I have only been programming for about 7 years.Before cutting my teeth in web development, I spent about 12 years as a paramedic in New Jersey.

I have been programming in ColdFusion since version 5, I also have a bit of PHP experience (I dumped the devils language after discovering CF).I also would like to consider myself fairly adept in database design and programming.I would not yet consider myself to be a guru in terms of OO Programming, but I am getting thereI think.I have become somewhat of a zealot for table-less, CSS based, layouts and accessibility.Lastly, I have recently developed quite the love affair with Flex, and her half-sister Apollo Adobe Integrated Runtime (AIR).

Id like to say I am excited to be joining the Alagad team and look forward to helping to do wonderful things for and with the company.

Today's Light Bulb Moment – Configuration Beans

In the past, I have always utilized an xml file that would contain all of the configuration information for an application things like data sources, paths, etc. Then, in the application.cfm/cfc file, I would read that xml file, parse it into a structure and store that structure in the application scope. Recently however, I came across an application that was originally designed using a series config beans. The application was pretty rough and I was doing a lot of refactoring, so I just inserted my usual xml config file, commented out the beans and moved on without really considering the potential benefits.

Since then, I have seen some discussions about configuration data and done some more reading and I am changing my opinion of configuration beans. As an example, take a basic data access object (DAO). If this DAO communicates with a database of some variety, you will probably need a data source name and possibly a username and password. Now with my config file approach, I would just reference application.config.dsn as a variable in the data access object. The problem with this is that the data source object is now dependent upon the application scope and a variable whose existence and content was not under the control of the object … not a good idea.

Enter the configuration bean. As a very simplistic definition, a bean is simply an object that holds data and should have getters and setters to encapsulate that data properly. So, we could have a data source bean that has three properties a data source name, a user name, and a password. Then, in the init method for our data access object, we setup a configuration argument which accepts this configuration bean and stores it in the instance scope for the data access object. Now instead of referencing application.config.dsn to find the data source name, we simply look at variables.instance.config.getDSN(). We have simplified the inheritance and replaced one dependency with another better one.

The only complex part of this is that we have to declare an instance of the data source config bean, populate it, and then pass it to the data access object. This is where dependency injection and ColdSpring help out. In our ColdSpring beans file we could make an entry for the data source config bean and pass either the path to an xml file that contains the data source settings or we could put the settings direction in the ColdSpring xml to be injected into the data source config bean. Then, we make an entry in the ColdSpring beans file for the data access object and simply provide the data source config bean as a parameter to be injected. Now, when we create a new instance of the data access object, it will already be pre-loaded with the data source configuration information and have no dependency on the application scope or other external variables.

Just as a side note to answer one question that came to my mind we could easily have had ColdSpring directly inject the data source name, username, and password into the data access object. Having that information stored in a bean gives a bit more flexibility in being able to make changes to it programmatically through the application. Is this enough justification for instantiating another object (even if that object is a singleton) maybe, maybe not. It is one of those questions there is not a right or wrong answer to.

This concludes our light bulb, eureka moment for today.