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!
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)
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.
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>..."?
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 ]
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, 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.
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!
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 by:autobot
I have a knack for fixing things like this ... um ... sorry ... here is a consilitory tiny ad:
a bit of art, as a gift, the permaculture playing cards