> 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]>
