Fixing the tomcat-catalina Gump failure
The Gump build for tomcat-catalina started failing on 6/3. I sent a patch to fix it to this list on 6/4, the same day that Remy commented that this breakage was an unacceptable situation for tomcat-dev. Later that day, Bill Barker commented that the patch worked for him. Now, on 6/12, it appears that the unacceptable situation is still being tolerated. I hate to see Gump builds failing when I know the failures can be easily corrected. If there is something else I can do, beyond submitting a patch, to help resolve this, please let me know. Otherwise, it would be nice if one of the committers could apply the patch and make Gump happy again. Thanks! -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fixing the tomcat-catalina Gump failure
What is breaking in Gump is Tomcat-4.1.x. My patch fixed Tomcat 5.x. If Remy (as RM) is happy with using rc1 in TC 4.1.x (and no other committers object), I've got no problem porting the patch. The only reason that I've not done it is that there hasn't been a decision on the list as to the version of FileUpload to target for 4.1.x. - Original Message - From: Martin Cooper [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 12, 2003 11:47 PM Subject: Fixing the tomcat-catalina Gump failure The Gump build for tomcat-catalina started failing on 6/3. I sent a patch to fix it to this list on 6/4, the same day that Remy commented that this breakage was an unacceptable situation for tomcat-dev. Later that day, Bill Barker commented that the patch worked for him. Now, on 6/12, it appears that the unacceptable situation is still being tolerated. I hate to see Gump builds failing when I know the failures can be easily corrected. If there is something else I can do, beyond submitting a patch, to help resolve this, please let me know. Otherwise, it would be nice if one of the committers could apply the patch and make Gump happy again. Thanks! -- Martin Cooper - 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]
Re: Fixing the tomcat-catalina Gump failure
Bill Barker wrote: What is breaking in Gump is Tomcat-4.1.x. My patch fixed Tomcat 5.x. If Remy (as RM) is happy with using rc1 in TC 4.1.x (and no other committers object), I've got no problem porting the patch. The only reason that I've not done it is that there hasn't been a decision on the list as to the version of FileUpload to target for 4.1.x. I don't think there's any alternative to upgrading ;-) +1 for upgrading. Sorry, I had forgotten a bit TC 4.1.x as far as commons-fileupload is concerned. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20738] New: - Session variable returns null in non-SSL page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20738. 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=20738 Session variable returns null in non-SSL page Summary: Session variable returns null in non-SSL page Product: Tomcat 4 Version: 4.1.24 Platform: Other OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I am transporting the webapp which was running on IIS+Tomcat3.x to TOmcat4.1.24. I have used SSL session using HTTPS for login and some user specific jsp pages. I maintains session using HttpSession. there are some non-SSL HTTP pages where i access session variables. I am getting the session variable which i set in login page after successful login as null. THis is happening in Tomcat4.1.24 version. I t was working fine with Tomcat3.2 version. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20738] - Session variable returns null in non-SSL page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20738. 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=20738 Session variable returns null in non-SSL page [EMAIL PROTECTED] changed: What|Removed |Added Summary|Session variable returns|Session variable returns |null in non-SSL page|null in non-SSL page --- Additional Comments From [EMAIL PROTECTED] 2003-06-13 10:22 --- I cant have my full webapp in ssl session as it consumes resources. so i have to have some non-ssl web pages also. in these pages i need some session variables for example user name to display in the page. I have also tested folowing. If i set my session variable in non-ssl page i can access that session variable in both http https pages , where is if i set my session variable in ssl page i can access that session variable ONLY in SSL page. in non-ssl page it returns null. here are jsp code . First begin by accessing first.jsp through HTTP //first.jsp/ % session.setAttribute(Name,Value); % a href=https://localhost/examples/test/second.jsp;next/a /end of first.jsp/ //second.jsp/ % out.println(o/p from second.jsp :+(String)session.getAttribute(Name)); % br a href=http://localhost/examples/test/third.jsp;next/a /end of second.jsp/ //third.jsp/ % out.println(o/p from third.jsp :+(String)session.getAttribute(Name)); % br a href=first.jspnext/a /end of third.jsp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem displaying accents in Tomcat
Hi everyone, I have a problem with tomcat 4.1.24 with displaying vowels with accents and special spanish characters such as ntilde;. The scenario is the following : - I have deployed a servlet application that accesses data on a MySQL database. The problem is that when displaying characters with accents or ntilde; they all appear as a question mark. But the fact is that they are correctly saved on the database, so the problem is not with the JDBC. - I am using Tomcat as a Stand-alone so, is acting as web server also. - The fact is that the same application has been running on Apache (Apache-tomcat) with no problem on displaying any character, but now I need it to be running directly on Tomcat as a web server. Any idea on what can be the problem, I am a bit desperate with this, I've been trying to find the solution for a long time now Thanks very much in advance Manuel [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem displaying accents in Tomcat
This is really one for tomcat-user, but seeing as it's quiet... I assume you HAD Apache (HTTP Server) and Tomcat hooked up with mod_jk (or similar) previously and NOW you've just got Tomcat (4.1.24) on its own. Given that this is the case then something else has changed and is causing this problem. What character encoding are you using in you web app? Is it the same server machine that WAS working with Apache HTTP Server and Tomcat? What OS are you running? -Original Message- From: Manuel Gonzalez [mailto:[EMAIL PROTECTED] Sent: 13 June 2003 12:17 To: [EMAIL PROTECTED] Subject: Problem displaying accents in Tomcat Hi everyone, I have a problem with tomcat 4.1.24 with displaying vowels with accents and special spanish characters such as ntilde;. The scenario is the following : - I have deployed a servlet application that accesses data on a MySQL database. The problem is that when displaying characters with accents or ntilde; they all appear as a question mark. But the fact is that they are correctly saved on the database, so the problem is not with the JDBC. - I am using Tomcat as a Stand-alone so, is acting as web server also. - The fact is that the same application has been running on Apache (Apache-tomcat) with no problem on displaying any character, but now I need it to be running directly on Tomcat as a web server. Any idea on what can be the problem, I am a bit desperate with this, I've been trying to find the solution for a long time now Thanks very much in advance Manuel [EMAIL PROTECTED] - 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]
Re: Problem displaying accents in Tomcat
Yes, your asumptsion is right. I had apache before hooked to Tomcat. Now the application is running with Tomcat 4.1.24 on its own. The OS is linux, SUSE distro. The character encoding it should be the default one I haven't specified any. So it should be (iso-8859-1) ? Thanks Manuel Andy Chapman wrote: This is really one for tomcat-user, but seeing as it's quiet... I assume you HAD Apache (HTTP Server) and Tomcat hooked up with mod_jk (or similar) previously and NOW you've just got Tomcat (4.1.24) on its own. Given that this is the case then something else has changed and is causing this problem. What character encoding are you using in you web app? Is it the same server machine that WAS working with Apache HTTP Server and Tomcat? What OS are you running? -Original Message- From: Manuel Gonzalez [mailto:[EMAIL PROTECTED] Sent: 13 June 2003 12:17 To: [EMAIL PROTECTED] Subject: Problem displaying accents in Tomcat Hi everyone, I have a problem with tomcat 4.1.24 with displaying vowels with accents and special spanish characters such as ntilde;. The scenario is the following : - I have deployed a servlet application that accesses data on a MySQL database. The problem is that when displaying characters with accents or ntilde; they all appear as a question mark. But the fact is that they are correctly saved on the database, so the problem is not with the JDBC. - I am using Tomcat as a Stand-alone so, is acting as web server also. - The fact is that the same application has been running on Apache (Apache-tomcat) with no problem on displaying any character, but now I need it to be running directly on Tomcat as a web server. Any idea on what can be the problem, I am a bit desperate with this, I've been trying to find the solution for a long time now Thanks very much in advance Manuel [EMAIL PROTECTED] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem displaying accents in Tomcat
Yes, your asumptsion is right. I had apache before hooked to Tomcat. Now the application is running with Tomcat 4.1.24 on its own. The OS is linux, SUSE distro. The character encoding it should be the default one I haven't specified any. So it should be (iso-8859-1) ? Thanks Manuel I've always used apache + tomcat and needed to add this to CATALINA_OPTS variable when executing tomcat so that it can display characters with tilde properly: CATALINA_OPTS=-Dfile.encoding=ISO8859_15 I use ISO8859_15 both in tomcat and in my database because it also supports euro character. Sergio. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem displaying accents in Tomcat
There are two issues with character encoding. Firstly the charset used by Jasper for jsp source files, this is set in Tomcat web.xml. The default is UTF-8 and will effect jsp source files with special characters. From what I gather this isn't the problem, and only really causes a problem with far-eastern charsets or where the OS does not support UTF-8. The second is the HTTP Content Type. If you don't set this in a jsp/servlet your text including unicode characters fetched from the db will not be displayed properly ie using non-unicode ascii charset. If you aren't setting the ContentType, you will need to either with a tag: %@ page contentType=text/html; charset=ISO-8859-1 % or code: % response.setContentType(text/html; charset=ISO-8859-1); % Why it worked before withou setting the content type I don't know, but I hope that setting the content type as above solves your problem. -Original Message- From: Manuel Gonzalez [mailto:[EMAIL PROTECTED] Sent: 13 June 2003 12:50 To: Tomcat Developers List Subject: Re: Problem displaying accents in Tomcat Yes, your asumptsion is right. I had apache before hooked to Tomcat. Now the application is running with Tomcat 4.1.24 on its own. The OS is linux, SUSE distro. The character encoding it should be the default one I haven't specified any. So it should be (iso-8859-1) ? Thanks Manuel Andy Chapman wrote: This is really one for tomcat-user, but seeing as it's quiet... I assume you HAD Apache (HTTP Server) and Tomcat hooked up with mod_jk (or similar) previously and NOW you've just got Tomcat (4.1.24) on its own. Given that this is the case then something else has changed and is causing this problem. What character encoding are you using in you web app? Is it the same server machine that WAS working with Apache HTTP Server and Tomcat? What OS are you running? -Original Message- From: Manuel Gonzalez [mailto:[EMAIL PROTECTED] Sent: 13 June 2003 12:17 To: [EMAIL PROTECTED] Subject: Problem displaying accents in Tomcat Hi everyone, I have a problem with tomcat 4.1.24 with displaying vowels with accents and special spanish characters such as ntilde;. The scenario is the following : - I have deployed a servlet application that accesses data on a MySQL database. The problem is that when displaying characters with accents or ntilde; they all appear as a question mark. But the fact is that they are correctly saved on the database, so the problem is not with the JDBC. - I am using Tomcat as a Stand-alone so, is acting as web server also. - The fact is that the same application has been running on Apache (Apache-tomcat) with no problem on displaying any character, but now I need it to be running directly on Tomcat as a web server. Any idea on what can be the problem, I am a bit desperate with this, I've been trying to find the solution for a long time now Thanks very much in advance Manuel [EMAIL PROTECTED] - 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] - 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]
Re: Fixing the tomcat-catalina Gump failure
+1 to port the fileupload patch to the Tomcat 4.1 branch Bill Barker wrote: What is breaking in Gump is Tomcat-4.1.x. My patch fixed Tomcat 5.x. If Remy (as RM) is happy with using rc1 in TC 4.1.x (and no other committers object), I've got no problem porting the patch. The only reason that I've not done it is that there hasn't been a decision on the list as to the version of FileUpload to target for 4.1.x. - Original Message - From: Martin Cooper [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 12, 2003 11:47 PM Subject: Fixing the tomcat-catalina Gump failure The Gump build for tomcat-catalina started failing on 6/3. I sent a patch to fix it to this list on 6/4, the same day that Remy commented that this breakage was an unacceptable situation for tomcat-dev. Later that day, Bill Barker commented that the patch worked for him. Now, on 6/12, it appears that the unacceptable situation is still being tolerated. I hate to see Gump builds failing when I know the failures can be easily corrected. If there is something else I can do, beyond submitting a patch, to help resolve this, please let me know. Otherwise, it would be nice if one of the committers could apply the patch and make Gump happy again. Thanks! -- Martin Cooper - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Fixing the tomcat-catalina Gump failure
Howdy, +1 to port the patch ;) Yoav Shapira Millennium ChemInformatics -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Friday, June 13, 2003 2:48 AM To: [EMAIL PROTECTED] Subject: Fixing the tomcat-catalina Gump failure The Gump build for tomcat-catalina started failing on 6/3. I sent a patch to fix it to this list on 6/4, the same day that Remy commented that this breakage was an unacceptable situation for tomcat-dev. Later that day, Bill Barker commented that the patch worked for him. Now, on 6/12, it appears that the unacceptable situation is still being tolerated. I hate to see Gump builds failing when I know the failures can be easily corrected. If there is something else I can do, beyond submitting a patch, to help resolve this, please let me know. Otherwise, it would be nice if one of the committers could apply the patch and make Gump happy again. Thanks! -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler TldLocationsCache.java
remm2003/06/13 09:50:41
Modified:jasper2/src/share/org/apache/jasper/compiler
TldLocationsCache.java
Log:
- Default to setting caches to false (rather than not), so that JAR locking does
not occur. IMO it is a far more sensible default value for TC 5.
Revision ChangesPath
1.19 +1 -1
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TldLocationsCache.java
Index: TldLocationsCache.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TldLocationsCache.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- TldLocationsCache.java14 Apr 2003 18:18:43 - 1.18
+++ TldLocationsCache.java13 Jun 2003 16:50:41 - 1.19
@@ -147,7 +147,7 @@
// Constructor and Initilizations
public TldLocationsCache(ServletContext ctxt) {
-this(ctxt, false);
+this(ctxt, true);
}
/** Constructor.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20752] New: - Soft links to jars in a webapp causes IllegalArgumentException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20752. 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=20752 Soft links to jars in a webapp causes IllegalArgumentException Summary: Soft links to jars in a webapp causes IllegalArgumentException Product: Tomcat 4 Version: 4.1.24 Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] For developement I have expanded my war file and replaced the jars in WEB-INF/lib with soft links because the jars are changing as I develop them. This causes Catalina to throw an IllegalArgumentException while starting up my webapp. The log output follows. I can provide a .war file on request. HostConfig[localhost]: Deploying web application directory colle-web StandardHost[localhost]: Installing web application at context path /colle-web from URL file:/ Users/dschultz/system/jakarta-tomcat-4.1.24/webapps/colle-web WebappLoader[/colle-web]: Deploying class repositories to work directory /Users/dschultz/ system/jakarta-tomcat-4.1.24/work/Standalone/localhost/colle-web WebappLoader[/colle-web]: Deploy JAR /WEB-INF/lib/colle-util.jar to /Users/dschultz/system/ jakarta-tomcat-4.1.24/webapps/colle-web/WEB-INF/lib/colle-util.jar WebappLoader[/colle-web]: Deploy JAR /WEB-INF/lib/colle-web.jar to /Users/dschultz/system/ jakarta-tomcat-4.1.24/webapps/colle-web/WEB-INF/lib/colle-web.jar WebappLoader[/colle-web]: Deploy JAR /WEB-INF/lib/jdom.jar to /Users/dschultz/system/jakarta- tomcat-4.1.24/webapps/colle-web/WEB-INF/lib/jdom.jar WebappLoader[/colle-web]: Deploy JAR /WEB-INF/lib/saxon.jar to /Users/dschultz/system/ jakarta-tomcat-4.1.24/webapps/colle-web/WEB-INF/lib/saxon.jar WebappLoader[/colle-web]: Deploy JAR /WEB-INF/lib/xerces.jar to /Users/dschultz/system/ jakarta-tomcat-4.1.24/webapps/colle-web/WEB-INF/lib/xerces.jar ContextConfig[/colle-web] Exception processing JAR at resource path /WEB-INF/lib/colle-web.jar javax.servlet.ServletException: Exception processing JAR at resource path /WEB-INF/lib/colle- web.jar at org.apache.catalina.startup.ContextConfig.tldScanJar(ContextConfig.java:930) at org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:868) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3567) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:821) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:579) at org.apache.catalina.core.StandardHostDeployer.install(StandardHostDeployer.java:307) at org.apache.catalina.core.StandardHost.install(StandardHost.java:772) at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:559) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:401) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:718) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:358) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1196) at org.apache.catalina.core.StandardHost.start(StandardHost.java:738) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347) at org.apache.catalina.core.StandardService.start(StandardService.java:497) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2190) at org.apache.catalina.startup.Catalina.start(Catalina.java:512) at org.apache.catalina.startup.Catalina.execute(Catalina.java:400) at org.apache.catalina.startup.Catalina.process(Catalina.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) - Root Cause - java.lang.IllegalArgumentException:
DO NOT REPLY [Bug 10026] - manager/stop and manager/remove
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10026. 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=10026 manager/stop and manager/remove --- Additional Comments From [EMAIL PROTECTED] 2003-06-13 18:14 --- A similar bug was fixed in Log4J. While it's arguable whether it's a struts bug, tomcat bug, or a windows bug, I thought I'd post the details to see if anyone has ideas on how tomcat can fix this. The bug (from what I understand) is that when dtd's are loaded from the jar (while running on windows), the jar is locked b/c the input stream for the dtd has not be properly closed. In log4j, this is fixed by using a custom EntityResolver to load the dtd. (the resolver makes a copy of the dtd input stream in memory and return the copied stream after closing the real input stream) references to this can be found in the log4j code, but this url from the barracuda project has a pretty good summary: http://barracuda.enhydra.org/software/cvs/cvsweb.cgi/Projects/EnhydraOrg/toolsT ech/Barracuda/WEB-INF/lib/log4j-1.2.7a.jar?rev=1.1content-type=text/x-cvsweb- markup the files of interest in log4j are: org/apache/log4j/xml/Log4jEntityResolver.java org/apache/log4j/xml/DOMConfigurator.java is there some way for tomcat to always use a custom EntityResolver if the system is windows? Something that may also be of interest: I've found that if I expand the jar and dump all the files into WEB- INF/classes, there are problems undeploy/removing the app - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10026] - manager/stop and manager/remove
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10026. 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=10026 manager/stop and manager/remove --- Additional Comments From [EMAIL PROTECTED] 2003-06-13 18:15 --- sorry, typo. that should read: I've found that if I expand the jar and dump all the files into WEB-INF/classes, there are NO problems undeploy/removing the app - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20758] New: - Memory Leak in Classloader/Manager deploy/undeploy
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20758. 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=20758 Memory Leak in Classloader/Manager deploy/undeploy Summary: Memory Leak in Classloader/Manager deploy/undeploy Product: Tomcat 4 Version: 4.1.24 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Webapps:Manager AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have found that after deploying and removing my application using tomcat manager a few times, the JVM throws an out of memory exception. I found the following posts on tomcat-dev/tomcat-user mail archives but did not see any bugzilla entries for it. POST 1 http://www.mail-archive.com/[EMAIL PROTECTED]/msg42351.html -- I believe I am seeing a memory leak that occurs when deploying or more precisely undeploying a web application through the Tomcat manager. I've done some analysis using a stripped down web application, JProbe, and code inspection. I would not presume to know the Tomcat source nor have done a complete and thorough analysis, but I would like to share my observations and more importantly, solicit feedback from the Tomcat user/development community. Environment: RedHat 8.0, JDK 1.4.1, Tomcat 4.1.21 Beta Synopsis of problem: We are deploying and undeploying our web applications through the Tomcat Manager. In the case of one of our web applications, redeploying 3-4 times resulted in an OutOfMemoryError in Tomcat's JVM. Initially, we thought this was due to several daemon Threads that were not Servlet lifecycle aware. But even after fixing these, we were still running out of memory. Suspecting that our classes were not being garbage collected (note the distinction between object garbage collection and class garbage collection) and might be pinned by classes that exist higher in the ClassLoader hierarchy (in common, shared, or possibly even server), I decided to try profiling using JProbe (http://java.quest.com/jprobe/jprobe.shtml) and a VERY simple web application. This web application is composed of a single Servlet that does nothing but allocate a 1,000,000 element byte array in its init() method and nulls it in its destroy() method. I deployed and undeployed several times running under JProbe's memory debugger and did observe a small memory leak of org.apache.* classes/instances. Analysis: These are the org.apache instances that do not appear to be garbage collected after a deploy/undeploy cycle: Class Count - org.apache.catalina.LifecycleListener[] 4 org.apache.catalina.Valve[] 1 org.apache.catalina.core.ApplicationContext 1 org.apache.catalina.core.ApplicationContextFacade 1 org.apache.catalina.core.NamingContextListener1 org.apache.catalina.core.StandardContext 1 org.apache.catalina.core.StandardContextMapper1 org.apache.catalina.core.StandardContextValve 1 org.apache.catalina.core.StandardPipeline 1 org.apache.catalina.deploy.ApplicationParameter[] 1 org.apache.catalina.deploy.NamingResources1 org.apache.catalina.deploy.SecurityConstraint[] 1 org.apache.catalina.deploy.FilterMap[]1 org.apache.catalina.loader.WebappClassLoader 1 org.apache.catalina.loader.WebappLoader 1 org.apache.catalina.session.StandardManager 1 org.apache.catalina.startup.ContextConfig 1 org.apache.catalina.util.LifecycleSupport 4 org.apache.commons.collections.LRUMap 1 org.apache.commons.collections.SequencedHashMap$Entry 6 org.apache.naming.NameParserImpl 2 org.apache.naming.NamingContext 3 org.apache.naming.NamingEntry 4 org.apache.naming.TransactionRef 1 org.apache.naming.resources.ImmutableNameNotFoundException1 org.apache.naming.resources.ProxyDirContext 1 org.apache.naming.resources.ProxyDirContext$CacheEntry5 org.apache.naming.resources.ResourceAttributes3 org.apache.naming.resources.WARDirContext 2
DO NOT REPLY [Bug 10026] - manager/stop and manager/remove
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10026. 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=10026 manager/stop and manager/remove --- Additional Comments From [EMAIL PROTECTED] 2003-06-13 18:35 --- I have specifically investigated this problem during the past few days, and can draw the same conclusions. There's unfortunately little or nothing that Tomcat can do. Here's what happens: - XML paser uses get resource to load the DTD - Tomcat returns a jar:file: URL, as the DTD is inside a JAR - XML parser does read from that without setting setUseCaches(false), so this causes the JAR to be locked until the VM is terminated Tomcat cannot do anything about it, unless we add custom code in getResource to handle non class resources (ex: we could extract the resource to teh work dir, and return a file URL to there). AFAIK, there's nothing which forbids that, so I'll experiment with doing that in TC 5. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20758] - Memory Leak in Classloader/Manager deploy/undeploy
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20758. 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=20758 Memory Leak in Classloader/Manager deploy/undeploy --- Additional Comments From [EMAIL PROTECTED] 2003-06-13 18:36 --- bug #11128 could be related (or the same) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 11128] - ServletContext memory leak
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11128. 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=11128 ServletContext memory leak --- Additional Comments From [EMAIL PROTECTED] 2003-06-13 18:38 --- bug#20758 may be related (or the same) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15672] - DBCP doesn't work on Tomcat 4.1.18 with Oracle JDBC driver
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15672. 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=15672 DBCP doesn't work on Tomcat 4.1.18 with Oracle JDBC driver --- Additional Comments From [EMAIL PROTECTED] 2003-06-13 21:07 --- In trying to make the move to automate my testing I have come up against the same problem. First some background. I am running Tomcat 4.1.18, Java 1.3.1, Win 2k classes12.jar, commons-collections.jar, commons-dbcp.jar, commons-pool are located in $TOMCAT_HOME/common/lib I am attempting to get automated testing running To do this was getting the ANT build to undeploy and then redeploy the war after it got created. In addition, I decided that it was more convenient to have the Test classes located in my app.war instead of a seperate war. Part of getting this dynamic undeploy/deploy cycle to work was removing the context from the server.xml. The reason I want to do this is I have 2 connection pools located there. In a dynamic deploy tomcat generates it's own context for the app. I found there were three ways I could do this. #1. put the connection pool into the GlobalNamingResources section of server.xml #2. create a $APP_NAME.xml file that contains the context of the app and put it into $TOMCAT_HOME/webapps. Both the Tomcat manager and Admin apps do this. #3. Possibly put the context info in the web.xml file for the app. I have tried both 1 and 2 and I am getting the java.sql.SQLException: Cannot load JDBC driver class 'null' error when the DBCP is accessed in both. Below are the relevant files for Option #2 WEB.XML- ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app display-nameTSR Application/display-name descriptionThis is the web configuration for the TSR application/description !-- SERVLET LISTINGS -- servlet servlet-nameTestServlet/servlet-name servlet-classnet.myco.myapp.servlets.TestServlet/servlet-class /servlet servlet servlet-nameControllerServlet/servlet-name servlet-classnet.myco.myapp.servlets.ControllerServlet/servlet-class /servlet servlet servlet-nameFileDownloadServlet/servlet-name servlet-classnet.myco.myapp.servlets.FileDownloadServlet/servlet- class /servlet servlet servlet-nameStartupServlet/servlet-name servlet-classnet.myco.myapp.servlets.StartupServlet/servlet-class load-on-startup1/load-on-startup /servlet !--servlet servlet-namelog4j-init/servlet-name servlet-classnet.myco.myapp.servlets.Log4jInit/servlet-class load-on-startup1/load-on-startup init-param param-namelog4j-init-file/param-name param-valueWEB-INF\classes\log4j.properties/param-value /init-param /servlet-- !-- integrate the testing -- servlet servlet-nameJUnitEETestServlet/servlet-name descriptionJUnitEE test runner/description servlet-classorg.junitee.servlet.JUnitEEServlet/servlet-class /servlet !-- SERVLET MAPPINGS -- servlet-mapping servlet-nameTestServlet/servlet-name url-pattern/test/url-pattern /servlet-mapping servlet-mapping servlet-nameStartupServlet/servlet-name url-pattern/startup/url-pattern /servlet-mapping servlet-mapping servlet-nameControllerServlet/servlet-name url-pattern/controller/url-pattern /servlet-mapping servlet-mapping servlet-nameFileDownloadServlet/servlet-name url-pattern/download/url-pattern /servlet-mapping !-- integrate the testing -- servlet-mapping servlet-nameJUnitEETestServlet/servlet-name url-pattern/TestServlet/*/url-pattern /servlet-mapping !-- JNDI resource for DB connection pool -- resource-ref description Resource reference to a factory for java.sql.Connection instances that may be used for talking to a particular database that is configured in the server.xml file. /description res-ref-name jdbc/oracle_myapp /res-ref-name res-type javax.sql.DataSource /res-type res-auth Container /res-auth /resource-ref !-- JNDI resource for DB connection pool -- resource-ref description Resource reference to a factory for java.sql.Connection instances that may be used for talking to a particular database that is configured in the server.xml file. /description res-ref-name jdbc/oracle_myco
DO NOT REPLY [Bug 20770] New: - Admin Tool removes workDir attribute from context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20770. 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=20770 Admin Tool removes workDir attribute from context Summary: Admin Tool removes workDir attribute from context Product: Tomcat 4 Version: 4.1.24 Platform: All OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Webapps:Administration AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If a workDir attribute has been manually added to server.xml configuration file, the next time the Administration Tool used used to modify any context, the workDir attribute is removed. Some IDE's reequire the workDir attribute to be set so that JSP's can be debugged. The current solution is to manually add the workDir back to server.xml each time the Administration Tool is used. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Servlets, Threading, and Memory
I'm experiencing a strange problem with a web application I'm developing under Tomcat 4.1.18 and am looking for information on how Tomcat handles threading and memory/variable scoping for servlets. I have a servlet that pulls data from a DB and generates graphs. On a given page sent the client browser, this servlet is called 3 times via image source tags: Example: img src=/wwwif-int/get.graphRW?ip=1.1.1.1report=Daily_Mbpsstart=12-JUN-03 img src=/wwwif-int/get.graphRW?ip=1.1.1.1report=Monthly_Mbpsstart=13-MAY-03 img src=/wwwif-int/get.graphRW?ip=1.1.1.1report=Yearly_Mbpsstart=13-JUN-02 These images take a while to make due to the number of data points in each graph. As I watch the page while it renders and logging that I've got in the graph servlet, I'm noticing two things: 1) There are only 2 threads spawned by Tomcat for each client (i.e. web browser in session with Tomcat) to run the graph servlet. I will typically get the first two images on the page. But, the third one fails to be rendered, and I don't see any traffic in the logs for a 3rd thread running the graph servlet. Is my browser only requesting 2 images from Tomcat at a time, or does Tomcat have a limit on the number of servlets/threads it will spawn for a given session? Or, is there something else I'm missing? 2) When called three times on one page, the graph servlet will return the wrong image for one of the graphs. For example, given the img src tags above, I'll get two Monthly graphs instead of a Daily and a Monthly. If I watch the log file, I see two threads working on generating the Monthly graph instead of one working on the Daily graph and one working on the Monthly graph. When single calls to the servlet are made, the right graph is returned each time. Am I bumping into a memory/variable scoping issue by making rapid, successive calls to the same servlet from one web client? It seems like the request parameters for the second graph (i.e. the Monthly one) are over writing the parameters for the first one. I wasn't sure, but these seemed like developer oriented questions since they deal with how Tomcat is running a servlet. Any help or pointers are greatly appreciated. Thanks, (John 3:16) Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 3888] - WebappClassLoader: Lifecycle error : CL stopped
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888. 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=3888 WebappClassLoader: Lifecycle error : CL stopped --- Additional Comments From [EMAIL PROTECTED] 2003-06-13 23:10 --- I'm seeing this error with Tomcat 4.1.24 (LE jdk14), but under what seems a somewhat different circumstance from what I'm seeing described here. I have a servlet that performs a rather lengthy action (from doPost())--it takes several minutes to complete. If I update the class while the doPost() is still in the midst of processing, I see my servlet's destroy method called, then see its init method called as it is reloaded. However the doPost method appears to continue to run, judging by the output. It completes its task normally and successfully, except that this WebappClassLoader: Lifecycle error : CL stopped error keeps occuring. I thought that destroy() was not supposed to be called until the service() method has exited, which definitely has not happened in my case. The reason I ran into this is I was testing the ability to take this servlet out of service without risking interrupting current tasks... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
running eXist XML database under tomcat-5.0.2
Hi, I am setting up a java web service using tomcat and eXist. I have successfully tested eXist as a standalone database. Now I want to integrate it into tomcat-5.0.2. I noticed when I start eXist as a standalone, using startup.sh, it says for tomcat, set openorb.home=/home/my_name/eXist-0.9.1/webapp/WEB-INF/openorb. What does this accomplish and which file under tomcat should this line be put in, web.xml? Thanks. Regards, Steve
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets HTMLManagerServlet.java
billbarker2003/06/13 19:07:46
Modified:catalina/src/share/org/apache/catalina/servlets
HTMLManagerServlet.java
Log:
Update to use the commons-fileupload-rc1 interface.
Submitted by: Martin Cooper [EMAIL PROTECTED]
Revision ChangesPath
1.16 +7 -7
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/HTMLManagerServlet.java
Index: HTMLManagerServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/HTMLManagerServlet.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- HTMLManagerServlet.java 13 Jan 2003 19:51:55 - 1.15
+++ HTMLManagerServlet.java 14 Jun 2003 02:07:46 - 1.16
@@ -84,7 +84,7 @@
import org.apache.catalina.Host;
import org.apache.catalina.util.ServerInfo;
import org.apache.commons.fileupload.FileItem;
-import org.apache.commons.fileupload.FileUpload;
+import org.apache.commons.fileupload.DiskFileUpload;
import org.apache.commons.fileupload.FileUploadException;
/**
@@ -195,7 +195,7 @@
String message = ;
// Create a new file upload handler
-FileUpload upload = new FileUpload();
+DiskFileUpload upload = new DiskFileUpload();
// Get the tempdir
File tempdir = (File) getServletContext().getAttribute
@@ -259,7 +259,7 @@
(htmlManagerServlet.installUploadWarExists,war);
break;
}
-warUpload.write(file.getCanonicalPath());
+warUpload.write(file);
try {
URL url = file.toURL();
war = url.toString();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0 build.properties.sample
billbarker2003/06/13 19:08:26
Modified:.build.properties.sample
Log:
Update to commons-fileupload-1.0-rc1
Revision ChangesPath
1.65 +4 -4 jakarta-tomcat-4.0/build.properties.sample
Index: build.properties.sample
===
RCS file: /home/cvs/jakarta-tomcat-4.0/build.properties.sample,v
retrieving revision 1.64
retrieving revision 1.65
diff -u -r1.64 -r1.65
--- build.properties.sample 4 May 2003 16:01:09 - 1.64
+++ build.properties.sample 14 Jun 2003 02:08:26 - 1.65
@@ -78,10 +78,10 @@
# - Commons FileUpload, nightly build -
-commons-fileupload.home=${base.path}/commons-fileupload-1.0-beta-1
+commons-fileupload.home=${base.path}/commons-fileupload-1.0-rc1
commons-fileupload.lib=${commons-fileupload.home}
-commons-fileupload.jar=${commons-fileupload.lib}/commons-fileupload-1.0-beta-1.jar
-commons-fileupload.loc=http://www.apache.org/dist/jakarta/commons/fileupload/commons-fileupload-1.0-beta-1.tar.gz
+commons-fileupload.jar=${commons-fileupload.lib}/commons-fileupload-1.0-rc1.jar
+commons-fileupload.loc=http://www.apache.org/dist/jakarta/commons/fileupload/commons-fileupload-1.0-rc1.tar.gz
# - Commons Logging, version 1.0.1 or later -
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
