RE: Jar_cache* files bis
-Message d'origine- De : Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Envoye : vendredi 12 juillet 2002 18:16 A : Tomcat Developers List; [EMAIL PROTECTED] Cc : [EMAIL PROTECTED] Objet : Re: Jar_cache* files bis On Fri, 12 Jul 2002, Arnaud HERITIER wrote: Date: Fri, 12 Jul 2002 15:05:15 +0200 From: Arnaud HERITIER [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Tomcat-Dev (E-mail) [EMAIL PROTECTED] Subject: Jar_cache* files bis Hello everybody! Few days ago, I send a question about jar_cache* files and I didn't have replies. I did answer ... must have been buried in your mailbox. Hi Craig. I'm very really sorry Craig !! I always read all your post carrefully and I don't explain how I do to not see it. I will castigate myself ;-) None of you knows how are used this files by Tomcat ??? Tomcat does not directly acces jar_cache files at all, in any way -- they are probably an implementation artifact of how your JDK deals with JAR files. ooops, it's a problem more annoying than I thought. it's possible because our customer uses the IBM JDK and not the SUN one. I will continue to search in this direction. Thx Craig for your patience. I would like to know if it possible to delete this files because Tomcat (4.0.1 under AIX) don't delete them when it shutdown :-( Sounds like a bug in your JDK. Can I delete this files when TC is running ?? How can I set the temp directory used for this files. It might be usefull when we have several Tomcat installed on the same machine in a production environnement. Thanks Arnaud Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10796] - reg. Tomcat performance
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=10796. 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=10796 reg. Tomcat performance [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID Summary|reg. Tomcat performance |reg. Tomcat performance --- Additional Comments From [EMAIL PROTECTED] 2002-07-15 08:49 --- I'm really sorry, but this is not a bug report, since it doesn't help in any way determine if there is in fact a problem with Tomcat, or a bug in your application. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10796] - reg. Tomcat performance
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=10796. 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=10796 reg. Tomcat performance [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2002-07-15 09:10 --- hi, i can send u the sample code how our programmers follows. Can you help us to refine our code if there is a problem in application itself. Please let us know if there is any other way to find the problem where it is ? regards, sudheer -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10796] - reg. Tomcat performance
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=10796. 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=10796 reg. Tomcat performance --- Additional Comments From [EMAIL PROTECTED] 2002-07-15 09:15 --- hi, Actually, with this code, system is working good. but suddenly.. some times it got stopped. Application has nothing but open database connection once and closing immedately after process the page. regards, sudheer -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Missing data
Hello folks, I passed through a lot of adventures until I receive some logical consequence for receiving the so needed module of mod_jk.so for Solaris 8.0. It turned out that latest source versions of Tomcat4.x.x are only empty folders... And when I try to get some of archives like jakarta-tomcat-4.x.x.tar.gz after the first decompression the tar file has wrong checksum But zip files are OK.. Now I get the tomcat-jakarta-connectors-4.0.2-src, but there are missing files again... I entered into the tomcat-jakarta-connectors-4.0.2-src/jk/native and tried to start the file buildconf.sh. Even during reading the documentation I noted that one of specified files is missing - aclocal.m4 (in previous versions that file is missing also). Anyway I started the script and I received the following message: Here is and the configure.in:14: no proper implementation of AM_INIT_AUTOMAKE was found, configure.in:14: probably because aclocal.m4 is missing... configure.in:14: You should run aclocal to create this file, then configure.in:14: run automake again. configure.in: installing `scripts/build/unix/install-sh' configure.in: installing `scripts/build/unix/mkinstalldirs' configure.in: installing `scripts/build/unix/missing' May I ask you how can I get the specified file? I have another idea how can I receive mod_jk.so or mod_webapps .so module, but my ideas are about to exhaust... Something else around documentation specified in INSTALL file: Besides libtool and autoconf tools, the developer has to have installed m4 library/module as well and automake tool. I see it is difficult to support a nice application and good documentation... But at least some of these omissions it is better to be mentioned and corrected. Thanks in advance! / Jennya Dobreva -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4829] - Automatic deployment of war files does not work properly
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=4829. 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=4829 Automatic deployment of war files does not work properly --- Additional Comments From [EMAIL PROTECTED] 2002-07-15 13:56 --- Dear Remy You have my full sympathy about this problem, but there is a lot of confusion occurring. You're being perfectly reasonable both in pointing out that this isn't a bug at all, but the designed behavior, and in suggesting that bug reporters instead submit a patch to change the behavior. The problem is that many people who are experiencing this bug, and this applies to me, are not technically adept enough to propose such a change - is there any chance that you could revisit the stated design and , or would this then contravene a specification? What I believe people want or need is to be able to start Tomcat *with* a context (e.g. MyApp) defined in server.xml, and with a MyApp.war file in place, but *without* the exploded MyApp webapp directory; in this scenario it would be most excellent if Tomcat unpacked the WAR before alternatively discovering the absence of the declared context. What are your thoughts on this suggestion? TIA Kind regards Tim Cooke P.S. At present I run Tomcat 4.0.1. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[GUMP] Build Failure - jakarta-tomcat-4.0
This email is autogenerated from the output from:
http://jakarta.apache.org/builds/gump/2002-07-15/jakarta-tomcat-4.0.html
Buildfile: build.xml
deploy-prepare:
deploy-static:
deploy:
[echo] Target: Catalina - Deploy ...
flags:
flags.display:
[echo] --- Build environment for Catalina ---
[echo] If ${property_name} is displayed, then the property is not set)
[echo] --- Build options ---
[echo] full.dist=${full.dist}
[echo] build.sysclasspath=only
[echo] compile.debug=${compile.debug}
[echo] compile.deprecation=${compile.deprecation}
[echo] compile.optimize=${compile.optimize}
[echo] --- Ant Flags ---
[echo] style task available (required)=true
[echo] --- JDK ---
[echo] jdk.1.2.present=true
[echo] jdk.1.3.present=true
[echo] jdk.1.4.present=${jdk.1.4.present}
[echo] --- Source Dependencies ---
[echo] jtc.home.present=true
[echo] --- Required Libraries ---
[echo] beanutils.present=true
[echo] collections.present=true
[echo] digester.present=true
[echo] jaxp.present=true
[echo] jndi.present=true
[echo] logging.present=true
[echo] regexp.present=true
[echo] servlet.present=true
[echo] --- Optional Libraries ---
[echo] daemon.present=${daemon.present}
[echo] dbcp.present=true
[echo] jaas.present=true
[echo] javamail.present=true
[echo] jmx.present=true
[echo] jsse.present=true
[echo] jta.present=true
[echo] junit.present=true
[echo] ldap.present=true
[echo] modeler.present=true
[echo] pool.present=true
[echo] tyrex.present=${tyrex.present}
[echo] --- Required JARs ---
[echo] jndi.jar.present(except JDK 1.3+)=true
[echo] regexp.jar.present=true
[echo] servlet.jar.present=true
[echo] xerces.jar.present(except JDK 1.4+ or xerces2)=true
[echo] xerces2.jars.present(except JDK 1.4+ or xerces1)=${xerces2.jars.present}
[echo] --- Optional JARs ---
[echo] daemon.jar.present=${daemon.jar.present}
[echo] dbcp.jar.present=true
[echo] jaas.jar.present=true
[echo] javamail.jar.present=true
[echo] jdbc20ext.jar.present=true
[echo] jmx.jar.present=true
[echo] jta.jar.present=true
[echo] junit.jar.present=${junit.jar.present}
[echo] ldap.jar.present=true
[echo] modeler.jar.present=true
[echo] pool.jar.present=true
[echo] tyrex.jar.present=${tyrex.jar.present}
[echo] --- Conditional compilation flags ---
[echo] compile.daemon=${compile.daemon}
[echo] compile.dbcp=true
[echo] compile.jaas=true
[echo] compile.javamail=true
[echo] compile.jmx=true
[echo] compile.jndi=true
[echo] compile.jsse=true
[echo] compile.jta=true
[echo] compile.junit=true
[echo] compile.ldap=true
[echo] compile.ssi=true
[echo] compile.tyrex=${compile.tyrex}
[echo] --- Distribution flags ---
[echo] copy.daemon.jar=${copy.daemon.jar}
[echo] copy.dbcp.jar=true
[echo] copy.jaas.jar=true
[echo] copy.jdbc20ext.jar=true
[echo] copy.javamail.jar=true
[echo] copy.jmx.jar=true
[echo] copy.jndi.jar=${copy.jndi.jar}
[echo] copy.jta.jar=true
[echo] copy.ldap.jar=${copy.ldap.jar}
[echo] copy.logging.jar=true
[echo] copy.modeler.jar=true
[echo] copy.pool.jar=true
[echo] copy.tyrex.jar=${copy.tyrex.jar}
[echo] copy.xerces.jar=true
[echo] copy.xerces2.jars=${copy.xerces2.jars}
build-prepare:
copy-activation.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/lib
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/lib
copy-daemon.jar:
copy-dbcp.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/lib
copy-jaas.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/server/lib
copy-jdbc20ext.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/lib
copy-jmx.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/server/lib
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/server/lib
copy-jndi.jar:
copy-jsse.jar:
copy-jta.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/lib
copy-ldap.jar:
copy-modeler.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/server/lib
copy-pool.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/lib
copy-tyrex.jar:
copy-xerces.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/endorsed
copy-xerces2.jars:
build-static:
build-tomcat-util:
detect:
DO NOT REPLY [Bug 6279] - Resubmit to j_security_check mistakenly fetches a page of that name
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=6279. 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=6279 Resubmit to j_security_check mistakenly fetches a page of that name --- Additional Comments From [EMAIL PROTECTED] 2002-07-15 15:39 --- One reasonable solution to the problem is: PROBLEM: The request would now fail with an SC_BAD_REQUEST - exactly as you would get if you bookmarked the login page. SOLUTION: (in authenticate() of FormAuthenticator.java) if (requestURI == null) requestURI =contextPath; //try to default to welcome page(s) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10789] - Setting DirectoryIndex of index.jsp does not get served by jk2
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=10789. 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=10789 Setting DirectoryIndex of index.jsp does not get served by jk2 --- Additional Comments From [EMAIL PROTECTED] 2002-07-15 16:02 --- Inserting some fprintf statements into mod_jk2 to show the sequence of hook invocations, I see that the problem is that jk2_handler is not getting invoked until too late in the process when the request is a directory. I assume this is because of the mod_dir processing, but I do not really know anything about the Apache internals. In the below trace, the sequence is http://XXX.XXX.XX.XX/ 1 and then turn around and request http://XXX.XXX.XX.XX/index.jsp 2 explictly. G:\Apache32\Apache2\binapache -X jk2_post_config( ) ENTER jk2_post_config( ) ENTER jk2_child_init( ) ENTER jk2_translate( ) ENTER --- 1 Unparsed uri: / Return DECLINED jk2_map_to_storage( ) ENTER Unparsed uri: / Return DECLINED jk2_translate( ) ENTER Unparsed uri: /index.html Return DECLINED jk2_map_to_storage( ) ENTER Unparsed uri: /index.html Return DECLINED jk2_translate( ) ENTER --- 1 Unparsed uri: /index.jsp Return OK jk2_map_to_storage( ) ENTER --- 1 Unparsed uri: /index.jsp Return OK--- If jk2_handler were now invoked .. jk2_translate( ) ENTER Unparsed uri: /error/HTTP_FORBIDDEN.html.var Return DECLINED jk2_map_to_storage( ) ENTER Unparsed uri: /error/HTTP_FORBIDDEN.html.var Return DECLINED jk2_translate( ) ENTER Unparsed uri: /error/include/top.html Return DECLINED jk2_map_to_storage( ) ENTER Unparsed uri: /error/include/top.html Return DECLINED jk2_handler( ) ENTER --- 1 Unparsed uri: /error/include/top.html Return DECLINED jk2_translate( ) ENTER Unparsed uri: /error/include/bottom.html Return DECLINED jk2_map_to_storage( ) ENTER Unparsed uri: /error/include/bottom.html Return DECLINED jk2_handler( ) ENTER Unparsed uri: /error/include/bottom.html Return DECLINED jk2_translate( ) ENTER Unparsed uri: /error/include/../contact.html.var Return DECLINED jk2_map_to_storage( ) ENTER Unparsed uri: /error/include/../contact.html.var Return DECLINED jk2_translate( ) ENTER --- 2 Unparsed uri: /index.jsp Return OK jk2_map_to_storage( ) ENTER --- 2 Unparsed uri: /index.jsp Return OK jk2_handler( ) ENTER --- 2 Unparsed uri: /index.jsp Return OK -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
TC 4.1.7 write access on config dir
While packaging tomcat 4.1.7 rpm, and trying to make it as secure as possible with tomcat running as tomcat4:tomcat4 and owning log/work/temp dir), I see that it tries to write on conf/tomcat-users.xml.new or conf/jk2.properties, and to mimic apache httpd server conf is owned by root and in read-only mode. Any ideas to fix that ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [VOTE] New branches and repositories
Sorry for the late vote. I've been on vacation last two weeks. ;-) ballot A) Servlet 2.4 JSP 2.0 API 1. [X] Use new jakarta-servletapi-5 2. [ ] Use the HEAD of jakarta-servletapi 3. [ ] Other: B) Catalina 2.0 1. [X] Use new jakarta-tomcat-catalina 2. [ ] Use new jakarta-tomcat-5.0 3. [ ] Use the HEAD of jakarta-tomcat-4.0 4. [ ] Other: C) Coyote 2.0 1. [X] Yes, use the HEAD of jakarta-tomcat-connectors 2. [ ] No, use: D) Tomcat 5.0 1. [ ] Use new jakarta-tomcat-5.0 2. [ ] Use the HEAD of jakarta-tomcat-4.0 3. [X] Use the HEAD of jakarta-tomcat 4. [ ] Other: E) Jasper 2.0 1. [X] Yes, use the HEAD of jakarta-tomcat-jasper 2. [ ] No, use: /ballot Amy Thanks for voting ;-) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New branches and repositories
The new repositories (jakarta-servletapi-5, jakarta-tomcat-5, and jakarta-tomcat-catalina) have been set up with just a LICENSE file checked in. Craig On Fri, 12 Jul 2002, Remy Maucherat wrote: Date: Fri, 12 Jul 2002 10:52:22 +0200 From: Remy Maucherat [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: New branches and repositories So it looks like the vote result (nearly everyone who voted +1 to the 5.0 proposal voted, and there's a clear majority for the winning choices) is: A) Use new jakarta-servletapi-5 (a root will need to create it) B) Use new jakarta-tomcat-catalina (a root will need to create it) C) Use HEAD of jakarta-tomcat-connectors (I will create the branch for Coyote 1.0) D) Use new jakarta-tomcat-5 (a root will need to create it) E) Use HEAD of jakarta-tomcat-jasper (I will create the branch for the current Jasper2 code) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Apache Tomcat 5.0 Proposal
Sorry for the late vote. I've been on vacation for last two weeks. But for the record, you have my +1. Thanks, Amy Remy Maucherat wrote: After trying to address the concerns raised by the proposal draft, I would like to call for a vote on it, now that the discussions have died down. ballot [ ] +1 I support the proposal, and will help implement it [ ] +0 I support the proposal [ ] -0 I do not support the proposal [ ] -1 I am against the proposal being implemented, because: /ballot The vote will run for one full week until July 9th. Users and other contributors may vote, but only committers have binding votes. Remy Proposal for Apache Tomcat 5.0 == Introduction: This document is a proposal for the next major release of Apache Tomcat, Apache Tomcat 5.0. Apache Tomcat 5.0 will improve on the Apache Tomcat 3.3 and Apache Tomcat 4.1 architectures, by making them simpler, more flexible and more modular, while at the same time adding support for the new Servlet API 2.4 and JSP 2.0 specifications, currently under development by the Java Community Process. The major goals for Apache Tomcat 5.0 are to: - improve scalability, reliability and performance over previous versions - have simpler/cleaner code, so more people can get involved - merge of the various ideas in 3.x and 4.x - get the community togheter - provide maximum modularity and compliance to the standards - make it easy to continue to maintain the existing codebases Testing will occur to make sure the stated robustness and performance goals are met by Tomcat 5.0. This proposal also tries to take advantage of the lessons learned while optimizing and maintaining Tomcat. Note: The development of Apache Tomcat 4.1.x will continue in parallel to the implementation of this proposal. General architecture: An improved version of Coyote 1.0, called Coyote 2.0, will be used as the Apache Tomcat 5.0 core. Coyote is currently considered a connector for Tomcat 3.3 and 4.x, and is under development in the jakarta-tomcat-connectors repository. Coyote 1.0 includes: - Protocol handlers for AJP 1.3, HTTP/1.1 and JNI - Adapter for Tomcat 3.3 - Adapter for Tomcat 4.x Extensibility capabilities will be added to Coyote, as well as JMX management features, and if possible, addional protocol handlers (like WARP 1.0). The Servlet API 2.4 specification will be implemented in a new version of Catalina, called Catalina 2.0. A new version of the Coyote adapter will be written for it if mandated by API changes. Components which duplicate functionality provided by Coyote will be removed, including the old connectors. On the JSP side, Jasper 2 will be updated to support JSP 2.0, will be renamed to Jasper 3, and is the proposed Jasper codebase. It provides many improvements over Jasper 1 included in Tomcat 3.x and Tomcat 4.0.x, including good tag library handling, and near zero overhead when compared to an equivalent hand coded servlet. Jasper 2 will also undergo additional optimizations. Apache Tomcat 5.0 will be made by default of the following components: - Coyote 2.0 - core - Catalina 2.0 - Servlet API 2.4 implementation - Jasper 2 - JSP 2.0 implementation Many other configurations are also possible, and it is expected that advanced users take advantage of it to make Tomcat better suit their needs. It is also possible that new special purpose components, like a bare bones Servlet API implementation, be developed to address the embedded market. Due to the scope of this work, this initial Proposal only plans the implementation and support of the default configuration described above. Changes over Apache Tomcat 4.1.x: A lot of the Apache Tomcat 5.0 code will be based on the Apache Tomcat 4.1.x codebase. Tomcat 5.0 will also be able to use the Tomcat 3.3.x code. The following major changes and additions are proposed to the current Apche Tomcat code, and related dependencies: A) Removal of the org.apache.catalina.connector.* This package is currently deprecated in Tomcat 4.1 because of its implementation inefficiencies, and general bad design. It is thus proposed that it is removed in Tomcat 5.0. B) Addition of new loader code for the commons-daemon subproject It is proposed that, in an attempt to solve the problems with using startup scripts, as well as adding additional features oriented towards reliability (including the capability to restart Tomcat automatically should the JVM crashes or experience memory management related problems), the launcher code which will be developed as part of commons-daemon be adopted. This code will be based in part on the launcher code used for the Sun Web Services Pack, and in part on the Wrapper project code (available at
Re: $ in JSP names
I totally agree that the use of $ in a file name is a pain in the neck. In fact, I don't see the need for appending a $jsp at all. Currently we have the following mapping: jsp file name: foo.jsp class name: foo$jsp servelt file name: foo$jsp.java class file name: foo$jsp.class I think it'd be perfectly OK to use the following mapping: jsp file name: foo.jsp class name: foo servelt file name: foo.java class file name: foo.class Date: Fri, 12 Jul 2002 14:55:01 -0700 (PDT) From: [EMAIL PROTECTED] Subject: $ in JSP names X-X-Sender: [EMAIL PROTECTED] To: List Tomcat-Dev [EMAIL PROTECTED] X-Authentication-warning: costinm.sfo.covalent.net: costin owned process doing -bs I just upgraded to jikes1.16, and I get one warning for each JSP file I compile: Lexical: The use of $ in an identifier, while legal, is strongly discouraged, since it can conflict with compiler-generated names. If you are trying to access a nested type, use . instead of $. In addition, it is painfull to look at the source from shell ( need to do emacs page\$jsp.jsp ). Would it be possible to use another delimiter in the generated name ? The change is trivial. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: $ in JSP names
On Mon, 15 Jul 2002, Kin-Man Chung wrote: Date: Mon, 15 Jul 2002 11:55:15 -0700 (PDT) From: Kin-Man Chung [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED], Kin-Man Chung [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: $ in JSP names I totally agree that the use of $ in a file name is a pain in the neck. In fact, I don't see the need for appending a $jsp at all. Currently we have the following mapping: jsp file name: foo.jsp class name: foo$jsp servelt file name: foo$jsp.java class file name: foo$jsp.class I think it'd be perfectly OK to use the following mapping: jsp file name: foo.jsp class name: foo servelt file name: foo.java class file name: foo.class Don't forget about pathological cases like having more than one extension mapped to the JSP servlet ... Craig Date: Fri, 12 Jul 2002 14:55:01 -0700 (PDT) From: [EMAIL PROTECTED] Subject: $ in JSP names X-X-Sender: [EMAIL PROTECTED] To: List Tomcat-Dev [EMAIL PROTECTED] X-Authentication-warning: costinm.sfo.covalent.net: costin owned process doing -bs I just upgraded to jikes1.16, and I get one warning for each JSP file I compile: Lexical: The use of $ in an identifier, while legal, is strongly discouraged, since it can conflict with compiler-generated names. If you are trying to access a nested type, use . instead of $. In addition, it is painfull to look at the source from shell ( need to do emacs page\$jsp.jsp ). Would it be possible to use another delimiter in the generated name ? The change is trivial. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: $ in JSP names
Craig R. McClanahan wrote: On Mon, 15 Jul 2002, Kin-Man Chung wrote: Date: Mon, 15 Jul 2002 11:55:15 -0700 (PDT) From: Kin-Man Chung [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED], Kin-Man Chung [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: $ in JSP names I totally agree that the use of $ in a file name is a pain in the neck. In fact, I don't see the need for appending a $jsp at all. Currently we have the following mapping: jsp file name: foo.jsp class name: foo$jsp servelt file name: foo$jsp.java class file name: foo$jsp.class I think it'd be perfectly OK to use the following mapping: jsp file name: foo.jsp class name: foo servelt file name: foo.java class file name: foo.class I thought the reason for appending something ($jsp or _jsp) was to prevent errors in the generated java files for jsp filenames that use one of java's keywords - default.jsp or new.jsp. -Arvind -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: $ in JSP names
I think you and Craig are both right. So how about using a _ instead of a $? Date: Mon, 15 Jul 2002 12:48:18 -0700 From: Arvind Srinivasan [EMAIL PROTECTED] Subject: Re: $ in JSP names To: Tomcat Developers List [EMAIL PROTECTED] Cc: Kin-Man Chung [EMAIL PROTECTED] Content-transfer-encoding: 7BIT Craig R. McClanahan wrote: On Mon, 15 Jul 2002, Kin-Man Chung wrote: Date: Mon, 15 Jul 2002 11:55:15 -0700 (PDT) From: Kin-Man Chung [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED], Kin-Man Chung [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: $ in JSP names I totally agree that the use of $ in a file name is a pain in the neck. In fact, I don't see the need for appending a $jsp at all. Currently we have the following mapping: jsp file name: foo.jsp class name: foo$jsp servelt file name: foo$jsp.java class file name: foo$jsp.class I think it'd be perfectly OK to use the following mapping: jsp file name: foo.jsp class name: foo servelt file name: foo.java class file name: foo.class I thought the reason for appending something ($jsp or _jsp) was to prevent errors in the generated java files for jsp filenames that use one of java's keywords - default.jsp or new.jsp. -Arvind -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: $ in JSP names
On Mon, 15 Jul 2002, Kin-Man Chung wrote: I think you and Craig are both right. So how about using a _ instead of a $? +1 ! Costin Date: Mon, 15 Jul 2002 12:48:18 -0700 From: Arvind Srinivasan [EMAIL PROTECTED] Subject: Re: $ in JSP names To: Tomcat Developers List [EMAIL PROTECTED] Cc: Kin-Man Chung [EMAIL PROTECTED] Content-transfer-encoding: 7BIT Craig R. McClanahan wrote: On Mon, 15 Jul 2002, Kin-Man Chung wrote: Date: Mon, 15 Jul 2002 11:55:15 -0700 (PDT) From: Kin-Man Chung [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED], Kin-Man Chung [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: $ in JSP names I totally agree that the use of $ in a file name is a pain in the neck. In fact, I don't see the need for appending a $jsp at all. Currently we have the following mapping: jsp file name: foo.jsp class name: foo$jsp servelt file name: foo$jsp.java class file name: foo$jsp.class I think it'd be perfectly OK to use the following mapping: jsp file name: foo.jsp class name: foo servelt file name: foo.java class file name: foo.class I thought the reason for appending something ($jsp or _jsp) was to prevent errors in the generated java files for jsp filenames that use one of java's keywords - default.jsp or new.jsp. -Arvind -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans mbeans-descriptors.xml
amyroh 2002/07/15 14:05:20 Modified:catalina/src/share/org/apache/catalina/mbeans mbeans-descriptors.xml Log: Add PersistentManager MBean info to mbeans-descripor.xml so it doesn't complain in case if you have PersistentManager. Patch submitted by Bob Herrmann [EMAIL PROTECTED]. Revision ChangesPath 1.64 +84 -1 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/mbeans-descriptors.xml Index: mbeans-descriptors.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/mbeans-descriptors.xml,v retrieving revision 1.63 retrieving revision 1.64 diff -u -r1.63 -r1.64 --- mbeans-descriptors.xml24 Jun 2002 21:11:42 - 1.63 +++ mbeans-descriptors.xml15 Jul 2002 21:05:19 - 1.64 @@ -2126,6 +2126,89 @@ /mbean + mbean name=PersistentManager +className=org.apache.catalina.mbeans.ClassNameMBean + description=Standard implementation of the Manager interface + domain=Catalina +group=Manager + type=org.apache.catalina.session.PersistentManager + +attribute name=algorithm + description=The message digest algorithm to be used when generating +session identifiers + type=java.lang.String/ + +attribute name=checkInterval + description=The interval (in seconds) between checks for expired +sessions + type=int/ + +attribute name=className + description=Fully qualified class name of the managed object + type=java.lang.String +writeable=false/ + +attribute name=debug + description=The debugging detail level for this component + type=int/ + +attribute name=distributable + description=The distributable flag for Sessions created by this +Manager + type=boolean/ + +attribute name=entropy + description=A String initialization parameter used to increase the +entropy of the initialization of our random number +generator + type=java.lang.String/ + +attribute name=managedResource + description=The managed resource this MBean is associated with + type=java.lang.Object/ + +attribute name=maxActiveSessions + description=The maximum number of active Sessions allowed, or -1 +for no limit + type=int/ + +attribute name=maxInactiveInterval + description=The default maximum inactive interval for Sessions +created by this Manager + type=int/ + +attribute name=maxIdleBackup + description=The time interval (in seconds) since the last access +to a session before it is eligible for being +persisted to the session store, or -1 to disable + type=int/ + +attribute name=maxIdleSwap + description=The time interval (in seconds) since the last access +to a session before it should be persisted to the +session store, or -1 to disable + type=int / + +attribute name=minIdleSwap + description=The time interval (in seconds) since the last access +to a session before it will be eligible to be +persisted to the session store, or -1 to disable + type=int / + +attribute name=saveOnRestart + description=Should all sessions be persisted and reloaded when +Tomcat is shut down and restarted? + type=boolean / + +attribute name=name + description=The descriptive name of this Manager implementation +(for logging) + type=java.lang.String +writeable=false/ + + /mbean + + mbean name=StandardManager className=org.apache.catalina.mbeans.ClassNameMBean description=Standard implementation of the Manager interface -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
No processor available - IIS and APJ13
Could someone give me a suggestion here? I'm having a problem that looks a lot like bug 5735 in the Apache Bug Database.. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5735 Basically, the server will suddenly start launching background threads until it reaches the maxProcessors parameter of the Connector, and reject all further requests. The responses in the bug database suggest using the Coyote connector to fix it. However, I have not had any luck getting it to work with Ajp13. It appears to me that I have to use the new Jakarta Redirector for IIS (JK2). Since I have only been able to find this except as a nightly build (no docs yet) this has been a rather daunting task. Also, is it likely that the root cause of this problem could be an IOException while loading persisted sessions? It seems that we have a non-serializable object in the session. My configuration is... Windows 2000 and IIS using isapi_redirect.dll Tomcat 4.0.1 Here is a log segment... 2002-07-13 10:57:25 Ajp13Processor[8009][26] process: invoke java.net.SocketException: Connection reset by peer: socket write error at java.net.SocketOutputStream.socketWrite(Native Method) at java.net.SocketOutputStream.write(SocketOutputStream.java:83) at org.apache.ajp.Ajp13.send(Ajp13.java:525) at org.apache.ajp.RequestHandler.finish(RequestHandler.java:495) at org.apache.ajp.Ajp13.finish(Ajp13.java:395) at org.apache.ajp.tomcat4.Ajp13Response.finishResponse(Ajp13Response.java:196) at org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:464) at org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:551) at java.lang.Thread.run(Thread.java:484) 2002-07-13 10:57:43 Ajp13Processor[8009][44] Starting background thread 2002-07-13 10:57:50 Ajp13Processor[8009][45] Starting background thread 2002-07-13 10:58:03 Ajp13Processor[8009][49] Starting background thread 2002-07-13 11:03:21 Ajp13Processor[8009][74] Starting background thread 2002-07-13 11:03:22 Ajp13Connector[8009] No processor available, rejecting this connection 2002-07-13 11:03:22 Ajp13Connector[8009] No processor available, rejecting this connection 2002-07-13 11:03:22 Ajp13Connector[8009] No processor available, rejecting this connection ... Thanks, Michael Reardon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: $ in JSP names
On Mon, 15 Jul 2002 [EMAIL PROTECTED] wrote: Date: Mon, 15 Jul 2002 13:40:28 -0700 (PDT) From: [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED], Kin-Man Chung [EMAIL PROTECTED] Subject: Re: $ in JSP names On Mon, 15 Jul 2002, Kin-Man Chung wrote: I think you and Craig are both right. So how about using a _ instead of a $? +1 ! +1 as well. Costin Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10850] New: - HttpUtils.getRequestURL omits port number
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=10850. 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=10850 HttpUtils.getRequestURL omits port number Summary: HttpUtils.getRequestURL omits port number Product: Tomcat 4 Version: 4.0.4 Final Platform: PC OS/Version: Windows XP Status: NEW Severity: Normal Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If tomcat is run on port 8080 (and likely anything but 80), the following simple jsp page will show that HttpUtils.getRequestURL omits the port number in the returned URL. This call worked fine in Tomcat 4.0.3. html body HttpUtils.getRequestURL(request) returns: %= HttpUtils.getRequestURL(request) % /body /html -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10852] New: - Patch: Add Connection Pooling to JNDIRealm
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=10852. 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=10852 Patch: Add Connection Pooling to JNDIRealm Summary: Patch: Add Connection Pooling to JNDIRealm Product: Tomcat 4 Version: 4.1.7 Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Attached (soon) will be a patch which add connection pooling to JNDIRealm. The pool used is from jakarta-commons/pool. The number of connections and amount of time for eviction of pool items are configurable. The javadocs have been updated too to reflect my additions. No new functionality has been introduced. The down side is testing for good connections. There is none. But bad connectinos are removed by waiting for bad things to happening - then remembering the connection later to be closed. The pool factory is implmented as an inner class. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10852] - Patch: Add Connection Pooling to JNDIRealm
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=10852. 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=10852 Patch: Add Connection Pooling to JNDIRealm --- Additional Comments From [EMAIL PROTECTED] 2002-07-16 01:51 --- Created an attachment (id=2359) Patch file as promised -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
