Re: shell connector

2002-01-31 Thread Oto Buchta

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

2002-01-31 Thread Craig R. McClanahan



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)

2002-01-22 Thread Alan Newberger

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

2002-01-11 Thread Armijn Hemel

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

2002-01-11 Thread Creighton Kirkendall





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

2002-01-11 Thread Alan Newberger

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

2002-01-11 Thread Creighton Kirkendall

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

2002-01-11 Thread Craig R. McClanahan



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

2002-01-11 Thread Craig R. McClanahan



 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

2002-01-11 Thread Alan Newberger

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

2002-01-10 Thread Armijn Hemel

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

2002-01-10 Thread Micael Padraig Og mac Grene

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

2002-01-10 Thread Craig R. McClanahan



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]