views:

252

answers:

5

Google does not really deliver much content (or my query sucks). Has anyone made the switch and can share the experience?

+3  A: 

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/

Jason
sounds good, our senior dev only used straight forward cfml, nothing obscure
mrt181
I would recommend, as Jayson pointed out, that setting up a local developer version of cf8 and testing things could be very helpful.
Jason
+1  A: 

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.

Jayson
There's not much from CFMX6.1 that Railo 3.1 hasn't implemented. Can just grab the Express edition and give it a try.
Peter Boughton
+4  A: 

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!

Ciaran Archer
+2  A: 

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.

Peter Boughton
+3  A: 

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

Gert