retrieving information up the stack
 

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.

Re: retrieving information up the stack
 

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

Re: retrieving information up the stack
 

On Jun 5, 10:27 am, Owen Jacobson <angrybald...@gmail.com> wrote:
> 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

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.

Re: retrieving information up the stack
 

On Jun 5, 10:40 am, b...@kafkaville.com wrote:
> On Jun 5, 10:27 am, Owen Jacobson <angrybald...@gmail.com> wrote:
>
>
>
> > 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
>
> 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.

Re: retrieving information up the stack
 

ben@kafkaville.com wrote:
....
> 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/...#ThreadLocal().

Patricia

Re: retrieving information up the stack
 

On Jun 5, 12:38 pm, Patricia Shanahan <p...@acm.org> wrote:
> b...@kafkaville.com wrote:
>
> ...
>
> > 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? 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.