RSS feed for InstantSpot site Blog of Dave

ColdFusion 9 bug: Change in behavior with CGI variables

Fri, 12 Mar 2010 20:52:00 GMT

EDIT: As Raymond Camden has pointed out in the comments, this is actually documented behavior, so I would like to state that this obviously isn't a bug in ColdFusion. However the fact remains that two developers (the only 2 out of 12+ that have upgraded to CF9) are seeing different behavior after upgrading to CF9 than the rest of the team. Unfortunately I will be unable to test this further until 3/15 and will update this post then.

Our company has an application that leverages SiteMinder for authentication. One of our developers, Andrew Leaf, noticed that when he installed ColdFusion 9 that he could no longer authenticate to the application. I was using an early beta version of CF9 and had no problems, so I initially dismissed the notion that this could be a ColdFusion 9 issue. After spending some time with Andrew as he walked through the ColdFusion Builder step debugger, we found the suspect block of code. The application code checked to see if a CGI variable has been set using StructKeyExists() and if it does, it sets session information based on that value. Today I set ColdFusion 9 up on new machine and am seeing the exact same behavior. What we are seeing is that with ColdFusion 9, when you test for existence of *any* variables in the CGI scope, it always returns true.

It essentially behaves in such a way that any variable name appears to be defined and paramed with a blank value in the CGI scope. For instance:
<cfdump var="#StructKeyExists(cgi,"someRandomString")" /> outputs YES

Likewise:
<cfdump var="#cgi.someRandomString#" /> outputs [empty string]

Need a "rock star" ColdFusion speaker for 7/30/2010 event in Dallas

Wed, 03 Mar 2010 17:24:55 GMT

Last year was the second annual Dallas TechFest, which is a 1-day multi-platform event centered around programming. They approached me at that time about bringing ColdFusion into the event, and giving us a dedicated track in one of the rooms. I made a optimistic claim that we could bring in 50+ CFML devs from the area, and low and behold, we ended up with 70+ people that registered with the discount code from our user group. It was very successful and had a good buzz with the local community. Additionally, we blew the PHP and Ruby groups out of the water! :)

For 2010, the organizers have offered a travel and expenses budget to to each track (CF being one of those) to pay for travel and expenses to get one "rock star" from each of the technologies. Based on last year's attendees, I would say that a large percentage were beginner-intermediate, with our regular core of advanced guys around as well. The event will be on Friday July 30, in Addison. Unfortunately this falls during the same week as CFUnited, which obviously zaps a number of speakers from the pool of availability, but if you are interested in speaking, please let me know! I am dshuck pretty much everywhere... gmail, twitter, facebook, etc.

UDF: pcase() - Captilize first letter of each word in a string

Thu, 25 Feb 2010 16:34:00 GMT

This is a UDF that I keep on hand for converting strings to "proper case", such as a person's name. For instance, in a database we might have a name stored like DAVID B. SHUCK, but when they log into our site and we welcome them, we don't necessarily want to shout it at them! Saying "Hello David B. Shuck..." would hopefully be a bit less abrasive.

Enter the user-defined function pcase(). Through the use of regular expressions we are doing a search for word patterns and capitalizing the first letter in each word. Enjoy!


<cffunction name="pcase" access="public" output="false"  returntype="string">
    <cfargument name="string"  type="string" required="true" />
    <cfreturn  REReplaceNoCase(LCase(arguments.string),"(^[a-z*]|[ *][a-z*])","\U\1\E","all")  />
</cffunction>

Implicit constructor and CF9 style implicit accessors without ColdFusion 9

Thu, 25 Feb 2010 11:56:00 GMT

One of the broadly welcomed features of ColdFusion 9 has been the addition of implicit getters and setters to CFCs. What this means is that you no longer have to hand code the repetitive boiler plate getXXX() and setXXX() methods for each property in your model objects. However, you don't need ColdFusion 9, (or even ColdFusion for that matter) to enjoy the benefits of the new implicit accessors with the version 9 release. Since ColdFusion 8, developers have had access to the OnMissingMethod() method which makes tasks like this very simple to implement on your own. The OnMissingMethod is also available in current versions of OpenBlueDragon and Railo.

For my implementation of this, I use a standard BaseBean class in a number of my projects which is extended by all of my model class objects. By leveraging the OnMissingMethod() in this BaseBean, I create these implicit accessors, in addition to an implicit constructor init() method as well.

There are multiple examples on the internet that show how you can use OnMissingMethod(), but for the most part, the examples that I have come across do not protect the class from being having infinite previously undefined properties added to it from the outside. For instance, I could have a class named Person.cfc with define properties of "firstName" and "lastName", but nothing would stop someone from doing Person.setThisIsNotAProperty(true) and that value would be dynamically added to the Person instance. While some might argue that the flexibility that this approach offers is a positive thing, I prefer to lock my classes down just a bit more. For instance I like the fact that I can open up a model class and see exactly what properties it can contain with clearly defined <cfproperty/> tags. From a maintainability standpoint the idea of "mystery" dynamic properties strike me as just wrong.

For my implicit constructor, I take an approach where I loop through any named arguments that were passed, and if the name matches a property that I have defined with <cfproperty/>, then it will be passed to a setter method. Any arguments that are passed that are not defined as a property are discarded.

So let's take a look at what this looks like. First I will paste the entire BaseBean, and below we will break it apart to discuss what is going on.

<cfcomponent output="false">       <cffunction name="init" access="public" output="false" returntype="BaseBean">   <cfset var i = "" />   <cfset initializePropertyList() />   <cfloop list="#this.propertyList#" index="i">    <cfif StructKeyExists(arguments,i)>     <cfset set(i,arguments[i]) />    </cfif>   </cfloop>     <cfreturn this />  </cffunction>      <cffunction name="initializePropertyList" access="private" output="false" returntype="void">   <cfset var i = "" />   <cfif NOT StructKeyExists(this,"propertyList")>    <cfset this.propertyList = "" />    <cfif ArrayLen(GetMetadata(this).properties)>     <cfloop from="1" to="#ArrayLen(GetMetadata(this).properties)#" index="i">      <cfset this.propertyList = ListAppend(this.propertyList,GetMetadata(this).properties[i].name)>     </cfloop>    </cfif>   </cfif>     <cfreturn />   </cffunction>      <cffunction name="onMissingMethod" access="public" output="false" returntype="any">   <cfargument name="missingMethodName" type="string" required="true" />   <cfargument name="missingMethodArguments" type="struct" required="true" />      <cfset var property = "" />            <cfif ReFindNoCase("^[gs](et)",arguments.missingMethodName)>    <cfset property = ReReplaceNoCase(arguments.missingMethodName,"^[gs](et)","") />    <cfset initializePropertyList() />     <cfif ListFindNoCase(this.propertyList,property)>     <cfif StructIsEmpty(arguments.missingMethodArguments)>      <cfreturn get(property) />     <cfelse>      <cfset set(property,arguments.missingMethodArguments[1]) />      <cfreturn this />     </cfif>     <cfelse>     <cfthrow message="The class #GetMetadata(this).name# does not have a property named #property# so the implicit #arguments.missingMethodName#() method is not available." />      </cfif>    </cfif>    <cfreturn />   </cffunction>    <cffunction name="get" access="public" output="false" returntype="any">   <cfargument name="property" type="string" required="true" />   <cfset var value = "" />        <cfset value = variables[arguments.property] />       <cfreturn value />   </cffunction>    <cffunction name="set" access="public" output="false" returntype="void">   <cfargument name="property" type="string" required="true" />   <cfargument name="value" type="any" required="true" />      <cfset variables[arguments.property] = arguments.value />      <cfreturn />  </cffunction>   </cfcomponent>

Before we walk through the actual flow, I would like to point out the method initializePropertyList() that you see here:

<cffunction name="initializePropertyList" access="private" output="false" returntype="void">  <cfset var i = "" />  <cfif NOT StructKeyExists(this,"propertyList")>   <cfset this.propertyList = "" />   <cfif ArrayLen(GetMetadata(this).properties)>    <cfloop from="1" to="#ArrayLen(GetMetadata(this).properties)#" index="i">     <cfset this.propertyList = ListAppend(this.propertyList,GetMetadata(this).properties[i].name)>    </cfloop>   </cfif>  </cfif>    <cfreturn />  </cffunction>

By using the GetMetadata() function, we are able to introspect our instance and create a list of property names which we can reference in our other methods. This is what enables us to enforce the rules that I described above in which we make sure that a property exists before setting it in the constructor or through an implicit accessor. You will see in both the init() and OnMissingMethod() methods that we call this method to ensure the list of properties is available before testing against it.

With that established, let's take a look at the init() constructor method:

<cffunction name="init" access="public" output="false" returntype="BaseBean">  <cfset var i = "" />  <cfset initializePropertyList() />  <cfloop list="#this.propertyList#" index="i">   <cfif StructKeyExists(arguments,i)>    <cfset set(i,arguments[i]) />   </cfif>  </cfloop>    <cfreturn this /> </cffunction>

After making sure that our propertyList has been initialized, we loop through that list and if there is a matching named argument, we call the set() method which sets that value into the variables scope.

So with the object initialized, let's take a look at our accessors. For our example, let's say that we have a Person object and we are doing to set our firstName property like this: person.setFirstName("Dave"). Since that setter method doesn't exist in our Person class, the OnMissingMethod() below will be invoked.

<cffunction name="onMissingMethod" access="public" output="false" returntype="any">  <cfargument name="missingMethodName" type="string" required="true" />  <cfargument name="missingMethodArguments" type="struct" required="true" />    <cfset var property = "" />          <cfif ReFindNoCase("^[gs](et)",arguments.missingMethodName)>   <cfset property = ReReplaceNoCase(arguments.missingMethodName,"^[gs](et)","") />   <cfset initializePropertyList() />    <cfif ListFindNoCase(this.propertyList,property)>    <cfif StructIsEmpty(arguments.missingMethodArguments)>     <cfreturn get(property) />    <cfelse>     <cfset set(property,arguments.missingMethodArguments[1]) />     <cfreturn this />    </cfif>    <cfelse>    <cfthrow message="The class #GetMetadata(this).name# does not have a property named #property# so the implicit #arguments.missingMethodName#() method is not available." />     </cfif>   </cfif>   <cfreturn />  </cffunction>

We are then doing a regular expression test to see if the missing method names starts with either "get" or "set". If so, we derive the name of the target property by stripping the "get" or "set" off of the string. After making sure that our propertyList has been defined, we then look in that list to see if the target property actually exists in the instance. If it does, the request is then routed on to either the getter or the setter depending on whether arguments were passed to it. Otherwise an exception will be thrown to let the developer know that he or she has attempted to access an undefined property.

One thing you might notice is that when our conditional block routes the request to the setter, we return an instance of the class itself. This allows us to do method chaining like this: person.setFirstName("Dave").setLastName("Shuck"). it should be noted that this is not the approach that Adobe took with ColdFusion 9.

So let's take a look at it in action. Here is our Person.cfc class.

<cfcomponent output="false" extends="BaseBean">    <cfproperty name="id" type="string" />  <cfproperty name="firstName" type="string" />  <cfproperty name="lastName" type="string" />   </cfcomponent>

As you can see in the <cfcomponent/> tag, we are extending our BaseBean which is all that we need to have a workable domain class object.

When we put this together and access it in our code, we can do this:

<cfset person = CreateObject("component","Person").init(id=7,firstName="Dave", lastName="Shuck") />  <cfdump var="#person#" />

Once we have an instance, we can modify those properties like so:

<cfset person.setId(8).setFirstName("Johnny").setLastName("Rotten") />

I have not actually tested this on Railo, but I can confirm that it works in OpenBlueDragon (including GAE version), and ColdFusion versions 8 and 9.

Link to the HFDP 4 CF Connect recordings

Wed, 10 Feb 2010 03:00:15 GMT

I have been asked more times than I would like to admit to put together a list of the meeting recordings that we have archived for our "Head First Design Patterns for ColdFusion Developers" series that the DFWCFUG has been doing since September of last year. I will be appending to that entry in the next couple of months as we near the end, so you may want to bookmark it for future reference if you are interested in following.

The entire archive can be found here.

Naked Domains in Google App Engine with GoDaddy

Thu, 17 Dec 2009 03:11:47 GMT

I recently set up a new site (hikethecanyon.org) on the Google App Engine running OpenBlueDragon. By default when you set up a new site on GAE (Google App Engine), you choose an ID for your application, which must be unique on their system as it also serves as the hostname of the URL like this: http://[your ID].appspot.com. For those that would like to use a different domain name, Google App Engine has mechanisms for doing so. In the administration panel of your application, you can add a domain and then choose hostnames from that domain that the application should respond to. However, it makes no provisions for serving the "naked domain".

What does this mean? For my example of hikethecanyon.org, I originally set the site up with an id of hikethecanyon-org which was initially served as http://hikethecanyon-org.appspot.com. After adding the domain hikethecanyon.org, I was able to add the host "www" so that it would respond to http://www.hikethecanyon.org. However, since GAE doesn't support naked domains, I was unable to set it up to respond to http://hikethecanyon.org. I was able find a workaround using GoDaddy's domain forwarding functionality. While walking fellow CFML developer Paul Kukiel through the process today, he mentioned that someone should blog this, so here it is with screenshots along the way (edit - it appears that he decided to blog it himself as well!)

For my example, I am going to use a domain I have had sitting around doing nothing for a few years (j4n.org) and walk through the process with some screenshots and explanations along the way.

First, you need to create your application in the GAE dashboard and deploy your application. Many people have covered this topic in our community including Paul Kukiel and Aaron Lynch, so I will skip to the next step and assume that you have a running application on Google App Engine. As you can see below, I have set up an app with an ID of j4n-org that is answering on http://j4n-org.appspot.com which is just running a Mach-II skeleton application.

The next thing that we want to do is add the j4n.org domain to this application. When you go into the GAE dashboard, you will see that option under the "Application Settings" section labeled "Domain Setup"

On this page you will see a note that tells you that the domain you add must be set up for Google Apps, a service that allows all sorts of functionality, including email services and more. NOTE: You do not have to use any of those services, you simply need to sign up!

By clicking the link that says Sign up for Google Apps, you will be taken to a page like this:

Walk through the process filling out your personal information and you will come to a screen that looks like this:

For our example, we are going to choose to create a new CNAME record in DNS to prove to Google that we own the domain. By choosing that option

At this point we need to go to the GoDaddy DNS manager and create a host name google46353a9a2d07a035 and point it to google.com. You can see what that looks like below:

Once that record is in place we can go back to the Google Apps page and click the button labeled I've completed the steps above. If all goes well, you will see a page directing you through additional setup. For our purposes in this example, we are done with Google Apps for the time being. Now we want to go back to the GAE dashboard and tell it that we want to use the j4n.org domain.

When you enter that domain you should see a message that looks like this:

This will bring us back into the Google Apps control panel for the j4n.org domain and we can add hostnames to our application like this:

When you click add you will see an page like the one below instructing you to add another CNAME to GoDaddy for the host "www".

In the screen below you will see that we have successfully added the "www" host and while we were in there I went ahead and deleted the temporary CNAME that we had to create earlier to validate the ownership of the domain.

At this point we can actually reach our application with the address http://www.j4n.org as you see below:

While this is pretty cool and all, we still can't access our application with http://j4n.org. For this, we will count on GoDaddy to do the rest. Go back into the GoDaddy domain manager look for this link:

On the next page, you will want to fill out the field like you see before. However, before you do, click the "learn more" link in the bottom left corner. On that page there is a very important note: For your domain to forward, your domain's A record must be 64.202.189.170. If you note my DNS information above, that is not what the default parked domain IP is. I won't bore you with yet another screen shot, but make sure you alter your domain's A record. Now when we ping j4n.org we get a response from 64.202.189.170.

Once we enter in www.j4n.org you can see that our plan is going to work by hitting the "Preview" link to the right and seeing a snapshot of our app!

You will notice that we accepted the default settings which actually does a 301 redirect from http://j4n.org to http://www.j4n.org. This means that we will never actually see http://j4n.org in the address bar after the page has loaded. If you click on the advanced settings you can select "masking" which allows the url to remain in the address bar as http://j4n.org. Each option has its own advantages. Select what is right for your application and choose OK.

That is all you need to do! Now, a word of warning... we have all gotten spoiled by the seemingly instant DNS changes in recent years. You will find that when you make this forwarding change, you may need to wait up to half an hour or so before you can see the finished product (your mileage may vary).

Relaunched HikeTheCanyon.org on OpenBD and GAE

Tue, 15 Dec 2009 16:44:05 GMT

Around a year or so ago, I inadvertently took hikethecanyon.org offline in a server move. Considering that it is a very low traffic site that is little more than a scrapbook of hiking pictures and descriptions, there is no active user community to send me nasty messages begging for me to bring it back online. Finally this past weekend, I spent a bit of time and revived the code base off an old server, moved all the images out to Amazon S3 and brought the site up running under OpenBlueDragon on the Google App Engine. Other than a very rudimentary Lightbox drop-in I did on the gallery to replace a no-longer functioning Flash image gallery, I didn't actually touch the codebase or the design. So if it looks dated to you, that is because it is!

For those interested in hiking, you may want to give it a look. It documents a hike of the Grand Canyon that I took with my dad in 2005 with a very detailed trip report and over 300 pictures. Enjoy!

HikeTheCanyon.org - Rim-to-Rim through the Grand Canyon on North Kaibab and the Bright Angel Trail

Setting up ColdSpring AOP and interesting behavior with return types

Mon, 07 Dec 2009 15:00:07 GMT

This weekend I had a task in which I needed to add a behavior onto a method in an existing production method in a service object. The new behavior is more or less notifying a 3rd party application whenever a particular method was being called. Considering that it is not really an essential part of the process, it didn't really belong inline as part of that method, nor did I really want to affect existing "sealed" production code. Although I understood that the AOP functionality of ColdSpring was designed for exactly that type of work, I had never actually used it before this task. I put together a little proof-of-concept application that validated what I wanted to do, then applied it to my application.

My goal was to set up an "afterReturningAdvice" object/method - that being a method which will be called at the completion of the target method, which is Member.saveMember() - where I could externalize the new behavior without touching the service itself. While I did get it to perform essentially how I expected, there were a couple of gotchas about this process. One of which makes good sense, the other... not so much.

For starters, my MemberService was defined in ColdSpring like this...
[codeblock 450]

In order to make this change without causing broad sweeping changes throughout the application (in theory!), we are going to create a proxy object that masquerades as the MemberService that will pass requests onto the original MemberService.
[codeblock 451]

As you can see, our MemberService is now actually of type coldspring.aop.framework.ProxyFactoryBean. We have defined its target as a bean named MemberServiceTarget which points to our original MemberService that has been renamed. it now has an "interceptors" property that basically wires in a new bean named RecordUpdatedMemberAfterReturningAdvisor that will serve as an interceptor anytime the "MemberService" is accessed.

So lets take a look at our interceptor definition:
[codeblock 452]

You can see that theRecordUpdatedMemberAfterReturningAdvisor that we declared in our previous snippet is defined here as type coldspring.aop.support.NamedMethodPointcutAdvisor, which is a another built-in type in the ColdSpring framework. We have defined a property "mappedNames" which will list any methods in our target object that we would like this interceptor to act on. In our case we are only wanting to act on the saveMember() method, which you see in the property. The "advice" property tells the interceptor that whenever our saveMember() method is called, that we need to notify our RecordUpdatedMemberAfterReturningAdvice. This is an object at we create that extends the coldspring.aop.AfterReturningAdvice abstract class that is included with the framework. When you use this advice, you must have a concrete implementation of the afterReturning() method, which is were we will actually put our code that notifies the 3rd party application. That method will contain the arguments: returnVal, method, args, and target, which will let you know all about the target method that was just called. Pretty cool huh?

Here is what that RecordUpdatedMemberAfterReturningAdvice looks like:
[codeblock 453]

You can see that our required afterReturning() method is what finally does the work that we were trying to implement. And all of this with no changes to our original application!

Well.... not exactly.

While this is certainly a pretty low impact change to our application, the idea that it would not affect any existing code wasn't the actual reality for a couple of reasons.

MemberService is no longer a MemberService! In about eleventy thousand places in my application, I had services that were wired with a dependency of our MemberService. Each of these had a getter/setter that looked something like this:
[codeblock 454]

With the changes that we have implemented, our MemberService is a completely different animal! Every single one of my getters and setters failed since my MemberService is now actually of type coldspring.aop.framework.ProxyFactoryBean. I altered them all to have type "any" (in case I remove this AOP piece later!) and all works. I suppose it is a worthwhile change, but it would be nicer if this change was truly transparent to my application.
This one is the head scratcher, and as of the time of this blog posting I have no explanation whatsoever.... but a Member isn't always a Member?!? In my MemberService, I have a getMember() method which returns a type my.objects.Member. In my initial testing I had no problems with this at all. However, once I rolled it into production, there was a process that called the MemberService.getMember() method that I had not hit in my initial tests. When it was called I received the following exception:

Message:The value returned from function fnct_
673EC50CBDBD5294E06289EE40D44ABE() is not of type Member
Our proxy MemberService creates a dynamic method that forwards requests onto the original target getMember() method. For whatever reason, in this one case, it was unable to validate that the returned object was indeed a Member. I modified my original MemberService to make the returntype of getMember() "any" an all is now working well. If anyone has an explanation for that one I am all ears!

Aside from those two issues, my new AOP functionality is now in production and working exactly as I had hoped. Overall, I think that this is a very cool feature of ColdSpring, and one that I will definitely be making more use of moving forward.

Talking through some current issues with ColdFusion Event Gateways

Mon, 09 Nov 2009 16:28:07 GMT

Normally on my blog I attempt to throw out some tip, trick, or nugget of some sort. This time? Not so! I am currently trying to find a solution to a problem at hand and am brainstorming the best way to handle a few things. I am really just talking this out for my own benefit, but I would love to hear thoughts from others that have perhaps solved similar issues.

On a project that I am currently engaged in I am leveraging ColdFusion Event Gateways which work as a subscriber to a SonicMQ JMS server. My gateway instance listens for messages on the ESB (Enterprise Service Bus) on a particular destination name (topic/queue). When it receives a message, it parses the XML that it received, and plays traffic cop pushing data into various services that need it. I have this working flawlessly in my small development environment. However, I have a couple of complexities ahead of me that I am having difficulty coming up with a good solution.

Running in the cloud - Our production environment will have any number of CF instances, not clustered, but rather running as isolated applications with a load balancer directing the requests using sticky sessions. Our system will be bringing new instances on/off line as traffic traffic dictates. I have yet to solve the issue of how to set up my JMS Event Gateway in this environment. I definitely don't want 20 different listeners out there all doing the same work. I have considered the idea of having some sort of a support database where a listener can insert a row with a specific JMS message ID and when any other server picks up a message with that ID it will see that it is already being acted upon and it can safely ignore it. There are a couple of negatives that I can see right off the bat. First is that every single subscribed instance will have to pull in the same message and test to see whether or not it should be acted upon. It just seems like a little bit of redundancy that shouldn't be there. Secondly, there is a chance that two servers could pick up the same request within milliseconds of each other and both could end up doing the work. Duplicate processing could not only be wasteful, but could also create some data integrity issues.
Different environments have different settings (dynamic config) - Right now in our development phase, we have a single config file with setting specific to our development JMS server (credentials, domain, URL, Initial Context Factory, etc). However, soon I will need to have this process support a number of different environments: multiple dev environments, multiple integration environments, multiple QA environments, and eventually production. Ideally it would be wonderful if I could find some way to load a specific config into the event gateway at server init time, but as of today I have _NO_ idea how to solve this one. First, there is no real intrinsic indicator at the server level that lets it know what environment is currently running (yet anyway...) and secondly, ColdFusion event gateway architecture isn't conducive in any way to dynamically loading a specific config.

So now I am counting on you CFML community. Help me brain storm on this! Do you have any thoughts/ideas that might help me here?

Strange behavior with ColdFusion ExpandPath() when using Symbolic Links

Wed, 23 Sep 2009 14:11:00 GMT

I was playing around with the Quicksilver framework last night, and for some reason it was unable to find and instantiate my CFCs properly. After digging into the framework a bit and determining where it was breaking, I discovered something strange about the way that ColdFusion interprets ExpandPath() when it exists in a directory that is defined as a symbolic link. I am not sure if the same behavior exists on Macs, but I would imagine it does. If someone could confirm that to be the case, I would be interested.

For starters, I usually have a 'www' directory in my user home directory. This way when I pass my user profile around from distro to distro, my development work is included in my home directory. For ease of configuration I typically have a symbolic link in my OS that points /www/ ---> /home/dshuck/www/. Then when I am creating a new web project called 'davescode', I would put it in /home/dshuck/www/davescode, but my Apache config would usually point to /www/davescode. For the past several years, this approach has worked will for me. That is until last night when experimenting with Quicksilver.

When Quicksilver loads, it creates a list of service CFCs in the the application in such a way that if I had Foo.cfc in a directory 'com' in the root of my davescode site, it would look like /home/dshuck/www/davescode/com/Foo.cfc. When I initted the application, I was getting an error that it couldn't find the CFC home/dshuckcom/Foo.cfc. Essentially what was happening is that it was getting the full path of the CFC and replacing the path to the root of the site with "". In a perfect world the value of the path after the string replace would have looked like com/Foo.cfc. Unfortunately that was not so. Here's why!

I put a test file called path.cfm in the root of my davescode site that considted of the following:

<cfoutput>#ExpandPath("./")#</cfoutput> <br/> <cfoutput>#ExpandPath("/")#</cfoutput>

The result was very surprising!

/home/dshuck/www/davescode/ /www/davescode/

For some reason when you do ExpandPath("/") it looks at the symbolic link path, but when you do ExpandPath("./"), it looks at the true file path. For the life of me, I can't think of why that would be. If anyone has an explanation, I would be all ears!

Solving java.lang.SecurityException: Seed must be between 20 and 64 bytes. Only 8 bytes supplied.

Fri, 08 May 2009 14:24:00 GMT

Recently I have began working with JMS and ColdFusion, in which we are building a system that subscribes to an enterprise JMS server and picks up messages relevant to its needs and acts on them. I had my proof of concept working with the open source Apache ActiveMQ server and was very pleased with the results. However, in our production environment, the powers that be decided to use the very non-free SonicMQ server.

As I tried to convert the event gateway over to the SonicMQ server, it failed on initialization with the following exception:

javax.naming.NamingException [Root exception is java.lang.SecurityException: Seed must be between 20 and 64 bytes. Only 8 bytes supplied.]  at com.sonicsw.jndi.mfcontext.MFConnectionManager.connect(Unknown Source)  at com.sonicsw.jndi.mfcontext.MFConnectionManager.<init>(Unknown Source)  at com.sonicsw.jndi.mfcontext.MFConnectionManager.getManager(Unknown Source)  at com.sonicsw.jndi.mfcontext.MFContext.<init>(Unknown Source)  at com.sonicsw.jndi.mfcontext.MFContextFactory.getInitialContext(Unknown Source)  at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)  at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)  at javax.naming.InitialContext.init(InitialContext.java:223)  at javax.naming.InitialContext.<init>(InitialContext.java:197)  at examples.JMS.JMSConsumer.start(Unknown Source)  at examples.JMS.JMSGateway.startGateway(Unknown Source)  at coldfusion.eventgateway.GenericGateway.start(GenericGateway.java:118)  at coldfusion.eventgateway.EventServiceImpl$GatewayStarter.run(EventServiceImpl.java:1428)

In my research on this problem, I found several people reporting similar errors, each on CF8, and each talking to 3rd party tools. Eventually I found the solution through an email discussion between one of the developers in my company and an Adobe developer. Apparently in CF8, they added FIPS security, which disables the Sun JCE (encryption libraries). To solve this error, you need to add the following line to your java.args in your jvm.config file in JRun.

-Dcoldfusion.disablejsafe=true

Now restart your server and try again!

Making your application flow obvious in Mach-II with event-mappings

Sat, 11 Apr 2009 18:46:00 GMT

I recently joined a company that makes use of Mach-II in a few applications. Some of them were created as the developers were learning the framework and employ some obvious un-best practices. The team is made up of people from various skill levels, but I have noticed that about half of the team just absolutely cringes when they hear "Mach-II". They talk about how difficult it is to troubleshoot and how it is next to impossible to follow application flow. I was very surprised to hear that response, because I think one of the big benefits of using Mach-II is that I can look at a config XML and read the story of my application. I will touch on this in more detail in a bit.

So the other day I had my first experience digging in deeply into one of they apps to solve a problem... and it took me forever to figure out where the hell anything was. I started on the default home event, which only had a filter that announced other events, that had listeners that announced other events and so on until I was *EIGHT* events deep. In each one of these announcements, I had to go find the listener/filter, look into the methods, and search for where I might be going next. It suddenly became overtly clear why the other developers hate Mach-II.

Now, back to why my config files tell a story... first of all, I can't think of many cases where an app needs to announce 8 events before it gets to a destination. However, troubleshooting this would have been so much simpler if only the developer had been clear in the XML using event-mappings. As a rule, if I ever alter the flow of my application from within a filter/listener, I always have an event-mapping that shows this in my config. That way I can quickly skim the XML and know what possible exits I have. In most cases, it should be pretty obvious where you are going based on that alone, and you don't even need to open the CFCs to figure it out. Although I certainly do use event-mapping for aliases, more often than not they will look like this:

<event-mapping event="SomeEvent" mapping="SomeEvent" />

It serves no actual functinal purpose other acting as a means to document the flow. Does anyone else use the practice? How do you keep the application flow obvious in your configuration files?

I was talking to Aaron Lynch about this (who uses the same practice) and from that conversation I decided I would open this up for conversation. What I would love to see is some type of optional setting in Mach-II that would enforce this so that all developer on a team had to use this methodology. Maybe something along the lines where when an event is announced from within a CFC and it hasn't been mapped in the XML it would barf up an exception?

I have no doubt that some people will hate this idea. However, in the bigger picture I would like to see less people hating frameworks, and if we can make things more clear from a troubleshooting/maintanence perspective, I think that there would be less FUD!

Any thoughts on this?

Interfaces in ColdFusion - I think I have finally come around on CFINTERFACE

Fri, 06 Mar 2009 17:03:00 GMT

I will admit it...

When all the pre-ColdFusion 8 debate was swirling about whether or not to add interfaces into CFML, I didn't really get it. It's true. The only OOP I had ever really done was in CFML, ever having experienced how interfaces really come into play, and I think I fell into the the easy path of considering it worthless because I didn't take the time to understand it. So very quietly, I was in the "we don't need it!" camp.

Much has changed for me as a developer since that time. I have gotten quite comfortable in Flex development, and working with Flex made me realize that Java is not really all that difficult to grasp for me now, and I am pretty comfortable getting around there too. I have begun playing a bit with Groovy as well, so I have been exposed to much more since there actually *was* a debate about interfaces.

So now that debate has long since died, and the pro-interface crowd won - and then immediately decided that they didn't actually need interfaces after all - I realized yesterday that I finally get it!

Before I go any further, I would like to give my definition of an interface, because I am sure there are still plenty of CF developers who are where I was just a short time ago with just a very loose grasp, if any, on the concept. In fact, I am not sure that I am much beyond a loose grasp, but I will do my best to explain. For those who already know all this, just bear with me here.

In talking about interfaces with another developer on my team yesterday he asked how they are used. Half joking, I replied "They aren't! They don't *do* anything at all". What I meant by this is that you don't ever actually call an interface and your application never actually asks an interface to do anything. The interface exists simply to enfore rules in your data model. In essence it is a zero-tolerance "Object Gestapo" that makes sure that no one ever gets out of line. An interface is truly little more than a contract that says "Any object that implements me must contain the things I define". In essence, I suppose you could think of it as a shell CFC that defines methods, arguments, and return types, that you can't actually call. If I then define a CFC that implements that interface, it better damn well adhere to it strictly or the object gestapo comes down on you hard!

So why this extra work right? CF is a loosely typed language. Its status as an OOP language has been debated. However, the fact of the matter is that most of the top slice of CFML developers are writing some really amazing object oriented applications. Due to this, some of the more strict products from languages like Java might actually have some place in our work.

Let me give a real world solution that might help solidify my swirling thoughts on the matter. to give background on the environment I am working in, I recently began working for a relatively large insurance provider. Counting another 17 developers that are just being moved into ColdFusion from other languages, we have one of the larger ColdFusion development groups that I am aware of in my area. Many of the developers work remotely, and we have several that are in other states. Due to this, communication must be clear to keep everyone on the same page.

A current project that is in the works is to move our entire policy system off of one third-party vendor to another. The APIs between the two are vastly different, however, we still need the same data available to us in our applications. To make things more complicated, we will be moving one state at a time. So effectively there will be two distinctly different policy systems in play until the last state is converted.

My architectural approach to solving that problem is to use a PolicySystemFactory that returns the appropriate PolicySystem to me based on specific business rules. Any PolicySystem will actually serve as an adapter to the specific API of its third-party system, but the methods that the PolicySystem object exposes to the application *must* be consistent. The application shouldn't really care which system it is talking to as long as the system is giving it the right data and doing taking the right action on data that is passed in.

How do we ensure that we have the exact same API for not only the two current policy systems, but any future policy systems that we don't even know about yet?

Well, we could just make sure all developers know about it, and write it in some document hundreds of pages long that no one ever reads. Then after both of those things fail, the developers will eventually figure it out as the application pukes in different areas as it is getting data in different shapes than it is expecting, or as it tries to use methods differently than the PolicySystem is expecting. Eventually they will work this out.

Or... You could do both of the above items (communicate & document) and save everyone a lot of trouble by establishing that any PolicySystem *must* adhere to rules established in an interface. By taking this approach, there is no question whatsoever that the PolicySystem will not break your application by working differently than expected.

How do you implement this approach? (really.. I didn't mean it as a pun)

First, we would want to figure out exactly how a PolicySystem should be shaped. In our ultra-simplified example, a PolicySystem must have three methods: getPolicy(id) returning a Policy object, getPolicyAgent(Policy) returning and Agent object, and getPoliciesByStatus(StatusId) returning a structure of Policy objects

This is what our Interface would look like:

PolicySystemInterface.cfc

<cfinterface>   <cffunction name="getPolicy" access="public" output="false" returntype="Policy">  <cfargument name="id" type="numeric" required="true" /> </cffunction>   <cffunction name="getPolicyAgent" access="public" output="false" returntype="Agent">  <cfargument name="Policy" type="Policy" required="true" /> </cffunction>   <cffunction name="getPoliciesByStatus" access="public" output="false" returntype="Policy{}">  <cfargument name="StatusId" type="numeric" required="true" /> </cffunction>   </cfinterface>

As you can see above, we use the <cfinterface /> tag to define this CFC as an interface. We then write our functions much like we would in a <cfcomponent /> keeping in mind that whatever we define must be used *exactly* the same way by any object that implements it. So what would one of those objects look like? Here is our old legacy policy system object. Take a look at what is going on in line #1 in the <cfcomponent /> tag.

OldLegacyPolicySystem.cfc

<cfcomponent name="OldLegacyPolicySystem" output="false" extends="AbstractPolicySystem" implements="PolicySystemInterface">  <cffunction name="init" access="public" output="false" returntype="AbstractPolicySystem">  <cfreturn super.init("OldLegacyPolicySystem") /> </cffunction>  <cffunction name="getPolicy" access="public" output="false" returntype="Policy">  <cfargument name="id" type="numeric" required="true" />  <!--- NOTE - In real life, we would use a service to create this bean, not instantiate it here!!! --->  <cfset var Policy = CreateObject("component","Policy").init() />    <!---   ########################################  In this area we would access policy info using the OldLegacyPolicySystem (however it does it!) and populate the Policy bean   ########################################  --->    <cfreturn Policy/> </cffunction>  <cffunction name="getPolicyAgent" access="public" output="false" returntype="Agent">  <cfargument name="Policy" type="Policy" required="true" />  <!--- NOTE - In real life, we would use a service to create this bean, not instantiate it here!!! --->  <cfset var Agent = CreateObject("component","Agent").init(arguments.Policy) />    <!---   ########################################  In this area we would access Agent info using the OldLegacyPolicySystem and populate the Agent bean   ########################################  --->    <cfreturn Policy/> </cffunction>  <cffunction name="getPoliciesByStatus" access="public" output="false" returntype="Policy{}">  <cfargument name="StatusId" type="numeric" required="true" />  <cfset var PolicyStruct = {} />  <!---   ########################################  In this area we would load Policies using the OldLegacyPolicySystem and build a structure of them   ########################################  --->   <cfreturn PolicyStruct /> </cffunction> </cfcomponent>

You should notice that we have:
extends="AbstractPolicySystem" implements="PolicySystemInterface"

Two things are happening there. First, we are extending an AbstractPolicySystem object that will hold common functionality among all PolicySystems. Ours looks like this:

<cfcomponent output="false"> <cffunction name="init" access="public" output="false" returntype="AbstractPolicySystem">  <cfargument name="SystemName" type="string" required="true" />  <cfset this.SystemName = arguments.SystemName />  <cfreturn this /> </cffunction> </cfcomponent>

For our test case, when we instantiate our PolicySystem we can quickly prove which one we are dealing with by looking at PolicySystem.SystemName. That said, your application shouldn't know or care.

By adding the implements attribute we are ensuring that this PolicySystem plays by the rules we defined in our PolicySystemInterface. No "ifs" "ands" or "but"s!

So, this is the exercise that brought me around on CFINTERFACE. What are your thoughts?

Setting up Apache, OpenBD, Railo and ColdFusion - Part 4 - Installing Railo under Tomcat with Apache webserver

Tue, 10 Feb 2009 04:31:00 GMT

This is Part 4 in an ongoing series demonstrating how to install OpenBlueDragon, ColdFusion, and Railo concurrently with all requests passing through the Apache webserver. You will find links to all parts of this series at the bottom under "Related Content"

In this post we will be building upon our existing environment in which we installed Apache webserver, Tomcat 6, OpenBlueDragon, and ColdFusion, by adding Railo to the mix. If you have been following along thus far, we are well past the hard stuff at this point. To install Railo, which is deployed as a java war file, we are going to repeat and slightly modify many of the steps that we took at the end of Part 2 when we installed OpenBD as a Tomcat web application.

Let's start by setting up our hosts entry so that our new site resolves to localhost.railo, and set up the Apache webserver to listen for the request. Open up /etc/hosts, and append 'localhost.railo' (without quotes!) to the line that begins with 127.0.0.1. Next we want to create a new virtual host file for the site under Apache. Do so like this:

$ cd /etc/apache2/sites-available   sudo gedit localhost.railo

Paste the following into that new file and save it.

<VirtualHost *>  ServerName localhost.railo  JKMount /* worker1 </VirtualHost>

As we learned in Part 2, the line "JKMount /* worker1" is instructing apache to pass everything to the worker we defined in /etc/apache2/workers.properties. That worker will then pass the request on to Tomcat port 8009, under which our application actually resides.

Now that we have defined this site, we want to make sure that it gets included on our next Apache restart. We do this by running the following:

$ sudo a2ensite localhost.railo  Site localhost.railo installed; run /etc/init.d/apache2 reload to enable.

At this point, we need to make sure there is a an application set up in Tomcat to receive our request. First, let's start by downloadingthe free Railo Server from their download page. Look toward the bottom of the page and download "Railo Custom" and download railo-3.0.2.001.war. (or newer version if it is there). Once we have the file downloaded, we will create a new directory for our application under Tomcat. We will then copy the Railo war file into it from our download directory. When we have the war file under /opt/tomcat6/webappas/localhost.railo/ we will extract it, and then safely delete the war file itself. These steps can be seen here:

$ sudo /opt/tomcat6/webapps/localhost.railo  sudo cp railo-3.0.2.001.war /opt/tomcat6/webapps/localhost.railo/  cd /opt/tomcat6/webapps/localhost.railo  sudo jar xvf railo-3.0.2.001.war   sudo rm railo-3.0.2.001.war

Since we now have the application in place, it is time to modify the Tomcat server config so that it knows to send the appropriate requests to it. Do the following:

$ sudo gedit /opt/tomcat6/conf/server.xml

Look for the section that we added previously for our OpenBlueDragon localhost site "localhost.bd". We are going to copy that section, modifying the "name" and "docBase" attributes to match our new application and paste it just below the localhost.bd site. When you are done they should look like this:

<Host name="localhost.bd"  appBase="webapps" unpackWARs="true"   autoDeploy="true" xmlValidation="true" xmlNamespaceAware="false">   <Context path="" docBase="localhost.bd/" reloadable="true" privileged="true" antiResourceLocking="false" anitJARLocking="false" /> </Host>  <Host name="localhost.railo"  appBase="webapps"  unpackWARs="true"   autoDeploy="true" xmlValidation="true" xmlNamespaceAware="false">   <Context path="" docBase="localhost.railo/" reloadable="true" privileged="true" antiResourceLocking="false" anitJARLocking="false" /> </Host>

With all that done, we are ready to restart (or start) Apache, Tomcat and our new Railo site will be available at http://localhost.railo

So with our original goal of being able to run the three CFML engines, it's time to see how we did....

Setting up Apache, OpenBD, Railo and ColdFusion - Part 3 - Installing ColdFusion and customizing the connector

Thu, 05 Feb 2009 04:35:00 GMT

This is the third part in a series of posts on setting up ColdFusion, OpenBlueDragon, and Railo all on the same machine using Apache webserver to listen for all requests and direct traffic. Part 2 can be found here. You will find links to all parts of this series at the bottom under "Related Content"

With that said, this part in the series focuses on installing ColdFusion and configuring the webserver adapter in such a way that only specific Virtual Hosts will be set up to pass requests to the ColdFusion server. First we want to start by creating a localhost site that is specific to ColdFusion 8 in Apache. I tend to keep all my sites under /www which is actually symlinked to a 'www' in my home directory. I find a few benefits in this. First, I usually keep my home partition in shape and carry it around with me from distro to distro, so I always have my sites in tact with me. Secondly since it is a symlink to my home and not in a system folder I don't need special permissions to write in it. I will be following along this path, but if you keep your sites elsewhere, then you can adjust as necessary.

$ mkdir /www/localhost.cf8

Now, we will want to create an Apache virtual host definition for this site. To do so, create a new configuration file like this:

$ sudo gedit /etc/apache2/sites-available/localhost.cf8

Paste the the following, then save and close.

<VirtualHost *>  ServerName localhost.cf8   <Directory /www/localhost.cf8/>   Options Indexes FollowSymLinks MultiViews   AllowOverride None   Order allow,deny   allow from all  </Directory>  DocumentRoot /www/localhost.cf8 </VirtualHost>

Now we need to make sure that file is included when Apache starts, so run the following command which will make a symlink to the sites-enabled directory.

$  sudo a2ensite localhost.cf8 Site localhost.cf8 installed; run /etc/init.d/apache2 reload to enable.

As you can see from the localhost.cf8 configuration file, we are expecting our ServerName to be localhost.cf8, so we now need to add that entry to our hosts file.

$ sudo gedit /etc/hosts

Append "localhost.cf8" (with no quotes!) to the line that begins with 127.0.0.1. Save the file and close. At this point you should be able to restart Apache and hit that empty site in your browser like this: Now that we have a site ready, it is time for us to install ColdFusion. Once you have downloaded the .bin installation file from Adobe, browse to that directory in a terminal window. You may need to chmod the file to be executable, then launch it like this:

$ chmod +x coldfusion-801-lin.bin  sudo ./coldfusion-801-lin.bin

Choose 1 for English. After the welcome screen, hit enter to continue. Next type "Y" and hit enter to agree to the terms and conditions. We are now faced with the installation type prompt. For this example of setting up a development environment, we will choose option 3 "Developer Edition" For our purposes we are going to choose the "Server configuration" option. However, it should be noted that you could quite easily choole the J2EE WAR file option and install into Tomcat as we did with OpenBlueDragon in Part 2 of thise series. Since we are installing from scratch, we will choose "No" (2) on the next option which is asking if there is an existing version of ColdFusion 8 installed on this machine. For this installation we do not want any of the extra options to install such as Documentation, LiveCycle, Search Services, nor do we want to start on system init since this is on my laptop and I may not always want ColdFusion to start at boot. So we will uncheck all options like you see in this image and continue. We are going to accept the default installation path of /opt/coldfusion8 Again, since this is a fresh installation, we are going to say "No" (2) to the prompt asking if there are earlier versions of ColdFusion on this computer. Now we start to work our way into the webserver configuration which will tie ColdFusion into Apache. To start, choose "Add Web Server Configuration" (1) when prompted, then choose "Apache" (1). In the following prompt asking for the Apache directory that contains your http.conf file, enter /etc/apache2 as you see in the picture below: For the location of the Apache program binary file, enter /usr/sbin/apache2. For the Start/Stop script, enter /etc/init.d/apache2. You will see both of these choices here: We now return to the first webserver configuration menu and this time choose "Continue with installation" (4). Then we will need to enter the location of the webroot. We are going to enter the directory of our new site /www/localhost.cf8 that we created above as you can see in the picture below. We will also be asked which user we would like ColdFusion to run as. I typically like to use my own user account for this so I don't end up with permissions issues where I have difficulty accessing files generated by ColdFusion Now enter your admin password, and if you choose to user RDS, enter the password for it as well. It will now show you the general options you have selected and you will hit enter to start the actual installation. Once it completes and prompts you to "Press Enter to exit the installer", do so and then start the server with this:

$ sudo /opt/coldfusion8/bin/coldfusion start

During this stage you should see messages that it is configuring the webserver successfully, assuming we entered everything properly above. Once you are returned to a prompt, it is time to go customize the Apache connector stuff just a bit. open the httpd.conf file like this:

$ sudo gedit /etc/apache2/httpd.conf

In that you will find the connector stuff that ColdFusion added starting with a line: #JRun Settings. Before we take the next steps, let me explain a bit what we are going to do. We are going to seperate this into two pieces: the module loader, and the actual connector declaration. As it stands right now, and request coming through the webserver would be handled by ColdFusion and we don't really want that. To make it more granular, we are going to create an include file that can be added to any site that will add the connector only to that particular site. With that said, let's walk through it. *Cut* (not copy!) these two lines of that connector info:

# JRun Settings LoadModule jrun_module /opt/coldfusion8/runtime/lib/wsconfig/1/mod_jrun22.so

Now we are going to paste those into a new file that will go in our mods-available directory. Click on the "New" button in gedit and paste that text in. Now save that file as /etc/apache2/mods-available/cf8.load. Now *cut* (not copy!) the remainder of the connector out that looks like this:

<IfModule mod_jrun22.c>     JRunConfig Verbose false     JRunConfig Apialloc false     JRunConfig Ignoresuffixmap false     JRunConfig Serverstore /opt/coldfusion8/runtime/lib/wsconfig/1/jrunserver.store     JRunConfig Bootstrap 127.0.0.1:51801     #JRunConfig Errorurl url <optionally redirect to this URL on errors>     #JRunConfig ProxyRetryInterval 600 <number of seconds to wait before trying to reconnect to unreachable clustered server>     #JRunConfig ConnectTimeout 15 <number of seconds to wait on a socket connect to a jrun server>     #JRunConfig RecvTimeout 300 <number of seconds to wait on a socket receive to a jrun server>     #JRunConfig SendTimeout 15 <number of seconds to wait on a socket send to a jrun server>     AddHandler jrun-handler .jsp .jws .cfm .cfml .cfc .cfr .cfswf </IfModule>

Create a new file named /etc/apache2/cf8connector. Pasted that text in and save the file. Lastly, you may not have this issue, but I found that the DirectoryIndex attribute of Apache was not adding index.cfm to the list of default files. Due to this I actually added it to my httpd.conf. After all of the steps above, my httpd.conf file only has a single line:

DirectoryIndex index.cfm

Now... it is time to do just a little more Apache config and we are ready to go! Rember that cf8.load mod file we created earlier? Let's turn that on:

$ sudo a2enmod cf8

Now, let's to add an include call to our localhost.cf8 virtual host configuration. Open up /etc/apache2/sites-available/localhost.cf8 and add the "Include c8connector" line that you see below:

<VirtualHost *>         ServerName localhost.cf8          <Directory /www/localhost.cf8/>                 Options Indexes FollowSymLinks MultiViews                 AllowOverride None                 Order allow,deny                 allow from all         </Directory>         DocumentRoot /www/localhost.cf8         Include cf8connector </VirtualHost>

Once you have saved that file, it is time to restart Apache and test out all of our hard work!

$ sudo /etc/init.d/apache2 restart

Now, using your browser, go to http://localhost.cf8/CFIDE/administrator/ and you will see the following: Now... if you are following along from earlier in this series, you should now be able to successfully connect to OpenBD at http://localhost.bd and ColdFusion 8 at http://localhost.cf8 On the next part of this series, we will bring Railo into the mix and finally have all three running on our system.

Next - Part 4 Installing Railo under Tomcat with Apache webserver

Setting up Apache, OpenBD, Railo and ColdFusion - Part 2 - Installing Tomcat/Apache/OpenBD

Sun, 01 Feb 2009 07:34:00 GMT

This is the second part in a series of posts on setting up ColdFusion, OpenBlueDragon, and Railo all on the same machine using Apache webserver to listen for all requests and direct traffic. Part 1 can be found here

Remember, the steps below have some commands specific to Linux, and more specifically to Debian/Ubuntu, but the concepts in general should have at least some similarites across any supported platform, especially you Mac folks.

To start out, we need to make sure that we have the Apache webserver installed with optional "dev" package. Additionally, later on we will need to be compiling, so let's make sure that you have the build-essential package as well $sudo apt-get install apache2 apache2-threaded-dev build-essential Next I installed the Sun Java 6 JDK $sudo apt-get install sun-java6-jdk

Next you want to go download Tomcat. I chose to use Tomcat 6, specifically v. 6.0.18, which the current release as of this posting. Now, using a terminal cd into the directory where you saved the dowloaded file and do the following: $ sudo cp apache-tomcat-6.0.18.tar.gz /opt/ $ cd /opt $ sudo tar xvzf apache-tomcat-6.0.18.tar.gz $ sudo mv apache-tomcat-6.0.18 tomcat6 $ sudo rm apache-tomcat-6.0.18.tar.gz

Next we will need to edit the Tomcat startup script, but to do so, we need to go get a little information first. We need to ensure that we know what the current Java home is on your machine. There are surely easier ways of accomplishing this, but here is the series of steps I took. ~$ which java /usr/bin/java $ ls -l /usr/bin/java lrwxrwxrwx 1 root root 22 2009-01-30 23:00 /usr/bin/java -> /etc/alternatives/java $ ls -l /etc/alternatives/java[return] lrwxrwxrwx 1 root root 36 2009-01-30 23:00 /etc/alternatives/java -> /usr/lib/jvm/java-6-sun/jre/bin/java

From that last line I can see that the default Java lives at /usr/lib/jvm/java-6-sun/ (which too is a sym link, but that's ok!). Now that we have our Java home we can edit the Tomcat startup script $sudo gedit /opt/tomcat6/bin/catalina.sh

Paste the following lines in just after the big comment block at the top. Make sure that if your Java path looked different than mine did, you will want to adjust accordingly. JAVA_HOME=/usr/lib/jvm/java-6-sun JRE_HOME=/usr/lib/jvm/java-6-sun/jre JAVA_OPTS="-server -Xms1024M -Xmx1024M -XX:PermSize=256m -XX:MaxPermSize=256m \ -Duser.language=en -Duser.country=US -Dfile.encoding=UTF-8 \ -Djavax.xml.transform.TransformerFactory=org.apache.xalan.processor.TransformerFactoryImpl"

Now we want to download the Apache Tomcat connector source so that we can pass requests from Apache webserver to Tomcat. This is the one I grabbed: http://apache.org/dist/tomcat/tomcat-connectors/jk/source/ Next you will want to browse to the directory that you downloaded that file into using in the terminal. Next run: $ tar xvzf tomcat-connectors-current-src.tar.gz $ cd tomcat-connectors-1.2.27-src/native $ ./configure --with-apxs=/usr/bin/apxs2 $ make $ sudo make install

Now we will need to create a jk mod file to be included by Apache so that it loads the adapter when Apache starts. In your terminal cd to /etc/apache2/mods-available. In this directory we will create a file named jk.load. $sudo gedit jk.load

In that file pasted the following, then save and exit: LoadModule jk_module /usr/lib/apache2/modules/mod_jk.so # Where to find workers.properties # Update this path to match your conf directory location (put workers.properties next to httpd.conf) JkWorkersFile /etc/apache2/workers.properties # Where to put jk shared memory # Update this path to match your local state directory or logs directory JkShmFile /var/log/apache2/mod_jk.shm # Where to put jk logs # Update this path to match your logs directory location (put mod_jk.log next to access_log) JkLogFile /var/log/apache2/mod_jk.log # Set the jk log level [debug/error/info] JkLogLevel info # Select the timestamp log format JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "

Now we want to create a symbolic link to this file in /etc/apache2/mods-enabled so that it is loaded when Apache starts. $ cd /etc/apache2/mods-enabled $ sudo ln -s ../mods-available/jk.load ./jk.load

Next we want to create a virtual host in Apache to catch the requests. We are going to create a new file in the sites-available directory. $ cd /etc/apache2/sites-available $ sudo gedit localhost.bd In that file, paste the following, save, and exit:

<VirtualHost *>  ServerName localhost.bd  JKMount /* worker1 </VirtualHost>

Now we need to create a symbolic link to that file from sites-enabled so that it is available when apache2 starts. $ cd /etc/apache2/sites-enabled $ sudo ln -s ../sites-available/localhost.bd ./001-localhost.bd

Next we want to make sure that we can get to that site in a browser, so we are going to add 'localhost.bd' to our hosts file. Open up /etc/hosts, and append 'localhost.bd' (without quotes!) to the line that begins with 127.0.0.1. Now we need to define that "worker1" that we just referenced above in the VirtualHost definition. We will do that by creating a workers.properties file in our apache2 directory. $ cd /etc/apache2 $ sudo gedit workers.properties

Insert the following. Then save and exit:

# Define 1 real worker using ajp13  worker.list=worker1  # Set properties for worker1 (ajp13)  worker.worker1.type=ajp13  worker.worker1.host=localhost.bd  worker.worker1.port=8009

Next we want to create a webapp in Tomcat for Apache to send to. sudo gedit /opt/tomcat6/conf/server.xml In that config, we need to define the localhost.bd site, or 'webapp'. Add the following:

<Host name="localhost.bd"  appBase="webapps"       unpackWARs="true" autoDeploy="true"       xmlValidation="true" xmlNamespaceAware="false">   <Context path="" docBase="localhost.bd/" reloadable="true" privileged="true" antiResourceLocking="false" anitJARLocking="false">  </Context> </Host>

Now we need to create the local.bd directory under Tomcat. Note: as you get more comfortable and adventurous, you may want this to be a symbolic link to another place on your machine where your source resides, but for now we are keeping it as simple as we can. Once the directory is created, we will download the OpenBlueDragon war file and extract it.

$ sudo mkdir /opt/tomcat6/webapps/localhost.bd $ cd /opt/tomcat6/webapps/localhost.bd  $ sudo wget http://openbd.viviotech.net/downloader.cfm/id/64/file/openbd.war  $ sudo jar xvf openbd.war

And with that step, and after restarting Apache, and starting Tomcat, OpenBlueDragon will now be available. $ sudo /etc/init.d/apache2 restart $ /opt/tomcat6/bin/catalina.sh start

Open up your browser and go to: http://localhost.bd/bluedragon/administrator

You should be created with your OpenBD admin page like this:

Next: Part 3 - Installing ColdFusion 8 and customizing the JRun connector

Setting up Apache, OpenBD, Railo, and ColdFusion - Part 1

Sun, 01 Feb 2009 07:33:00 GMT

This is Part 1 of a muilt-part blog post demonstrating how run OpenBlueDragon, Railo, and ColdFusion all on the same machine, and all using the Apache webserver with individual Virtual hosts using different CFML engines. But, before we get into it, here is a little background.

For the past several months now I have stepped over to Windows on my laptop after years of not using it regularly. It was actually the first time I had actually used Vista, actually and was quite an interesting experience. First, as much as I love the Linux environment, I really expected to loathe being in Windows daily. I was surprised at how much Vista *didn't* suck. With all the raging passion against it in general I suppose that I had low expectations, but nevertheless I really thought it was pretty decent in general. However it has a more sluggish, constricting feel to it in comparison to Linux, so I have decided I have paid my dues and it is time to go back to using an OS that is truly fun to use, rather than one that just wasn't as crappy as I thought it would be.

After lots of experimentation with various flavors, hands-down Ubuntu is the most painless and most comfortable Linux distros for me personally. My reasoning for that is vast and probably belongs in another blog entry, so I will attempt to keep from straying any further off the topic! That said, last night I decided to try gOS which is a really neat distro built off of Ubuntu. Although the UI is Gnome based, it has more of a Max 10.5.x feel to it. I think Mac folks would feel right at home taking this environment for a spin.

Immediately after the first boot of my shiny new OS I started trying to put my development environment back together. I decided that I wanted to have ColdFusion, Railo, and OpenBD all on from the beginning, with all requests first passing through Apache httpd. Quite some time ago, Aaron Lynch put together some steps to install Smith Project w/Tomcat/Apache, which we have used several times since, primarily setting up Railo. I am not sure I ever would have waded my way through it without his early experimentation and documentation. On this iteration, I loosely followed those instructions, opting for several packages from the repos, and updated versions of software, and have documented my steps as the are somewhat different in areas. For my current environment, I first installed OpenBD. I then followed this by installing ColdFusion and setting it up to user the default JRUN connector that is set up during the installation. Lastly, I installed Railo as another webapp in Tomcat and tied that into Apache as well.

In the following posts, you will see these steps in detail.

Next: Part 2 - Installing Tomcat/Apache/OpenBD

Customizing Illudium CFCGenerator XSL to fit your needs

Wed, 28 Jan 2009 19:18:00 GMT

Aaron and I are about to start work on a super-top-secret project (oops! Man I suck at secrets) in which we will be making use of Amazon ec2 and SimpleDB platforms using an Apache/Tomcat/OpenBD setup. Considering the fact that in spite of the coolness of amazon services in production, it seems to be somewhat of a problematic platform to develop on.

So, until we have a a somewhat functional alpha release, we probably will do all the development that we can on local setups. One of the immediate questions was in regards to how we would set up our CFC data model. We tend to be fans of the Service/Bean/DAO/Gateway approach, but things change a bit when it comes to using Amazon SimpleDB. We came to a decision that our best bet would be to have abstract DAO/Gateway classes that would in turn call the appropriate specific DAO/Gateway classes, so if we are working in development the path would be: Service--> AbstractDAO--> MySQL-DAO and in production it would be Service--> AbstractDAO--> Amazon-DAO. To make the change only need to alter a ColdSpring property "databasetype" from "mysql" to "amazonbd". Notice the "BD" at the end of Amazon? That is because this is not only an Amazon data object, but one that is actually designed for use with OpenBD to make use of the <cfquery dbtype="amazon" /> functionality! Down the line we may add other specific subclasses as well as we need.

One other approach that Aaron and I live and die by in our objects is to steer clear of custom code into our generated CFCs. If you ever make changes to your database or objects in general that require you to re-generate them, it can be a real pain in the ass to make sure that you don't overwrite custom code that you spent precious hours on. Our solution to this is to have all of our Bean/DAO/Gateway/Objects extend base classes so that if you have a UserDAO.cfc there would also be a BaseUserDAO.cfc which would be generated as an empty object. We can then safely stuff all sorts of custom functionality in that base object, such as hasMany relationships/methods, etc, and then later regenerate the DAO itself on a whim, typically without repercussions whatsoever.

With all of this functionality, we now end up with a ton of CFCs in each package, but the flexibility gained is well worth it. Just how many? Well in the example of a User, we would have:

User
BaseUser
UserService
BaseUserService
UserDAOAbstract
BaseUserDAO
UserDAOMySQL
UserDAOAmazonBD
UserGatewayAbstract
BaseUserGateway
UserGatewayMySQL
UserGatewayAmazonBD

For those that have used and know Illudium, you know that the templates it comes with don't fit these patterns! I decided that I would set out to *make* it fit.

Of course I took the first tool I could grab in my toolbox - my sledgehammer - and started hacking into the Flex code trying to figure out what exactly I could change to make this work. After more investigative work than I would like to admit, I realized I didn't need my sledgehammer at all!

Brian Rinaldi has written such a flexible tool that I needed to do no more than create a new set of XSL templates to fit my needs and the rest would all fall in place. If you look in the illudium code under cfcgenerator/xsl, you will find a folder named "projects". For some reason it never hit me previously what populated the "Template:" dropdown in the UI, but this list is generated from directories that lie under "projects". I then took a copy of the default XSL templates and put them in a new directory named "subclassed_data" since that is kind of the general goal of this. By adding new XSL docs, modifying the existing ones, and then making sure all the files I wanted to generate were listed in yac.xml, I easily acheived what I was after. Here is the end product of XSL...

Really the only limitation I came across is that I was never happy with the casing that I ended up with. We typically use camel casing in our objects like UserDaoMysql. Given the way that Illudium works it would come out as UserDaomysql. Considering that fact, I opted for making the end products of my CFCs all lower case. Thankfully with ColdSpring I never actually see the casing of my filenames, so I think I can live with that. To make this happen, I ended up changing the only line of the Illudium codebase so that it would force lowercase to the filenames that it saved.

At this point, the only remaining thing that I may do is alter the Illudium UI. Why? Take a look at this!

Dependent objects made even easier in Mach-II 1.6

Wed, 23 Jul 2008 14:39:00 GMT

In case you were wondering if Mach-II could get any cooler, the answer is *yes*!

For a few versions now, Mach-II has added the ability to inject ColdSpring beans in to your framework components (listeners, plugins, and filters) by use the parameter resolveMachIIDependencies when instantiating the ColdSpring plugin or property.

Take this example... Say that I have a LoginListener.cfc that is dependent on a ColdSpring bean LoginService that lives in our /com directory. I would first define that bean in our ColdSpring config like this: [codeblock 178]

Then, in our LoginListener we would need to create a setter that matched the Bean that we have defined in ColdSpring like so: [codeblock 179]

By taking these two actions, and insuring that your LoginService as an init() method as a constructor, when you initialize your application, variables.LoginService will automatically be available to you as an instance of your LoginService bean. That alone was pretty dang cool.

But wait there's more!

With Mach-II 1.6, this process has become even less cumbersome. In some CFML tags, you can add unexpected attributes without throwing exceptions and are in essence ignored to offer a better solution for managing dependent objects. By default, Mach-II will look for a "depends" attribute in your tags, which can contain a comma separated list of your dependencies. For our simple LoginListener, our tag would look like this: [codeblock 180]

Now, instead of repetitive getters/setters, just by merely having that attribute, our LoginListener will now contain the method getLoginService() which will return an instance of the LoginService. That is just ridiculously easy!

As I said, the attribute actually accepts a comma separated list, so as we add dependencies, our tag might look more like this: [codeblock 181]

If you have made it this far, you have probably deducted that we will now have access to getLoginService(), getUserService(), and getLoggingService().

As I mentioned earlier, Mach-II will look for the attribute "depends" by default, but you can customize it to use other attribute names if you wish. You can find that information and more on the Mach-II wiki.

Related checkbox validation with JQuery

Wed, 16 Jul 2008 14:41:00 GMT

I was given a problem yesterday where I needed to do the following client-side validation. If a user selects a checkbox that they wish to enable credit card transactions, I need to display a panel of specific credit card companies and they need to select at least one before submitting.

If you think about writing the JS to do this without a library it is a somewhat lengthy task. In essence, you would need to do some type of an onsubmit function on your form, check the value of the key checkbox. If it was checked, check the value of each credit card checkbox to see if the user had selected one of the children. After writing this in JQuery, I thought it might be worth demonstrating what an easy task this is.

Let's start with the specific part of my form that has my checkboxes:

<label for="RequireCCInfo">Require Credit Card Information?</label> <input name="RequireCCInfo" id="RequireCCInfo" value="1" type="checkbox"> <div id="CreditCardCompanyPanel">  <div>   <input id="ccAmex" class="ccCheckBox" value="1" type="checkbox">   <label for="ccAmex">American Express</label>  </div>  <div>   <input id="ccVisa" class="ccCheckBox" value="1" type="checkbox">   <label for="ccVisa">Visa</label>  </div>  <div>   <input id="ccDiscover" class="ccCheckBox" value="1" type="checkbox">   <label for="ccDiscover">Discover</label>  </div>  <div>   <input id="ccMc" class="ccCheckBox" value="1" type="checkbox">   <label for="ccMc">Master Card</label>        </div> </div>

There is nothing too notable in all of that other than the fact that you should notice that I have added a class "ccCheckBox" to all of my dependent checkboxes. I will explain more on that in a bit, but I wanted to point out that it is there. You will also notice that I am not doing anything in the way of hiding the "CreditCardCompanyPanel" div. We need to determine at request time whether that will be hidden or not based on whether the "RequireCCInfo" checkbox is checked.

Now, here is the fun part... I am including the JS that I use for this task below:

<script language="javascript">  (document).ready(function(){  $("#RequireCCInfo").change(function(){   toggleCreditCardCompanyPanel();  });    function toggleCreditCardCompanyPanel() {   if ($("#RequireCCInfo").attr("checked") == true)  $("#CreditCardCompanyPanel").show();    else $("#CreditCardCompanyPanel").hide();  }  $("#SaveButton").click(function(){   var pass = false;   if ($("#RequireCCInfo").attr("checked") == true){    $(".ccCheckBox").each(function() {                   if ($(this).attr("checked") == true) pass = true;               });   }   else pass = true;   if (pass) $("#frmMyForm").submit();   else alert('You must select at least on credit card company if "Require Credit Card Information" is checked.');  });   toggleCreditCardCompanyPanel(); }); </script>

First, by using the $(document).ready() function we are telling JQuery to run this JS once the DOM has been completely loaded. Let's look at each section within that ready() block...

The first thing you will see is the $("#RequireCCInfo").change() method. JQuery gives us the concept of binding a listener to an element. For our example, this listener says that anytime that an element with an ID of "RequireCCInfo" is changed, that we will run the code in its function(). You will see that anytime our "RequireCCInfo" checkbox is changed we are going to run a function called toggleCreditCardCompanyPanel(). As you can see we have that method defined immediately after our "RequireCCInfo" checkbox.

In our toggleCreditCardCompanyPanel() method, we are making the decision as to whether or not our "CreditCardCompanyPanel" will be displayed based on whether our user has decided to check the box labeled "Require Credit Card Information?". By using the JQuery selectors we are in essence saying: If a checkbox with an ID of "RequireCCInfo" is checked, display an element with the ID "CreditCardCompanyPanel". Otherwise we will hide this element.

Next comes our validation on form submit... and pretty cool stuff!

Basically I have added a listener which is bound to our submit button with the ID of "SaveButton" which will submit our form "frmMyForm". Anytime that this button is clicked, we will run the code in the function() block. We start this function by setting a value pass=false. We will use this variable to determine whether our form has passed validation. Next we get just a small taste of the magic of JQuery selectors. First, as we did in the toggleCreditCardCompanyPanel() function, we are determining if the element with the ID of "RequireCCInfo" is checked. If so, by using the each() function, we are going to loop through all elements on the page with the class "ccCheckBox" (remember that from above?). In each iteration of the loop we are going to determine if the element has been checked. If so, we are going to set pass=true since we know that our validation has passed.

Lastly, now that we have determined that our form is either going to pass/fail, we take the appropriate action. If pass==fail, we are simply going to alert a message telling the user that if they are going to enable credit cards that they have to choose at least one credit card company. Otherwise, we are going to call the submit() method on our form.

I almost took the time to write out the equivalent of this in POJS (plain old JavaScript) to show how much easier life is with JQuery, but I realized I didn't have the time, patience, or will. JQuery has spoiled me!