From: Paul G. <pau...@so...> - 2001-07-20 08:02:20
|
I am currently have a side project that will do something like this. It = is a module that implements a telnet daemon that runs as a java thread. = When someone connects, it starts a jython interpreter and uses this as=20 the shell for user interaction. Thus, if this is embedded in a running=20 server, you can connect using an ordinary telnet client and manipulate=20 object running in the same VM. This is still work in progress, but some = of the sticky points so far: - Implementing telnet: I tried to find a java telnet daemon that I=20 could adapt or borrow code from. There does not seem to be any yet. Also= =20 getting complete and understandable documentation for the telnet protoco= l=20 is not that easy (every time I use a new telnet client, it starts trying= =20 to negotiate some other connection parameter that i cannot find in any=20 documentation). - There has to be a way to get references to the other objects that=20 you want to manipulate. This can be as simple as placing references to=20 all of the objects that you want to manipulate into a hashtable that is = statically initialized or available through a singleton. It just need to= =20 be done in advance, otherwise the jython interpreter winds up more or=20 less isolated from the rest of the application. - If I try to run multiple instances of jython interpreters in=20 different threads, bad things start to happen. It is not really critical= =20 that I handle multiple connections simultaneously, but I would not expec= t=20 this to be a problem. :-( AFAIK it is also possible to remotely connect to a running VM using the = Java debugging API (if the VM was started with debugging options on), so= =20 if you go this route, you do not need to provide your own interpreter in= =20 that VM, but jython might be helpful in making a simple client. The idea of the project above is to do more high level interaction, like= =20 reconfiguration, at runtime. -Paul > I am experimenting with Jython at the moment. I am impressed. > I was wondering if any jython-guru's have used it to debug Java code. > I guess you could run the Jython interpretor in a seperate thread to t= he > program you're trying to debug. You could then stop the thread from=20 jython > and inspect the state of its attributes and test calling some of the > methods. > This would be very handy for experimenting with swing gui's. > Has anybody experimented with some of the Java debugger api's? It may = even > be possible to set break points on particular methods. > Any Ideas would be appreciated. > Thanks, > Greg. |
From: Adrian S. J. <as...@pa...> - 2001-07-20 08:24:38
|
> From: Paul Giotta > > I am currently have a side project that will do something like this. It > is a module that implements a telnet daemon that runs as a java thread. > When someone connects, it starts a jython interpreter and uses this as > the shell for user interaction. Thus, if this is embedded in a running > server, you can connect using an ordinary telnet client and manipulate > object running in the same VM. This is still work in progress, but some > of the sticky points so far: > > - Implementing telnet: I tried to find a java telnet daemon that I > could adapt or borrow code from. There does not seem to be any yet. Also > getting complete and understandable documentation for the telnet protocol > is not that easy (every time I use a new telnet client, it starts trying > to negotiate some other connection parameter that i cannot find in any > documentation). I've implemented telnet-like daemons in C++ and Smalltalk. The one thing I have learnt is that if you don't offer any telnet option codes, the clients tend not to try to negotiate anything. The other thing you can do is just send a WONT in response to any option you don't understand that the client sends as a DO, and a DONT when you're sent a WILL. > - If I try to run multiple instances of jython interpreters in > different threads, bad things start to happen. It is not really critical > that I handle multiple connections simultaneously, but I would not expect > this to be a problem. :-( What sort of problems? I've just got a mud-like engine running with multiple interpreters each in their own thread, and had very few problems. The hardest thing I had to do was to redirect stdout/stderr back to the telnet connection, as it seems that Jython 2.0 grabs stdout/stderr at the point that you initialise it, rather than just using Java's stdout. > -Paul Adrian. |
From: John D. H. <jh...@is...> - 2001-07-20 14:30:07
Attachments:
jdip.py
|
Hi all, This is really old JPython code that I started when I was doing a lot of = Java=20 coding (~2 years ago). But it might be useful to people. Attached is a JPython module that is supposed to wrap the JDI debugger=20 libraries. I used to run it interactively in JPython and interatively de= bug=20 Java programs. Note: I apparently am missing a Helper module that used to go along with= =20 this, but I don't think it was terribly important. It does mean that thi= s=20 code won't run currently at all though. I hope this is useful to someone. John On Friday 20 July 2001 03:02, Paul Giotta wrote: > I am currently have a side project that will do something like this. It > is a module that implements a telnet daemon that runs as a java thread. > When someone connects, it starts a jython interpreter and uses this as > the shell for user interaction. Thus, if this is embedded in a running > server, you can connect using an ordinary telnet client and manipulate > object running in the same VM. This is still work in progress, but some > of the sticky points so far: > > - Implementing telnet: I tried to find a java telnet daemon that I > could adapt or borrow code from. There does not seem to be any yet. Als= o > getting complete and understandable documentation for the telnet protoc= ol > is not that easy (every time I use a new telnet client, it starts tryin= g > to negotiate some other connection parameter that i cannot find in any > documentation). > > - There has to be a way to get references to the other objects that > you want to manipulate. This can be as simple as placing references to > all of the objects that you want to manipulate into a hashtable that is > statically initialized or available through a singleton. It just need t= o > be done in advance, otherwise the jython interpreter winds up more or > less isolated from the rest of the application. > > - If I try to run multiple instances of jython interpreters in > different threads, bad things start to happen. It is not really critica= l > that I handle multiple connections simultaneously, but I would not expe= ct > this to be a problem. :-( > > > AFAIK it is also possible to remotely connect to a running VM using the > Java debugging API (if the VM was started with debugging options on), s= o > if you go this route, you do not need to provide your own interpreter i= n > that VM, but jython might be helpful in making a simple client. > > The idea of the project above is to do more high level interaction, lik= e > reconfiguration, at runtime. > > -Paul > > > I am experimenting with Jython at the moment. I am impressed. > > > > I was wondering if any jython-guru's have used it to debug Java code. > > > > I guess you could run the Jython interpretor in a seperate thread to = the > > program you're trying to debug. You could then stop the thread from > > jython > > > and inspect the state of its attributes and test calling some of the > > methods. > > > > This would be very handy for experimenting with swing gui's. > > > > Has anybody experimented with some of the Java debugger api's? It may > > even > > > be possible to set break points on particular methods. > > > > Any Ideas would be appreciated. > > > > Thanks, > > Greg. > > _______________________________________________ > Jython-users mailing list > Jyt...@li... > http://lists.sourceforge.net/lists/listinfo/jython-users --=20 =2E . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | jh...@is... w w w . d a t a c h a n n e l . c o m |
From: D-Man <ds...@ri...> - 2001-07-20 15:43:54
|
On Fri, Jul 20, 2001 at 08:02:12AM +0000, Paul Giotta wrote: | | I am currently have a side project that will do something like this. It | is a module that implements a telnet daemon that runs as a java thread. | When someone connects, it starts a jython interpreter and uses this as | the shell for user interaction. Thus, if this is embedded in a running | server, you can connect using an ordinary telnet client and manipulate | object running in the same VM. This is still work in progress, but some | of the sticky points so far: | | - Implementing telnet: I tried to find a java telnet daemon that I | could adapt or borrow code from. There does not seem to be any yet. Also | getting complete and understandable documentation for the telnet protocol | is not that easy (every time I use a new telnet client, it starts trying | to negotiate some other connection parameter that i cannot find in any | documentation). You should probably just ignore anything not mentioned in the RFC. All you need is character input, output, and (ideally) backspace. This is all the interactive interpreter provides anyways (no readline in Java :-( ). If you don't do anything then the telnet client should behave properly (I think). What I mean is, for example, try "telnet mail 25" and see how telnet can connection to an SMTP server just fine. You could also try that on port 80 and see how HTTP daemons have no trouble with it either. A telnet client should be able to connect to any port and behave, though it might not have any advanced terminal features. -D |