Seeking Jython tool to "inspect" live java server

[James_Althoff at i2.com]

Michael Chermside wrote:
>Jython users:
>
>I'm looking for what I think would be an EXCELLENT tool for debugging
>code running inside a java server (in my case, an application server
>like WebLogic). Java lacks an interactive mode, and most debuggers are a
>pain to use and also won't work well when trying to debug code that runs
>inside a large server system, and I very often find myself adding print
>statements and restarting the server.

I just wrote a similar tool except that it is an "inspector" for
client-side Jython applications (normally with Swing user interfaces).
>From a running application the developer can open an Inspector window.  The
inspector starts by inspecting the application object.  From the
application object you can traverse and inspect any reachable object in the
application.  The inspector shows fields and methods and has a
"scratchpad", a gui that lets you type Jython code into a text area and
execute fragments that you select with the mouse (much easier to use than
the traditional "prompt and scroll"-type interpreter).  For Jython code the
inspect lets you change the value of fields, add fields, and delete fields.
You can also change methods, and do a reload.  During the reload the
inspector fixes up the functions in the affected class so that existing
instances start calling the new method code without restarting the
application and without forcing you to create new instances of the class.
In addition I added a gui on top of pdb so that you can insert a
pdb.set_trace() call into a method, reload it, and then start working your
way through the code (again, without having to restart the application or
reinstantiate existing objects).  The pdb gui has buttons and pop-up menus
that reduce the need for typing while debugging.

This "inspector" tool has been a big hit with our developers.

I believe your proposed server-based tool would also be very, very useful.
Our developers go through very long development cycles when working on
server-side code.  It is really painful to have to shut down a server,
write a few lines of Java, compile it, restart the server, reconnect,
navigate to the failure point, look at print output in a logfile, and then
do that all over again for every problem encountered.

One advantage that I have with my current client-side inspector is that
most of our client-side code is written in Jython (as opposed to pure
Java).  My inspector handles pure Java instances as well as Python
instances.  But, of course, there are limitations when you are dealing with
Java (as opposed to Python).  You can view attributes of Java objects, but
editing is out (unless you are willing to go through many, many hoops).  So
the user has to use the scratchpad to make method calls on Java objects to
make changes (assuming the Java object's class has such methods defined).
Dynamic editing and reloading of methods along with adjusting a class to
allow existing instances to run the new code is out (even with your own
class loader, the last part is probably something you don't want to
contemplate).

Doing the simple things is also more of a pain for Java objects (as opposed
to Python objects).  For example, to inspect a Java object you need to use
Class.getDeclaredFields instead of Class.getFields.  The reason is that the
latter will only return Public fields and most of your server object fields
are probably going to be Private or Protected.  So Class.getFields is
pretty useless for inspecting.  On the other hand, Class.getDeclaredFields
-- although it will return non-Public fields -- won't return inherited
fields.  So you have to do the traversing of superclasses and interfaces
yourself.  Except that Class.getClasses is not implemented (at least in
Sun's JVMs through JDK 1.3).  So you have to use Class.getSuperclass --
which only returns the base superclass and not additional interfaces (if
any).  Which means you need a different mechanism to show constants defined
in base interfaces.  And it goes on and on.  (Editorial note: this is what
you get when you design a language for "typical" cases and don't think
about "meta-programming" until later.)  Dealing with Java reflection is a
big pain, but you can provide a reasonable amount of utility if you
persist.

Good luck,

Jim