RE: Jk2: scoreboard format and semantics.
- Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, April 19, 2002 10:34 PM To: List Tomcat-Dev Subject: Jk2: scoreboard format and semantics. That's a difficult and critical issue. The scoreboard is needed to allow the loadbalancing to react to changes in the workers. It is also help with runtime configuration of jk in multi-process servers. The problem is obviously how to implement it without mutexes ( or with minimal use of interprocess synchronization ). The first proposal is based on the model used by Apache and jserv. 1. Each worker will get it's own 'slot'. Each slot and the jk_shm_head will get a 'version' ( or 'serial' ) field. 2. Whenever a worker ( tomcat ) is created, we create a slot - this operation requires inter-process locking ( for the unlikely but possible case 2 tomcat instances will start at the same time ). 3. Any change in the slots will result in incrementing ( or just changing ) the version in the slot and in the head. 4. jk_worker_lb will just monitor the int field in the head. If a change is detected ( from the previous value ) - it'll walk all fields and update the worker map. The same process could work for doing updates in the uriMap and other config changes - but later. My current understanding is that this model will does not require extra synchronization or even atomic operations on read ( i.e. in the critical path ). Even if we read the version while changing - what we care is if the value is different from the last one we read. ( atomic operations are usually expensive - and not trivial on MP systems ). The creation or change in slots will require synchronization. The 'bad' thing that can happen is a process reading the slot while we change it. My initial thinking was that we could have a 'changing' field in the slot - but I don't think we can have guarantee of the order of the writes. But a simple CRC of the data would work - the reader will copy the slot, then do a CRC. If it doesn't match, it'll either keep the old data or try again. The information in the slot will include the worker id ( used in the 'session id' or jvmRoute ), information about the channels it supports ( host:port, unix domain, etc ), state. To keep things simple and use existing code, I think we should use the current marshalling/demarshalling code ( ajp13 ) to store/get informations from each slot. Why not just use native read/write on int/strings ? Do you think we should share these shared informations with others apps/modules ? To keep things simple, we should start with fixed-size slots. The shm scoreboard will be updated by: - the lb worker ( when it detects that a worker is down ) ok - a tomcat process when it starts and auto-register itself ( including the case of Apache multi-process where VMs are created with each process ) ok, a tomcat started on another boxes, but that we want to add to the list of known workers will be handled by jk_status/jk_control ? - an admin tool ( either C or an ant bean using the jkjni.so lib ) to register workers on different machines ( jk_status worker can do that too ). ok, so jk_status became jk_control or jk_admin in that case. No more just a read-only task ? Comments ? Other ideas ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_webapp.so socketpool changes..
Pier Fumagalli wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, As mentioned in my last email I have updated the socketpool changes to incorporate the changes recommended. I'm not sure if my mail was missed or not but I haven't received any feedback on the latest changes. What's the process to get this code into the codebase? I believe I would need cvs access to commit this (if deemed acceptable) into the source myself. Is this the case? Can someone fill me in Attached are the changes made. Simon, both I and JF have been pretty busy this last few days... I wanted to it out also with Apache 2.0's worker MPM before committing... I have been out for a week... But I will try to find some time today ;-) Pier -- 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]
DO NOT REPLY [Bug 8363] New: - Out of memory error
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=8363. 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=8363 Out of memory error Summary: Out of memory error Product: Tomcat 4 Version: 4.0.3 Final Platform: PC URL: http://www.sitegalore.com OS/Version: Windows NT/2K Status: NEW Severity: Critical Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] We are using Tomcat4.03 on Windows 2000/IIS 5 and we have a problem in that. The memory allocated to Tomcat.exe is not getting released. Even many hours after the usage has been stopped, the memory used is not coming down. Depending on the load, Tomcat reports Out of Memory error in a few hours or days and the process occupies all available memory. The only option is to restart the server. We had the same problem in Tomcat 3.2.3 also. And we have tried Tomcat with Apache also. This problem has already been reported by few other people in Tomcat3 bug database and has been resolved as fixed. What is the possible cause of this problem? Is it a Tomcat bug? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: MinTC, terrible rudeness, persistence
GOMEZ Henri wrote: This cannot be done, as the layering structure of the ASF won't allow it. It can be hosted either in commons, either here (but then it would be swallowed by the TC project itself), or as a top level project of Jakarta (or some other project)... couldn't it be a tomcat sub project like jasper2 or jtc ? Do you remember what you say yesterday about platform problems ?) I clearly do, I replied to your post saying that I don't care about AS/400s and stated clearly what my objectives are (compilation of mod_jk under hesoteric operating systems is not a bug, not a security hole, but simply a port of a component I'm not involved with - let's make a difference here). Ok, that's why an alternative build system which may help build on hesoterico-exotico OS is still good to take. end of story ;) It's something I won't probably need in the future, and _I_BELIEVE_ doesn't affect our users community at large, as frankly AFAIK you're the only one with one of those little nifty IBM machines I know). JF/Martin from ASF have also some interesting systems ;) Sure ;-) I hope to run TC on an EBCDIC mainframe (Using Apache-1.3 and mod_jk). There is many commiters on ASF who works directly on indirectly for IBM and use/contribute ASF projects. Not speaking about AS/400 techies from IBM Rochester Labs tracking tomcat-dev in silent mode, and I'd like to heard a little more (Walt, Jim be our guests). Tomcat is a server side application and AS/400 is not so exotic on server area. That's why it's so important to get it there. IBM use on AS/400, some of the latest ASF works, Apache 2.0, Tomcat (yes still 3.2.1, they need to upgrade their own mod_jk version to be able to use tomcat 3.3.1 or 4.0.3 since updates in headers in ajp13). I'm very happy using tomcat/apache2.0/jk on AS/400 instead of being limited to IBM own websphere. Having OSS on such 'closed' systems is a great victory of ASF But at least I replied... (Ok, now don't nitpick on the fact that I'm not fixing Win32 bugs on Win32, I _don't_have_ a Win32 machine anymore, at least since I left Sun Microsystems, and my MSVC license is not available anymore since those people testing out builds at the University of Westminster don't work there anymore...) On the other hand, how many replies were there to a notification of a _bug_ (a serious security hole -IMO) I found on OS/X? Zero, not even a (as I said) since you have OS/X can you volunteer to fix it, or since I don't have OSX I don't care about it... none, nada, nihil, nothing... I didn't have OS/X, and you know how I'll be happy to have one, so couldn't do anything to fix. Now I'm wondering... What would have happened if I reported the same bug for Tomcat 3.3? :) :) :) :) Same problem that in 4.x and related question : - how many tomcat 3.3 developpers have access to OS/X ? - how many tomcat 4.x developpers have access to OS/X ? if the bug is a security problem, at least on one platform, it should be fixed and since you have access to such platform you may provide the fix. There was fix for windows platform not so long from that but it's clear that OS/X and AS/400 have a common problem today, less users/developpers than Unix or Windows -- 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]
DO NOT REPLY [Bug 8363] - Out of memory error
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=8363. 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=8363 Out of memory error [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Component|Unknown |Catalina Resolution||LATER --- Additional Comments From [EMAIL PROTECTED] 2002-04-22 10:53 --- Since you can't point out from where the memory leak is coming from, I'll assume it is caused by your application (indirectly). It is very likely your problems come from having too many active sessions. A more efficient session manager is a necessity for high availability scenarios when web applications are making heavy use of them. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8339] - Request.getInputStream() has no data
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=8339. 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=8339 Request.getInputStream() has no data [EMAIL PROTECTED] changed: What|Removed |Added Severity|Major |Normal Component|Catalina|Connector:Coyote HTTP/1.1 --- Additional Comments From [EMAIL PROTECTED] 2002-04-22 11:11 --- You're doing the upload with a form encoding content type, which is incorrect here (you're uploading text/xml, and not parameters). Since you are not calling getParameters, the problem would be that the adapter would apparentl parse them anyway (I don't know why yet), which may be incorrect (at least, it should be a lazy evaluation). I'll check to see if there is a bug. Also, your byte reading algorithm is bad (do a loop to do that, and handle negative values). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8323] - No support for running the 64 bit JVM
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=8323. 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=8323 No support for running the 64 bit JVM [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8318] - class not found for: org.apache.cocoon.servlet.CocoonServlet
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=8318. 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=8318 class not found for: org.apache.cocoon.servlet.CocoonServlet [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-04-22 11:20 --- It is extremely likely you have a configuration problem somewhere. Using a correcly deployed Cocoon 2 (I only tried 2.0.1, though) does work. I don't know what would happen if you tweak too much you deployment of Tomcat (moving JARs around is obviously not supported), or install other integrated applications (like Slide). If you do so, I'd rather limit the potential classloader trouble and use multiple instances (you trade memory use for trouble; a good deal if you look at the memory price). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8235] - message.properties is missing in package Tyrex-0.9.7.0.jar
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=8235. 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=8235 message.properties is missing in package Tyrex-0.9.7.0.jar [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-04-22 11:22 --- Due to problems Tyrex is not supported anymore in Tomcat, due to nearly impossible to solve problems when using its pooling functionality. Using commons-dbcp as the DataSource provider is now recommended (the next major release of Tomcat will include it). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Bad build process for mod_webapp for Apache 2
(sorry if this has come through already, but I did not see the post on
the mail archive, so I done went and subscribed to the list to resend it)
For those of you who do not regularly cruise the tomcat-user postings
(you all do that regularly, right? ;-), a number of us in the user
community have been struggling with getting Tomcat 4 integrated with
Apach 2 using mod_webapp. I and a number of other users found a number
of problems in the build process for mod_webapp - biggest of which is
that the Makefile does not actually produce a DSO module (i.e.
mod_webapp.so) for Apache 2. We figured out that the following will do
so (after running configure and make):
cd ${LOCATION_OF_CONNECTOR_SRC}/webapp/lib
gcc -shared -o libwebapp.so *.lo
cd ../apache-2.0
${APACHE_HOME}/build/libtool --silent --mode=link \
gcc -shared -o mod_webapp.so -rpath ${APACHE_HOME}/modules \
-module -avoid-version -I../include -L../lib \
-dlopen ../lib/libwebapp.la mod_webapp.lo
cp mod_webapp.so ${APACHE_HOME}/modules/
I have included a brief HOWTO that I compiled during the process of
figuring this all out. If more information is needed, please let me
know directly to my email (I am not presently on the dev mailing list
distribution).
Thanx!
jeff
--
Jeffrey Bonevich
Ann Arbor, Michigan
[EMAIL PROTECTED]
http://www.bonevich.com
Hwæt! Wë Gär-Dena in geär-dagum,
peod-cyninga, prym gefrünon,
hü ða aepelingas ellen fremedon!
Tomcat4+Apache2+mod_webapp_HOWTO.sh
Description: Bourne shell script
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7640] - JDBC connection and transaction related
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=7640. 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=7640 JDBC connection and transaction related [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-04-22 13:46 --- This is a Tyrex problem, not a Tomcat problem, so it won't be fixed (at least not by Tomcat). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0 RELEASE-PLAN-4.1.txt
remm02/04/22 08:12:23 Added: .RELEASE-PLAN-4.1.txt Log: - Major features have been added to Tomcat since 4.0.x (list of the major features is included in the document), and as all (but one) is now feature complete, I think it is time to start a new release cycle. - The proposed release cycle is short, as the codebase is an evolution of the 4.0.x codebase, and has recieved all the bugfixes introduced in the 4.0.x branch. Revision ChangesPath 1.1 jakarta-tomcat-4.0/RELEASE-PLAN-4.1.txt Index: RELEASE-PLAN-4.1.txt === $Id: RELEASE-PLAN-4.1.txt,v 1.1 2002/04/22 15:12:23 remm Exp $ Release Plan for Apache Tomcat 4.1 == Introduction: This document is a release plan for the *final* release of Apache Tomcat 4.1. The goal of the Apache Tomcat 4.1 final release is to provide a stable container that supports 100% of the mandatory requirements of the Servlet 2.3 and JSP 1.2 specifications, as well as to improve and add many useful additional features on top of the existing Apache Tomcat 4.0 releases. Apache Tomcat 4.1 includes the following major new features over Apache Tomcat 4.0: * JMX based administration features * JSP and Struts based administration web application * New Coyote HTTP/1.1 connector * New Coyote JK2 AJP 1.4 connector * Rewritten Jasper JSP page compiler * Performance and memory efficiency improvements * Many other miscanellous improvements This Release Plan proposes the following schedule: Friday, April 26, 2002 Apache Tomcat 4.1 Beta 1 Friday, May 10, 2002Apache Tomcat 4.1 Beta 2 Friday, May 17, 2002Apache Tomcat 4.1 Release Candidate In order to complete final release, all outstanding Bugzilla bug reports against Tomcat 4.1 above NORMAL severity need to be fixed or deferred for later releases. After the first 4.1 Release Candidate, other RC releases may be made as needed until one is promoted as Final by the Tomcat committers. This Release Plan proposes the following classification of current outstanding bug reports in the bug tracking system, sorted by component and their ID numbers in our bug tracking system at: http://nagoya.apache.org/bugzilla/ Please review the bug reports, and their classification as must have, nice to have, or address later. Lobbying for changes in classification can take place on the TOMCAT-DEV mailling list. In addition, if you have a bug report or enhancement that you wish to have considered prior to final release, please submit a bug report as quickly as possible. Bugs That Must Be Addressed Before Final Release: Nice To Have Fixes Before Final Release: --- Unconfirmed Bugs (Awaiting Reproducible Failure Case): - -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[COMMENTS] Tomcat 4.1 release plan draft posted
I have committed a draft of a release plan for the next major release of Tomcat 4.x (proposed version number: 4.1). All the major features currently in development in HEAD, j-t-c, j-t-j are either feature complete, or reasonably close from being feature complete, and should all contribute to improve Tomcat. This includes: * JMX based administration features * JSP and Struts based administration web application * New Coyote HTTP/1.1 connector * New Coyote JK2 AJP 1.3/1.4 connector * Rewritten Jasper JSP page compiler (called Jasper 2) * Performance and memory efficiency improvements * Miscanellous refactorings The release plan includes the proposed release schedule. It is short, as the codebase is an evolution of the 4.0.x codebase, and has recieved all the bugfixes introduced in the 4.0.x branch. The release plan is available through CVSWEB: http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-4.0/RELEASE-PLAN-4.1.txt Committers can directly edit the release plan, or can comment on it and I'll make the changes. I plan to call for a vote on the release plan on 04/24, or later if necessary. Comments ? Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Daemon Thread Problem in J-T-C
With the latest and greated J-T-C code, the HEAD branch of Tomcat 4 doesn't shut down cleanly. Usually, this implies that somebody forgot to mark their threads as daemon threads (or otherwise clean them up at shutdown time). Indeed, a thread dump after the shutdown command is executed shows a bunch of active threads, including those suspended by a wait() at: org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable.run(ThreadPool.java:407) org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable.run(ThreadPool.java:495) org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable.run(ThreadPool.java:495) org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable.run(ThreadPool.java:495) Could someone working on the thread pool code please take a look at this? Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8339] - Request.getInputStream() has no data
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=8339. 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=8339 Request.getInputStream() has no data --- Additional Comments From [EMAIL PROTECTED] 2002-04-22 18:11 --- Absolutely right - stupidly I assumed XmlSerializer was setting the content type when obviously it can't. However I thought getParameter().. OR getReader()/getInputStream() were choices that the servlet could make even if form urlencoded? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8339] - Request.getInputStream() has no data
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=8339. 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=8339 Request.getInputStream() has no data --- Additional Comments From [EMAIL PROTECTED] 2002-04-22 18:35 --- Yes, as I implied in my comment, I think there's a bug (if you don't call getParameters, it shouldn't parse the parameters). You have a nice workaround in the meantime (set the right content-type, and it shouldn't parse the parameters). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8339] - Request.getInputStream() has no data
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=8339. 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=8339 Request.getInputStream() has no data --- Additional Comments From [EMAIL PROTECTED] 2002-04-22 18:53 --- Thank you for speedy responses -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin TomcatTreeBuilder.java
manveen 02/04/22 11:53:51 Modified:webapps/admin/WEB-INF/classes/org/apache/webapp/admin TomcatTreeBuilder.java Log: Do not show fully blown tree at tool startup. Revision ChangesPath 1.28 +7 -7 jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/TomcatTreeBuilder.java Index: TomcatTreeBuilder.java === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/TomcatTreeBuilder.java,v retrieving revision 1.27 retrieving revision 1.28 diff -u -r1.27 -r1.28 --- TomcatTreeBuilder.java16 Apr 2002 17:04:19 - 1.27 +++ TomcatTreeBuilder.java22 Apr 2002 18:53:51 - 1.28 @@ -1,7 +1,7 @@ /* - * $Header: /home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/TomcatTreeBuilder.java,v 1.27 2002/04/16 17:04:19 manveen Exp $ - * $Revision: 1.27 $ - * $Date: 2002/04/16 17:04:19 $ + * $Header: /home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/TomcatTreeBuilder.java,v 1.28 2002/04/22 18:53:51 manveen Exp $ + * $Revision: 1.28 $ + * $Date: 2002/04/22 18:53:51 $ * * * @@ -93,7 +93,7 @@ * * @author Jazmin Jonson * @author Manveen Kaur - * @version $Revision: 1.27 $ $Date: 2002/04/16 17:04:19 $ + * @version $Revision: 1.28 $ $Date: 2002/04/22 18:53:51 $ */ @@ -204,7 +204,7 @@ nodeLabel= + URLEncoder.encode(nodeLabel), content, -true); +false); serverNode.addChild(serviceNode); getConnectors(serviceNode, serviceName); getHosts(serviceNode, serviceName); @@ -243,7 +243,7 @@ nodeLabel= + URLEncoder.encode(nodeLabel), content, -true); +false); serviceNode.addChild(connectorNode); } } @@ -276,7 +276,7 @@ nodeLabel= + URLEncoder.encode(nodeLabel), content, -true); +false); serviceNode.addChild(hostNode); getContexts(hostNode, hostName); getLoggers(hostNode, hostName); -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads Reaper.java ThreadPool.java
costin 02/04/22 11:55:56
Modified:util/java/org/apache/tomcat/util/threads Reaper.java
ThreadPool.java
Log:
Make the ThreadPool threads 'daemon'.
Make the Reaper non-deamon.
In 3.x there is no thread waiting for the shutdown, so we need at
least a user thread.
Revision ChangesPath
1.2 +5 -2
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/Reaper.java
Index: Reaper.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/Reaper.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- Reaper.java 6 Jan 2002 08:34:56 - 1.1
+++ Reaper.java 22 Apr 2002 18:55:56 - 1.2
@@ -69,14 +69,17 @@
* @author Costin Manolache
*/
public class Reaper extends Thread {
+private boolean daemon=false;
public Reaper() {
- this.setDaemon(true);
+ if( daemon )
+this.setDaemon(true);
this.setName(TomcatReaper);
}
public Reaper(String name) {
- this.setDaemon(true);
+if( daemon )
+this.setDaemon(true);
this.setName(name);
}
1.2 +5 -3
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java
Index: ThreadPool.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ThreadPool.java 6 Jan 2002 08:34:56 - 1.1
+++ ThreadPool.java 22 Apr 2002 18:55:56 - 1.2
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java,v
1.1 2002/01/06 08:34:56 costin Exp $
- * $Revision: 1.1 $
- * $Date: 2002/01/06 08:34:56 $
+ * $Header:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java,v
1.2 2002/04/22 18:55:56 costin Exp $
+ * $Revision: 1.2 $
+ * $Date: 2002/04/22 18:55:56 $
*
*
*
@@ -395,6 +395,7 @@
shouldTerminate = false;
this.p = p;
t = new Thread(this);
+t.setDaemon(true);
t.setName( MonitorRunnable );
t.start();
}
@@ -480,6 +481,7 @@
shouldRun = false;
this.p = p;
t = new Thread(this);
+t.setDaemon(true);
t.start();
noThData=true;
thData=null;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkCoyoteHandler.java JkMain.java
costin 02/04/22 12:03:34
Modified:jk/java/org/apache/jk/server JkCoyoteHandler.java
JkMain.java
Log:
Fix the shutdown for jk2.
Revision ChangesPath
1.12 +1 -1
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java
Index: JkCoyoteHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- JkCoyoteHandler.java 17 Apr 2002 22:39:26 - 1.11
+++ JkCoyoteHandler.java 22 Apr 2002 19:03:34 - 1.12
@@ -155,7 +155,7 @@
}
public void destroy() {
-// jkMain.stop();
+jkMain.stop();
}
// OutputBuffer implementation
1.21 +18 -1
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkMain.java
Index: JkMain.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkMain.java,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- JkMain.java 18 Apr 2002 19:13:02 - 1.20
+++ JkMain.java 22 Apr 2002 19:03:34 - 1.21
@@ -230,7 +230,24 @@
shm,
request,
container,
- channelSocket};
+ channelSocket,
+ channelJni,
+ channelUn};
+
+public void stop()
+{
+for( int i=0; iwEnv.getHandlerCount(); i++ ) {
+if( wEnv.getHandler(i) != null ) {
+try {
+wEnv.getHandler(i).destroy();
+} catch( IOException ex) {
+log.error(Error stoping + wEnv.getHandler(i).getName(), ex);
+}
+}
+}
+
+started=false;
+}
public void start() throws IOException
{
--
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/startup Catalina.java ContextConfig.java
craigmcc02/04/22 12:04:01
Modified:catalina/src/share/org/apache/catalina/startup Catalina.java
ContextConfig.java
Log:
When parsing server.xml and web.xml files, use an InputSource rather than an
InputStream so that we can set a system identifier. Among other things, this
allows developers to split up their input files with the use of external
entities like this:
?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;
[
!ENTITY webinc PUBLIC webinc webinc.xml
]
web-app
webinc;
/web-app
Tested this with web.xml files in both unpacked directories and a packaged
WAR file, and it seems to work.
NOTE: This patch doesn't address trying to parse tag library descriptors
that have external entities included in them. The same approach would probably
work, but will require a couple of API changes to some private methods in
o.a.c.ContextConfig and the corresponding code in Jasper.
Based on a patch provided by Attila Szegedi szegedia at freemail.hu for
Bugzilla #8024.
Revision ChangesPath
1.47 +18 -6
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java
Index: Catalina.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java,v
retrieving revision 1.46
retrieving revision 1.47
diff -u -r1.46 -r1.47
--- Catalina.java 15 Apr 2002 09:34:06 - 1.46
+++ Catalina.java 22 Apr 2002 19:04:01 - 1.47
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java,v
1.46 2002/04/15 09:34:06 remm Exp $
- * $Revision: 1.46 $
- * $Date: 2002/04/15 09:34:06 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java,v
1.47 2002/04/22 19:04:01 craigmcc Exp $
+ * $Revision: 1.47 $
+ * $Date: 2002/04/22 19:04:01 $
*
*
*
@@ -66,6 +66,7 @@
import java.io.File;
+import java.io.FileInputStream;
import java.io.IOException;
import java.io.OutputStream;
import java.lang.reflect.InvocationTargetException;
@@ -82,6 +83,7 @@
import org.apache.commons.digester.Digester;
import org.apache.commons.digester.Rule;
import org.xml.sax.Attributes;
+import org.xml.sax.InputSource;
/**
@@ -97,7 +99,7 @@
* /u
*
* @author Craig R. McClanahan
- * @version $Revision: 1.46 $ $Date: 2002/04/15 09:34:06 $
+ * @version $Revision: 1.47 $ $Date: 2002/04/22 19:04:01 $
*/
public class Catalina {
@@ -438,8 +440,13 @@
Digester digester = createStartDigester();
File file = configFile();
try {
+InputSource is =
+new InputSource(file:// + file.getAbsolutePath());
+FileInputStream fis = new FileInputStream(file);
+is.setByteStream(fis);
digester.push(this);
-digester.parse(file);
+digester.parse(is);
+fis.close();
} catch (Exception e) {
System.out.println(Catalina.start: + e);
e.printStackTrace(System.out);
@@ -548,8 +555,13 @@
Digester digester = createStopDigester();
File file = configFile();
try {
+InputSource is =
+new InputSource(file:// + file.getAbsolutePath());
+FileInputStream fis = new FileInputStream(file);
+is.setByteStream(fis);
digester.push(this);
-digester.parse(file);
+digester.parse(is);
+fis.close();
} catch (Exception e) {
System.out.println(Catalina.stop: + e);
e.printStackTrace(System.out);
1.62 +23 -8
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/ContextConfig.java
Index: ContextConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
retrieving revision 1.61
retrieving revision 1.62
diff -u -r1.61 -r1.62
--- ContextConfig.java4 Apr 2002 20:30:34 - 1.61
+++ ContextConfig.java22 Apr 2002 19:04:01 - 1.62
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
1.61 2002/04/04 20:30:34 craigmcc Exp $
- * $Revision: 1.61 $
- * $Date: 2002/04/04 20:30:34 $
+ * $Header:
DO NOT REPLY [Bug 8024] - Can't include entities in web.xml
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=8024. 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=8024 Can't include entities in web.xml [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-04-22 19:05 --- The proposed patch only covers the parsing of the conf/server.xml file, so I extended this for the places in o.a.c.startup.ContextConfig that web.xml files are parsed as well. This still doesn't cover TLDs (which are parsed in ContextConfig to register listeners, and parsed in Jasper as part of compilation), but I suspect the need for external entities in TLDs is a lot less common. Fixed in nightly build 20020423. Thanks for the patch! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8318] - class not found for: org.apache.cocoon.servlet.CocoonServlet
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=8318. 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=8318 class not found for: org.apache.cocoon.servlet.CocoonServlet [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2002-04-22 19:06 --- I do not agree that this bug should be closed. Please follow an appropriate test between the installation instructions with Tomcat 4.0.4b1, Cocoon 2.0.2 (binary distribution is fine) and Slide (integrated jar technique rather than just the war file). I believe the problem is in properly resolving the jaxp.jar or jta.jar of slide. If you wish to reclassify this bug on the Slide group, fine. If Tomcat is to be a proper Servlet Container, than we should be able to load all Servlets properly under the Tomcat/Catalina Engine in any order and in any combination. I scrapped my Tomcat 4 install and reloaded. The Exception error is a bit different, but definately points to a problem resolving which classes can be loaded, when. Please review -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8318] - class not found for: org.apache.cocoon.servlet.CocoonServlet
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=8318. 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=8318 class not found for: org.apache.cocoon.servlet.CocoonServlet [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-04-22 19:23 --- Customized versions of Tomcat are not supported. If the problem occurs because you have moved JARs around, then it is your problem (obviously, not all configurations are valid and will be supported). Slide integrated is not the same as Tomcat standalone (I know it, since I wrote it), and won't be supported. It is also not advertised as a general purpose servlet container (instead, it is advertised as a content server). Please run two Tomcat instances to avoid problems. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkCoyoteHandler.java
remm02/04/22 13:19:02
Modified:jk/java/org/apache/jk/server JkCoyoteHandler.java
Log:
- Fix the fix for the shutdown.
- Costin: if the fix is not good, feel free to revert or fix it.
Revision ChangesPath
1.13 +3 -0
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java
Index: JkCoyoteHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- JkCoyoteHandler.java 22 Apr 2002 19:03:34 - 1.12
+++ JkCoyoteHandler.java 22 Apr 2002 20:19:02 - 1.13
@@ -155,6 +155,9 @@
}
public void destroy() {
+if( started ) return;
+
+started = false;
jkMain.stop();
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Daemon Thread Problem in J-T-C
With the latest and greated J-T-C code, the HEAD branch of Tomcat 4 doesn't shut down cleanly. Usually, this implies that somebody forgot to mark their threads as daemon threads (or otherwise clean them up at shutdown time). Indeed, a thread dump after the shutdown command is executed shows a bunch of active threads, including those suspended by a wait() at: org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable.run(ThreadPool.jav a:407) org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable.run(ThreadPool.jav a:495) org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable.run(ThreadPool.jav a:495) org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable.run(ThreadPool.jav a:495) Could someone working on the thread pool code please take a look at this? These days, I was always shutting down Tomcat using the shutdown hook, instead of the shutdown script, so I didn't notice it. It appears to be working now. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6990] - Catalina 4.0.2 hangs after a few days
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=6990. 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=6990 Catalina 4.0.2 hangs after a few days --- Additional Comments From [EMAIL PROTECTED] 2002-04-22 20:22 --- cool, thanks a lot for the info. I have a script that finds these spinning httpd processes and terminates them, it's a hack but it works wonderfully. Looking forward to future tomcat 4.0.x releases -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/appdev web.xml.txt
remm02/04/22 13:31:16 Modified:webapps/tomcat-docs/appdev web.xml.txt Log: - XML was not well formed. - Patch submitted by Andy Warburton andy2602 at lycos.co.uk Revision ChangesPath 1.5 +1 -1 jakarta-tomcat-4.0/webapps/tomcat-docs/appdev/web.xml.txt Index: web.xml.txt === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/appdev/web.xml.txt,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- web.xml.txt 12 Feb 2002 23:51:40 - 1.4 +++ web.xml.txt 22 Apr 2002 20:31:16 - 1.5 @@ -76,7 +76,7 @@ description This servlet plays the controller role in the MVC architecture used in this application. It is generally mapped to the .do -filename extension with a servlet-mapping element, and all form +filename extension with a servlet-mapping element, and all form submits in the app will be submitted to a request URI like saveCustomer.do, which will therefore be mapped to this servlet. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/appdev web.xml.txt
remm02/04/22 13:31:57 Modified:webapps/tomcat-docs/appdev Tag: tomcat_40_branch web.xml.txt Log: - XML was not well formed (bug 8344). - Patch submitted by Andy Warburton andy2602 at lycos.co.uk Revision ChangesPath No revision No revision 1.2.2.3 +1 -1 jakarta-tomcat-4.0/webapps/tomcat-docs/appdev/web.xml.txt Index: web.xml.txt === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/appdev/web.xml.txt,v retrieving revision 1.2.2.2 retrieving revision 1.2.2.3 diff -u -r1.2.2.2 -r1.2.2.3 --- web.xml.txt 13 Feb 2002 01:11:25 - 1.2.2.2 +++ web.xml.txt 22 Apr 2002 20:31:57 - 1.2.2.3 @@ -76,7 +76,7 @@ description This servlet plays the controller role in the MVC architecture used in this application. It is generally mapped to the .do -filename extension with a servlet-mapping element, and all form +filename extension with a servlet-mapping element, and all form submits in the app will be submitted to a request URI like saveCustomer.do, which will therefore be mapped to this servlet. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8344] - Badly formed XML doc
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=8344. 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=8344 Badly formed XML doc [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-04-22 20:32 --- Fixed. Thanks. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs realm-howto.xml
remm02/04/22 13:45:52 Modified:webapps/tomcat-docs Tag: tomcat_40_branch realm-howto.xml Log: - Fix JDBC URL (bug 7580). - Patch submitted by Konrad Jagodziñski konrad at hansin.com.pl Revision ChangesPath No revision No revision 1.2.2.2 +1 -1 jakarta-tomcat-4.0/webapps/tomcat-docs/realm-howto.xml Index: realm-howto.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/realm-howto.xml,v retrieving revision 1.2.2.1 retrieving revision 1.2.2.2 diff -u -r1.2.2.1 -r1.2.2.2 --- realm-howto.xml 26 Mar 2002 14:18:44 - 1.2.2.1 +++ realm-howto.xml 22 Apr 2002 20:45:52 - 1.2.2.2 @@ -280,7 +280,7 @@ source lt;Realm className=org.apache.catalina.realm.JDBCRealm debug=99 driverName=org.gjt.mm.mysql.Driver - connectionURL=jdbc:mysql://localhost/authority?user=dbuser;password=dbpass + connectionURL=jdbc:mysql://localhost/authority?user=dbuseramp;password=dbpass userTable=users userNameCol=user_name userCredCol=user_pass userRoleTable=user_roles roleNameCol=role_name/gt; /source -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7580] - Wrong URL for jdbc connection
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=7580. 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=7580 Wrong URL for jdbc connection [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-04-22 20:46 --- Fixed. Thanks. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6908] - JavaCompiler interface setOutputDir always called with null parameter
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=6908. 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=6908 JavaCompiler interface setOutputDir always called with null parameter [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2002-04-22 20:50 --- When I executed the test page index.jsp, and got the expected reponse The lines below are just some jsp code to make sure this page compiles 1 and DummyCompiler is never executed. setOutputDir has been working correctly, for both SunJavaCompiler and JikesJavaCompiler, and if it doesn't work for you, you'll just need to debug your code. Sorry. If you can find places in the source that's wrong, please submit a patch, but I examined the code again and couldn't find anything that's obviously wrong. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7558] - ClassLoader can't find classes in new created jar from zip
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=7558. 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=7558 ClassLoader can't find classes in new created jar from zip [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-04-22 20:52 --- This has already been reported. *** This bug has been marked as a duplicate of 6406 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
patch to jk_uri_worker_map.c
Hi, I was looking at jk_uri_worker_map.c because my context url maps were not working like expected. I also saw a bunch of posts on the web about this problem. I looked at the source code and I am submitting a patch to this in a different mail. Basically, I am just extracting the sub string before you do the comparison, so that the match will work. For example the current code will not work with this If the JkMount is JkMount /servlet/* worker_name then a url like http://www.xxx.yyy.zzz/myproject/servlet/MyServlet will not match. Only urls like http://www.xxx.yyy.zzz/servlet/MyServlet will match. My patch will allow urls like the first one to work. I am searching the uri string for the uwr-context instead of doing an exact strncmp. I have tested this and it works on my setup. I am sending my patch in the next e-mail. Please let me know if you guys think I should change anything. Also as you guys can probably tell this is my first patch I am submitting to the list :-). What's the right way to get this patch in the source tree. I tried sending messages to [EMAIL PROTECTED] and [EMAIL PROTECTED] and nothing useful came out of it. If this was a planned feature I apologise. Thank you, Aravind Gottipati -- Let me put it this way: today is going to be a learning experience -- Anonymous (seen on slashdot) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] to jk_uri_worker_map.c (fix url matching for context matches)
Index: jk_uri_worker_map.c
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/native/common/jk_uri_worker_map.c,v
retrieving revision 1.13
diff -u -r1.13 jk_uri_worker_map.c
--- jk_uri_worker_map.c 7 Dec 2001 00:57:16 - 1.13
+++ jk_uri_worker_map.c 22 Apr 2002 01:27:15 -
@@ -469,9 +469,7 @@
continue; /* can not be a best match anyway */
}
-if(0 == strncmp(uwr-context,
-uri,
-uwr-ctxt_len)) {
+if (strstr(uri, uwr-context)) {
if(MATCH_TYPE_EXACT == uwr-match_type) {
if(strlen(uri) == uwr-ctxt_len) {
jk_log(l,
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/doc mod_jk-howto.html
Hi Glenn,
Could you update at least the apache2 connector ? This features makes
sense on all servers actually ( i.e. IIS, etc ) - but we should have it
at least in 1.3 and 2.0.
Also, any chance to update this on native2 ? I'll do it later if you don't
have the time.
Costin
On 21 Apr 2002 [EMAIL PROTECTED] wrote:
glenn 02/04/21 15:57:11
Modified:jk/native/apache-1.3 mod_jk.c
jk/native/common jk_logger.h jk_uri_worker_map.c jk_util.c
jk/doc mod_jk-howto.html
Log:
Apache mod_jk 1.2 new features.
Added JkRequestLogFormat for Apache style request logging
including Tocmat request latency in seconds and microseconds.
Added JkAutoAlias, this can be used to automatically Alias
web application context directories so that static files
can be served by Apache instead of Tomcat. When configured,
requests for a WAR file in the Tomcat appBase (webapps) directory
are forbidden. Requests for the WEB-INF and META-INF directories
within a web application context dir are also forbidden and will
return an HTTP 403 error.
Added ability to JkMount so that /*/servlet/ can be used to
configure mod_jk to pass all servlet requests on to Tomcat
for any web application context.
Revision ChangesPath
1.26 +521 -12 jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- mod_jk.c3 Apr 2002 00:49:19 - 1.25
+++ mod_jk.c21 Apr 2002 22:57:11 - 1.26
@@ -61,7 +61,7 @@
* Author: Gal Shachor [EMAIL PROTECTED] *
* Dan Milstein [EMAIL PROTECTED]*
* Henri Gomez [EMAIL PROTECTED] *
- * Version: $Revision: 1.25 $ *
+ * Version: $Revision: 1.26 $ *
***/
/*
@@ -101,6 +101,7 @@
#define JK_WORKER_ID(jakarta.worker)
#define JK_HANDLER (jakarta-servlet)
+#define JK_DURATION (jakarta.worker.duration)
#define JK_MAGIC_TYPE (application/x-jakarta-servlet)
#define NULL_FOR_EMPTY(x) ((x !strlen(x)) ? NULL : x)
@@ -139,6 +140,18 @@
jk_uri_worker_map_t *uw_map;
/*
+ * Automatic context path apache alias
+ */
+char *alias_dir;
+
+/*
+ * Request Logging
+ */
+
+char *format_string;
+array_header *format;
+
+/*
* SSL Support
*/
int ssl_enable;
@@ -742,7 +755,7 @@
/*
* JkLogLevel Directive Handling
*
- * JkLogLevel debug/info/error/emerg
+ * JkLogLevel debug/info/request/error/emerg
*/
static const char *jk_set_log_level(cmd_parms *cmd,
@@ -773,6 +786,402 @@
}
/*
+ * JkAutoAlias Directive Handling
+ *
+ * JkAutoAlias application directory
+ */
+
+static const char *jk_set_auto_alias(cmd_parms *cmd,
+void *dummy,
+char *directory)
+{
+server_rec *s = cmd-server;
+jk_server_conf_t *conf =
+(jk_server_conf_t *)ap_get_module_config(s-module_config, jk_module);
+
+conf-alias_dir = directory;
+
+if (conf-alias_dir == NULL)
+return JkAutoAlias directory invalid;
+
+return NULL;
+}
+
+/*
+ *
+ * Actually logging.
+ */
+
+typedef const char *(*item_key_func) (request_rec *, char *);
+
+typedef struct {
+item_key_func func;
+char *arg;
+} request_log_format_item;
+
+static const char *process_item(request_rec *r,
+ request_log_format_item *item)
+{
+const char *cp;
+
+cp = (*item-func) (r,item-arg);
+return cp ? cp : -;
+}
+
+static int request_log_transaction(request_rec *r,
+ jk_server_conf_t *conf)
+{
+request_log_format_item *items;
+char *str, *s;
+int i;
+int len = 0;
+const char **strs;
+int *strl;
+array_header *format = conf-format;
+
+strs = ap_palloc(r-pool, sizeof(char *) * (format-nelts));
+strl = ap_palloc(r-pool, sizeof(int) * (format-nelts));
+items = (request_log_format_item *) format-elts;
+for (i = 0; i
[PATCH] org.apache.catalina.connector.warp.WarpRequestHandler.java
Could someone please tell me what I need to do to get the attached patch committed? It fixes a NullPointerException thrown when the Warp Connector is used with a user-data-constraint. I got the original file from the archive located here http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.4-b2/src/jakarta-tomcat-connectors-4.0.4-b2-src.zip --- WarpRequestHandler.java.orginal Mon Apr 22 15:30:03 2002 +++ WarpRequestHandler.java Mon Apr 22 15:30:56 2002 @@ -101,6 +101,7 @@ response.setConnection(connection); response.setPacket(packet); request.setConnection(connection); +request.setConnector(connector); // Prepare the Proceed packet packet.reset(); -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] possible speed enhancement to JspServlet.java
Duncan, I looked at your patch carefully, looks like Remy's work on jasper2 already addressed the issues that you are trying to solved. In fact, Remy only creates a compiler for the container, whereas you would have created a compiler for each jsp page. OTOH, you save the modification date for each page in a hashtable, so is potentially faster when checking whether a jsp needs to be send to the compiler. I may incoporate your idea on this one later, maybe reusing the JspServletWrapper class instead of using another hashtabl, since that **IS** a per page object. Thanks again for the patch. If you wish, you should try running with japser2, and compare its performance with the one you patched. Date: Fri, 19 Apr 2002 16:58:54 -0700 (PDT) From: Kin-Man Chung [EMAIL PROTECTED] Subject: Re: [PATCH] possible speed enhancement to JspServlet.java To: [EMAIL PROTECTED] MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-MD5: Pd6UqZXWO7AIRUPw9V+AAQ== Delivered-to: mailing list [EMAIL PROTECTED] Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N List-Post: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Id: Tomcat Developers List tomcat-dev.jakarta.apache.org Thank you for the patch! It looks interesting! I'll definitely look at it carefully and apply it to jasper or jasper2 when I have time, most probably sometime next week. Date: Fri, 19 Apr 2002 17:09:49 -0400 From: Duncan McLean [EMAIL PROTECTED] Subject: [PATCH] possible speed enhancement to JspServlet.java To: Tomcat Developers List [EMAIL PROTECTED] MIME-version: 1.0 Content-transfer-encoding: 7bit X-Accept-Language: en,pdf Delivered-to: mailing list [EMAIL PROTECTED] Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N List-Post: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Id: Tomcat Developers List tomcat-dev.jakarta.apache.org I'm new to this list (and the jasper code), so please let me know if I've submitted this incorrectly. I was doing some profiling of the server side environment that I work on and noticed that quite a bit of time was being used in the JSP engine. After further investigation I noticed that each JSP request that comes into the jasper engine generates a new compiler object and attempt at compilation. As much as 15% of the time of a JSP request is wasted this way. The change I made attempts to read the last modified date from the JSP file being request. A comparison is made against known last modified time for the current compiled version, if they are different then the code flows as it used to. If the times are the same then the rest of loadJSP is skipped. In my test application which relies on calling ~10 jsp files to generate a single page I found a speed improvement of ~25-50ms (on a PIII 650). There may be better ways to do this. I concentrated my fix here because it is where the profiler said the problem was. One drawback of the code I'm submitting is that if there are a large number of JSP's the Hashtable I use to store information may get large. However I can't see that being a problem until a site has 10,000 jsp's. The change I'm submitting may not be the correct way to approach the problem. Either way I think this is an issue that deserves some attention so if someone can suggest a better fix please do. -- 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]
DO NOT REPLY [Bug 8390] New: - debug logging is always on
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=8390. 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=8390 debug logging is always on Summary: debug logging is always on Product: Tomcat 4 Version: Nightly Build Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Connector:Webapp AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] debug logging is always on. This is because the while the DEBUG variable is set to false, the code uses #ifdef DEBUG instead of #if DEBUG. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8356] - Can't remove this package using rpm version 4.0.3
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=8356. 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=8356 Can't remove this package using rpm version 4.0.3 [EMAIL PROTECTED] changed: What|Removed |Added URL|http://jakarta.apache.org/bu|http://jakarta.apache.org/bu |ilds/jakarta-tomcat-|ilds/jakarta-tomcat- |4.0/release/v4.0.3/rpms/mod_|4.0/release/v4.0.3/rpms/mod_ |jk2-2.0-1.0-1.4.0.2.i386.rpm|jk2-2.0-1.0-1.4.0.2.i386.rpm -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8392] New: - Removal of
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=8392. 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=8392 Removal of Summary: Removal of Product: Tomcat 4 Version: Nightly Build Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Connector:Other AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8393] New: - Removal of WEB-INF from jk connector not noted in parent build.xml
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=8393. 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=8393 Removal of WEB-INF from jk connector not noted in parent build.xml Summary: Removal of WEB-INF from jk connector not noted in parent build.xml Product: Tomcat 4 Version: Nightly Build Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Connector:Other AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Version 1.33 of /jakarta-tomcat-connectors/jk/build.xml removed WEB-INF from the build directory. However, /jakarta-tomcat-connectors/build.xml still has this set of lines in the coyote target: fileset dir=jk/build/WEB-INF/classes include name=org/apache/** / exclude name=org/apache/jk/ant/** / /fileset Without any other information, I believe the fix is just to remove /WEB-INF from the dir attribute of the fileset element. In my testing, this makes the top-level build process succeed. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8392] - Removal of
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=8392. 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=8392 Removal of [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE Summary|Removal of |Removal of --- Additional Comments From [EMAIL PROTECTED] 2002-04-23 02:20 --- *** This bug has been marked as a duplicate of 8393 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8393] - Removal of WEB-INF from jk connector not noted in parent build.xml
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=8393. 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=8393 Removal of WEB-INF from jk connector not noted in parent build.xml --- Additional Comments From [EMAIL PROTECTED] 2002-04-23 02:20 --- *** Bug 8392 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [COMMENTS] Tomcat 4.1 release plan draft posted
Rempy, * New Coyote HTTP/1.1 connector Do you plan to replace the old HTTP connector and set it as default? +1 for this. Comments ? Remy Punky _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [COMMENTS] Tomcat 4.1 release plan draft posted
On Tue, 23 Apr 2002, Punky Tse wrote: Date: Tue, 23 Apr 2002 11:08:40 +0800 From: Punky Tse [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED], Punky Tse [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: [COMMENTS] Tomcat 4.1 release plan draft posted Rempy, * New Coyote HTTP/1.1 connector Do you plan to replace the old HTTP connector and set it as default? +1 for this. This is already the case in the nightly builds, and will thus be in the release unless someone reverses it. I agree with your +1. Comments ? Remy Punky Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tomcat in industry
Hello, I don't know where I heard it, or if indeed I heard it all, but can someone clarify if Tomcat can be used in industrial strength web applications? That is, is it able to handle for example, traffic of 100 hits p/s? Must it be integrated with the Apache web server to make it so? Where may I find such information regarding this please? Thanks Paul. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/doc mod_jk-howto.html
On Mon, 22 Apr 2002, Glenn Nielsen wrote: Hmmm, this gives me an incentive to play around with Apache 2.0. It's a nice server :-) What would help the most is a 'common' implementation - i.e. have as much as possible independent of the server. Also, any chance to update this on native2 ? I'll do it later if you don't have the time. I need to look at jk2 anyway. I'll see what I can do, I may not have the time to get to it until the weekend. No hurry. But one more hand would really help... Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Why is JDK needed to install Apache Tomcat 4.0 on WinNT?
I am trying to create a setup an application of mine for distribution among my associates. But during the installation of Tomcat 4.0, it initially checks if JDK is installed and if not, it exits the installation. Why does it need the JDK? All my target PCs have JREs installed. What should be done to disable this check in Tomcat Setup. I am in need of a solution to this urgently. Please help. Thanks and Best Regards, nKiran -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8399] New: - Nightly Build from 04/22/2002 does not shutdown
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=8399. 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=8399 Nightly Build from 04/22/2002 does not shutdown Summary: Nightly Build from 04/22/2002 does not shutdown Product: Tomcat 4 Version: Nightly Build Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I started tomcat with startup.bat (jakarta-tomcat-4.0-20020422.zip), everything runs fine but when i run shutdown.bat this doesnt work, i was running tomcat alone, and testing admin webapp. Never installed any packages than the original nightly build no ADD-ONS, And running with jdk 1.4. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
PATCH: jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_es.properties
Its not all done but now its a lot betterthan before. Cheers, Adrian Almenar ApplicationResources_es.properties.patch Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Why is JDK needed to install Apache Tomcat 4.0 on WinNT?
Maybe because TC compiles JSP's into classes and it needs javac for that, which is probably not part of the JRE. Bojan Quoting Kiran Kumar N (RBIN/DCA-NMS) [EMAIL PROTECTED]: I am trying to create a setup an application of mine for distribution among my associates. But during the installation of Tomcat 4.0, it initially checks if JDK is installed and if not, it exits the installation. Why does it need the JDK? All my target PCs have JREs installed. What should be done to disable this check in Tomcat Setup. I am in need of a solution to this urgently. Please help. Thanks and Best Regards, nKiran -- 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: Tomcat in industry
It is easy to find out. Install it on your target system, put your applications in it (i.e. JSP's, Velocity pages, servlets or whatever else you use) and run 'ab' (from Apache) on it. It will come back with the number of pages served per second. Do the above for a few days and you'll find out if it's industrial strength or not. Tomcat can run on its own or behind Apache and other popular web servers. Bojan PS. I works for me ;-) Quoting Paul Wallace [EMAIL PROTECTED]: Hello, I don't know where I heard it, or if indeed I heard it all, but can someone clarify if Tomcat can be used in industrial strength web applications? That is, is it able to handle for example, traffic of 100 hits p/s? Must it be integrated with the Apache web server to make it so? Where may I find such information regarding this please? Thanks Paul. -- 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]
