ColdFusion 10 update 1 released
Adobe ColdFusion 10 | Announcements | ColdFusion
We have released the first update for ColdFusion 10 today. It fixes quite a number of important/critical issues in ColdFusion 10. This update can be downloaded and installed using the update installer mechanism in the administrator that we introduced in ColdFusion 10.
Some of the important bugs fixed in this update are
- Missing CGI.Redirect_* variables (CGI.Redirect_URL)
- The value of CGI.path_info is an empty string when URL rewrite condition uses {PATH_INFO} in IIS.
- ORM 2nd level cache does not function when application is restarted after timeout.
- ExpandPath for custom tags is very slow
- Can't create recurring scheduled tasks in the Standard Edition.
For more details on this release, please refer to this technote.
31 comments so far ↓
http://www.krishnap.com/2012/09/coldfusion-10-hotfix-1update-1-is.html
The hotfix may not be available for download at this moment for those of us with servers that block the Internet, but you can either download the hotfix .JAR file and run it from a command line or set up an update proxy. For the manual update, see the Adobe Help page for updating the server at:
http://help.adobe.com/en_US/ColdFusion/10.0/Admin/WSe61e35da8d318518-33adffe0134c60cd31c-7ffe.html
Hope this helps other ColdFusion administrators that are in the same situation as myself.
But I (and others) have noticed that in CF10, it never asks you where to put it (even if you tell it to use an external web server, during installation). It always puts it in the [cf]\cfusion\wwwroot, and it sets the CFIDE admin mapping to point to that. (And it then adds a CFIDE virtual directory in the external web server to point to that.)
I actually appreciated why Adobe did that, so that the updater would in fact only have to update one place, and all sites would see that.
So this is interesting, what you have experienced. As you (and other readers) may have noticed, the CFIDE mapping in the CF Admin is unique in that you can't update it on that Admin page.
I do have a guess at what may have happened: did you perhaps import a CAR file from another CF admin? That's one way that the CFIDE admin mapping could be overwritten.
As you say, it could be helpful if Adobe detected this, as it doesn't seem that unusual (though perhaps Adobe may d say, no, the CFIDE admin mapping is not changed via a CAR import. That would then beg the question of how your CF10 CFIDE mapping was changed to something else.)
Of course, one might propose that another way to address this (for those with this challenge) is to change your external web server web sites to use a virtual directory to point to the [cf10]\cfusion\]wwwroot. But that still leaves the challenge that the CFIDE admin mapping can't be changed (by hand). This seems indeed an interesting problem calling for a solution (or more discussion).
In my CF admin it shows my /CFIDE mapping as the correct path to my CFIDE folder and not the default mapping that the HF installer copied the files to (Coldfusion10/cfusion/wwwroot/cfide). I also have a virtual directory to the cfide scripts folder for the Default CFForm ScriptSrc Directory setting. To be honest, I cannot remember what I did during setup to get the /CFIDE mapping to a non-default location as like you said with CF10 it does not ask you where you would like to install it. I actually just found this in the CF10 install directions: "•wwwroot: Default web root directory for the built-in web server. When running on other web servers, this directory contains the CFIDE and WEB-INF directories; do not remove this directory." But I changed it before I read that so opps. Has anyone else moved the default CFIDE folder? Does the CF connector tool change that setting based on virtual directories setup?
I think the title and URL of this blog post is causing confusion about versioning.
ColdFusion 8 Update 1 was "8.0.1". ColdFusion 9 Update 1 was "9.0.1". So ColdFusion 10 Update 1 should be "10.0.1", right?
So why does the CF Admin and SERVER.coldfusion.productversion still say "10,0,0"?
Repro:
1) Look up in address bar of this blog post
2) See "coldfusion-10-update-1-10-0-1-released" (note the "10-0-1")
3) go to: http://www.adobe.com/support/coldfusion/downloads_updates.html
4) scroll down and see: "ColdFusion 9 Update 1 (9.0.1)"
5) go to: http://helpx.adobe.com/coldfusion/kb/faq-coldfusion-8-update-8.html
6) see: "ColdFusion 8 Update 1" and "(8.0.1)"
7) go to: http://en.wikipedia.org/wiki/Adobe_ColdFusion
8) scroll down and see: "Adobe ColdFusion 8.0.1" and "Adobe ColdFusion 9.0.1"
I also was surprised to see a "ColdFusion 10 Update 1" so soon after CF10 itself.
Related ticket #3323518: https://bugbase.adobe.com/index.cfm?event=bug&id=3323518
Thanks,
-Aaron
Variable CTASK is undefined.
I just purchased CF 10 and installed it to coexist with cf 9.0.1. I noted that my scheduled tasks and webservices did not migrate.
When I could not create a simple scheduled task I found this post and ran server update from CF Admin.
Server Product ColdFusion
Version ColdFusion 10,282462
Update Level 02
Tomcat Version 7.0.23.0
Edition Standard
Operating System Windows Server 2008 R2
OS Version 6.1
Update Level /D:/cfusion/lib/updates/chf10000002.jar
Adobe Driver Version 4.1 (Build 0001)
Repro:
1) In CF9.0.1, login to CF Admin and click 'i' (System Information page)
2) See: 9,0,1,274733 (formatted as list w/ length of 4)
3) In CF10.0.1, login to CF Admin and click 'i' (System Information page)
4) See: ColdFusion 10,282462 (formatted as list w/ length of 2)
Issue: CF 10's "System Information" page should format the version number as a list having a length of 4. (Admin API and SERVER-scope return version number correctly formatted w/ list length of 4)
Thanks,
-Aaron
With ColdFusion 10, we have a single way to update the server. It is capable of applying all types of update to your server - individual, cumulative, security or anything else. Since the delivery mechanism is same for all kind of updates, instead of changing the version number, we have introduced the concept of 'Update Level' which tells you which update the server is on. Product version is considered as the base version, based on which we decide whether an update is applicable to it or not. I am curious to know why the update level does not serve the purpose. Is there any specific information that you think update level does not provide that the product version does?
We are aware that Update level is missing from the 'Server' scope and we will fix that in the next update that goes.
The confusion (for me at least) begins with the URL and title of this blog entry:
URL: blogs.coldfusion.com/post.cfm/coldfusion-10-update-1-10-0-1-released
Title: ColdFusion 10 update 1 released
Users familiar with "ColdFusion 8 Update 1 (8.0.1)" and "ColdFusion 9 Update 1 (9.0.1)" will interpret the above URL as meaning "ColdFusion 10 Update 1 (10.0.1)". Users won't immediately understand that CF10 changed the meaning of X in "Update X". Prior to CF10, X referred to a new version (which had a Prerelease/beta and added new features). In CF10, X merely refers to a patch level containing bug fixes.
See? Let's pretend there is a future 10.0.1. Would it be called "ColdFusion 10 Update 1" (as per the naming of 8.0.1 and 9.0.1)? Well, that would be confusing if "ColdFusion 10 Update 1" had dual meaning and meant both "ColdFusion 10.0.0 Update Level 1" AND "ColdFusion 10.0.1". So ColdFusion 10.0.1 would have to have a new name.. but what would that name be? I don't know..
Perhaps the title of this blog entry should've been called "ColdFusion 10 Update Level 1 Released". Then it would be clear that this blog entry is about an update level (patch level) and not a new version.
WELL, that would just create another issue: What would 10.0.1's 1st update be called? "ColdFusion 10 Update 1 Update Level 1"?
That just sounds odd. I guess another way to resolve this issue would be to say:
1) Update Levels will never introduce new functionality or have Prereleases/betas
2) There will never be point releases anymore (meaning, there will never be a 10.0.1)
I don't know how to resolve this issue but the confusion most definitely remains.
As for server scope returning the Update Level, yes that will indeed be helpful. Thanks for that, btw.
Thanks,
-Aaron
P.S. In any case, the "10-0-1" should probably be removed from the URL of this blog entry since this is not 10.0.1
Please note the following wording, under "Uninstall ColdFusion 10 Update 1":
----
Run the uninstaller for the update from the command prompt. For example, java -jar {cf_install_home}/{instance_home}/hf_update/hf-10-00001/uninstall/uninstaller.jar
----
The "hf_update" should be plural "hf_updates".
Thanks,
-Aaron
Though in my case the upgrade from cf9 to 10 didn't go well. I ended up having a few items listed in my config when I finally got it all working. Including ALL. In testing I just added a new site specific item to a test site. I was hesitant to remove all items and re-add them or just all, for fear of nuking my system again. Can someone confirm if I need to do this, or shouldn't have to?
Honestly this should have been documented and or automated as part of the patch I would think.
C:\ColdFusion10\config\wsconfig
and
C:\ColdFusion10\cfusion\wwwroot\CFIDE
Regarding the troublesome CF9-to-CF10 migration:
Was this on IIS7+? If so, please note that CF9.0.1 and CF10 configure IIS7+ differently. This was done for good reason, but can _sometimes_ require an extra manual step if any of the 9.0.1 config info wasn't completely removed from IIS7+. After uninstalling 9.0.1, and before installing CF10, I recommend checking each site's root for a web.config file. Open the web.config file and ensure it does not contain any CF-related settings:
- Default document
- Handlers access policy and the handler mappings
- ISAPI filter
If the site's web.config contains no CF-related settings at all, then that web.config file can simply be deleted.
Updater 1's wsconfig.exe correctly does not configure IIS7+'s applicationHost.config any differently than the wsconfig.exe that shipped w/ the final release of CF10. Therefore, your site configurations should safely remain unaltered after performing the recommended process of running Update 1's wsconfig.exe to unconfigure/reconfigure IIS7+.
Thankfully, CF10 now writes all IIS7+ settings to a single file (Windows\System32\inetsrv\config\applicationHost.config) which results in faster unconfig/reconfig of IIS7+ and should allow future versions of CF to run side-by-side in IIS7+ (something not easily achieved w/ the combination of CF9.0.1 and CF10).
Regarding the PATH_INFO fix:
Updater 1 does not restore the pre-CF10 behavior of copying SCRIPT_NAME into PATH_INFO.
Example: protocol://ip:port/script/name.cfm/extra/path/info?query=string
In this example, CGI.PATH_INFO should never contain "/script/name.cfm". That was a pre-CF10 bug. Updater 1's PATH_INFO fix is specifically for the issue where PATH_INFO was empty when {PATH_INFO} was used in an IIS URL Rewrite Rule.
Regarding Updater 1 automating the wsconfig.exe unconfig/reconfig process:
Some admins customize the ColdFusion10\config\wsconfig\1\uriworkermap.properties file to enable case-insensitive URLs (ex: .CFM, /REST/, etc) and to enable custom SES URL's w/o needing to create rewrite rules in the web server. The Updaters would need to also create a backup of the C:\ColdFusion10\config\wsconfig directory, in order to prevent those uriworkermap.properties customizations from being lost.
Adobe, can the Updaters please create a backup of the C:\ColdFusion10\config\wsconfig directory and then automate the wsconfig.exe unconfig/reconfig process as suggested by Josh?
Should I log an ER?
Regarding wsconfig.exe's tasks:
The /jakarta and /CFIDE virtual directories are only a couple of the many settings that wsconfig.exe writes to applicationHost.config. But editing applicationHost.config isn't wsconfig.exe's only duty. It also creates the C:\ColdFusion10\config\wsconfig\{number} directory and its contents. This directory contains the isapi_redirect.dll file which appears to contain the CGI-related fixes in this updater.
It is worth noting that IIS7/7.5 has a limitation that requires wsconfig.exe to be re-ran after each new site is created (even if the "ALL sites" option was selected during config). This is b/c IIS7/7.5 is unable to define a virtual directory in such a way that it is automatically picked up by the root application (the website root) of each new IIS site definition. I hope Microsoft knows about this issue and has either fixed it in IIS8 or is working on it.
Thank you (regarding the technote). Question:
1) CF Admin > Updates > Installed Updates
2) See "ColdFusion 10 Update 1 (10.0.1)" or "ColdFusion 10 Update 2 (10.0.2)"
I just wanted to get clarification.. so 10.0.1 and 10.0.2 are not referring to version#?
I reconfigured the connectors and now I do see the isapi_redirect.dll (8/9/12) so thank you.
I then went ahead and manually removed the CFIDE/Jakarta directories from other sites not using CF, no problem with that right?
Any update on the issues with Jakarta/ISAPI/isapi_redirector/1.2.32 failure messages? We had to restart our one cf 10 server about 8 times in the last 12 hours. It was fine the 48 hours before that.
My prior comment: "If the site's web.config contains no CF-related settings at all, then that web.config file can simply be deleted."
Should've been: "If the site's web.config contains ONLY CF-related settings, then that web.config file can simply be deleted."
@Ryan:
Just to be clear, Updater 1's wsconfig.exe creates a newer version of the isapi_redirect.dll that pre-Updater's wsconfig.exe also created. Regarding the isapi_redirector failure message, are you referring to one of these?:
- http://forums.adobe.com/message/4465125
- bugbase.adobe.com/index.cfm?event=bug&id=3222748
If so, I do not know the resolution but can try to repro the issue.
Regarding group change deletes recurring task, I was unable to reproduce this in CF10 Standard Update 2:
1) Created new task 'mytask' recurring Daily at 12:00 AM w/ URL http://a
2) Edited task and changed group from 'default' to 'mygroup'
3) Task was not deleted and 'Variable CTASK is undefined.' error was not thrown
Could you please post the repro steps?
http://forums.adobe.com/message/4465125
Although our logs will show active sessions, but other data is missing. Such as the following
Max threads: null Current thread count: null Current thread busy: null Max processing time: null Request count: null Error count: null Bytes received: null Bytes sent: null Free memory: 2870559312 Total memory: 4056481792 Active Sessions: 453
Tonight we had to restart the service 6 times inside of about 1.5 hours. It was fine the last two days. It's looking like we need to revert back to cf 9.1. Which is to bad since we have other servers we wanted to upgrade.
I see the silent task deletion + "Variable CTASK is undefined" error in a very specific scenario. Questions:
1) Is this on Windows/IIS?
2) Are you creating the task via <cfschedule or via CF Admin?
3) Are you updating the task via <cfschedule or via CF Admin?
4) Does the task have a password?
5) Does the task use an event handler? (new in CF10)
Depending on the answers, I may have more questions.
To reproduce create new task:
Task Name: Test
URL: http://www.adobe.com
Password: adobe
Everything else leave as default
Save Task. Then go back and rename the task to Test2 and the error occurs and the task gets deleted (very annoying).
This is a major problem for me as I have over 20 tasks on one instance and they require a password to execute and anytime I change the Task Name or Group Name on the task it deletes.
Found the bug! That task auto-deletion bug w/ CTASK error msg appears when 15 asterisks are in the password field in Administrator's add/edit task UI. The bug does not affect the cfschedule tag. The bug even exists when creating a new task.
To reproduce (using same info you provided earlier) create new task:
Task Name: Test
URL: http://www.adobe.com
Password: ***************
Everything else leave as default
Save task. Immediately see error "Variable CTASK is undefined".
The number of asterisks must be exactly 15. Adobe should be able to take it from here as it is obviously an issue related to task creation rather than task updating (perhaps an issue w/ a behind-the-scenes call to Quartz's Scheduler.rescheduleJob() - that's just a guess and I could be totally wrong there). Anyhow, I see you filed a ticket and will just add a note to it.
Workaround, for now, is to always re-enter the password when changing the task's name or group w/in the add/edit task UI.
Thanks!,
-Aaron
Leave a Comment