The amazing adventures of Doug Hughes

I’ve read the recent flurry of blog entries about wishlists for ColdFusion 8. (As have many people, given the popularity of the subject.)

Personally, I only have one real wish for ColdFusion 8:

I wish that Adobe would allow me to configure an application without ever having to log into the administration interface.

What does this mean? Well, for example, it annoys me that I need to have access to the administration interface to create any data sources and scheduled processes I might need for an application. This includes caching configuration, mail server configuration, event gateway configuration (that’s the main reason I don’t use event gateways) and so on.

I believe that an application’s configuration should be separate from the server configuration. In particular, it drives me nuts when I have to use absolute paths for configuration settings! Relative paths could save so many headaches!

My reasons for this belief can be summed up as:

An application’s configuration is specific to an application, not to a server.

For example, two different applications rarely share the same database. Obviously these two applications need different DSNs. Why should this information be set at the server level? In my opinion it shouldn’t. The same thing goes for scheduled processes, caching, etc.

To deploy a new I should not need to access an unrelated administrative interface for the server.

This is particularly relevant to shared hosting providers, or any company which restricts access to the administrative tools. This not only creates a barrier that developers must overcome, but it opens the door to errors when deploying applications.

For example, if all of the data sources, scheduled processes, etc, were configured in an XML file, I could easily write an Ant script to deploy the application and make any configuration changes I need for production. I could easily, turn off debugging, turning on trusted caching, changing the mail server to a real server, and so on.

In a nutshell what is currently a manual process could be automated.

I shouldn’t have to remember the configuration settings for each site. Half the time I forget to do something like configure a scheduled process

Because I have to manually remember to make configuration changes as I deploy an application I’m likely to forget a step. If this is something like a scheduled process that runs weekly, it could be quite a while before I realize my application is broken.

I shouldn’t have to share the server’s configuration between applications

This is the last real problem I have with server-based configuration as opposed to application based configuration. What if on one server instance, I want to enabled trusted caching for one application but not for another? Simply put, I can’t. I believe configuration choices like these should be made at an application level.

I propose that…

First off, the administration interface (and its API) remain unchanged. I do think that this should continue to allow developers and administrators to add data sources, and make configuration changes at the server level.

Additionally, I would like to see an XML file or another configuration format which can easily be manipulated programmatically be used to override the server settings for a specific application.

For example, maybe Adobe would create a .cfn file which could contain xml markup. When the application starts up it would look for a .cfn file in the root of the webserver and parse it to find out how that application’s configuration overrides the server’s configuration. For example, it might create a data source named “Foo” pointing to the MSSQL database “Bar”.

It might also define a scheduled process which executes the file at “/foo/bar.cfm” every four hours. Note that this is a relative URL and is therefore independent of the URL the site may be accessed on. This would allow for the exact same configuration settings for this process between two development, staging and production servers. Less moving parts means less room for screw-ups.

All in all, I think that configuration is a part of an application, not a server. A separate configuration file becomes part of the application’s source code would be very valuable. It would make deploying applications easier and it would help reduce accidental errors resulting from configuration mistakes. Lastly, it would allow for automated deployments of applications.

Comments on: "My One Wish for ColdFusion" (17)

  1. Tariq Ahmed said:

    Hmmm yes I second that notion! We’re running multiple IIS sites (using host headers to point to different directories), so hence multiple apps… and the problems you identify above.


  2. Sami Hoda said:

    This is a very powerful request. I would suggest you add a comment to Damon’s blog entry today – to make sure he reads this entry.


  3. Vince Bonfanti said:

    Hi Doug,

    I’d like to point out that all of the problems you mention are currently solved by BlueDragon.NET 6.2.1 (though not by the Java/J2EE editions of BlueDragon).

    As Tariq mentions, every IIS web site is a separate application. With BlueDragon.NET, there’s a separate BlueDragon instance for each application (and therefore or every web site), each with a separate admin console and configuration file.

    The bluedragon.xml configuration file is currently an XML file, which allows you to configure datasources, mappings, scheduled tasks, etc. (everything that can be configured via the admin console can be configured via bluedragon.xml. Also, BlueDragon (all editions, not just .NET) supports relative paths for mappings, custom tag paths, etc.

    So everything you’re asking for can be done right now with BlueDragon.NET. You really should take a look at it.




  4. Sami Hoda said:


    Is this something that could be available for the J2EE edition or will it always be a .NET feature?


  5. Brandon Harper said:

    Ahh yes, I work with .properties files all the time with Java apps but didn’t think about it from this perspective. Nice angle! It looks like we are sharing similar pains:


  6. Vince Bonfanti said:

    Sami, it seems I mispoke earlier. You can actually do the same thing now on the BlueDragon/J2EE edition if you deploy each application as a separate webapp.


  7. Doug Hughes said:

    One thing I forgot to mention in my proposal is that access to the .cfn configuration file should be protected by the server. After all, you don’t want your configuration slashed all over the web.


  8. Ben Forta said:

    If you make each app a seperate instance, as Vince suggested, then ColdFusion does exactly what you want, totally seperate configuration per application.

    But that is not what most users want, they want the concept of applications in CF (there is no such thing now, an application is whatever files are impacted by an Application.cfc or a tag).

    Take a look at this thread from last last year:

    — Ben


  9. Vince Bonfanti said:

    “One thing I forgot to mention in my proposal is that access to the .cfn configuration file should be protected by the server. After all, you don’t want your configuration slashed all over the web.”

    Yep, got that covered, too. For BlueDragon/J2EE the bluedragon.xml file is stored within WEB-INF, which is always protected. For BlueDragon.NET, depending on which installation you choose the bluedragon.xml file is either stored outside the webapp directory (so it can’t be served), or within a protected “bluedragon” directory within your webapp.


  10. Doug Hughes said:

    Ben I’m pretty sure you understood my request, but just to be sure, Ill clarify. There are placed and times for separate instances of CF. That’s not what I want. If I have 50 small scale sites I certainly don’t want 50 instances of ColdFusion running on my server. I want one instance of ColdFusion to become more granular in terms of configuration at the application level.

    I’d rather have 50 configuration files for those 50 sites than 50 instances of ColdFusion. Not only is it not realistic to run 50 instances on one server (which means it’s an expensive option), it still requires that I log on to the server administration interface to manage the instance’s configuration. This is what I want to avoid.

    Under the covers CF manages its configuration via XML. Even if 50 instances of CF were realistic, as far as I know, tinkering with CF’s configuration files is not supported and may void the EULA. Furthermore, the configuration wouldn’t be something that’s as easily considered part of the source code of an application.


  11. Ben Forta said:

    Doug, yes, I did indeed understand what you are asking for. That thread I referred to discusses just that, per application settings. Although the suggestions there are more about programmatic control as opposed to a config file.

    — Ben


  12. Doug Hughes said:

    Ben – I honestly forgot to look at the link. I was one of the commentors in that thread and my opinion seems to have remained the same in the last 10 months.

    That said, it just occured to me that if these settings were programatic I would actually prefer that over xml. It would be familiar to most CF developers, more consitent with the rest of the language and, if I so desired, I could abstract it out into XML.

    Heck, doing that, I could configure everything with ColdSpring, which was one of my unstated concerns about the XML format I proposed.


  13. Mark Stanton said:

    For a project that we are working on we keep all the neo-*.xml files in source control. Part of our deployment process includes uploading a completely blank/vanilla CF instance and then uploading the appropriate neo-*.xml files for the particular server/environment that is being deployed over the top of this blank cf instance.

    My biggest gripe is that these XML files are not really human readable. If they just preserved some white space that would be a huge help for us because most of the changes we make are by hand.

    A more logical / semantic XML structure would also be nice 🙂



  14. Ben Forta said:

    Then we’re in complete agreement. I’d love to see this in Scorpio.

    — Ben


  15. Jochem van Dieten said:

    We do this already with every application we deliver as an EAR or WAR file. The onApplicationStart event configures everything. If it is missing information it shows a wizard where you can fill out all the missing info and that information is saved to a .properties file within the classpath. While it doesn’t solve the lack of isolation between applications, you could quite easily use a similar autoconfiguration for different applications within the same instance.


  16. Nik Molnar said:

    Doug, perhaps Im missing part of the point here, but I know you would be the man to ask. Couldnt most, if not all, of what you are talking about be done with the admin API?

    I envision some sort of Config Framework. You specify a config XML file, it could parse the file, check and set all the DSN/Scheduled Tasks/Gateways/Etc. Of course this would be called during the application start.

    In addition to CF Admin settings, perhaps other vars for the application could be set for the application too. Examples would include admin email, and user/pass for 3rd party services. I would think that the function called would return some sort of object with all the vars, to be scoped and used throughout the app.

    I guess the word framework isnt exactly right in this place. More like specification for how the XML file would be structured.

    Of course I see the value of having something of this nature built into CF, but it seems to me that this could be feasible. What do you think? Could something like this play well with ColdSpring?


  17. Chris Dawes said:

    If you modify the cf admin menu page to create a plugin is that a big no-no from Adobe’s site?

    Why can’t you just download ‘that tool’ and unencypt the admin pages and write your own plugin for the cfadmin that performs this functionality. Just grab the IHTK from intrafoundation and off you go! Create away! Websites, virtual directories, then use the factoryObject to do the rest.


Comments are closed.

Tag Cloud

%d bloggers like this: