• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

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

 
Robert Paris
Ranch Hand
Posts: 585
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 4313
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Check out this thread:how to find oyut the caller object
 
Robert Paris
Ranch Hand
Posts: 585
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Robert Paris
Ranch Hand
Posts: 585
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Robert,
may I ask what you do need this for?
 
Robert Paris
Ranch Hand
Posts: 585
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
    Posts: 313
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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,
     
    Robert Paris
    Ranch Hand
    Posts: 585
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 313
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 1865
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    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 ]
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic