This content has been marked as final. Show 6 replies
Why not just tell the CFC who you are?
You can also access the CGI variables from inside your CFC.
Thx for your response, passing an argument would idealy be the simplest approach but in the context of the problem it would not be posible. I am working with a VERY large application and to do so would mean modifying hundreds of lines of code where the CFC I'm invoking is called from throughout the system. With large legancy systems as you know, it's always exceptable to make sweeping changes through sensitive code. If I end up not being able to find a method in which to find who invoked the CFC I am modifying I will just have to live with the fact. Idealy I want to be able to track and log who it was that initiated the CFC. That can come from a number of model cfm files or cfc's.
This can be done easily if debug is on and the client PC is in the allowed list. But, then you would also have the regular debug information appended or popping up. You could also create a CF template that just canceled the debug displays but then debugging info would not be shown for any user or any application on that server.
When debug is off, or the client PC is not allowed to view it, CF either doesn't collect the information you seek or does a darn good job of hiding it.
Please note that CFC's should be atomic as much as possible. Having them know, use, or depend on their call state is dangerous and flies against good object oriented principles.
Do you need to get down to the include level? If not, CGI.SCRIPT_NAME (and a little list parsing with delimiter="/"), will give you the initial .cfm.
Please see my original posting, I have moved my comments to there.
I understood your requirement and a solution is possible as outlined in my previous post.
However, you did not say that this was part of an exception handling scheme. This makes what you want much easier to get.
First, set up application level error checking in Application.cfc or using cferror in Application.cfm.
Next, modify your catch handling to set whatever global flags you want and then rethrow the exception. The normal errror handling framework makes it easy to get the calling tree.
The getPageContext() approach is not needed, may break with the next CF release, and requires proprietary knowledge that nobody seems willing to divulge.