retrieving information up the stack

Thread view:

ben@kafkaville.com - 05 Jun 2007 17:12 GMT

I have a need to traverse up the stack, access a particular calling
object and retrieve an instance variable via a getter. Was wondering
if anyone knows how to do this. I can identify the caller through the
StackTraceElement but don't know how I can retrieve the object to
reflect on the getter. IDE's do this some how when debugging.

Reply to this Message

Owen Jacobson - 05 Jun 2007 17:27 GMT

On Jun 5, 9:12 am, b...@kafkaville.com wrote:

> I have a need to traverse up the stack, access a particular calling
> object and retrieve an instance variable via a getter. Was wondering
> if anyone knows how to do this. I can identify the caller through the
> StackTraceElement but don't know how I can retrieve the object to
> reflect on the getter. IDE's do this some how when debugging.

When debugging, IDEs use the JVM's external debugging hooks, which are
not[1] available to applications running inside the JVM. Furthermore,
that kind of stack grovelling introduces some truly hairy and subtle
dependencies between the callee and the caller; I seriously doubt that
it's the best way to accomplish, well, anything.

What are you aiming to do with the information you get from this
getter?

[1] readily

Reply to this Message

ben@kafkaville.com - 05 Jun 2007 17:40 GMT

> On Jun 5, 9:12 am, b...@kafkaville.com wrote:
>
[quoted text clipped - 14 lines]
>
> [1] readily

I'm writing a custom logger that writes to the database. This logger
groups a set of logs with a "processObjectId" which is associated with
a batch run. For example, the dailybulletinprocess as 6 main classes
that get invoked. These classes each invoke additional classes that
are running in all types of unrelated contexts. I want to be able to
retrieve my logs only in the context of the "dailybulletinprocess". I
cannot specify this in the Logging statement because the contexts
differ. I also don't want to pass this info to each class as that
would begin to smell.
I was thinking if I could set a variable in a top level constructor
and access it up the stack it would solve my problem.

Reply to this Message

ben@kafkaville.com - 05 Jun 2007 17:57 GMT

On Jun 5, 10:40 am, b...@kafkaville.com wrote:

> > On Jun 5, 9:12 am, b...@kafkaville.com wrote:
>
[quoted text clipped - 26 lines]
> I was thinking if I could set a variable in a top level constructor
> and access it up the stack it would solve my problem.

Best solution I've come up with so far would be to log all batch stuff
to a file and when done, the top level class would parse it and suck
it into the database logging tables.

Reply to this Message

Patricia Shanahan - 05 Jun 2007 19:38 GMT

...

> I'm writing a custom logger that writes to the database. This logger
> groups a set of logs with a "processObjectId" which is associated with
[quoted text clipped - 7 lines]
> I was thinking if I could set a variable in a top level constructor
> and access it up the stack it would solve my problem.

Why not set a thread local variable in the top level constructor? See
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/ThreadLocal.html#ThreadLocal().

Patricia

Reply to this Message

ben@kafkaville.com - 05 Jun 2007 20:13 GMT

> b...@kafkaville.com wrote:
>
[quoted text clipped - 15 lines]
>
> Patricia

Yes was thinking along those lines to some extent. My explanation was
somewhat simplified of the use case. These processes (within the batch
context) are distributed to random machines, each runs an Eclipse rich
client, which spins off a new thread for the particular task it's
doing. My thought, after ruminating over lunch on it, is to record the
machine name (gotten from the stack), and the thread number(s) in a
table and associate them with the process objectid. I will pass the
process object id to the instantiated upper level class and store it
in the database and a ThreadLocal variable.

Reply to this Message

retrieving information up the stack

Free Magazines