retrieving information up the stack

[ben]

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.

 

[Owen Jacobson]

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

 

[ben]

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

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.

 

[ben]

On Jun 5, 9:12 am, (e-mail address removed) wrote:

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

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.

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.

 

[Patricia Shanahan]

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.

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

 

[ben]

(e-mail address removed) wrote:

...


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

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.