PATCH: Out-of-box build apache-tomcat-5.5.1[56]-src fix
Dear Developers, When following the build instructions at http://tomcat.apache.org/tomcat-5.5-doc/building.html I needed to make a couple of fixes to get it to build. Please accept this patch to correct the build errors that occur when following the instructions. --- build.xml~ 2006-03-13 12:22:25.0 + +++ build.xml 2006-03-13 12:22:25.0 + @@ -26,7 +26,7 @@ - + --- build/build.xml~2006-03-13 12:35:38.0 + +++ build/build.xml 2006-03-13 12:35:38.0 + @@ -29,7 +29,7 @@ - + ... Thanks -- Darryl L. Miles - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
WIN32 anti-resource-locking support in 5.5.x, would a back port be acceptable ?
What is the chance of getting this feature supported in 5.0.x or 4.x to help developers using the WIN32 platform under an IDE ? I'm not asking someone to do it, I can investigate and spend some time on it, but I'd like to understand the on going maintenance implications that has for you guys and me. What would the arguments be for / against accepting patches to back port this feature ? If against would it be feasible to reliably support this type of modification as external addon by dumping files into a classes directory to override distribution behavior ? When I say reliably are there fairly solid internal interfaces to work to ? Google found http://forum.springframework.org/showthread.php?t=19516 on a related thread that Costin explained the mechanics of the situation. Is it possible to see (even for a split second) a locked .class file in the WEB-INF/classes directory (the thread explains the trick is only used on resources inside jars) and if this is the case I think an IDE driven environment on WIN32 is able to hit this problem frequently. Are there any unwanted side effects to using it, the documentation states there are, at http://tomcat.apache.org/faq/windows.html there are details. Is there a technical reason / argument not to have the JSP reload side effect, if re-compilation is necessary for the temp/ dir copy to be deleted/replaced, if thats not possible then create a random filename and re-map that resource to that new file (requires class loader support). I appreciate that some of this stuff is pure bloat in a production environment, is there a simple way to keep it out of the core distribution and put it into some sort of developer support addon package cleanly. I want development to be a dream but production to be stable. RFC -- Darryl L. Miles - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RFC: Commonly occuring problems with integrated IDE development <-> test cycle?
.log4j.Category.forcedLog(Category.java:379) at org.apache.log4j.Category.log(Category.java:844) at org.apache.commons.logging.impl.Log4JLogger.error(Log4JLogger.java:193) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3673) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4104) at org.apache.catalina.core.StandardContext.reload(StandardContext.java:2930) at org.apache.catalina.loader.WebappLoader.backgroundProcess(WebappLoader.java:403) at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1276) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1568) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1577) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1577) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1557) at java.lang.Thread.run(Thread.java:595) 25-Oct-2005 03:13:34 org.apache.catalina.core.StandardContext reload INFO: Reloading this Context has started DEBUG 03:13:34,128 (ApplicationLifecycleListener.java:contextDestroyed:36) -contextDestroyed on "foo" 25-Oct-2005 03:13:34 org.apache.catalina.loader.WebappClassLoader loadClass INFO: Illegal access: this web application instance has been stopped already. Could not load org.apache.log4j.spi.ThrowableInformation. The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact. 25-Oct-2005 03:13:34 org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor processChildren SEVERE: Exception invoking periodic operation: java.lang.ThreadDeath at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1221) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1181) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at org.apache.log4j.spi.LoggingEvent.(LoggingEvent.java:145) at org.apache.log4j.Category.forcedLog(Category.java:379) at org.apache.log4j.Category.log(Category.java:844) at org.apache.commons.logging.impl.Log4JLogger.error(Log4JLogger.java:193) at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:3714) at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4283) at org.apache.catalina.core.StandardContext.reload(StandardContext.java:2924) at org.apache.catalina.loader.WebappLoader.backgroundProcess(WebappLoader.java:403) at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1276) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1568) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1577) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1577) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1557) at java.lang.Thread.run(Thread.java:595) -- Darryl L. Miles - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
