CF9: How to force recompile?

Report · Jul 20, 2009

I have an odd problem with CF9. Code sometimes runs, sometimes errors out when initializing an app.

When the app starts, several objects get created and their init routines invoked. Suddenly and inexplicably, I started getting this error:

"The OEMAIL argument passed to the init function is not of type console.objects.Email"

Line xx8: <cfset oTasks.init(cDSN, oEmail)>
Line xx9: <cfset oRedirect.init(cDSN,oEmail, oLib)>

But the error comes from line xx9, not line xx8. In fact, oEmail gets passed to several init routines before CF complains about it on Line xx9. This is all code that has worked for months with CF8 and since July 14th with CF9.

First I tried deleting all C:\ColdFusion9\wwwroot\WEB-INF\cfclasses\cfEmail.*.class files. Same error. Then I made a white space change in email.cfc and saved it. No more error on Line xx9, but now I got a similar error with another object. I had to make white space changes to about 5 of them, and finally no more error messages.

Is there some way, besides touching all these cfc files, that CF can be forced to recompile them to hopefully eliminate these erroneous error messages?

Report · Jul 24, 2009

Not sure what's happening with the error but to clear the cache I believe what you will want to do is to uncheck "Save class files " in cfadmin under caching. In the same area you can clear the component and template cache. I suppose you could try setting the "Maximum number of cached templates" to 0 and then clear the cache and keep it that way for testing. Expect very slow performance of course.

Another thing to be warry of are the effects of proxy servers. I have seen some odd behavior due to proxy servers caching what should have been totally dynamic templates. In the past it happened when I used SEO Friendly URL's and there was nothing unique to the URL and no query string.

-Joe

Report · Jul 27, 2009

I tried unchecking everything having to do with caching, but I'm still having the same problem. In fact I can't get the app to run. I tried rechecking them too, to no avail.

Might re-installing CF9 help in a case like this?

Report · Jul 28, 2009

If you have a second system with the developers edition of CF8 or CF9 beta on it you might just want to post your code to it and see if the same thing happens. If it does then yes reinstalling would be an option.

-Joe

Report · Jul 29, 2009

Trying it on a second system would be nice. I tried reinstalling CF9, same problem. I un-installed 9 and re-installed 8, same problem. Well reinstalling 8 may not be accurate. I had never uninstalled for one thing. But after un-installing 9, I put the previous copy of the coldfusion8 directory back from a backup copy, and used an old copy of the CFIDE directory. (Verified that no CF9 services were running) I guess the next step is to un-install then re-install 8. It just can't be the code, because it's run in the past, runs on Railo now.

Refering to the original problem, I'm getting this error

blah argument passed to the init function is not of type blah.blah.blah when I pass it to the init routine of another cfc. Init routines of other cfc's accept it just fine. Is there a way to see just what 'type' CF sees this as?

Report · Jul 30, 2009

Un-installing and reinstalling CF8 didn't help. I finally narrowed the problem down to:

if I specify the argument as:

I get the error. But if I specify it as

it works. The cfc with this argument is in a different directory than objectName and so it was a little surprising to me that it didn't require the full path, although it is in a subdirectory of directory2..

The big mystery is why this has suddenly stopped working.

Report · Jul 30, 2009

It gets weirder.

I have another app that is structed similarly, and there's no problem there. Doing a self introspect I get

generate.objects.kEmail
Component kEmail (kEmail)

Email Routines

hierarchy:    WEB-INF.cftags.component
      generate.objects.kBase
            generate.objects.kEmail
path:     D:\webrootB\generate\objects\kEmail.cfc

Introspection on the non working cfc gives

kEmail
Component kEmail

Email Routines

hierarchy:    WEB-INF.cftags.component
      kBase
            kEmail
path:     D:\webrootA\console\objects\kEmail.cfc

So I made a copy of kEmail.cfc on the non working app, and the introspection gives

console.objects.kEmailCopy
Component kEmailCopy (kEmail)

Email Routines

hierarchy:    WEB-INF.cftags.component
      console.objects.kBase
            console.objects.kEmailCopy
path:     D:\webrootA\console\objects\kEmailCopy.cfc

!

So apparently something that's not in the class files got stored somewhere?

Report · Aug 01, 2009

Un-installing and reinstalling CF8 didn't help. I finally narrowed the problem down to:
if I specify the argument as:
<cfargument name="someObject" type="directory1.directory2.objectName" required="yes">
I get the error. But if I specify it as
<cfargument name="someObject" type="objectName" required="yes">
it
works. The cfc with this argument is in a different directory than
objectName and so it was a little surprising to me that it didn't
require the full path, although it is in a subdirectory of directory2..
The big mystery is why this has suddenly stopped working.

You can avoid that completely. Use mappings.

The following saves me a lot of headache. In the Administrator, I register a mapping to my CFC directory -- or mappings, if there are two or more groups of CFCs.

Now suppose order.cfc is in the client directory and salary.cfc in the employee directory. Suppose further that both client and employee are subdirectories of the CFC directory. Register CFC mapping in the administrator.

Logical Path: /cfc

Directory Path: C:\ColdFusion9\wwwroot\cfc

You can then specify the types as follows, without confusion or ambguity:

In fact, you might decide to register separate mappings for the different component types, like this

Logical Path: /clientcfc

Directory Path: C:\ColdFusion9\wwwroot\cfc\client

Logical Path: /employeecfc

Directory Path: C:\ColdFusion9\wwwroot\cfc\employee

You would then specify the types as:

Report · Jul 31, 2009

"The OEMAIL argument passed to the init function is not of type console.objects.Email"
Line xx8: <cfset oTasks.init(cDSN, oEmail)>
Line xx9: <cfset oRedirect.init(cDSN,oEmail, oLib)>
But the error comes from line xx9, not line xx8. In fact, oEmail gets passed to several init routines before CF complains about it on Line xx9.

Are oTasks and oRedirect both instances of the same component? The different signatures for init suggest not. One takes two arguments, the other three.

I don't think Coldfusion supports this kind of function overloading. Could we see code for the email component?

How do you define the parameter oEmail? Is it an instance of the component console.objects.Email? That is, do you create oEmail like this,

<cfset oEmail=createobject("component","console.objects.Email") >?

Coldfusion seems to think you don't.

Report · Jul 31, 2009

oTasks and oRedirect are different components.

Yes, creating oEmail exactly like this <cfset oEmail=createobject("component","console.objects.Email") >, and oEmailCopy similarly.