Re: shell connector
Dne pá 11. leden 2002 15:05 Armijn Hemel napsal(a): 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'. I think you should rather write a new Midnight Commander Virtual File System. Each .war file should be a directory, which contains the structure of files from the .war with some additional virtual executable files - stop.sh, start.sh, deply.sh,... Everything should be done only using some utilities, such as grep and sed and, of course, wget. -- Oto 'tapik' Buchta -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: shell connector
On Thu, 31 Jan 2002, Oto Buchta wrote: Date: Thu, 31 Jan 2002 14:58:48 +0100 From: Oto Buchta [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: shell connector Dne pá 11. leden 2002 15:05 Armijn Hemel napsal(a): 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'. In the nightly builds of Tomcat 4, there are some custom Ant tasks available that interact with the Manager webapp. Among other things, these tasks give you scriptable control over installing, reloading, and removing webapps. In the version of the docs included with the nightly build, these are documented on the Manager App How-To page, and in the Application Developer's Guide. http://localhost:8080/tomcat-docs/manager-howto.html http://localhost:8080/tomcat-docs/appdev/ Now, you can say things like ant install or ant reload, either from the command line or in a shell script, and the corresponding manager commands will be executed immediately. Although the Ant tasks are not shipped with Tomcat 4.0.x, they should be compatible with it -- simply install the server/lib/catalina-ant.jar file from a current nightly build into your $ANT_HOME/lib directory to make them available. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
StandardWrapper patch (was RE: shell connector)
Finally got around to packages my changes as a patch to the HEAD. As previously discussed, it should be sufficient for a servlet to implement ContainerServlet and for the class to be placed in the server/lib directory for it to load and initialize correctly (in a Context where privileged is true). This is currently not the case, because in the current implementation being placed in the server/lib directory is not sufficient for the servlet to be loaded by the catalina class loader. The attached StandardWrapper patch resolves this issue by attempting to load the servlet class in the catalina class loader if the context is privileged. 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: Alan Newberger Sent: Friday, January 11, 2002 1:52 PM To: Tomcat Developers List Subject: RE: shell connector thanks for your reply, I still feel there is a problem with ContainerServlets from arbitrary packages even when placed in $CATALINA_HOME/server/lib, see below... From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] I committed some Ant custom tasks yesterday that talk to Manager ... they might be useful to you. I'll check them out, thanks. So that one can write servlet-based services that need access to Catalina internals. Existing examples include: * Manager servlet (needs to install, remove, and reload webapps) * Invoker servlet (needs to create new Wrapper instances on the fly) * Administration servlet (will provide web-based user interface for updating pretty much all of the things in server.xml). The third thing is in the admin webapp in the HEAD branch. That also sounds really useful, I'm going to have to take a close look at the HEAD branch :) Hopefully it's capable of persisting changes back into server.xml... In order to execute a ContainerServlet that has access to the internals of Tomcat 4, the following rules must all be followed: * Your servlet must implement the org.apache.catalina.ContainerServlet interface. * Your servlet, and all the code it depends on, must be loaded from the server classloader. That means it needs to be installed as unpacked classes under $CATALINA_HOME/server/classes or in JAR files in $CATALINA_HOME/server/lib. (Classes in common/classes and common/lib are also visible to these components.) No changes to Tomcat code, or to standard server.xml settings, are required. IF a servlet which implements ContainerServlet is loaded by the Catalina class loader, everything will work fine, i.e. it will have its 'setWrapper()' command called by StandardWrapper.load(). The problem is in the way StandardWrapper decides which classloader to use to load the servlet. It uses its private 'isContainerServlet(string)' method, which only looks at the String representation of the className and checks if it starts with 'org.apache.catalina'. So, if I have a servlet implementing ContainerServlet in some package, say 'com.foo.servlets', and put it in a jar $CATALINA_HOME/server/lib, and create some webapp with a web.xml with com.foo.servlets.SomeContainerServlet as a 'server-class' for a servlet, things will still fail. The StandardWrapper.isContainerServlet(string classname) method will return false, so the StandardWrapper.load() method will try to load the class from the webapp classloader, which of course will not find the class since it is not in the webapp classpath. You can put the com.foo.servlets.SomeContainerServlet in the common/lib folder and it will load correctly, but things will break because no catalina classes will be visible to it (an object instance cannot see other objects loaded in _child_ classloaders, only _parent_ classloaders). The solution to this isn't trivial -- you want all ContainerServlets to be loaded in the catalina classloader, but how do you know whether a servlet is a ContainerServlet by its classname alone, before actually loading it and doing something like 'instanceof' or 'isAssignableFrom()'? I'm sure this was why the StandardWrapper.isContainerServlet() method was written but it just doesn't do the right thing. I think the way to a nicer solution is through the 'privileged' attribute for a Context in servlet.xml (evaluated in ServletWrapper via the isServletAllowed() function). I suggest that if a Context is designated as privileged, the context's wrapper should attempt to load servlets via the catalina classloader. If the class isn't found, catch the exception and attempt to load it via the webapp classloader. If the class is loaded, check if it implements ContainerServlet; if so, call setWrapper() on it and continue, if not destroy the class object and attempt to load
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]
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]
RE: shell connector
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
RE: shell connector
I think that you could use the Rhino shell to be this shell. You would have to write an initializer so that all of the command objects that you wanted to work on where available. This would fit nicely with some of my ideas on how to wrap different commands. You could simply use the HTTP connection class in initialization to execute the commands. You would have to write a script that ran the initializer before you return the shell to the user. Bellow is some rhino code that I think could initialize the reload web app command. This is vary basic it does not take authentication or error handling into account. It is just to illustrate the point. I do not know rhino that well, I just started playing today. defineClass(java.net.URL); defineClass(java.net.HTTPConnectionClass); server=localhost:8080; function reload(webapp) { url=new URL(http://+server+/manager/reload?path=+webapp); conn=url.OpenConnection(); // code to return the results. // I think a wrapper for the connection // object is probably required to handle // exception well. } Creighton Kirkendall -Original Message- From: Alan Newberger [mailto:[EMAIL PROTECTED]] Sent: Friday, January 11, 2002 11:28 AM To: Tomcat Developers List Subject: RE: shell connector 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
RE: shell connector
On Fri, 11 Jan 2002, Creighton Kirkendall wrote: Date: Fri, 11 Jan 2002 12:39:08 -0500 From: Creighton Kirkendall [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: 'Tomcat Developers List' [EMAIL PROTECTED] Subject: RE: shell connector I think that you could use the Rhino shell to be this shell. You would have to write an initializer so that all of the command objects that you wanted to work on where available. This would fit nicely with some of my ideas on how to wrap different commands. You could simply use the HTTP connection class in initialization to execute the commands. You would have to write a script that ran the initializer before you return the shell to the user. Bellow is some rhino code that I think could initialize the reload web app command. This is vary basic it does not take authentication or error handling into account. It is just to illustrate the point. I do not know rhino that well, I just started playing today. defineClass(java.net.URL); defineClass(java.net.HTTPConnectionClass); server=localhost:8080; function reload(webapp) { url=new URL(http://+server+/manager/reload?path=+webapp); conn=url.OpenConnection(); // code to return the results. // I think a wrapper for the connection // object is probably required to handle // exception well. } Creighton Kirkendall You might also be amused by some Ant tasks for all the basic Manager servlet functions that I committed to the HEAD branch yesterday. Now you can do things like install and reload apps directly from your build scripts. Docs are on the manager-howto.html page in last night's nightly build. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: shell connector
From: Alan Newberger [mailto:[EMAIL PROTECTED]] 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. I committed some Ant custom tasks yesterday that talk to Manager ... they might be useful to you. 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? Yes. if so, why publicize such an interface?). So that one can write servlet-based services that need access to Catalina internals. Existing examples include: * Manager servlet (needs to install, remove, and reload webapps) * Invoker servlet (needs to create new Wrapper instances on the fly) * Administration servlet (will provide web-based user interface for updating pretty much all of the things in server.xml). The third thing is in the admin webapp in the HEAD branch. 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 :) In order to execute a ContainerServlet that has access to the internals of Tomcat 4, the following rules must all be followed: * Your servlet must implement the org.apache.catalina.ContainerServlet interface. * Your servlet, and all the code it depends on, must be loaded from the server classloader. That means it needs to be installed as unpacked classes under $CATALINA_HOME/server/classes or in JAR files in $CATALINA_HOME/server/lib. (Classes in common/classes and common/lib are also visible to these components.) No changes to Tomcat code, or to standard server.xml settings, are required. Trying to load a Container servlet in a standard webapp will fail, because the org.apache.catalina.* classes cannot be loaded through the webapp class loader (for security reasons). -alan Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: shell connector
thanks for your reply, I still feel there is a problem with ContainerServlets from arbitrary packages even when placed in $CATALINA_HOME/server/lib, see below... From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] I committed some Ant custom tasks yesterday that talk to Manager ... they might be useful to you. I'll check them out, thanks. So that one can write servlet-based services that need access to Catalina internals. Existing examples include: * Manager servlet (needs to install, remove, and reload webapps) * Invoker servlet (needs to create new Wrapper instances on the fly) * Administration servlet (will provide web-based user interface for updating pretty much all of the things in server.xml). The third thing is in the admin webapp in the HEAD branch. That also sounds really useful, I'm going to have to take a close look at the HEAD branch :) Hopefully it's capable of persisting changes back into server.xml... In order to execute a ContainerServlet that has access to the internals of Tomcat 4, the following rules must all be followed: * Your servlet must implement the org.apache.catalina.ContainerServlet interface. * Your servlet, and all the code it depends on, must be loaded from the server classloader. That means it needs to be installed as unpacked classes under $CATALINA_HOME/server/classes or in JAR files in $CATALINA_HOME/server/lib. (Classes in common/classes and common/lib are also visible to these components.) No changes to Tomcat code, or to standard server.xml settings, are required. IF a servlet which implements ContainerServlet is loaded by the Catalina class loader, everything will work fine, i.e. it will have its 'setWrapper()' command called by StandardWrapper.load(). The problem is in the way StandardWrapper decides which classloader to use to load the servlet. It uses its private 'isContainerServlet(string)' method, which only looks at the String representation of the className and checks if it starts with 'org.apache.catalina'. So, if I have a servlet implementing ContainerServlet in some package, say 'com.foo.servlets', and put it in a jar $CATALINA_HOME/server/lib, and create some webapp with a web.xml with com.foo.servlets.SomeContainerServlet as a 'server-class' for a servlet, things will still fail. The StandardWrapper.isContainerServlet(string classname) method will return false, so the StandardWrapper.load() method will try to load the class from the webapp classloader, which of course will not find the class since it is not in the webapp classpath. You can put the com.foo.servlets.SomeContainerServlet in the common/lib folder and it will load correctly, but things will break because no catalina classes will be visible to it (an object instance cannot see other objects loaded in _child_ classloaders, only _parent_ classloaders). The solution to this isn't trivial -- you want all ContainerServlets to be loaded in the catalina classloader, but how do you know whether a servlet is a ContainerServlet by its classname alone, before actually loading it and doing something like 'instanceof' or 'isAssignableFrom()'? I'm sure this was why the StandardWrapper.isContainerServlet() method was written but it just doesn't do the right thing. I think the way to a nicer solution is through the 'privileged' attribute for a Context in servlet.xml (evaluated in ServletWrapper via the isServletAllowed() function). I suggest that if a Context is designated as privileged, the context's wrapper should attempt to load servlets via the catalina classloader. If the class isn't found, catch the exception and attempt to load it via the webapp classloader. If the class is loaded, check if it implements ContainerServlet; if so, call setWrapper() on it and continue, if not destroy the class object and attempt to load it in the webapp classloader. This is a bit more expensive way of loading classes than what is done now, but if only performed in Contexts marked 'privileged', most Context will be unaffected and privileged Contexts would actually work :) I'm fairly sure I'm right about this, I've read the code pretty carefully and tested out the above behavior (i.e. I've previously tried doing the two things you outline as necessary above and things failed, it was a mystery until I delved into StandardWrapper source). I'd be happy to code up these proposed changes into StandardWrapper if you're interested. -alan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
shell connector
hi, 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)? 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]
Re: shell connector
At 06:55 PM 1/10/02 +0100, Armijn Hemel wrote: hi, 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)? armijn -- Writing a UNIX like shell is pretty straight-forward, armijn. Use a command design pattern and have your class names and constructor parameters equal the commands, options and targets you want. Do something like what is done with JNDI by Flanagan, Farley, Crawford and Magnusson in Java Enterprise in a Nutshell (O'Reilly), Ch. 6, The Naming Shell Application, and convert it for the web. -- micael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: shell connector
On Thu, 10 Jan 2002, Armijn Hemel wrote: Date: Thu, 10 Jan 2002 18:55:24 +0100 From: Armijn Hemel [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: shell connector hi, 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. armijn Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]