Skip to main content
D
darbus23
Inspiring
March 25, 2010
Answered

cfajaxproxy problem in CF9

  • March 25, 2010
  • 2 replies
  • 4537 views

We just upgraded to ColdFusion 9 on a Windows Server 2003 box that uses IIS 6 to serve the sites.

Now that we've upgraded all of our <cfajaxproxy> tags are broken.  Here is a sample:  <cfajaxproxy cfc="getReports" jsclassname="GetReportsInfo">.  The cfcs reside in the same directory as the cfm pages but we are getting an error that says "The specified CFC getReports 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."

It doesn't make sense that if they are in the same directory as the calling program then why can't it find them.

    This topic has been closed for replies.
    Correct answer ilssac

    In my instance the cfc and cfm files reside at the logical location of

    D:\CAR\ Therefore I tried <cfajaxproxy cfc="D:.CAR.getReports"... and

    <cfajaxproxy cfc="D:\CAR\getReports"... but still get the error. Is that

    the correct dot notation in my first example?


    A hint here is that if you can get to the file by putting something into the URL of the browser, then that is the path to put into the <cfajaxproxy...> tag minus the server name.

    I.E.  If this works to serve up the CFC, whether it be the code or the Coldfusion documentation, "http://www.yourDomain.com/some/path/to/myAjax.cfc"  Then what you would put into the <cfajaxproxy...> tag would be cfc="some.path.to.myAjax"

    NOTE:  The most likely result of correctly entering a CFC url path into the browser is an attempt by the ColdFusion Administrator to serve up the CFC self documentation.  This will change the URL to the CFC documentaiton tool and may or may not work and will probably ask for a password.  But none of that matters as if that happens it all means that the browser was able to see the CFC file and that the original URL was a good one and should be used in the <cfajaxproxy...> tag.

    P.S.  This is also a good way to make sure web service CFC's can be properly seen by the world at large.

    2 replies

    D
    David_Dykstra
    Participant
    July 16, 2010

    I had this same problem with apache2 on mac os x. When I upgraded to CF9 I also upgraded my apache server. Then when I tried my web application that worked great on CF8 it didn't work any more. Then I found this forum and tried what was suggested. It Worked. BUT...

    My application has many cfajaxproxy's and I am working locally for development, and I realized when I upload the files to the main server I am going to have to change all the names back so I seeked out a different solution, and I discovered something.

    It seems that when I upgraded my apache the Document root (on mac) was set to a different location then before. That got me thinking, apparently cfajaxproxy always uses and absolute path from the DocumentRoot. Why does it not support relative pathing, like it says? Also discovered that when I change the DocumentRoot in httpd.conf you have to move CFIDE and cfdocs to that new location as well.

    David

    A
    arisseu
    Participant
    July 3, 2012

    Desperate-

    I migrated to mac os Lion CF9 from Windows CF8 under apache.

    No way to understand which path is used to look for components.

    I have (local) virtual hosts. Tried absolute and relative paths with / and . notations.

    Moved the .cfc around in various directories, never found...

    Added webroot path in jrun.xml, nothing...

    A
    arisseu
    Participant
    July 13, 2012

    It seems that the problem is indeed the CFIDE location.

    I put the CFIDE folder in the web root and in my site folder I created a symbolic link to CFIDE.

    Now it works.

    It seems other ways of configuring/mapping  the path are not working

    Fernis
    Fernis
    Inspiring
    March 26, 2010

    Your'e running your site from a IIS virtual directory, right? This causes problems for many people, since IIS and ColdFusion may see the "/" path differently. From what I've read, ColdFusion does not honor the IIS virtual directories with relative mappings.

    A hint can be found in ColdFusion 9 developer's guide, page 850.

    Note: The component path cannot use a mapping. The componentPath value must be a dot-delimited path from the web root or the directory that contains the current page.

    Try

    <cfajaxproxy cfc="myrealdirectorypath.getReports" jsclassname="GetReportsInfo"> (replacing the path with the correct one)

    Which CF configuration were you running earlier, btw? Was that with virtual directories?

    --

    - Fernis - fernis.net - ColdFusion Developer For Hire

    D
    darbus23Author
    Inspiring
    March 26, 2010

    Yes we're running the site from an IIS virtual directory.  I tried the

    real directory path with both \ and . notation but I'm still getting the

    same error.  We upgraded from CF 8.0.1 and it was the same IIS

    configuration with virtual directories.  The note that you point out from

    the developer's guide says that "The componentPath value must be ... the

    directory that contains the current page" which is the case with the code

    that I originally posted because the cfc and calling cfm page reside in

    the same directory.

    Fernis
    Fernis
    Inspiring
    March 26, 2010

    Actually the behaviour is expected - it does not matter if the .cfc is in the same folder as the calling .cfm template.With IIS virtual directories you can expect problems if you don't specify the exact dotted notation for the CFC. It should work, if you use the correct notation. It is strange, however, that it worked with CF8 and not now in CF9.

    What about (using mappings and) setting custom tag paths in application.cfc?

    http://livedocs.adobe.com/coldfusion/8/htmldocs/help.html?content=appFramework_04.html

    http://help.adobe.com/en_US/ColdFusion/9.0/CFMLRef/WSc3ff6d0ea77859461172e0811cbec22c24-750b.html

    -Fernis

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices