swarm-support
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: problem with latest win32 patch for java VarProbe


From: Steve Brophy
Subject: RE: problem with latest win32 patch for java VarProbe
Date: Mon, 3 Jul 2000 10:11:46 -0400

thanks, I think I'm confused over the correct way to call the
getProbeForVariable$inClass method.

Our old code had done this, which worked with older javaswarm.dll files:

Sample (old way, wrong?):
(where SuperClass defines the public instance variable "superclassvar",
and SubClass extends SuperClass)
  pmap = new EmptyProbeMapImpl(aZone, SubClass.class);
  VarProbe vp = Globals.env.probeLibrary.getProbeForVariable$inClass(
                        "superclassvar", SubClass.class);
  pmap.addProbe(vp);

Your message helped me realize to specify the variable-declaring class
(superclass) rather than the target object subclass.  And this works with
the latest javaswarm.dll fix:

Sample (new way):
  pmap = new EmptyProbeMapImpl(aZone, SubClass.class);
  VarProbe vp = Globals.env.probeLibrary.getProbeForVariable$inClass(
                        "superclassvar", SuperClass.class);
  pmap.addProbe(vp);

But the new code doesn't work with the older javaswarm.dll files, an error
occurrs at the line "pmap.addProbe(vp)".

Am I still not seeing the correct way to make probemaps for inherited
variables, or is the 'new way' fine and we should update our client site's
dll files?  Or is something more needed as in your suggestion of subclasses
on VarProbe?

thanks again,
Steve

> -----Original Message-----
> From: address@hidden [mailto:address@hidden
> Sent: Friday, June 30, 2000 11:02 PM
> To: address@hidden
> Subject: Re: problem with latest win32 patch for java VarProbe 
> 
> SB> I think this is the same problem which had been fixed in an
> SB> earlier patch, where I couldn't get a VarProbe for an instance
> SB> variable which belonged to a java superclass.
> 
> That's the behavior that VarProbe and the ProbeLibrary
> getProbeForVariable have always had.  I don't have an objection to
> changing the behavior of those two cases, but since the ProbeLibrary
> method is currently based on ProbeMaps (which *ought* to be restricted
> to the immediate declared class), it would take some reworking.
> 
> I'd suggest for clarity you subclass VarProbe and explicitly 
> instantiate the probes you want.  (Your subclass would step up through
> the hierarchy testing each one for the variable.)
> 
> 

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]