I've been using ColdFusion 9 along with the ColdFusion on Wheels Framework for about 6 months now. I still consider myself a beginner, but I am comfortable doing most things I need to.
I recently started writing full CF Script components, and I'm loving the cleanliness of the syntax. I am disappointed to lose some of the simplicity afforded by CFQuery, CFLoop, and so on... but I can live without this for now.
Recently, a few people have mentioned that Railo has better CFScript support. I'm considering switching for that reason.
What things should I keep in mind, and how do the two platforms stack against one another in terms of functionality and ease of use?
Here are the things you need to look for as far as differences between Railo and ColdFusion. This page lists all of the things that Adobe CF has that Railo doesn't, and vice versa:
http://www.getrailo.org/index.cfm/documentation/compatibility/cfml-compatibility/
Mel,
well the easiest way to try it out is to create a mapping called "/" that points to "/" and then compile this mapping from the admin. That should give you a good result on how compatible your code is in terms of compilation.
And a good thing to consider. If you are really happy with CF9, stick with it. You never change a winning team. I am of course proud of Railo and convinced it is the best CFML engine. But I am biased and you should only consider a switch if it is really necessary for different reasons. Costs, performance, memory footprint. But again, if your system runs very well on CF9, just save the money and do something else with it.
Gert Franz
Railo Technologies GmbH
Be careful making decisions based on anecdotes! ColdFusion 9.0.1 brought even more support for cfscript:
Support for the following:
for-in construct (for arrays) in CFScript
var declaration within for loop in CFScript
Function argument metadata
Function equivalents for cfile action="upload" (FileUpload) and cffile action="uploadall" (FileUploadAll)
The following script functions have been implemented as CFCs:
dbinfo
imap
pop
ldap
feed
From:
http://kb2.adobe.com/cps/847/cpsid_84725.html
If you are doing much work with PDF generation (CFdocument) or charting (cfchart), you'll want to try these out in Railo and see how they compare to what you are currently getting with Adobe CF. When I tested charting in Railo I found the Adobe CF engine to produce much nicer looking graphs. I think the PDF engine is better in Adobe CF also.
Related
We are currently using Adobe ColdFusion 9 for a rather large application. We are thinking about moving to Railo or Blue Dragon.
What problems will we run into?
Will it require a large amount of refactoring or will most CFML code just work on the new system?
Do alternative engines provide support for most all official tags, or are they more limited?
In short, how divergent are these alternatives from the official language?
Is there anything we can do to make this process less painful (like upgrading to CF11 first or removing/avoiding certain features)?
My question is similar to What Notable Differences are there between Railo, Open Bluedragon, and Adobe Coldfusion?, but while that is concerned with practical differences I'm asking more specifically about practicality of transition/implementation.
It all depends on your code and the specific Adobe ColdFusion functionality that you are using. For the most part each CFML iteration supports the same tags/functionality. Where they deviate from the Adobe product is usually documented and explained. You need to dive into your code base and look specifically at the features you are using and compare those to the CFML engine of your choosing. Or you can just download and spin-up the alternate CFML engine, drop your code base in it and see what breaks.
As an example from Railo - CFML Compatibility
Railo tries to adhere the CFML standard as good as possible, Still there are some differences like missing tags and functions or a slightly different behavior. This page and the ones below should describe the incompatibilities.
And I have to question what you are basing this comment on? "and especially it's very uncertain future with them". You are running ColdFusion 9. Adobe has implemented two major version releases since then (10 and 11) and are currently working on the future release.
There are two main areas that can prove problematic when migrating from Adobe ColdFusion to Railo:
Use of feature areas that are not supported by Railo
Sloppy CFML code
The former includes integration with Microsoft technologies, such as Exchange and Sharepoint, as well as Office document manipulation; PDF forms and some of the more sophisticated document manipulations; UI "widget" integration. There are third party extensions for some of the Microsoft integrations, e.g., cfSpreadsheet, but for PDF-related stuff you'll need to roll your own using Java libraries (PDF forms and high quality HTML to PDF conversion are Adobe specialties so be prepared to do quite a bit of work in your migration if you rely on these). As for the UI "widgets", you're better off doing that the "right way" so if you rely on those, you should read ColdFusion UI The Right Way.
The latter is a harder issue to nail down. The differences are not well documented - except in experience posts to mailing lists and blogs by people who've made the transition to Railo - but they include things like:
Using scope names as variables (Railo treats scopes as reserved names for performance reasons)
Embedding comments inside tags, e.g., <cfif x gt y <!--- check boundary --->> (I've seen things like this in older CFML code and was surprised it worked).
Reliance on automatic creation of nested struct elements, e.g., a.b.c = 0 when a has not been declared.
Reliance on long-deprecated features, e.g., parameterExists().
There are many other small differences: Railo is generally stricter about syntax and semantics than Adobe ColdFusion, and often those decisions are driven by performance concerns in that compatibility with Adobe ColdFusion would make Railo slower.
Full disclosure here: I have used Railo pretty much exclusively for five years and I used to run the US arm of Railo's consulting business. That said, you need to consider that Railo is a small company (despite the backing of five fairly large former Adobe partners) with just a handful of people working on the engine, and very little awareness of the product outside the more leading edge portion of the CFML community. By comparison, Adobe have a large team and a marketing budget. Your concerns about the difficulty of finding developers will not be addressed by switching to Railo - to gain access to a larger developer pool, you'd really need to switch to a more popular language, not just a different engine.
Finally, a word about Blue Dragon's engine, specifically Open BlueDragon: the maintainers of that project have stated publicly several times that compatibility with the other engines (Adobe, Railo) is not a primary concern for them, and indeed there are a lot of modern language features that they still don't support or at least don't support in a compatible manner. Last I checked, full-script components were on that list despite having been supported in Adobe ColdFusion and Railo for many years (by which I mean using component { ... } rather than the <cfcomponent><cfscript> .. </cfscript></cfcomponent> form). The BlueDragon dialect of CFML has been steadily diverging over the years so unless you have very old school CFML, that would still run on CFMX7 / ACF8, you probably won't have much success trying to migrate to Open BlueDragon.
There are a couple good answers here and I appreciate the advice given in them. When I asked this question I was looking for something a little more specific, so now that I've had the chance to really play around with migrating our app to Railo I thought I should come back and list out the issues we've run into and, just as importantly, the severity and workarounds. Hopefully this will help others considering making the jump:
cfMessageBox:
cfMessageBox is not a supported tag in Railo. The best solution we've come up with is to create a new custom tag called MessageBox.cfm, then drop it into “{railo-install}/lib/railo-server/context/library/tag/”. This will allow it to be recognized as a core tag and referenced via “”, which saves us from updating hundreds of templates that call it. This, of course, requires us to create a message box custom tag from the ground up.
cfDiv:
cfDiv seems to be throwing a JS error when used to bind to a JS function. I'm going to guess that this is because JS binding is not officially supported (given that I can't find any reference in the official docs), and while ACF allows it as delayed execution, Railo simply doesn’t accept it. We could just create a custom tag that generates a JS setTimeout as described in (1) above, which solved our problem, but applications that actually use this tag for its intended purpose may have a more difficult road ahead.
cfWindow:
There appears to be limited support for cfWindow in Railo. Specifically, new windows need manually shown, and the destroy methods do not exist. Various other bugs appeared as well. We decided that it made more sense to just move to JQuery based modals.
cfLayout:
cfLayout support is questionable. It is based on JQuery and not Ext-JS like ACF’s version. This causes a problem because we run JQuery 1.10 right now and the built-in tag doesn’t appear to work beyond JQuery 1.8. In fact, I could not find any JQuery version within which the tag worked perfectly. We decided that it may be best to, again, just write our own custom tag based on JQuery.
cfDocument:
cfDocument works differently in Railo and seems to require more strict HTML. I found a lot of helpful information here, though as of yet I haven't actually gotten any of my cfDocument calls to work as expected.
Relative cfLocations:
cfLocations that began with a “../” and backtracked beyond the webroot would throw a weird Java error. This ended up being a bug in Tomcat, and was patched by the Railo team in version 4.3.1.003. If you download an older Railo version you may run into this issue and need to update all of your cfLocation calls.
Oracle Thin Client:
Our database guy reported to me that he setup the Oracle Thin Client, because the OCI client is not natively supported in Railo. I found this, which might be relevant, but I don't have the expertise to say for sure.
Documentation:
ACF Livedocs are sometimes aggravating as they don't touch on the more important intricacies of how some tags are implemented, but Railo's version is the definition of minimalist. I think it's fair to say that Railo has no docs specifying each tag and function and that they leave you to rely on Adobe for that, which causes a serious issue when you need to know how the two implementations differ.
In the end it seems like, as predicted by previous answers, the UI tags were the bulk of our issues. Based on previous comments I was hoping for better implementations of them that may just require a tweak here and there, but (at least for our needs) the Railo versions seem borderline non-functional and it looks like we would need to replace them completely. For us, this may not be realistic, though we are still tossing the idea around.
To be fair, here are some of the good points from our research and testing:
Performance:
Although compatibility problems have prevented me from doing much performance testing, initial spot checks show approximately a 50% decrease in execution time for most pages.
Debugging:
The debugging options in Railo are quite amazing. There are far more options for formatting, including specifying different formats for different developers (IP addresses). One incredible feature is the inclusion of a comma delimited list of query fields that were actually used in the page: this could allow you to effectively develop based on a "select *" query and simply copy and paste the fieldlist into the query at the end of development, which would save a lot of time with views as large as the ones we're using.
Cost:
This is one of the larger reasons we decided to look into alternatives. Switching just a few Enterprise licensed ACF servers over to Railo would save $20k+ over upgrading to the newest version of ACF. Further, with the performance increases you could see an even greater savings in hardware requirements. A side effect of this point is that one can keep far more up to date without the constant cost/benefit analysis of licensing costs holding up upgrades.
Support:
Without a support contract, it doesn't seem like Adobe responds to user concerns. I've had a production impacting bug reported since ACF 9 which still hasn't been fixed. Yet the Railo community is one of the most helpful and responsive I've ever seen, and developers have even responded directly to concerns and bug reports I've raised.
Longevity:
This is a highly opinionated point, of course, but while Adobe seems to be relegating ACF to the shadows more and more with each new version, Railo appears to be dedicated to growing the community. Combined with its open source nature I think this makes it a safer bet for future support in the long term, even if that support is just us taking development into our own hands when needed.
For a number of reasons, including divergent CFML compatibility, we did not even get to the testing stage with Blue Dragon.
Background:
I have a new site in the design phase and am considering using ColdFusion. The Server is currently set-up with ColdFusion and Python (done for me).
It is my choice on what to use and ColdFusion seems intriguing with the tag concept. Having developed sites in PHP and Python the idea of using a new tool seems fun but I want to make sure it is as easy to use as my other two choices with things like URL beautification and scalability.
Are there any common problems with using ColdFusion in regards to scalability and speed of development?
My other choice is to use Python with WebPy or Django.
ColdFusion 9 with a good framework like Sean Cornfeld's FW/1 has plenty of performance and all the functionality of any modern web server development language. It has some great integration features like exchange server support and excel / pdf support out of the box.
Like all tools it may or may not be the right one for you but the gotchas in terms of scalability will usually be with your code, rarely the platform.
Liberally use memcached or the built in ehache in CF9, be smart about your data access strategy, intelligently chunk returned data and you will be fine performance wise.
My approach with CF lately involves using jQuery extensively for client side logic and using CF for the initial page setup and ajax calls to fill tables. That dramatically cuts down on CF specific code and forces nice logic separation. Plus it cuts the dependency on any one platform (aside from the excellent jQuery library).
To specifically answer your question, if you read the [coldfusion] tags here you will see questions are rarely on speed or scalability, it scales fine. A lot of the questions seem to be on places where CF is a fairly thin layer on another tool like Apache Axis (web services) and ExtJs (cfajax) - neither of which you need to use. You will probably need mod-rewrite or IIS rewrite to hide .cfm
Since you have both ColdFusion and Python available to you already, I would carefully consider exactly what it is you're trying to accomplish.
Do you need a gradual learning curve, newbie-friendly language (easy for someone who knows HTML to learn), great documentation, and lots of features that make normally difficult tasks easy? That sounds like a job for ColdFusion.
That said, once you get the basics of ColdFusion down, it's easy to transition into an Object Oriented approach (as others have noted, there are a plethora of MVC frameworks available: FW/1, ColdBox, Fusebox, Model-Glue, Mach-ii, Lightfront, and the list goes on...), and there are also dependency management (DI/IoC) frameworks (my favorite of which is ColdSpring, modeled after Java's Spring framework), and the ability to do Aspect-Oriented Programming, as well. Lastly, there are also several ORM frameworks (Transfer, Reactor, and DataFaucet, if you're using CF8 or earlier, or add Hibernate to the list in CF9+).
ColdFusion also plays nicely with just about everything else out there. It can load and use .Net assemblies, provides native access to Java classes, and makes creating and/or consuming web services (particularly SOAP, but REST is possible) a piece of cake. (I think it even does com/corba, if you feel like using tech from 1991...)
Unfortunately, I've got no experience with Python, so I can't speak to its strengths. Perhaps a Python developer can shed some light there.
As for url rewrting, (again, as others have noted) that's not really done in the language (though you can fudge it); to get a really nice looking URL you really need either mod_rewrite (which can be done without .htaccess, instead the rules would go into your Apache VHosts config file), or with one of the IIS URL Rewriting products.
The "fudging" I alluded to would be a url like: http://example.com/index.cfm/section/action/?search=foo -- the ".cfm" is in the URL so that the request gets handed from the web server (Apache/IIS) to the Application Server (ColdFusion). To get rid of the ".cfm" in the URL, you really do have to use a URL rewriting tool; there's no way around it.
From two years working with CF, for me the biggest gotchas are:
If you're mainly coding using tags (rather than CFScript) and formatting for readability, be prepared for your output to be filled with whitespace. Unlike other scripting languages, the whitespace between statements are actually sent to the client - so if you're looping over something 100 times and outputting the result, all the linebreaks and tabs in the loop source code will appear 100 times. There are ways around this but it's been a while - I'm sure someone on SO has asked the question before, so a quick search will give you your solution.
Related to the whitespace problem, if you're writing a script to be used with AJAX or Flash and you're trying to send xml; even a single space before the DTD can break some of the more fussy parsing engines (jQuery used to fall over like this - I don't know if it still does and flash was a nightmare). When I first did this I spent hours trying to figure out why what looked like well formed XML was causing my script to die.
The later versions aren't so bad, but I was also working on legacy systems where even quite basic functionality was lacking. Quite often you'll find you need to go hunting for a COM or Java library to do the job for you. Again, though, this is in the earlier versions.
CFAJAX was a heavy, cumbersome beast last time I checked - so don't bother, roll your own.
Other than that, I found CF to be a fun language to work with - it has its idiosyncracies like everything else, but by and large it was mostly headache free and fast to work with.
Hope this helps :)
Cheers
Iain
EDIT: Oh, and for reasons best known to Adobe, if you're running the trial version you'll get a lovely fat HTML comment before all of your output - regardless of whether or not you're actually outputting HTML. And yes, because the comment appears before your DTD, be prepared for some browsers (not looking at any one in particular!) to render it like crap. Again - perhaps they've rethought this in the new version...
EDIT#2: You also mentioned URL Rewriting - where I used to work we did this all the time - no problems. If you're running on Apache, use mod_rewrite, if you're running on IIS buy ISAPI Rewrite 3.
do yourself the favor and check out the CFWheels project. it has the url rewriting support and routes that you're looking for. also as a full stack mvc framework, it comes with it's own orm.
It's been a few years, so my information may be a little out of date, but in my experience:
Pros:
Coldfusion is easy to learn, and quick to get something up and running end-to-end.
Cons:
As with many server-side scripting languages, there is no real separation between persistence logic, business logic, and presentation. All of these are typically interwoven throughout a typical Coldfusion source file. This can mean a lot more work if you want to make changes to the database schema of a mature application, for example.
There are some disciplines that can be followed to make things a little more maintainable; "Fusebox" was one. There may be others.
I am currently working on a program that I really think is a good idea (at least I sure hope it is). For the program I am building I am using (after some very long consideration) ColdFusion - Flex - Adobe Air. However, I have to learn ColdFusion to do this.
I am an independent developer that for the most part uses PHP to build my client's websites. Since I plan on learning ColdFusion to build this program, do you guys have any advice on how I can use ColdFusion elsewhere. It is not very exciting to think that I am learning this language for just one thing.
I don't plan on bulding Coca-Cola's lastest greatest website anytime soon, but I (for some odd reason) enjoy coding and was just wondering if you guys had any advice on any smaller-time avenues that one could persue??
Any advice would be greatly appreciated! :)
Cliff notes: I'm an independent PHP developer learning ColdFusion for a client. Its not exciting to learn a language which I will never use again. Where can I apply ColdFusion in the future?
You can use ColdFusion to build any webapp you could build with PHP. I've seen a few articles lately with comments from PHP developers switching to ColdFusion. This one was posted today, and lists some pros and cons of switching to ColdFusion.
http://blog.rubicon.je/2009/09/coldfusion-half-a-year-away/
I wouldn't consider it an either/or proposition though. If you want to learn CF for your AIR app, it will absolutely come in handy for something else down the road, even if you don't plan for that. Knowing more than one (or three) languages is always beneficial, as it gives you additional insight into other ways to solve problems.
Dan
ColdFusion or CFML the language is a tool, like any other you might add to your toolkit. As developers I personally feel we choose choose the best tool for the job. That said having another tool available will invariably come in handy down the road rather you write another CFML application or not. General solid programming advice is to try and learn at least one new language a year.
CFML is easy to learn, yet also provides for advanced development, which is why many choose to go with it. I came from a PHP/Perl background and picked it up in a couple weeks. If you are comfortable programming once you get the syntax down you can use to it do anything you can do with PHP. I wrote at length on the comparison in this answer.
Further lengthy Question/Answers to the viability/use of ColdFusion:
Is ColdFusion a good choice for web development?
What is the status of ColdFusion today?
I know you didn't ask about comparisons, you have made your decision. For building Flex/AIR apps with a data back-end imho ColdFusion or BlazeDs is the way to go. ColdFusion allows you to hook up the power of java to serve data with the easy of a scripting language. With that starting point you have your foot in the Java platform which is tremendously powerful and extensive. You can invoke interact with the Java layer and harness that power. Many will make the leap to Java or a more "friendly" JVM language like Groovy or JRuby.
do you guys have any advice on how I can use ColdFusion elsewhere.
slidesix is a recent example of an interesting use of ColdFusion. NASDAQ built Flex/AIR market replay application. Also you can check Ben Forta's site for more sites running ColdFusion to get some ideas.
But I think you already hit the nail on the head with Flex/AIR apps if you plan on making more, much of what Adobe does is work to make integration with their technologies as seamless as possible. Honestly that alone has been what has excited me most about using CFML and the recent addition of open source alternatives in Railo/BlazeDs I have been building Flex apps powered by Railo/BlazeDs without paying a dime to Adobe.
I guess the bottom line is that the Java platform (via CFML) and the Flash Platform (via Flex Framework ) are both not going anywhere any time soon, and for that matter neither is PHP so I think you will have a solid set of skill from which to build on either way you go.
ColdFusion is huge in Government, both at the Federal and State level. I moved to the D.C. area in large part because of the number CF jobs available around here.
So, you could always use it for gainful employment.
Update: Some links as requested
Ben Forta's list of sites using ColdFusion, Government category
Who uses ColdFusion - a list of ColdFusion development shops
GotCFM?com - a list of sites using ColdFusion; lots of government sites there (look under "N"; the "Government" category isn't fleshed out)
Adobe.com - abridged list of customers, some with links to case studies
Monster.com search "coldfusion" in Washington, DC
Dice.com search "coldfusion" in Washington, DC
You can get a basic reading of what people are paying for via (shudder) RentACoder: http://www.google.com/search?q=coldfusion+site%3Arentacoder.com
You can use coldfusion everywhere and as much as you like in PHP. There's enough free engines (Railo, Smith, OpenBlueDragon) that you can load into Tomcat instances, or use something like stax to put a coldfusion app into the cloud.
How far you do or don't go is up to you. I find that I write about 1/2 the code in coldfusion that I do in PHP. Maybe it's syntax that I feel less, I don't know.
But build your first project, I think the dots to connect will become apparent on their own
Google does not really deliver much content (or my query sucks). Has anyone made the switch and can share the experience?
We found that when we upgraded to CF 8:
Carraige returns are stripped in plain text emails. We found we had to be explicit about line feed characters by creating a var like so <cfset CRLF = "#Chr(13)##Chr(10)#"> and inserting it in the plain text email where we needed the line feed. We eventually went to HTML emails.
Third party jar files caused problems due to the order in which jar files are loaded. Certain jar files must appear first in the java classpath as defined in cfroot/runtime/bin/jvm.config. This was a messy workaround and we have discontinued using that jar.
Also make sure to patch immediately to 8.0.1. We had a performance nightmare becuase of this issue.
Best of luck!
I haven't had any CFMX 6.1 apps to switch across, but Railo is definitely my CFML engine of choice.
Compatibility-wise, there is very unlikely to be any significant issues migrating from CFMX 6.1, and you can easily test this with the Express version - no installation required!
Railo can be stricter about certain aspects of CFML, so you might get a few errors if you exploit bugs/weaknesses with CF, but nothing really to worry about.
And, if you do get stuck on anything, the Railo mailing list is active with plenty of friendly helpful people who can help to get you going again.
We made the switch about a year ago and if you are talking about only on the code side, then the change from cf6 to cf8 shouldn't require any changes as long as your setup remains the same. One change is the way that CF handles verity collections, so if you make use of cfsearch then it might be something you look into. There are a number of improvements from cf6 that you should look to implement. The few that we have found especially helpful are cfdocument, cfimage, cfpdf, and cffeed. Here is a good link with other key points... http://www.adobe.com/products/coldfusion/upgrade/
If you are upgrading from CFMX 6.1 to Railo 3.1 almost no problems should occur. There are some things that we do not support (like CFREPORT or C++ CFX tags). Besides that it should be very easy to migrate existing CFMX 6.1 code over to Railo. By default Railo is configured to be as compatible as possible with CFMX.
There are some other things you might watch out for:
If you create a struct like this in CF: <cfset a["image.x"]> you will be able to call that variable by using the "." notation, although it's misleading. So in CF you could do <cfoutput>#a.image.x#</cfoutput> whereas in Railo you would have to write: <cfoutput>#a["image.x"]#</cfoutput>
Inside functions creating variables in the local scope that are named like scopes will work in CFMX but not in Railo. So this: <cfset var url = "whatever"> will work in CF but not in Railo.
In Railo you cannot use the application scope or the session scope before it was initialized with cfapplication. Well in CF you couldn't either but there CF will create a local variable in the variables scope called "application" or "session". This sometimes leads to confusion.
Besides these things, it should go flawlessly. If you have of course any problems, just contact our Railo Google group or us directly at www.getrailo.com
Gert Franz
Railo Professional Open Source
I'm not aware of any depreciated tags or functions from CF6.1 to CF8. CF8 has been optimized for performance so you will most likely see an improvement in your application depending on what was used.
I successfully upgraded a large application from CF4.5 to CF8 with no problems. If the application consists of pretty straight forward use of ColdFusion tags and functions, you shouldn't have much problem.
However, since the developer version is free to use, you should really setup a test environment and determine the answer to this question yourself by testing your application. All datasources, custom tags, etc will have to be migrated and tested. If any CF6.1 applications used any of the lower level java api available in some things, you may need to test that thoroughly to make sure the underlying implementation of the coldfusion hasn't changed and fix what's necessary.
As for Railo3.1, there may be some tags or functions not implemented yet. You will again need to setup a test environment and determine this yourself. Somewhere on the Railo site there should be a list of compatibilities between the difference versions of CF and Railo.
Has anyone here had any experience with running OpenBD or Railo in production? We have some legacy CF6.1 apps that need to be hosted somewhere and I'm wondering if OpenBD or Railo is stable enough for production use, won't require a great deal effort to migrate to, etc.
I'll chime in as the 'Adobe' guy and say that yes, both OpenBD and Railo are viable CFML engines. The main hurdles are around CFML compatibility. For the last decade Allaire/Macomedia/Adobe has been driving the CFML standard, but we've formed an open CFML Advisory board made up of various experts in the field to help drive the future of the language.
Today it seems that ColdFusion 7 is the foundational standard. From there the CFML standard seems to splinter between vendors. ColdFusion 8 added a number of exclusive features that haven't been added to the other engines and vice-versa with Railo and OpenBD. In the future, the CFML Advisory should solve this problem.
Using ColdFusion as the standard, I find the following two link to be the best places to understand the compatibility differences.
OpenBD Compatibility
Railo Compatability
Here is the url for the CFML Advisory group. They just started the site so there isn't too much info up there yet.
OpenCFML.org
The CFML compatibility in Railo is a major focus for us. If there are things in Railo that aren't compatible with Adobe CF, then please let us know about them and then we'll try to fix them asap. We are of course trying to get all the requirements of the CFML Advisory Committee implemented in Railo 3.1.x so that we can call ourselves CFML 2009 compatible.
AFAIK an engine should implement the core and the extended core to be called CFML 2009 compatible, but I guess the Advisory Committee hasn't agreed on this. In fact the vendors (like we are) should obey these standards and implement them accordingly.
If of course you experience any problems, just let the Railo Google group know or contact us at www.getrailo.com
Gert Franz
Railo Professional Open Source
Both are on par with CFMX 7 compatability so you shouldn't have any problems migrating a cf6.1 site to either.
Be for warned through that OpenBD DOES NOT support the CFDOCUMENT tag so PDF generation is going to be a problem. Railo on the other hand does.
Railo has an express version, which doesn't require an install and makes it real easy to see if an existing application works with it or not.
OpenBD also has a download and ready to run version, though I haven't tried it out, it should be as easy to setup as the Railo Express version.
It seems that there is project started for OpenBD to integrate the Flying Saucer project as a replacement for CFDOCUMENT support. More can be found here about this.
Absolutely! Both are enterprise class solutions and shouldn't pose too many problems. As rip747 mentions there are copies you can download to quickly test your applications compatibility.
As for performance it's generally believed that Railo is the fastest of the three engines while BlueDragon is the slowest. Although it's not currently in production I'm developing an application against Railo 3.0 and intend to deploy to Railo 3.1 once it's released.
Support for cfdocument will be included in the next "major" versioned release of OpenBD.
Just to give folks a bit of background on cfdocument support in OpenBD, a commercial library was used for cfdocument in New Atlanta BlueDragon, so that had to be removed when OpenBD went open source. The "hooks" are still in the OpenBD engine, however, so it's really just a matter of implementing the underlying functionality using an open source document engine, of which there are many.
I think replacedirect.nl recently migrated their webshop to railo.
Railo virtually has no documentation. It does not seem to be a priority for the core team, they have not managed the Railo open source project well. It is a case of lost momentum due to incompetency.
Railo is quite difficult to deploy on account of very weak documentation and consequently cannot be taken seriously. Furthermore the tag and function tags are empty when you scroll down to usage examples. This open source project and the team running it are a joke, completely out of touch with the recurrinfg complaints of install/config difficulties over the past 2 years.
Stick with Adobe Coldfusion which has good documentation or switch to another language.
Rob, mind if I try to solve your problem by providing a different solution than your question asks?
In that you mention an interest in hosting, just keep in mind that if you mean shared hosting, then you don't need to worry about the cost of the CFML engine. That will be born by the hosting provider, and amortized over the folks on the server. As such, you will find many low- (and even no-) cost CF hosting providers running on Adobe CF (and you'll find a range of them running different versions to suit one's taste, from CF 6, 7, 8, or 9, as I write today.)
There are various lists of CF hosting providers. I offer one (and also provide pointers to still other lists) at a category of my CF411 site: http://www.cf411.com/#cfhost