I'm working on something very similar, I have a management servlet that uses rhino to wrap important container objects as javascript objects. You can then send javascript function definitions and commands over HTTP. Basically this is the plumbing for a nice ant task that will deploy a webapp to a remote server. After building a WAR, Ant will transfer the WAR to a remote tomcat server, remove an existing context and clear it out of the filesystem if necessary, and then (re)deploy the WAR. This allows WAR deployment and redeployment to be part of a build process without needing access to the filesystem and, most importantly, without the need to restart Tomcat. The javascript infrastructure allows us to perform this task and others in the future in a consistent general way (and securely, through the use of authentication etc.). It makes it really really easy to define new adminstration tasks that can then be scripted remotely as part of a buildprocess, or through a utility tool.
HOWEVER, I feel that the ability to make third party management-type servlets (i.e., ContainerServlets) is a bit broken currently. The ContainerServlet interface exists, however it only properly loads tomcat classes (from 'org.apache.catalina') correctly to have access to the various container object necessary for management (is this a design decision? if so, why publicize such an interface?). One could write their own ServletWrapper to load servlets in a context however they like, but the 'wrapperClass' property of a Context doesn't correctly induce a Context to use that Wrapper class instead of StandardWrapper. So for a third party to add a ContainerServlet to Tomcat, they must either change Tomcat source (undesirable, it would be nicer to be able to drop such a webapp in any Tomcat install) or reimplement a bunch of things (extend StandardContext and override 'createWrapper()', use that Context's className in a Context tag in server.xml, have that Context return the custom Wrapper, have that Wrapper use the catalina class loader for its servlets, etc.). If anyone thinks this is wrong and there is an easier way to do it, please let me know it would make my life easier :) -alan ________________________________________________________________________ p l u m b d e s i g n alan newberger chief architect 157 chambers st ny ny 10007 p.212.381.0541 | f.212.285.8999 -----Original Message----- From: Creighton Kirkendall [mailto:[EMAIL PROTECTED]] Sent: Friday, January 11, 2002 11:08 AM To: 'Tomcat Developers List' Subject: RE: shell connector I was just wondering why you do not want to use http as the underlying protocol. I do not believe it would be that difficult to write a shell application to utilize the management web app in tomcat. In fact with a little abstraction this could be rather simplistic. I may be totally off base here on what you are trying to do. I personally think this would be a good project and may even be interested in helping with it. I have some ideas on how to make it configurable so that as the manager adds new commands we do not have to change the code of the shell. Creighton Kirkendall -----Original Message----- From: Armijn Hemel [mailto:[EMAIL PROTECTED]] Sent: Friday, January 11, 2002 9:05 AM To: Tomcat Developers List Subject: Re: shell connector On Thu, Jan 10, 2002 at 11:08:00AM -0800, Craig R. McClanahan wrote: > > I'm working on a webapp, for which I want to build (eventually) some shell > > access for administration purposes. I want administrators to be able to > > log into the application and perform maintenance through a UNIX like shell. > > I was thinking about writing this in Jython, but I wonder how I can do this > > best. Does this involve writing a new connector and if so, is it the best > > thing to do (and do others need it as well)? > > > > What's wrong with just using telnet or ssh, and running command line apps > that update the *data* that underlies your web application? I don't see > any reason that all data updates need to be made through Tomcat. Well, I prefer updates to be mode through one program for consistency. If anything changes, it's easier to maintain/update one application, than two. I'll give a small example of a use I see. To manage servlerts in my Tomcat instance I don't want to use the web (I'm a console guy and lynx is not my favourite webbrowser). I'd rather use a shell like tool to control the server. As in, use ls (or dir, whatever you prefer) to see all webapps and use small commands like `stop <webapp>'. So, even though I appreciate your answers and suggestions (I am a stubborn guy by nature :) I want to write it. I don't think I want to use HTTP as the underlying protocol (and no one said servlets should use HTTP). I'll flesh out the idea a bit more, see what's on the market (maybe JMX). Thanks so far :) armijn -- --------------------------------------------------------------------------- [EMAIL PROTECTED] | http://people.nl.linux.org/~armijn/ | Penguin Power --------------------------------------------------------------------------- http://nl.linux.org/ | Alles over Linux --------------------------------------------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
