I keep encountering a "The method was not found in component" error upon restarting CF services. Upon stopping and starting again this method will then be fine.
The method not found happens to be the most recently added function to a CFC that has been in production for years. None of the other functions in that CFC are throwing errors just this one. I have attempted clearing caches, etc. All CFC are defined in Application.cfm.
Has anyone encountered this issue or have any advice or solution?
Thanks.
The method not found happens to be the most recently added function
Is the method marked access="private"?
Is the method marked access="package"?
Is the method spelled correctly?
Is the reference to the method spelled correctly?
Can other methods in the same CFC be called?
Are you sure you've deployed that file change to production?
Have you checked the actual file on the server to make sure the method is there?
Have you verified that your CF Admin is pointing to the correct mapping path?
Is that path where this CFC is actually located?
In CF admin, is "Component cache" unchecked?
Related
I am working on DjangoRest Framework, if I update values from the API, and see the content on the frontend, the changes are not getting reflected without server startup. For debugging, I also directly changed the value in the database, but the changes are not getting reflected either in this case too.
What could be the reason behind this? Can someone point me out in the right direction?
I read about it and someone told this is happening because of .pyc files I even deleted them. But nothing solved my issue yet.
If you need to see any screenshot or logs. I am happy to provide it. But How can i resolve it ?
I see an error using CFCHART with Lucee. Same code works in CF. But in Lucee it try to refer to a file graph.cfm in a folder lucee.
mytestserver.com/lucee/graph.cfm?img=026f01d7b8c85b891a9c35c102623747&type=png
Do I need to create any mapping? Should this mapping be in Lucee admin or in IIS?
The short answer is: No, you don't need to add any additional mapping in IIS, nor in Lucee or Tomcat.
I've seen this question here for too long, so I'm placing an answer here to shed some light into Lucee's graph.cfm.
Some tags in CFML need to create additional image files to later embbed them as an inline HTML element into the reendered output altogether. Examples for such file creation are <cfimage type="captcha" ...> or like you have already noted in your issue, <cfchart>.
For such functionality Lucee needs to create these files temporarily somewhere and also make them publicly available. To achive this for cfimage/cfchart, Lucee creates the files in the web context folder of your webroot (which typically is located at path-to-your-webroot\WEB-INF\lucee\temp\graph ) and embbed them inline with a link to graph.cfm. The template graph.cfm just reads the temporary file from that folder, and delivers it in realtime to your application.
If you want to take a look into Lucees original graph.cfm, we can take a peek thanks to OpenSource:
source of Lucees graph.cfm at github
In order to make the files and the template graph.cfm temporarily publicly available, which by the way sits behind the WEB-INF folder ( which is also hidden/blocked by default in Tomcat for securtiy reasons), Lucee MUST have a virtual mapping. But you don't need to set it up, because these are already set up by default. You can see this in the image below taken from the "Mapping"-section of Lucee Administrator:
Because graph.cfm is a .cfm file, IIS will redirect the request directly through the implemented CFML connector ( probably Boncode Connector ) per AJP to Tomcat. Thus you don't need to set any mapping in IIS neither.
Because you have not submitted any additonal error information, such as http error codes or stack traces, I don't have any clue of what might be the cause of your error. It may also be some incompability issue which might be addressed if you submit it to the Lucee core team.
Another possibility is that many installation guides advise you to lock down the "/lucee/" path with IIS URL Rewrite Module, because this is also the path where the Lucee Administrator sits behind. If so, you can change the setting in IIS Rewrite Rule and adapt the rule in such a manner, that it would not block the graph.cfm.
It's also important to note that many of these cftags are implemented as Lucee extensions (.lex files). These are not necessarily pre-shipped or pre-installed in Lucee, but you may install it within Lucee Administrator or get them from Lucees Download site and upload it through your Lucee Administrator in the "Extension" section.
I've just encountered this too. Issue being though the the default mapping still don't navigate to "graph.cfm" so we've added an IIS virtual mapping instead.
I have a few related selects that work perfectly on a testing server with very loose security (basically just a simple default install of CF 10).
I have tried to implement the CF 10 lockdown guide on the production server and all seems well, except that related select don't work. That is, the first select in the chain doesn't populate and therefore, none of the related selects populate either.
I even recreated Ben Forta's art media example: perfect on the testing server, no triggering in production.
All other CFC functions seem to work: SELECT and INSERT queries are just fine. Only CFSELECTs with bindings are hosed. I pretty sure that the problem is a server configuration. The same pages worked just fine on our old CF 9 box. Any ideas would be helpful.
My advice to you would be to NOT use cfselect or any other UI stuff in ColdFsuion - It only causes more headaches than it gets rid of.
That being said, if you followed the lockdown guide, you should have limited access to the CFIDE directory - which is needed for any of the ColdFusion UI stuff. There is an option in CF Admin to use a 'custom' path for the scripts ColdFusion uses - it is on the main Settings page. Set this value and create a virtual directory in IIS with the same name pointing to the {cfroot}CFIDE/scripts directory.
I am running ColdFusion 9,0,1,274733 with hotfix 2 applied on a Windows 2008 Server 64-bit with IIS.
I have written a cfc to handle logging (user auditing) to a database table. Basically I call this cfc at different points during the request cycle. On application start, on request end, on application end and when errors occur. It all works perfectly well until the application expires.
So here are some relevant parts from my Application.cfc.
I am defining a mapping to the cfc's location outside of any cffunction like so:
this.versionfolder="version1";
this.mappings["/modules"]="C:\Webroot\folder\#this.versionfolder#";
Then in the aforementioned application events I can call my logging cfc like so:
<cfinvoke component="/modules/LogIt" method="Store" />
This works fine until the application expires. When the code fires my cfinvoke for the logging module in the OnApplicationEnd method I get this error:
Message: Could not find the ColdFusion component or interface /modules/LogIt.
Detail: Ensure that the name is correct and that the component or interface exists.
I know that the cfc exists it has been calling it the same exact way throughout the application's life span. Has anybody else seen this behavior?
To throw a wrench at this, the application that I am having this problem with is located in the web root. I have another application, running on this same server, which is located in a sub-folder of this application (they have different application names). I am using the exact same logic in that Application.cfc referencing the same logging cfc via that application's mapping and it works fine on application end. I am stumped and have not been able to find anything online about this specific scenario.
To be clear, my application in the web root fails every time on application end. My application in the sub-folder works every time. Not sure if this is relevant but the web root application is started (accessed) before the sub-folder application. Although I have tested only hitting the web root application and it still fails. I have also tried using dot-notation for the component name but it still fails.
I just did some research into this because I spotted another question here asking much the same thing.
My findings were that there's a but in CF8-10 that result in Application.cfc-set mappings do not work in onApplicationEnd() (nor indeed in onSessionEnd() in CF8). the work around is to set the mappings in CFAdmin. Not much of a workaround, I'm afraid.
onApplicationEnd fires AFTER the application has ended, so the application scope is no longer available.
Because your sub application is in a subfolder when its onApplicationEnd method fires it still can access its parents application scope.
Use the ApplicationScope parameter to access the application scope; you cannot reference the scope directly; for example, use Arguments.ApplicationScope.myVariable, not Application.myVariable. - docs
Following: http://help.adobe.com/en_US/ColdFusion/9.0/Installing/WSf01dbd23413dda0e-3f89e8d411fae637e44-8000.html
I already commented out the RDS in \JRun4\servers\[name]\cfusion.ear\cfusion.war\WEB-INF\web.xml
However, the RDS tab is still there in the CF Administrator, and browsing to a CFC still redirect me to /CFIDE/componentutils/cfcexplorer.cfc
How to disable "Component Browser" in ColdFusion?
Thanks
If you don't want your CFCs to be browseable, don't put them in a directory that's browseable! Only files you intend to be browseable ought to be exposed by the web server.
I think the problem here is not the CFC explorer's functionality, it's that you've got stuff you don't want to be browsed to in a browseable location.
The "Component Browser" cannot be disabled--it is a hard-wired function of ColdFusion, which automatically fires when you make a web request to the full location where a .CFC resides--and is unrelated to RDS, whether it is enabled or not.
You will have to decide upon a methodology that you want to approach to prevent direct access to your CFCs, and implement it that way, instead. Such options are:
Disabling the "auto-documentation" of a CFC, as described in the post provided by Henry above (Source: Ray Camden).
Remove the /CFIDE virtual mapping from any of your public facing websites, so that a direct .CFC web request results in a HTTP 500 (as cfcexplorer will no longer be accessible).
A slicker option altogether is to make your public-facing websites use a different virtual /CFIDE directory:
Remove the existing /CFIDE mapping for your public-facing site (#2 above)
Create a new folder in your public facing site called "CFIDE".
Within that directory, create a folder called "componentutils".
, 4. Within "componentutils", create a single file, "cfcexplorer.cfc", which you will then use to make a single call, and return a 403 (Forbidden) code to the browser:
<cfheader statuscode="403" statustext="Forbidden" />
This option is good, because you not only hide your CFCs from direct access via the implicit functionality of the Component Browser, you also hide your CF Administrator from the public (which many CF sites often forget about).
Can't you just delete/rename the cfcexplorer.cfc?