我们目前正在将Adobe ColdFusion 9用于相当大的应用程序。我们正考虑搬到Railo或Blue Dragon。
我们会遇到什么问题？
我的问题类似于What Notable Differences are there between Railo, Open Bluedragon, and Adobe Coldfusion?，但是虽然这与实际差异有关，但我更具体地询问过渡/实施的实用性。
答案 0 :(得分：6)
这完全取决于您的代码和您正在使用的特定Adobe ColdFusion功能。在大多数情况下，每个CFML迭代都支持相同的标签/功能。他们偏离Adobe产品的地方通常会被记录和解释。您需要深入了解代码库并专门查看正在使用的功能，并将其与您选择的CFML引擎进行比较。或者您可以下载并启动备用CFML引擎，将代码库放入其中，看看有什么中断。
作为Railo的一个例子 - CFML Compatibility
Railo试图尽可能地遵守CFML标准，但仍存在一些差异，例如缺少标签和功能或行为略有不同。此页面和下面的页面应描述不兼容性。
我必须质疑你的评论基础是什么？ “尤其是与他们的未来非常不确定”。您正在运行ColdFusion 9.自那时起，Adobe已经实施了两个主要版本（10和11），目前正在开发未来版本。
答案 1 :(得分：3)
从Adobe ColdFusion迁移到Railo时，有两个主要方面可能会出现问题：
前者包括与Microsoft技术的集成，例如Exchange和Sharepoint，以及Office文档操作; PDF表格和一些更复杂的文件操作; UI“小部件”集成。某些Microsoft集成有第三方扩展，例如cfSpreadsheet，但对于PDF相关的东西，您需要使用Java库自行推出（PDF格式和高质量的HTML到PDF转换是Adobe专业所以，如果依赖这些，请准备好在迁移中做很多工作。对于UI“小部件”，你最好以“正确的方式”做到这一点，所以如果你依赖这些，你应该read ColdFusion UI The Right Way。
后者是一个难以解决的问题。这些差异没有得到很好的记录 - 除了邮件列表的经验帖子和已经过渡到Railo的人的博客 - 但它们包括以下内容：
<cfif x gt y <!--- check boundary --->>（我在较旧的CFML代码中看到了类似的内容，并对其有效感到惊讶。）a.b.c = 0未声明a时。parameterExists()。还有许多其他小的差异：Railo在语法和语义方面通常比Adobe ColdFusion更严格，而且这些决策通常都是由性能问题驱动的，因为与Adobe ColdFusion的兼容性会使Railo变慢。
此处充分披露：我已经将Railo专门用了五年而且我曾经在Railo的咨询业务中经营美国分公司。也就是说，你需要考虑到Railo是一家小公司（尽管得到了五个相当大的前Adobe合作伙伴的支持），只有少数人在使用该引擎，并且很少有人知道该产品在更前沿的部分之外CFML社区。相比之下，Adobe拥有庞大的团队和营销预算。切换到Railo无法解决您对寻找开发人员困难的担忧 - 要获得对更大的开发人员池的访问权限，您真的需要切换到更流行的语言，而不仅仅是不同的引擎。
最后，关于Blue Dragon的引擎，特别是Open BlueDragon：该项目的维护者已多次公开表示与其他引擎（Adobe，Railo）的兼容性不是他们主要关注的问题，事实上有一个很多现代语言功能，他们仍然不支持或至少不支持兼容的方式。最后我查了一下，尽管Adobe ColdFusion和Railo多年来一直支持，但是全部脚本组件都在该列表中（我的意思是使用component { ... }而不是<cfcomponent><cfscript> .. </cfscript></cfcomponent>形式）。这些年来，CFML的BlueDragon方言一直在稳步发展，所以除非你有非常老的学校CFML，那仍然可以在CFMX7 / ACF8上运行，你可能不会在尝试迁移到Open BlueDragon方面取得多大成功。
答案 2 :(得分：3)
这里有几个很好的答案，我很欣赏他们给出的建议。当我问这个问题时，我正在寻找一些更具体的东西，所以现在我已经有机会真正将我们的应用程序迁移到Railo，我想我应该回来列出我们的问题＆＃39我们遇到了严重性和变通方法，同样重要的是。希望这会有助于其他人考虑跳跃：
<强> cfMessageBox： cfMessageBox不是Railo中支持的标记。我们提出的最佳解决方案是创建一个名为MessageBox.cfm的新自定义标记，然后将其放入“{railo-install} / lib / railo-server / context / library / tag /”。这将允许它被识别为核心标记并通过“”引用，这使我们无法更新数百个调用它的模板。当然，这需要我们从头开始创建一个消息框自定义标记。
<强> CFDIV： cfdiv在用于绑定JS函数时似乎抛出了JS错误。我猜这是因为JS绑定没有得到官方支持（鉴于我无法在官方文档中找到任何引用），而ACF允许它作为延迟执行，而Railo根本就没有接受。我们可以创建一个自定义标记来生成JS setTimeout，如上面（1）中所述，它解决了我们的问题，但实际上将这个标记用于其预期目的的应用程序可能会面临更加困难的道路。
<强> cfWindow： 在Railo中对cfWindow的支持似乎有限。具体来说，需要手动显示新窗口，并且不存在destroy方法。还出现了各种其他错误。我们认为转移到基于JQuery的模态更有意义。
<强> cfLayout： cfLayout支持值得怀疑。它基于JQuery，而不是像ACF版本那样的Ext-JS。这会导致问题，因为我们现在运行JQuery 1.10并且内置标记似乎不能超越JQuery 1.8。事实上，我找不到任何标签工作完美的JQuery版本。我们决定再次编写基于JQuery的自定义标记可能是最好的。
<强> cfDocument： cfDocument在Railo中的工作方式不同，似乎需要更严格的HTML。我找到了很多有用的信息here，但到目前为止我还没有实际上让我的cfDocument调用按预期工作。
相对cfLocations： 以“../”开头并在webroot之外回溯的cfLocations会引发一个奇怪的Java错误。这最终成为Tomcat中的一个错误，并且由版本4.3.1.003中的Railo团队修补。如果您下载较旧的Railo版本，则可能会遇到此问题并需要更新所有cfLocation调用。
Oracle瘦客户端 我们的数据库人员向我报告他设置了Oracle瘦客户端，因为在Railo中本身不支持OCI客户端。我找到了this，这可能是相关的，但我没有专业知识可以说肯定。
<强>文档： ACF Livedocs有时会加剧，因为他们没有触及更复杂的标签实现方式，但Railo的版本是极简主义的定义。我认为可以公平地说，Railo没有指定每个标签和功能的文档，并且它们让你依赖Adobe来做这件事，当你需要知道这两个实现有何不同时，这会导致严重的问题。
最后看起来，正如之前的答案预测的那样，UI标签是我们的大部分问题。基于之前的评论，我希望能够更好地实现它们，这可能只需要在这里和那里进行调整，但（至少对于我们的需求），Railo版本似乎是边缘无功能的，看起来我们需要完全替换它们。对我们来说，这可能不太现实，尽管我们仍在抛弃这个想法。
公平地说，以下是我们研究和测试的一些优点：
<强>性能： 虽然兼容性问题阻止我进行大量的性能测试，但初始抽样检查显示大多数页面的执行时间减少了大约50％。
<强>调试： Railo中的调试选项非常棒。格式化的选项还有很多，包括为不同的开发人员（IP地址）指定不同的格式。一个令人难以置信的功能是包含一个以逗号分隔的查询字段列表，这些列表实际在页面中使用：这可以让您基于＆＃34; select *＆＃34;在开发结束时查询并简单地将字段列表复制并粘贴到查询中，这将节省大量时间与我们正在使用的视图一样大。
<强>费用： 这是我们决定研究替代方案的一个较大原因。只需将少数企业许可的ACF服务器切换到Railo，即可在升级到最新版本的ACF时节省2万美元以上。此外，随着性能的提高，您可以看到更大的硬件需求节省。这一点的另一个副作用是，如果没有持续升级的许可成本的成本/收益分析，就可以保持更新更新。
<强>支持： 如果没有支持合同，Adobe似乎不会回应用户关注的问题。自ACF 9以来，我已经报告了一个影响生产的错误，但仍然没有修复。然而，Railo社区是我见过的最有帮助和最敏感的社区之一，开发人员甚至直接回应了我提出的问题和错误报告。
<强>长寿： 当然，这是一个高度自以为是的观点，但是随着每个新版本Adobe越来越多地将ACF降级为阴影，Railo似乎致力于发展社区。结合其开源性质，我认为这使得它成为未来长期支持的更安全的选择，即使这种支持只是我们在需要时将开发掌握在自己手中。
由于多种原因，包括不同的CFML兼容性，我们甚至没有进入Blue Dragon的测试阶段。