Patch for bad Implementation of the session serialization mechanism
Hi,
I've download tomcat 4.0.1 and I have the great problem with sessions, when
I've uncommented the Session Manager.
If I use configuration
Manager className="org.apache.catalina.session.PersistentManager"
debug="0"
saveOnRestart="true"
maxActiveSessions="1000"
minIdleSwap="-1"
maxIdleSwap="300"
maxIdleBackup="-1"
Store className="org.apache.catalina.session.FileStore"/
/Manager
in server.xml, all active sessions are filled with the old stored values each
one minute.
Why?
The bug is allowed by stupid implementation of harmless method
StandardSession.setId(String id)
When somebody has written the method StoreBase.processExpires() he has no
idea about problems with creating new session from file, testing its settings
and removing the session. It seems to be good idea, but the method
StandardSession.load(String) loads the session from file (correct), but it
also stores the session to the manager (throw setId(String) method) and than
it (only for testing, if the session file have to be removed) stores the
session to the manager and replaces the current, active session.
So,
I've changed three classes from org.apache.catalina.session package :
StoreBase - processExpires() is commented due the thread with the same
functonality is started by PersistentManagerBase. Other reason is the
unsynchronisation and possible "unconsistence", because the StoreBase time to
time loads session, which is not stored completely.
ManagerBase and StandardSession - adding of the new session is moved from the
StandardSession.setId() (may be called also by load() ) to the
ManagerBase.createSession() .
I know that the moving of the calling add() may be a problem because of the
removing the transparent addign to the Manager, but current implementation
doesn't work :-(((
Please test it.
All diffs are created against the source distribution of the tomcat-4.0.1 .
--
Oto 'tapik' Buchta
556a557,559
synchronized (sessions) {
add (session);
}
351,357c351,356
if ((this.id != null) (manager != null))
manager.remove(this);
this.id = id;
if (manager != null)
manager.add(this);
---
if ((this.id != null) (manager != null)) {
manager.remove(this);
this.id = id;
manager.add(this);
} else
this.id = id;
350c350
processExpires();
---
//processExpires(); This is also in PersistentManageru
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
AW: Configuring Multiple Tomcat JVMs with Apache - LoadBalancing - Attributes
Tom, I understand, looks pretty :-) You state Apache solution can be implemented without concern for this. What kind of connector will be supported mod_jk or mod_webapp ? Oliver AXA eSolutions GmbH AXA Konzern AG Germany Oliver Lauer Web Architect Wörthstraße 34 D-50668 Köln Germany Tel.: +49 221 148 31277 Fax: +49 221 148 43963 Mobil: +49 179 59 064 59 e-Mail: [EMAIL PROTECTED] _ -Ursprüngliche Nachricht- Von: Tom Drake [mailto:[EMAIL PROTECTED]] Gesendet: Montag, 17. Dezember 2001 19:18 An: Lauer, Oliver Cc: Tomcat Dev List Betreff: Re: Configuring Multiple Tomcat JVMs with Apache - Load Balancing - Attributes Oliver: No, there is no single point of failure. The way it works is thus: Each tomcat instance in a cluster (defined by a single multicast address/port): - Shall keep a copy of all sessions that it owns (created). - May be configured to be a session repository (or not). Session repositories keep copies of all sessions created by all members of the cluster. - Shall automatically discover the other instances at startup time. (instances that were started earlier and discovered, shall be notified of newly started instances). - during startup of a new 'repository', will request that it be sent copies of all known Sessions (from an arbitrary known repository). - Shall copy all new / updated sessions to all other known 'repositories' after the completion of a web request. - Shall 'lock' each owned session object while it is in use. - Shall retrieve and lock a requested session from the 'owner' if the current Tomcat is not the owner of the session. - If the owner (tomcat) has been brought down in an orderly fashion, it will transfer ownership of all of it's owned sessions to arbitrary repositories in the cluster (during it's shutdown sequence). - If the owner (tomcat) has crashed, the 1st Tomcat (repository) to receive a request for a session that was owned by the downed tomcat will become the new owner of that session. So, - There is no single point of failure. - Server/session affinity, is not required, but will provide performance benefits. - New instances may be brought on-line, and will automatically become a part of the cluster. - Existing instances may be brought down with no impact on users (other than a one-time performance hit). - Existing instances may crash with *limited* deleterious side-effects. - There must be at least two 'repository' instances in order to support the fail-over scenarios. However, the number of 'repository' instances should be limited to as small a number as is necessary to meet your fail-over needs. - This feature will only be present (and consume bandwidth) if it has been configured. Other load balancing solutions that don't require fail-over protection, such as the Tomcat 3.x / Apache solution can be implemented without concern for this. - Original Message - From: Lauer, Oliver [EMAIL PROTECTED] To: 'Tomcat Developers List' [EMAIL PROTECTED]; 'Tom Drake' [EMAIL PROTECTED] Sent: Monday, December 17, 2001 9:25 AM Subject: AW: Configuring Multiple Tomcat JVMs with Apache - Load Balancing | Tom, | | Will the repository be a single point of failure then ? | Oliver | | AXA eSolutions GmbH | AXA Konzern AG Germany | Oliver Lauer | Web Architect | Wörthstraße 34 | D-50668 Köln | Germany | Tel.: +49 221 148 31277 | Fax: +49 221 148 43963 | Mobil: +49 179 59 064 59 | e-Mail: [EMAIL PROTECTED] | _ | | | | -Ursprüngliche Nachricht- | Von: Tom Drake [mailto:[EMAIL PROTECTED]] | Gesendet: Montag, 17. Dezember 2001 18:26 | An: Tomcat Developers List | Betreff: Re: Configuring Multiple Tomcat JVMs with Apache - Load | Balancing | | | Keep in mind that with distributed sessions (coming soon to a tomcat near | you), affinity | is no longer 'required' in order to function. This provides the added | benefit of fail-over. | | Affinity is still desirable for performance reasons. However, the if the | Tomcat instance | that created the session is brought down, the user needn't be affected. | Apache | should notice this and route subsequent requests (for the affected sessions) | to another | TC instance in the cluster. The other TC instances will either already have | a copy of | the session or can retrieve it from a 'repository'. | | Tom | | - Original Message - | From: [EMAIL PROTECTED] | To: Tomcat Developers List [EMAIL PROTECTED] | Sent: Monday, December 17, 2001 9:07 AM | Subject: RE: Configuring Multiple Tomcat JVMs with Apache - Load Balancing | | | | On Mon, 17 Dec 2001, GOMEZ Henri wrote: | | | | couldn't the connector be solely | | responsible for | | this? the connector could add a cookie to the response, then read this | | cookie on subsequent requests, and then you wouldn't have to | | add stuff to | | servlet containers to handle this. or, i could be totally off base :) | | | | Could we
RE: Configuring Multiple Tomcat JVMs with Apache - Load Balancing
Session afinity is often mandatory when in situations where parts of applications are not just data, ie when your web-application is used to discuss with a real-time system requiring that all the app session came from the same JVM. And so the session afinity must be configurable. - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Monday, December 17, 2001 7:38 PM To: Tomcat Developers List; Tom Drake Subject: Re: Configuring Multiple Tomcat JVMs with Apache - Load Balancing On Mon, 17 Dec 2001, Tom Drake wrote: Keep in mind that with distributed sessions (coming soon to a tomcat near you), affinity is no longer 'required' in order to function. This provides the added benefit of fail-over. As I mentioned in a thread about this on TOMCAT-USER, there *are* session affinity requirements in the servlet specs (both 2.2 and 2.3) that should be obeyed. Craig -- 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 5479] New: - HttpRequest.getRemoteAddr() returns localhost invoking a jsp or servlet directly, without a connected web server
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=5479. 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=5479 HttpRequest.getRemoteAddr() returns localhost invoking a jsp or servlet directly, without a connected web server Summary: HttpRequest.getRemoteAddr() returns localhost invoking a jsp or servlet directly, without a connected web server Product: Tomcat 3 Version: 3.3 Final Platform: PC URL: http://www.prosa.com OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Webapps AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I installed Tomcat on my server. Invoking one of the sample jsp (http://www.prosa.com/examples/jsp/snp/snoop.jsp) returns the expected snoop values: JSP Request Method: GET Request URI: /examples/jsp/snp/snoop.jsp Request Protocol: HTTP/1.1 Servlet path: /jsp/snp/snoop.jsp Path info: null Path translated: null Query string: null Content length: 0 Content type: null Server name: www.prosa.com Server port: 80 Remote user: null Remote address: 195.120.217.111 Remote host: 195.120.217.111 Authorization scheme: null Locale: it Invoking the same jsp page bypassing the web server (http://www.prosa.com:3080/examples/jsp/snp/snoop.jsp) produces the following values: JSP Request Method: GET Request URI: /examples/jsp/snp/snoop.jsp Request Protocol: HTTP/1.1 Servlet path: /jsp/snp/snoop.jsp Path info: null Path translated: null Query string: null Content length: -1 Content type: null Server name: www.prosa.com Server port: 3080 Remote user: null Remote address: 127.0.0.1 Remote host: localhost Authorization scheme: null Locale: it -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
tomcatctl
Hello List, I was told to post this into a appropriate Tomcat mailing list and I think this should be the right one. I wrote a little script which may be interesting for the tomcat-project. It is based on the file apachectl and this is what it is about: When I installed tomcat on my Server I missed something what I could put in my /etc/rc.d/rcX.d-directories. Besides: the startup- und shutdown-files are fine, but with them I can't decide which user I want to run tomcat under. So I wrote a skript to fixes this problems. I attached it to this mail. Maybe you find this usefull and put it into the /bin-directory of the tomcat-distribution. Best regards Stephan Sann - CiBes - Computerinstallations- und Beratungsservice Inhaber: Stephan Sann, Hefehof 8 (c/o medienPARK), 31785 Hameln 0700 FON CIBES (0700 366 24237), 0700 FAX CIBES (0700 329 24237) eMail: [EMAIL PROTECTED], Internet: http://www.cibes.de #!/bin/sh # # Tomcat control script designed to start up Tomcat at boot-time and # shutdown it on system halt. Written by Stephan Sann 07.12.2001 # # The exit codes returned are: # 0 - operation completed successfully # 1 - # 2 - usage error # 3 - tomcat could not be started # 4 - tomcat could not be stopped # # When multiple arguments are given, only the error from the _last_ # one is reported. Run tomcatctl help for usage info # # # START CONFIGURATION SECTION # # # User to run Tomcat TOMCATUSER=nobody # # the path to your tomcat-installation TOMCATDIR=/usr/local/jakarta-tomcat-4.0.1 # # # END CONFIGURATION SECTION ERROR=0 ARGV=$@ if [ x$ARGV = x ] ; then ARGS=help fi for ARG in $@ $ARGS do case $ARG in start) if su - $TOMCATUSER -c $TOMCATDIR/bin/startup.sh; then echo $0 $ARG: tomcat started else echo $0 $ARG: tomcat could not be started ERROR=3 fi ;; stop) if su - $TOMCATUSER -c $TOMCATDIR/bin/shutdown.sh; then echo $0 $ARG: tomcat stopped else echo $0 $ARG: tomcat could not be stopped ERROR=4 fi ;; *) echo usage: $0 (start|stop|help) cat EOF start - start tomcat stop - stop tomcat help - this screen EOF ERROR=2 ;; esac done exit $ERROR -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5483] New: - I18N fails using AJP 1.3 with Tomcat 4.01 final / Apache 1.3.22
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=5483. 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=5483 I18N fails using AJP 1.3 with Tomcat 4.01 final / Apache 1.3.22 Summary: I18N fails using AJP 1.3 with Tomcat 4.01 final / Apache 1.3.22 Product: Tomcat 4 Version: 4.0.1 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Critical Priority: Other Component: AJP Connector AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Overview Description: I18N of web app based on ACCEPT_LANGUAGE header fails with AJP 1.3 and Tomcat 4.01 final / Apache 1.3.22. ACCEPT_LANGUAGE value is *ignored* instead the default location of the Java runtime Tomcat is running in seems to be used resulting in the deliverance of always the same language regardless of the browser´s HTTP request. Steps to reproduce: Just create a minimal web app consisting of one JSP which *prints* the language settings. Regardless of the HTTP request it seems to be always the Java runtime default setting. Actual results: Web app always delivers its contents in the same language regardless of the requested language and the available language resources. Expected result: Web app should deliver its content in the requested language falling back to its default language if no suitable language resources were found. Build date platform: Tomcat 4.01 final / AJP 1.3 / Apache 1.3.22 running on NT 4 SP 6 IE 4.0 to IE 6 with latest respective SPs and NN 4.78, NN 6.01 and NN 6.02 as browser platforms. Additional information: We *cross-tested* the mentioned minimal web app with all mentioned browsers (vendors and versions) and the described behaviour was ALWAYS reproducible. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5484] New: - ClassNotFoundException on shutdownhook thread
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=5484. 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=5484 ClassNotFoundException on shutdownhook thread Summary: ClassNotFoundException on shutdownhook thread Product: Tomcat 4 Version: 4.0.1 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In my webapp i used the ShutdownHook thread as on java.lang.RunTime , it worked well on Tomcat 3.2.3 but failed on Catalina 4.0.1 , the failur was as to ClassNotFoundException thrown from the ShutdownHook thread.The reason for that is that the WebAppClassLoader was stop() and there for fired Lifecycle error : CL stopped + ClassNotFoundException . It seems that the stop() was called earlier then expected. Invoking the start() Method(by reflection) again on the Thread ClassLoader solved the problem. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5484] - ClassNotFoundException on shutdownhook thread
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=5484. 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=5484 ClassNotFoundException on shutdownhook thread [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID Summary|ClassNotFoundException on |ClassNotFoundException on |shutdownhook thread |shutdownhook thread --- Additional Comments From [EMAIL PROTECTED] 2001-12-18 06:37 --- We support the lifecycle of the webapp, which is something different from the lifecycle of the VM itself. When the VM is stopped, all the Catalina components, including all the CL, will have been stopped already. -- 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
remm01/12/18 07:50:28
Modified:catalina/src/share/org/apache/catalina/startup Catalina.java
Log:
- Bug 5484 mentioned a shutdown hook, and that reminded me that Catalina
doesn't set one which could be used to try to do a clean shutdown of the
server when the process is killed (under Windows, it happens often when ^C
is used to close the server). This patch adds a shutdown hook which will
stop the server object.
Revision ChangesPath
1.42 +37 -5
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.41
retrieving revision 1.42
diff -u -r1.41 -r1.42
--- Catalina.java 2001/12/02 19:22:23 1.41
+++ Catalina.java 2001/12/18 15:50:28 1.42
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java,v
1.41 2001/12/02 19:22:23 patrickl Exp $
- * $Revision: 1.41 $
- * $Date: 2001/12/02 19:22:23 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java,v
1.42 2001/12/18 15:50:28 remm Exp $
+ * $Revision: 1.42 $
+ * $Date: 2001/12/18 15:50:28 $
*
*
*
@@ -97,7 +97,7 @@
* /u
*
* @author Craig R. McClanahan
- * @version $Revision: 1.41 $ $Date: 2001/12/02 19:22:23 $
+ * @version $Revision: 1.42 $ $Date: 2001/12/18 15:50:28 $
*/
public class Catalina {
@@ -490,11 +490,15 @@
definition + java.,org.apache.catalina.,org.apache.jasper.);
}
+Thread shutdownHook = new CatalinaShutdownHook();
+
// Start the new server
if (server instanceof Lifecycle) {
try {
server.initialize();
((Lifecycle) server).start();
+// Register shutdown hook
+Runtime.getRuntime().addShutdownHook(shutdownHook);
// Wait for the server to be told to shut down
server.await();
} catch (LifecycleException e) {
@@ -511,6 +515,7 @@
if (server instanceof Lifecycle) {
try {
((Lifecycle) server).stop();
+Runtime.getRuntime().removeShutdownHook(shutdownHook);
} catch (LifecycleException e) {
System.out.println(Catalina.stop: + e);
e.printStackTrace(System.out);
@@ -574,6 +579,34 @@
}
+// --- CatalinaShutdownHook Inner Class
+
+
+/**
+ * Shutdown hook which will perform a clean shutdown of Catalina if needed.
+ */
+protected class CatalinaShutdownHook extends Thread {
+
+public void run() {
+
+if (server != null) {
+try {
+((Lifecycle) server).stop();
+} catch (LifecycleException e) {
+System.out.println(Catalina.stop: + e);
+e.printStackTrace(System.out);
+if (e.getThrowable() != null) {
+System.out.println(- Root Cause -);
+e.getThrowable().printStackTrace(System.out);
+}
+}
+}
+
+}
+
+}
+
+
}
@@ -609,4 +642,3 @@
}
-
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5484] - ClassNotFoundException on shutdownhook thread
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=5484. 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=5484 ClassNotFoundException on shutdownhook thread --- Additional Comments From [EMAIL PROTECTED] 2001-12-18 07:57 --- This actually means that the Java ShutdownHook is *not available* when developing webapps for Catalina ! is that what we want ?! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/webapp/java WarpConnector.java
Ah! That is why it stops building against 4.0.1 ;-(
[EMAIL PROTECTED] wrote:
remm01/11/30 23:20:29
Modified:webapp/java WarpConnector.java
Log:
- Add the findLifecycleListeners method, so that webapp builds against the
HEAD of the CVS.
Revision ChangesPath
1.26 +8 -0 jakarta-tomcat-connectors/webapp/java/WarpConnector.java
Index: WarpConnector.java
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/java/WarpConnector.java,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- WarpConnector.java2001/10/31 08:10:29 1.25
+++ WarpConnector.java2001/12/01 07:20:29 1.26
@@ -449,6 +449,14 @@
}
/**
+ * Get the lifecycle listeners associated with this lifecycle. If this
+ * Lifecycle has no listeners registered, a zero-length array is returned.
+ */
+public LifecycleListener[] findLifecycleListeners() {
+return lifecycle.findLifecycleListeners();
+}
+
+/**
* Remove a codeLifecycleEvent/code listener from this
* codeConnector/code.
*
--
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 5486] New: - Standard EA3 Taglib import does not work with if-modified-since http header field
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=5486. 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=5486 Standard EA3 Taglib import does not work with if-modified-since http header field Summary: Standard EA3 Taglib import does not work with if- modified-since http header field Product: Tomcat 4 Version: 4.0.1 Final Platform: Sun OS/Version: Solaris Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I'm not sure what is causing this problem, whether it is the Standard taglib implementation or a bug in Tomcat 4.0.1 but the taglib people pointed the finger this way ;-) Basically, I am trying to use the new Standard taglib to perform XSL transformations. What my pages do is use the core:import tag to load an XSL from a local resource file and pass it to a xml:transform. This works fine under IE 5.5 and Netscape but under Opera 5 and 6 I get very strange behaviour. The first time I visit the page it works fine, but if I visit the page from another page the import does not happen. The attribute in the page context has been created but it is empty. I have created a small web archive to demostrate this and have attached it. You will need to put the EA3 jars in the WEB-INF lib directory before it works. To get this strange behaviour you have to vist the two pages using the links provided. After a couple of visits the imported text on the first page does not get displayed unless you do a refresh on that page. I have also included a request/response dump from catalina which shows this procedure first done with IE and then using Opera. The only major difference that I can see is the if-modified-since field. After further testing it seems it is definiately to do with the if-modified-since field, something that Opera always provides once it has seen a page but IE does not seem to. I have created a little Java program to do this, you will have to edit it to provide the correct URL! Thanks. Sam. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5486] - Standard EA3 Taglib import does not work with if-modified-since http header field
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=5486. 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=5486 Standard EA3 Taglib import does not work with if-modified-since http header field --- Additional Comments From [EMAIL PROTECTED] 2001-12-18 08:56 --- Created an attachment (id=916) Request response debug output from Tomcat 4.0.1 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5486] - Standard EA3 Taglib import does not work with if-modified-since http header field
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=5486. 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=5486 Standard EA3 Taglib import does not work with if-modified-since http header field --- Additional Comments From [EMAIL PROTECTED] 2001-12-18 08:57 --- Created an attachment (id=918) Java http request code that shows the same problem. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5487] New: - Jasper does not recognize end tags with trailing spaces
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=5487. 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=5487 Jasper does not recognize end tags with trailing spaces Summary: Jasper does not recognize end tags with trailing spaces Product: Tomcat 4 Version: 4.0.1 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Minor Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Saw this in a JSP file, not confirmed with a JSP document (ie full XML) yet, but eg custom:tag/custom:tag will cause jasper to throw an exception that it has reached the end of parsing without finding a matching end tag, possible nesting error?. This may be a problem in the 3.x series as well - I eventually traced the problem using NetBeans 3.3 which IIRC uses tomcat 3.2.something as its JSP engine; similar errors came out there. The particular spec this violates is the XML one, production 42, for end tags: http://www.w3.org/TR/REC-xml#NT-ETag Very minor as there is an obvious workaround (don't put whitespace in there :o) ) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5487] - Jasper does not recognize end tags with trailing spaces
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=5487. 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=5487 Jasper does not recognize end tags with trailing spaces --- Additional Comments From [EMAIL PROTECTED] 2001-12-18 09:25 --- Re reading my submission I think I could have been clearer. Whitespace inside an end tag will prevent jasper from matching the end tag with anything. This whitespace would appear to be legal even in non-xml JSPs, since, (quoting the 1.2-fcs-spec, which is still fairly vague on this point): sec 2.3.3: Action elements follow the syntax of an XML element. sec 2.3.7: This specification follows the whitespace behaviour defined for XML. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Netbeans/tomcat work around for unavailable source code problem while trying to debug servlets
In June David Karr wrote that he was unable to debug Servlets with Netbeans while the debugger could not find the source code - unavailable source file. I have circumvented this problem on windows by using the SUBST command. After following the instructions listed at http://www.netbeans.org/articles/faqs/web_apps.html ( Using the IDE to debug servlets ) I created a drive mapping for the directory which contained the code that I wanted to debug. For example the actual directory was D:\Programme\tomcat-3.2.2\webapps\pdfdemo\WEB-INF so I did SUBST N D:\Programme\tomcat-3.2.2\webapps\pdfdemo\WEB-INF and then mounted the classes directory from with NetBeans. Hope this helps. Mit freundlichen Grüßen William Pennoyer Danet Internet Solutions GmbH TalkTo: (06151) 868-846 FaxTo: (06151) 868-666 MailTo: [EMAIL PROTECTED] WalkTo: Gutenbergstrasse 10 - 64331 Pennoyer, William.vcf -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Load balancing - fail-over support with mod_webapp
I have two questions about mod_webapp and/or mod_jk. But first a little background: Most of you know that I'm working on a distributed session management solution the purpose for which is to provide fail-over capability in the context of a load balanced environment. By fail-over, I mean that in a cluster of Tomcat instances that are front-ended by Apache (as a load manager or proxy), any of the tomcat instances could be brought down (or crash) without the user knowing it. This requires that the load-balancing front-end route requests for sessions on the downed Tomcat instance to a different tomcat instance. It also means that all session data that was 'hosted' on the downed tomcat has been stored somewhere else in the cluster and is available to any tomcat instance. The bulk of this work (to manage the distribution of session data) is complete, I'm now in the process of integrating it with the Tomcat 4.x. As an aside, It could also be integrated with Tomcat 3.x should someone desperately require it. I haven't been able to find much information about mod_webapp and how it is supposed to work (for load balancing). I can only assume that it is similar to mod_jk's load balancing behavior. My understanding of this is that Apache will remember which tomcat instance 'created' each JSESSIONID, and route subsequent requests to the tomcat instance that was responsible for creating that session. First question: Are my above assumptions correct? If not, can someone provide a more accurate description of the intended behavior or point me to the place that does? If my assumptions are correct, this means that fail-over cannot occur, since requests are only routed to the tomcat instance that 'created' the given JSESSIONID. Second question: How can I go about getting the necessary connector level changes made that will support re-routing of requests for sessions hosted on a 'downed' tomcat to some other tomcat? This re-routing of requests is critical. Without it fail-over is simply not possible. Regards, Tom Drake President, software/etc inc. Cell: 408-505-6864 Email: [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/webapp/java WarpConnector.java
Ah! That is why it stops building against 4.0.1 ;-(
That's a backward compatible change, and it's very low impact. If you add
the method, it will still build with 4.0, 4.0.x, and the HEAD branch.
Remy
[EMAIL PROTECTED] wrote:
remm01/11/30 23:20:29
Modified:webapp/java WarpConnector.java
Log:
- Add the findLifecycleListeners method, so that webapp builds against
the
HEAD of the CVS.
Revision ChangesPath
1.26 +8 -0
jakarta-tomcat-connectors/webapp/java/WarpConnector.java
Index: WarpConnector.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/webapp/java/WarpConnector.java,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- WarpConnector.java2001/10/31 08:10:29 1.25
+++ WarpConnector.java2001/12/01 07:20:29 1.26
@@ -449,6 +449,14 @@
}
/**
+ * Get the lifecycle listeners associated with this lifecycle. If
this
+ * Lifecycle has no listeners registered, a zero-length array is
returned.
+ */
+public LifecycleListener[] findLifecycleListeners() {
+return lifecycle.findLifecycleListeners();
+}
+
+/**
* Remove a codeLifecycleEvent/code listener from this
* codeConnector/code.
*
--
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]
DO NOT REPLY [Bug 5488] New: - Parser error with language encoding Cp1252
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=5488. 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=5488 Parser error with language encoding Cp1252 Summary: Parser error with language encoding Cp1252 Product: Tomcat 4 Version: 4.0.1 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The Java 2 SDK EE deploytool includes the machine's default language encoding in the web.xml it creates. On the NT and Win2K platforms the default US language is Cp1252 and deploytool inserts ?xml version=1.0 encoding=Cp1252? which generates a sax parsing exception: The encoding Cp1252 is not supported. Tomcat 3.2 accepts the XML as generated by deploytool; the parsing error occurs in the 4.0.1 binaries for Win32. The workaround is to remove the encoding attribute from the XML after Tomcat expands the WAR file. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5489] New: - Typos in resource-env-ref example
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=5489. 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=5489 Typos in resource-env-ref example Summary: Typos in resource-env-ref example Product: Tomcat 4 Version: Nightly Build Platform: All URL: http://jakarta.apache.org/tomcat/tomcat-4.0-doc/jndi- resources-howto.html OS/Version: All Status: NEW Severity: Minor Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] JNDI Resources HOW-TO. In section 2 of 'Generic JavaBean Resources' there are 3 typos 1. Description. Should be description 2. /Description. Should be /description 3. resource-env-ref...resource-env-ref. The last tag should be /resource-env-ref. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs jndi-resources-howto.xml
remm01/12/18 10:17:44 Modified:webapps/tomcat-docs jndi-resources-howto.xml Log: - Fix typos in example. Submitted by Janek Bogucki janekdb at yahoo.co.uk Revision ChangesPath 1.11 +3 -3 jakarta-tomcat-4.0/webapps/tomcat-docs/jndi-resources-howto.xml Index: jndi-resources-howto.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/jndi-resources-howto.xml,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- jndi-resources-howto.xml 2001/11/30 07:00:36 1.10 +++ jndi-resources-howto.xml 2001/12/18 18:17:44 1.11 @@ -201,16 +201,16 @@ source lt;resource-env-refgt; - lt;Descriptiongt; + lt;descriptiongt; Object factory for MyBean instances. - lt;/Descriptiongt; + lt;/descriptiongt; lt;resource-env-ref-namegt; bean/MyBeanFactory lt;/resource-env-ref-namegt; lt;resource-env-ref-typegt; com.mycompany.MyBean lt;/resource-env-ref-typegt; -lt;resource-env-refgt; +lt;/resource-env-refgt; /source pstrongWARNING/strong - Be sure you respect the element ordering -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5479] - HttpRequest.getRemoteAddr() returns localhost invoking a jsp or servlet directly, without a connected web server
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=5479. 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=5479 HttpRequest.getRemoteAddr() returns localhost invoking a jsp or servlet directly, without a connected web server [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2001-12-18 10:18 --- *** This bug has been marked as a duplicate of 4564 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4564] - request.getRemoteAddr() and AccesLog not working
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=4564. 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=4564 request.getRemoteAddr() and AccesLog not working [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2001-12-18 10:18 --- *** Bug 5479 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: Load balancing - fail-over support with mod_webapp
Hi, I have been working on load balancing Apache/Tomcat clusters. In mod_jk, the fail-over is done in the function get_most_suitable_worker. Basically if the worker who initiated the session is available (i.e. not in error state), use it, otherwise loop through the workers and select either the one with the lowest load balancing value OR one that has been in error for at least WAIT_BEFORE_RECOVER seconds if such worker exists. Thus the faulted workers are privileged when selecting a worker for a request whose worker designated by the jvmroute is not available. There is though no algorithm implemented which will map all requests to the same 'backup' worker, thus either the worker which created the session (the one in the jvmroute) is available, either another worker will be selected, but in the latter case there is no guarantee that 'second choice' will be the same for the next requests. Therefore re-routing does exist in mod_jk and works, but it is not optimal for your case, the worst thing being the dispatching of incoming requests to a different worker each time, your distributed session management would therefore give the parenting of the session to a different worker each time, far from optimal! Mathias. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5490] New: - references to non-existant URL's cause tomcat to hang
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=5490. 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=5490 references to non-existant URL's cause tomcat to hang Summary: references to non-existant URL's cause tomcat to hang Product: Tomcat 3 Version: 3.2.3 Final Platform: PC URL: https://secure1.csz.com/thankyou.jsp OS/Version: Linux Status: NEW Severity: Major Priority: Other Component: Connectors AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] web server: Apache-ssl connector: mod-jk Refering to a .jsp page in the parent directory causes tomcat to start a java process which never completes and consumes all available CPU. Work around is to start tomcat 'niced'. All contexts are sub-directories off of the secure server's home directory so tomcat should not be processing .jsp pages. If a non-existant page is refered to within a context, the page not found error is properly returned. Potential denial of service impact. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Load balancing - fail-over support with mod_webapp
Hi Mathias, Maybe you could contribute some docs, you seem very familiar with the subject ! Code would be even better :-) In jk2 it should be possible for 'callbacks' to change anything, and all the information about lb is exposed in accessible structures ( private data has been greatly reduced ). That means a tomcat that takes over for a falled one could ( during the negotiation phase ) add a mapping ( probably we need a 'redirect' table in uriMap ). BTW, one thing that we should add is 'greacefull shutdown' - that will also be done ( probably ) using a callback ( i.e. have only sticky requests forwarded to a tomcat instance ). Costin On Tue, 18 Dec 2001, Mathias Herberts wrote: Hi, I have been working on load balancing Apache/Tomcat clusters. In mod_jk, the fail-over is done in the function get_most_suitable_worker. Basically if the worker who initiated the session is available (i.e. not in error state), use it, otherwise loop through the workers and select either the one with the lowest load balancing value OR one that has been in error for at least WAIT_BEFORE_RECOVER seconds if such worker exists. Thus the faulted workers are privileged when selecting a worker for a request whose worker designated by the jvmroute is not available. There is though no algorithm implemented which will map all requests to the same 'backup' worker, thus either the worker which created the session (the one in the jvmroute) is available, either another worker will be selected, but in the latter case there is no guarantee that 'second choice' will be the same for the next requests. Therefore re-routing does exist in mod_jk and works, but it is not optimal for your case, the worst thing being the dispatching of incoming requests to a different worker each time, your distributed session management would therefore give the parenting of the session to a different worker each time, far from optimal! Mathias. -- 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]
Q about working on a bug
I submitted a refactoring for o-a-j-JspC as a patch. There is now a bug report (5471) that will likely require changes to JspC. Should I use the CVS latest as my starting point? or the refactored code? What would make it easier? - Dave _ Chat with friends online, try MSN Messenger: http://messenger.msn.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Ever increasing heap size with Tomcat 3.2.3 !!!
Hello, Before my manager insists that we switch to JRun, can any of the Tomcat developers help with a problem of an ever increasing heap size of the Tomcat java.exe. ?? (We are running Tomcat 3.2.3 and JRE1.3.1. and the IIS redirector) We are running a load test using LoadRunner scripts on some JSP and servlets that are running under Tomcat. The load is not all that heavy but the heap size of the Tomcat java.exe process keeps growing and growing. We modified the java command line to start with -Xmx128m to allow 128 MB of heap but we still max out after a day or so. We even modified one of our servlets to create a thread that runs Runtime.gc() every 30 seconds. The LoadRunner scripts just keep logging in the same 5 people via our authentication servlet so you would think memory use would level out at some point. Nothing we do seems to keep the heap size from growing. Are there known issues with Tomcat and heap size?? Doing a web search revealed numerous posts with people having similar problems so I believe there is a problem. The standard response these people receive is to increase the heap size via -Xmx But that seems like a band-aid rather than a real solution. That just delays the inevitable. Any insight as to how to keep the Tomcat process from grabbing more and more memory would be appreciated. Thanks, Keith
DO NOT REPLY [Bug 5490] - references to non-existant URL's cause tomcat to hang
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=5490. 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=5490 references to non-existant URL's cause tomcat to hang [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID Version|3.2.3 Final |3.1.1 Final --- Additional Comments From [EMAIL PROTECTED] 2001-12-18 11:09 --- found error in mod-jk.conf file. there was no corresonding context in server.xml. Red face. sorry for the noise. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: load balancing - integration thoughts
Hi Tom, hi Craig!
Another approach would be to extend the event model that is used for Session
(Servlet Spec SRV.10.1/SRV15.1.13) to fire events when a request is
completed..
Craig, would it be compliant with the spec to add another subclass of
SessionEvent (Maybe SessionRequestEvent)?
Then you could register your manager with newly created sessions as a
SessionListener.
Mika
- Original Message -
From: Tom Drake [EMAIL PROTECTED]
To: Mika Goeckel [EMAIL PROTECTED]
Cc: Craig McClanahan [EMAIL PROTECTED]
Sent: Tuesday, December 18, 2001 8:50 PM
Subject: load balancing - integration thoughts
Mika and/or Craig:
After having looked around the code, here's my thoughts
about how to implement 'end-of-request' notification. Because
we need post session updates to the 'other' repositories,
and 'unlock' the session at the end of each Http request.
Can you review and comment? Being new to Tomcat, I'd
like some confirmation that I'm on the right track, or some
gentle guidance.
o.a.c.Manager.java
- add new method
public void completeRequest(String sessionId);
o.a.c.session.ManagerBase.java
- add new method
public void completeRequest(String sessionId) {
// noop - non-distributed sessions don't care.
}
o.a.c.Request.java
- add new method
public void completeRequest();
o.a.c.connector.ResponseBase.java
- modify 'finishResponse()' by adding the following code
getRequest().completeRequest();
o.a.c.connector.RequestBase.java
- add new method
public void completeRequest() {
if (session != null) {
manager.completeRequest(session.getId());
}
}
o.a.c.session.RepositoryManager - new class that extends
StandardManager.java.
public void completeRequest(String sessionId) {
// deal with updating the remote repositories here
}
There's lots of other code in RepositoryManager, I just wanted to focus
on the end-of-request notification bits.
Regards,
Tom Drake
President, software/etc inc.
Email: [EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] jakarta-tomcat-4.0/webapps/admin
Hi,
Please commit my patch to the HEAD branch.
Sincerely,
Manveen
==
Comments:
-
This is a fix for the bug:
The selected node does not get highlighted when the node is selected.
Made changes so that the tree also gets refreshed with each node selection,
along with loading the appropriate content in the content frame.
Index: WEB-INF/classes/org/apache/webapp/admin/TreeControlTag.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/TreeControlTag.java,v
retrieving revision 1.5
diff -u -r1.5 TreeControlTag.java
--- WEB-INF/classes/org/apache/webapp/admin/TreeControlTag.java 2001/12/16 19:38:02
1.5
+++ WEB-INF/classes/org/apache/webapp/admin/TreeControlTag.java 2001/12/18 20:10:38
@@ -397,6 +397,9 @@
String action = replace(getAction(), ${name}, encodedNodeName);
+String updateTreeAction =
+replace(getAction(), tree=${name}, select= +
+encodedNodeName);
+
out.print(td);
if ((action != null) !node.isLeaf()) {
out.print(a href=\);
@@ -448,6 +451,10 @@
out.print(target);
out.print(\);
}
+ // to refresh the tree in the same 'self' frame
+out.print( onclick=\);
+out.print(self.location.href=' + updateTreeAction + ');
+out.print(\);
out.print();
}
out.print(img src=\);
@@ -484,6 +491,10 @@
out.print(labelStyle);
out.print(\);
}
+ // to refresh the tree in the same 'self' frame
+out.print( onclick=\);
+out.print(self.location.href=' + updateTreeAction + ');
+out.print(\);
out.print();
} else if (labelStyle != null) {
out.print(span class=\);
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Load balancing - fail-over support with mod_webapp
Tom Drake wrote: Mathias; Thanks for your very informative reply. From your reply, it seems that mod_jk comes close to doing what I want, and should actually provide the fail-over I'm looking for, however not in the most optimal way. What would be involved in adding (optionally configured) logic to mod_jk that would prefer another running instance over a downed instance, and then remember this as the 'jvmroute' for the given JSESSIONID? Humm the design Gal Shachor did for mod_jk is pretty slick, there is no need to maintain any session table in Apache memory as the jvmroute is part of the session id. Therefore I do not see any way coherent with that design to re-route a given session id (containing a jvmroute not to be used) to a new Tomcat in a sticky way. My best shot would be, the first time a request is received on a Tomcat which did not issue it, to reissue Set-Cookie and Set-Cookie2 headers to force a new session id to be used. Therefore the mapping would be explicit in the new session id. The new session id would have to be used also in URL rewritings. This solution would provide the re-mapping you requested and the new Tomcat would become the new session parent. There are though several drawbacks to issueing a new session id. First the marketing guys won't be happy :-) Their client tracking would probably suffer from this change of session id, even if the end user doesn't notice anything. Second, depending if you use load balancing equipment before the Apache servers, and what kind of stickyness you use those equipments with, you could end up with non optimal routings of requests, but that's only minor since it will only apply to sessions that were on the downed worker initially. Can you provide any insights into mod_webapp? Nope, I only dug into mod_jk for now. Mathias. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] Bug 5471 - JspC broken when compiling webapps
This patch changes CommandLineContext.getServletPackageName() to return a package name based on the path to the JSP as well as the package name supplied on the command line. Without a change like this, a webapp that has files with the same name, such as index.jsp, in more than one place is compiled incorrectly, with both JSP files being mapped to the same servlet. With this patch, the java files are placed in the correct directories, and generation of web.xml works. This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail. bug5471.patch Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: load balancing - integration thoughts
Mika:
That would certainly work. However, would this mean that
all SessionListeners would start picking up this new event?
Tom
- Original Message -
From: Mika Goeckel [EMAIL PROTECTED]
To: Tom Drake [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: Craig McClanahan [EMAIL PROTECTED]
Sent: Tuesday, December 18, 2001 12:12 PM
Subject: Re: load balancing - integration thoughts
| Hi Tom, hi Craig!
|
| Another approach would be to extend the event model that is used for
Session
| (Servlet Spec SRV.10.1/SRV15.1.13) to fire events when a request is
| completed..
| Craig, would it be compliant with the spec to add another subclass of
| SessionEvent (Maybe SessionRequestEvent)?
|
| Then you could register your manager with newly created sessions as a
| SessionListener.
|
| Mika
|
| - Original Message -
| From: Tom Drake [EMAIL PROTECTED]
| To: Mika Goeckel [EMAIL PROTECTED]
| Cc: Craig McClanahan [EMAIL PROTECTED]
| Sent: Tuesday, December 18, 2001 8:50 PM
| Subject: load balancing - integration thoughts
|
|
| Mika and/or Craig:
|
| After having looked around the code, here's my thoughts
| about how to implement 'end-of-request' notification. Because
| we need post session updates to the 'other' repositories,
| and 'unlock' the session at the end of each Http request.
|
| Can you review and comment? Being new to Tomcat, I'd
| like some confirmation that I'm on the right track, or some
| gentle guidance.
|
| o.a.c.Manager.java
| - add new method
| public void completeRequest(String sessionId);
|
| o.a.c.session.ManagerBase.java
| - add new method
| public void completeRequest(String sessionId) {
| // noop - non-distributed sessions don't care.
| }
|
| o.a.c.Request.java
| - add new method
| public void completeRequest();
|
| o.a.c.connector.ResponseBase.java
| - modify 'finishResponse()' by adding the following code
| getRequest().completeRequest();
|
| o.a.c.connector.RequestBase.java
| - add new method
| public void completeRequest() {
| if (session != null) {
| manager.completeRequest(session.getId());
| }
| }
|
| o.a.c.session.RepositoryManager - new class that extends
| StandardManager.java.
|
| public void completeRequest(String sessionId) {
| // deal with updating the remote repositories here
| }
|
| There's lots of other code in RepositoryManager, I just wanted to focus
| on the end-of-request notification bits.
|
|
| Regards,
|
| Tom Drake
| President, software/etc inc.
| Email: [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: Load balancing - fail-over support with mod_webapp
Mathias: In Tomcat 4, unless I'm not reading the code correctly, or completely, it doesn't appear that that any routing information is stored in the session id. Can anyone comment on this? Tom - Original Message - From: Mathias Herberts [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, December 18, 2001 12:23 PM Subject: Re: Load balancing - fail-over support with mod_webapp | Tom Drake wrote: | | Mathias; | | Thanks for your very informative reply. From your reply, it seems | that mod_jk comes close to doing what I want, and should actually | provide the fail-over I'm looking for, however not in the most | optimal way. | | What would be involved in adding (optionally configured) logic to | mod_jk that would prefer another running instance over a downed | instance, and then remember this as the 'jvmroute' for the given | JSESSIONID? | | Humm the design Gal Shachor did for mod_jk is pretty slick, there | is no need to maintain any session table in Apache memory as the | jvmroute | is part of the session id. | | Therefore I do not see any way coherent with that design to re-route | a given session id (containing a jvmroute not to be used) to a new | Tomcat in a sticky way. | | My best shot would be, the first time a request is received on a Tomcat | which did not issue it, to reissue Set-Cookie and Set-Cookie2 headers to | force a new session id to be used. Therefore the mapping would be | explicit in | the new session id. The new session id would have to be used also in URL | rewritings. | | This solution would provide the re-mapping you requested and the new | Tomcat would | become the new session parent. | | There are though several drawbacks to issueing a new session id. | | First the marketing guys won't be happy :-) Their client tracking would | probably suffer from this change of session id, even if the end user | doesn't notice anything. | | Second, depending if you use load balancing equipment before the Apache | servers, and what kind of stickyness you | use those equipments with, you could end up with non optimal routings of | requests, but that's only minor since | it will only apply to sessions that were on the downed worker initially. | | Can you provide any insights into mod_webapp? | | Nope, I only dug into mod_jk for now. | | Mathias. | | -- | 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 RELEASE-NOTES-4.0.2-B1.txt
remm01/12/18 13:22:43 Modified:.Tag: tomcat_40_branch RELEASE-NOTES-4.0.2-B1.txt Log: - (big) changelog update. Revision ChangesPath No revision No revision 1.1.2.4 +133 -1jakarta-tomcat-4.0/Attic/RELEASE-NOTES-4.0.2-B1.txt Index: RELEASE-NOTES-4.0.2-B1.txt === RCS file: /home/cvs/jakarta-tomcat-4.0/Attic/RELEASE-NOTES-4.0.2-B1.txt,v retrieving revision 1.1.2.3 retrieving revision 1.1.2.4 diff -u -r1.1.2.3 -r1.1.2.4 --- RELEASE-NOTES-4.0.2-B1.txt2001/12/04 02:48:02 1.1.2.3 +++ RELEASE-NOTES-4.0.2-B1.txt2001/12/18 21:22:43 1.1.2.4 @@ -3,7 +3,7 @@ Release Notes = -$Id: RELEASE-NOTES-4.0.2-B1.txt,v 1.1.2.3 2001/12/04 02:48:02 larryi Exp $ +$Id: RELEASE-NOTES-4.0.2-B1.txt,v 1.1.2.4 2001/12/18 21:22:43 remm Exp $ @@ -37,11 +37,16 @@ * Please note the revised documentation below related to * * using XML parsers with Tomcat 4.0 based applications. * +AJP: Add some documentation on AJP with Tomcat 4. + - Catalina New Features: - +StandardHost: Allow disabling the error report valve by setting its classname + to an empty string. + --- Jasper New Features: @@ -72,22 +77,149 @@ Catalina Bug Fixes: -- +RequestFacade: The method getRemoteHost of the facade should call + getRemoteHost. + +WebappLoader: Add back some permissions, which were incorrectly removed while + refactoring the loader and classloader + +WebappClassLoader: getResource and getResourceAsStream weren't calling + the superclass (which is needed when there are external repositories). + +WebappClassLoader: Will attempt to load a class even if it already + failed before. + +Build script: Exclude the binaries from the fixCRLF. + +NamingContext: Specify the name in the exception message for the alreadyBound + error. + +AccessLogValve: Fixes for potential thread safety problems. + +StandardContext: Cross context should default to false. + +GenericPrincipal: Is now a public class. + +Bootstrap: Remove System.exit(0) call at the end of the main() method. + +WarpConnector: making WarpConnector's thread a daemon to facilitate shutting + down without System.exit(0). + +FileDirContext: Fix security manager bug when using Windows. The base should + be an absolute path (instead of a relative path), otherwise a security + exception would be thrown by the case sensitivity checking code when trying + to access the user.dir system property. + +HttpResponseStream: Don't remove the transfer encoding header if chunking is + disabled. + +HttpProcessor: If the client announced it was closing the connection, repeat + the connection: close in the response. + +WebappLoader: Canonicalize the context root permission. + +AuthenticatorBase: Fix a problem with auth constraints, where roles wouldn't + get processed right when the wildcard was used. + +StandardEngineValve: Backport the HTTP/1.1 compliance fix to send 400 + (bad request) instead of 500 (internal server error) on an unrecognized + or missing host. + +ErrorDispatcherValve: Wrapper could be null when the request was incompletely + mapped, which often happened when using an authenticator valve. + +NamingContext: Rebind references. + +HttpResponseBase: Return 404 when parsing invalid URLs. + +StandardClassLoader: Fix race condition, where defineClass could be called + multiple times on the same class. +Catalina: Only set the initial context factory if it has not been set. +ErrorDispatcherValve: When processing an error-page triggered by an exception, + set the status code to 500. + +StandardContext: Fix incorrect Javadoc. + +ErrorDispatcherValve: Fix a NPE which occured when handling the 500 that was + returned when the host mapper failed to map the request to a context. + The status is still 500, but the error report gives some info on the + problem, and no exception is logged. + +AuthenticatorBase: Set the seed after computing it. + +HttpResponseBase: Suspend response after sendError and sendRedirect + (simulates that the response has been sent from the application perspective). + +StandardWrapper: Fix single thread model thread safety problems under very high + loads. + +ApplicationDispatcher: Makes forward code more robust. + +ResponseFacade: getOutputStream(), getWriter(), and flushBuffer() + non-fatal even if called after response is finished. + +ErrorReportValve: Fix regression when printing exception reports, caused by the + change of
Re: Load balancing - fail-over support with mod_webapp
On Tue, 18 Dec 2001, Tom Drake wrote: Date: Tue, 18 Dec 2001 13:25:07 -0800 From: Tom Drake [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED], Tom Drake [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: Load balancing - fail-over support with mod_webapp Mathias: In Tomcat 4, unless I'm not reading the code correctly, or completely, it doesn't appear that that any routing information is stored in the session id. Can anyone comment on this? The load balancer routing from JK hasn't ever been implemented in Catalina yet. Patches welcome :-). Tom Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5250] - Load balancing workers do not correctly handle Cookies conformant with RFC 2965
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=5250. 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=5250 Load balancing workers do not correctly handle Cookies conformant with RFC 2965 --- Additional Comments From [EMAIL PROTECTED] 2001-12-18 13:36 --- Created an attachment (id=919) New patch correcting a problem with the previous, id_sep not being set to ';' in the loop. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Bug 5471 - JspC broken when compiling webapps
Believe or not, Jasper once mangled the file names in a way similar to what is in the patch. It was modified in response to a bug (Bugzilla is currently unavailable, so I can't look up the bug number). The filer complained that for a file with deeply nested path, the resultant file name is too long to work in Window, since there is a 250(?) character file name limit there. I think a better fix is not to mangle the path into the file name, but to put the .java (and .class) files in a directory structure that mirrors the .jsp structure. This is how it work currently, for the non -webapps case. Date: Tue, 18 Dec 2001 15:47:25 -0500 From: Steve Downey [EMAIL PROTECTED] Subject: [PATCH] Bug 5471 - JspC broken when compiling webapps To: [EMAIL PROTECTED] (E-mail) [EMAIL PROTECTED] MIME-version: 1.0 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 This patch changes CommandLineContext.getServletPackageName() to return a package name based on the path to the JSP as well as the package name supplied on the command line. Without a change like this, a webapp that has files with the same name, such as index.jsp, in more than one place is compiled incorrectly, with both JSP files being mapped to the same servlet. With this patch, the java files are placed in the correct directories, and generation of web.xml works. This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] Bug 5471 - JspC broken when compiling webapps
The patch doesn't mangle the class file name, just the package name, so that the resulting java file is put in a directory that matches the path of the jsp file. Just putting the java file in a subdirectory is insufficient, though. Unless the packages are different, there isn't a way to disambiguate the servlets that result from two index.jsp's in the web.xml file. Example: input /index.jsp /subdir/index.jsp result /index.java - contains class index /subdir/index.java - contains class subdir.index If the -p option is used, eg -p com.netfolio.jspservlets /com/netfolio/jspservlets/index.java - contains class com.netfolio.jspservlets.index /com/netfolio/jspservlets//subdir/index.java - contains class com.netfolio.jspservlets.subdir.index -Original Message- From: Kin-Man Chung [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 18, 2001 4:37 PM To: [EMAIL PROTECTED] Subject: Re: [PATCH] Bug 5471 - JspC broken when compiling webapps Believe or not, Jasper once mangled the file names in a way similar to what is in the patch. It was modified in response to a bug (Bugzilla is currently unavailable, so I can't look up the bug number). The filer complained that for a file with deeply nested path, the resultant file name is too long to work in Window, since there is a 250(?) character file name limit there. I think a better fix is not to mangle the path into the file name, but to put the .java (and .class) files in a directory structure that mirrors the .jsp structure. This is how it work currently, for the non -webapps case. Date: Tue, 18 Dec 2001 15:47:25 -0500 From: Steve Downey [EMAIL PROTECTED] Subject: [PATCH] Bug 5471 - JspC broken when compiling webapps To: [EMAIL PROTECTED] (E-mail) [EMAIL PROTECTED] MIME-version: 1.0 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 This patch changes CommandLineContext.getServletPackageName() to return a package name based on the path to the JSP as well as the package name supplied on the command line. Without a change like this, a webapp that has files with the same name, such as index.jsp, in more than one place is compiled incorrectly, with both JSP files being mapped to the same servlet. With this patch, the java files are placed in the correct directories, and generation of web.xml works. This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: load balancing - integration thoughts
Craig:
I'll look into both of these suggestions. The Valve idea sounds
like a winner, since it wouldn't require changing anything in
the 'other' packages.
Thanks.
Tom
- Original Message -
From: Craig R. McClanahan [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Cc: Tom Drake [EMAIL PROTECTED]
Sent: Tuesday, December 18, 2001 1:33 PM
Subject: Re: load balancing - integration thoughts
|
|
| On Tue, 18 Dec 2001, Mika Goeckel wrote:
|
| Date: Tue, 18 Dec 2001 21:12:34 +0100
| From: Mika Goeckel [EMAIL PROTECTED]
| Reply-To: Tomcat Developers List [EMAIL PROTECTED]
| To: Tom Drake [EMAIL PROTECTED], [EMAIL PROTECTED]
| Cc: Craig McClanahan [EMAIL PROTECTED]
| Subject: Re: load balancing - integration thoughts
|
| Hi Tom, hi Craig!
|
| Another approach would be to extend the event model that is used for
Session
| (Servlet Spec SRV.10.1/SRV15.1.13) to fire events when a request is
| completed..
| Craig, would it be compliant with the spec to add another subclass of
| SessionEvent (Maybe SessionRequestEvent)?
|
|
| We can't add javax.servlet.* events (that's all managed by the Servlet
| Spec), but we could certainly create request started and request ended
| events that are Catalina-specific that you could register listeners for.
|
| Another approach would be to stick a Valve in the request processing
| pipeline. Since all requests would go through it, you've got a natural
| opportunity to preprocess and postprocess as needed.
|
| Then you could register your manager with newly created sessions as a
| SessionListener.
|
| Mika
|
| Craig
|
|
| - Original Message -
| From: Tom Drake [EMAIL PROTECTED]
| To: Mika Goeckel [EMAIL PROTECTED]
| Cc: Craig McClanahan [EMAIL PROTECTED]
| Sent: Tuesday, December 18, 2001 8:50 PM
| Subject: load balancing - integration thoughts
|
|
| Mika and/or Craig:
|
| After having looked around the code, here's my thoughts
| about how to implement 'end-of-request' notification. Because
| we need post session updates to the 'other' repositories,
| and 'unlock' the session at the end of each Http request.
|
| Can you review and comment? Being new to Tomcat, I'd
| like some confirmation that I'm on the right track, or some
| gentle guidance.
|
| o.a.c.Manager.java
| - add new method
| public void completeRequest(String sessionId);
|
| o.a.c.session.ManagerBase.java
| - add new method
| public void completeRequest(String sessionId) {
| // noop - non-distributed sessions don't care.
| }
|
| o.a.c.Request.java
| - add new method
| public void completeRequest();
|
| o.a.c.connector.ResponseBase.java
| - modify 'finishResponse()' by adding the following code
| getRequest().completeRequest();
|
| o.a.c.connector.RequestBase.java
| - add new method
| public void completeRequest() {
| if (session != null) {
| manager.completeRequest(session.getId());
| }
| }
|
| o.a.c.session.RepositoryManager - new class that extends
| StandardManager.java.
|
| public void completeRequest(String sessionId) {
| // deal with updating the remote repositories here
| }
|
| There's lots of other code in RepositoryManager, I just wanted to
focus
| on the end-of-request notification bits.
|
|
| Regards,
|
| Tom Drake
| President, software/etc inc.
| Email: [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: [PATCH] Bug 5471 - JspC broken when compiling webapps
I responsed in haste, without reading your patch carefully. :( My apologies. I'll get the patch in, later. Thanks. Date: Tue, 18 Dec 2001 16:44:42 -0500 From: Steve Downey [EMAIL PROTECTED] Subject: RE: [PATCH] Bug 5471 - JspC broken when compiling webapps To: 'Tomcat Developers List' [EMAIL PROTECTED] MIME-version: 1.0 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 The patch doesn't mangle the class file name, just the package name, so that the resulting java file is put in a directory that matches the path of the jsp file. Just putting the java file in a subdirectory is insufficient, though. Unless the packages are different, there isn't a way to disambiguate the servlets that result from two index.jsp's in the web.xml file. Example: input /index.jsp /subdir/index.jsp result /index.java - contains class index /subdir/index.java - contains class subdir.index If the -p option is used, eg -p com.netfolio.jspservlets /com/netfolio/jspservlets/index.java - contains class com.netfolio.jspservlets.index /com/netfolio/jspservlets//subdir/index.java - contains class com.netfolio.jspservlets.subdir.index -Original Message- From: Kin-Man Chung [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 18, 2001 4:37 PM To: [EMAIL PROTECTED] Subject: Re: [PATCH] Bug 5471 - JspC broken when compiling webapps Believe or not, Jasper once mangled the file names in a way similar to what is in the patch. It was modified in response to a bug (Bugzilla is currently unavailable, so I can't look up the bug number). The filer complained that for a file with deeply nested path, the resultant file name is too long to work in Window, since there is a 250(?) character file name limit there. I think a better fix is not to mangle the path into the file name, but to put the .java (and .class) files in a directory structure that mirrors the .jsp structure. This is how it work currently, for the non -webapps case. Date: Tue, 18 Dec 2001 15:47:25 -0500 From: Steve Downey [EMAIL PROTECTED] Subject: [PATCH] Bug 5471 - JspC broken when compiling webapps To: [EMAIL PROTECTED] (E-mail) [EMAIL PROTECTED] MIME-version: 1.0 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 This patch changes CommandLineContext.getServletPackageName() to return a package name based on the path to the JSP as well as the package name supplied on the command line. Without a change like this, a webapp that has files with the same name, such as index.jsp, in more than one place is compiled incorrectly, with both JSP files being mapped to the same servlet. With this patch, the java files are placed in the correct directories, and generation of web.xml works. This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail. -- 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: Load balancing - fail-over support with mod_webapp
On Tue, 18 Dec 2001, Craig R. McClanahan wrote: The load balancer routing from JK hasn't ever been implemented in Catalina yet. Patches welcome :-). Can we get a 'setRequest' method on Manager ? I'm trying to find workarounds, but that would be the simple solution. Again, adding support for load balancer is simple - the Manager just need to append the vmroute to the generated session id. How you get the session id is the problem - it is available in request, or it could be configured in server.xml if getting from the request is not possible. ( right now I'm trying to finish jk2 asap - when I'm done I'll try again to fix the lb for 40 if nobody does it before ) Costin -- 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 Ajp13.java Ajp13Packet.java AjpHandler.java NegociationHandler.java RequestHandler.java
costin 01/12/18 14:16:37
Added: jk/java/org/apache/jk Ajp13.java Ajp13Packet.java
AjpHandler.java NegociationHandler.java
RequestHandler.java
Log:
Adding the files from org.apache.ajp.
This is the same code, as startup point for jk2 and refactoring.
Revision ChangesPath
1.1 jakarta-tomcat-connectors/jk/java/org/apache/jk/Ajp13.java
Index: Ajp13.java
===
/*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Tomcat, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
* [Additional notices, if required by prior licensing conditions]
*
*/
package org.apache.jk;
import java.io.IOException;
import java.io.UnsupportedEncodingException;
import java.io.InputStream;
import java.io.OutputStream;
import java.io.ByteArrayInputStream;
import java.net.Socket;
import java.util.Enumeration;
import java.security.cert.X509Certificate;
import java.security.cert.CertificateFactory;
import org.apache.tomcat.util.buf.MessageBytes;
import org.apache.tomcat.util.buf.ByteChunk;
import org.apache.tomcat.util.http.MimeHeaders;
import org.apache.tomcat.util.http.HttpMessages;
import org.apache.tomcat.util.http.BaseRequest;
/**
* Represents a single, persistent connection between the web server and
* the servlet container. Uses the Apache JServ Protocol version 1.3 for
* communication. Because this protocal does not multiplex requests, this
* connection can only be associated with a single request-handling cycle
* at a time.P
*
* This class contains knowledge about how an individual packet is laid out
* (via the CODEAjp13Packet/CODE class), and also about the
* stages of communicaton between the server and the servlet container. It
* translates from Tomcat's internal servlet support methods
* (e.g. doWrite) to the correct packets to send to the web server.
*
* @see Ajp13Interceptor
*
* @author Dan Milstein [[EMAIL PROTECTED]]
* @author Keith Wannamaker [[EMAIL PROTECTED]]
* @author Kevin Seguin [[EMAIL PROTECTED]]
* @author Henri Gomez [[EMAIL PROTECTED]]
* @author Costin Manolache
*/
public class Ajp13 {
public static final int MAX_PACKET_SIZE=8192;
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server - New directory
costin 01/12/18 14:16:46 jakarta-tomcat-connectors/jk/java/org/apache/jk/server - New directory -- 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/tomcat40 - New directory
costin 01/12/18 14:16:50 jakarta-tomcat-connectors/jk/java/org/apache/jk/server/tomcat40 - New directory -- 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/tomcat40/config - New directory
costin 01/12/18 14:17:03 jakarta-tomcat-connectors/jk/java/org/apache/jk/server/tomcat40/config - New directory -- 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/tomcat33 - New directory
costin 01/12/18 14:17:40 jakarta-tomcat-connectors/jk/java/org/apache/jk/server/tomcat33 - New directory -- 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/tomcat33 Ajp14Interceptor.java
costin 01/12/18 14:17:59
Added: jk/java/org/apache/jk/server/tomcat33 Ajp14Interceptor.java
Log:
Initial commit, the code from ajp
Revision ChangesPath
1.1
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/tomcat33/Ajp14Interceptor.java
Index: Ajp14Interceptor.java
===
/*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Tomcat, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
* [Additional notices, if required by prior licensing conditions]
*
*/
package org.apache.jk.server.tomcat33;
import java.io.*;
import java.net.*;
import java.util.*;
import org.apache.jk.*;
import org.apache.tomcat.modules.server.PoolTcpConnector;
import org.apache.tomcat.core.*;
import org.apache.tomcat.util.net.*;
import org.apache.tomcat.util.buf.*;
import org.apache.tomcat.util.log.*;
import org.apache.tomcat.util.http.*;
/** Note. PoolTcpConnector is a convenience base class used for
TCP-based connectors in tomcat33. It allows all those modules
to share the thread pool and listener code.
In future it's likely other optimizations will be implemented in
the PoolTcpConnector, so it's better to use it if you don't have
a good reason not to ( like a connector for J2ME, where you want
minimal footprint and don't care about high load )
*/
/** Tomcat 33 module implementing the Ajp14 protocol.
*
* The actual protocol implementation is in Ajp14.java, this is just an
* adapter to plug it into tomcat.
*/
public class Ajp14Interceptor extends PoolTcpConnector
implements TcpConnectionHandler
{
int ajp14_note=-1;
String password;
RequestHandler reqHandler=new RequestHandler();
NegociationHandler negHandler=new NegociationHandler();
public Ajp14Interceptor()
{
super();
super.setSoLinger( 100 );
super.setTcpNoDelay( true );
}
// initialization
public void engineInit(ContextManager cm) throws TomcatException {
log(engineInit);
}
public void engineStart(ContextManager cm) throws TomcatException {
super.engineInit( cm );
ajp14_note=cm.getNoteId( ContextManager.REQUEST_NOTE, ajp14 );
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common - New directory
costin 01/12/18 14:18:08 jakarta-tomcat-connectors/jk/java/org/apache/jk/common - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Bug 5471 - JspC broken when compiling webapps
Believe or not, Jasper once mangled the file names in a way similar to what is in the patch. It was modified in response to a bug (Bugzilla is currently unavailable, so I can't look up the bug number). The filer complained that for a file with deeply nested path, the resultant file name is too long to work in Window, since there is a 250(?) character file name limit there. I did file such a bug for Tomcat 3.2.x. ;-) I was glad Tomcat 4 did fix this at some point as the only workaround was to shorten the Tomcat's workdir path (something like d:\w), which is an ugly fix anyway. Keeping the structure of the webapps directories seems to me a good solution for 2 reasons : -- The surprise of too long filenames in Zindozs will disappear (your webapp won't work with original JSP files either), so you move from a known bug to a non-issue (the end-user aka JSP writer just has to make sure his filenames are compatible with his OS - I guess he would even have a hard time saving them...). -- It will be far easier to look through java generated files when errors happen on pages (at least, we can type a filename !) - mangling the directory names with all those % and figures is a bit painful in Tomcat 3.2 when we have to debug our webapps... Using a UID for each generated filename would be an idea tooand it's easy to generate (using java.rmi.server.UIDI know it is a strange location for such a class, but it works fine ! - although this is not the best as the UID may not fit filenames patterns), but I prefer the directory structure solution. Hope my $0.02 helps... Denis I think a better fix is not to mangle the path into the file name, but to put the .java (and .class) files in a directory structure that mirrors the .jsp structure. This is how it work currently, for the non -webapps case. Date: Tue, 18 Dec 2001 15:47:25 -0500 From: Steve Downey [EMAIL PROTECTED] Subject: [PATCH] Bug 5471 - JspC broken when compiling webapps To: [EMAIL PROTECTED] (E-mail) [EMAIL PROTECTED] MIME-version: 1.0 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 This patch changes CommandLineContext.getServletPackageName() to return a package name based on the path to the JSP as well as the package name supplied on the command line. Without a change like this, a webapp that has files with the same name, such as index.jsp, in more than one place is compiled incorrectly, with both JSP files being mapped to the same servlet. With this patch, the java files are placed in the correct directories, and generation of web.xml works. This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail. -- 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-connectors/jk/native2/server/apache2 mod_jk.c
costin 01/12/18 14:51:55
Modified:jk/native2/common jk_ajp14_worker.c
jk/native2/include jk_webapp.h
jk/native2/jni jk_jni_aprImpl.c
jk/native2/server/apache2 mod_jk.c
Log:
Move the reading of initial post data after the sending the request
( to do it in paralel )
Few cleanups ( vars not used )
Removed the 'ctl' handler in mod_jk ( that I added few days back for monitoring
that state). There is a much better and cleaner way to do it.
Started to add some (prototype for now) code to aprImpl ( the Jni side ). We want to
be able use use unix sockets and few other things from APR from java ( probably
signals and chuid will also help ). Of course, long-term we should try to create
a nicer interface, etc - this is now highly experimental.
Revision ChangesPath
1.12 +21 -20jakarta-tomcat-connectors/jk/native2/common/jk_ajp14_worker.c
Index: jk_ajp14_worker.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_ajp14_worker.c,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- jk_ajp14_worker.c 2001/12/17 07:17:08 1.11
+++ jk_ajp14_worker.c 2001/12/18 22:51:55 1.12
@@ -313,25 +313,6 @@
return JK_FALSE;
}
-/* Prepare to send some post data ( ajp13 proto ) */
-if (s-is_chunked || s-left_bytes_to_send 0) {
-/* We never sent any POST data and we check it we have to send at
- * least of block of data (max 8k). These data will be kept in reply
- * for resend if the remote Tomcat is down, a fact we will learn only
- * doing a read (not yet)
- */
-err=jk_serialize_postHead( env, e-post, s, e );
-
-if (err != JK_TRUE ) {
-/* the browser stop sending data, no need to recover */
-e-recoverable = JK_FALSE;
-env-l-jkLog(env, env-l, JK_LOG_ERROR,
- ajp14.service() Error receiving initial post data\n);
-return JK_FALSE;
-}
-hasPost=JK_TRUE;
-}
-
env-l-jkLog(env, env-l, JK_LOG_INFO,
ajp14.service() %s\n, e-worker-name);
@@ -386,8 +367,28 @@
*is_recoverable_error = JK_TRUE;
e-recoverable = JK_TRUE;
-if( hasPost==JK_TRUE)
+/* Prepare to send some post data ( ajp13 proto ). We do that after the
+ request was sent ( we're receiving data from client, can be slow, no
+ need to delay - we can do that in paralel. ( not very sure this is
+ very usefull, and it brakes the protocol ) ! */
+if (s-is_chunked || s-left_bytes_to_send 0) {
+/* We never sent any POST data and we check it we have to send at
+ * least of block of data (max 8k). These data will be kept in reply
+ * for resend if the remote Tomcat is down, a fact we will learn only
+ * doing a read (not yet)
+ */
+err=jk_serialize_postHead( env, e-post, s, e );
+
+if (err != JK_TRUE ) {
+/* the browser stop sending data, no need to recover */
+e-recoverable = JK_FALSE;
+env-l-jkLog(env, env-l, JK_LOG_ERROR,
+ ajp14.service() Error receiving initial post data\n);
+return JK_FALSE;
+}
+
err= e-post-send( env, e-post, e );
+}
err = e-worker-workerEnv-processCallbacks(env, e-worker-workerEnv,
e, s);
1.4 +1 -12 jakarta-tomcat-connectors/jk/native2/include/jk_webapp.h
Index: jk_webapp.h
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_webapp.h,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- jk_webapp.h 2001/12/16 23:17:23 1.3
+++ jk_webapp.h 2001/12/18 22:51:55 1.4
@@ -140,22 +140,11 @@
/** You can fine-tune the logging level per location
*/
-int log_level;
+int logLevel;
/** Different apps can have different loggers.
*/
struct jk_logger *l;
-
-/* SSL Support - you can fine tune this per application.
- * ( most likely you only do it per virtual host or globally )
- * XXX shouldn't SSL be enabled by default ???
- */
-int ssl_enable;
-char *https_indicator;
-char *certs_indicator;
-char *cipher_indicator;
-char *session_indicator;
-char *key_size_indicator;
/* Jk Options. Bitflag.
*/
1.2 +97 -3 jakarta-tomcat-connectors/jk/native2/jni/jk_jni_aprImpl.c
Index: jk_jni_aprImpl.c
===
RCS file:
cvs commit: jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin TreeControlTag.java
amyroh 01/12/18 14:59:41
Modified:webapps/admin/WEB-INF/classes/org/apache/webapp/admin
TreeControlTag.java
Log:
The selected node does not get highlighted when the node is selected.
Made changes so that the tree also gets refreshed with each node selection,
along with loading the appropriate content in the content frame.
Submitted by Manveen Kaur.
Revision ChangesPath
1.6 +16 -4
jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/TreeControlTag.java
Index: TreeControlTag.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/TreeControlTag.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- TreeControlTag.java 2001/12/16 19:38:02 1.5
+++ TreeControlTag.java 2001/12/18 22:59:41 1.6
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/TreeControlTag.java,v
1.5 2001/12/16 19:38:02 patrickl Exp $
- * $Revision: 1.5 $
- * $Date: 2001/12/16 19:38:02 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/TreeControlTag.java,v
1.6 2001/12/18 22:59:41 amyroh Exp $
+ * $Revision: 1.6 $
+ * $Date: 2001/12/18 22:59:41 $
*
*
*
@@ -104,7 +104,7 @@
* strongFIXME/strong - Internationalize the exception messages!
*
* @author Craig R. McClanahan
- * @version $Revision: 1.5 $ $Date: 2001/12/16 19:38:02 $
+ * @version $Revision: 1.6 $ $Date: 2001/12/18 22:59:41 $
*/
public class TreeControlTag extends TagSupport {
@@ -397,6 +397,10 @@
String action = replace(getAction(), ${name}, encodedNodeName);
+
+String updateTreeAction =
+replace(getAction(), tree=${name}, select= + encodedNodeName);
+
out.print(td);
if ((action != null) !node.isLeaf()) {
out.print(a href=\);
@@ -448,6 +452,10 @@
out.print(target);
out.print(\);
}
+// to refresh the tree in the same 'self' frame
+out.print( onclick=\);
+out.print(self.location.href=' + updateTreeAction + ');
+out.print(\);
out.print();
}
out.print(img src=\);
@@ -484,6 +492,10 @@
out.print(labelStyle);
out.print(\);
}
+// to refresh the tree in the same 'self' frame
+out.print( onclick=\);
+out.print(self.location.href=' + updateTreeAction + ');
+out.print(\);
out.print();
} else if (labelStyle != null) {
out.print(span class=\);
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 3.3 deployment - last minute problem
The only thing that I can think of is that your javac doesn't support the -encoding switch. Is it possible that you have an old copy of tools.jar somewhere? Jasper writes out the .java file in UTF8 encoding, which is then passed to javac to compile to a .class. If javac is trying to read the .java file as iso-latin-1, then you'd see something like you're reporting. You might try using Jikes. Tomcat's JspWriter doesn't do any encoding. It just (eventually) passes the chars to the result of calling response.getWriter. This means that the encoding should the same as for a servlet (which you've reported does work). I can't personally reproduce your problem on either Windows or Solaris, so I don't know how much more help I can be. The main files involved are src/facade22/org/apache/tomcat/facade/JspInterceptor.java and src/share/org/apache/jasper/compiler/Compiler.java, if you want to dig through the code. - Original Message - From: Renato [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, December 18, 2001 6:27 PM Subject: Re: Tomcat 3.3 deployment - last minute problem Hi all, I'm investigating this problem and may found something. The html that is pushed to my browser is definitely pure Unicode ( UTF8 ), so somehow the HTML bytes are not been properly translated to chars. Where can I look in the code to make some tests ? Thanks Renato. Reply-to: Tomcat Developers List From: Renato Date: Fri Dec 14 15:19:28 2001 To: Tomcat Developers List , Tomcat Developers List , , Subject: Re: Tomcat 3.3 deployment - last minute problem Hi, This is what I'm using: I saw the servlet generated in the work directory and it actually write the response.setContentType(text/html;charset=ISO-8859-1) ( default type in server.xml is set to ISO-8859-1 too ) How can I know the charset of Linux ? ( I'll STW of course.. :)) ) Thanks for the promptness ! On Fri, 14 Dec 2001 08:48:31 -0800 (PST), escreveu : On Fri, 14 Dec 2001, Renato wrote: *** HTML pages with latin characters don't display correctly on Linux *** ( JSP file with: ) Ex: áéíóú It's maybe a problem with the locale variables on my Linux, which I don't quite understand ( tried LC_ALL, LANG, LC_CTYPE and it didn't work ) or Tomcat itself. Do you set the charset in the page setContentType(text/html;charset=8859-??) or the jsp equivalent ? What charset do you use to write the page ? ( i.e. UTF or 8859-?? ) ? There are few variables: - Java default charset ( which is typically the same as the OS charset). This is what jasper uses to read the page from disk. The page is converted to UTF by the reader. ( you can override the charset used on each page, don't remember the directive ) - output charset. This is specified in setContentType() or setCharEncoding on the response, and is used to convert from UTF to the target charset. 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: Tomcat 3.3 deployment - last minute problem
Hi Bill, Thanks for the help. I found out the problem. It was jikes. I was using jikes in the JspInterceptor and somewhat it wasn't working. Now, I will upgrade all my user base to Tomcat 3.3 :)) Renato. On Tue, 18 Dec 2001 14:29:24 -0800, Bill Barker [EMAIL PROTECTED] escreveu : The only thing that I can think of is that your javac doesn't support the -encoding switch. Is it possible that you have an old copy of tools.jar somewhere? Jasper writes out the .java file in UTF8 encoding, which is then passed to javac to compile to a .class. If javac is trying to read the .java file as iso-latin-1, then you'd see something like you're reporting. You might try using Jikes. Tomcat's JspWriter doesn't do any encoding. It just (eventually) passes the chars to the result of calling response.getWriter. This means that the encoding should the same as for a servlet (which you've reported does work). I can't personally reproduce your problem on either Windows or Solaris, so I don't know how much more help I can be. The main files involved are src/facade22/org/apache/tomcat/facade/JspInterceptor.java and src/share/org/apache/jasper/compiler/Compiler.java, if you want to dig through the code. - Original Message - From: Renato [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, December 18, 2001 6:27 PM Subject: Re: Tomcat 3.3 deployment - last minute problem Hi all, I'm investigating this problem and may found something. The html that is pushed to my browser is definitely pure Unicode ( UTF8 ), so somehow the HTML bytes are not been properly translated to chars. Where can I look in the code to make some tests ? Thanks Renato. Reply-to: Tomcat Developers List From: Renato Date: Fri Dec 14 15:19:28 2001 To: Tomcat Developers List , Tomcat Developers List , , Subject: Re: Tomcat 3.3 deployment - last minute problem Hi, This is what I'm using: I saw the servlet generated in the work directory and it actually write the response.setContentType(text/html;charset=ISO-8859-1) ( default type in server.xml is set to ISO-8859-1 too ) How can I know the charset of Linux ? ( I'll STW of course.. :)) ) Thanks for the promptness ! On Fri, 14 Dec 2001 08:48:31 -0800 (PST), escreveu : On Fri, 14 Dec 2001, Renato wrote: *** HTML pages with latin characters don't display correctly on Linux *** ( JSP file with: ) Ex: áéíóú It's maybe a problem with the locale variables on my Linux, which I don't quite understand ( tried LC_ALL, LANG, LC_CTYPE and it didn't work ) or Tomcat itself. Do you set the charset in the page setContentType(text/html;charset=8859-??) or the jsp equivalent ? What charset do you use to write the page ? ( i.e. UTF or 8859- ?? ) ? There are few variables: - Java default charset ( which is typically the same as the OS charset). This is what jasper uses to read the page from disk. The page is converted to UTF by the reader. ( you can override the charset used on each page, don't remember the directive ) - output charset. This is specified in setContentType() or setCharEncoding on the response, and is used to convert from UTF to the target charset. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5353] - Characters with accents not displayed correctly in Tomcat 3.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=5353. 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=5353 Characters with accents not displayed correctly in Tomcat 3.3 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2001-12-18 15:30 --- It was jikes. Somehow it wasn't working. I removed the jikes entry in the JspInterceptor, and everything worked fine. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Load balancing - fail-over support with mod_webapp
Adding the vmroute may help with load balancing, but it doesn't help with fail-over. What happens when the tomcat instance that created a session goes down, and then the user sends another request? It should be routed to 'another' tomcat in the cluster. This 'other' tc instance should probably become the new 'owner' of the session. All subsequent requests for that session should be routed to the new owner (until / unless the new owner goes down). One simple solution is to simply keep track of the 'vmroute's that are 'down' or no longer available and substitue each down vm with one other vm in the cluster. Anytime a request is received from a client that is destined for one of the 'down' vm's, Apache can route the request to the 'stand-in' vm instead. The obvious disadvantage is that it will unfairly burden the 'stand-in' vm's, which may have already been handling their fair share of traffic. This, does provide fail-over. Which, is an important feature to have for ha environments. Another solution would be to calculate some sort of checksum on each session id received for a vm that is no longer on the air. Then modulo that number by the number of available tc instances in the cluster, and route the request to the the jth server in the cluster (where j is the calculated modulo). This would spread the load without requiring anyone to start maintaining copious session routing tables. I don't know what you'd do if the number of available tc's changes. Another solution would be to send a cookie back to the client that contains the new jvmrouting info. But, that only works for clients that allow cookies. Another solution would be to choose a new 'owner', and store this mapping (of session id to owner vm) in a hashtable. Then, in subsequent requests, do a hashtable lookup to find the owner vm. Solutions that require a large routing table are probably not desirable, but would probably result in the greatest flexibility. Tom Drake - Original Message - From: [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, December 18, 2001 2:14 PM Subject: Re: Load balancing - fail-over support with mod_webapp | On Tue, 18 Dec 2001, Craig R. McClanahan wrote: | | The load balancer routing from JK hasn't ever been implemented in | Catalina yet. Patches welcome :-). | | Can we get a 'setRequest' method on Manager ? I'm trying to find | workarounds, but that would be the simple solution. | | Again, adding support for load balancer is simple - the Manager just need | to append the vmroute to the generated session id. How you get the session | id is the problem - it is available in request, or it could be configured | in server.xml if getting from the request is not possible. | | ( right now I'm trying to finish jk2 asap - when I'm done I'll try again | to fix the lb for 40 if nobody does it before ) | | 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]
DO NOT REPLY [Bug 5497] New: - JSP include not always including
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=5497. 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=5497 JSP include not always including Summary: JSP include not always including Product: Tomcat 4 Version: 4.0.1 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Loading a page with a single JSP include directive works in IE5, NS4 but not in NS6.1, unless you do a Shift-Refresh (no-cache reload), or modify the include file. My guess is that Tomcat is not including it because the modify time of the include file is later than the If-Modified-Since header. Here are the successful/failed requests in full (host/URL names mofified). The include file is between the text Before and After and is just the text Hey Successful: GET http://host:8080/example/test.jsp HTTP/1.1 Host: host:8080 User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 Accept: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9, image/png, image/jpeg, image/gif;q=0.2, text/plain;q=0.8, text/css, */*;q=0.1 Accept-Language: en-us Accept-Encoding: gzip,deflate,compress,identity Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66 Keep-Alive: 300 Connection: keep-alive Cookie: JSESSIONID=866366D2738128D9A0C1650535F7F531 If-Modified-Since: Tue, 18 Dec 2001 23:23:09 GMT Cache-Control: max-age=0 HTTP/1.0 200 OK Content-Type: text/html;charset=ISO-8859-1 Date: Tue, 18 Dec 2001 23:23:26 GMT Server: Apache Tomcat/4.0.1 (HTTP/1.1 Connector) X-Cache: MISS from antares Proxy-Connection: close !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN html headtitleUntitled/title/head body Before Hey After /body /html Failed: GET http://host:8080/example/test.jsp HTTP/1.1 Host: host:8080 User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 Accept: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9, image/png, image/jpeg, image/gif;q=0.2, text/plain;q=0.8, text/css, */*;q=0.1 Accept-Language: en-us Accept-Encoding: gzip,deflate,compress,identity Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66 Keep-Alive: 300 Connection: keep-alive Cookie: JSESSIONID=866366D2738128D9A0C1650535F7F531 If-Modified-Since: Tue, 18 Dec 2001 23:23:26 GMT Cache-Control: max-age=0 HTTP/1.0 200 OK Content-Type: text/html;charset=ISO-8859-1 Date: Tue, 18 Dec 2001 23:24:16 GMT Server: Apache Tomcat/4.0.1 (HTTP/1.1 Connector) X-Cache: MISS from antares Proxy-Connection: close !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN html headtitleUntitled/title/head body Before After /body /html -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4426] - DB polling
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=4426. 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=4426 DB polling --- Additional Comments From [EMAIL PROTECTED] 2001-12-18 15:48 --- Not sure I fully understand this bug report, but the first thing to do is to upgrade from m3 to 3.3 final and try again. As for the CLASSPATH, TC 3.3 will ignore it, so I don't know how is that relevant. Another thing to try is a different type of database, just to eliminate JDBC driver problems. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/xml XmlMapper.java
bojan 01/12/18 15:59:25
Modified:src/share/org/apache/tomcat/util/xml XmlMapper.java
Log:
Jochen Wiedmann fix for web.xml that has no DOCTYPE
Revision ChangesPath
1.39 +8 -7
jakarta-tomcat/src/share/org/apache/tomcat/util/xml/XmlMapper.java
Index: XmlMapper.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/xml/XmlMapper.java,v
retrieving revision 1.38
retrieving revision 1.39
diff -u -r1.38 -r1.39
--- XmlMapper.java2001/10/25 01:41:48 1.38
+++ XmlMapper.java2001/12/18 23:59:25 1.39
@@ -98,13 +98,14 @@
sb.append(/);
for( int i=0; i sp ; i++ ) sb.append( tagStack[i] ).append( / );
sb.append( );
- AttributeList attributes=(AttributeList) attributeStack[sp-1];
- if( attributes!=null)
- for (int i = 0; i attributes.getLength (); i++) {
- sb.append(attributes.getName(i)).append( =
).append(attributes.getValue(i));
- sb.append( );
- }
-
+if( sp 0 ) {
+ AttributeList attributes=(AttributeList) attributeStack[sp-1];
+ if( attributes!=null)
+ for (int i = 0; i attributes.getLength (); i++) {
+ sb.append(attributes.getName(i)).append( =
).append(attributes.getValue(i));
+ sb.append( );
+ }
+ }
return sb.toString();
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/xml XmlMapper.java
bojan 01/12/18 16:02:09
Modified:src/share/org/apache/tomcat/util/xml XmlMapper.java
Log:
Tabs corrected...
Revision ChangesPath
1.40 +2 -2
jakarta-tomcat/src/share/org/apache/tomcat/util/xml/XmlMapper.java
Index: XmlMapper.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/xml/XmlMapper.java,v
retrieving revision 1.39
retrieving revision 1.40
diff -u -r1.39 -r1.40
--- XmlMapper.java2001/12/18 23:59:25 1.39
+++ XmlMapper.java2001/12/19 00:02:09 1.40
@@ -98,8 +98,8 @@
sb.append(/);
for( int i=0; i sp ; i++ ) sb.append( tagStack[i] ).append( / );
sb.append( );
-if( sp 0 ) {
- AttributeList attributes=(AttributeList) attributeStack[sp-1];
+ if( sp 0 ) {
+ AttributeList attributes=(AttributeList) attributeStack[sp-1];
if( attributes!=null)
for (int i = 0; i attributes.getLength (); i++) {
sb.append(attributes.getName(i)).append( =
).append(attributes.getValue(i));
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5314] - NPE when reading web.xml without DOCTYPE declaration
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=5314. 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=5314 NPE when reading web.xml without DOCTYPE declaration [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2001-12-18 16:03 --- Thanks. Applied. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Load balancing - fail-over support with mod_webapp
On Tue, 18 Dec 2001 [EMAIL PROTECTED] wrote: Date: Tue, 18 Dec 2001 14:14:10 -0800 (PST) From: [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: Load balancing - fail-over support with mod_webapp On Tue, 18 Dec 2001, Craig R. McClanahan wrote: The load balancer routing from JK hasn't ever been implemented in Catalina yet. Patches welcome :-). Can we get a 'setRequest' method on Manager ? I'm trying to find workarounds, but that would be the simple solution. In other words, a *single* request property for the entire Manager? Wouldn't that have problems when you had simultaneous requests in progress? Same thing would happen (but on a smaller scale) if you added setRequest on the session instead -- it's legal to have multiple simultaneous requests. Again, adding support for load balancer is simple - the Manager just need to append the vmroute to the generated session id. How you get the session id is the problem - it is available in request, or it could be configured in server.xml if getting from the request is not possible. The request (and therefore the response because they maintain mutual references) knows what the session id is ... is that good enough? ( right now I'm trying to finish jk2 asap - when I'm done I'll try again to fix the lb for 40 if nobody does it before ) Costin Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] Bug 5471 - JspC broken when compiling webapps
You may want this one, also. Turns out that jasper.sh is mildly broken on
HEAD. It doesn't grab the libraries in shared/lib or the classes in
shared/classes.
I'm guessing that JspC isn't the most heavily exercised part of the system.
g
Index: jasper.sh
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/jasper/src/bin/jasper.sh,v
retrieving revision 1.5
diff -u -r1.5 jasper.sh
--- jasper.sh 2001/09/13 15:22:45 1.5
+++ jasper.sh 2001/12/19 00:10:39
@@ -35,7 +35,7 @@
done
JASPER_HOME_1=`dirname $PRG`/..
- echo Guessing JASPER_HOME from catalina.sh to ${JASPER_HOME_1}
+ echo Guessing JASPER_HOME from jasper.sh to ${JASPER_HOME_1}
if [ -d ${JASPER_HOME_1}/conf ] ; then
JASPER_HOME=${JASPER_HOME_1}
echo Setting JASPER_HOME to $JASPER_HOME
@@ -80,6 +80,10 @@
done
CP=$CP:$JASPER_HOME/common/classes
for i in $JASPER_HOME/common/lib/*.jar ; do
+ CP=$CP:$i
+done
+CP=$CP:$JASPER_HOME/shared/classes
+for i in $JASPER_HOME/shared/lib/*.jar ; do
CP=$CP:$i
done
-Original Message-
From: Kin-Man Chung [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 18, 2001 5:12 PM
To: [EMAIL PROTECTED]
Subject: RE: [PATCH] Bug 5471 - JspC broken when compiling webapps
I responsed in haste, without reading your patch carefully. :( My
apologies.
I'll get the patch in, later. Thanks.
Date: Tue, 18 Dec 2001 16:44:42 -0500
From: Steve Downey [EMAIL PROTECTED]
Subject: RE: [PATCH] Bug 5471 - JspC broken when compiling webapps
To: 'Tomcat Developers List' [EMAIL PROTECTED]
MIME-version: 1.0
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
The patch doesn't mangle the class file name, just the
package name, so that
the resulting java file is put in a directory that matches
the path of the
jsp file. Just putting the java file in a subdirectory is
insufficient,
though. Unless the packages are different, there isn't a
way to disambiguate
the servlets that result from two index.jsp's in the web.xml file.
Example:
input
/index.jsp
/subdir/index.jsp
result
/index.java - contains class index
/subdir/index.java - contains class subdir.index
If the -p option is used, eg -p com.netfolio.jspservlets
/com/netfolio/jspservlets/index.java - contains class
com.netfolio.jspservlets.index
/com/netfolio/jspservlets//subdir/index.java - contains class
com.netfolio.jspservlets.subdir.index
-Original Message-
From: Kin-Man Chung [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 18, 2001 4:37 PM
To: [EMAIL PROTECTED]
Subject: Re: [PATCH] Bug 5471 - JspC broken when compiling webapps
Believe or not, Jasper once mangled the file names in a way
similar to what
is in the patch. It was modified in response to a bug
(Bugzilla is currently
unavailable, so I can't look up the bug number). The filer
complained that
for a file with deeply nested path, the resultant file name
is too long to
work in Window, since there is a 250(?) character file name
limit there.
I think a better fix is not to mangle the path into the
file name, but
to put the .java (and .class) files in a directory structure
that mirrors
the .jsp structure. This is how it work currently, for the
non -webapps
case.
Date: Tue, 18 Dec 2001 15:47:25 -0500
From: Steve Downey [EMAIL PROTECTED]
Subject: [PATCH] Bug 5471 - JspC broken when compiling webapps
To: [EMAIL PROTECTED] (E-mail)
[EMAIL PROTECTED]
MIME-version: 1.0
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
This patch changes
CommandLineContext.getServletPackageName() to return a
package name based on the path to the JSP as well as the
package name
supplied on the command line.
Without a change like this, a webapp that has files with
the same name, such
as index.jsp, in more than one place is compiled
incorrectly, with both JSP
files being mapped to the same servlet.
With this patch, the java files are placed in the correct
directories, and
generation of web.xml works.
This electronic
mail transmission
may contain confidential information and is
cvs commit: jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin ActionTag.java ActionsTag.java
craigmcc01/12/18 17:58:10
Modified:webapps/admin/WEB-INF controls.tld
Added: webapps/admin/WEB-INF/classes/org/apache/webapp/admin
ActionTag.java ActionsTag.java
Log:
Add a simple instant actions tag that can be used for the Available
Actions control that is common to most of the property sheet pages in the
Admin App prototype.
Typical usage would look something like:
form style=instant-actions-style
Select one of the following:
controls:actions
controls:action---Available Actions---/controls:action
controls:action---/controls:action
controls:action url=first.jspFirst Choice/controls:action
controls:action url=second.jspSecond Choice/controls:action
/controls:actions
/form
Revision ChangesPath
1.2 +171 -79 jakarta-tomcat-4.0/webapps/admin/WEB-INF/controls.tld
Index: controls.tld
===
RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/controls.tld,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- controls.tld 2001/12/18 04:17:32 1.1
+++ controls.tld 2001/12/19 01:58:10 1.2
@@ -13,6 +13,98 @@
Tomcat Administrative Application.
/description
+ !-- == Instant Actions Tag = --
+
+ tag
+
+nameactions/name
+tag-classorg.apache.webapp.admin.ActionsTag/tag-class
+body-contentJSP/body-content
+description
+ Render an instant actions object, which is rendered as an HTML
+ select element, where the selection of a particular element from
+ the list immediately causes a JavaScript function to be executed
+ (with the available elements specified by action tag instances
+ nested within the body of the actions tag).
+
+ NOTE: The only valid nested content for this tag is
+ action tags from this library. Anything else will cause
+ the rendered HTML to be invalid.
+
+ NOTE: To be usable, this tag must be nested inside an
+ HTML lt;formgt; element.
+/description
+
+attribute
+ namesize/name
+ requiredfalse/required
+ rtexprvaluetrue/rtexprvalue
+ description
+(Integer) number of rows that will be visible to the user. If
+not specified, only one row will be visible.
+ /description
+/attribute
+
+attribute
+ namestyle/name
+ requiredfalse/required
+ rtexprvaluetrue/rtexprvalue
+ description
+The CSS style class to be applied to the entire rendered output
+of the instant actions control. If not specified, no overall
+style class is applied.
+ /description
+/attribute
+
+ /tag
+
+
+ tag
+
+nameaction/name
+tag-classorg.apache.webapp.admin.ActionTag/tag-class
+body-contentJSP/body-content
+description
+ Define a single instant action option for the surrounding actions
+ tag. It is not valid to use this tag *except* when nested inside an
+ actions tag.
+
+ NOTE: The body content of this tag (which should be suitably
+ localized, if required by your application) is used as the
+ user-visible label for this action.
+/description
+
+attribute
+ nameselected/name
+ requiredfalse/required
+ rtexprvaluetrue/rtexprvalue
+ description
+(Boolean) variable set to true or yes if this action should
+already be selected when the instant actions element is
+initially displayed.
+ /description
+/attribute
+
+attribute
+ nameurl/name
+ requiredfalse/required
+ rtexprvaluetrue/rtexprvalue
+ description
+The URL to which the current frame or window will be transferred
+if the onchange event handler of this instant actions element
+is triggered, and this is the currently selected action. If no
+URL is specified, no action will be taken (useful for (None)
+options and dividers).
+
+NOTE: This URL will be passed through URL rewriting so that it
+will maintain session identity even in environments were cookies
+are not being used.
+ /description
+/attribute
+
+ /tag
+
+
!-- == Tree Control Tag --
tag
@@ -28,85 +120,85 @@
/description
attribute
-nameaction/name
-requiredfalse/required
-rtexprvaluetrue/rtexprvalue
-description
- Hyperlink to which expand/contract actions should be sent,
- with a string ${node} marking where the node name of the
- affected node should be included (which
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util JavaGeneratorTool.java
larryi 01/12/18 18:39:39
Modified:src/share/org/apache/tomcat/util JavaGeneratorTool.java
Log:
Fix IndexOutOfBoundsException
Revision ChangesPath
1.5 +1 -1
jakarta-tomcat/src/share/org/apache/tomcat/util/JavaGeneratorTool.java
Index: JavaGeneratorTool.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/JavaGeneratorTool.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- JavaGeneratorTool.java2001/12/14 03:55:11 1.4
+++ JavaGeneratorTool.java2001/12/19 02:39:39 1.5
@@ -78,7 +78,7 @@
continue;
}
- if( (s.length()=endIdx) s.charAt( endIdx ) != '/' ) {
+ if( (s.length()endIdx) s.charAt( endIdx ) != '/' ) {
index = s.indexOf(keywords[i],index+3);
continue;
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util JavaGeneratorTool.java
Oh, well, I guess I had to screw up eventually :-(
Thanks for cleaning up my mess.
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, December 18, 2001 6:39 PM
Subject: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util
JavaGeneratorTool.java
larryi 01/12/18 18:39:39
Modified:src/share/org/apache/tomcat/util JavaGeneratorTool.java
Log:
Fix IndexOutOfBoundsException
Revision ChangesPath
1.5 +1 -1
jakarta-tomcat/src/share/org/apache/tomcat/util/JavaGeneratorTool.java
Index: JavaGeneratorTool.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/JavaGeneratorTool.
java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- JavaGeneratorTool.java 2001/12/14 03:55:11 1.4
+++ JavaGeneratorTool.java 2001/12/19 02:39:39 1.5
@@ -78,7 +78,7 @@
continue;
}
- if( (s.length()=endIdx) s.charAt( endIdx ) != '/' ) {
+ if( (s.length()endIdx) s.charAt( endIdx ) != '/' ) {
index = s.indexOf(keywords[i],index+3);
continue;
}
--
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: Load balancing - fail-over support with mod_webapp
Another solution would be to calculate some sort of checksum on each session id received for a vm that is no longer on the air. Then modulo that number by the number of available tc instances in the cluster, and route the request to the the jth server in the cluster (where j is the calculated modulo). This would spread the load without requiring anyone to start maintaining copious session routing tables. I don't know what you'd do if the number of available tc's changes. You implicitly make the assumption that in a setup with several frontend Apache servers they all use the same workers and that there is an order relationship between those. Choosing the jth worker only makes sense if the workers are in the same order on all mod_jk configs. You could very well have a setup where a load balancing equipment first routes a request according to a client ip for example to a given Apache server, being in a 'GOLD' customer all my requests are forwarded to a fast Apache with fast workers. Now if I am a 'COPPER' customer my requests will be routed to the slower Apache server using slower workers. The 'GOLD' setup has fail-over, that is the slow workers can handle the requests coming from the 'GOLD' Apache but 'COPPER' clients get no fail-over. The modulo trick is really tricky in such a setup. Another solution would be to send a cookie back to the client that contains the new jvmrouting info. But, that only works for clients that allow cookies. If the webapp uses URL rewriting where needed, the new value containing the new jvmroute can very well be included where it belongs (in all encoded URLs). The problem I see can arise is the atomicity of the setting of the new value. Somehow we need a 'lock' in the cluster of workers so that the first one to receive old session ID S1 will turn it into S2 and all subsequent requests for S1 will also turn it into S2, even if one of those requests is dispatched to a worker which would, if it had received the first request with S1, have turned it into S3. The mapping S1-S2 should be kept for the life of the session, so are possible further mappings, S1-S3 and/or S2-S'3, etc, should further workers fail. Mathias. Another solution would be to choose a new 'owner', and store this mapping (of session id to owner vm) in a hashtable. Then, in subsequent requests, do a hashtable lookup to find the owner vm. Solutions that require a large routing table are probably not desirable, but would probably result in the greatest flexibility. Yep, sort of what I talked about in my previous paragraph, but I would see this mapping stored among the workers, not in Apache modules. Tom Drake Mathias. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Servlet Caching problem
hi I am facing problem in tomcat 3.2.3 while recompiling the servlet ,whenever i make any changes in any existing servlet but after compiling the servlet its still show me the old output of the servlet because its taking that servlet from caching and its not reffreshing that unless until i don't restart the tomcat server Pls help me to solve this problem thanks Rakesh
Re: Load balancing - fail-over support with mod_webapp
I'm going to ignore the complete problem case where you have configured Apache to be the default servlet, and index.html is a frameset with 'n' jsp frames (which will typically result in 'n' different sessions). This is why mod_webapp only supports forwardAll, and forwardAll is the default for Ajp. Most 3.3 methods map well to Catalina. It's either an xxxListener or a Valve. This is one of the problem cases that falls through the cracks. As such, I personally can't see how to do this better than Costin's idea of adding a jvmroute attribute to the Manager. Instead, I'm going to try and describe the programmatic requirements and hope that someone smarter than me can see how to implement it. Apache knows who it sent the request to, and can (and does in 3.x) pass this information on to the Request object. If, as it happens, that the servlet that eventually gets executed at the end of the pipeline (or a rogue Valve/Filter) creates a new Session (e.g. Listener), then somebody with access to the Request object (e.g. Valve) needs to re-set the SessionId to be SessionId += . +request.getJvmroute(). This has to happen before the servlet regains control (so that response.encodeURL works), and before the cookie is set (or at least sent). Of course, what I care about is Apache. However in the above you can s/Apache/IIS/ or s/Apache/IPlanet/, and get to the same point. - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, December 18, 2001 6:09 PM Subject: Re: Load balancing - fail-over support with mod_webapp On Tue, 18 Dec 2001 [EMAIL PROTECTED] wrote: Date: Tue, 18 Dec 2001 14:14:10 -0800 (PST) From: [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: Load balancing - fail-over support with mod_webapp On Tue, 18 Dec 2001, Craig R. McClanahan wrote: The load balancer routing from JK hasn't ever been implemented in Catalina yet. Patches welcome :-). Can we get a 'setRequest' method on Manager ? I'm trying to find workarounds, but that would be the simple solution. In other words, a *single* request property for the entire Manager? Wouldn't that have problems when you had simultaneous requests in progress? Same thing would happen (but on a smaller scale) if you added setRequest on the session instead -- it's legal to have multiple simultaneous requests. Again, adding support for load balancer is simple - the Manager just need to append the vmroute to the generated session id. How you get the session id is the problem - it is available in request, or it could be configured in server.xml if getting from the request is not possible. The request (and therefore the response because they maintain mutual references) knows what the session id is ... is that good enough? ( right now I'm trying to finish jk2 asap - when I'm done I'll try again to fix the lb for 40 if nobody does it before ) Costin Craig -- 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]
