jQuery in Action, 2nd edition*
The moose likes Beginning Java and the fly likes is there any way to know what class/object called your method? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "is there any way to know what class/object called your method?" Watch "is there any way to know what class/object called your method?" New topic
Author

is there any way to know what class/object called your method?

Robert Paris
Ranch Hand

Joined: Jul 28, 2002
Posts: 585
I want to be able to tell in a method what object or class (either is fine) called my method. Any idea how I would do this?
For example, if I had this class:
public class Test
{
public void do()
{
//WHO CALLED IT?
}
}
and had an object "x" of type CallerClass:
CallerClass x = new CallerClass();
and my first class as object "y":
Test y = new Test();
and "x" called "y.do()", how in "y.do()" would I be able to get that either:
1. "x" called it (in other words the ref. to "x")
2. class "CallerClass" called it
Thanks!
Jessica Sant
Sheriff

Joined: Oct 17, 2001
Posts: 4313

Check out this thread:how to find oyut the caller object
Robert Paris
Ranch Hand

Joined: Jul 28, 2002
Posts: 585
Thanks Jessica.
One question, is the stackTrace standardized across ALL VM implementations? Can I be 100% sure that it will always print that out exactly the same way in every implementation?
(Assuming no one did a -Xbootclasspath and rewrote Throwable or StackTrace of course)
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
No, unfortunately. Not the one from printStackTrace() anyway. Using 1.4 the getStackTrace() method is much more standardized. But there's still a chance that some info may be unavailable due to compiler optimizations.


"I'm not back." - Bill Harding, Twister
Robert Paris
Ranch Hand

Joined: Jul 28, 2002
Posts: 585
argh. Any idea if I can at least be sure that
1. printStackTrace will include all the info I need
2. while it may not have a perfect standard, I can at least be sure that the order will be the same and it will always include "at <class>.<method>..."?
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Robert,
may I ask what you do need this for?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Robert Paris
Ranch Hand

Joined: Jul 28, 2002
Posts: 585
No problem. (NOTE: Most of the explanation below also exists in another post of mine. However the two posts WERE/ARE distinct. That post was only about a ClassLoader question when it started, but both are posts' questions are functions I wanted my Configuration object to be able to do)
  • Configurator will hold these files (resources)
  • Classes can call config.getConfig() and (hopefully) my Configurator will pass back only the file that fits the caller


  • The way I want it to do this, is for my configurator to know what class called it. It will then pass back whatever config file is stored for that class.
    Someone told me the way to do this is with printStackTrace() into a StringWriter or whatever. However, I don't know if this is standard across all VMs or not, or if there is a better way to do this.
    The reason for this, is I do not want classes to be able to see resources (config files) that are for other classes - for security reasons. So I can't have something where the class calls getCOnfig(String className) because that gives them the ability to pass another class's name.
    WHY SECURITY ON CONFIG FILES?
    ------------------------------
    Normally, I agree. Config files - who cares? It's for your own app, there's no risk. However my app is for collaboration. You can plug in objects from different places (as long as they have the right interface) - e.g. two diff. companies that work with you, on the fly at runtime. (It's through RMI right now that it works with other objects) Given this, and the fact that almost all of these objects will be configurable, I'd prefer that they only have access to their own configurations.
    WHY NOT USE ID THAT TEH OBJECT PASSES?
    ----------------------------------
    You might be right on this, as I might need an ability to give two diff. instances of Company object diff. configurations. So they would need instance markers that my Manager object can use to make sure they get the right configs. However, again I do not want this to lie with the object itself. Simply because then it is up to the object writer to implement this correctly. Not even so much a security issue as much as there's a chance for error EVERY time someone makes an object for my app.

    ANOTHER POSSIBLE SOLUTION
    ---------------------------
    So here's what I'm thinking:
    Have config for my Manager that tells it all the instances it needs to create and what their ids are
    Manager keeps a HashMap (or whatever) with a ref. to the object and its ID.
    The config files locations are also under those IDs, so when a class calls:
    config.getConfigOptions(Object ref)
    it simply passes itself in, and the config looks it up in the Manager for the id and gets the right config file
    Questions
  • Will this work with RMI?
  • Will this work even normally? Will putting a ref to the object into a HashMap and then passing that object as an argument to the method match up, but two different objects of the same class not match up?


  • [ July 31, 2002: Message edited by: Robert Paris ]
    Byron Estes
    Ranch Hand

    Joined: Feb 21, 2002
    Posts: 313
    Why not just have the calling object pass itself as a parameter (i.e. this)?
    Then you can do losts of stuff to determine who is calling you (i.e. getClass, instanceOf, etc...)
    It should also more efficient.
    If you had lots of classes that needed this capabilty, but didn't want all of them to need to deal with "this" you might be able to implemnt something imploying a Factory Method or Mediator pattern.
    Regards,


    Byron Estes<br />Sun Certified Enterprise Architect<br />Senior Consulant<br />Blackwell Consulting Services<br />Chicago, IL<br /><a href="http://www.bcsinc.com" target="_blank" rel="nofollow">www.bcsinc.com</a>
    Robert Paris
    Ranch Hand

    Joined: Jul 28, 2002
    Posts: 585
    Byron,
    Thanks for the reply. Right now that's where I'm leaning (they pass the "this" ref) but I don't think this works in RMI. Any idea what little fix I'd need to do to get it to work with rmi?
    For example, if a non-local object tries to pass "this" I think it won't really give me anything I can look up/keep a ref of, because i believe RMI does not garauntee that the ref. will stay the same throughout the life of an app.
    Byron Estes
    Ranch Hand

    Joined: Feb 21, 2002
    Posts: 313
    I didn't realize you were dealing with RMI here, but I believe you would still be ok in this case as long as the object calling you implements java.io.Serializable.
    Take a look at the RMI Specification.
    Here's a link
    rmi specification
    Here's an excerpt...
    2.6 Parameter Passing in Remote Method Invocation
    An argument to, or a return value from, a remote object can be any object that is serializable. This includes primitive types, remote objects, and non-remote objects that implement the java.io.Serializable interface. For more details on how to make classes serializable, see the "Java Object Serialization Specification." Classes, for parameters or return values, that are not available locally are downloaded dynamically by the RMI system. See the section on "Dynamic Class Loading" for more information on how RMI downloads parameter and return value classes when reading parameters, return values and exceptions.
    Good luck!
    Dan Chisholm
    Ranch Hand

    Joined: Jul 02, 2002
    Posts: 1865

    The way I want it to do this, is for my configurator to know what class called it. It will then pass back whatever config file is stored for that class.

    Is the config file assigned to a class or to a particular instance of a class? If the assignment is based on the instance, then it would make sense to pass "this" to the configurator. However, if the assignment is based on the class type, then why not have the client call Object.getClass and pass the result to the configurator?
    [ July 31, 2002: Message edited by: Dan Chisholm ]

    Dan Chisholm<br />SCJP 1.4<br /> <br /><a href="http://www.danchisholm.net/" target="_blank" rel="nofollow">Try my mock exam.</a>
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
     
    subject: is there any way to know what class/object called your method?
     
    Similar Threads
    Problem in Generic Method Declaration
    Interfaces
    Please explain these answers
    SCJP prep - protected method inheritence question
    I am new to Java programming