Who called a CFC

[dj-kirE]

is there a way to find out who invoked a CFC? I would like to check and log who the calling .CFM or .CFC file is from within the CFC being invoked. Sort of like back in the Custom Tag days, I need to know which templated called me. I am looking at the GetMetaData() and GetPageContext() functions but nothing stands out yet as how to do what I need to do.

*****************************************

Thanks All for the Posts below,

This is a pretty tough one, and I wish I could diagram it to help explain.

cfc1
cfc2
...
...
cfc55

In any of these CFC's, we have code wraped in try/catch statements. When an exception is thrown, the catch statements kick in. in the catch blocks, I invoke a cfc called myErrorCFC.cfc..

err = createObject("component", "myError");

From there inside of the catch block I am invoking a method (see below) which performs legancy handling/logging.

err.parseException(cfcatch.Message);

What I now need to do is extend that method to log who thrown the exception. Yes the simple way is to pass the name of the cfc or cfm page as an argument, but changing the code which invokes the err cfc is out of my control. So I am left with trying to solve this the hard way.

So far this is where I am at (in my "myErrorCFC.cfc", invoked from within the catch blocks) which is not currently working:

tmp = getPageContext().getException();

This does not work but it may clearify the approach I am taking. Does anyone have any good ideas on how to return the error object from the JRun/jsp/java side of things. "getPageContext()" returns a "coldfusion.runtime.NeoPageContext" object. The end result I am trying to achieve is simply (ha ha) to find out which cfc or cfm page that the exception was thrown and having access to any additional info would be benificial as well.

Any help will be appriciated greatly.

Thank you,
Erik

[pete_freitag]

Why not just tell the CFC who you are?

You can also access the CGI variables from inside your CFC.

[dj-kirE]

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.

[MikerRoo]

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.

[JMGibson3]

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.

[dj-kirE]

Please see my original posting, I have moved my comments to there.

[MikerRoo]

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.