cfajaxproxy problem in CF9

[darbus23]

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.

[Fernis]

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

[darbus23]

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]

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

[darbus23]

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?

[Fernis]

What matters is where your IIS main document root is. That is what you use as the basis of your notation.

And the notation must be relative to the web server root - thus you cannot mix physical paths (such as drive letters) and dots.

Answering shortly this time, since I'm tired and had a glass or ten of wine . I hope other people contribute to this thread, since I'm not actually an expert on this one. Try searching google for this, since many people have this issue - from CF 8 on already...

-Fernis

[ilssac · Accepted solution]

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.

[darbus23]

@Ian Skinner

Thank you very much for your reply as that solved my problem.  I now put the virtual directory into my path cfc="CAR.getReports" and all works.

[David_Dykstra]

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

[arisseu]

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...

[arisseu]

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