Yes, I was assuming that the manager application was enabled and accessible. Your original message did not specify otherwise.

One option you have...

Look through the manager application source code to determine how it causes a context to be started/reloaded. Copy that functionality into a separate application (if possible). Because you control the names under which a context is deployed, you simply have to have the student authenticate in this application and you can determine (through database, xml file, or property file) which context to start/reload.

Variation on the above...

Write the application to handle requests for reloading a context with the same process as above. But instead of hosting the functionality of starting/reloading a context, construct a request that include authentication on the server-side to get the manager application to start/reload the application. For example...

/reloader/SignOnForm.jsp

...shows a simple form which accept the student's username and password. action goes to...

/reloader/RequestReloadServlet

...which authenticates the student, throwing them back to the previous page if they fail. If they successfully authenticate, construct an HTTP request that includes authentication for the manager application. From the server, open the socket to localhost on port 8080, pass the request "GET /manager/html/reload?path=/myapp" along with the appropriate authentication data (BASIC or DIGEST) so you don't get a forbidden error.

Users can then reload their own context without knowing the manager application password.

If you want, you can hire me to write this for you. :-)

Another option I've heard of...

Schedule a UNIX cron task (or Windows Server "at" task) which stops Tomcat every hour on the hour. Schedule a second UNIX cron task (or Windows Server "at" task) that starts Tomcat every hour in the fourth minute of the hour. That way, students experience a maximum of one hour of downtime.

One last recommendation...

Teach the students how to validate their web.xml file against the DTD outside of Tomcat so that they are less likely to end up publishing a bunged web.xml file.



At 18:40 2003-02-05 -0500, you wrote:
That is assuming the manager application is enabled.  I was hoping for more
of an internal solution that Tomcat can do itself.  This is being used in an
educational environment and everytime a student blows up his context, he/she
shouldnt have to run to the prof to reload the application...

Kevin
----- Original Message -----
From: "Sean Dockery" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Wednesday, February 05, 2003 6:38 PM
Subject: Re: Web.xml mistake results in <Context> unavailable !?


> One of the following should work...
>
> http://localhost:8080/manager/html/start?path=/yourwebapp
>
> or
>
> http://localhost:8080/manager/html/reload?path=/yourwebapp
>
> This will prompt the Tomcat manager application to either start or reload
> your application.
>
> At 17:59 2003-02-05 -0500, you wrote:
> >In Tomcat 4.1.18, i have several different contexts each with a
> >corresponding WEB-INF hierarchy and web.xml. Now, if I make a mistake in
> >the web.xml like i forget to end a </servlet> tag, it says that there is
a
> >parse error and then "Marking this application unavailable due to
previous
> >error(s)" and I cannot use the context ever again until the server
> >restarts. How can i fix this so the context gets checkd again at some
point?
> >
> >Kevin
>
> Sean Dockery
> [EMAIL PROTECTED]
> Certified Java Web Component Developer
> Certified Delphi Programmer
> SBD Consultants
> http://www.sbdconsultants.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Sean Dockery
[EMAIL PROTECTED]
Certified Java Web Component Developer
Certified Delphi Programmer
SBD Consultants
http://www.sbdconsultants.com



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to