Re: limits the access of upper directory

[reuben]

I have discovered that the best way to keep people from looking into higher 
directories is to create an index page for those directories. In fact, on 
websites I develope, every directory has an index page.  The directories into 
which  I do not wish people to look  I create one similar to this:
-
 
http://www.w3.org/TR/html4/loose.dtd"";>




  Index
  





 Have you lost your way? 
This link http://bac-portal.mc.vanderbilt.edu/";>"bac-portal" 
will help quide you.






You can change the anchor "http://bac-portal.mc.vanderbilt.edu";  to a URL you 
want.  Also "bac-portal" ,  can be changed to more accurately define where 
the visistor is going when they click on the link.

You could cut and paste the html between the above lines and it should work 
fine.

Reuben

http://www.irontediumhost.com/


On Friday 15 August 2003 11:41, Luo, Zhongjun wrote:
> Dear Sir/Madam:
>  
> I have used Tomcat to make a web site, please see:
> http://bac-portal.mc.vanderbilt.edu/BAC/BACWEB.jsp
> Would you please tell me how I can limit the access to whole name of this
> site only?
 For example. now people can access (by deleting /BACWEB.jsp):
> http://bac-portal.mc.vanderbilt.edu/BAC  where I have other sites
> developing.
 
> Thank you a lot for give me the convenience to built this web site. Tomcat
> is great.
 
> Zhongjun Luo, Ph.D. 
>  
> Research Assistant Professor
> Genetic Medicine Department
> Vanderbilt University Medical Center
> Nashville, TN 37232
>  
> 
>  


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

DO NOT REPLY [Bug 22478] - Ant manager deploy causing webapp to initialize twice

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22478

Ant manager deploy causing webapp to initialize twice





--- Additional Comments From [EMAIL PROTECTED]  2003-08-16 16:04 ---
Well, I see a log4j owned thread accessing a stopped classloader. The stack
trace is obvious enough. BTW, if you don't believe me, sorry, I don't care ;-)

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

Re: JSP 2.0 Jasper in Jetty 5

[Remy Maucherat]

Greg Wilkins wrote:
I've just started checking the integration of jasper from 5.0.7
in Jetty 5, and felt compelled to send a quick thank you note.
Integration has been totally painless and the results appear to
be a very fast and snappy!
Also the 2.0 features are very cool - I'll have to stop making
nasty remarks about JSPs!-)
So thanks again for jasper!  Good work guys!
(Is it some of the effects of my rants on the members list ?)

Anyway, a late thank you is a lot better than no thank you :) (the
Jasper in Tomcat 4.1 contained most of the useful refactorings; Jasper
for TC 5 merely builds on that and adds the useful features)
We'll need to do bugfixing now, of course.

Remy



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

DO NOT REPLY [Bug 22478] - Ant manager deploy causing webapp to initialize twice

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22478

Ant manager deploy causing webapp to initialize twice





--- Additional Comments From [EMAIL PROTECTED]  2003-08-16 16:02 ---
As I said, I will consider the deployment bug, not the classloader errors. Do
not bother reopening the bug.

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

DO NOT REPLY [Bug 22478] - Ant manager deploy causing webapp to initialize twice

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22478

Ant manager deploy causing webapp to initialize twice





--- Additional Comments From [EMAIL PROTECTED]  2003-08-16 16:00 ---
>log4j has no buisness accessing anything from a thread outside of the control of
>the container after the web application shutdown.

Like I said before, Log4j is completely and utterly shut down.  All thread are
stopped.  So, I agree with you about Log4j having no business continuing threads
after application shutdown, but it just not the case that Log4j is actually
keeping any open threads after application shutdown, so that argument is
completely moot.

Jake

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

DO NOT REPLY [Bug 22478] - Ant manager deploy causing webapp to initialize twice

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22478

Ant manager deploy causing webapp to initialize twice

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2003-08-16 15:56 ---
Ok, I just tested with a completely fresh copy of Tomcat-4.1.27 and not only do
I not get exceptions upon the first deploy (
http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=7843 ), future
undeploys and deploys work perectly as well with no classloader errors or double
initialization.

Am I not making a pretty good case that there is something wrong with Tomcat5
and not my application if it works perfectly in a previous version of Tomcat? 
Its the same webapp, the only difference is Tomcat.

Reopening...

Jake

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

DO NOT REPLY [Bug 22478] - Ant manager deploy causing webapp to initialize twice

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22478

Ant manager deploy causing webapp to initialize twice





--- Additional Comments From [EMAIL PROTECTED]  2003-08-16 15:39 ---
I'll look at the first part, but this worked fine for me when I tried it; the
second part is invalid, and won't be resolved or looked into (this is bug 3888,
which I am tired to discuss, and is invalid).
log4j has no buisness accessing anything from a thread outside of the control of
the container after the web application shutdown.

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

DO NOT REPLY [Bug 22478] - Ant manager deploy causing webapp to initialize twice

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22478

Ant manager deploy causing webapp to initialize twice





--- Additional Comments From [EMAIL PROTECTED]  2003-08-16 15:24 ---
>The bug, if there's one, is maybe that your context XML should be removed on
>undeploy. This works fine for me (the WAR, expanded dir, and expanded XML are
>all removed on undeploy, as long as their names match).

My context configuration file (ccf) and everything else is removed just fine
upon undeploy.  I've verified this many times.  Also, Tomcat creates the ccf
from the one I supply in the .war file; META-INF/context.xml.  I assume that is
still correct to do with Tomcat5, right?  That's the way Tomcat4.1.xx worked. 
It must be right because it seems to extract it to the appropriate place and use it.

Besides, given that with a virgin Tomcat server and my app never having been
deployed there before, I still get exceptions upon the first deploy shown in the
stacktrace in the log file I attached.  Did you have a look at that yet?
http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=7843

This doesn't happen if I physically place the application there before Tomcat
has ever been started.  It only happens upon a manager app deployment, so I
think that pretty clearly implicates the manager application or some process it
uses.

>As for the "CL stopped" exception, well, log4j shouldn't have watchdog threads
>or similar stuff (or you should destroy your loggers manually when your
>application is stopped).

I actually do manually shutdown Log4j when the application is stopped...

See for yourself here...
http://cvs.apache.org/viewcvs/jakarta-log4j-sandbox/src/java/org/apache/log4j/servlet/InitContextListener.java?rev=1.7&content-type=text/vnd.viewcvs-markup

Here's the relevant code from there...

public void contextDestroyed(ServletContextEvent sce) {
ServletContext context = sce.getServletContext();

cleanupLog4j(context);
}

private void cleanupLog4j(ServletContext context) {
//shutdown this webapp's logger repository
context.log(
  "Cleaning up Log4j resources for context: "
  + context.getServletContextName() + "...");
context.log("Shutting down all loggers and appenders...");
org.apache.log4j.LogManager.shutdown();
context.log("Log4j cleaned up.");
}

Either way, the watchdog is in the process of configuring itself at startup. 
How is this a shutdown issue?  Additionally, although Log4j involved in the
stack trace, it doesn't seem to be the cause of the issue.  These are the lines
of significance...

java.lang.IncompatibleClassChangeError:
org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1251)

Please explain to me how the Log4j watchdog is responsible for an
IncompatibleClassChangeError in org.apache.xerces.jaxp.DocumentBuilderFactoryImpl?

And then, of course, there is the issue which I don't believe you addressed at
all which is the fact that the contextInitialized() in my servlet context
listener is running twice every time I do a deploy after an undeploy.


I'll leave this bug invalid for now, but I don't believe that is the case.  I
don't see where I am doing anything wrong?  Tomcat should be able to deal with
this deployment just fine, but it isn't.

Jake

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

DO NOT REPLY [Bug 22478] - Ant manager deploy causing webapp to initialize twice

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22478

Ant manager deploy causing webapp to initialize twice

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-08-16 14:18 ---
The bug, if there's one, is maybe that your context XML should be removed on
undeploy. This works fine for me (the WAR, expanded dir, and expanded XML are
all removed on undeploy, as long as their names match).
As for the "CL stopped" exception, well, log4j shouldn't have watchdog threads
or similar stuff (or you should destroy your loggers manually when your
application is stopped).

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

RE: [j-t-c] Thread problem in jk_uri_worker_map.c

[Marc Saegesser]

That makes sense.  The manipulations that map_uri_to_worker() does always
make the string shorter so there is no need to worry about the modifiable
string passed in being too short and needing reallocated.

Trying to fix this in the jk/common code is, I think, a waste of effort.

-- Marc
 

> -Original Message-
> From: Bill Barker [mailto:[EMAIL PROTECTED]
> Sent: Friday, August 15, 2003 7:16 PM
> To: Tomcat Developers List
> Subject: Re: [j-t-c] Thread problem in jk_uri_worker_map.c
> 
> The easiest solution would be to change the map_uri_to_worker contract to
> be
> that the uri parameter is modifiable.  Then Apache can dup it using the
> request's pool, it looks like IIS is doing this most of the time anyway,
> and
> Netscape isn't using map_uri_to_worker at all.  That leave Domino, which I
> don't really know.
> 
> 
> - Original Message -
> From: "Marc Saegesser" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, August 15, 2003 3:11 PM
> Subject: [j-t-c] Thread problem in jk_uri_worker_map.c
> 
> 
> I've run into a threading problem in
> /j-t-c/native/jk/common/jk_uri_worker_map.c.  The problem has been around
> for a long time, but I believe the changes checked in for version 1.15 on
> June, 27, 2003 made the problem worse.  I have only been able to reproduce
> the problem on multi-processor machines running under a fairly heavy load.
> Unfortunately, I don't have a good solution, yet.
> 
> The worker map contains a temp pool (jk_uri_worker_map.tp) that is used in
> the map_uri_to_worker() function.  The temp pool is used to store a copy
> of
> the incoming URI so that it can be altered to remove any jsessionid and to
> remove multiple adjacent / characters.
> 
> The problem is that this single pool is shared by all the worker threads
> so
> if multiple threads are executing map_uri_to_worker() simultaneously there
> is a chance that the pool will get corrupted.  This can happen in two
> ways.
> The jk_pool code is not thread safe so the internal state of the pool may
> be
> corrupted.  Second, the map_uri_to_worker() function always calls
> jk_pool_reset() after mapping the URI.  This means that if multiple URIs
> did
> get allocated into the pool without corruption, when the first thread
> finishes it will reset the pool.  This may not create a noticeable problem
> because the memory in the pools isn't overwritten by a reset.  If the
> other
> threads finish before another thread enters map_uri_to_worker() then
> nothing
> will fail.  However, if another thread does enter map_uri_to_worker() then
> its call to jk_pool_strdup() will overwrite some of the previous contents
> of
> the pool and really bad things may happen.
> 
> As I said, I don't have a solution, yet.  Any solution would have to be
> platform independent and also work with all the Web servers that use the
> JK
> plugin (e.g. Apache 1.3, Apache 2.0, ISAPI, Netscape, ...).
> 
> Suggestions?
> 
> -- Marc
> 
> 
> 
> -
> 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]

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardHostValve.java StandardWrapperValve.java

[remm]

remm2003/08/16 06:43:43

  Modified:catalina/src/share/org/apache/catalina/core
StandardHostValve.java StandardWrapperValve.java
  Log:
  - Fix client abort logging.
  - Log client abort exceptions as debug.
  
  Revision  ChangesPath
  1.9   +14 -7 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardHostValve.java
  
  Index: StandardHostValve.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardHostValve.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- StandardHostValve.java19 Jul 2003 14:33:29 -  1.8
  +++ StandardHostValve.java16 Aug 2003 13:43:43 -  1.9
  @@ -73,6 +73,10 @@
   import javax.servlet.ServletResponse;
   import javax.servlet.http.HttpServletRequest;
   import javax.servlet.http.HttpServletResponse;
  +
  +import org.apache.commons.logging.Log;
  +import org.apache.commons.logging.LogFactory;
  +
   import org.apache.catalina.Container;
   import org.apache.catalina.Context;
   import org.apache.catalina.Globals;
  @@ -108,6 +112,8 @@
   extends ValveBase {
   
   
  +private static Log log = LogFactory.getLog(StandardHostValve.class);
  +
   // - Instance Variables
   
   
  @@ -234,9 +240,10 @@
   
   // If this is an aborted request from a client just log it and return
   if (realError instanceof ClientAbortException ) {
  -log(sm.getString(
  -"standardHost.clientAbort",
  -((ClientAbortException)realError).getThrowable().getMessage()));
  +log.debug
  +(sm.getString("standardHost.clientAbort",
  +  ((ClientAbortException) realError).getThrowable()
  +  .getMessage()));
   return;
   }
   
  
  
  
  1.21  +17 -7 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapperValve.java
  
  Index: StandardWrapperValve.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapperValve.java,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- StandardWrapperValve.java 5 Aug 2003 18:41:50 -   1.20
  +++ StandardWrapperValve.java 16 Aug 2003 13:43:43 -  1.21
  @@ -71,6 +71,13 @@
   import javax.servlet.UnavailableException;
   import javax.servlet.http.HttpServletRequest;
   import javax.servlet.http.HttpServletResponse;
  +
  +import org.apache.commons.beanutils.PropertyUtils;
  +import org.apache.commons.logging.Log;
  +import org.apache.commons.logging.LogFactory;
  +
  +import org.apache.tomcat.util.buf.MessageBytes;
  +
   import org.apache.catalina.Context;
   import org.apache.catalina.Globals;
   import org.apache.catalina.HttpRequest;
  @@ -78,13 +85,10 @@
   import org.apache.catalina.Request;
   import org.apache.catalina.Response;
   import org.apache.catalina.ValveContext;
  +import org.apache.catalina.connector.ClientAbortException;
   import org.apache.catalina.deploy.FilterDef;
   import org.apache.catalina.util.StringManager;
   import org.apache.catalina.valves.ValveBase;
  -import org.apache.tomcat.util.buf.MessageBytes;
  -import org.apache.commons.beanutils.PropertyUtils;
  -import org.apache.commons.logging.Log;
  -import org.apache.commons.logging.LogFactory;
   
   /**
* Valve that implements the default basic behavior for the
  @@ -254,6 +258,10 @@
   filterChain.doFilter(hreq, hres);
   }
   hreq.removeAttribute(Globals.JSP_FILE_ATTR);
  +} catch (ClientAbortException e) {
  +hreq.removeAttribute(Globals.JSP_FILE_ATTR);
  +throwable = e;
  +exception(request, response, e);
   } catch (IOException e) {
   hreq.removeAttribute(Globals.JSP_FILE_ATTR);
   log(sm.getString("standardWrapper.serviceException",
  @@ -304,8 +312,10 @@
   }
   } while (rootCauseCheck != null);
   
  -log(sm.getString("standardWrapper.serviceException",
  - wrapper.getName()), rootCause);
  +if (!(rootCause instanceof ClientAbortException)) {
  +log(sm.getString("standardWrapper.serviceException",
  + wrapper.getName()), rootCause);
  +}
   throwable = e;
   exception(request, response, e);
   } catch (Throwable e) {
  
  
  

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

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 OutputBuffer.java

[remm]

remm2003/08/16 06:40:51

  Modified:catalina/src/share/org/apache/coyote/tomcat5
OutputBuffer.java
  Log:
  - Fix client abort logging.
  - Throw a client abort when an IOException occurs when writing bytes.
  
  Revision  ChangesPath
  1.4   +10 -1 
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/OutputBuffer.java
  
  Index: OutputBuffer.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/OutputBuffer.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- OutputBuffer.java 30 May 2003 17:00:29 -  1.3
  +++ OutputBuffer.java 16 Aug 2003 13:40:51 -  1.4
  @@ -75,6 +75,8 @@
   
   import org.apache.coyote.Response;
   
  +import org.apache.catalina.connector.ClientAbortException;
  +
   
   /**
* The buffer used by Tomcat response. This is a derivative of the Tomcat 3.3
  @@ -386,7 +388,14 @@
   if (cnt > 0) {
   // real write to the adapter
   outputChunk.setBytes(buf, off, cnt);
  -coyoteResponse.doWrite(outputChunk);
  +try {
  +coyoteResponse.doWrite(outputChunk);
  +} catch (IOException e) {
  +// An IOException on a write is almost always due to
  +// the remote client aborting the request.  Wrap this
  +// so that it can be handled better by the error dispatcher.
  +throw new ClientAbortException(e);
  +}
   }
   
   }
  
  
  

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

DO NOT REPLY [Bug 22477] - Modifying classes in WEB-INF/classes causes reloadable="true" to crash

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22477

Modifying classes in WEB-INF/classes causes reloadable="true" to crash

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-08-16 13:05 ---
This looks similar to the webapp reloading bug (bug 22096). Did you not read on
the download page about the hotfix that was available ?

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

DO NOT REPLY [Bug 22477] - Modifying classes in WEB-INF/classes causes reloadable="true" to crash

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22477

Modifying classes in WEB-INF/classes causes reloadable="true" to crash

[EMAIL PROTECTED] changed:

   What|Removed |Added

 OS/Version|Solaris |All
   Platform|Sun |All

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

DO NOT REPLY [Bug 22477] - Modifying classes in WEB-INF/classes causes reloadable="true" to crash

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22477

Modifying classes in WEB-INF/classes causes reloadable="true" to crash

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Priority|Other   |High
Summary|Modifying classes in WEB-   |Modifying classes in WEB-
   |INF/classes causes Exception|INF/classes causes
   ||reloadable="true" to crash



--- Additional Comments From [EMAIL PROTECTED]  2003-08-16 12:39 ---
I just did two default installs of Tomcat on WinXP (jsdk build 1.4.1_03-b02):

4.1.24 - Reloadable="true" worked great
4.1.27 - reloadable="true" made tomcat crash

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