tracker issue : CF-3477538

select a category, or use search below
(searches all categories and all time range)

cfajaxproxy and cfcomponent extends no longer work in CF 10 when using IIS Virtual Directories

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/

Reporter/Name(from Bugbase): Dav Stott / Dav Stott (davstott-csl)

Created: 01/16/2013

Components: CFComponent, Components

Versions: 10.0

Failure Type: Non Functioning

Found In Build/Fixed In Build: Final /

Priority/Frequency: Major / Some users will encounter

Locale/System: English / Win 2003 Server

Vote Count: 0

Problem Description:

CFAJAXPROXY and CFCOMPONENT EXTENDS="" no longer resolve relative paths to CFCs when running in Coldfusion 10 on Windows from an IIS Website that uses virtual directories.

We have application code that worked fine on Windows Server 2003 R2 using IIS Virtual Directories up until we upgraded to Coldfusion 10 Enterprise Standalone. Now, instead of correctly resolving the path to the CFC, CF throws the following exception:

The specified CFC calc could not be found. The path to the CFC must be specified as a full path, or as a relative path from the current template, without the use of mappings

coldfusion.tagext.html.ajax.AjaxProxyTag$InvalidCFCException: The specified CFC calc could not be found.
	at coldfusion.tagext.html.ajax.AjaxProxyTag.getCFCInvocationPath(
	at coldfusion.tagext.html.ajax.AjaxProxyTag.generateAjaxProxy(
	at coldfusion.tagext.html.ajax.AjaxProxyTag.doStartTag(
	at coldfusion.runtime.CfJspPage._emptyTcfTag(
	at cfindex2ecfm543476416.runPage(I:\inetpub\temp\test\index.cfm:1)

We have confirmed that relative CFC paths work ok on Linux and Apache and on Windows and IIS without using virtual directories. We have not tested newer versions of Windows, neither have we tested Coldfusion running in J2EE configuration nor have we tested it on CF 9. We can confirmed that the only thing that changed on our servers was the upgrade to Coldfusion, the code hasn't changed.

Steps to Reproduce:

Create a website on Windows Server 2003 and configure it to handle CF against a standalone instance of CF 10 Enterprise on the same computer. 
Create a virtual directory on that website that connects a URL to a filesystem not in that webroot, but still on that same operating system.
Unzip the attached application and run it

Actual Result:

coldfusion.tagext.html.ajax.AjaxProxyTag$InvalidCFCException is thrown

Expected Result:

The number '3'

Any Workarounds:

CFAJAXPROXY can probably be worked around by setting a variable for each request that works out the absolute path to the CFC in that environment. This approach cannot work for CFCOMPONENT inheritance though, we cannot think of a workaround for that because that path resolution occurs earlier in the compilation process.

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3477538

External Customer Info:
External Company:  
External Customer Name: davstott-csl
External Customer Email:  
External Test Config: My Hardware and Environment details:

Windows Server 2003 R2 32bit 


Coldfusion 10 Enterprise Standalone Configuration

A single website that's had its CF connector configured by wsconfig.jar

A virtual directory created in that website that is configured to run scripts and executables with its filesystem path somewhere else on that server, outside of the website's document root.


  1. January 16, 2013 00:00:00:


@Immanuel Can you try to repro it as this bug involves some setup
Comment by Uday O.
16740 | May 06, 2014 01:44:11 AM GMT
davstott-csl I can observe this issue in CF10, but this works as expected in CF11 update 3.
Comment by Piyush K.
16741 | December 11, 2014 08:01:47 AM GMT
This is language related issue and not specifically related to ajax. Passing it to awdhesh
Comment by Uday O.
16742 | January 15, 2015 05:22:19 AM GMT
This issue is not observed in CF 11. Closing this as fixed in CF11 as, at this point of time we are not taking this up for CF10.
Comment by Piyush K.
16743 | September 24, 2015 11:36:14 PM GMT