Possible bug in isapi_redirector.dll
Hello there everybody, We think we may have found a bug, possibly in IIS, which affects isapi_redirect.dll. We were wondering if anyone else has seen this. Perhaps this is a bug for MS, but it seems to affect tomcat so maybe someone here can shed some light. Our software versions are: IIS 4.0 jk_isapi_plugin.c revision 1.5.2.2 tomcat 3.2.2 Windows NT 4.0 sp6 The relevant code in is the file jk_isapi_plugin.c, line 960 in the function: static int get_server_value(LPEXTENSION_CONTROL_BLOCK lpEcb, char *name, char *buf, DWORD bufsz, char *def_val) When the function lpEcb-GetServerVariable(...) on line 965 is called to retrieve CERT_SERIALNUMBER, the value returned in bufsz is wrong. Our certificate serial number is 48 chars long, but the value contained in bufsz is 47, where it should be 49 (the length of the serial number + 1 for string terminator). After the call to GetServerVariable() a '\0' is inserted into buf at bufsz-1. This causes our certificate serial number to be truncated by 2 bytes. The microsoft doco says that the value returned should be the value length + 1 for the string terminator. This is from: http://msdn.microsoft.com/library/en-us/iisref/html/psdk/asp/isre8376.asp?fr ame=true Here is an example from our isapi.log. We had modified the code to so that it prints out the full serial number, and added a couple of our own debugging statements in here too). You can see that the actual CERT_SERIALNUMBER is 48 chars. A call to strlen(buf) right after the function call returns 48 but bufsz is 47. [jk_isapi_plugin.c (967)]: get_server_value(): strlen(buf)=48[jk_isapi_plugin.c (973)]: get_server_value(): bufsz=47 [jk_isapi_plugin.c (974)]: get_server_value(): CERT_SERIALNUMBER=a8-33-ac-b2-ad-c4-34-0e-41-07-01-b1-24-b7-55-05- [jk_isapi_plugin.c (967)]: get_server_value(): strlen(buf)=67[jk_isapi_plugin.c (973)]: get_server_value(): bufsz=68 [jk_isapi_plugin.c (974)]: get_server_value(): HTTPS_SERVER_ISSUER=C=AU, S=SA, L=Thebarton, O=StrategicEcommerce, OU=Toytown, CN=Jules [jk_isapi_plugin.c (967)]: get_server_value(): strlen(buf)=2[jk_isapi_plugin.c (973)]: get_server_value(): bufsz=3 [jk_isapi_plugin.c (974)]: get_server_value(): HTTPS_KEYSIZE=40 This only seems to occur when trying to retrieve values related to certificates. All the others seem fine. If anyone wants any more details, please let us know and we will gladly help. Cheers Sam + Jules
RE: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS: [TomcatDocumentation Redactors To Hire]
Craog I have a feeling that whatever is the same will be a lot of piecemeal here and there, excluding of course, web-app documentation. So far yourself, Pier, and Henri are the only three TC developers to post their position on that (re: inter-version relevancy). Pier and I also working together on a separate sub-project, J-T-C. A starting user will first install the servlet-engine and then will try to figure how to link it with its web-server. Should we ask him to switch from one documentation to another ? I thought of another reason for my preference in the shower this morning :-). Consider that I might make a code change that also requires a change to the corresponding docs. If the docs are in the same repository, that can easily be done on the same commit (and it becomes obvious to everyone when a developer makes a change that breaks the documentation, but fails to update it :-). Having a separate docs repository means I need to do two independent check-ins -- it's easy to forget one, and there is no obvious link between them to remind you (for example) to back out the docs change if you back out the code change. If you commit a code change in TC 4.0, you'll only have one doc commit in J-T-D. What's the duplicate effort here ? On the other hand, a separate docs repository has one potential advantage as well: we can grant CVS commit privileges on the docs to people who do not have those privileges on the code repositories. To me, this isn't a big deal -- if we can trust people to get the docs right, we should be able to trust them not to screw up the code -- but it's still there. That's the goal. a redactor will have access only to J-T-D. A tomcat commiter will have access to code docs... * The files that are checked in should only be the XML sources, *not* the generated files. This varies from what Jon set up in jakarta-site2, based on long and drawn out earlier discussions (same issues as those surrounding checking JAR files into CVS :-). Someone will have to setup something that exposes the latest generated documentation on the Jakarta www site. It's being done already for Struts, so I guess that won't be a big problem. It's pretty straightforward. * At least two documentation webapps (developer-oriented and user-oriented) would seem to be appropriate. Having more than two developer as in web or Tomcat? I'm not sure why separating the doc into two packages helps - perhaps I'm missing some obvious benefit trying to think at 7:15am =) Developer in the sense of this sentence is a Tomcat developer. User is the people that just want to download, install, configure, and utilize Tomcat as a servlet container. And a third category is the redactor, someone who write docs to explains users how to install and run TC stuff. He also describe to potentials new developpers Tomcats (3.2/3.3/4.0) architectures and how they could add functionnalities to the main core. That's why Apache HTTPD server was so successfull...
RE: hello everyone (regarding documentation)
Pier: A nice way to duplicate the job, indeed... Why not joining Alex et. al and Each contribution is good to have. If he feel more confortable using docbook, why not let him start some docs with it. write the documentation with them? Just because you want to do it with the DocBook DTD? A ridiculous excuse, as with a very simple XSLT stylesheet you can convert the Anakia DTD in DocBook with no fuzz... If an XSLT exist for converting Anakia to DocBook, it should be possible to do the reverse. Could you provide us, Pier, the XLST file to convert from Anakia to DocBook ? BTW, I didn't recall there was a vote on the list to decide if we should use DocBook or Anakia to produce documentation ?
cvs commit: jakarta-tomcat-4.0/catalina/src/bin catalina.bat
remm01/07/10 00:35:46 Modified:catalina/src/bin catalina.bat Log: - Syntax fix. Patch submitted by Sergey A. Lipnevich sergeyli at pisem.net Revision ChangesPath 1.15 +2 -2 jakarta-tomcat-4.0/catalina/src/bin/catalina.bat Index: catalina.bat === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/bin/catalina.bat,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- catalina.bat 2001/01/03 19:55:45 1.14 +++ catalina.bat 2001/07/10 07:35:43 1.15 @@ -12,7 +12,7 @@ rem rem JAVA_HOME Must point at your Java Development Kit installation. rem -rem $Id: catalina.bat,v 1.14 2001/01/03 19:55:45 craigmcc Exp $ +rem $Id: catalina.bat,v 1.15 2001/07/10 07:35:43 remm Exp $ rem --- @@ -68,7 +68,7 @@ if %1 == stop goto doStop :doUsage -echo Usage: catalina ( env | run | start | stop ) +echo Usage: catalina ( env ^| run ^| start ^| stop ) echo Commands: echo env - Set up environment variables that Catalina would use echo run - Start Catalina in the current window
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http HttpConnector.java
remm01/07/10 00:36:44
Modified:catalina/src/share/org/apache/catalina/connector/http
HttpConnector.java
Log:
- Negative value for maxProcessors means unlimited number of processors.
Bug reported by Kumar Mettu mettu.kumar at redspark.com
Revision ChangesPath
1.18 +17 -11
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpConnector.java
Index: HttpConnector.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpConnector.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- HttpConnector.java2001/06/18 21:35:54 1.17
+++ HttpConnector.java2001/07/10 07:36:42 1.18
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpConnector.java,v
1.17 2001/06/18 21:35:54 remm Exp $
- * $Revision: 1.17 $
- * $Date: 2001/06/18 21:35:54 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpConnector.java,v
1.18 2001/07/10 07:36:42 remm Exp $
+ * $Revision: 1.18 $
+ * $Date: 2001/07/10 07:36:42 $
*
*
*
@@ -95,7 +95,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.17 $ $Date: 2001/06/18 21:35:54 $
+ * @version $Revision: 1.18 $ $Date: 2001/07/10 07:36:42 $
*/
@@ -805,18 +805,24 @@
synchronized (processors) {
if (processors.size() 0) {
-//if (debug = 2)
-//log(createProcessor: Reusing existing
processor);
+// if (debug = 2)
+// log(createProcessor: Reusing existing processor);
return ((HttpProcessor) processors.pop());
}
if ((maxProcessors 0) (curProcessors maxProcessors)) {
-//if (debug = 2)
-//log(createProcessor: Creating new
processor);
+// if (debug = 2)
+// log(createProcessor: Creating new processor);
return (newProcessor());
} else {
-//if (debug = 2)
-//log(createProcessor: Cannot create new
processor);
- return (null);
+if (maxProcessors 0) {
+// if (debug = 2)
+// log(createProcessor: Creating new processor);
+return (newProcessor());
+ } else {
+// if (debug = 2)
+// log(createProcessor: Cannot create new processor);
+return (null);
+}
}
}
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http10 HttpConnector.java
remm01/07/10 00:37:08
Modified:catalina/src/share/org/apache/catalina/connector/http10
HttpConnector.java
Log:
- Negative value for maxProcessors means unlimited number of processors.
Bug reported by Kumar Mettu mettu.kumar at redspark.com
Revision ChangesPath
1.7 +12 -7
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http10/HttpConnector.java
Index: HttpConnector.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http10/HttpConnector.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- HttpConnector.java2001/05/09 23:42:14 1.6
+++ HttpConnector.java2001/07/10 07:37:05 1.7
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http10/HttpConnector.java,v
1.6 2001/05/09 23:42:14 craigmcc Exp $
- * $Revision: 1.6 $
- * $Date: 2001/05/09 23:42:14 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http10/HttpConnector.java,v
1.7 2001/07/10 07:37:05 remm Exp $
+ * $Revision: 1.7 $
+ * $Date: 2001/07/10 07:37:05 $
*
*
*
@@ -94,7 +94,7 @@
* purposes. Not intended to be the final solution.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.6 $ $Date: 2001/05/09 23:42:14 $
+ * @version $Revision: 1.7 $ $Date: 2001/07/10 07:37:05 $
*/
@@ -742,10 +742,15 @@
synchronized (processors) {
if (processors.size() 0)
return ((HttpProcessor) processors.pop());
- if ((maxProcessors 0) (curProcessors maxProcessors))
+ if ((maxProcessors 0) (curProcessors maxProcessors)) {
return (newProcessor());
- else
- return (null);
+ } else {
+if (maxProcessors 0) {
+return (newProcessor());
+} else {
+return (null);
+}
+}
}
}
RE: [PATCH] Ajp13 wrong Response
I'll study carefully this one to see if he didn't broke the recovery stuff added to handle case where tomcat is restarted... Thanks - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: William Barker [mailto:[EMAIL PROTECTED]] Sent: Monday, July 09, 2001 8:58 PM To: [EMAIL PROTECTED] Subject: [PATCH] Ajp13 wrong Response This fixes the problem reported by Angel Aray in thread 23795. The diff is against TC3.3 M4. What was happening is that the user hitting the stop button in the browser was invoking the re-try broken connection logic. This totally freaks out the proxy server who now thinks that the re-sent page is actually the page for a different request.
RE: Possible bug in isapi_redirector.dll
Hi Sam, -Original Message- From: sam [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 10, 2001 9:31 AM To: [EMAIL PROTECTED] Subject: Possible bug in isapi_redirector.dll Hello there everybody, We think we may have found a bug, possibly in IIS, which affects isapi_redirect.dll. We were wondering if anyone else has seen this. Perhaps this is a bug for MS, but it seems to affect tomcat so maybe someone here can shed some light. Our software versions are: IIS 4.0 jk_isapi_plugin.c revision 1.5.2.2 tomcat 3.2.2 Windows NT 4.0 sp6 The relevant code in is the file jk_isapi_plugin.c, line 960 in the function: static int get_server_value(LPEXTENSION_CONTROL_BLOCK lpEcb, char *name, char *buf, DWORD bufsz, char *def_val) When the function lpEcb-GetServerVariable(...) on line 965 is called to retrieve CERT_SERIALNUMBER, the value returned in bufsz is wrong. Our certificate serial number is 48 chars long, but the value contained in bufsz is 47, where it should be 49 (the length of the serial number + 1 for string terminator). After the call to GetServerVariable() a '\0' is inserted into buf at bufsz-1. This causes our certificate serial number to be truncated by 2 bytes. The microsoft doco says that the value returned should be the value length + 1 for the string terminator. This is from: http://msdn.microsoft.com/library/en-us/iisref/html/psdk/asp/is re8376.asp?fr ame=true The problem is clearly in IIS. It return 47 instead of 49 Could you see if the bug is reported in IIS
RE: [DOC]: Vote on oustanding doc issues?
Yeah, I guess anarchy will be a little too... anarchic :-) (Rob S. made the point more strongly in his latest message.) PDF conversion would be pretty cool... Anyone feel like coming up with a sheet to generate XSL:FO? =) If someone is scared of XML, they can submit it to us in text format and we can go add tags (as time permits), but we're all developers here, so I don't think that's an issue. With the (hopeful ;) abundance of docs we'll put in there ourselves, there'll be plenty of sample 'code' to work with. As well, the closer we stick to HTML, the easier it'll be... I. Standalone Installation Guide II. Installation Behind a Web Server Guide III. Deploying and Configuring, or Tomcat Administrator's Guide IV. Performance Tuning Guide V. Tomcat Developer's Guide (writing code for Tomcat itself) I and II may merge, as may III and IV, but I think we're looking at at least three major parts. Seems natural that they'd be in separate subdirectories. But... I like the above breakdown as a high-level view of things. I won't have a chance to look at the new detailed TOC until tonite, but anything I can't think of that would go in the docs easily fits under I - V. The tough thing about separating the docs is that the server.xml config stuff is spread out among multiple files. I wonder how difficult it would be to maintain an index, or even if it's necessary. As well, is the intro not part of this breakdown or just not necessary or what? Is the list even getting my emails? =) I still think we should have an intro for people that may/not use Tomcat... err I'll just write it tonite and send it to the list and you guys can let me know if you like the direction it's headed in! =p My vote is -1 for a separate mailing list at this point, at least until we prove that we're not going to peter out like every other documentation effort so far. :-) Agreed! - r
RE: [DOC] Vote on oustanding doc issues?
Things To Do before we decide on format or CVS: * Look at the latest TOC and make comments * Pick a section or subsection and start writing :-) * Look at http://tomcatbook.sourceforge.net/ and http://groups.yahoo.com/group/tcbook and see if there's anyone there to recruit, or if effort is being duplicated Sounds good to me. That latest TOC is even more mind-blowing than the first one. I think you're *really* scaring people off =) I like this compromise. I will propose that we get rid of the 3.2 docs on the site -- once I'm convinced they're similar enough. There's still that old 3.3 is a rogue release sentiment floating around, and people might not appreciate giving 3.3 implied legitimacy by making it the official documentation... Woah, I thought the committers worked that out a long time ago. Well, I don't want to open any cans of worms so AFAIC, the TC3 doc people can do what they want (of course), although I don't think maintaining 2 sets of docs is expected, a good idea, or will even happen =) Good point. I'm for Anakia plus a stylebook saying which HTML tags and tricks are approved (like, stay away from JavaScript :-) OMG! +1 (re: JavaScript) No, I think we're making progress. As far as the TOC is concerned, agreed. - r
RE: [DOC]: Vote on oustanding doc issues?
PDF conversion would be pretty cool... Anyone feel like coming up with a sheet to generate XSL:FO? =) Good idea, we should find help on xml.apache.org. If someone is scared of XML, they can submit it to us in text format and we can go add tags (as time permits), but we're all developers here, so I don't think that's an issue. With the (hopeful ;) abundance of docs we'll put in there ourselves, there'll be plenty of sample 'code' to work with. As well, the closer we stick to HTML, the easier it'll be... I. Standalone Installation Guide II. Installation Behind a Web Server Guide III. Deploying and Configuring, or Tomcat Administrator's Guide IV. Performance Tuning Guide V. Tomcat Developer's Guide (writing code for Tomcat itself) I and II may merge, as may III and IV, but I think we're looking at at least three major parts. Seems natural that they'd be in separate subdirectories. But... I feel that I and II shouldn't merge. It will confuse users with Apache .conf, and server.xml. Also many time, it will be only the Admin/WebMaster of a site which will read the part II. May be more fluent in Apache config that Tomcat server.xml... My vote is -1 for a separate mailing list at this point, at least until we prove that we're not going to peter out like every other documentation effort so far. :-) I agree with you. Just prefix your mail with [J-T-D] and it will help developpers follow your works and questions :)
RE: Table of Contents
2) How about moving Developing Interceptors, Valves and Connectors, and Using Tomcat Utility Classes to a seperate Developer Guide? They are only useful for real hackers. Don't forget what make Apache HTTP server so successfull. The number of modules built for Apache 1.2/1.3 APIs. If we don't comments and explain how to use and extend Tomcat, we'll loose many contributions and indirects users.
AW: [DOC]: Vote on oustanding doc issues?
PDF conversion would be pretty cool... Anyone feel like coming up with a sheet to generate XSL:FO? =) No problem, I can help out on this issue regards, tom
Re: t4 - status check
What is the status of T4? I haven't seen a huge amount of commits from Craig and Remy recently Did you hear about Sun's shutdown last week ? ;-) no ... :) what is this all about ??
RE: t4 - status check
What is the status of T4? I haven't seen a huge amount of commits from Craig and Remy recently and it seems like the whole adaptor stuff will never get finished cause it seems like a big political, testing and configuration mess. Did you notice the commit from JF Clere and Pier on J-T-C ???
cvs commit: jakarta-tomcat build.xml
larryi 01/07/10 06:03:40
Modified:.build.xml
Log:
Update javadoc tasks to avoid most of the error messages
Revision ChangesPath
1.140 +35 -8 jakarta-tomcat/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat/build.xml,v
retrieving revision 1.139
retrieving revision 1.140
diff -u -r1.139 -r1.140
--- build.xml 2001/07/02 19:40:54 1.139
+++ build.xml 2001/07/10 13:03:34 1.140
@@ -636,11 +636,31 @@
chmod perm=+x file=${tomcat.dist}/bin/shutdown.sh/
/target
+ path id=javadoc.classpath
+pathelement location=${servlet22.jar}/
+fileset dir=${jaxp.home}
+ include name=jaxp.jar/
+ include name=parser.jar/
+ include name=crimson.jar/
+ include name=xerces.jar/
+/fileset
+fileset dir=${java.home}/..
+ include name=lib/tools.jar/
+/fileset
+fileset dir=${java.home}
+ include name=lib/classes.zip/
+/fileset
+fileset dir=${jsse.lib}
+ include name=*.jar if=jdk12.present/
+/fileset
+ /path
+
target name=javadoc depends=main,webapps,tomcat-jars
!-- Add Tomcat internal javadoc --
mkdir dir=${tomcat.build}/webapps/ROOT/javadoc/
javadoc packagenames=org.apache.*
- sourcepath=src/share;src/facade22
+
sourcepath=src/share;src/facade22;${jakarta-tomcat-connectors}/util/java
+ classpathref=javadoc.classpath
destdir=${tomcat.build}/webapps/ROOT/javadoc
author=true
version=true
@@ -652,7 +672,8 @@
/target
target name=javadoc.tomcat depends=main,webapps,tomcat-jars
javadoc packagenames=org.apache.tomcat.*
- sourcepath=src/share;src/facade22
+
sourcepath=src/share;src/facade22;${jakarta-tomcat-connectors}/util/java
+ classpathref=javadoc.classpath
destdir=${tomcat.build}/webapps/ROOT/javadoc
author=true
version=true
@@ -663,7 +684,8 @@
/target
target name=javadoc.tomcat.core depends=main,webapps,tomcat-jars
javadoc packagenames=org.apache.tomcat.core
- sourcepath=src/share;src/facade22
+
sourcepath=src/share;src/facade22;${jakarta-tomcat-connectors}/util/java
+ classpathref=javadoc.classpath
destdir=${tomcat.build}/webapps/ROOT/javadoc
author=true
version=true
@@ -674,7 +696,8 @@
/target
target name=javadoc.tomcat.facade depends=main,webapps,tomcat-jars
javadoc packagenames=org.apache.tomcat.facade
- sourcepath=src/share;src/facade22
+
sourcepath=src/share;src/facade22;${jakarta-tomcat-connectors}/util/java
+ classpathref=javadoc.classpath
destdir=${tomcat.build}/webapps/ROOT/javadoc
author=true
version=true
@@ -685,7 +708,8 @@
/target
target name=javadoc.tomcat.modules depends=main,webapps,tomcat-jars
javadoc packagenames=org.apache.tomcat.modules.*
- sourcepath=src/share;src/facade22
+
sourcepath=src/share;src/facade22;${jakarta-tomcat-connectors}/util/java
+ classpathref=javadoc.classpath
destdir=${tomcat.build}/webapps/ROOT/javadoc
author=true
version=true
@@ -696,7 +720,8 @@
/target
target name=javadoc.tomcat.startup depends=main,webapps,tomcat-jars
javadoc packagenames=org.apache.tomcat.startup
- sourcepath=src/share;src/facade22
+
sourcepath=src/share;src/facade22;${jakarta-tomcat-connectors}/util/java
+ classpathref=javadoc.classpath
destdir=${tomcat.build}/webapps/ROOT/javadoc
author=true
version=true
@@ -707,7 +732,8 @@
/target
target name=javadoc.tomcat.util depends=main,webapps,tomcat-jars
javadoc packagenames=org.apache.tomcat.util.*
- sourcepath=src/share;src/facade22
+
sourcepath=src/share;src/facade22;${jakarta-tomcat-connectors}/util/java
+ classpathref=javadoc.classpath
destdir=${tomcat.build}/webapps/ROOT/javadoc
author=true
version=true
@@ -718,7 +744,8 @@
/target
target name=javadoc.jasper depends=main,webapps,tomcat-jars
javadoc packagenames=org.apache.jasper.*
- sourcepath=src/share;src/facade22
+
sourcepath=src/share;src/facade22;${jakarta-tomcat-connectors}/util/java
+ classpathref=javadoc.classpath
destdir=${tomcat.build}/webapps/ROOT/javadoc
author=true
version=true
Re: InstanceListener syntax?
Remy Maucherat wrote: Hi folks, can someone give me the definitive syntax for the InstanceListener? Also, is it possible to setup an Engine (or Host) level InstanceListener that would get applied to all context's within said Engine or Host? Having to add a InstanceListener to every context just to get the old tomcat 3.2 pre/post Lifecycle event (Init,service,destroy) support is a bit onerous. Glenn, would the default context help here ? Remy Its in the code for DefaultContext, but I don't know if it has been tested. Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: t4 - status check
GOMEZ Henri at [EMAIL PROTECTED] wrote: What is the status of T4? I haven't seen a huge amount of commits from Craig and Remy recently and it seems like the whole adaptor stuff will never get finished cause it seems like a big political, testing and configuration mess. Did you notice the commit from JF Clere and Pier on J-T-C ??? Knowing Jon, I don't really think he was referring to the module... He would have called it module :) Pier
[TC322 diff] appending to logfiles
Hi All,
Hope all is well.
I know TC322 is now in maintainence mode, but FWIW, here's a patch
that allows you to specify append=boolean in the Logger definitions
of the server.xml. This allows you to configure appending to log
files in the server.xml.
Is such functionality already in TC33 or T4 ?
Cheers,
Marcus
--
.
,,$, Marcus Crafter
;$' ':Computer Systems Engineer
$: : Open Software Associates GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$,_/\ :' 60327 Frankfurt Germany
' /(
\_' Email : [EMAIL PROTECTED]
.Business Hours : +49 69 9757 200
:
Index: src/share/org/apache/tomcat/logging/Logger.java
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/logging/Attic/Logger.java,v
retrieving revision 1.7.4.1
diff -u -r1.7.4.1 Logger.java
--- src/share/org/apache/tomcat/logging/Logger.java 2000/07/06 22:20:17
1.7.4.1
+++ src/share/org/apache/tomcat/logging/Logger.java 2001/07/10 10:20:47
@@ -236,7 +236,7 @@
if (!file.exists())
new File(file.getParent()).mkdirs();
- this.sink = new FileWriter(path);
+ this.sink = new FileWriter(path, append);
} catch (IOException ex) {
System.err.print(Unable to open log file: +path+! );
System.err.println( Using stderr as the default.);
@@ -253,6 +253,19 @@
public static final int INFORMATION = 3;
public static final int DEBUG = 4;
+/**
+ * Set whether this logger should append to log files or not. Default is
+ * not to.
+ *
+ * @param flagboolean string indicated whether or not logs
+ * should be appended to.
+ */
+public void setAppend(String flag) {
+if (true.equalsIgnoreCase(flag))
+ this.append = true;
+ else
+ this.append = false;
+}
/**
* Set the verbosity level for this logger. This controls how the
@@ -398,6 +411,7 @@
protected static Hashtable loggers = new Hashtable(5);
private int level = WARNING;
+private boolean append = false;
/**
* Should we timestamp this log at all?
RE: t4 - status check
Knowing Jon, I don't really think he was referring to the module... He would have called it module :) Could someone teach us why the word 'module' is so impopular in Tomcat whereas it was the success reason of Apache HTTP Server. Small is beautifull :)
RE: My small, simple problem continued... (null container for my valve)
All right, I think I figured it out, and it seems a little strange. I was checking to see what the container for my valve was, in the _constructor_...the constructor is getting called before any of the heirarchy tree is built, it seems. Does Catalina load up components and run constructors in-order, rather than pre-order? One odd question, though...when IS the invoke method of a valve called? -KSH -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Monday, July 09, 2001 5:57 PM To: [EMAIL PROTECTED] Subject: Re: My small, simple problem continued... (null container for my valve) Oh, WOW. It did work, and I didn't even have to modify Catalina's startup classpath. I had tried putting the class under common\lib and server\lib, but I didn't know that common\classes would work. But now I've got another problem... In the lib folders, you can only put jars. Un-jarred classes should be in the classes folders. That's mentioned in the CL docs. The best place to put your valve here is in server/classes/ Again, I have this barebones valve class I wrote, and I've gotten it to load up without exception in Catalina. Now, oddly enough, I find that my valve has a null container, even though its nested in a context in my server.xml: Context className=org.apache.catalina.core.StandardContext path=/ debug=0 docBase=/ reloadable=true Logger className=org.apache.catalina.logger.FileLogger verbosity=1 directory=/logs/kedlog prefix=valvetest timestamp=true / Valve className=org.apache.catalina.valvetest.KedValve / /Context Is there some initialization I need to do, or am I forgetting some tags in my server.xml? Does your valve extend ValveBase or implement Contained ? Remy
RE: My small, simple problem continued... (null container for my valve)
Forget the last question. I'm finding that I'm rising to new levels of stupidity. :)
InvocationTargetException tomcat + visualage
Hi, I also have had similar problems with an InvocationTargetException being thrown by StartTomcat. I am using VisualAge 3.0 Enterprise and Tomcat 3.2.2, following instructions found in http://www7.software.ibm.com/vad.nsf/Data/Document2390?OpenDocument I also have made the suggested code change to the main in StartTomcat, overcome the issue of passing arguments and setting the home to . in the main of StartTomcat. Have you any other suggestions, as to what the cause is? Cheers Jayne
RE: t4 - status check
Did you hear about Sun's shutdown last week ? ;-) no ... :) what is this all about ?? Sun asked everybody to use up some vacation, so they could stop carrying it as a future liability. They weren't alone. See, e.g.: http://public.wsj.com/sn/y/SB993836687859524630.html tc
Re: t4 - status check
GOMEZ Henri at [EMAIL PROTECTED] wrote: Knowing Jon, I don't really think he was referring to the module... He would have called it module :) Could someone teach us why the word 'module' is so impopular in Tomcat whereas it was the success reason of Apache HTTP Server. Small is beautifull :) It's not unpopular at all... Who makes you believe it is? Pier
Year in copyright
The current LICENSE file in jakarta-tomcat root says Copyright 1999. Shouldn't this be 1999-2001? Or does it apply to the text of the license, and not to the content of the project? -- Alex Chaffee mailto:[EMAIL PROTECTED] jGuru - Java News and FAQs http://www.jguru.com/alex/ Creator of Gamelan http://www.gamelan.com/ Founder of Purple Technology http://www.purpletech.com/ Curator of Stinky Art Collective http://www.stinky.com/
Re: hello everyone (regarding documentation)
GOMEZ Henri wrote: Pier: A nice way to duplicate the job, indeed... Why not joining Alex et. al and Each contribution is good to have. If he feel more confortable using docbook, why not let him start some docs with it. write the documentation with them? Just because you want to do it with the DocBook DTD? A ridiculous excuse, as with a very simple XSLT stylesheet you can convert the Anakia DTD in DocBook with no fuzz... If an XSLT exist for converting Anakia to DocBook, it should be possible to do the reverse. Could you provide us, Pier, the XLST file to convert from Anakia to DocBook ? Docbook is a *huge* file format. I've heard it described as SGML in XML. There are probably features in DocBook that would be very difficult to automatically port back to XHTML. BTW, I didn't recall there was a vote on the list to decide if we should use DocBook or Anakia to produce documentation ? Not yet. Another reason why nobody should jump the gun with a complicated format that might end up having to be ported to XHTML. My advice for potential authors is to use text or very simple HTML (h1, code, p, pre, and a) so it'll be easy to shift to a common format once we do decide. Also it'll mean you don't waste time making it pretty, and focus on the text itself. -- Alex Chaffee mailto:[EMAIL PROTECTED] jGuru - Java News and FAQs http://www.jguru.com/alex/ Creator of Gamelan http://www.gamelan.com/ Founder of Purple Technology http://www.purpletech.com/ Curator of Stinky Art Collective http://www.stinky.com/
Re: [DOC]: Vote on oustanding doc issues?
Rob S. wrote: The tough thing about separating the docs is that the server.xml config stuff is spread out among multiple files. I wonder how difficult it would be to maintain an index, or even if it's necessary. I don't think it's a big deal. I forgot to list the appendices, but one of them will be a technical doc describing server.xml tag by tag. Whoever writes this should put links in to the relevant parts of the TOC (which will in turn contain links to the relevant documents). As well, is the intro not part of this breakdown or just not necessary or what? Is the list even getting my emails? =) I still think we should have an intro for people that may/not use Tomcat... err I'll just write it tonite and send it to the list and you guys can let me know if you like the direction it's headed in! =p I'm not too worried about the intro, since the Web site already has a paragraph describing it, but a why should I use Tomcat chapter would go in the Overview section (see TOC). Also, that's more a FAQ than a chapter. But hey, write it! We'll check it in, and you can also post it to the jGuru FAQ if you like. -- Alex Chaffee mailto:[EMAIL PROTECTED] jGuru - Java News and FAQs http://www.jguru.com/alex/ Creator of Gamelan http://www.gamelan.com/ Founder of Purple Technology http://www.purpletech.com/ Curator of Stinky Art Collective http://www.stinky.com/
Re: [DOC] Vote on oustanding doc issues?
Rob S. wrote: I like this compromise. I will propose that we get rid of the 3.2 docs on the site -- once I'm convinced they're similar enough. There's still that old 3.3 is a rogue release sentiment floating around, and people might not appreciate giving 3.3 implied legitimacy by making it the official documentation... Woah, I thought the committers worked that out a long time ago. I was off the list for a while. I tried to read through the archives but all the vitriol gave me a headache. Did they just agree to disagree? Do you think there'll be a problem with proposing to remove the 3.2 docs from the site? -- Alex Chaffee mailto:[EMAIL PROTECTED] jGuru - Java News and FAQs http://www.jguru.com/alex/ Creator of Gamelan http://www.gamelan.com/ Founder of Purple Technology http://www.purpletech.com/ Curator of Stinky Art Collective http://www.stinky.com/
Re: [DOC]: Vote on oustanding doc issues?
on 7/10/01 4:06 AM, Rob S. [EMAIL PROTECTED] wrote: PDF conversion would be pretty cool... Anyone feel like coming up with a sheet to generate XSL:FO? =) We have started that here: http://jakarta.apache.org/cvsweb/index.cgi/jakarta-velocity/whiteboard/dave b/pdfvsl/ Not perfect yet because Anakia will need some tweaking to generate all of the pages as a single FO object, but it is a start. The real hard part is figuring out how to write FO's. :-) -jon
RE: [DOC] Table of Contents
I'm missing a very important one : servlet debugging. All the development environments support jps debugging, but servlet debugging is still a pain.. So that could need some explenation.. Mvgr, Martin -Original Message- From: Alex Chaffee [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 10, 2001 4:37 AM To: [EMAIL PROTECTED] Subject: [DOC] Table of Contents OK, at Craig's request, here's the current Table of Contents for Tomcat docs. (I wrote a program to convert *** to 1.2.3. format so it's easier to read.) It just occured to me that maybe the TOC will be applicable to both versions (3 vs 4), even though the content of each chapter will be completely different. I think there's actually value in synchronizing the TOCs of two different books, though maybe I'm just being weird :-) -- Alex Chaffee mailto:[EMAIL PROTECTED] jGuru - Java News and FAQs http://www.jguru.com/alex/ Creator of Gamelan http://www.gamelan.com/ Founder of Purple Technology http://www.purpletech.com/ Curator of Stinky Art Collective http://www.stinky.com/
Suggestions (was Re: hello everyone (regarding documentation))
Hi Hiten! hiten pandya wrote: i am planning to start my own documentation project for Tomcat 3.3 and 4.0. The different thing about this project is that, i am going to port all of the tomcat documentation to XML Docbook format. Not speaking officially, I'm not a committer: if you want to document Tomcat, then go ahead and good luck! Your focused work can do lots for the docs: you will probably end before the committee decides the right format for Tomcat docs :) Just a suggestion: Though i am not very good at docbook but i think i can cope. Once the documentation is complete, I will submit it to the main tomcat development team. Don't wait till everything is ready; send your updates regularly to the dev list, so folks can criticize your work and point possible mistakes. That way, you can change course in a timely manner; otherwise you might find at the end that a chapter is unnecessary and another one is missing :) Un saludo, Alex.
RE: InstanceListener syntax?
Hi Guys, I'm a wee bit confused - I was looking for the XML Syntax for the InstanceListener, not how it's being used within the default context. I've tried the following in server.xml (within a Context definition): InstanceListener my.instance.listener /InstanceListener And this works fine, however it doesn't match the other more familiar constructs within server.xml, something similar to: InstanceListener className=my.instance.listener debug=99 /InstanceListener I was just curious as to what, if any, xml exposed options were available for InstanceListener. And again, I'm still wondering if it's possible to have an Engine or Host level instance listener be applied to all Contexts (where the context doesn't have an Instance entry of it's own). How is DefaultContext used? Is it used in the case where there is not a Context entry for a war file being served by tomcat? Either way, it looks to me that, if I want to handle before/after events for any given servlet, I need to specifically add an InstanceListener to each and every Context. Does anyone know of an alternative way of catching the before and after stages of servlet init, service and destroy? In tomcat 3.2 I just used a specialized Interceptor (which nicely applied to all contexts) this new way is a bit awkward... Hmm... maybe I can add a InstanceListener list to the parent container(s) and, in the code that handles the current InstanceListener processing, in the absence of there being a ContextLevel InstanceListener, I could go up the hierarchy looking for Instance listeners to invoke. Any thoughts if that makes sense - or am I likely to get in trouble with class loading (Context level vs. host Engine level)... -Thom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Glenn Nielsen Sent: Tuesday, July 10, 2001 6:16 AM To: [EMAIL PROTECTED] Subject: Re: InstanceListener syntax? Remy Maucherat wrote: Hi folks, can someone give me the definitive syntax for the InstanceListener? Also, is it possible to setup an Engine (or Host) level InstanceListener that would get applied to all context's within said Engine or Host? Having to add a InstanceListener to every context just to get the old tomcat 3.2 pre/post Lifecycle event (Init,service,destroy) support is a bit onerous. Glenn, would the default context help here ? Remy Its in the code for DefaultContext, but I don't know if it has been tested. Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
RE: InstanceListener syntax?
I've had a better look at DefaultContext, it appears to do what I want - i.e. give me the ability to define InstanceListener once that will be applied for all contexts within a given host. Now I need to find out how to define a DefaultContext ;-) -Thom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Glenn Nielsen Sent: Tuesday, July 10, 2001 6:16 AM To: [EMAIL PROTECTED] Subject: Re: InstanceListener syntax? Remy Maucherat wrote: Hi folks, can someone give me the definitive syntax for the InstanceListener? Also, is it possible to setup an Engine (or Host) level InstanceListener that would get applied to all context's within said Engine or Host? Having to add a InstanceListener to every context just to get the old tomcat 3.2 pre/post Lifecycle event (Init,service,destroy) support is a bit onerous. Glenn, would the default context help here ? Remy Its in the code for DefaultContext, but I don't know if it has been tested. Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: [DOC] Table of Contents
Martin van den Bemt wrote: I'm missing a very important one : servlet debugging. All the development environments support jps debugging, but servlet debugging is still a pain.. So that could need some explenation.. See http://www.jguru.com/faq/view.jsp?EID=158 I've added it to the TOC. -- Alex Chaffee mailto:[EMAIL PROTECTED] jGuru - Java News and FAQs http://www.jguru.com/alex/ Creator of Gamelan http://www.gamelan.com/ Founder of Purple Technology http://www.purpletech.com/ Curator of Stinky Art Collective http://www.stinky.com/
InstanceListener event handling?
Hi Folks, more on the whole InstanceListener thing. First the good news - Inserting a DefaultContext at the Engine or Host level allows each Context that doesn't define the override attribute to successfully pick up the InstanceListener defined in the DefaultContext. I'm assuming that the only syntax for multiple InstanceListeners is as follows: InstanceListener my.instance.listener1 /InstanceListener Please tell me if this is a wrong assumption. And now for something that's confusing me! I've written a simple instance listener that simply outputs which event it's either before or after and I get the following output: beforeFilter received for app '/examples' beforeFilter received for app '/examples' beforeService received for app '/examples' beforeInit received for app '/examples' afterInit received for app '/examples' afterService received for app '/examples' afterFilter received for app '/examples' afterFilter received for app '/examples' beforeService received for app '/examples' afterService received for app '/examples' beforeService received for app '/examples' afterService received for app '/examples' beforeService received for app '/examples' afterService received for app '/examples' beforeService received for app '/examples' afterService received for app '/examples' Why does the 'beforeService' get called before the 'beforeInit'? Shouldn't an init precede the service event in all cases of a servlet call? In the above output, \ the init call seems to be nested withing the service call e.g. ... beforeService beforeInit afterInit afterService ... The before and after events for my servlet also seem to be being called far more often that I would expect ie. for one request why don't I see the following: beforeFilter afterFilter (for every filter defined for my app) beforeInit afterInit beforeService afterService and, ultimately, beforeDestroy afterDestroy why do I see so many beforeService/afterService calls? - after all, I'm only invoking my servlet once. and, if it's some system servlet (like invokerServlet), why don't I see just as many beforeInit/afterInit calls. Of course this is all likely due to my lack of understanding of the Servlet spec (it usually is!) -Thom
Re: Suggestions (was Re: hello everyone (regarding documentation))
On Tue, Jul 10, 2001 at 10:39:12AM +0200, Alex Fernández wrote: Hi Hiten! hiten pandya wrote: i am planning to start my own documentation project for Tomcat 3.3 and 4.0. The different thing about this project is that, i am going to port all of the tomcat documentation to XML Docbook format. Not speaking officially, I'm not a committer: if you want to document Tomcat, then go ahead and good luck! Your focused work can do lots for the docs: you will probably end before the committee decides the right format for Tomcat docs :) OK, I appreciate the :-) but... that's not *quite* fair. We're closing in on a decision, and if you want to write new stuff now you should just go ahead and do it. Use text or HTML or even Word. I think using DocBook is premature. I don't think a wholesale conversion of existing docs to DocBook will be a good use of anyone's time right now. Maybe in a week or two we'll be converting them to Anakia or DocBook but not just yet. Just a suggestion: Though i am not very good at docbook but i think i can cope. Once the documentation is complete, I will submit it to the main tomcat development team. Don't wait till everything is ready; send your updates regularly to the dev list, so folks can criticize your work and point possible mistakes. That way, you can change course in a timely manner; otherwise you might find at the end that a chapter is unnecessary and another one is missing :) Before you write a chapter (or article or HOWTO or whatever you want to call it), please take a look at (a) the existing docs, and more importantly (b) the Table of Contents and see if it fits in anywhere. Then let the list know what you're working on. We're trying to organize the docs so there's no redundant information. (For instance, there's lots of information on configuring Apache scattered among half a dozen howtos and FAQs right now. Most of it is now out of date, and it'll be impossible to bring it all current. I'd like there to be one chapter on integrating with Apache, with subsections for mod_jk, mod_webapp, mod_jserv, and so on -- and since the subsections can rely on the introduction of the Apache chapter, they won't have to duplicate information that's already been covered above, and won't confuse anybody. On the Tomcat Forum I regularly get questions where people have read a mod_jserv howto instead of a mod_jk howto and they don't even realize there's a difference, since they're both called Configuring Apache without mentioning the name of the connector.) -- Alex Chaffee mailto:[EMAIL PROTECTED] jGuru - Java News and FAQs http://www.jguru.com/alex/ Creator of Gamelan http://www.gamelan.com/ Founder of Purple Technology http://www.purpletech.com/ Curator of Stinky Art Collective http://www.stinky.com/
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler ParserController.java
horwat 01/07/10 13:12:13
Modified:jasper/src/share/org/apache/jasper/compiler
ParserController.java
Log:
Fixes include bug. Nested include directive files were not found. In an include
directive, the file should be found relative to the jsp file doing the including.
Helpful hint:
%@ include file=XX % says file and is thus relative to the JSP file.
jsp:include page=XXX / says page and is thus relative to the JSP page.
Bugzilla #2543
Revision ChangesPath
1.16 +1 -2
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/ParserController.java
Index: ParserController.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/ParserController.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- ParserController.java 2001/06/02 18:44:45 1.15
+++ ParserController.java 2001/07/10 20:12:07 1.16
@@ -186,7 +186,6 @@
String absFileName = resolveFileName(inFileName);
//p(filePath: + filePath);
-
String encoding = topFileEncoding;
InputStreamReader reader = null;
try {
@@ -419,7 +418,7 @@
isAbsolute ?
inFileName : (String) baseDirStack.peek() + inFileName;
String baseDir =
- inFileName.substring(0, inFileName.lastIndexOf(/) + 1);
+ fileName.substring(0, fileName.lastIndexOf(/) + 1);
baseDirStack.push(baseDir);
return fileName;
}
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/runtime PageContextImpl.java
horwat 01/07/10 13:20:05 Modified:jasper/src/share/org/apache/jasper/runtime PageContextImpl.java Log: Added missing break statement to REQUEST_SCOPE case. Bugzilla #2423 Revision ChangesPath 1.11 +4 -3 jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/runtime/PageContextImpl.java Index: PageContextImpl.java === RCS file: /home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/runtime/PageContextImpl.java,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- PageContextImpl.java 2001/05/10 20:42:33 1.10 +++ PageContextImpl.java 2001/07/10 20:20:02 1.11 @@ -1,7 +1,7 @@ /* - * $Header: /home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/runtime/PageContextImpl.java,v 1.10 2001/05/10 20:42:33 craigmcc Exp $ - * $Revision: 1.10 $ - * $Date: 2001/05/10 20:42:33 $ + * $Header: /home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/runtime/PageContextImpl.java,v 1.11 2001/07/10 20:20:02 horwat Exp $ + * $Revision: 1.11 $ + * $Date: 2001/07/10 20:20:02 $ * * * @@ -262,6 +262,7 @@ case REQUEST_SCOPE: request.removeAttribute(name); +break; case SESSION_SCOPE: if (session == null)
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler TagEndGenerator.java
horwat 01/07/10 13:32:04
Modified:jasper/src/share/org/apache/jasper/compiler
TagEndGenerator.java
Log:
Changed to a more meaningful variable name.
Bugzilla #2364
Revision ChangesPath
1.7 +2 -2
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/TagEndGenerator.java
Index: TagEndGenerator.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/TagEndGenerator.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- TagEndGenerator.java 2001/04/26 23:17:40 1.6
+++ TagEndGenerator.java 2001/07/10 20:32:01 1.7
@@ -179,9 +179,9 @@
// TryCatchFinally
if (implementsTryCatchFinally) {
- writer.println(} catch (Throwable t) {);
+ writer.println(} catch (Throwable exception) {);
writer.pushIndent();
- writer.println(thVarName+.doCatch(t););
+ writer.println(thVarName+.doCatch(exception););
writer.popIndent();
}
cvs commit: jakarta-tomcat-jasper/jasper34/generator/org/apache/jasper34/generator CharDataGenerator.java MappedCharDataGenerator.java
larryi 01/07/10 13:41:53
Modified:jasper34/generator/org/apache/jasper34/generator
CharDataGenerator.java MappedCharDataGenerator.java
Log:
Fix problem with JSP files which use just CR as line terminator. During
translation CR's would be stripped instead of kept as is or replaced with
CRLF. With this patch, line termination is preserved.
Submitted by: Si Ly
Revision ChangesPath
1.5 +6 -5
jakarta-tomcat-jasper/jasper34/generator/org/apache/jasper34/generator/CharDataGenerator.java
Index: CharDataGenerator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper34/generator/org/apache/jasper34/generator/CharDataGenerator.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- CharDataGenerator.java2001/06/13 01:11:35 1.4
+++ CharDataGenerator.java2001/07/10 20:41:49 1.5
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-jasper/jasper34/generator/org/apache/jasper34/generator/CharDataGenerator.java,v
1.4 2001/06/13 01:11:35 costin Exp $
- * $Revision: 1.4 $
- * $Date: 2001/06/13 01:11:35 $
+ * $Header:
/home/cvs/jakarta-tomcat-jasper/jasper34/generator/org/apache/jasper34/generator/CharDataGenerator.java,v
1.5 2001/07/10 20:41:49 larryi Exp $
+ * $Revision: 1.5 $
+ * $Date: 2001/07/10 20:41:49 $
*
*
*
@@ -109,7 +109,8 @@
sb.append();
break;
case '\r':
- continue;
+ sb.append(\\r);
+ break;
/*
case '\'':
sb.append('\\');
@@ -117,7 +118,7 @@
break;
*/
case '\n':
- sb.append(\\r\\n);
+ sb.append(\\n);
break;
case '\t':
sb.append(\\t);
1.3 +6 -5
jakarta-tomcat-jasper/jasper34/generator/org/apache/jasper34/generator/MappedCharDataGenerator.java
Index: MappedCharDataGenerator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper34/generator/org/apache/jasper34/generator/MappedCharDataGenerator.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- MappedCharDataGenerator.java 2001/06/06 06:17:47 1.2
+++ MappedCharDataGenerator.java 2001/07/10 20:41:50 1.3
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-jasper/jasper34/generator/org/apache/jasper34/generator/MappedCharDataGenerator.java,v
1.2 2001/06/06 06:17:47 costin Exp $
- * $Revision: 1.2 $
- * $Date: 2001/06/06 06:17:47 $
+ * $Header:
/home/cvs/jakarta-tomcat-jasper/jasper34/generator/org/apache/jasper34/generator/MappedCharDataGenerator.java,v
1.3 2001/07/10 20:41:50 larryi Exp $
+ * $Revision: 1.3 $
+ * $Date: 2001/07/10 20:41:50 $
*
*
*
@@ -95,7 +95,8 @@
sb.append();
break;
case '\r':
- continue;
+ sb.append(\\r);
+ break;
/*
case '\'':
sb.append('\\');
@@ -103,7 +104,7 @@
break;
*/
case '\n':
- sb.append(\\r\\n);
+ sb.append(\\n);
writer.print(sb.toString());
writer.print(\);\n);
sb = new StringBuffer();
cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compiler CharDataGenerator.java MappedCharDataGenerator.java
larryi 01/07/10 13:43:38
Modified:src/share/org/apache/jasper/compiler Tag: tomcat_32
CharDataGenerator.java MappedCharDataGenerator.java
Log:
Fix problem with JSP files which use just CR as line terminator. During
translation CR's would be stripped instead of kept as is or replaced with
CRLF. With this patch, line termination is preserved.
Submitted by: Si Ly
Revision ChangesPath
No revision
No revision
1.2.4.1 +6 -5
jakarta-tomcat/src/share/org/apache/jasper/compiler/CharDataGenerator.java
Index: CharDataGenerator.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/CharDataGenerator.java,v
retrieving revision 1.2
retrieving revision 1.2.4.1
diff -u -r1.2 -r1.2.4.1
--- CharDataGenerator.java2000/04/05 02:55:12 1.2
+++ CharDataGenerator.java2001/07/10 20:43:33 1.2.4.1
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/CharDataGenerator.java,v
1.2 2000/04/05 02:55:12 craigmcc Exp $
- * $Revision: 1.2 $
- * $Date: 2000/04/05 02:55:12 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/CharDataGenerator.java,v
1.2.4.1 2001/07/10 20:43:33 larryi Exp $
+ * $Revision: 1.2.4.1 $
+ * $Date: 2001/07/10 20:43:33 $
*
*
*
@@ -107,7 +107,8 @@
sb.append();
break;
case '\r':
- continue;
+ sb.append(\\r);
+ break;
/*
case '\'':
sb.append('\\');
@@ -115,7 +116,7 @@
break;
*/
case '\n':
- sb.append(\\r\\n);
+ sb.append(\\n);
break;
case '\t':
sb.append(\\t);
1.2.4.1 +6 -5
jakarta-tomcat/src/share/org/apache/jasper/compiler/MappedCharDataGenerator.java
Index: MappedCharDataGenerator.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/MappedCharDataGenerator.java,v
retrieving revision 1.2
retrieving revision 1.2.4.1
diff -u -r1.2 -r1.2.4.1
--- MappedCharDataGenerator.java 2000/03/06 00:33:51 1.2
+++ MappedCharDataGenerator.java 2001/07/10 20:43:34 1.2.4.1
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/MappedCharDataGenerator.java,v
1.2 2000/03/06 00:33:51 mandar Exp $
- * $Revision: 1.2 $
- * $Date: 2000/03/06 00:33:51 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/MappedCharDataGenerator.java,v
1.2.4.1 2001/07/10 20:43:34 larryi Exp $
+ * $Revision: 1.2.4.1 $
+ * $Date: 2001/07/10 20:43:34 $
*
*
*
@@ -93,7 +93,8 @@
sb.append();
break;
case '\r':
- continue;
+ sb.append(\\r);
+ break;
/*
case '\'':
sb.append('\\');
@@ -101,7 +102,7 @@
break;
*/
case '\n':
- sb.append(\\r\\n);
+ sb.append(\\n);
writer.print(sb.toString());
writer.print(\);\n);
sb = new StringBuffer();
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core BaseInterceptor.java
larryi 01/07/10 13:51:10
Modified:src/share/org/apache/tomcat/core BaseInterceptor.java
Log:
Update authorize() method to default to returning DECLINED so it doesn't
authorize by default.
Revision ChangesPath
1.48 +2 -2
jakarta-tomcat/src/share/org/apache/tomcat/core/BaseInterceptor.java
Index: BaseInterceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/BaseInterceptor.java,v
retrieving revision 1.47
retrieving revision 1.48
diff -u -r1.47 -r1.48
--- BaseInterceptor.java 2001/06/28 07:43:00 1.47
+++ BaseInterceptor.java 2001/07/10 20:51:08 1.48
@@ -163,7 +163,7 @@
* The authorize is called by isUserInRole() and by ContextManager
* if the request have security constraints.
*
- * @returns 0 if the module can't take a decision
+ * @returns DECLINED if the module can't make a decision
* 401 If the user is not authorized ( doesn't have
* any of the required roles )
* 200 If the user have the right roles. No further module
@@ -171,7 +171,7 @@
*/
public int authorize(Request request, Response response,
String reqRoles[]) {
- return 0;
+ return DECLINED;
}
/** Called before service method is invoked.
cvs commit: jakarta-tomcat/src/tests/webpages/aaa - New directory
larryi 01/07/10 14:01:06 jakarta-tomcat/src/tests/webpages/aaa - New directory
cvs commit: jakarta-tomcat/src/tests/webpages/aaa/protected - New directory
larryi 01/07/10 14:03:26 jakarta-tomcat/src/tests/webpages/aaa/protected - New directory
cvs commit: jakarta-tomcat/src/tests/webpages/aaa/protected index.jsp
larryi 01/07/10 14:13:24
Modified:src/tests/webpages/WEB-INF test-tomcat.xml web.xml
Added: src/tests/webpages/aaa login.jsp loginerr.jsp
src/tests/webpages/aaa/protected index.jsp
Log:
Add a test that catches my recent breakage of authorization in the patch
for avoiding recursive status errors. Patch for fixing authorization to follow.
Also some minor cleanup.
Revision ChangesPath
1.32 +15 -5 jakarta-tomcat/src/tests/webpages/WEB-INF/test-tomcat.xml
Index: test-tomcat.xml
===
RCS file: /home/cvs/jakarta-tomcat/src/tests/webpages/WEB-INF/test-tomcat.xml,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- test-tomcat.xml 2001/05/23 03:28:13 1.31
+++ test-tomcat.xml 2001/07/10 21:13:02 1.32
@@ -16,7 +16,7 @@
early tests.
--
- property name=revision value=$Revision: 1.31 $ /
+ property name=revision value=$Revision: 1.32 $ /
property name=host value=127.0.0.1 /
property name=port value=8080 /
property name=outputType value=text /
@@ -1113,7 +1113,7 @@
/target
- target name=security_chk
+ target name=security_chk depends=init
gtest description=This URL should return 404 Not Found
request=GET /test/jsp/HelloWorld.jsp. HTTP/1.0
returnCode=${http.protocol} 404
@@ -1210,7 +1210,7 @@
/
/target
- target name=writer
+ target name=writer depends=init
httpClient
commentWriter test, closing writer at end/comment
httpRequest path=/test/servlet/CloseWriter /
@@ -1219,7 +1219,7 @@
goldenMatch file=${gdir}/CloseWriter.txt/
/httpClient
httpClient
- commentWriter test,trying to catch reciclying issues/comment
+ commentWriter test,trying to catch recycling issues/comment
httpRequest path=/test/servlet/CloseWriter /
httpStatusMatch match=200 /
headerMatch name=Content-Type value=text/plain /
@@ -1227,8 +1227,18 @@
/httpClient
/target
+ target name=aaa depends=init
+ httpClient
+ commentTest for required authorization redirection response/comment
+ httpRequest path=/test/aaa/protected/index.jsp /
+ httpStatusMatch match=302 /
+ headerMatch name=Location
value=http://${host}:${port}/test/aaa/login.jsp; /
+ responseMatch match=This document has moved /
+ /httpClient
+ /target
+
!-- All targets --
- target name=client
depends=file,params,writer,dispatch,get,requestMap,post,wrong_request,restricted,jsp,unavailable,headers,security_chk
+ target name=client
depends=file,params,writer,dispatch,get,requestMap,post,wrong_request,restricted,jsp,unavailable,headers,security_chk,aaa
/target
!-- Aux targets --
1.11 +16 -0 jakarta-tomcat/src/tests/webpages/WEB-INF/web.xml
Index: web.xml
===
RCS file: /home/cvs/jakarta-tomcat/src/tests/webpages/WEB-INF/web.xml,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- web.xml 2001/03/11 22:25:46 1.10
+++ web.xml 2001/07/10 21:13:07 1.11
@@ -203,4 +203,20 @@
transport-guaranteeCONFIDENTIAL/transport-guarantee
/user-data-constraint
/security-constraint
+ security-constraint
+ web-resource-collection
+ web-resource-nameAccess-Authentication-Authorization Test
Area/web-resource-name
+ url-pattern/aaa/protected/*/url-pattern
+ /web-resource-collection
+ auth-constraint
+ role-namerole1/role-name
+ /auth-constraint
+ /security-constraint
+ login-config
+ auth-methodFORM/auth-method
+ form-login-config
+ form-login-page/aaa/login.jsp/form-login-page
+ form-error-page/aaa/loginerr.jsp/form-error-page
+ /form-login-config
+ /login-config
/web-app
1.1 jakarta-tomcat/src/tests/webpages/aaa/login.jsp
Index: login.jsp
===
htmlbody
form method=POST action=j_security_check
Username: input type=text name=j_usernamebr
Password: input type=password name=j_passwordbrbr
input type=submit value=login name=j_security_check
/form
/body/html
1.1 jakarta-tomcat/src/tests/webpages/aaa/loginerr.jsp
Index: loginerr.jsp
Re: cvs commit:jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compilerParserController.java
on 7/10/01 1:12 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: %@ include file=XX % says file and is thus relative to the JSP file. jsp:include page=XXX / says page and is thus relative to the JSP page. Try teaching that to a web designer. Bah. JSP sucks. -jon
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session LocalStrings.properties StandardSession.java
remm01/07/10 15:08:30
Modified:catalina/src/share/org/apache/catalina/session
LocalStrings.properties StandardSession.java
Log:
- Specifying a null name will result in a illegal arg exception being thrown.
Bug reported by Kumar Mettu mettu.kumar at redspark.com
Revision ChangesPath
1.8 +1 -0
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/LocalStrings.properties
Index: LocalStrings.properties
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/LocalStrings.properties,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- LocalStrings.properties 2001/04/26 01:40:55 1.7
+++ LocalStrings.properties 2001/07/10 22:08:25 1.8
@@ -42,6 +42,7 @@
standardSession.sessionEvent=Session event listener threw exception
standardSession.setAttribute.ise=setAttribute: Non-serializable attribute
standardSession.setAttribute.ise=setAttribute: Session already invalidated
+standardSession.setAttribute.namenull=setAttribute: name parameter cannot be null
standardSession.sessionCreated=Created Session id = {0}
persistentManager.loading=Loading {0} persisted sessions
persistentManager.unloading=Saving {0} persisted sessions
1.22 +9 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardSession.java
Index: StandardSession.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardSession.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- StandardSession.java 2001/07/10 03:18:57 1.21
+++ StandardSession.java 2001/07/10 22:08:27 1.22
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardSession.java,v
1.21 2001/07/10 03:18:57 jon Exp $
- * $Revision: 1.21 $
- * $Date: 2001/07/10 03:18:57 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardSession.java,v
1.22 2001/07/10 22:08:27 remm Exp $
+ * $Revision: 1.22 $
+ * $Date: 2001/07/10 22:08:27 $
*
*
*
@@ -111,7 +111,7 @@
* @author Craig R. McClanahan
* @author Sean Legassick
* @author a href=mailto:[EMAIL PROTECTED];Jon S. Stevens/a
- * @version $Revision: 1.21 $ $Date: 2001/07/10 03:18:57 $
+ * @version $Revision: 1.22 $ $Date: 2001/07/10 22:08:27 $
*/
class StandardSession
@@ -1021,6 +1021,11 @@
* invalidated session
*/
public void setAttribute(String name, Object value) {
+
+// Name cannot be null
+if (name == null)
+throw new IllegalArgumentException
+(sm.getString(standardSession.setAttribute.namenull));
// Null value is the same as removeAttribute()
if (value == null) {
[DOC] TOC - thoughts
There is a WHACK of info in that TOC. Your copyright is well-deserved =) First off, I think we should have an ultra-quick install guide. If you're like a lot of geeks, you know your stuff. You need to know a quick few steps, a quick 2-3 gotchas, and BAM that's it. I want to make sure the quick-and-dirty impatient install is available to the people who can take advantage of it; admins experienced with other containers, trying Tomcat for the first time perhaps. PI.1.1: I agree with the big picture view of things, but from what's there, it almost looks like you're explaining the parts that I as an admin, would expect to see in the installation documentation. Was there something more to this section than a description of Tomcat's internal layout? PI.1.2: Agree with comments, remove to appendix. There are a million other places on the Internet that introduce these things, and I'm sure they'll have done a better job than most of us care to attempt. PI.2.1: I love pictures! Some nice diagrams in here would go a lllong way. Not sure about the choose OS or install Java sections. I mean, there's catering to the LCD and there's catering to the LCD... I think a lot of PI.2 is overkill, and some unnecessary, dependant upon the implied length of the sections from the TOC I suppose... I mean one or two sentences to downloading JDK, sure, but more than that? Definitely more suited to a book than good enough docs ;) Overall, thanks for organizing this in such detail. It's a really good read! I need to cook dinner and catch Law and Order. I'll reply to the rest later =) - r
Re: Suggestions (was Re: hello everyone (regarding documentation))
Alex Fernández wrote: Hi Hiten! hiten pandya wrote: i am planning to start my own documentation project for Tomcat 3.3 and 4.0. The different thing about this project is that, i am going to port all of the tomcat documentation to XML Docbook format. Not speaking officially, I'm not a committer: if you want to document Tomcat, then go ahead and good luck! Your focused work can do lots for the docs: you will probably end before the committee decides the right format for Tomcat docs :) LLAMF! True that. Just a suggestion: Though i am not very good at docbook but i think i can cope. Once the documentation is complete, I will submit it to the main tomcat development team. Don't wait till everything is ready; send your updates regularly to the dev list, so folks can criticize your work and point possible mistakes. [snip] Am I the only one that initially read that as send your updates regularly so that folks can criticize you and your pointless mistakes? Alex deals some very sage advice here, but when I first hit Reply he was about to get some even higher praise for the funniest pointed sarcasm I had heard in quite some time. ... Uhhh ... I guess you had to be there. In any event, Alex's advice is quite sound, FWIW.
Re: cvscommit:jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compilerParserController.java
on 7/10/01 3:25 PM, Rob S. [EMAIL PROTECTED] wrote: Ha! I've been working with JSP since 1999 and I never caught that! Even more proof! :-) JSP is overly complex and takes *years* to master. :-) -jon
cvs commit: jakarta-tomcat/src/facade22/org/apache/tomcat/facade HttpSessionFacade.java
nacho 01/07/10 16:08:35
Modified:src/facade22/org/apache/tomcat/facade HttpSessionFacade.java
Log:
* setAttribute() was calling valueBound() after storing the
object in the session. The spec calls for the reverse.
* setAttribute() didn't call valueUnbound() for the
object it replaces, if present.
Revision ChangesPath
1.9 +63 -60
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpSessionFacade.java
Index: HttpSessionFacade.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpSessionFacade.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- HttpSessionFacade.java2001/03/09 23:33:59 1.8
+++ HttpSessionFacade.java2001/07/10 23:08:32 1.9
@@ -100,21 +100,21 @@
/** Package-level method - accessible only by core
*/
void setRealSession(ServerSession s) {
- realSession=s;
- realSession.setFacade( this );
+realSession=s;
+realSession.setFacade( this );
}
/** Package-level method - accessible only by core
*/
void recycle() {
- // realSession=null;
+// realSession=null;
}
// public facade
public String getId() {
- checkValid();
- return realSession.getId().toString();
+checkValid();
+return realSession.getId().toString();
}
/**
@@ -125,8 +125,8 @@
* invalidated session
*/
public long getCreationTime() {
- checkValid();
- return realSession.getTimeStamp().getCreationTime();
+checkValid();
+return realSession.getTimeStamp().getCreationTime();
}
/**
@@ -136,12 +136,12 @@
* @deprecated
*/
public HttpSessionContext getSessionContext() {
- return new SessionContextImpl();
+return new SessionContextImpl();
}
public long getLastAccessedTime() {
- checkValid();
- return realSession.getTimeStamp().getLastAccessedTime();
+checkValid();
+return realSession.getTimeStamp().getLastAccessedTime();
}
/**
@@ -151,8 +151,8 @@
* an invalidated session
*/
public void invalidate() {
- checkValid();
- realSession.getTimeStamp().setValid( false );
+checkValid();
+realSession.getTimeStamp().setValid( false );
}
/**
@@ -166,59 +166,62 @@
* invalidated session
*/
public boolean isNew() {
- checkValid();
- return realSession.getTimeStamp().isNew();
+checkValid();
+return realSession.getTimeStamp().isNew();
}
/**
* @deprecated
*/
public void putValue(String name, Object value) {
- setAttribute(name, value);
+setAttribute(name, value);
}
public void setAttribute(String name, Object value) {
- checkValid();
+checkValid();
+Object oldValue;
+// ServerSessionManager ssm=(ServerSessionManager)
+// realSession.getManager();
+// Original code - it's up to session manager to decide
+// what it can handle.
+// if (ssm.isDistributable()
+//!(value instanceof Serializable))
+// throw new IllegalArgumentException
+// (sm.getString(standardSession.setAttribute.iae));
+oldValue=realSession.getAttribute( name) ;
+if (oldValue!=null) {
+removeAttribute(name);
+}
+if (value instanceof HttpSessionBindingListener)
+ ((HttpSessionBindingListener) value).valueBound
+(new HttpSessionBindingEvent( this, name));
+realSession.setAttribute( name, value );
- // ServerSessionManager ssm=(ServerSessionManager)
- // realSession.getManager();
- // Original code - it's up to session manager to decide
- // what it can handle.
- // if (ssm.isDistributable()
- //!(value instanceof Serializable))
- // throw new IllegalArgumentException
- // (sm.getString(standardSession.setAttribute.iae));
-
- realSession.setAttribute( name, value );
- if (value instanceof HttpSessionBindingListener)
- ((HttpSessionBindingListener) value).valueBound
- (new HttpSessionBindingEvent( this, name));
-
}
/**
* @deprecated
*/
public Object getValue(String name) {
- return getAttribute(name);
+return getAttribute(name);
}
public Object getAttribute(String name) {
-
cvs commit: jakarta-tomcat KEYS
nacho 01/07/10 16:13:23 Modified:.KEYS Log: Adding my key Revision ChangesPath 1.4 +27 -0 jakarta-tomcat/KEYS Index: KEYS === RCS file: /home/cvs/jakarta-tomcat/KEYS,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- KEYS 2001/06/22 06:50:26 1.3 +++ KEYS 2001/07/10 23:13:20 1.4 @@ -75,3 +75,30 @@ =6l+I -END PGP PUBLIC KEY BLOCK- +Type bits keyID Date User ID +DSS 1024/1024 0xFEA4C043 2001/6/24 Ignacio J. Ortega [EMAIL PROTECTED] + +-BEGIN PGP PUBLIC KEY BLOCK- +Version: PGPfreeware 7.0.3 for non-commercial use http://www.pgp.com + +mQGiBDs1PSgRBAD8g1RLIdDEk1+XW0DeaOrtzDPRUblHwty9S7a2UfiOEJA8GMZv +GAT7HcEynxt6P4a58k3DceWvRw4kcu5PRF++qufzroWkSHK3V/gaDxva9XavfbS0 +vgQC5In4ZG+iKw1CbGeXzMnA28YIVbQztpKWFhyrD5q86DjrcBTefM2e0wCg/+iA +J0DSHbKfiu9mqe8HzVcuXlsEALSSTdUJPRa80bmr6prsuc2heJLa22ddGHkJ5OXD +pvY9mmY+fDe9wL5bnsbnDvmhwoDAsog/+jjWjJhleF+TR+wzEkmO5fYLv8qZPXet +r6loSaY84XwrcN1ZMvGKfhfZMeAGg/McUeivT2q+3NH2dD5IK5tM960lPvq2kk6f +41miA/4kxh/en3CG/qyfb0E33L6XY5xY+IMTnGX7tKFZuGcXtni04mqnmJAdGcoM +Y8IwLQ1jyy3rJnXYKcJ59ZaIiku5fsOYOMu2MKRr7H6sBhC9wbmk1XfAHNJAaWTK +GItHjCIIjneFZwZttC44PRspMI5bzb2sskSlH1gO7bt7nbDKMLQkSWduYWNpbyBK +LiBPcnRlZ2EgPG5hY2hvQGFwYWNoZS5vcmc+iQBYBBARAgAYBQI7NT0oCAsDCQgH +AgEKAhkBBRsDAAoJEAO7fiv+pMBDCqQAn08IyL3DNeIF6mo4DlE4BVk7rEN4 +AJ43Di7ytG4nj9y5qioBRhfBjkMZRLkBDQQ7NT0tEAQA2MJMI4ekdHE7YH0CEt1N +GwPm6ymI0Qkg4L4bFXtazgZAKH0iJS6+kpQ0W2wqt9/QKEOxb+OQvECChu+wgJXf +wg2P4ZoqdwXvfR8vZiMaJ08+aK1p280qxuhkb82WoTspnGOI0lvwXpi1rMTDT+j7 +AHvugFdwv9XFoTnomDpm/tkAAgIEAL1gLivRvNlYlFbuXEoucD5/48gKQdUsOSL9 +WFTroUCwuvrLUJe9EHcb0aiDNRDX/CMtwmznLtFMUteUQBWjiDij39WnPDISvWvj +tVxg1wthlNsFqd/M2SpvE1b4yI5I0jPAQ/t4LYD3DOQ94xqUvA/5oWb/g54KNUQD +YbEf2RYSiQBMBBgRAgAMBQI7NT0tBRsMAAoJEAO7fiv+pMBDGhEAnRz4KyzY +exuadIvVuO6wHxaKqnBjAJ0Zmsli7ai95+k7BwOpWx3Hv8YWVw== +=GIGG +-END PGP PUBLIC KEY BLOCK-
Re: cvs commit:jakarta-tomcat/src/facade22/org/apache/tomcat/facadeHttpSessionFacade.java
on 7/10/01 4:08 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
public long getLastAccessedTime() {
-checkValid();
-return realSession.getTimeStamp().getLastAccessedTime();
+checkValid();
+return realSession.getTimeStamp().getLastAccessedTime();
}
I thought that Costin wants tabs in the files for Tomcat 3.x.
-jon
cvs commit: jakarta-tomcat-4.0/tester/web/WEB-INF web.xml
craigmcc01/07/10 16:30:16
Modified:tester/src/bin tester.xml
tester/web/WEB-INF web.xml
Added: tester/src/tester/org/apache/tester Lifecycle01.java
Lifecycle02.java
Log:
Add unit tests to prove that servlet lifecycle is handled correctly - i.e.
init() is called exactly once before the service() method is invoked, and
the first call can be either a GET or a POST.
These tests indicate that the error reported by Bugzilla #206 does *not*
occur with current Tomcat 4.0 code.
Revision ChangesPath
1.53 +24 -1 jakarta-tomcat-4.0/tester/src/bin/tester.xml
Index: tester.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/tester/src/bin/tester.xml,v
retrieving revision 1.52
retrieving revision 1.53
diff -u -r1.52 -r1.53
--- tester.xml2001/06/25 15:40:47 1.52
+++ tester.xml2001/07/10 23:30:10 1.53
@@ -15,7 +15,7 @@
taskdef name=tester classname=org.apache.tester.TestClient/
- target name=all
depends=ROOT,Authentication,CaseSensitive,Decoding,ErrorPage,FilterRequest,FilterResponse,Jndi,RequestDispatcher,Resources,ServletContext,ServletRequest,ServletResponse,HttpSession,XercesTest,SSITest,CGITest/
+ target name=all
depends=ROOT,Authentication,CaseSensitive,Decoding,ErrorPage,FilterRequest,FilterResponse,Jndi,Lifecycle,RequestDispatcher,Resources,ServletContext,ServletRequest,ServletResponse,HttpSession,XercesTest,SSITest,CGITest/
target name=ROOT
@@ -493,6 +493,29 @@
tester host=${host} port=${port} protocol=${protocol}
request=${context.path}/WrappedJndi02 debug=${debug}
outContent=Jndi02 PASSED/
+
+ /target
+
+
+ target name=Lifecycle
+
+!-- == Lifecycle Management == --
+
+tester host=${host} port=${port} protocol=${protocol}
+ request=${context.path}/Lifecycle01
+ outContent=Lifecycle01 PASSED debug=${debug}/
+
+tester host=${host} port=${port} protocol=${protocol}
+ request=${context.path}/WrappedLifecycle01
+ outContent=Lifecycle01 PASSED debug=${debug}/
+
+tester host=${host} port=${port} protocol=${protocol}
+ request=${context.path}/Lifecycle02 method=POST
+ outContent=Lifecycle02 PASSED debug=${debug}/
+
+tester host=${host} port=${port} protocol=${protocol}
+ request=${context.path}/WrappedLifecycle02 method=POST
+ outContent=Lifecycle02 PASSED debug=${debug}/
/target
1.1
jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/Lifecycle01.java
Index: Lifecycle01.java
===
/* = *
* *
* The Apache Software License, Version 1.1 *
* *
* Copyright (c) 1999, 2000, 2001 The Apache Software Foundation. *
* All rights reserved.*
* *
* = *
* *
* Redistribution and use in source and binary forms, with or without modi- *
* fication, are permitted provided that the following conditions are met: *
* *
* 1. Redistributions of source code must retain the above copyright notice *
*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
RE: Possible bug in isapi_redirector.dll
Hi Henry I agree, i think the bug is in IIS. We havent been able to find anything about this bug on the microsoft site. Also we havent reported it. But we think therese buckleys chance of gettting microsoft to fix it. They'll probably say its fixed in IIS 5.0. We have modified the isapi_redirector.dll code for our own purposes. I guess its up to you guys about how you want to approach the situatation. Cheers Sam -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 10, 2001 5:55 PM To: [EMAIL PROTECTED] Subject: RE: Possible bug in isapi_redirector.dll Hi Sam, -Original Message- From: sam [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 10, 2001 9:31 AM To: [EMAIL PROTECTED] Subject: Possible bug in isapi_redirector.dll Hello there everybody, We think we may have found a bug, possibly in IIS, which affects isapi_redirect.dll. We were wondering if anyone else has seen this. Perhaps this is a bug for MS, but it seems to affect tomcat so maybe someone here can shed some light. Our software versions are: IIS 4.0 jk_isapi_plugin.c revision 1.5.2.2 tomcat 3.2.2 Windows NT 4.0 sp6 The relevant code in is the file jk_isapi_plugin.c, line 960 in the function: static int get_server_value(LPEXTENSION_CONTROL_BLOCK lpEcb, char *name, char *buf, DWORD bufsz, char *def_val) When the function lpEcb-GetServerVariable(...) on line 965 is called to retrieve CERT_SERIALNUMBER, the value returned in bufsz is wrong. Our certificate serial number is 48 chars long, but the value contained in bufsz is 47, where it should be 49 (the length of the serial number + 1 for string terminator). After the call to GetServerVariable() a '\0' is inserted into buf at bufsz-1. This causes our certificate serial number to be truncated by 2 bytes. The microsoft doco says that the value returned should be the value length + 1 for the string terminator. This is from: http://msdn.microsoft.com/library/en-us/iisref/html/psdk/asp/is re8376.asp?fr ame=true The problem is clearly in IIS. It return 47 instead of 49 Could you see if the bug is reported in IIS
Re: cvs commit:jakarta-tomcat/src/facade22/org/apache/tomcat/facadeHttpSessionFacade.java
on 7/10/01 4:29 PM, Ignacio J. Ortega [EMAIL PROTECTED] wrote: Hola Jon: Who will cry for the lost of tabs? me not.. perhaps you? :) Lazy Consensus 3 days for a -1.. if anybody complaints ( more ) i will rollback and reapply my patch.. Saludos , Ignacio J. Ortega I would say that following coding conventions for a project is extremely important. It increases the ability to read the code and given that this is an OSS project, that is very important. So, here is my -1. Personally, I hate tabs, but your friend Costin loves em. Go figure. -jon
Re: [DOC] TOC - thoughts
Rob S. wrote: [snip] First off, I think we should have an ultra-quick install guide. If you're like a lot of geeks, you know your stuff. You need to know a quick few steps, a quick 2-3 gotchas, and BAM that's it. I want to make sure the quick-and-dirty impatient install is available to the people who can take advantage of it; admins experienced with other containers, trying Tomcat for the first time perhaps. +1 PI.2.1: I love pictures! Some nice diagrams in here would go a lllong way. Not sure about the choose OS or install Java sections. I mean, there's catering to the LCD and there's catering to the LCD... I haven't yet had a chance to look over the TOC (planning on doing it tonight), but one of the docs I have lying around is a step-by-step on installing java on Linux *specifically* in preparation for a Tomcat build/install. Granted, the README file hits the important stuff, like what needs to be in the CLASSPATH, etc. I was actually thinking of morphing it into a more general (and quick) guide to preping your OS for a Tomcat build/install (I have some Windoze notes lying around as well). I could very quickly touch on Java installation, including a few Linux-specific tips above and beyond the rather obvious actual install, cover the environment varibles that need to be defined for a build, reiterate the jakarta directory structure that needs to be in place, etc. Basically, everything up to the point of the actual build. Again, I haven't yet looked over the TOC, and maybe this doesn't fit that scheme, or is not at all what is being discussed in PI.2.1. So don't flame me too badly for not RTFM, just a quick thought I had when reading Rob's reply. I think a lot of PI.2 is overkill, and some unnecessary, dependant upon the implied length of the sections from the TOC I suppose... I mean one or two sentences to downloading JDK, sure, but more than that? Definitely more suited to a book than good enough docs ;) Well, my thoughts on the aforementioned doc I was planning are to provide a list of the available JDKs for each platform, what else one needs to download for certain optional functionality (SSL, etc.), where to get each of them, and any relevant comments on software selection. Mainly just the huge stuff, like the infamous Sun 1.3.1 JDK for Linux completely broken under the new gcc threading libraries. (That one really pissed me off.) This might fall under the category of too much information as Rob is stating, but my feeling is that it is easy enough to skip over entire sections (assuming they're laid out logically) in a Preping your OS for Tomcat doc, and those users who are planning on building out a new box (or reformatting an existing box) specifically for a web server will appreciate such heads-up info. Getting Tomcat up and running on a barebones OS install is pretty rare for us developers, but it happens quite frequently in the corporate world. The bigger the master Tomcat documentation library, from the essentials to the sublimely tangential steps along the way, the more comfortable corporations will feel about choosing Tomcat over a proprietary solution. As long as someone is willing to write such things, which in this case I am, why not just throw it in the mix for the few people who might benefit from it? Of course, I completely agree that there also needs to be some short-and-sweet versions of how to do install-type things, so maybe an abbreviated version of my Preping doc would also be in order. Just a thought ... - Christopher
cvs commit: jakarta-tomcat/src/facade22/org/apache/tomcat/facade HttpSessionFacade.java
nacho 01/07/10 16:56:36
Modified:src/facade22/org/apache/tomcat/facade HttpSessionFacade.java
Log:
Readded tabs, to maintain actual coding style..
Revision ChangesPath
1.10 +45 -45
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpSessionFacade.java
Index: HttpSessionFacade.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpSessionFacade.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- HttpSessionFacade.java2001/07/10 23:08:32 1.9
+++ HttpSessionFacade.java2001/07/10 23:56:33 1.10
@@ -100,21 +100,21 @@
/** Package-level method - accessible only by core
*/
void setRealSession(ServerSession s) {
-realSession=s;
-realSession.setFacade( this );
+ realSession=s;
+ realSession.setFacade( this );
}
/** Package-level method - accessible only by core
*/
void recycle() {
-// realSession=null;
+ // realSession=null;
}
// public facade
public String getId() {
-checkValid();
-return realSession.getId().toString();
+ checkValid();
+ return realSession.getId().toString();
}
/**
@@ -125,8 +125,8 @@
* invalidated session
*/
public long getCreationTime() {
-checkValid();
-return realSession.getTimeStamp().getCreationTime();
+ checkValid();
+ return realSession.getTimeStamp().getCreationTime();
}
/**
@@ -136,12 +136,12 @@
* @deprecated
*/
public HttpSessionContext getSessionContext() {
-return new SessionContextImpl();
+ return new SessionContextImpl();
}
public long getLastAccessedTime() {
-checkValid();
-return realSession.getTimeStamp().getLastAccessedTime();
+ checkValid();
+ return realSession.getTimeStamp().getLastAccessedTime();
}
/**
@@ -151,8 +151,8 @@
* an invalidated session
*/
public void invalidate() {
-checkValid();
-realSession.getTimeStamp().setValid( false );
+ checkValid();
+ realSession.getTimeStamp().setValid( false );
}
/**
@@ -166,15 +166,15 @@
* invalidated session
*/
public boolean isNew() {
-checkValid();
-return realSession.getTimeStamp().isNew();
+ checkValid();
+ return realSession.getTimeStamp().isNew();
}
/**
* @deprecated
*/
public void putValue(String name, Object value) {
-setAttribute(name, value);
+ setAttribute(name, value);
}
public void setAttribute(String name, Object value) {
@@ -203,25 +203,25 @@
* @deprecated
*/
public Object getValue(String name) {
-return getAttribute(name);
+ return getAttribute(name);
}
public Object getAttribute(String name) {
-checkValid();
-return realSession.getAttribute(name);
+ checkValid();
+ return realSession.getAttribute(name);
}
-
+
/**
* @deprecated
*/
public String[] getValueNames() {
-checkValid();
-
-Enumeration attrs = getAttributeNames();
-String names[] = new String[realSession.getAttributeCount()];
-for (int i = 0; i names.length; i++)
-names[i] = (String)attrs.nextElement();
-return names;
+ checkValid();
+
+ Enumeration attrs = getAttributeNames();
+ String names[] = new String[realSession.getAttributeCount()];
+ for (int i = 0; i names.length; i++)
+ names[i] = (String)attrs.nextElement();
+ return names;
}
/**
@@ -232,15 +232,15 @@
* invalidated session
*/
public Enumeration getAttributeNames() {
-checkValid();
-return realSession.getAttributeNames();
+ checkValid();
+ return realSession.getAttributeNames();
}
/**
* @deprecated
*/
public void removeValue(String name) {
-removeAttribute(name);
+ removeAttribute(name);
}
/**
@@ -258,33 +258,33 @@
* invalidated session
*/
public void removeAttribute(String name) {
-checkValid();
-Object object=realSession.getAttribute( name );
-realSession.removeAttribute(name);
-if (object instanceof HttpSessionBindingListener) {
-((HttpSessionBindingListener) object).valueUnbound
-(new HttpSessionBindingEvent( this, name));
-}
+ checkValid();
+ Object
StandardContext.getNamingContextName returns non unique name
StandardContext.getNamingContextName() returns name of the form /host/context no matter which engine the context is part of. This will create a problem for running multiple services serving the same webapp. It should be returning the name of the form /engine/host/context Let me know if this is a bug or am I missing something? -- Cheers!
Re: [DOC] TOC - thoughts
First off, I think we should have an ultra-quick install guide. If you're like a lot of geeks, you know your stuff. You need to know a quick few steps, a quick 2-3 gotchas, and BAM that's it. I want to make sure the quick-and-dirty impatient install is available to the people who can take advantage of it; admins experienced with other containers, trying Tomcat for the first time perhaps. README file of the binary distribution of tomcat already contains the ultra-quick install guide. If not, just make sure the README file have it, right? Punky
Re: please read -- need to specify current working directory
On Sun, 8 Jul 2001, Donald Ball wrote: On Sun, 8 Jul 2001, Victor Wynnytsky wrote: [ WHY I NEED THIS ] It is very common for an XSL page to include another XSL page. An XSL page called orderDetail.xsl might begin like this... xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform; version=1.0 xsl:import href=nav.xsl/ xsl:import href=grid.xsl/ xsl:template match=/ ... The focus of my problem is on the xsl:import tag. I'm using a *web* path there, and I'm sure everyone using Xalan is using an *file* path. The above sample XSL shows orderDetail.xsl trying to refer to nav.xsl in the same folder (ie: web path). you should check out the javax.xml.transform.URIResolver interface. you can have trax transformers call one of your methods to resolve uris. You should really do as Donald suggests. One of the flaws to your current approach is that user.dir is global to all webapps, so as soon as you have your apps processing multiple requests at the same time, you're going to run into race conditions. - donald Craig McClanahan
RE: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS: [TomcatDocumentation Redactors To Hire]
On Tue, 10 Jul 2001, GOMEZ Henri wrote: Craog I have a feeling that whatever is the same will be a lot of piecemeal here and there, excluding of course, web-app documentation. So far yourself, Pier, and Henri are the only three TC developers to post their position on that (re: inter-version relevancy). Pier and I also working together on a separate sub-project, J-T-C. A starting user will first install the servlet-engine and then will try to figure how to link it with its web-server. Should we ask him to switch from one documentation to another ? The user doesn't care what repository the docs came from -- they only care that the hyperlinks work correctly :-). In other words, the packaging of the docs in the binary distribution need not have anything to do with the source file organization. I thought of another reason for my preference in the shower this morning :-). Consider that I might make a code change that also requires a change to the corresponding docs. If the docs are in the same repository, that can easily be done on the same commit (and it becomes obvious to everyone when a developer makes a change that breaks the documentation, but fails to update it :-). Having a separate docs repository means I need to do two independent check-ins -- it's easy to forget one, and there is no obvious link between them to remind you (for example) to back out the docs change if you back out the code change. If you commit a code change in TC 4.0, you'll only have one doc commit in J-T-D. What's the duplicate effort here ? Assume a change to class Abc.java and a corresponding change to Abc-doc.html. If they are in the same CVS repository, a single commit does both. Otherwise, you need to remember to do two individual commits (one on each repository). Likewise, when you decide later to back out this change (because it was incorrect or something), you have to remember that there was also a commit on the docs repository. In the same repository, the commit message contains both sets of changes, so you know that you have to back them both out. Craig McClanahan
Re: [DOC] Table of Contents
3) How about putting all the installation and configuration of Tomcat standalone first, and then followed by some chapters (advanced topics) about Running Tomcat behind web servers? It's already organized that way. See the first paragraph of the editorial notes: I think there should be a chapter or series of chapters on installing Tomcat standalone, that covers *everything* or almost everything start-to-finish. Then we also need separate chapters for installing behind each Web server. Then come chapters on administration and advanced configuration issues. I have a feeling you may have missed the attachment. See the post I just made for the latest one (in much detail). Alex, What I mean is to swap Part II with Part III like below: I. Standalone Installation Guide II. Deploying and Configuring, or Tomcat Administrator's Guide III. Installation Behind a Web Server Guide IV. Performance Tuning Guide V. Tomcat Developer's Guide (writing code for Tomcat itself) I treat Installation Behind a Web Server Guide as advanced topics. For general tomcat users, they should be more interested in configuring Tomcat than in making it running behind web server. Punky
Re: Poor Tomcat 3.2.2 performance on Win32 with class reloadingenabled
On Mon, 9 Jul 2001, Stuart Roebuck wrote: Remy Craig, Thanks for your responses... On Saturday, July 7, 2001, at 07:28 am, Remy Maucherat wrote: The cases you've described above all happen only once (at startup time). Assuming that we could safely optimize these cases, would it really make a significant difference? It wouldn't. While you were away, I did some profiling of the startup (since people complained), and it turns out that the time is mostly spent in : - Crimson, because it's used in validating mode - introspecting and doing various things in the XML mapper (no surprise) The examples I gave were just some examples of getCanonicalPath that I located in the source - I acknowledge that I had been unable to identify which ones were taking up significant resources, though all the ones I listed were at least in loops. I have had problems profiling Tomcat and Cocoon, but in those threads I have been able to profile under Mac OS X, getCanonicalPath (i.e. native UnixFileSystem.canonicalize) calls whilst running Tomcat 4 and Cocoon II constitute a *very* significant proportion of runtime. I know that others have noted that this is also true under Windows, so this does not appear to be specific to Mac OS X, though the 'cost' of getCanonicalPath under Mac OS X may be proportionally higher than on other operating systems due to certain underlying filesystem issues. One commonality, IIRC - both Windows and MacOS are case insensitive. The servlet spec (at least in 2.3) mandates case sensitive comparisons for web app resources. The only way we've discovered to do that is to rely on getCanonicalPath(). To influence the performance of Cocoon, we'd want to look at the Resources implementation. It's been worked on, but I would certainly not say we've really optimized it yet. And reducing the number of calls to getCanonicalPath() sounds like a good strategy -- as long as it can be done safely. getCanonicalPath is called only under Windows (for case sensitivity checking). More profiling showed that the resources were fast enough. Remy Remy - could you explain what you mean here. getCanonicalPath calls within Tomcat are not, as far as I can see, conditional upon runtime Operating System. Both Windows filing systems and HFS / HFS+ (Under Mac OS / Mac OS X) are case insensitive, the latter being BSD Unix derivative. I would have thought that calls to getCanonicalPath would be required, not just for case sensitivity reasons, but also to deal with the assortment of equivalent path descriptors, e.g. the use of .., ., ~user and the effects of filesystem softlinks, hardlinks, aliases, shortcuts, or whathaveyou. If getCanonicalPath is being used as a case insensitive string comparitor, then I am sure there are less costly alternatives. When you say that profiling indicated that resources were fast enough, do you mean that getCanonicalPath is not a significant bottleneck on any platform? I'm not doubting this with respect to Tomcat 4, as the main issues I have run across may be largely Cocoon II specific, unfortunately currently profiling problems mean that I'm going round the houses a little to pin this one down. However, as I indicated in my earlier email, I have tested substituting th java.io.File.getCanonicalPath() method with a caching version and found a very visible speedup which confirms that getCanonicalPath is an issue somewhere in this Tomcat 4 / Cocoon II combination. Stuart. - Stuart Roebuck [EMAIL PROTECTED] Lead Developer Java, XML, MacOS X, XP, etc. ADOLOS http://www.adolos.com/ Craig
Re: [DOC] Vote on oustanding doc issues?
On Mon, 9 Jul 2001, Alex Chaffee wrote: Bundle the 3.2.x docs with 3.2.x and only have the 3.3 docs online (latest Tomcat release). If you want the 3.2.x docs, get them with the binary or whatever. I certainly don't think we should keep old versions of documentation updated. I mean, why would updated 3.0 or 3.1 docs be useful? Unless and until there's a 3.3 or 4.0 final release, *3.2* is the latest Tomcat release, and deserves to be documented on the web site. Fortunately, there's a real easy way to handle this -- it's called subdirectories :-). There's no reason to banish the current Tomcat released version, or any other version that is being actively developed. And it's quite easy to arrange the user interface so that it's obvious which version you are looking at (for example, including Tomcat X.Y in the header or footer of the pages about that version). Craig
Re: '_' - 0x5f and Jasper
On Sat, 7 Jul 2001, Keith Wannamaker wrote: Is there a known problem with jsp filenames containing '_'? The Jasper in jakarta-tomcat head compiles 'foo_bar.jsp' to 'foo_0005fbar.jsp' for me. Clearly there is some escaping gone awry, but surely I'm not the first to encounter this? I'm digging into it now... Keith What problem does it cause you that the escaping is done? The application should not care what the generated Java source code filenames are. Craig
Re: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS:[TomcatDocumentation Redactors To Hire]
On Mon, 9 Jul 2001, Jon Stevens wrote: on 7/7/01 9:33 AM, Craig R. McClanahan [EMAIL PROTECTED] wrote: FWIW, I'm fine with Anakia, XSLT, Cocoon, Stylebook, Docbook, or whatever ... but IF AND ONLY IF the tags for use by the document authors are well documented, and the page generation procedure is amenable to Ant scripting (not a difficult problem in most cases). Jakarta-Site tags are now documented. http://jakarta.apache.org/site/jakarta-site-tags.html Cool. That's exactly what I was looking for. Also, please quit grouping Anakia into Anakia tags need to be documented. It is the Jakarta-Site2 project's tags which need to be documented (and have been). Anakia itself doesn't give a shit what tags you use. :-) That's correct. It's also correct of XSLT :-). -jon Craig
Re: Copyright issues (was Re: DOC: Table of Contents)
For Apache projects, documentation is licensed under the same license as the code (i.e. documentation is software). If you check it in to an Apache repository, it needs to have the Apache license (including the Apache copyright on it). Of course, that also gives you the right to use the docs under the same terms as you can use the software. Note that discussion of GPL licensing for docs isn't really relevant to Tomcat documentation. Craig On Mon, 9 Jul 2001, Alex Fernández wrote: Hi Alex! Alex Chaffee wrote: A note on copyright: I'm claiming copyright for this document, since I may use parts of it to write articles or books, and I haven't done the research on what it means to post text (as opposed to code) into an Apache project. I'd contribute it explicitly as open source if I were sure I'd keep my rights to use it too. If anyone can enlighten me on this topic, please respond with a separate subject line (like Copyrights) so we can keep discussions of copyright separate from discussions of the table of contents itself. The copyright will not prevent other Apache contributors from using or editing it or adding it to the code base -- that is, I want to preserve *my* right to use it in a non-Apache context, but also to grant Apache the right to use it too. If that's even possible. I'm confused. On www.gnu.org you can read the following: --- Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001 Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. Updated: $Date: 2001/06/29 17:42:09 $ $Author: rms $ --- For all I know, (c) in software is not essentially different from (c) issues in text. Of course, the concept has been borrowed from there, otherwise we would use patents. In fact, you can copyleft a book, or BSD-like-license an essay. But I don't know much anyway. Perhaps the following link would be useful: http://www.gnu.org/philosophy/nonsoftware-copyleft.html Un saludo, Alex.
Re: Table of Contents
2) How about moving Developing Interceptors, Valves and Connectors, and Using Tomcat Utility Classes to a seperate Developer Guide? They are only useful for real hackers. Don't forget what make Apache HTTP server so successfull. The number of modules built for Apache 1.2/1.3 APIs. If we don't comments and explain how to use and extend Tomcat, we'll loose many contributions and indirects users. Henri, Agree. And we need to make the developer guide more richer in content. But before that, we should make a good user guide first in order to make tomcat more popular. Once we have a large user base, we will have a stronger support for extending tomcat. Punky P.S. What hacker I mean is: The one who read the source code and make change to it so that the whole system get benefit from it. So you are hacker. (but me not yet). The guy who break the system is cracker, or black hacker to be specific.
Re: Probably a simple problem with an equally simple solution...
On Mon, 9 Jul 2001, Kedar Hirve wrote: I was trying to develop my own valve to plug into Catalina, but running into some problems. I wrote up a little class that implements Valve and has empty code for getInfo() and invoke(). I put it in its own package called valvetest, compiled it just fine, put that folder with the class in it in Catalina's startup classpath, and added a valve element to my server.xml. Catalina could find the class when it started, but would give me an IllegalArgumentException - argument type mismatch for the valve. Finally I decided to stick the classes into catalina.jar, and it worked. The odd thing here is that before I jarred it, Catalina found the class just fine, and even _ran its constructor_. Though I have one solution for this now (jarring it into catalina.jar), I'm not terribly satisfied with that. I wanted to know if there's a more convenient way of adding my custom components without modifying catalina.jar. Thanks, in advance. -KSH You should put Valve classes in one of the following two places: - Unpacked under $CATALINA_HOME/server/classes - In a JAR file under $CATALINA_HOME/server/lib The startup processing automatically adds these repositories to the correct class loader, so no mucking around with CLASSPATH is required (or allowed). Craig
RE: My small, simple problem continued... (null container for my valve)
On Tue, 10 Jul 2001, Kedar Hirve wrote: All right, I think I figured it out, and it seems a little strange. I was checking to see what the container for my valve was, in the _constructor_...the constructor is getting called before any of the heirarchy tree is built, it seems. Does Catalina load up components and run constructors in-order, rather than pre-order? For the record, Catalina assumes that all components can be instantiated dynamically with newInstance(); then initialized by having the appropriate setXxxx methods called; and finally (if it implements Lifecycle) then start() will be called. Therefore, testing for stuff in the constructor is not going to work. One odd question, though...when IS the invoke method of a valve called? It is called once per request. If you nest it inside a Context, as your example indicates, then every request for that webapp will flow through your Valve, but no request for any other webapp. -KSH Craig -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Monday, July 09, 2001 5:57 PM To: [EMAIL PROTECTED] Subject: Re: My small, simple problem continued... (null container for my valve) Oh, WOW. It did work, and I didn't even have to modify Catalina's startup classpath. I had tried putting the class under common\lib and server\lib, but I didn't know that common\classes would work. But now I've got another problem... In the lib folders, you can only put jars. Un-jarred classes should be in the classes folders. That's mentioned in the CL docs. The best place to put your valve here is in server/classes/ Again, I have this barebones valve class I wrote, and I've gotten it to load up without exception in Catalina. Now, oddly enough, I find that my valve has a null container, even though its nested in a context in my server.xml: Context className=org.apache.catalina.core.StandardContext path=/ debug=0 docBase=/ reloadable=true Logger className=org.apache.catalina.logger.FileLogger verbosity=1 directory=/logs/kedlog prefix=valvetest timestamp=true / Valve className=org.apache.catalina.valvetest.KedValve / /Context Is there some initialization I need to do, or am I forgetting some tags in my server.xml? Does your valve extend ValveBase or implement Contained ? Remy
Re: [DOC]: Vote on oustanding doc issues?
On Tue, 10 Jul 2001, Alex Chaffee wrote: Rob S. wrote: The tough thing about separating the docs is that the server.xml config stuff is spread out among multiple files. I wonder how difficult it would be to maintain an index, or even if it's necessary. I don't think it's a big deal. I forgot to list the appendices, but one of them will be a technical doc describing server.xml tag by tag. Whoever writes this should put links in to the relevant parts of the TOC (which will in turn contain links to the relevant documents). For Tomcat 4 at least, you'll find that the tag-by-tag docs on server.xml is about 90% done -- the remaining work is to document the few remaining undocumented elements, then convert the stuff from HTML to XML. Having a file per major element seemed to be a convenient way to organize it, but I'm certainly open to any reasonable layout. See directory catalina/docs/config/ in the source repository -- or just follow the online links if you're running Tomcat. These docs were designed to be reference material, so they fit the concept of an Appendix (as described above) quite well. What's also important, of course, is the *why* I would use a particular element, and the *how* to solve some standard problems like I want to use a single JDBCRealm for all the webapps on this virtual host or how do I set up user home directory based web apps?. Craig
Re: t4 - status check
On Mon, 9 Jul 2001, Jon Stevens wrote: What is the status of T4? I haven't seen a huge amount of commits from Craig and Remy recently and it seems like the whole adaptor stuff will never get finished cause it seems like a big political, testing and configuration mess. As usual, I'm focused on the container. There seems to be progress made on the connectors as well but (just getting back from vacation) I'm not up to date on the details. I would like to see Apache+Tomcat pass all the tester and Watchdog tests, the same way that Tomcat standalone does. Pier et. al., where do we stand on that? I'm not asking for a timeline, just a status report. I'd like to see a concerted effort to clean up the outstanding Bugzilla reports and then cut a beta 6 release within the next couple of weeks. This will allow us to catch up on all the recent bug fixes and enhancements, and have a release that closely corresponds to what will be included in J2EE 1.3. At the moment, there are 25 outstanding Tomcat 4 bug reports. I think a bunch of them have already been fixed, so I would like the folks focusing on those areas of the code to please update Bugzilla to reflect that -- so we'll be able to clearly identify outstanding issues, and get to work on them. If anyone has issues that are not reflected in Bugzilla (perhaps you've reported them in email), *please* submit a bug report. That way, we can track it for posterity, and not have to wade back through the mail archives to find them. -jon Craig PS: I know you didn't ask for a timeline, but I'd like to float a concept and see how the other developers feel about it: The Servlet 2.3 and JSP 1.2 specs will go final (along with the rest of the J2EE specs) sometime in the pretty near future, and I'd like to release Tomcat 4.0 final on the day that the specs go final. Does that sound like a worthwhile goal?
Re: [t4] StandardSession.readObject()
On Mon, 9 Jul 2001, Jon Stevens wrote:
Shouldn't it call setAttribute(name, value) instead of:
synchronized (attributes) {
attributes.put(name, value);
}
?
If it did, the session event listeners and HttpSessionBindingListeners
will get called more than once for the same attribute -- once when you
originally added it, and once for each time you reload the application.
That doesn't seem like the right thing to do, since (as far as the app is
concerned), persisting and reloading should be transparent.
-jon
Craig
Re: [TC322 diff] appending to logfiles
On Tue, 10 Jul 2001, Marcus Crafter wrote: Hi All, Hope all is well. I know TC322 is now in maintainence mode, but FWIW, here's a patch that allows you to specify append=boolean in the Logger definitions of the server.xml. This allows you to configure appending to log files in the server.xml. Is such functionality already in TC33 or T4 ? In Tomcat 4, log files are automatically opened in append mode. They also roll over automatically on the first logged message after midnight. Cheers, Marcus Craig -- . ,,$, Marcus Crafter ;$' ':Computer Systems Engineer $: : Open Software Associates GmbH $ o_)$$$: 82-84 Mainzer Landstrasse ;$,_/\ :' 60327 Frankfurt Germany ' /( \_' Email : [EMAIL PROTECTED] .Business Hours : +49 69 9757 200 :
signoff tomcat-dev
signoff tomcat-dev begin:vcard n:Mistri;Vaskar tel;cell:91-98301-45597 tel;fax:+91.33.337.6290 tel;work:+91.33.334.0467 x-mozilla-html:TRUE org:Vaskar Technology Corporation;Software Development version:2.1 email;internet:[EMAIL PROTECTED] title:CEO adr;quoted-printable:;;BC 37 Suite No. 1=0D=0ASalt Lake City;Calcutta;;700064;India fn:Vaskar Mistri end:vcard
RE: '_' - 0x5f and Jasper
Our build process precompiles jsps using jasper then javac from make. make expects foo_bar.jsp to be compiled to foo_bar.java in order to invoke javac on the correct file. When jasper cooks up foo_0005fbar.java, make is confused. I built a hacked jasper after I changed the mangler to not mangle '_'. Keith | -Original Message- | From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] | Sent: Tuesday, July 10, 2001 10:19 PM | To: [EMAIL PROTECTED] | Subject: Re: '_' - 0x5f and Jasper | | | On Sat, 7 Jul 2001, Keith Wannamaker wrote: | | Is there a known problem with jsp filenames containing '_'? | The Jasper in jakarta-tomcat head compiles 'foo_bar.jsp' to | 'foo_0005fbar.jsp' for me. Clearly there is some escaping | gone awry, but surely I'm not the first to encounter this? | I'm digging into it now... | Keith | | | What problem does it cause you that the escaping is done? The application | should not care what the generated Java source code filenames are. | | Craig | |
Re: t4 - status check
on 7/10/01 8:04 PM, Craig R. McClanahan [EMAIL PROTECTED] wrote: PS: I know you didn't ask for a timeline, but I'd like to float a concept and see how the other developers feel about it: The Servlet 2.3 and JSP 1.2 specs will go final (along with the rest of the J2EE specs) sometime in the pretty near future, and I'd like to release Tomcat 4.0 final on the day that the specs go final. Does that sound like a worthwhile goal? It is a good goal, however, it must not be the deciding factor. In other words, I'm just stating that releasing before the specs go final *is* possible. -jon
Jasper and parsed tree
I'm new to Tomcat/Jasper. I have a question regarding Jasper: Does Jasper parse a JSP into a DOM-like objects. In other words, does Jasper create in-memory parsed tree of the the JSP file? I notice from Tomcat 4.0's documentation that there's some plan to upgrade Jasper. I'm wondering how that's going and whether the upgrade does anything related to the above area I mentioned. Thanks in advance. -- John Yu Scioworks Technologies e: [EMAIL PROTECTED]w: +(65) 873 5989 w: http://www.scioworks.com m: +(65) 9782 9610
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core ContextManager.java
larryi 01/07/10 22:24:15
Modified:src/share/org/apache/tomcat/core Tag: tomcat_32
ContextManager.java
Log:
Prior patch to fix recursive status handling went too far and broke
authorization which makes a recursive call to the status handling.
Modify to report a recursive loop only if recursion occurs with the same
status code.
Suggested by: Ignacio J. Ortega
Revision ChangesPath
No revision
No revision
1.100.2.25 +5 -3
jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java
Index: ContextManager.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java,v
retrieving revision 1.100.2.24
retrieving revision 1.100.2.25
diff -u -r1.100.2.24 -r1.100.2.25
--- ContextManager.java 2001/07/06 18:40:05 1.100.2.24
+++ ContextManager.java 2001/07/11 05:24:14 1.100.2.25
@@ -1047,7 +1047,7 @@
if( debug0 )
ctx.log( Handler + errorServlet + + errorPath);
-if ( statusLoop( ctx, req ) ){
+if ( statusLoop( ctx, req, code ) ){
log( Error loop for + req + error code + code);
return;
}
@@ -1206,8 +1206,10 @@
/** Handle the case of status handler generating an error
*/
-private boolean statusLoop( Context ctx, Request req ) {
-if ( req.getAttribute(javax.servlet.error.status_code) != null ) {
+private boolean statusLoop( Context ctx, Request req, int newCode ) {
+Integer lastCode =
(Integer)req.getAttribute(javax.servlet.error.status_code);
+// If status code repeated, assume recursive loop
+if ( lastCode != null lastCode.intValue() == newCode) {
if( ctx.getDebug() 0 )
ctx.log( Error: nested error inside status servlet +
req.getAttribute(javax.servlet.error.status_code));
