RE: cvs commit: jakarta-tomcat-4.0 RELEASE-PLAN-4.0.txt
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] On Wed, 12 Sep 2001, jean-frederic clere wrote: Hi, How was the issue with sun.tools.javac.Main solved? It is going to be deferred to a future release. Here's the reasoning: * The Merlin (i.e. JDK 1.4) folks originally planned to simply remove the old compiler entry point. But they have changed plans, and now it is merely deprecated. The old compiler *will* work in the 1.4 final release, so the time pressure is off. * The new entry point can indeed be programmed to (like Ant does, for example), but it has a crippling disadvantage for a servlet container - it only writes error messages to System.out, so you have to synchronize and do at most one compile at a time. This is not a good thing, and I'd rather see us take some time to look at alternative approaches. Nice of them - esp considering that they added a log capability into the base distribution... Cheers Jean-frederic Craig J. === Information in this email and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other commitment through the use of this email. Experian Limited (registration number 653331). Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF
RE: [ANNOUNCE] Tomcat 4.0 Release Candidate 1 Available
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] I *finally* got to these suggested patches, and have commited changes to catalina.sh, digest.sh, and jasper.sh to implement Cygwin support consistently and (hopefully) correctly. Could you please try all of these scripts with tonight's nightly build (20010912) to make sure that I didn't mess anything up? catalina.sh works like a charm. jasper.sh I have a small glitch in the classpath when running jasper but I don't know where it is coming from. I have an invalid character sets in the middle of the classpath when converting the paths back to windows. Seems to be a cygwin issue with loong paths, since i have no problems with short paths. If someone with cygwin could check this it would be nice. see in the middle of the classpath: I have a jakart ?mcat-4.0 bash-2.05$ jasper.sh Guessing JASPER_HOME from catalina.sh to ./.. Setting JASPER_HOME to ./.. Using CLASSPATH: .;m:\sb_desproto\desproto\ichannel\lib\tomcat\jakarta-tomcat-4.0\classes;m:\ sb_desproto\desproto\ichannel\lib\tomcat\jakarta-tomcat-4.0\lib\jasper-runti me.jar;m:\sb_desproto\desproto\ichannel\lib\tomcat\jakarta-tomcat-4.0\common \lib\servlet.jar;m:\sb_desproto\desproto\ichannel\lib\tomcat\jakarta-tomcat- 4.0\lib\namingfactory.jar;m:\sb_desproto\desproto\ichannel\lib\tomcat\jakart a-tomcat-4.0\common\lib\servlet.jar;m:\sb_desproto\desproto\ichannel\lib\tom cat\jakarta-tomcat-4.0\jasper\crimson.jar;m:\sb_desproto\desproto\ichannel\l ib\tomcat\jakart ?mcat-4.0\common\lib\servlet.jar;m:\sb_desproto\desproto\ichannel\lib\tomcat \jakarta-tomcat-4.0\jasper\jasper-compiler.jar;m:\sb_desproto\desproto\ichan nel\lib\tomcat\jakarta-tomcat-4.0\common\lib\servlet.jar;m:\sb_desproto\desp roto\ichannel\lib\tomcat\jakarta-tomcat-4.0\jasper\jaxp.jar;m:\sb_desproto\d esproto\ichannel\lib\tomcat\jakarta-tomcat-4.0\common\lib\servlet.jar Using JASPER_HOME: m:\sb_desproto\desproto\ichannel\lib\tomcat\jakarta-tomcat-4.0 Using JAVA_HOME: e:\jdk\jdk1.3.1 Usage: jasper.sh ( jspc ) Commands: jspc - Run the jasper offline JSP compiler However, jasper.bat is incorrect. It sets JASPER_HOME=. and looks for %JASPER_HOME%\bin\jappend.bat Should be JASPER_HOME=.. Stephane
RE: [PATCH] TC 4.0 build patch - not a joke
Hi Craig and others in USA,
First, I make a point of presenting to you all
my condolences for the tragedy which struck
the USA, Tuesday last.
Henri,
I'm not necessarily opposed to this patch -- just want to
understand it a
little better. Basically, it looks like you are trying to do the
following (my comments interspersed in indented paragraphs):
* Declare foo.lib properties for all of the actual directories
in which the JAR files would be found.
I presume this is the thing your RPM build
script would be customizing, right?
Exact. For your information, the consensus on Linux Boxes,
Debian, Redhat, Mandrake, Suse, is to put ALL the jar jars
in /usr/share/java/
So all the TC 4.0 required stuff is installed in
/usr/share/java/
And when we package a RPM we indicate that to build TC 4.0
for example, we need JSSE, JAVAMAIL... which all lives in
/usr/share/java/
* Declare the foo.jar properties based on foo.lib settings
A logical consequence of the previous goal, but ...
* Remove declarations and uses of any foo.home
properties that currently exist.
This one I have some heartburn with, because
it breaks backwards compatibility with environments
that depend on this approach (which is also used in
several other projects at Jakarta and elsewhere).
* Add support for JSSE jar files using the standard approach
I haven't caught up on the email thread and/or patches
about this, but agree in principle that it should follow
the same conventions as for other JAR dependencies.
Can we think of a way to accomplish what you would like for RPMs that
does *not* create backwards incompatibilities? How about a three-layer
model like this (for a package with JARs in the home directory):
property name=activation.homevalue=/usr/local/jaf-1.0.1/
property name=activation.lib value=${activation.home}/
property name=activation.jar
value=${activation.lib}/activation.jar/
Ok for me that way.
or like this for something with a nested lib directory:
property name=jsse.home value=/usr/local/jsse-1.0.2/
property name=jsse.lib value=${jsse.home}/lib/
property name=jcert.jar value=${jsse.lib}/jcert.jar/
That way, you could override at *any* of the three levels, without
breaking old scripts that rely on the foo.home approach.
What do you think?
Ok for me also like this, since I could override jsse.lib in command
line. We want to avoid having to patch all the build.xml.
I fully agree, but we'll need also another modification since
in catalina build you grab every .jar in for regexp and when
regexp is in /usr/share/java/, you copy just ALL system jars !!!
In my case not less that 80 jar (regexp, oro, jtopen, .)
A another addon, be naming the name :
property name=regexp.name value=jakarta-regexp-1.2.jar/
=
--- catalina/build.xml.orig Tue Sep 11 00:05:17 2001
+++ catalina/build.xml Tue Sep 11 13:20:36 2001
@@ -25,14 +25,19 @@
property name=activation.jar
value=${activation.home}/activation.jar/
property name=jaxp.jarvalue=${catalina.jaxp.home}/jaxp.jar/
property name=parser.jar
value=${catalina.jaxp.home}/${catalina.jaxp.parser.jar}/
- property name=jcert.jar value=${jsse.home}/lib/jcert.jar/
- property name=jndi.jarvalue=${jndi.home}/lib/jndi.jar/
- property name=jnet.jarvalue=${jsse.home}/lib/jnet.jar/
- property name=jsse.jarvalue=${jsse.home}/lib/jsse.jar/
- property name=jmxri.jar value=${jmx.home}/lib/jmxri.jar/
+ property name=jsse.libvalue=${jsse.home}/lib//
+ property name=jmx.lib value=${jmx.home}/lib//
+ property name=jndi.libvalue=${jndi.home}/lib//
+ property name=servletapi.lib value=${servletapi.home}/lib//
+ property name=jcert.jar value=${jsse.lib}/jcert.jar/
+ property name=jndi.jarvalue=${jndi.lib}/jndi.jar/
+ property name=jnet.jarvalue=${jsse.lib}/jnet.jar/
+ property name=jsse.jarvalue=${jsse.lib}/jsse.jar/
+ property name=jmxri.jar value=${jmx.lib}/jmxri.jar/
property name=mail.jarvalue=${mail.home}/mail.jar/
- property name=regexp.jar
value=${regexp.home}/jakarta-regexp-1.2.jar/
- property name=servlet.jar
value=${servletapi.home}/lib/servlet.jar/
+ property name=regexp.name value=jakarta-regexp-1.2.jar/
+ property name=regexp.jar value=${regexp.home}/${regexp.name}/
+ property name=servlet.jar value=${servletapi.lib}/servlet.jar/
!-- Construct unit tests classpath --
path id=test.classpath
@@ -107,7 +112,7 @@
tofile=${catalina.build}/server/lib/${catalina.jaxp.parser.jar} /
!-- Catalina needs the regular expression library --
copy todir=${catalina.build}/server/lib
- fileset dir=${regexp.home} includes=*.jar/
+ fileset dir=${regexp.home} includes=${regexp.name}/
/copy
!-- Catalina needs the JSSE packages --
!--
=
URI handling in tomcat 3.2.3
Hi everyone, we were in progress of moving our project to tomcat 3.2.3 when we came accross the new handling of URIs (release-notes sec. 7.2). Since we are using the URI to transport other hierarchical information then filesystem paths, we have the feeling, that this kind of functionality belongs to the default servlet serving filesystem requests. Especialy the fact that %25, %2E, %2F and %5c inside an URI lead to a 404 error seems to somewhat strange. For Example: http://server/app/UCB/vnd.sun.star.hier:%2F/address/myresource would be rejected, before app has teh possibilty to look at the request and ...hier://address/myfile... would be normalized to hier:/address. We are perfectly aware of the security concerns behind these changes. However, they only apply when serving resources from the filesystem. A URL's path-components however are in no way bound to the representaion of filesystem paths.(After all, the U in URL stands for universal :) RFC 2396 states that '/' in an URI has another semantic meaning then %2F in an URI. The '/' seperates path-components, while the %2F means a slash character in a path-component. When such an URI is mapped to a filesystem this would denote a filename that contains a slash. When the system does not allow for such names, it is the responsebilty of the filesystem servlet to report an error (404 since such a file must not exist on unix for example). What are your opinions on this? Cheers -Lars -- -- Lars Oppermann [EMAIL PROTECTED] Sun Microsystems Software Engineer - Sun ONE Webtop Sachsenfeld 4 Phone: +49 40 23646 959D-20097 Hamburg Fax: +49 40 23646 550 http://www.sun.com/webtop
RE: Remaining Tomcat 3.3 Issues
Then we need to be sure to encode r-uri in the main branch
and to change r-unparsed_uri to encode(r-uri) in the 3.2
branch. I am swamped now and will put it on a long todo
list.. if anyone beats me to it.
And don't forget to port to j-t-c which is still using
for Apache 1.3/2.0 :::
/*
* The 2.2 servlet spec errata says the uri from
* HttpServletRequest.getRequestURI() should remain encoded.
* [http://java.sun.com/products/servlet/errata_042700.html]
*/
s-req_uri = r-unparsed_uri;
if (s-req_uri != NULL) {
char *query_str = strchr(s-req_uri, '?');
if (query_str != NULL) {
*query_str = 0;
}
}
What do you think about that Ryan and Frederic ?
I was planning to add JkOptions directive to mod_jk,
à la mod_ssl, may be another this could be one of the
option to tune the comportement depending people use ?
JkOptions +ForwardUnparsedURI
Tomcat4-RC1: parse exception on taglibs
Hey I've finally managed to get Catalina working with JBoss (I had not set catalina.base, but no error was produced, just nothing happened). Anyway, the first thing I try is to deploy an app with a taglib JAR, with the TLD inside. But it seems like there's something wrong with the TLD parsing because I get this: org.xml.sax.SAXParseException: The markup in the document preceding the root element must be well-formed. And this happens no matter what I do with the actual TLD. Removing the taglib makes the WAR deploy properly, so it's definitely that which blows up. Any ideas? /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0 BUILDING.txt
Hi,
What about telling how to get xalan.jar?
Like:
Xalan could be downloaded from http://xml.apache.org/dist/xalan-j, the xalan.jar
file is located in the bin directory of the Xalan installation.
Which Xalan should be used? - I have used xalan-j_2_2_D10 -
Cheers
Jean-frederic
[EMAIL PROTECTED] wrote:
craigmcc01/09/11 09:54:41
Modified:.BUILDING.txt
Log:
Update BUILDING.txt to reflect the new requirement for Ant 1.4.
NOTE: The new requirements for JavaMail and JAF (added on Saturday)
*were* added in the version of BUILDING.txt, but I forgot to remove the
old docs about optionally downloading them. Removee the obsolete stuff
and renumbered following points as needed.
Revision ChangesPath
1.3 +20 -51jakarta-tomcat-4.0/BUILDING.txt
Index: BUILDING.txt
===
RCS file: /home/cvs/jakarta-tomcat-4.0/BUILDING.txt,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- BUILDING.txt 2001/09/09 04:00:07 1.2
+++ BUILDING.txt 2001/09/11 16:54:41 1.3
@@ -1,4 +1,4 @@
-$Id: BUILDING.txt,v 1.2 2001/09/09 04:00:07 craigmcc Exp $
+$Id: BUILDING.txt,v 1.3 2001/09/11 16:54:41 craigmcc Exp $
Building The Tomcat 4.0 Servlet/JSP Container
@@ -26,29 +26,25 @@
(1) Download and Install the Ant Binary Distribution
-NOTE: These instructions assume that you are using the Ant 1.3 release.
-Procedures for Ant 1.4 and later versions should be similar, but have not
-been tested.
+* Download a binary distribution of Ant 1.4 from:
-* Download a binary distribution of Ant 1.3 from:
+http://jakarta.apache.org/builds/jakarta-ant/release/v1.4/bin/
-http://jakarta.apache.org/builds/jakarta-ant/release/v1.3/bin/
-
On a Windows platform, you will need:
-jakarta-ant-1.3-bin.zip
-jakarta-ant-1.3-optional.jar
+jakarta-ant-1.4-bin.zip
+jakarta-ant-1.4-optional.jar
On a Unix platform, you will need:
-jakarta-ant-1.3-bin.tar.gz
-jakarta-ant-1.3-optional.jar
+jakarta-ant-1.4-bin.tar.gz
+jakarta-ant-1.4-optional.jar
* Unpack the binary distribution into a convenient location so that the
Ant release resides in its own directory (conventionally named
- jakarta-ant-1.3). For the purposes of the remainder of this document,
+ jakarta-ant-1.4). For the purposes of the remainder of this document,
the symbolic name ${ant.home} is used to refer to the full pathname of
the release directory.
-* Copy the file jakarta-ant-1.3-optional.jar, downloaded above, into
+* Copy the file jakarta-ant-1.4-optional.jar, downloaded above, into
the directory ${ant.home}/lib. This makes available several Ant
extension commands that are commonly required when building Jakarta
based projects.
@@ -69,18 +65,11 @@
jaxp-1.1. For the purposes of the remainder of this document, the
symbolic name ${jaxp.home} is used to refer to the full pathname of
the release directory.
-
-* Make the JAR files of this distribution (crimson.jar, jaxp.jar, and
- xalan.jar) available for use by performing ONE of the following options:
- - Remove the existing jaxp.jar and parser.jar files found in the
-${ant.home}/lib directory, and copy these JAR files into the
-${ant.home}/lib directory (prefered option).
+* Make the xalan.jar file of this distribution available to Ant (so that
+ it can be used with the style tag) by copying it to ${ant.home}/lib.
- - Add these files to your CLASSPATH environment variable when you
-execute the build process.
-
(3) Download and Install Subproject Source Code
* Use Anonymous CVS (as described on the Jakarta web site at
@@ -161,28 +150,8 @@
* Unpack the package into a convenient location so that it resides
in its own subdirectory.
-
-(7) Download and Install JavaMail and Java Activation Framework (OPTIONAL)
-
-NOTE: This step is required only if you plan to build the resource object
-factories for creating mail-related JNDI resources.
-
-* Download the JavaMail Reference Implementation (version 1.2 or later) from:
-
-http://java.sun.com/products/javamail/
-
-* Unpack the reference implementation into a convenient location so that
- it resides in its own subdirectory.
-
-* Download the JavaBeans Activation Framework (version 1.0.1 or later) from:
-
-http://java.sun.com/products/javabeans/glasgow/jaf.html
-
-* Unpack the framework into a convenient location so that it resides
- in its own subdirectory.
-
-(8) Download and Install the JMX 1.0 Reference Implementation
+(7) Download and Install the JMX 1.0 Reference Implementation
* Download the JMX Instrumentation and Agent Reference
Re: Tomcat4-RC1: parse exception on taglibs
Rickard Öberg wrote: I've finally managed to get Catalina working with JBoss (I had not set catalina.base, but no error was produced, just nothing happened). Anyway, the first thing I try is to deploy an app with a taglib JAR, with the TLD inside. But it seems like there's something wrong with the TLD parsing because I get this: org.xml.sax.SAXParseException: The markup in the document preceding the root element must be well-formed. And this happens no matter what I do with the actual TLD. Removing the taglib makes the WAR deploy properly, so it's definitely that which blows up. This apparently only happens when the WAR is deployed through the EmbeddedManager MBean. When deploying the same WAR, with the taglib, as a webapp by placing it in /webapps and running startup.bat, there is no error. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED]
[DO NOT REPLY: Bug 3580] New: manager webapp: role wrong
PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL BE LOST SOMEWHERE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3580 *** shadow/3580 Thu Sep 13 04:18:18 2001 --- shadow/3580.tmp.2294Thu Sep 13 04:18:18 2001 *** *** 0 --- 1,36 + ++ + | manager webapp: role wrong | + ++ + |Bug #: 3580Product: Tomcat 4| + | Status: NEW Version: Nightly Build | + | Resolution:Platform: Other | + | Severity: Normal OS/Version: Other | + | Priority: Other Component: Webapps | + ++ + | Assigned To: [EMAIL PROTECTED]| + | Reported By: [EMAIL PROTECTED] | + | CC list: Cc: | + ++ + | URL: | + ++ + | DESCRIPTION | + Hi, + + The docs state that role admin is checked for by the manager app. Eg, in + webapps/tomcat-docs/manager-howto.xml: + + lt;user name=craigmcc password=secret roles=standard,admingt; + + This is also what 3.x uses. + + However, the manager app actually requires role manager. The web.xml contains: + +auth-constraint +!-- NOTE: This role is not present in the default users file -- +role-namemanager/role-name + /auth-constraint + + So either the docs need to change, or the manager web.xml needs to change. + Preferably the latter, given the precendent. + + --Jeff
[DO NOT REPLY: Bug 3581] New: Ctx() : Error creating validation mark - java.io.FileNotFoundException
PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL BE LOST SOMEWHERE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3581 *** shadow/3581 Thu Sep 13 05:52:35 2001 --- shadow/3581.tmp.2600Thu Sep 13 05:52:35 2001 *** *** 0 --- 1,67 + ++ + | Ctx() : Error creating validation mark - java.io.FileNotFoundException| + ++ + |Bug #: 3581Product: Tomcat 3| + | Status: NEW Version: 3.3 Beta 2 | + | Resolution:Platform: PC | + | Severity: Normal OS/Version: Linux | + | Priority: Other Component: Unknown | + ++ + | Assigned To: [EMAIL PROTECTED]| + | Reported By: [EMAIL PROTECTED] | + | CC list: Cc: | + ++ + | URL: | + ++ + | DESCRIPTION | + Hi, + + Since we've moved to tomcat 3.3-b1 tomcat 3.3-b2, we've been getting this + error into the logs : + + 2001-09-13 14:44:40 - SessionIdGenerator: Opening /dev/urandom + 2001-09-13 14:44:40 - ServerXmlReader: Config=$TOMCAT_HOME/conf/server.xml + 2001-09-13 14:44:40 - PathSetter: home=/var/tomcat + 2001-09-13 14:44:41 - ContextXmlReader: Context + config=$TOMCAT_HOME/conf/apps-kitu.xml + 2001-09-13 14:44:41 - AutoDeploy: Source or destination missing + 2001-09-13 14:44:41 - AutoWebApp: No autoconf directory /var/tomcat/modules + 2001-09-13 14:44:41 - AutoWebApp: Auto-Adding DEFAULT:/kitu-1.9.39 + 2001-09-13 14:44:41 - ContextManager: Tomcat configured and in stable state + 2001-09-13 14:44:41 - WorkDirSetup: Creating work dir + /var/tomcat/work/kitu.olympe.o2t/ROOT + 2001-09-13 14:44:41 - ContextManager: Adding kitu.olympe.o2t:/ROOT + 2001-09-13 14:44:41 - WorkDirSetup: Creating work dir + /var/tomcat/work/DEFAULT/kitu-1.9.39 + 2001-09-13 14:44:41 - ContextManager: Adding DEFAULT:/kitu-1.9.39 + 2001-09-13 14:44:41 - Ctx() : Validating web.xml + 2001-09-13 14:44:41 - Ctx() : Error creating validation mark - + java.io.FileNotFoundException: + /var/tomcat/work/kitu.olympe.o2t/ROOT/webxmlval.txt (No such file or directory) + at java.io.FileOutputStream.open(Native Method) + at java.io.FileOutputStream.init(FileOutputStream.java:108) + at java.io.FileOutputStream.init(FileOutputStream.java:68) + at java.io.FileOutputStream.init(FileOutputStream.java:138) + at + org.apache.tomcat.facade.WebXmlReader.processWebXmlFile(WebXmlReader.java:237) + at org.apache.tomcat.facade.WebXmlReader.contextInit(WebXmlReader.java:112) + at org.apache.tomcat.core.Context.init(Context.java:542) + at org.apache.tomcat.core.ContextManager.init(ContextManager.java:595) + at + org.apache.tomcat.startup.EmbededTomcat.initContextManager(EmbededTomcat.java:425) + at org.apache.tomcat.startup.EmbededTomcat.execute1(EmbededTomcat.java:546) + at org.apache.tomcat.startup.EmbededTomcat$1.run(EmbededTomcat.java:530) + at + org.apache.tomcat.util.compat.Jdk12Support$PrivilegedProxy.run(Jdk12Support.java:163) + at java.security.AccessController.doPrivileged(Native Method) + at + org.apache.tomcat.util.compat.Jdk12Support.doPrivileged(Jdk12Support.java:96) + at org.apache.tomcat.startup.EmbededTomcat.execute(EmbededTomcat.java:528) + at java.lang.reflect.Method.invoke(Native Method) + at + org.apache.tomcat.util.IntrospectionUtils.execute(IntrospectionUtils.java:87) + at org.apache.tomcat.startup.Main.execute(Main.java:307) + at org.apache.tomcat.startup.Main.main(Main.java:134) + + is it dangerous ? + How can we solve this ?
[DO NOT REPLY: Bug 3582] New: Tomcat 3.2.1
PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL BE LOST SOMEWHERE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3582 *** shadow/3582 Thu Sep 13 06:09:30 2001 --- shadow/3582.tmp.3214Thu Sep 13 06:09:30 2001 *** *** 0 --- 1,23 + ++ + | Tomcat 3.2.1 | + ++ + |Bug #: 3582Product: Tomcat 3| + | Status: NEW Version: 3.2.1 Final | + | Resolution:Platform: Other | + | Severity: Normal OS/Version: Windows NT/2K | + | Priority: Other Component: Webapps | + ++ + | Assigned To: [EMAIL PROTECTED]| + | Reported By: [EMAIL PROTECTED] | + | CC list: Cc: | + ++ + | URL: | + ++ + | DESCRIPTION | + The Tomcat server crashes if we access a Quickbook database ..through Linkbook + odbc driver through JDBC:ODBC bridge. We have developed a webservices to query + the results which uses the Linkbook odbc to connect to Quickbooks and after + returning the result(to and fro SOAP call) immediately Tomcat crashes and only + once we can query the result. We are USING JDK 1.2.2 (JDBC 2). We need to have + a solution for this as Linkbook ODBC driver can be accessed only through JDK + 1.2.2or its predecessers.
RE: URI handling in tomcat 3.2.3
I agree that this URI handling sucks. I'm the one that committed the change that made it happen and I still think it sucks. However, allowing these encoded characters opens some very large security problems. Also, even if TC 3.2.x allowed these characters, the resulting URL wouldn't be portable because several other web servers impose the same restrictions. In fact we lifted our restriction on encoded special characters straight from Apache HTTPD. In your example URL, if /app/UCB was a CGI script then you would still get a 404 on Apache (at least on Apache 1.3.19 which is what I tested with). If you need to pass this sort of data to a servlet (or CGI) the most portable way is to simply use a query string. Marc Saegesser -Original Message- From: Lars Oppermann [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 5:00 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: URI handling in tomcat 3.2.3 Hi everyone, we were in progress of moving our project to tomcat 3.2.3 when we came accross the new handling of URIs (release-notes sec. 7.2). Since we are using the URI to transport other hierarchical information then filesystem paths, we have the feeling, that this kind of functionality belongs to the default servlet serving filesystem requests. Especialy the fact that %25, %2E, %2F and %5c inside an URI lead to a 404 error seems to somewhat strange. For Example: http://server/app/UCB/vnd.sun.star.hier:%2F/address/myresource would be rejected, before app has teh possibilty to look at the request and ...hier://address/myfile... would be normalized to hier:/address. We are perfectly aware of the security concerns behind these changes. However, they only apply when serving resources from the filesystem. A URL's path-components however are in no way bound to the representaion of filesystem paths.(After all, the U in URL stands for universal :) RFC 2396 states that '/' in an URI has another semantic meaning then %2F in an URI. The '/' seperates path-components, while the %2F means a slash character in a path-component. When such an URI is mapped to a filesystem this would denote a filename that contains a slash. When the system does not allow for such names, it is the responsebilty of the filesystem servlet to report an error (404 since such a file must not exist on unix for example). What are your opinions on this? Cheers -Lars -- -- Lars Oppermann [EMAIL PROTECTED] Sun Microsystems Software Engineer - Sun ONE Webtop Sachsenfeld 4 Phone: +49 40 23646 959D-20097 Hamburg Fax: +49 40 23646 550 http://www.sun.com/webtop
RE: URI handling in tomcat 3.2.3
Oops, minor correction. Apache actually returns 400 Bad Request Here's the telnet session GET http://localhost:8081/cgi-bin/dumpenv.bat/fu%2fbar HTTP/1.1 server: msaegesserlpt HTTP/1.1 400 Bad Request Date: Thu, 13 Sep 2001 13:51:21 GMT Server: Apache/1.3.19 (Win32) mod_jk Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1 18b !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN HTMLHEAD TITLE400 Bad Req uest/TITLE /HEADBODY H1Bad Request/H1 Your browser sent a request that th is server could not understand.P client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /cgi-bin/dumpenv.bat/fu%2fbarP HR ADDRESSApache /1.3.19 Server at msaegesserlpt Port 8081/ADDRESS /BODY/HTML 0 Connection to host lost. Marc Saegesser -Original Message- From: Marc Saegesser [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 8:48 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: URI handling in tomcat 3.2.3 I agree that this URI handling sucks. I'm the one that committed the change that made it happen and I still think it sucks. However, allowing these encoded characters opens some very large security problems. Also, even if TC 3.2.x allowed these characters, the resulting URL wouldn't be portable because several other web servers impose the same restrictions. In fact we lifted our restriction on encoded special characters straight from Apache HTTPD. In your example URL, if /app/UCB was a CGI script then you would still get a 404 on Apache (at least on Apache 1.3.19 which is what I tested with). If you need to pass this sort of data to a servlet (or CGI) the most portable way is to simply use a query string. Marc Saegesser -Original Message- From: Lars Oppermann [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 5:00 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: URI handling in tomcat 3.2.3 Hi everyone, we were in progress of moving our project to tomcat 3.2.3 when we came accross the new handling of URIs (release-notes sec. 7.2). Since we are using the URI to transport other hierarchical information then filesystem paths, we have the feeling, that this kind of functionality belongs to the default servlet serving filesystem requests. Especialy the fact that %25, %2E, %2F and %5c inside an URI lead to a 404 error seems to somewhat strange. For Example: http://server/app/UCB/vnd.sun.star.hier:%2F/address/myresource would be rejected, before app has teh possibilty to look at the request and ...hier://address/myfile... would be normalized to hier:/address. We are perfectly aware of the security concerns behind these changes. However, they only apply when serving resources from the filesystem. A URL's path-components however are in no way bound to the representaion of filesystem paths.(After all, the U in URL stands for universal :) RFC 2396 states that '/' in an URI has another semantic meaning then %2F in an URI. The '/' seperates path-components, while the %2F means a slash character in a path-component. When such an URI is mapped to a filesystem this would denote a filename that contains a slash. When the system does not allow for such names, it is the responsebilty of the filesystem servlet to report an error (404 since such a file must not exist on unix for example). What are your opinions on this? Cheers -Lars -- -- Lars Oppermann [EMAIL PROTECTED] Sun Microsystems Software Engineer - Sun ONE Webtop Sachsenfeld 4 Phone: +49 40 23646 959D-20097 Hamburg Fax: +49 40 23646 550 http://www.sun.com/webtop
RE: Ajp13Interceptor
What about adding a debug attributes in server.xml for Ajps Connectors ? Could be very very very usefull in many circumstances.. - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Larry Isaacs [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 2:15 PM To: '[EMAIL PROTECTED]' Subject: RE: Ajp13Interceptor Its hard wired near the end of the Ajp13Request class. Its now fixed. Thanks for finding this. Larry -Original Message- From: Bojan Smojver [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 12:10 AM To: Tomcat Dev List Subject: Ajp13Interceptor I've notice that the most recent Ajp13Interceptor prints something like this into log files: -- Ajp13Request: Read: formid=orderemail=a%40aacustomer=aaddress=acity=astate=a postcode=acountry=Bermudashipping=airproduct=Pooh+Cosmology +and+the+Quantum+Physicsquantity=2.0product=Pooh+Geology+and +the+History+of+Lifequantity=recalculate=Recalculate -- After inspecting the code, it turns out that the output is the result of the call in line 243 to method d(). This is controlled by: -- private static final int dL=10; -- How do I disable that from within server.xml (or whichever other conf file), rather then by modifying the code? For debugging it's OK, but it creates a lot of noise in the log files... Bojan
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup Bootstrap.java BootstrapService.java
glenn 01/09/13 07:26:18
Modified:catalina/src/share/org/apache/catalina/startup
Bootstrap.java BootstrapService.java
Log:
Add org.apache.catalina.util.URL to classes preloaded
Revision ChangesPath
1.26 +6 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java
Index: Bootstrap.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- Bootstrap.java2001/09/11 23:34:43 1.25
+++ Bootstrap.java2001/09/13 14:26:18 1.26
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
1.25 2001/09/11 23:34:43 craigmcc Exp $
- * $Revision: 1.25 $
- * $Date: 2001/09/11 23:34:43 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
1.26 2001/09/13 14:26:18 glenn Exp $
+ * $Revision: 1.26 $
+ * $Date: 2001/09/13 14:26:18 $
*
*
*
@@ -85,7 +85,7 @@
* class path and therefore not visible to application level classes.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.25 $ $Date: 2001/09/11 23:34:43 $
+ * @version $Revision: 1.26 $ $Date: 2001/09/13 14:26:18 $
*/
public final class Bootstrap {
@@ -179,6 +179,8 @@
(basePackage + session.StandardSession);
catalinaLoader.loadClass
(basePackage + util.CookieTools);
+catalinaLoader.loadClass
+(basePackage + util.URL);
catalinaLoader.loadClass(basePackage + util.Enumerator);
catalinaLoader.loadClass(javax.servlet.http.Cookie);
}
1.7 +6 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/BootstrapService.java
Index: BootstrapService.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/BootstrapService.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- BootstrapService.java 2001/09/12 21:15:59 1.6
+++ BootstrapService.java 2001/09/13 14:26:18 1.7
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/BootstrapService.java,v
1.6 2001/09/12 21:15:59 remm Exp $
- * $Revision: 1.6 $
- * $Date: 2001/09/12 21:15:59 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/BootstrapService.java,v
1.7 2001/09/13 14:26:18 glenn Exp $
+ * $Revision: 1.7 $
+ * $Date: 2001/09/13 14:26:18 $
*
*
*
@@ -86,7 +86,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.6 $ $Date: 2001/09/12 21:15:59 $
+ * @version $Revision: 1.7 $ $Date: 2001/09/13 14:26:18 $
*/
public final class BootstrapService
@@ -178,6 +178,8 @@
(basePackage + session.StandardSession);
catalinaLoader.loadClass
(basePackage + util.CookieTools);
+catalinaLoader.loadClass
+(basePackage + util.URL);
catalinaLoader.loadClass(basePackage + util.Enumerator);
catalinaLoader.loadClass(javax.servlet.http.Cookie);
}
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp Ajp13.java
jfclere 01/09/13 07:29:51 Modified:jk/java/org/apache/ajp Ajp13.java Log: Add javax.servlet.request.key_size for TC4.0 Revision ChangesPath 1.11 +2 -0 jakarta-tomcat-connectors/jk/java/org/apache/ajp/Ajp13.java Index: Ajp13.java === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/Ajp13.java,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- Ajp13.java2001/09/10 18:32:36 1.10 +++ Ajp13.java2001/09/13 14:29:51 1.11 @@ -403,6 +403,8 @@ isSSL = true; req.setAttribute(javax.servlet.request.X509Certificate, msg.getString()); +req.setAttribute(javax.servlet.request.key_size, + new Integer (msg.getLen())); break; case SC_A_SSL_CIPHER :
[DO NOT REPLY: Bug 3582] Tomcat 3.2.1
PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL BE LOST SOMEWHERE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3582 *** shadow/3582 Thu Sep 13 06:09:30 2001 --- shadow/3582.tmp.4873Thu Sep 13 08:01:49 2001 *** *** 2,9 | Tomcat 3.2.1 | ++ |Bug #: 3582Product: Tomcat 3| ! | Status: NEW Version: 3.2.1 Final | ! | Resolution:Platform: Other | | Severity: Normal OS/Version: Windows NT/2K | | Priority: Other Component: Webapps | ++ --- 2,9 | Tomcat 3.2.1 | ++ |Bug #: 3582Product: Tomcat 3| ! | Status: RESOLVEDVersion: 3.2.1 Final | ! | Resolution: INVALIDPlatform: Other | | Severity: Normal OS/Version: Windows NT/2K | | Priority: Other Component: Webapps | ++ *** *** 20,23 returning the result(to and fro SOAP call) immediately Tomcat crashes and only once we can query the result. We are USING JDK 1.2.2 (JDBC 2). We need to have a solution for this as Linkbook ODBC driver can be accessed only through JDK ! 1.2.2or its predecessers. --- 20,28 returning the result(to and fro SOAP call) immediately Tomcat crashes and only once we can query the result. We are USING JDK 1.2.2 (JDBC 2). We need to have a solution for this as Linkbook ODBC driver can be accessed only through JDK ! 1.2.2or its predecessers. ! ! --- Additional Comments From [EMAIL PROTECTED] 2001-09-13 08:01 --- ! Since Tomcat is entirely written in Java, it should be impossible to crash. ! Thus, crashes represent bugs outside of Tomcat's control. Try a different ! JDK and/or investigating the JDBC:ODBC support as the source of the crash.
Re: Tomcat4-RC1: parse exception on taglibs
Rickard Öberg wrote: Rickard Öberg wrote: I've finally managed to get Catalina working with JBoss (I had not set catalina.base, but no error was produced, just nothing happened). Anyway, the first thing I try is to deploy an app with a taglib JAR, with the TLD inside. But it seems like there's something wrong with the TLD parsing because I get this: org.xml.sax.SAXParseException: The markup in the document preceding the root element must be well-formed. And this happens no matter what I do with the actual TLD. Removing the taglib makes the WAR deploy properly, so it's definitely that which blows up. This apparently only happens when the WAR is deployed through the EmbeddedManager MBean. When deploying the same WAR, with the taglib, as a webapp by placing it in /webapps and running startup.bat, there is no error. Even more info. Setting debug level to high, and looking in the logs I found this: 2001-09-13 17:12:35 ContextConfig[/webwork]: URI='webwork', ResourcePath='/WEB-INF/lib/webwork.jar' 2001-09-13 17:12:35 ContextConfig[/webwork]: tldConfigJar(/WEB-INF/lib/webwork.jar): java.lang.IllegalStateException: zip file closed 2001-09-13 17:12:35 ContextConfig[/webwork]: tldConfigTld(/WEB-INF/lib/webwork.jar): org.xml.sax.SAXParseException: The markup in the document preceding the root element must be well-formed. This does not happen if the webapp is deployed in /webapps and I run Tomcat4 through startup.bat, only when I do it using the EmbeddedManager MBean. Any ideas? Should I just send this to the bug tracker and await any response? /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/jasper/src/bin jasper.sh
craigmcc01/09/13 08:22:45 Modified:jasper/src/bin jasper.sh Log: Fix the jasper.sh update checked in yesterday: * Do not use an uninitialized CP variable the first time through * Add double quotes as needed in case paths have spaces in them * Add all of the repositories that will be visible at runtime (classes, jasper/*.jar, lib/*.jar, common/classes, common/lib/*.jar) * Build the class path in an order to simulate the class loading hierarchy that will be visible at runtime. Revision ChangesPath 1.5 +13 -7 jakarta-tomcat-4.0/jasper/src/bin/jasper.sh Index: jasper.sh === RCS file: /home/cvs/jakarta-tomcat-4.0/jasper/src/bin/jasper.sh,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- jasper.sh 2001/09/12 00:54:28 1.4 +++ jasper.sh 2001/09/13 15:22:45 1.5 @@ -13,7 +13,7 @@ # JAVA_HOME # Must point at your Java Development Kit installation. # -# $Id: jasper.sh,v 1.4 2001/09/12 00:54:28 craigmcc Exp $ +# $Id: jasper.sh,v 1.5 2001/09/13 15:22:45 craigmcc Exp $ # - @@ -47,7 +47,7 @@ fi if [ $JAVA_HOME = ] ; then - echo You must set JAVA_HOME to point at your Java Development Kit installation + echo You must set JAVA_HOME to point at your Java Development Kit installation exit 1 fi @@ -71,11 +71,17 @@ # - Set Up The System Classpath --- -CP=$CP:$JASPER_HOME/classes -for i in $JASPER_HOME/lib/*.jar $JASPER_HOME/jasper/*.jar ; do - CP=$CP:$i -CP=$CP:$JASPER_HOME/common/lib/servlet.jar +CP=$JASPER_HOME/classes +for i in $JASPER_HOME/jasper/*.jar ; do + CP=$CP:$i done +for i in $JASPER_HOME/lib/*.jar ; do + CP=$CP:$i +done +CP=$CP:$JASPER_HOME/common/classes +for i in $JASPER_HOME/common/lib/*.jar ; do + CP=$CP:$i +done # - Cygwin Windows Paths Setup @@ -103,7 +109,7 @@ else - echo Usage: jasper.sh ( jspc ) + echo Usage: jasper.sh [ jspc ] echo Commands: echo jspc - Run the jasper offline JSP compiler exit 1
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator LocalStrings_es.properties
craigmcc01/09/13 08:24:06 Modified:catalina/src/share/org/apache/catalina/authenticator LocalStrings_es.properties Log: Cosmetic change only. Revision ChangesPath 1.2 +1 -3 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/LocalStrings_es.properties Index: LocalStrings_es.properties === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/LocalStrings_es.properties,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- LocalStrings_es.properties2000/11/09 23:11:30 1.1 +++ LocalStrings_es.properties2001/09/13 15:24:06 1.2 @@ -1,7 +1,5 @@ -# $Id: LocalStrings_es.properties,v 1.1 2000/11/09 23:11:30 nacho Exp $ - +# $Id: LocalStrings_es.properties,v 1.2 2001/09/13 15:24:06 craigmcc Exp $ # language es - # package org.apache.catalina.authenticator
RE: [ANNOUNCE] Tomcat 4.0 Release Candidate 1 Available
I should have jasper.sh working correctly now. It was using CP the first time without initializing it, and was missing some double quotes that could cause problems with paths that had spaces in them. Will be fixed in nightly build 20010914 (and rc2). Craig On Thu, 13 Sep 2001, Stephane Bailliez wrote: Date: Thu, 13 Sep 2001 10:15:49 +0100 From: Stephane Bailliez [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: [ANNOUNCE] Tomcat 4.0 Release Candidate 1 Available -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] I *finally* got to these suggested patches, and have commited changes to catalina.sh, digest.sh, and jasper.sh to implement Cygwin support consistently and (hopefully) correctly. Could you please try all of these scripts with tonight's nightly build (20010912) to make sure that I didn't mess anything up? catalina.sh works like a charm. jasper.sh I have a small glitch in the classpath when running jasper but I don't know where it is coming from. I have an invalid character sets in the middle of the classpath when converting the paths back to windows. Seems to be a cygwin issue with loong paths, since i have no problems with short paths. If someone with cygwin could check this it would be nice. see in the middle of the classpath: I have a jakart ?mcat-4.0 bash-2.05$ jasper.sh Guessing JASPER_HOME from catalina.sh to ./.. Setting JASPER_HOME to ./.. Using CLASSPATH: .;m:\sb_desproto\desproto\ichannel\lib\tomcat\jakarta-tomcat-4.0\classes;m:\ sb_desproto\desproto\ichannel\lib\tomcat\jakarta-tomcat-4.0\lib\jasper-runti me.jar;m:\sb_desproto\desproto\ichannel\lib\tomcat\jakarta-tomcat-4.0\common \lib\servlet.jar;m:\sb_desproto\desproto\ichannel\lib\tomcat\jakarta-tomcat- 4.0\lib\namingfactory.jar;m:\sb_desproto\desproto\ichannel\lib\tomcat\jakart a-tomcat-4.0\common\lib\servlet.jar;m:\sb_desproto\desproto\ichannel\lib\tom cat\jakarta-tomcat-4.0\jasper\crimson.jar;m:\sb_desproto\desproto\ichannel\l ib\tomcat\jakart ?mcat-4.0\common\lib\servlet.jar;m:\sb_desproto\desproto\ichannel\lib\tomcat \jakarta-tomcat-4.0\jasper\jasper-compiler.jar;m:\sb_desproto\desproto\ichan nel\lib\tomcat\jakarta-tomcat-4.0\common\lib\servlet.jar;m:\sb_desproto\desp roto\ichannel\lib\tomcat\jakarta-tomcat-4.0\jasper\jaxp.jar;m:\sb_desproto\d esproto\ichannel\lib\tomcat\jakarta-tomcat-4.0\common\lib\servlet.jar Using JASPER_HOME: m:\sb_desproto\desproto\ichannel\lib\tomcat\jakarta-tomcat-4.0 Using JAVA_HOME: e:\jdk\jdk1.3.1 Usage: jasper.sh ( jspc ) Commands: jspc - Run the jasper offline JSP compiler However, jasper.bat is incorrect. It sets JASPER_HOME=. and looks for %JASPER_HOME%\bin\jappend.bat Should be JASPER_HOME=.. Stephane
RE: [PATCH] TC 4.0 build patch - not a joke
On Thu, 13 Sep 2001, GOMEZ Henri wrote:
Date: Thu, 13 Sep 2001 11:44:19 +0200
From: GOMEZ Henri [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: RE: [PATCH] TC 4.0 build patch - not a joke
Hi Craig and others in USA,
First, I make a point of presenting to you all
my condolences for the tragedy which struck
the USA, Tuesday last.
Thanks.
For those of you who don't know, Sun had an office on the 25th and 26th
floor of WTC #2, housing about 350 employees. Thankfully, all of them
have been accounted for -- but a Sun manager was on one of the hijacked
planes from Boston.
Henri,
I'm not necessarily opposed to this patch -- just want to
understand it a
little better. Basically, it looks like you are trying to do the
following (my comments interspersed in indented paragraphs):
* Declare foo.lib properties for all of the actual directories
in which the JAR files would be found.
I presume this is the thing your RPM build
script would be customizing, right?
Exact. For your information, the consensus on Linux Boxes,
Debian, Redhat, Mandrake, Suse, is to put ALL the jar jars
in /usr/share/java/
So all the TC 4.0 required stuff is installed in
/usr/share/java/
And when we package a RPM we indicate that to build TC 4.0
for example, we need JSSE, JAVAMAIL... which all lives in
/usr/share/java/
How does the RPM packaging deal with the fact that different JAR files
need to be loaded into different class loaders? If they are all under
/usr/share/java, I don't see how that can work.
How does the RPM packaging deal with the fact that you might want to use
different XML parsers inside Catalina (i.e. from serverl/lib) or in
webapps (from lib)?
* Declare the foo.jar properties based on foo.lib settings
A logical consequence of the previous goal, but ...
* Remove declarations and uses of any foo.home
properties that currently exist.
This one I have some heartburn with, because
it breaks backwards compatibility with environments
that depend on this approach (which is also used in
several other projects at Jakarta and elsewhere).
* Add support for JSSE jar files using the standard approach
I haven't caught up on the email thread and/or patches
about this, but agree in principle that it should follow
the same conventions as for other JAR dependencies.
Can we think of a way to accomplish what you would like for RPMs that
does *not* create backwards incompatibilities? How about a three-layer
model like this (for a package with JARs in the home directory):
property name=activation.homevalue=/usr/local/jaf-1.0.1/
property name=activation.lib value=${activation.home}/
property name=activation.jar
value=${activation.lib}/activation.jar/
Ok for me that way.
OK, I will go ahead and modify the build scripts to follow this pattern.
or like this for something with a nested lib directory:
property name=jsse.home value=/usr/local/jsse-1.0.2/
property name=jsse.lib value=${jsse.home}/lib/
property name=jcert.jar value=${jsse.lib}/jcert.jar/
That way, you could override at *any* of the three levels, without
breaking old scripts that rely on the foo.home approach.
What do you think?
Ok for me also like this, since I could override jsse.lib in command
line. We want to avoid having to patch all the build.xml.
I fully agree, but we'll need also another modification since
in catalina build you grab every .jar in for regexp and when
regexp is in /usr/share/java/, you copy just ALL system jars !!!
In my case not less that 80 jar (regexp, oro, jtopen, .)
I did a separate patch to catalina.bat/catalina.sh that specifically adds
the JSSE classes.
For Regexp, if Jon would remove the version number from the JAR file I
wouldn't have to do that :-). Of all the dependencies in Tomcat, this is
the *only* project that does versioning in the JAR file name.
A another addon, be naming the name :
property name=regexp.name value=jakarta-regexp-1.2.jar/
I'll make sure I cover that one too.
Craig
Does Jasper use the Context Classpath when compiling JSP's?
Greetings! I know there are two (or three) different classpaths within Tomcat 3.2. I asked this question on tomcat-user last week, but no one knew the answer. The question is, does Jasper, when compiling JSP files, use the Context Classpath, which referrs to the WEB-INF/classes directory for that specific JSP? If not, how could I add the Context Classpath to the Jasper code? Can someone point me to a breakdown of the classloading within Jasper specifically? I've seen the classloading for Servlets, and that is all kosher. Thank you in advance for any tips, pointers, or direction. Will -- /~'find `funny quote`': Command not found; humor not installed. 1986 Concours 72,xxx CDA #00046 COG AMA Overland Park, KS [EMAIL PROTECTED] PCS: 316-371-FOAD http://will.mylanders.com/
Re: cvs commit: jakarta-tomcat-4.0 BUILDING.txt
On Thu, 13 Sep 2001, jean-frederic clere wrote:
Date: Thu, 13 Sep 2001 12:48:25 +0200
From: jean-frederic clere [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED], [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: cvs commit: jakarta-tomcat-4.0 BUILDING.txt
Hi,
What about telling how to get xalan.jar?
I thought I *did* tell you that ...
Under paragraph (2), where you download JAXP/1.1, the last bullet point
reads:
* Make the xalan.jar file of this distribution available to Ant
(so that it can be used with the style tag) by copying it to
${ant.home}/lib.
Like:
Xalan could be downloaded from http://xml.apache.org/dist/xalan-j, the xalan.jar
file is located in the bin directory of the Xalan installation.
Which Xalan should be used? - I have used xalan-j_2_2_D10 -
I've only ever tested with the xalan.jar in JAXP/1.1. Your mileage may
vary.
Cheers
Jean-frederic
Craig
Ajp13 and setSoLinger
Hi, Did we really need to have a linger set in Ajp13 ? In Ajp13Interceptor there is a : super.setSoLinger(100); Which make us that we'll wait up to 100s before releasing the socket if data must be sent to remote (may be a restarted Apache...) or better drop the all wait before close : super.setSoLinger(0); Thanks for your ligth here, I'm still looking for the ajp13 bugs under heavy-load and couldn't reproduce these bug.
Re: Tomcat4-RC1: parse exception on taglibs
Please do report to the bug tracking system: http://nagoya.apache.org/bugzilla/ Craig On Thu, 13 Sep 2001, Rickard Öberg wrote: Date: Thu, 13 Sep 2001 17:18:36 +0200 From: Rickard Öberg [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Tomcat4-RC1: parse exception on taglibs Rickard Öberg wrote: Rickard Öberg wrote: I've finally managed to get Catalina working with JBoss (I had not set catalina.base, but no error was produced, just nothing happened). Anyway, the first thing I try is to deploy an app with a taglib JAR, with the TLD inside. But it seems like there's something wrong with the TLD parsing because I get this: org.xml.sax.SAXParseException: The markup in the document preceding the root element must be well-formed. And this happens no matter what I do with the actual TLD. Removing the taglib makes the WAR deploy properly, so it's definitely that which blows up. This apparently only happens when the WAR is deployed through the EmbeddedManager MBean. When deploying the same WAR, with the taglib, as a webapp by placing it in /webapps and running startup.bat, there is no error. Even more info. Setting debug level to high, and looking in the logs I found this: 2001-09-13 17:12:35 ContextConfig[/webwork]: URI='webwork', ResourcePath='/WEB-INF/lib/webwork.jar' 2001-09-13 17:12:35 ContextConfig[/webwork]: tldConfigJar(/WEB-INF/lib/webwork.jar): java.lang.IllegalStateException: zip file closed 2001-09-13 17:12:35 ContextConfig[/webwork]: tldConfigTld(/WEB-INF/lib/webwork.jar): org.xml.sax.SAXParseException: The markup in the document preceding the root element must be well-formed. This does not happen if the webapp is deployed in /webapps and I run Tomcat4 through startup.bat, only when I do it using the EmbeddedManager MBean. Any ideas? Should I just send this to the bug tracker and await any response? /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED]
FW: [Bug 3543] - pageContext.include() causes Illegal to flushwithin a custom tag
-- Forwarded Message From: Erich Meier [EMAIL PROTECTED] Organization: method park Date: Wed, 12 Sep 2001 11:16:18 +0200 To: [EMAIL PROTECTED] Subject: Re: [Bug 3543] - pageContext.include() causes Illegal to flush within a custom tag [EMAIL PROTECTED] wrote: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3543 [EMAIL PROTECTED] changed: What|Old Value |New Value Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2001-09-11 10:24 --- Up until 4.0-rc1, Tomcat 4 was incorrectly *not* doing the flush in it. In rc1, this was added to conform to the spec. Because it is a spec requirement, there is no way to turn it off. Just a moment: then the PageContext.include() method is just plain broken. I don't flush the output stream anywhere in my app. I just call PageContext.include() that results in that exception. I don't believe, that this is what's desired. Regards, Erich -- End of Forwarded Message
[DO NOT REPLY: Bug 3588] New: Make roles of a user available
PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL BE LOST SOMEWHERE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3588 *** shadow/3588 Thu Sep 13 09:19:30 2001 --- shadow/3588.tmp.8212Thu Sep 13 09:19:30 2001 *** *** 0 --- 1,29 + ++ + | Make roles of a user available | + ++ + |Bug #: 3588Product: Tomcat 4| + | Status: NEW Version: 4.0 Release Candidate 1 | + | Resolution:Platform: Other | + | Severity: Enhancement OS/Version: Other | + | Priority: Other Component: Catalina| + ++ + | Assigned To: [EMAIL PROTECTED]| + | Reported By: [EMAIL PROTECTED] | + | CC list: Cc: | + ++ + | URL: | + ++ + | DESCRIPTION | + Is there a reason (security or other) that the list/array of roles in a + GenericPrincipal is not accesible from other classes? + + In certain web applications we found it would be nececcary to tell ALL the + roles of a user not query each one for existence. Especially if the roles do + not follow a fixed scheme or change from user to user it is not always possible + to just take a known role and look for it. + This could be done by reading the xml/db storage of the roles but is not + efficiant because the roles ARE already there once the user is authenticated. + + This is partly the same for Tomcat 3.x, but as the new classes in Catalina are + more modular and sophisticated I assume such enhancement to be more useful for + the new generation of Tomcat.
RE: [PATCH] TC 4.0 build patch - not a joke
How does the RPM packaging deal with the fact that different JAR files
need to be loaded into different class loaders? If they are all under
/usr/share/java, I don't see how that can work.
The /usr/share/java is in our case only usefull when building
the RPM (.spec file). It's a BuildRequires Tag.
How does the RPM packaging deal with the fact that you might
want to use
different XML parsers inside Catalina (i.e. from serverl/lib) or in
webapps (from lib)?
A great pain here since we try to avoid installing too lib
allready present in system. In this case the RPM will
mark the libs as Required (Require Tag) and will do symlink
at install time
ln -s /usr/share/java/regexp.jar /var/tomcat4/server/lib/
to
* Declare the foo.jar properties based on foo.lib settings
A logical consequence of the previous goal, but ...
* Remove declarations and uses of any foo.home
properties that currently exist.
This one I have some heartburn with, because
it breaks backwards compatibility with environments
that depend on this approach (which is also used in
several other projects at Jakarta and elsewhere).
* Add support for JSSE jar files using the standard approach
I haven't caught up on the email thread and/or patches
about this, but agree in principle that it should follow
the same conventions as for other JAR dependencies.
Can we think of a way to accomplish what you would like for
RPMs that
does *not* create backwards incompatibilities? How about a
three-layer
model like this (for a package with JARs in the home directory):
property name=activation.home
value=/usr/local/jaf-1.0.1/
property name=activation.lib value=${activation.home}/
property name=activation.jar
value=${activation.lib}/activation.jar/
Ok for me that way.
OK, I will go ahead and modify the build scripts to follow
this pattern.
or like this for something with a nested lib directory:
property name=jsse.home
value=/usr/local/jsse-1.0.2/
property name=jsse.lib value=${jsse.home}/lib/
property name=jcert.jar
value=${jsse.lib}/jcert.jar/
That way, you could override at *any* of the three levels, without
breaking old scripts that rely on the foo.home approach.
What do you think?
Ok for me also like this, since I could override jsse.lib in command
line. We want to avoid having to patch all the build.xml.
I fully agree, but we'll need also another modification since
in catalina build you grab every .jar in for regexp and when
regexp is in /usr/share/java/, you copy just ALL system jars !!!
In my case not less that 80 jar (regexp, oro, jtopen, .)
I did a separate patch to catalina.bat/catalina.sh that
specifically adds
the JSSE classes.
For Regexp, if Jon would remove the version number from the JAR file I
wouldn't have to do that :-). Of all the dependencies in
Tomcat, this is
the *only* project that does versioning in the JAR file name.
We use it often on RPM packaging. I'm working on a Java Packaging
project where all jar have version inside :
-rw-r--r--1 root root 298756 Jun 11 12:10 ant-1.3.jar
lrwxrwxrwx1 root root 11 Jun 11 12:15 ant.jar -
ant-1.3.jar
-rw-r--r--1 root root 331767 Jun 11 11:40 antlr-2.7.1.jar
lrwxrwxrwx1 root root 15 Jun 11 11:50 antlr.jar -
antlr-2.7.1.jar
-rw-r--r--1 root root 379658 Jan 11 2001 ecs-1.4.1.jar
lrwxrwxrwx1 root root 13 Jan 18 2001 ecs.jar -
ecs-1.4.1.jar
-rw-r--r--1 root root66350 Jun 4 16:41
jakarta-oro-2.0.3.jar
lrwxrwxrwx1 root root 21 Jun 4 16:42 jakarta-oro.jar -
jakarta-oro-2.0.3.jar
-rw-r--r--1 root root25079 Jun 7 12:04
jakarta-regexp-1.2.jar
lrwxrwxrwx1 root root 22 Jan 18 2001 jakarta-regexp.jar
- jakarta-regexp-1.2.jar
-rw-r--r--1 root root92056 Jul 20 12:31 jdom-1.0b7.jar
lrwxrwxrwx1 root root 14 Jul 20 12:32 jdom.jar -
jdom-1.0b7.jar
-rw-r--r--1 root root 491517 Aug 29 16:30 jswat-1.3.3.jar
lrwxrwxrwx1 root root 15 Aug 29 17:44 jswat.jar -
jswat-1.3.3.jar
-rw-r--r--1 root root 108419 Jun 7 12:12 junit-3.7.jar
lrwxrwxrwx1 root root 13 Jun 7 11:43 junit.jar -
junit-3.7.jar
-rw-r--r--1 root root 226870 Feb 6 2001 mm.mysql-2.0.4.jar
lrwxrwxrwx1 root root 18 Feb 6 2001 mm.mysql.jar -
mm.mysql-2.0.4.jar
lrwxrwxrwx1 root root9 May 28 13:21 xalan-2.1.0.jar -
xalan.jar
-rw-r--r--1 root root 732330 May 28 18:23 xalan.jar
-rw-r--r--1 root root 1770662 Aug 23 16:02 xerces-1.4.3.jar
lrwxrwxrwx1 root root 16 Aug 23 16:03 xerces.jar -
xerces-1.4.3.jar
A another addon, be naming the name :
property name=regexp.name
value=jakarta-regexp-1.2.jar/
I'll make sure I cover
[DO NOT REPLY: Bug 3588] Make roles of a user available
PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL BE LOST SOMEWHERE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3588 *** shadow/3588 Thu Sep 13 09:19:30 2001 --- shadow/3588.tmp.8416Thu Sep 13 09:29:35 2001 *** *** 2,9 | Make roles of a user available | ++ |Bug #: 3588Product: Tomcat 4| ! | Status: NEW Version: 4.0 Release Candidate 1 | ! | Resolution:Platform: Other | | Severity: Enhancement OS/Version: Other | | Priority: Other Component: Catalina| ++ --- 2,9 | Make roles of a user available | ++ |Bug #: 3588Product: Tomcat 4| ! | Status: RESOLVEDVersion: 4.0 Release Candidate 1 | ! | Resolution: WONTFIXPlatform: Other | | Severity: Enhancement OS/Version: Other | | Priority: Other Component: Catalina| ++ *** *** 26,29 This is partly the same for Tomcat 3.x, but as the new classes in Catalina are more modular and sophisticated I assume such enhancement to be more useful for ! the new generation of Tomcat. --- 26,40 This is partly the same for Tomcat 3.x, but as the new classes in Catalina are more modular and sophisticated I assume such enhancement to be more useful for ! the new generation of Tomcat. ! ! --- Additional Comments From [EMAIL PROTECTED] 2001-09-13 09:29 --- ! Tomcat (all versions) conforms to the standard servlet APIs, and these APIs ! provide no mechanism to ask for all the roles a user has. Indeed, in some ! security environments, there *is* no single place where this information is ! accumulated, so it would not always be possible to implement such a method. ! ! You could certainly write a piece of code (installed *inside* Tomcat so that it ! has visibility to the needed classes) that makes this info available for the ! default Realm implementations, but it would be specific to Tomcat and not ! portable to any other container.
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources ResourceAttributes.java
remm01/09/13 09:31:42
Modified:catalina/src/share/org/apache/naming/resources
ResourceAttributes.java
Log:
- Make resource attributes non-final.
Revision ChangesPath
1.3 +5 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/ResourceAttributes.java
Index: ResourceAttributes.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/ResourceAttributes.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ResourceAttributes.java 2001/06/13 00:59:10 1.2
+++ ResourceAttributes.java 2001/09/13 16:31:42 1.3
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/ResourceAttributes.java,v
1.2 2001/06/13 00:59:10 remm Exp $
- * $Revision: 1.2 $
- * $Date: 2001/06/13 00:59:10 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/ResourceAttributes.java,v
1.3 2001/09/13 16:31:42 remm Exp $
+ * $Revision: 1.3 $
+ * $Date: 2001/09/13 16:31:42 $
*
*
*
@@ -83,9 +83,9 @@
* Attributes implementation.
*
* @author a href=mailto:[EMAIL PROTECTED];Remy Maucherat/a
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.3 $
*/
-public final class ResourceAttributes extends BasicAttributes {
+public class ResourceAttributes extends BasicAttributes {
// -- Constants
cvs commit: jakarta-tomcat-4.0 RELEASE-PLAN-4.0.txt
craigmcc01/09/13 09:39:52 Modified:.RELEASE-PLAN-4.0.txt Log: Latest status. Revision ChangesPath 1.14 +8 -15 jakarta-tomcat-4.0/RELEASE-PLAN-4.0.txt Index: RELEASE-PLAN-4.0.txt === RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-PLAN-4.0.txt,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- RELEASE-PLAN-4.0.txt 2001/09/12 05:25:58 1.13 +++ RELEASE-PLAN-4.0.txt 2001/09/13 16:39:52 1.14 @@ -1,4 +1,4 @@ -$Id: RELEASE-PLAN-4.0.txt,v 1.13 2001/09/12 05:25:58 craigmcc Exp $ +$Id: RELEASE-PLAN-4.0.txt,v 1.14 2001/09/13 16:39:52 craigmcc Exp $ Release Plan for Apache Tomcat 4.0 == @@ -46,8 +46,7 @@ Bugs That Must Be Addressed Before Final Release: -Catalina3511Line too long (currently WORKSFORME, awaiting reproducible -failure case) +Catalina3511Line too long (awaiting reproducible failure case) Catalina3515Process hanging after stopping Tomcat (awaiting reproducible failure case) @@ -56,8 +55,6 @@ Connectors 3476Cannot use other than default context when using mod_webapp -Connectors 3481Webapp socket leak when Apache process shuts down - Connectors 3509Apache 1.3.20 and mod_webapp and Tomcat 4b7 HANGS (likely to be the same issue as 1788) @@ -65,12 +62,13 @@ Connectors 3534File Upload doesn't work with Apache, mod_webapp, Tomcat 4 -Jasper 3079NullPointerException in JakartaCommentGenerator.generateEnd +Connectors 3574Basic authentication doesn't work through connector -Jasper 3127jsp:directive.include/ not supported (currently -WORKSFORME, awaiting reproducible failure case) +Jasper 3079NullPointerException in JakartaCommentGenerator.generateEnd +(awaiting reproducible failure case) -Jasper 3350Using XML syntax causes content rearrangement +Jasper 3127jsp:directive.include/ not supported (awaiting +reproducible failure case) Jasper 3529JSPC can't handle taglibs in RC1 (dup of 3235, includes a proposed patch) @@ -78,15 +76,10 @@ Nice To Have Fixes Before Final Release: --- - -Catalina3114Spanish translations of LocalString.properties files -(Japanese translations have also been provided) -Catalina3194Javadoc errors during build +Connectors 3570Info page reporting wrong server port Jasper 3055jsp:plugin tag ignores the name attribute - -Jasper 3195Javadoc errors during build Servletapi 3196Javadoc errors during build
Re: URI handling in tomcat 3.2.3
While 3.3 has this behavior as the default, it can be disabled in the config by: DecodeInterceptor safe=false / Since the release is scheduled to happen by the end of the month, you might consider jumping straight to 3.3. - Original Message - From: Lars Oppermann [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 3:00 AM Subject: URI handling in tomcat 3.2.3 Hi everyone, we were in progress of moving our project to tomcat 3.2.3 when we came accross the new handling of URIs (release-notes sec. 7.2). Since we are using the URI to transport other hierarchical information then filesystem paths, we have the feeling, that this kind of functionality belongs to the default servlet serving filesystem requests. Especialy the fact that %25, %2E, %2F and %5c inside an URI lead to a 404 error seems to somewhat strange. For Example: http://server/app/UCB/vnd.sun.star.hier:%2F/address/myresource would be rejected, before app has teh possibilty to look at the request and ...hier://address/myfile... would be normalized to hier:/address. We are perfectly aware of the security concerns behind these changes. However, they only apply when serving resources from the filesystem. A URL's path-components however are in no way bound to the representaion of filesystem paths.(After all, the U in URL stands for universal :) RFC 2396 states that '/' in an URI has another semantic meaning then %2F in an URI. The '/' seperates path-components, while the %2F means a slash character in a path-component. When such an URI is mapped to a filesystem this would denote a filename that contains a slash. When the system does not allow for such names, it is the responsebilty of the filesystem servlet to report an error (404 since such a file must not exist on unix for example). What are your opinions on this? Cheers -Lars -- -- Lars Oppermann [EMAIL PROTECTED] Sun Microsystems Software Engineer - Sun ONE Webtop Sachsenfeld 4 Phone: +49 40 23646 959D-20097 Hamburg Fax: +49 40 23646 550 http://www.sun.com/webtop ** This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
[PATCH][ Bug 3581] New: Ctx() : Error creating validation mark - java.io.FileNotFoundException
Let's try that again. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 5:52 AM Subject: [DO NOT REPLY: Bug 3581] New: Ctx() : Error creating validation mark - java.io.FileNotFoundException PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL BE LOST SOMEWHERE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3581 *** shadow/3581 Thu Sep 13 05:52:35 2001 --- shadow/3581.tmp.2600 Thu Sep 13 05:52:35 2001 *** *** 0 --- 1,67 + +=== =+ + | Ctx() : Error creating validation mark - java.io.FileNotFoundException| + +--- -+ + |Bug #: 3581Product: Tomcat 3 | + | Status: NEW Version: 3.3 Beta 2 | + | Resolution:Platform: PC | + | Severity: Normal OS/Version: Linux | + | Priority: Other Component: Unknown | + +--- -+ + | Assigned To: [EMAIL PROTECTED] | + | Reported By: [EMAIL PROTECTED] | + | CC list: Cc: | + +--- -+ + | URL: | + +=== =+ + | DESCRIPTION | + Hi, + + Since we've moved to tomcat 3.3-b1 tomcat 3.3-b2, we've been getting this + error into the logs : + + 2001-09-13 14:44:40 - SessionIdGenerator: Opening /dev/urandom + 2001-09-13 14:44:40 - ServerXmlReader: Config=$TOMCAT_HOME/conf/server.xml + 2001-09-13 14:44:40 - PathSetter: home=/var/tomcat + 2001-09-13 14:44:41 - ContextXmlReader: Context + config=$TOMCAT_HOME/conf/apps-kitu.xml + 2001-09-13 14:44:41 - AutoDeploy: Source or destination missing + 2001-09-13 14:44:41 - AutoWebApp: No autoconf directory /var/tomcat/modules + 2001-09-13 14:44:41 - AutoWebApp: Auto-Adding DEFAULT:/kitu-1.9.39 + 2001-09-13 14:44:41 - ContextManager: Tomcat configured and in stable state + 2001-09-13 14:44:41 - WorkDirSetup: Creating work dir + /var/tomcat/work/kitu.olympe.o2t/ROOT + 2001-09-13 14:44:41 - ContextManager: Adding kitu.olympe.o2t:/ROOT + 2001-09-13 14:44:41 - WorkDirSetup: Creating work dir + /var/tomcat/work/DEFAULT/kitu-1.9.39 + 2001-09-13 14:44:41 - ContextManager: Adding DEFAULT:/kitu-1.9.39 + 2001-09-13 14:44:41 - Ctx() : Validating web.xml + 2001-09-13 14:44:41 - Ctx() : Error creating validation mark - + java.io.FileNotFoundException: + /var/tomcat/work/kitu.olympe.o2t/ROOT/webxmlval.txt (No such file or directory) + at java.io.FileOutputStream.open(Native Method) + at java.io.FileOutputStream.init(FileOutputStream.java:108) + at java.io.FileOutputStream.init(FileOutputStream.java:68) + at java.io.FileOutputStream.init(FileOutputStream.java:138) + at + org.apache.tomcat.facade.WebXmlReader.processWebXmlFile(WebXmlReader.java:23 7) + at org.apache.tomcat.facade.WebXmlReader.contextInit(WebXmlReader.java:112) + at org.apache.tomcat.core.Context.init(Context.java:542) + at org.apache.tomcat.core.ContextManager.init(ContextManager.java:595) + at + org.apache.tomcat.startup.EmbededTomcat.initContextManager(EmbededTomcat.jav a:425) + at org.apache.tomcat.startup.EmbededTomcat.execute1(EmbededTomcat.java:546) + at org.apache.tomcat.startup.EmbededTomcat$1.run(EmbededTomcat.java:530) + at + org.apache.tomcat.util.compat.Jdk12Support$PrivilegedProxy.run(Jdk12Support. java:163) + at java.security.AccessController.doPrivileged(Native Method) + at + org.apache.tomcat.util.compat.Jdk12Support.doPrivileged(Jdk12Support.java:96 ) + at org.apache.tomcat.startup.EmbededTomcat.execute(EmbededTomcat.java:528) + at java.lang.reflect.Method.invoke(Native Method) + at + org.apache.tomcat.util.IntrospectionUtils.execute(IntrospectionUtils.java:87 ) + at org.apache.tomcat.startup.Main.execute(Main.java:307) + at org.apache.tomcat.startup.Main.main(Main.java:134) + + is it dangerous ? + How can we solve this ? ** This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition
RE: URI handling in tomcat 3.2.3
Lars, I agree with you. These encoded characters should be allowed in URIs and disallowing them is a hack. Like I said, I think the approach sucks. We were faced with a very serious security problem that had to be addressed very quickly and the decision was made that it was better to forbid certain 'odd' URIs in order to guarantee that resources that the specification *requires* to be protected were indeed protected. We need to look into how to solve the security problems without forbidden valid URIs, but right now I'm about the only one around paying much attention to the tomcat_32 branch so I don't know what kind of time frame wold be involved to get this changed. I do know that the solution will not be trivial. I mentioned Apache httpd only to show that our approach to this problem is in-line with that taken by other industry leading products. We should not (and I think have not) blindly follow httpd (it does a few other things that disagree with). Patches or discussion on how to go about fixing this are certainly welcome! Marc Saegesser -Original Message- From: Lars Oppermann [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 9:23 AM To: [EMAIL PROTECTED] Subject: Re: URI handling in tomcat 3.2.3 Hi Marc, Thanks for you reply... Marc Saegesser wrote: I agree that this URI handling sucks. I'm the one that committed the change that made it happen and I still think it sucks. However, allowing these encoded characters opens some very large security problems. From what I understand, these security problems are all related to mapping URIs to filesystem paths. So how do you feel about doing this processing in the filesystem (default) servlet? Also, even if TC 3.2.x allowed these characters, the resulting URL wouldn't be portable because several other web servers impose the same restrictions. [400 with Apache 1.3.19] I think, if it is possible to do this in a better way while keeping up the protection there is no reason for copying the behaviour of httpd. However, if those security implications can not be handled in the file servlet like I mentioned before, I'd need to do some more thinking on this point. If you need to pass this sort of data to a servlet (or CGI) the most portable way is to simply use a query string. Yes, that sounds like a straight-forward solution. Unfortunatly the service that gets excuted here will access some document and return an html representation. This document contains relative references within the hierarchy represented by the 'wrapped' URI. for this to work with a browser, the request URI has to be used, because the client can not resolve relative references inside a query (why should it) I belive that there are many more use-cases where using URIs to represent hierachical names that do not map to files is desirable, espacialy in a servlet environment. In httpd, which's main work consists of serving file-system resources this might be viewed differently Cheers, Lars -- -- Lars Oppermann [EMAIL PROTECTED] Sun Microsystems Software Engineer - Sun ONE Webtop Sachsenfeld 4 Phone: +49 40 23646 959D-20097 Hamburg Fax: +49 40 23646 550 http://www.sun.com/webtop
RE: [PATCH][Bug 3581] New: Ctx() : Error creating validation mark - java.io.FileNotFoundException
Hi Bill, Though this might fix the webxmlval.txt creation, I suspect it still might fail for the same reason, what ever it was, that caused: 2001-09-13 14:44:41 - WorkDirSetup: Creating work dir /var/tomcat/work/kitu.olympe.o2t/ROOT to not actually create the directory. I don't get time to play with Linux that often, so I'm not sure of the cause. Would this be a have to run as root or some other permissions issue? Cheers, Larry -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 12:55 PM To: [EMAIL PROTECTED] Subject: [PATCH][Bug 3581] New: Ctx() : Error creating validation mark - java.io.FileNotFoundException Make certain that the directory exists. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 5:52 AM Subject: [DO NOT REPLY: Bug 3581] New: Ctx() : Error creating validation mark - java.io.FileNotFoundException PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL BE LOST SOMEWHERE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3581 *** shadow/3581 Thu Sep 13 05:52:35 2001 --- shadow/3581.tmp.2600 Thu Sep 13 05:52:35 2001 *** *** 0 --- 1,67 + += == =+ + | Ctx() : Error creating validation mark - java.io.FileNotFoundException| + +- -- -+ + |Bug #: 3581Product: Tomcat 3 | + | Status: NEW Version: 3.3 Beta 2 | + | Resolution:Platform: PC | + | Severity: Normal OS/Version: Linux | + | Priority: Other Component: Unknown | + +- -- -+ + | Assigned To: [EMAIL PROTECTED] | + | Reported By: [EMAIL PROTECTED] | + | CC list: Cc: | + +- -- -+ + | URL: | + += == =+ + | DESCRIPTION | + Hi, + + Since we've moved to tomcat 3.3-b1 tomcat 3.3-b2, we've been getting this + error into the logs : + + 2001-09-13 14:44:40 - SessionIdGenerator: Opening /dev/urandom + 2001-09-13 14:44:40 - ServerXmlReader: Config=$TOMCAT_HOME/conf/server.xml + 2001-09-13 14:44:40 - PathSetter: home=/var/tomcat + 2001-09-13 14:44:41 - ContextXmlReader: Context + config=$TOMCAT_HOME/conf/apps-kitu.xml + 2001-09-13 14:44:41 - AutoDeploy: Source or destination missing + 2001-09-13 14:44:41 - AutoWebApp: No autoconf directory /var/tomcat/modules + 2001-09-13 14:44:41 - AutoWebApp: Auto-Adding DEFAULT:/kitu-1.9.39 + 2001-09-13 14:44:41 - ContextManager: Tomcat configured and in stable state + 2001-09-13 14:44:41 - WorkDirSetup: Creating work dir + /var/tomcat/work/kitu.olympe.o2t/ROOT + 2001-09-13 14:44:41 - ContextManager: Adding kitu.olympe.o2t:/ROOT + 2001-09-13 14:44:41 - WorkDirSetup: Creating work dir + /var/tomcat/work/DEFAULT/kitu-1.9.39 + 2001-09-13 14:44:41 - ContextManager: Adding DEFAULT:/kitu-1.9.39 + 2001-09-13 14:44:41 - Ctx() : Validating web.xml + 2001-09-13 14:44:41 - Ctx() : Error creating validation mark - + java.io.FileNotFoundException: + /var/tomcat/work/kitu.olympe.o2t/ROOT/webxmlval.txt (No such file or directory) + at java.io.FileOutputStream.open(Native Method) + at java.io.FileOutputStream.init(FileOutputStream.java:108) + at java.io.FileOutputStream.init(FileOutputStream.java:68) + at java.io.FileOutputStream.init(FileOutputStream.java:138) + at + org.apache.tomcat.facade.WebXmlReader.processWebXmlFile(WebXml Reader.java:23 7) + at org.apache.tomcat.facade.WebXmlReader.contextInit(WebXmlReader .java:112) + at org.apache.tomcat.core.Context.init(Context.java:542) + at org.apache.tomcat.core.ContextManager.init(ContextManager.java:595) + at + org.apache.tomcat.startup.EmbededTomcat.initContextManager(Emb ededTomcat.jav a:425) + at org.apache.tomcat.startup.EmbededTomcat.execute1(EmbededTomcat .java:546) + at org.apache.tomcat.startup.EmbededTomcat$1.run(EmbededTomcat.java:530) + at + org.apache.tomcat.util.compat.Jdk12Support$PrivilegedProxy.run (Jdk12Support. java:163) + at java.security.AccessController.doPrivileged(Native Method) + at + org.apache.tomcat.util.compat.Jdk12Support.doPrivileged(Jdk12S upport.java:96 ) +
RE: URI handling in tomcat 3.2.3
Be aware that setting this false will open Tomcat 3.3 to the vulnerability it is intended to prevent. Serving JSP source and bypassing security constraints are among the problems. Detecting potential URL trickery early in the handling provides the most reliable fix. Allowing unsafe URL's past this point means that many modules would need to be updated to detect the trickery. StaticInterceptor, which serves static resources, would only be the first, and perhaps easiest module to fix. Our assessment was that this approach wasn't practical to implement. Cheers, Larry -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 12:36 PM To: [EMAIL PROTECTED] Subject: Re: URI handling in tomcat 3.2.3 While 3.3 has this behavior as the default, it can be disabled in the config by: DecodeInterceptor safe=false / Since the release is scheduled to happen by the end of the month, you might consider jumping straight to 3.3. - Original Message - From: Lars Oppermann [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 3:00 AM Subject: URI handling in tomcat 3.2.3 Hi everyone, we were in progress of moving our project to tomcat 3.2.3 when we came accross the new handling of URIs (release-notes sec. 7.2). Since we are using the URI to transport other hierarchical information then filesystem paths, we have the feeling, that this kind of functionality belongs to the default servlet serving filesystem requests. Especialy the fact that %25, %2E, %2F and %5c inside an URI lead to a 404 error seems to somewhat strange. For Example: http://server/app/UCB/vnd.sun.star.hier:%2F/address/myresource would be rejected, before app has teh possibilty to look at the request and ...hier://address/myfile... would be normalized to hier:/address. We are perfectly aware of the security concerns behind these changes. However, they only apply when serving resources from the filesystem. A URL's path-components however are in no way bound to the representaion of filesystem paths.(After all, the U in URL stands for universal :) RFC 2396 states that '/' in an URI has another semantic meaning then %2F in an URI. The '/' seperates path-components, while the %2F means a slash character in a path-component. When such an URI is mapped to a filesystem this would denote a filename that contains a slash. When the system does not allow for such names, it is the responsebilty of the filesystem servlet to report an error (404 since such a file must not exist on unix for example). What are your opinions on this? Cheers -Lars -- -- Lars Oppermann [EMAIL PROTECTED] Sun Microsystems Software Engineer - Sun ONE Webtop Sachsenfeld 4 Phone: +49 40 23646 959 D-20097 Hamburg Fax: +49 40 23646 550 http://www.sun.com/webtop ** This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
Re: [PATCH][Bug 3581] New: Ctx() : Error creating validation mark - java.io.FileNotFoundException
You're right, I didn't look closely enough. WorkDirSetup claims to have created the directory already. In that case, it is most likely a permissions problem. The easiest is to do rm -rf $TOMCAT_HOME/work and re-start tomcat. This is especially true since B2 is the first one to get the default charset right on JSP pages (so you likely want to recompile anyway). Of course, the answer to is it dangerous is no (except in so far as creating e.g. JSP classes will likely fail). In and of itself it only means that it will validating-parse the web.xml file if/when the context is re-loaded (costing you a fraction of a second). - Original Message - From: Larry Isaacs [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 11:00 AM Subject: RE: [PATCH][Bug 3581] New: Ctx() : Error creating validation mark - java.io.FileNotFoundException Hi Bill, Though this might fix the webxmlval.txt creation, I suspect it still might fail for the same reason, what ever it was, that caused: 2001-09-13 14:44:41 - WorkDirSetup: Creating work dir /var/tomcat/work/kitu.olympe.o2t/ROOT to not actually create the directory. I don't get time to play with Linux that often, so I'm not sure of the cause. Would this be a have to run as root or some other permissions issue? Cheers, Larry -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 12:55 PM To: [EMAIL PROTECTED] Subject: [PATCH][Bug 3581] New: Ctx() : Error creating validation mark - java.io.FileNotFoundException Make certain that the directory exists. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 5:52 AM Subject: [DO NOT REPLY: Bug 3581] New: Ctx() : Error creating validation mark - java.io.FileNotFoundException PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL BE LOST SOMEWHERE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3581 *** shadow/3581 Thu Sep 13 05:52:35 2001 --- shadow/3581.tmp.2600 Thu Sep 13 05:52:35 2001 *** *** 0 --- 1,67 + += == =+ + | Ctx() : Error creating validation mark - java.io.FileNotFoundException| + +- -- -+ + |Bug #: 3581Product: Tomcat 3 | + | Status: NEW Version: 3.3 Beta 2 | + | Resolution:Platform: PC | + | Severity: Normal OS/Version: Linux | + | Priority: Other Component: Unknown | + +- -- -+ + | Assigned To: [EMAIL PROTECTED] | + | Reported By: [EMAIL PROTECTED] | + | CC list: Cc: | + +- -- -+ + | URL: | + += == =+ + | DESCRIPTION | + Hi, + + Since we've moved to tomcat 3.3-b1 tomcat 3.3-b2, we've been getting this + error into the logs : + + 2001-09-13 14:44:40 - SessionIdGenerator: Opening /dev/urandom + 2001-09-13 14:44:40 - ServerXmlReader: Config=$TOMCAT_HOME/conf/server.xml + 2001-09-13 14:44:40 - PathSetter: home=/var/tomcat + 2001-09-13 14:44:41 - ContextXmlReader: Context + config=$TOMCAT_HOME/conf/apps-kitu.xml + 2001-09-13 14:44:41 - AutoDeploy: Source or destination missing + 2001-09-13 14:44:41 - AutoWebApp: No autoconf directory /var/tomcat/modules + 2001-09-13 14:44:41 - AutoWebApp: Auto-Adding DEFAULT:/kitu-1.9.39 + 2001-09-13 14:44:41 - ContextManager: Tomcat configured and in stable state + 2001-09-13 14:44:41 - WorkDirSetup: Creating work dir + /var/tomcat/work/kitu.olympe.o2t/ROOT + 2001-09-13 14:44:41 - ContextManager: Adding kitu.olympe.o2t:/ROOT + 2001-09-13 14:44:41 - WorkDirSetup: Creating work dir + /var/tomcat/work/DEFAULT/kitu-1.9.39 + 2001-09-13 14:44:41 - ContextManager: Adding DEFAULT:/kitu-1.9.39 + 2001-09-13 14:44:41 - Ctx() : Validating web.xml + 2001-09-13 14:44:41 - Ctx() : Error creating validation mark - + java.io.FileNotFoundException: + /var/tomcat/work/kitu.olympe.o2t/ROOT/webxmlval.txt (No such file or directory) + at java.io.FileOutputStream.open(Native Method) + at java.io.FileOutputStream.init(FileOutputStream.java:108) + at java.io.FileOutputStream.init(FileOutputStream.java:68) +
Re: cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docstomcat-docs.xsl
on 9/12/01 7:52 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Remove a width=100% setting from the table generated for attributes lists, to see if that helps avoid problems where the right side of the documentation pages are cut off for some users. Nope. That problem happens as a result of the pre/pre tags which get generated because of the source/source tags. The table size won't affect the fact that pre/pre tags respect whitespace. I haven't found a good solution for this yet other than to suggest changing the side navigation to be at the top (and copied to the bottom for convenience). -jon
RE: Remaining Tomcat 3.3 Issues
7. Evaluate whether anything should be done to deal with the use of non-thread-safe DateFormat and related classes. The Date used in Http10 connector response, is allready handled by stuff I commited some time ago which use a speed hack and return allready processed date String if it was processed in the same second removing need to use SimpeDateFormat at each hit. format1123() in org\apache\tomcat\util\buf\DateTool But the request.getDateHeader(Date) in facade is still using DateTool.parseDate(value) in DateTool which need to be synchronized. Question: should we sync in facade or in DateTool ? 1798 Tomcat 3.2.2b5 with Apache and ajp13 stops responding after This one is very difficult to reproduce (I never succeed). We need more information on configuration. May be related with CHUNKED. I'd like to see bug reporter to test against latest TC 3.3 8. We need to remove or optionally disable the shutdown support in Ajp13Interceptor. This allows configuring a password protected Ajp12Interceptor shutdown to be the only shutdown available. Having Ajp13 or Ajp12 shutdown from a distant machine is dangerous. We should use Ajp13 as link between web-server and tomcat and use Ajp12 accepting only from localhost. 9. Some files under src/native have embedded CR's, i.e. Unix files would have CRLF and Windows files would have CRCRLF's. These need to be fixed. Couldn't we say that ALL src in native will be only in Unix mode ? 11. Make sure we are okay with mod_jk not supporting Apache's rewrite in Tomcat 3.3's mod_jk. I'm fine with not supporting it, but I want to include some justification in the documentation to avoid some of the why don't you questions. As said Costin, making mod_jk using uri or unparsed_uri is not difficult, but we have here 2 situations. Strict respect of spec (unparsed) or mod_rewrite compatibility. Why not let the final user decide and create a new JkOptions directive (easy). ie : JkOptions +ForwardUnparsedURI = strict spec respect JkOptions -ForwardUnparsedURI = rewrite compatibility 111 after httpd reload mod_jk fails to find a worker BugRat Repo Didn't know this one but must be easy to handle 2333 Nor Oth PC [EMAIL PROTECTED] NEW HTTP Reason will be destroyed in header using AJP12 Some patch was sent some time ago and even if AJP12 is somewhat deprecated, I should try to commit the provided patch. 2550 Ajp13 Connection hanging on static content. Should take a look at this one even. Majority of users use Apache to handle static data but it must be investigated (I) 2927 Nor Oth PC [EMAIL PROTECTED] NEW ArrayIndexOutOfBoundsException when accessing ajp13 I take care of this I will update the RELEASE-PLAN-3.3 tomorrow with the previous schedule and these issues, updating as needed base on discussion that occurs before then. These issues are the driving force for when RC1 and RC2 can be built and posted. The dates previously voted on are still the targets, but may slip as needed to deal with these issues. I plan to go through (possibly with some help) all the Tomcat3 bugs. Where I find bugs for earlier Tomcat's that have not been addressed for Tomcat 3.3, I will do what I can to address them. I will prepare and post a list of all bugs and there status in Tomcat 3.3. If I don't have this list ready prior to RC2, I will still build and post RC2, but will not start the 7 day voting deadline clock until this list is posted. If a showstopper appears from this scan (which I don't expect to happen) I will post this issue and plan on another release candidate. Let's go
mod_webapp/SSL and TC 4.0
Hi to all, I take a look at mod_webapp and warp java, and didn't find reference to SSL informations forwarded from WebServer. Should it be fixed before release since it may break the spec ? I could grab code from mod_jk to support that, but I'm pretty busy with my day work and mod_jk fixes for TC 3.3 release. Maybe Pier, JF or Ryan could grab existing code from mod_jk and use it in mod_webapp ? It should works at least for Apache 1.3/2.0. To follow the Servlet 2.3, take a look at jk in J-T-C since it also handle the SSL_KEY_SIZE. - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
mod_jk using warp protocol ?
What about adding warp protocol to mod_jk and may be adding with functionnalities from ajp14 ? Of course in J-T-C, since mod_jk in J-T must be freezed. ajp14 and warp are very similar, they use the same (it seems) logon system (using md5), and differents protocol encoding but since ajp14 is still experimental, it could be changed in using warp packet system. I've got some questions here : In ajp14, the JkAutoMount was designed to help web-server knows about URL/URI handled by the remote tomcat (examples/*.jsp, examples/servlet/*). JkAutoMount * myworker This allow us to remove the need of configuring these mappings in httpd.conf. More in ajp14, the AutoMount key is the Virtual, if a Virtual section is present in Tomcat we could be sure that a Virtual section in Web-Server will get mappings only for the corresponding Virtual of Tomcat. Virtual myhost1 JkAutoMount myhost1 myworker /Virtual Did there is the same strategy in mod_webapp ? May be the local Apache Gurus (JF, Ryan) could tell us if we could avoid to set myhost1 in Virtual ? The VirtualHostName must be present somewhere in Apache Recs... - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
[DO NOT REPLY: Bug 3591] New: HttpServletResponse.sendError() and sendRedirect() should commit the response
PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL BE LOST SOMEWHERE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3591 *** shadow/3591 Thu Sep 13 12:25:10 2001 --- shadow/3591.tmp.19951 Thu Sep 13 12:25:10 2001 *** *** 0 --- 1,19 + ++ + | HttpServletResponse.sendError() and sendRedirect() should commit the respo | + ++ + |Bug #: 3591Product: Tomcat 4| + | Status: NEW Version: 4.0 Release Candidate 1 | + | Resolution:Platform: All | + | Severity: MajorOS/Version: All | + | Priority: Other Component: Catalina| + ++ + | Assigned To: [EMAIL PROTECTED]| + | Reported By: [EMAIL PROTECTED] | + | CC list: Cc: | + ++ + | URL: | + ++ + | DESCRIPTION | + According to Servlet 2.3 Section 5,3, calling sendRedirect() or sendError() + should commit the response. This code has been commented out in the + implementation with a FIXME comment that needs to be addressed.
Re: Remaining Tomcat 3.3 Issues
I interpreted #111 to be the graceful restart clean-up problem that was fixed some months ago. - Original Message - From: GOMEZ Henri [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 12:13 PM Subject: RE: Remaining Tomcat 3.3 Issues 7. Evaluate whether anything should be done to deal with the use of non-thread-safe DateFormat and related classes. The Date used in Http10 connector response, is allready handled by stuff I commited some time ago which use a speed hack and return allready processed date String if it was processed in the same second removing need to use SimpeDateFormat at each hit. format1123() in org\apache\tomcat\util\buf\DateTool But the request.getDateHeader(Date) in facade is still using DateTool.parseDate(value) in DateTool which need to be synchronized. Question: should we sync in facade or in DateTool ? 1798 Tomcat 3.2.2b5 with Apache and ajp13 stops responding after This one is very difficult to reproduce (I never succeed). We need more information on configuration. May be related with CHUNKED. I'd like to see bug reporter to test against latest TC 3.3 8. We need to remove or optionally disable the shutdown support in Ajp13Interceptor. This allows configuring a password protected Ajp12Interceptor shutdown to be the only shutdown available. Having Ajp13 or Ajp12 shutdown from a distant machine is dangerous. We should use Ajp13 as link between web-server and tomcat and use Ajp12 accepting only from localhost. 9. Some files under src/native have embedded CR's, i.e. Unix files would have CRLF and Windows files would have CRCRLF's. These need to be fixed. Couldn't we say that ALL src in native will be only in Unix mode ? 11. Make sure we are okay with mod_jk not supporting Apache's rewrite in Tomcat 3.3's mod_jk. I'm fine with not supporting it, but I want to include some justification in the documentation to avoid some of the why don't you questions. As said Costin, making mod_jk using uri or unparsed_uri is not difficult, but we have here 2 situations. Strict respect of spec (unparsed) or mod_rewrite compatibility. Why not let the final user decide and create a new JkOptions directive (easy). ie : JkOptions +ForwardUnparsedURI = strict spec respect JkOptions -ForwardUnparsedURI = rewrite compatibility 111 after httpd reload mod_jk fails to find a worker BugRat Repo Didn't know this one but must be easy to handle 2333 Nor Oth PC [EMAIL PROTECTED] NEW HTTP Reason will be destroyed in header using AJP12 Some patch was sent some time ago and even if AJP12 is somewhat deprecated, I should try to commit the provided patch. 2550 Ajp13 Connection hanging on static content. Should take a look at this one even. Majority of users use Apache to handle static data but it must be investigated (I) 2927 Nor Oth PC [EMAIL PROTECTED] NEW ArrayIndexOutOfBoundsException when accessing ajp13 I take care of this I will update the RELEASE-PLAN-3.3 tomorrow with the previous schedule and these issues, updating as needed base on discussion that occurs before then. These issues are the driving force for when RC1 and RC2 can be built and posted. The dates previously voted on are still the targets, but may slip as needed to deal with these issues. I plan to go through (possibly with some help) all the Tomcat3 bugs. Where I find bugs for earlier Tomcat's that have not been addressed for Tomcat 3.3, I will do what I can to address them. I will prepare and post a list of all bugs and there status in Tomcat 3.3. If I don't have this list ready prior to RC2, I will still build and post RC2, but will not start the 7 day voting deadline clock until this list is posted. If a showstopper appears from this scan (which I don't expect to happen) I will post this issue and plan on another release candidate. Let's go ** This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
Re: cvs commit: jakarta-tomcat-4.0/catalina build.xml
On 13 Sep 2001 [EMAIL PROTECTED] wrote: Date: 13 Sep 2001 18:56:11 - From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: cvs commit: jakarta-tomcat-4.0/catalina build.xml glenn 01/09/13 11:56:11 Modified:catalina build.xml Log: Update build, Copy the jndi, activation, and mail jar files only if they are present -1 The jndi.jar file is required to run on JDK 1.2, and activation.jar/mail.jar are now required by the standard resource factory and corresponding example program. Craig
RE: Remaining Tomcat 3.3 Issues
-Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 3:14 PM To: [EMAIL PROTECTED] Subject: RE: Remaining Tomcat 3.3 Issues 7. Evaluate whether anything should be done to deal with the use of non-thread-safe DateFormat and related classes. The Date used in Http10 connector response, is allready handled by stuff I commited some time ago which use a speed hack and return allready processed date String if it was processed in the same second removing need to use SimpeDateFormat at each hit. format1123() in org\apache\tomcat\util\buf\DateTool But the request.getDateHeader(Date) in facade is still using DateTool.parseDate(value) in DateTool which need to be synchronized. Question: should we sync in facade or in DateTool ? My initial preference is in DateTool. However, I may be unaware of some pro's or con's. 1798 Tomcat 3.2.2b5 with Apache and ajp13 stops responding after This one is very difficult to reproduce (I never succeed). We need more information on configuration. May be related with CHUNKED. I'd like to see bug reporter to test against latest TC 3.3 Did your attempts include 3.2.2 or 3.2.3. If so, I'll resolve the bug reports as worksforme. Otherwise, I'll just add a note that it couldn't be reproduced in 3.3 and is assumed fixed. 8. We need to remove or optionally disable the shutdown support in Ajp13Interceptor. This allows configuring a password protected Ajp12Interceptor shutdown to be the only shutdown available. Having Ajp13 or Ajp12 shutdown from a distant machine is dangerous. We should use Ajp13 as link between web-server and tomcat and use Ajp12 accepting only from localhost. I'll take this as a vote to remove the shutdown support from Ajp13 and not provide an option. I'm not sure if you are implying additional changes by your statement shutdown from a distant machine is dangerous. 9. Some files under src/native have embedded CR's, i.e. Unix files would have CRLF and Windows files would have CRCRLF's. These need to be fixed. Couldn't we say that ALL src in native will be only in Unix mode ? I need CRLF for building on Windows. It appears that some files were checked in from *nix containing CR's that were not stripped during the commit. When I checkout or update from Windows, CVS still adds a CR in front of all LFs. The result is CRCRLF which Dev Studio wants to fix. I'd just like the source to be clean for final release. I'm not sure what happens on *nix systems when they encounter a CR. 11. Make sure we are okay with mod_jk not supporting Apache's rewrite in Tomcat 3.3's mod_jk. I'm fine with not supporting it, but I want to include some justification in the documentation to avoid some of the why don't you questions. As said Costin, making mod_jk using uri or unparsed_uri is not difficult, but we have here 2 situations. Strict respect of spec (unparsed) or mod_rewrite compatibility. Why not let the final user decide and create a new JkOptions directive (easy). ie : JkOptions +ForwardUnparsedURI = strict spec respect JkOptions -ForwardUnparsedURI = rewrite compatibility I'm +1 for user configurability. I would prefer strict compliance to be the default. 111 after httpd reload mod_jk fails to find a worker BugRat Repo Didn't know this one but must be easy to handle I assume this is likely fixed since the bug is very old. I just prefer someone more familiar with the history of mod_jk to say so. 2333 Nor Oth PC [EMAIL PROTECTED] NEW HTTP Reason will be destroyed in header using AJP12 Some patch was sent some time ago and even if AJP12 is somewhat deprecated, I should try to commit the provided patch. I scanned but didn't have much time assess applying the supplied patch. My main reservation is that I'm not sure if IIS or netscape is multi-threaded, in which case the static buffer could do more harm than good. 2550 Ajp13 Connection hanging on static content. Should take a look at this one even. Majority of users use Apache to handle static data but it must be investigated (I) My understanding is that Ajp13 keeps the connection open, so a Connection reset by peer sounds bad to me. Do you know if this issue might have been fixed since the bug was opened? I though there was some work on re-establishing the connection. 2927 Nor Oth PC [EMAIL PROTECTED] NEW ArrayIndexOutOfBoundsException when accessing ajp13 I take care of this If this is complicated or potentially unsafe, I'm fine with resolving as wontfix. Larry
RE: Remaining Tomcat 3.3 Issues
Thanks. Do you know if just 3.3 was affected or 3.2.x as well? If you can give me a clue as to what was changed, I can try to determine this. Larry -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 3:15 PM To: [EMAIL PROTECTED] Subject: Re: Remaining Tomcat 3.3 Issues I interpreted #111 to be the graceful restart clean-up problem that was fixed some months ago. - Original Message - From: GOMEZ Henri [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 12:13 PM Subject: RE: Remaining Tomcat 3.3 Issues 7. Evaluate whether anything should be done to deal with the use of non-thread-safe DateFormat and related classes. The Date used in Http10 connector response, is allready handled by stuff I commited some time ago which use a speed hack and return allready processed date String if it was processed in the same second removing need to use SimpeDateFormat at each hit. format1123() in org\apache\tomcat\util\buf\DateTool But the request.getDateHeader(Date) in facade is still using DateTool.parseDate(value) in DateTool which need to be synchronized. Question: should we sync in facade or in DateTool ? 1798 Tomcat 3.2.2b5 with Apache and ajp13 stops responding after This one is very difficult to reproduce (I never succeed). We need more information on configuration. May be related with CHUNKED. I'd like to see bug reporter to test against latest TC 3.3 8. We need to remove or optionally disable the shutdown support in Ajp13Interceptor. This allows configuring a password protected Ajp12Interceptor shutdown to be the only shutdown available. Having Ajp13 or Ajp12 shutdown from a distant machine is dangerous. We should use Ajp13 as link between web-server and tomcat and use Ajp12 accepting only from localhost. 9. Some files under src/native have embedded CR's, i.e. Unix files would have CRLF and Windows files would have CRCRLF's. These need to be fixed. Couldn't we say that ALL src in native will be only in Unix mode ? 11. Make sure we are okay with mod_jk not supporting Apache's rewrite in Tomcat 3.3's mod_jk. I'm fine with not supporting it, but I want to include some justification in the documentation to avoid some of the why don't you questions. As said Costin, making mod_jk using uri or unparsed_uri is not difficult, but we have here 2 situations. Strict respect of spec (unparsed) or mod_rewrite compatibility. Why not let the final user decide and create a new JkOptions directive (easy). ie : JkOptions +ForwardUnparsedURI = strict spec respect JkOptions -ForwardUnparsedURI = rewrite compatibility 111 after httpd reload mod_jk fails to find a worker BugRat Repo Didn't know this one but must be easy to handle 2333 Nor Oth PC [EMAIL PROTECTED] NEW HTTP Reason will be destroyed in header using AJP12 Some patch was sent some time ago and even if AJP12 is somewhat deprecated, I should try to commit the provided patch. 2550 Ajp13 Connection hanging on static content. Should take a look at this one even. Majority of users use Apache to handle static data but it must be investigated (I) 2927 Nor Oth PC [EMAIL PROTECTED] NEW ArrayIndexOutOfBoundsException when accessing ajp13 I take care of this I will update the RELEASE-PLAN-3.3 tomorrow with the previous schedule and these issues, updating as needed base on discussion that occurs before then. These issues are the driving force for when RC1 and RC2 can be built and posted. The dates previously voted on are still the targets, but may slip as needed to deal with these issues. I plan to go through (possibly with some help) all the Tomcat3 bugs. Where I find bugs for earlier Tomcat's that have not been addressed for Tomcat 3.3, I will do what I can to address them. I will prepare and post a list of all bugs and there status in Tomcat 3.3. If I don't have this list ready prior to RC2, I will still build and post RC2, but will not start the 7 day voting deadline clock until this list is posted. If a showstopper appears from this scan (which I don't expect to happen) I will post this issue and plan on another release candidate. Let's go ** This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential
RE: Remaining Tomcat 3.3 Issues
I need CRLF for building on Windows. It appears that some files were checked in from *nix containing CR's that were not stripped during the commit. When I checkout or update from Windows, CVS still adds a CR in front of all LFs. The result is CRCRLF which Dev Studio wants to fix. I'd just like the source to be clean for final release. I'm not sure what happens on *nix systems when they encounter a CR. This question pops up from time to time.. The problem is in CVS, somebody has co the sources from a windows machine and committed from *nix system, or reversed ( i think however that co'ing in *nix and commiting from windows is worse ) .. this a known problem and the culprit is the CVS itself.., that stores the files without the CR ever, and if the co machine is win32 it adds automatically the CR.. The solution is so easy make sure that the file in question has the correct line endings for the system where it is and commit from there, CVS will take care.., and every one that gets the code form CVs will get the correct line endings. Another problem is to have them bundled correctly in the src distribution, or we need 2 distributions ( win32 and *nix) or someone will complaint , if the dist is done in win32 , *nix people will scream , if reversed the other :).. Saludos , Ignacio J. Ortega
RE: Remaining Tomcat 3.3 Issues
Another problem is to have them bundled correctly in the src distribution, or we need 2 distributions ( win32 and *nix) or someone will complaint , if the dist is done in win32 , *nix people will scream , if reversed the other :).. In the Tomcat 3.3 releases .zip files will contain files with CRLF's and .tar.gz files will contain files with LF's, excluding binary files of course. One exception is the .sh files within the .zip distribution. These have just LF's. There may be other exceptions that I don't recall at the moment. Hopefully this will satisfy the majority of users. Larry
Re: Remaining Tomcat 3.3 Issues
I don't think they ever got back-ported to 3.2.x, but I don't know for sure. The files include: mod_jk.c[R1.9],jk_ajp13_worker.c[R1.8]. You'll have to hunt down Mike Anderson for the details. I just remember the commits. - Original Message - From: Larry Isaacs [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 1:06 PM Subject: RE: Remaining Tomcat 3.3 Issues Thanks. Do you know if just 3.3 was affected or 3.2.x as well? If you can give me a clue as to what was changed, I can try to determine this. Larry -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 3:15 PM To: [EMAIL PROTECTED] Subject: Re: Remaining Tomcat 3.3 Issues I interpreted #111 to be the graceful restart clean-up problem that was fixed some months ago. - Original Message - From: GOMEZ Henri [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 12:13 PM Subject: RE: Remaining Tomcat 3.3 Issues 7. Evaluate whether anything should be done to deal with the use of non-thread-safe DateFormat and related classes. The Date used in Http10 connector response, is allready handled by stuff I commited some time ago which use a speed hack and return allready processed date String if it was processed in the same second removing need to use SimpeDateFormat at each hit. format1123() in org\apache\tomcat\util\buf\DateTool But the request.getDateHeader(Date) in facade is still using DateTool.parseDate(value) in DateTool which need to be synchronized. Question: should we sync in facade or in DateTool ? 1798 Tomcat 3.2.2b5 with Apache and ajp13 stops responding after This one is very difficult to reproduce (I never succeed). We need more information on configuration. May be related with CHUNKED. I'd like to see bug reporter to test against latest TC 3.3 8. We need to remove or optionally disable the shutdown support in Ajp13Interceptor. This allows configuring a password protected Ajp12Interceptor shutdown to be the only shutdown available. Having Ajp13 or Ajp12 shutdown from a distant machine is dangerous. We should use Ajp13 as link between web-server and tomcat and use Ajp12 accepting only from localhost. 9. Some files under src/native have embedded CR's, i.e. Unix files would have CRLF and Windows files would have CRCRLF's. These need to be fixed. Couldn't we say that ALL src in native will be only in Unix mode ? 11. Make sure we are okay with mod_jk not supporting Apache's rewrite in Tomcat 3.3's mod_jk. I'm fine with not supporting it, but I want to include some justification in the documentation to avoid some of the why don't you questions. As said Costin, making mod_jk using uri or unparsed_uri is not difficult, but we have here 2 situations. Strict respect of spec (unparsed) or mod_rewrite compatibility. Why not let the final user decide and create a new JkOptions directive (easy). ie : JkOptions +ForwardUnparsedURI = strict spec respect JkOptions -ForwardUnparsedURI = rewrite compatibility 111 after httpd reload mod_jk fails to find a worker BugRat Repo Didn't know this one but must be easy to handle 2333 Nor Oth PC [EMAIL PROTECTED] NEW HTTP Reason will be destroyed in header using AJP12 Some patch was sent some time ago and even if AJP12 is somewhat deprecated, I should try to commit the provided patch. 2550 Ajp13 Connection hanging on static content. Should take a look at this one even. Majority of users use Apache to handle static data but it must be investigated (I) 2927 Nor Oth PC [EMAIL PROTECTED] NEW ArrayIndexOutOfBoundsException when accessing ajp13 I take care of this I will update the RELEASE-PLAN-3.3 tomorrow with the previous schedule and these issues, updating as needed base on discussion that occurs before then. These issues are the driving force for when RC1 and RC2 can be built and posted. The dates previously voted on are still the targets, but may slip as needed to deal with these issues. I plan to go through (possibly with some help) all the Tomcat3 bugs. Where I find bugs for earlier Tomcat's that have not been addressed for Tomcat 3.3, I will do what I can to address them. I will prepare and post a list of all bugs and there status in Tomcat 3.3. If I don't have this list ready prior to RC2, I will still build and post RC2, but will not start the 7 day voting deadline clock until this list is posted. If a showstopper appears from this scan (which I don't expect to happen) I will post this issue and plan on another release candidate. Let's go ** This message is intended only for the use of the person(s) listed above
Re: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3
At least with isTomcatAuth=false and mod_ssl configured properly, 274 should work now. I don't have a system configured to be able to test it (e.g. no user certs), but mod_ssl will set REMOTE_USER to the CN, and Ajp13 will allocate a SimplePrincipal to match the REMOTE_USER. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 12:57 PM Subject: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3 larryi 01/09/13 12:57:38 Modified:.RELEASE-PLAN-3.3 Log: Update to the release plan. Also: Bugs 3572 and 3577 have been added as required for RC1 Bug 3581 has been added as required for RC2 Bug 1482 has been moved to the fixed in 3.3 catagory Revision ChangesPath 1.13 +122 -5jakarta-tomcat/RELEASE-PLAN-3.3 Index: RELEASE-PLAN-3.3 === RCS file: /home/cvs/jakarta-tomcat/RELEASE-PLAN-3.3,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- RELEASE-PLAN-3.3 2001/06/21 04:42:08 1.12 +++ RELEASE-PLAN-3.3 2001/09/13 19:57:38 1.13 @@ -147,16 +147,133 @@ 1. TBD... +Tomcat 3.3 Release Candidate 1: + + Code Freeze/Tag Date: Sept 14, 2001 + Release Manager: Larry Isaacs + + This release should be used to verify that we really are + at release quality. It should include any fixes needed + to reach that status. Documentation updates may continue + after this release. + +To Be Addressed for RC1: + +1. HttpSessionFacade.setAttribute() isn't synchronized. If a second request +called setAttribute() after this request's removeAttribute() and before +realSession.setAttribute(), the second request's value would be overwritten +without an valueUnbound() being called. + +2. Evaluate Tomcat 3.3's vulnerability to Double Checked Locking. This +is referred to in Bug #177. See: +http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html +for details. I think ServletHandler.init() is currently subject to this +vulnerability. + +3. The spec doesn't address whether a the form-login-page and form-error-page +should be excluded from the security-constraint, but it makes sense that +it should. It might be best to postpone this. + +4. Address user authentication via Ajp12 and Ajp13. Ajp12 has a test for +isTomcatAuthentication() to see if req.setRemoteUser() should be called. +I think Ajp13 doesn't have this yet and probably should. Also, if the +user is anonymous, i.e. user = , should we call req.setRemoteUser() +with this value? This prevents Tomcat's normal authentication from being +triggered. + +5. If a error handler is not found for an exception, check the root cause +as well if it is a ServletException. This is mentioned in Bug 3233. I think +it would be a good idea to apply this. I don't think we are prohibited +by the spec. We could add an option to be safe if there is concern. + +6. StaticInterceptor is missing a localization enhancement added to +Tomcat 3.2.x. Should this enhancement be ported to Tomcat 3.3? Is +this still considered a regression, though it isn't part of the +Servlet 2.2/JSP 1.1 spec? + +7. Evaluate whether anything should be done to deal with the use of +non-thread-safe DateFormat and related classes. + +Must Resolve Bugs: + +177 Race condition during servlet initialization BugRat Report#2 +182 JSP error-page doesn't work with virtual hosts BugRat Report +274 request.getUserPrincipal() doesn't work when user is authent +437 req.getParameter(name) Ignores charset. always assumes ISO88 +463 Ctx( /examples ): IOException in: R( /examples + + null) No +1253 Frequent Connection reset by peer errors +1663 Tomcat -SSL problem +1798 Tomcat 3.2.2b5 with Apache and ajp13 stops responding after +3233 exception handling wrt errorpages seems to be incorrect +3486 Session problem (with case insensitive context matching on windows) +3572 HttpSessionFacade.invalidate don't unbound Attributes +3577 NPE when DecodeInterceptor gets confused + +Tomcat 3.3 Release Candidate 2: + + Code Freeze/Tag Date: Sept 21, 2001 + Release Manager: Larry Isaacs + + Will be the build put to a vote as a release. This release should + only include very minor fixes and documentation updates from the + RC1 release. + +To Be Addressed by RC2: + +8. We need to remove or optionally disable the shutdown support in +Ajp13Interceptor. This allows configuring a password protected +Ajp12Interceptor shutdown to be the only shutdown available. + +9. Some files under src/native have embedded CR's, i.e. Unix files would have +CRLF and Windows files would have CRCRLF's. These need to be fixed. + +10. The jk_nt_service, and
[Bug 3589] - Cannot process Taglib TLD when deployed through EmbeddedManager MBean
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3589 --- Additional Comments From [EMAIL PROTECTED] 2001-09-13 14:31 --- Can I build the full package from the jBoss tree ? I assume the problem is with the Embedded deployment scenario, but I would have assumed we would have had that issue reported by the J2EE RI, since they also use the Embedded class (the wrapper MBean just calls it without doing anything significant).
IIS Connector for TC4.0
Hi Gal, Developers, I'm about to produce a webapp version of the Domino connector for TC4.0, and I see there isn't an IIS connector. Is anyone working on this? Want me to take a look? Bye. -- Andy Armstrong, Tagish
Re: Tomcat4-RC1: parse exception on taglibs
On Thu, 13 Sep 2001, Rickard Öberg wrote: Date: Thu, 13 Sep 2001 12:40:35 +0200 From: Rickard Öberg [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: Tomcat4-RC1: parse exception on taglibs Hey I've finally managed to get Catalina working with JBoss (I had not set catalina.base, but no error was produced, just nothing happened). Yesterday, I added an update to Embedded.start() to set catalina.base to the value of catalina.home if it's not already set. That way, others won't get bit by this one. Anyway, the first thing I try is to deploy an app with a taglib JAR, with the TLD inside. But it seems like there's something wrong with the TLD parsing because I get this: org.xml.sax.SAXParseException: The markup in the document preceding the root element must be well-formed. And this happens no matter what I do with the actual TLD. Removing the taglib makes the WAR deploy properly, so it's definitely that which blows up. Any ideas? It's certainly an odd symptom. One potentially significant environmental difference is that Embedded does not set up the usual class loader hierarchy that org.apache.catalina.startup.Bootstrap does. What is the class loader environment when you're running into this? /Rickard Craig
[Bug 3581] - Ctx() : Error creating validation mark - java.io.FileNotFoundException
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3581 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2001-09-13 15:17 --- webxmlval is a mark that the web.xml file has been validated once, so the expensive operation will not be duplicated. It is create in the work directory of each app - where you are supposed to be able to write ( or jsp will fail ). Please check the directory for file permissions ( and for existence - but if it isn't there the workdir may have problems ). I believe it's a configuration problem - please reopen the bug if you have the right permissions and you still see the problem ( it's nothing bad if the file can't be created, but you'll have problems later with jsp, so make sure the workdir exists and is writable ).
Re: IIS Connector for TC4.0
Andy Armstrong wrote: Hi Gal, Developers, I'm about to produce a webapp version of the Domino connector for TC4.0, and I see there isn't an IIS connector. Is anyone working on this? Want me to take a look? (Sorry to follow myself up) Off-list I've had it explained to me that jk is still valid for TC4.0, so I'll concentrate on testing the jk version of the Domino connector with 4.0. Sorry for the confusion (all mine). -- Andy Armstrong, Tagish
Re: IIS Connector for TC4.0
Andy Armstrong [EMAIL PROTECTED] wrote: Hi Gal, Developers, I'm about to produce a webapp version of the Domino connector for TC4.0, and I see there isn't an IIS connector. Is anyone working on this? Want me to take a look? No, I'm not yet working on those. I'm actually concentrating on fixing the library bugs, the required improvements, and its integration with APR, plus a bunch of developer docs which will help in refining/extending the WebApp library API. It would be so cool to be able to have at least a base code on which to work on, as Colin gratefully donated his code for NSAPI. Regarding a long-term plan, I heard Costin and Henri talking about refactorying the JK connector APIs, and using APR, but that actually nothing is ready yet (correct me if I'm wrong)... My alleged thought right now goes to a big input in terms of API design from the JK guys, I believe (but that's my personal feeling) that if a major redesign needs to be done in JK land, we can use some of the bases put in place by WebApp and especially APR, to come out with maybe a new/revised improved APR-based module... Let me know your thoughts... Pier
[Bug 3594] New: - Have to reload page or page will not be shown
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3594 Summary: Have to reload page or page will not be shown Product: Tomcat 4 Version: 4.0 Release Candidate 1 Platform: PC OS/Version: Windows NT/2K Status: UNCONFIRMED Severity: Major Priority: Other Component: Webapps AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When tomcat includes a page i have to reload the browser or else the page will not be shown. This is only when I request the page the first time!!! After it has been cached there is no problem.
[Bug 3577] - NPE when DecodeInterceptor gets confused
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3577 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2001-09-13 15:30 --- Very strange bug. The NPE is easy to solve ( I'll check in tonight ), however switching the encoding in a session with bad browser is not something I know how to solve... We do our best to remember/guess the encoding in a session, and that's quite difficult - but there's a limit on how much we can guess. The bug is of course in the browser that doesn't send the encoding in the first place. If you have any sugestion on how to improve the guessing alghoritm to deal with this case - please reopen this ( as an enhancement request - for post 3.3 ). I'll mark it as fixed ( the NPE ), the second part would be a WONTFIX or LATER ( rather the first, as I don't know any solution and I don't want to mess with the current guessing ). Thanks for the report.
Re: IIS Connector for TC4.0
Pier Fumagalli wrote: Andy Armstrong [EMAIL PROTECTED] wrote: Hi Gal, Developers, I'm about to produce a webapp version of the Domino connector for TC4.0, and I see there isn't an IIS connector. Is anyone working on this? Want me to take a look? No, I'm not yet working on those. I'm actually concentrating on fixing the library bugs, the required improvements, and its integration with APR, plus a bunch of developer docs which will help in refining/extending the WebApp library API. It would be so cool to be able to have at least a base code on which to work on, as Colin gratefully donated his code for NSAPI. Regarding a long-term plan, I heard Costin and Henri talking about refactorying the JK connector APIs, and using APR, but that actually nothing is ready yet (correct me if I'm wrong)... My alleged thought right now goes to a big input in terms of API design from the JK guys, I believe (but that's my personal feeling) that if a major redesign needs to be done in JK land, we can use some of the bases put in place by WebApp and especially APR, to come out with maybe a new/revised improved APR-based module... Let me know your thoughts... Urm. I'm keen to be guided by people who have a better overview of where connectors are headed in general and what needs doing really. My priority is to make sure the current Domino/JK connector works OK with TC4.0. Once that's nailed I'm open to suggestions. I'd be happy to produce a wepapp version of the Domino connector, but I'm also happy to undertake any work that needs doing on the IIS connector (I'm not suggesting there /is/ work to do on IIS -- it's just something I could quite easily do). As usual I'm also pondering why I'm spending so much time on IIS and Domino when I wouldn't run anything apart from Apache if I ruled the world. I wonder what I did in a past life... -- Andy Armstrong, Tagish
Re: mod_webapp/SSL and TC 4.0
GOMEZ Henri [EMAIL PROTECTED] wrote: Hi to all, I take a look at mod_webapp and warp java, and didn't find reference to SSL informations forwarded from WebServer. Should it be fixed before release since it may break the spec ? I could grab code from mod_jk to support that, but I'm pretty busy with my day work and mod_jk fixes for TC 3.3 release. Maybe Pier, JF or Ryan could grab existing code from mod_jk and use it in mod_webapp ? It should works at least for Apache 1.3/2.0. To follow the Servlet 2.3, take a look at jk in J-T-C since it also handle the SSL_KEY_SIZE. Yes, will do... Check out # 3510... Pier
Re: mod_jk using warp protocol ?
GOMEZ Henri [EMAIL PROTECTED] wrote: What about adding warp protocol to mod_jk and may be adding with functionnalities from ajp14 ? I'm more than +1 about a merger between AJPv14 and WARP... The protocols are pretty similar... Of course in J-T-C, since mod_jk in J-T must be freezed. Cool... We can mirror changes around there... ajp14 and warp are very similar, they use the same (it seems) logon system (using md5), and differents protocol encoding but since ajp14 is still experimental, it could be changed in using warp packet system. The packet system of WARP is basically the one developed for AJPv21, multiplexing (if we want to implement it) can be written on top of it, as an extension to the packet layout... I've got some questions here : In ajp14, the JkAutoMount was designed to help web-server knows about URL/URI handled by the remote tomcat (examples/*.jsp, examples/servlet/*). JkAutoMount * myworker This allow us to remove the need of configuring these mappings in httpd.conf. More in ajp14, the AutoMount key is the Virtual, if a Virtual section is present in Tomcat we could be sure that a Virtual section in Web-Server will get mappings only for the corresponding Virtual of Tomcat. Virtual myhost1 JkAutoMount myhost1 myworker /Virtual Did there is the same strategy in mod_webapp ? Precisely the same exact approach... When you deploy an app, tomcat basically responds with two pieces of data (all enclosed in the protocol, but it's not hard to figure that out), a root path (local to tomcat) where the application is deployed and the list of permitted and forbidden URL paths: basically, WebApp check if it can read the WEB-INF/web.xml file, and if so, it automagically processes the list of allowed and denied URL patterns supplied by tomcat to see what should be served locally: In servlet 2.3 we have to deny any URL pattern associated with a servlet, anything associated with a security constraint and anything that need to be filtered (the last one is specific for 2.3). May be the local Apache Gurus (JF, Ryan) could tell us if we could avoid to set myhost1 in Virtual ? The VirtualHostName must be present somewhere in Apache Recs... server_rec-hostname , the server rec is passed to you in all config functions, and the virtual host name is in there (check out mod_webapp.c in the Apache 1.3 directory, or mod_jserv)... Pier
Re: IIS Connector for TC4.0
Andy Armstrong [EMAIL PROTECTED] wrote: Andy Armstrong wrote: Hi Gal, Developers, I'm about to produce a webapp version of the Domino connector for TC4.0, and I see there isn't an IIS connector. Is anyone working on this? Want me to take a look? (Sorry to follow myself up) Off-list I've had it explained to me that jk is still valid for TC4.0, so I'll concentrate on testing the jk version of the Domino connector with 4.0. Sorry for the confusion (all mine). Well, the effort for bringing any connector to WebApp is kinda big, I mean, basically every API used there MUST follow APR counterparts (no ANSI-C), so I'd see it as a long-term plan for APR-ization of the connector world... Pier
Re: IIS Connector for TC4.0
On Thu, 13 Sep 2001, Pier Fumagalli wrote: Regarding a long-term plan, I heard Costin and Henri talking about refactorying the JK connector APIs, and using APR, but that actually nothing is ready yet (correct me if I'm wrong)... My alleged thought right now goes to a big input in terms of API design from the JK guys, I believe (but that's my personal feeling) that if a major redesign needs to be done in JK land, we can use some of the bases put in place by WebApp and especially APR, to come out with maybe a new/revised improved APR-based module... My view: It should happen only after 3.3 (and 4.0) is released, switching to APR is reasonably easy ( IMHO ), adding warp protocol is doable ( but require some changes in the request representation to use the same struct as the other jk modules ). Integrating WARP and AJP14 seems easy ( technically - there are many common things ), but it'll require some 'negotiation' - and I hope some real community involvment. Refactoring/cleaning of jk - one part will be done by the move to APR ( of course ), there are some optimizations and improvements in the jni connector I am planning ( also after APR is in ), and some of the webapp API ( and docs :-) could also help a lot. And of course, I'm happy to see both Pier and Henri are open. Costin
[PATCH] Missing jar in jakarta-tomcat-4.0/catalina/build.xml
Hello,
Can the attached patch to the jakarta-tomcat-4.0/catalina/build.xml file
be committed?
The attached patch adds ${jndi.jar} to the CLASSPATH. Without this
patch, the build of the catalina directory will fail.
Thanks,
Patrick
--
_
Patrick Luby Email: [EMAIL PROTECTED]
Software Engineering Manager Phone: 408-863-3284
Sun Microsystems, Desktop Foundation Software
901 San Antonio Road, UCUP01-103
Palo Alto, CA 94303-4900
_
Index: build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/build.xml,v
retrieving revision 1.58
diff -u -r1.58 build.xml
--- build.xml 2001/09/13 19:57:04 1.58
+++ build.xml 2001/09/13 22:57:43
@@ -42,6 +42,7 @@
pathelement location=${servlet.jar}/
pathelement location=${activation.jar}/
pathelement location=${jcert.jar}/
+pathelement location=${jndi.jar}/
pathelement location=${jnet.jar}/
pathelement location=${jsse.jar}/
pathelement location=${jmxri.jar}/
Re: Remaining Tomcat 3.3 Issues
Re. 7) Since there is only one facade per Request and only one Request per thread, you could avoid synchronized all together by having an instance of SimpleDateFormat in either the Request or the facade. That would just leave ServerCookie using DateTool, where the hit would be minimal. Just me $0.02. - Original Message - From: Larry Isaacs [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 12:57 PM Subject: RE: Remaining Tomcat 3.3 Issues -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 3:14 PM To: [EMAIL PROTECTED] Subject: RE: Remaining Tomcat 3.3 Issues 7. Evaluate whether anything should be done to deal with the use of non-thread-safe DateFormat and related classes. The Date used in Http10 connector response, is allready handled by stuff I commited some time ago which use a speed hack and return allready processed date String if it was processed in the same second removing need to use SimpeDateFormat at each hit. format1123() in org\apache\tomcat\util\buf\DateTool But the request.getDateHeader(Date) in facade is still using DateTool.parseDate(value) in DateTool which need to be synchronized. Question: should we sync in facade or in DateTool ? My initial preference is in DateTool. However, I may be unaware of some pro's or con's. 1798 Tomcat 3.2.2b5 with Apache and ajp13 stops responding after This one is very difficult to reproduce (I never succeed). We need more information on configuration. May be related with CHUNKED. I'd like to see bug reporter to test against latest TC 3.3 Did your attempts include 3.2.2 or 3.2.3. If so, I'll resolve the bug reports as worksforme. Otherwise, I'll just add a note that it couldn't be reproduced in 3.3 and is assumed fixed. 8. We need to remove or optionally disable the shutdown support in Ajp13Interceptor. This allows configuring a password protected Ajp12Interceptor shutdown to be the only shutdown available. Having Ajp13 or Ajp12 shutdown from a distant machine is dangerous. We should use Ajp13 as link between web-server and tomcat and use Ajp12 accepting only from localhost. I'll take this as a vote to remove the shutdown support from Ajp13 and not provide an option. I'm not sure if you are implying additional changes by your statement shutdown from a distant machine is dangerous. 9. Some files under src/native have embedded CR's, i.e. Unix files would have CRLF and Windows files would have CRCRLF's. These need to be fixed. Couldn't we say that ALL src in native will be only in Unix mode ? I need CRLF for building on Windows. It appears that some files were checked in from *nix containing CR's that were not stripped during the commit. When I checkout or update from Windows, CVS still adds a CR in front of all LFs. The result is CRCRLF which Dev Studio wants to fix. I'd just like the source to be clean for final release. I'm not sure what happens on *nix systems when they encounter a CR. 11. Make sure we are okay with mod_jk not supporting Apache's rewrite in Tomcat 3.3's mod_jk. I'm fine with not supporting it, but I want to include some justification in the documentation to avoid some of the why don't you questions. As said Costin, making mod_jk using uri or unparsed_uri is not difficult, but we have here 2 situations. Strict respect of spec (unparsed) or mod_rewrite compatibility. Why not let the final user decide and create a new JkOptions directive (easy). ie : JkOptions +ForwardUnparsedURI = strict spec respect JkOptions -ForwardUnparsedURI = rewrite compatibility I'm +1 for user configurability. I would prefer strict compliance to be the default. 111 after httpd reload mod_jk fails to find a worker BugRat Repo Didn't know this one but must be easy to handle I assume this is likely fixed since the bug is very old. I just prefer someone more familiar with the history of mod_jk to say so. 2333 Nor Oth PC [EMAIL PROTECTED] NEW HTTP Reason will be destroyed in header using AJP12 Some patch was sent some time ago and even if AJP12 is somewhat deprecated, I should try to commit the provided patch. I scanned but didn't have much time assess applying the supplied patch. My main reservation is that I'm not sure if IIS or netscape is multi-threaded, in which case the static buffer could do more harm than good. 2550 Ajp13 Connection hanging on static content. Should take a look at this one even. Majority of users use Apache to handle static data but it must be investigated (I) My understanding is that Ajp13 keeps the connection open, so a Connection reset by peer sounds bad to me. Do you know if this issue might have been fixed since the bug was opened? I though there was some work on re-establishing the connection. 2927 Nor Oth PC [EMAIL
Re: IIS Connector for TC4.0
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: My view: It should happen only after 3.3 (and 4.0) is released, switching to APR is reasonably easy ( IMHO ), adding warp protocol is doable ( but require some changes in the request representation to use the same struct as the other jk modules ). Well, for 4.0 it's pretty easy... It doesn't ship with a connector, only the WARP java counterpart... I don't want to touch 3.3 in terms of their plans. Anyway, switching to APR is not that easy (IMO), if you want to take advantage of ALL which is provided by APR (I'm deprecating ANSI-C here). Integrating WARP and AJP14 seems easy ( technically - there are many common things ), but it'll require some 'negotiation' - and I hope some real community involvment. C'mon... It _IS_ the easiest thing... We just need to adjust those routines to read/send packets, and what packet is used for what... The easiest thing is to implement the real protocol... All hard work is about how that data is organized within the respective modules, not how to grab it and put it on the network... And being the author of 2 out of 3 connectors on this project, I know what I'm talking about :) :) :) Refactoring/cleaning of jk - one part will be done by the move to APR ( of course ), there are some optimizations and improvements in the jni connector I am planning ( also after APR is in ), and some of the webapp API ( and docs :-) could also help a lot. DOH! I'm saying, let's refactor WebApp how you guys want it... In the past 6 months I got to know APR quite well, on the other hand, you guys have more experience on the different web-servers... We have a working APR-based implementation, let's just put it together in a nice way so that it fits BOTH needs... And of course, I'm happy to see both Pier and Henri are open. DOH! I've always been... :) Pier
Re: Remaining Tomcat 3.3 Issues
On Thu, 13 Sep 2001, Bill Barker wrote: Re. 7) Since there is only one facade per Request and only one Request per thread, you could avoid synchronized all together by having an instance of SimpleDateFormat in either the Request or the facade. That would just leave ServerCookie using DateTool, where the hit would be minimal. Just me $0.02. +1 Costin - Original Message - From: Larry Isaacs [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 12:57 PM Subject: RE: Remaining Tomcat 3.3 Issues -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 3:14 PM To: [EMAIL PROTECTED] Subject: RE: Remaining Tomcat 3.3 Issues 7. Evaluate whether anything should be done to deal with the use of non-thread-safe DateFormat and related classes. The Date used in Http10 connector response, is allready handled by stuff I commited some time ago which use a speed hack and return allready processed date String if it was processed in the same second removing need to use SimpeDateFormat at each hit. format1123() in org\apache\tomcat\util\buf\DateTool But the request.getDateHeader(Date) in facade is still using DateTool.parseDate(value) in DateTool which need to be synchronized. Question: should we sync in facade or in DateTool ? My initial preference is in DateTool. However, I may be unaware of some pro's or con's. 1798 Tomcat 3.2.2b5 with Apache and ajp13 stops responding after This one is very difficult to reproduce (I never succeed). We need more information on configuration. May be related with CHUNKED. I'd like to see bug reporter to test against latest TC 3.3 Did your attempts include 3.2.2 or 3.2.3. If so, I'll resolve the bug reports as worksforme. Otherwise, I'll just add a note that it couldn't be reproduced in 3.3 and is assumed fixed. 8. We need to remove or optionally disable the shutdown support in Ajp13Interceptor. This allows configuring a password protected Ajp12Interceptor shutdown to be the only shutdown available. Having Ajp13 or Ajp12 shutdown from a distant machine is dangerous. We should use Ajp13 as link between web-server and tomcat and use Ajp12 accepting only from localhost. I'll take this as a vote to remove the shutdown support from Ajp13 and not provide an option. I'm not sure if you are implying additional changes by your statement shutdown from a distant machine is dangerous. 9. Some files under src/native have embedded CR's, i.e. Unix files would have CRLF and Windows files would have CRCRLF's. These need to be fixed. Couldn't we say that ALL src in native will be only in Unix mode ? I need CRLF for building on Windows. It appears that some files were checked in from *nix containing CR's that were not stripped during the commit. When I checkout or update from Windows, CVS still adds a CR in front of all LFs. The result is CRCRLF which Dev Studio wants to fix. I'd just like the source to be clean for final release. I'm not sure what happens on *nix systems when they encounter a CR. 11. Make sure we are okay with mod_jk not supporting Apache's rewrite in Tomcat 3.3's mod_jk. I'm fine with not supporting it, but I want to include some justification in the documentation to avoid some of the why don't you questions. As said Costin, making mod_jk using uri or unparsed_uri is not difficult, but we have here 2 situations. Strict respect of spec (unparsed) or mod_rewrite compatibility. Why not let the final user decide and create a new JkOptions directive (easy). ie : JkOptions +ForwardUnparsedURI = strict spec respect JkOptions -ForwardUnparsedURI = rewrite compatibility I'm +1 for user configurability. I would prefer strict compliance to be the default. 111 after httpd reload mod_jk fails to find a worker BugRat Repo Didn't know this one but must be easy to handle I assume this is likely fixed since the bug is very old. I just prefer someone more familiar with the history of mod_jk to say so. 2333 Nor Oth PC [EMAIL PROTECTED] NEW HTTP Reason will be destroyed in header using AJP12 Some patch was sent some time ago and even if AJP12 is somewhat deprecated, I should try to commit the provided patch. I scanned but didn't have much time assess applying the supplied patch. My main reservation is that I'm not sure if IIS or netscape is multi-threaded, in which case the static buffer could do more harm than good. 2550 Ajp13 Connection hanging on static content. Should take a look at this one even. Majority of users use Apache to handle static data but it must be investigated (I) My understanding is that Ajp13 keeps the connection open, so a Connection reset by peer sounds
Re: IIS Connector for TC4.0
On Fri, 14 Sep 2001, Pier Fumagalli wrote: Anyway, switching to APR is not that easy (IMO), if you want to take advantage of ALL which is provided by APR (I'm deprecating ANSI-C here). This is an incremental process, and can only increase the stability of jk. Refactoring/cleaning of jk - one part will be done by the move to APR ( of course ), there are some optimizations and improvements in the jni connector I am planning ( also after APR is in ), and some of the webapp API ( and docs :-) could also help a lot. DOH! I'm saying, let's refactor WebApp how you guys want it... In the past 6 months I got to know APR quite well, on the other hand, you guys have more experience on the different web-servers... We have a working APR-based implementation, let's just put it together in a nice way so that it fits BOTH needs... It doesn't make too much sense. You're saying we should use WebApp because it already uses APR, and port back all the protocols and modules to it. I don't know - if using APR is so difficult that it's easier to port all the modules to webapp rather than replace the C functions with the APR equivalent in jk - then maybe we should thing again about using APR. But my impression so far is that APR is quite easy to use and very close to the current abstractions used in jk. Costin
[Bug 3594] - Have to reload page or page will not be shown
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3594 --- Additional Comments From [EMAIL PROTECTED] 2001-09-13 17:21 --- If you have a reproducible test case that demonstrates this problem, please add it as an attachment to this bug report. Otherwise, there is nothing we can do with a report like this (and it will be closed with status WORKSFORME, because this feature does in fact work for me and for many other people). That being said, it is highly likely that this is an application programming error. To help understand *what* might be happening,the TOMCAT-USER mailing list is a useful forum for asking and answering questions. You can subscribe to it via http://jakarta.apache.org/site/mail.html.
Re: cvs commit: jakarta-tomcat-4.0/catalina build.xml
On Thu, 13 Sep 2001, Glenn Nielsen wrote: Date: Thu, 13 Sep 2001 19:23:56 -0500 From: Glenn Nielsen [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-tomcat-4.0/catalina build.xml Craig R. McClanahan wrote: On 13 Sep 2001 [EMAIL PROTECTED] wrote: Date: 13 Sep 2001 18:56:11 - From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: cvs commit: jakarta-tomcat-4.0/catalina build.xml glenn 01/09/13 11:56:11 Modified:catalina build.xml Log: Update build, Copy the jndi, activation, and mail jar files only if they are present -1 The jndi.jar file is required to run on JDK 1.2, and activation.jar/mail.jar are now required by the standard resource factory and corresponding example program. Craig Craig, JNDI comes as part of the 1.3 JVM, so there is no need for it to be included with Tomcat if the JVM is 1.3. But it *is* required if you are building on 1.2. Until we decide otherwiwe, Tomcat 4 must still be able to be compiled and run on a 1.2 platform. Given that the Tomcat build script converts the source code into a binary distribution that can be run on any 1.2 or later platform, the only portable thing we can do is require jndi.jar to be available at build time, so that it can be copied to the distribution (as well as used in the compile, as just patched). Note that the classloader initialization does recognize if these classes are built in, and skips jndi.jar when creating the class loader repository list on a 1.3 or later system. And the mail jar is the type of API that should really be installed in the $JAVA_HOME/jre/lib/ext directory. I do *not* agree that this is a good idea. TOMCAT-USER gets 10 or so messages a week from people who have old versions of servlet.jar (or even j2ee.jar!) in their system extensions directory. The symptoms that this causes are very strange to a newbie, and are guaranteed to happen to happen the next time JavaMail is rev'd. The current practice of including javamail.jar and activation.jar in the place that Tomcat needs them (need vs. want is a separate issue, addressed in your next comments), also makes Tomcat easier to install -- just unpack it, set a couple of environment variables (optional), and go. Finally, many environments do not allow developers or users to add arbitrary JAR files to JAVA_HOME anyway (because it is a shared resource), so we cannot assume that this is even possible. The change I made gave the build more flexibility. The jar files are still put in the Tomcat distributions if their properties are configured to a jar file that exists. Making the build flexible instead of one size fits all is a good thing IMHO. There is room to improve how that flexibility is implemented in the build. Perhaps testing the build environment to make sure that class's related to those API's are available, but only copying them if they defined property points to a jar file that exists. I agree with you that the flexibility of the build process for Tomcat can be improved -- especially in the light of Ant 1.4 (which suddenly became the norm on Monday, with no discussion or vote :-). But it's too close to final release to start ripping major things back out, now that we have actually documented the Tomcat features available that support mail sessions as a JNDI resource. Remember that the build process we are talking about is for folks developing Tomcat, not using it. In order to produce an all in one binary distribution that includes these JAR files in the distribution (per the reasoning above), they *must* be present anyway so that they can be copied into the right places. And, if the JAR files have to be there anyway, there is no point in making the compiles conditional. Regards, Glenn Craig -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
cvs commit: jakarta-tomcat-connectors/webapp/java WarpRequestHandler.java
pier01/09/13 18:04:19
Modified:webapp/java WarpRequestHandler.java
Log:
Fix for bug #3574. Thanks to Fred Romelfanger [EMAIL PROTECTED].
Revision ChangesPath
1.16 +26 -0 jakarta-tomcat-connectors/webapp/java/WarpRequestHandler.java
Index: WarpRequestHandler.java
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/java/WarpRequestHandler.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- WarpRequestHandler.java 2001/08/05 18:33:42 1.15
+++ WarpRequestHandler.java 2001/09/14 01:04:19 1.16
@@ -75,6 +75,8 @@
import org.apache.catalina.util.RequestUtil;
import org.apache.catalina.util.StringParser;
+import java.security.Principal;
+
public class WarpRequestHandler {
private StringParser parser = new StringParser();
@@ -167,6 +169,11 @@
logger.debug(Request user=+user+ auth=+auth);
request.setAuthType(auth);
// What to do for user name?
+if(user != null auth != null auth.equals(Basic)) {
+Principal prin = new BasicPrincipal(user);
+request.setUserPrincipal(prin);
+}
+
break;
}
@@ -397,5 +404,24 @@
}
}
+class BasicPrincipal implements Principal {
+private String user;
+BasicPrincipal(String user) {
+this.user = user;
+}
+
+public boolean equals(Object another) {
+return (another instanceof Principal
+((Principal)another).getName().equals(user));
+}
+
+public String getName() {
+return user;
+}
+
+public String toString() {
+return getName();
+}
+}
}
[PATCH] jakarta-tomcat-4.0/catalina/src/bin/catalina.sh
Hello, Attached is a patch to the jakarta-tomcat-4.0/catalina/src/bin/catalina.sh file. This patch eliminates the use of the pushd and popd shell commands when running this script with the debug argument. This patch is necessary because pushd and popd are only built-in commands in the Bash shell. While /bin/sh is the Bash shell on Linux, /bin/sh is the Bourne shell on most other Unix platforms. As a result, on Unix platforms where /bin/sh is the Bourne shell, this script will fail since there is no pushd or popd. Thanks, Patrick -- _ Patrick Luby Email: [EMAIL PROTECTED] Software Engineering Manager Phone: 408-863-3284 Sun Microsystems, Desktop Foundation Software 901 San Antonio Road, UCUP01-103 Palo Alto, CA 94303-4900 _ Index: catalina.sh === RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/src/bin/catalina.sh,v retrieving revision 1.19 diff -u -r1.19 catalina.sh --- catalina.sh 2001/09/12 17:38:47 1.19 +++ catalina.sh 2001/09/14 00:59:47 @@ -128,12 +128,11 @@ if [ $1 = debug ] ; then shift - pushd $CATALINA_HOME if [ $1 = -security ] ; then shift $JAVA_HOME/bin/jdb \ $CATALINA_OPTS \ - -sourcepath ../../jakarta-tomcat-4.0/catalina/src/share \ + -sourcepath $CATALINA_HOME/../../jakarta-tomcat-4.0/catalina/src/share \ -classpath $CP \ -Dcatalina.base=$CATALINA_BASE \ -Dcatalina.home=$CATALINA_HOME \ @@ -141,13 +140,12 @@ else $JAVA_HOME/bin/jdb \ $CATALINA_OPTS \ - -sourcepath ../../jakarta-tomcat-4.0/catalina/src/share \ + -sourcepath $CATALINA_HOME/../../jakarta-tomcat-4.0/catalina/src/share \ -classpath $CP \ -Dcatalina.base=$CATALINA_BASE \ -Dcatalina.home=$CATALINA_HOME \ org.apache.catalina.startup.Bootstrap $@ start fi - popd elif [ $1 = embedded ] ; then
Re: IIS Connector for TC4.0
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Fri, 14 Sep 2001, Pier Fumagalli wrote: At the same time, since also JK is moving towards APR, but they're far behind what WebApp does ATM, let's try to refine/update/change the WebApp API, already based on APR, and work on it as the APR based connector, when that is ready, we can think about porting all nice stuff that are still missing (load balancing, JNI and such), over to the new architecture... Pier, APR is a library of portable code - not a new 'architecture'. Mod_jk has an API that is used with 4 different protocols ( webapp will be the 5th ), 4 different web servers. This architecture is pretty well tested and stable. I'm not sure I understand your idea - of moving all this into webapp, instead of moving warp as a jk protocol ( or integrate it with ajp14). I'm just saying that APR is not the easiest bitch to handle on this planet... And I've given my full support since it seems that you guys want to refactor the JK api and use APR... Since there is already a working connector based on APR, and you're refactorying the JK API, I thought it might have been wise to use the already working APR-ized connector as a starting point. I don't mind rewriting the full WebApp core if it's worth to, it doesn't scare me... I'm just trying to be the nice guy around here, simply saying part of it is there, and if you guys want, I'm more than welcome to turn the sucker inside out... Trying to avoid duplicate work... If that's against your way of working, well, I'm just going to go ahead my own way. I simply thought that the one mentioned above was a win-win situation... But as always, if you don't want to, well, whatever :) We're just going to go on and re-duplicate work over and over again... WebApp, as JServ, (and 3.3 for you?) is my baby, and I'm not going to abandon it, even if you guys kick me out :) I just said that if you want to APR-ize JK and change the API, well, maybe we can see to lay the grounds for new foundations? Pier
Re: IIS Connector for TC4.0
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Fri, 14 Sep 2001, Pier Fumagalli wrote: Anyway, switching to APR is not that easy (IMO), if you want to take advantage of ALL which is provided by APR (I'm deprecating ANSI-C here). This is an incremental process, and can only increase the stability of jk. You'll see :) APR is nice, but I believe that, as it's wrong to write C++ code in Java, so it's wrong to port stuff to APR... Once you discover the APR platform, if you want to take full advantage of it, you have to THINK APR... Refactoring/cleaning of jk - one part will be done by the move to APR ( of course ), there are some optimizations and improvements in the jni connector I am planning ( also after APR is in ), and some of the webapp API ( and docs :-) could also help a lot. DOH! I'm saying, let's refactor WebApp how you guys want it... In the past 6 months I got to know APR quite well, on the other hand, you guys have more experience on the different web-servers... We have a working APR-based implementation, let's just put it together in a nice way so that it fits BOTH needs... It doesn't make too much sense. You're saying we should use WebApp because it already uses APR, and port back all the protocols and modules to it. I'm saying that, since in your previous messages you said you wanted to refactor the JK api, and port it to APR, well, why not considering a new planning ground? The WebApp API at the moment is _so_ tiny that can be changed, revolted, destroyed and rebuilt with no problems in a reasonable amount of time... I don't know - if using APR is so difficult that it's easier to port all the modules to webapp rather than replace the C functions with the APR equivalent in jk - then maybe we should thing again about using APR. Your choice... Mine was to use APR as my platform forgetting everything I knew about C... But my impression so far is that APR is quite easy to use and very close to the current abstractions used in jk. You're welcome to go ahead and do whatever you want... I'm not vetoing (as always)... I'm just being propositive... Pier (the nice guy?)
[Bug 3597] New: - Shutting down takes *ages*
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3597 Summary: Shutting down takes *ages* Product: Tomcat 4 Version: Nightly Build Platform: Other OS/Version: Linux Status: NEW Severity: Minor Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I just timed the shutdown process of an out-the-box Tomcat 4.0 install, with the preinstalled 4 webapps. It takes 2 minutes on my pentium 3. 0% CPU usage. Is this usual? By shutdown process, I mean the time from the invocation of ./shutdown.sh till the point at which all Tomcat threads actually die (as reported by 'ps'). Here is the log output of what I'd consider a normal shutdown. Nothing untoward, just the last few lines take forever. [jeff@kermit bin]$ date ; ./shutdown.sh Fri Sep 14 11:19:07 EST 2001 Using CLASSPATH: /home/jeff/apache/jakarta/jakarta-tomcat-4.0/dist/bin/bootstrap.jar:/usr/local/jdk/lib/tools.jar Using CATALINA_BASE: /home/jeff/tc Using CATALINA_HOME: /home/jeff/apache/jakarta/jakarta-tomcat-4.0/dist Using JAVA_HOME: /usr/local/jdk [jeff@kermit bin]$ 2001-09-14 12:19:10 HttpProcessor[8080][4] Stopping background thread 2001-09-14 12:19:10 HttpProcessor[8080][3] Stopping background thread 2001-09-14 12:19:10 HttpProcessor[8080][2] Stopping background thread 2001-09-14 12:19:10 HttpProcessor[8080][1] Stopping background thread 2001-09-14 12:19:10 HttpProcessor[8080][0] Stopping background thread 2001-09-14 12:19:10 HttpConnector[8080] Stopping background thread == ../logs/catalina.out == Stopping service Tomcat-Standalone == ../logs/localhost_log.2001-09-14.txt == 2001-09-14 12:19:15 StandardHost[localhost]: Removing web application at context path /examples 2001-09-14 12:19:15 SessionListener: contextDestroyed() 2001-09-14 12:19:15 ContextListener: contextDestroyed() 2001-09-14 12:20:04 StandardHost[localhost]: Removing web application at context path /webdav 2001-09-14 12:20:07 StandardHost[localhost]: Removing web application at context path /tomcat-docs 2001-09-14 12:20:15 StandardHost[localhost]: Removing web application at context path /manager 2001-09-14 12:21:07 StandardHost[localhost]: Removing web application at context path --Jeff
cvs commit: jakarta-tomcat-connectors/webapp/support aplocal.m4
pier01/09/13 18:26:19
Modified:webapp/support aplocal.m4
Log:
Added directory resolution script.
Revision ChangesPath
1.5 +10 -1 jakarta-tomcat-connectors/webapp/support/aplocal.m4
Index: aplocal.m4
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/support/aplocal.m4,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- aplocal.m42001/09/10 03:33:51 1.4
+++ aplocal.m42001/09/14 01:26:19 1.5
@@ -57,7 +57,7 @@
dnl --
dnl Author Pier Fumagalli [EMAIL PROTECTED]
-dnl Version $Id: aplocal.m4,v 1.4 2001/09/10 03:33:51 pier Exp $
+dnl Version $Id: aplocal.m4,v 1.5 2001/09/14 01:26:19 pier Exp $
dnl --
AC_DEFUN(LOCAL_INIT,[
@@ -121,3 +121,12 @@
${ECHO} Execution of $1 returned ${ret}
])
+AC_DEFUN(LOCAL_RESOLVEDIR,[
+ AC_MSG_CHECKING([for $2])
+ localdir=`pwd`
+ cd $1
+ DIR=`pwd`
+ AC_MSG_RESULT([${DIR}])
+])
+
+
Log4J ?
Can anyone tell me how to use Log4J ? the sample is cat.debug(Hello world.); cat.info(What a beatiful day.); so, what is the different if i use System.err.println(Hello world.); ??? Both are output to standout... How to use Log4J more easy ? Thanks /* Kenny Ma [EMAIL PROTECTED] */
[Bug 111] - after httpd reload mod_jk fails to find a worker BugRat Report#118
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=111 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2001-09-13 19:29 --- Changes were made that I believe fixes this problem and feedback from Bill Barker confirms the fix. These changes appear in both Tomcat 3.2.3 and Tomcat 3.3. Marking as fixed.
Re: cvs commit: jakarta-tomcat-4.0/catalina build.xml
On Thu, 13 Sep 2001, Glenn Nielsen wrote: Date: Thu, 13 Sep 2001 20:33:02 -0500 From: Glenn Nielsen [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-tomcat-4.0/catalina build.xml Craig, I have no problem with the binary distribution provided on the jakarta site containing all the jar files. And the default build and directions for building to do that also. All I added was the flexibility to *NOT* require that. This is not a major change before release, the build was just recently changed to distribute these jar files in $CATALINA_HOME/common/lib. If we can not agree, it can be put to a vote. Sounds like a vote is in order, then. My thinking for the current approach is as follows: * If a JAR file is included in the official binary distribution of Tomcat, it needs to be put there by the standard build script. Otherwise, you end up with duplicate build scripts or targets (guaranteed to get out of sync over time) or manual intervention when creating a distribution (tedious, error-prone, and not repeatable). * If a JAR file is part of the official binary distribution of Tomcat, the build process should fail if it's not present. Otherwise, you run into the current situation with Tomcat 3.2 -- if you build 3.2 without the JSSE jar files, the build silently succeeds -- but the SSLSocketFactory you need is not built, and you cannot use this distro to run https connections even if you *do* install the JSSE jar files. * If a JAR file is used in the core of Tomcat, or used in example applications included with Tomcat, it must be part of the official distribution, and therefore fall under the purview of the previous two rules. Otherwise, you cannot have a install and run right away user experience, and you make your users have to do the integration. Thus, it all comes down to which JAR files do we consider essential? This should not be too controversial in most cases. External libraries we require include: * JSSE - These are required to build (to avoid the 3.2 syndrome described above, but are not included solely because of legal requirements) * JNDI - The jndi.jar file is required to compile or run on a 1.2 platform at all. Therefore, it is essential until we decide to desupport 1.2, after which it could be removed. * Servlet API - Pretty obvious that we need servlet.jar for a servlet container. * Regular Expressions Library - Required to implement the request filters that are a standard feature. * XML Parser - Required to function, so must be included. Replaceable by any parser compatible with JAXP/1.1, however. * Mail and Activation - Required for the JNDI resource factories and the corresponding example application. IMHO, these things should not be optional (see the 3.2 syndrome, above), so I removed the conditional compile stuff (and updated the BUILDING.txt to document the revised requirements). A few conditional compilation cases remain in the current build scripts. I plan to get rid of as many of them as possible before final release. Do other developers have different opinions/votes on this issue? Regards, Glenn Craig Craig R. McClanahan wrote: On Thu, 13 Sep 2001, Glenn Nielsen wrote: Date: Thu, 13 Sep 2001 19:23:56 -0500 From: Glenn Nielsen [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-tomcat-4.0/catalina build.xml Craig R. McClanahan wrote: On 13 Sep 2001 [EMAIL PROTECTED] wrote: Date: 13 Sep 2001 18:56:11 - From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: cvs commit: jakarta-tomcat-4.0/catalina build.xml glenn 01/09/13 11:56:11 Modified:catalina build.xml Log: Update build, Copy the jndi, activation, and mail jar files only if they are present -1 The jndi.jar file is required to run on JDK 1.2, and activation.jar/mail.jar are now required by the standard resource factory and corresponding example program. Craig Craig, JNDI comes as part of the 1.3 JVM, so there is no need for it to be included with Tomcat if the JVM is 1.3. But it *is* required if you are building on 1.2. Until we decide otherwiwe, Tomcat 4 must still be able to be compiled and run on a 1.2 platform. Given that the Tomcat build script converts the source code into a binary distribution that can be run on any 1.2 or later platform, the only portable thing we can do is require jndi.jar to be available at build time, so that it can be copied to the distribution (as well as used in the compile, as just patched). Note that the classloader initialization does recognize if these classes are built in, and skips jndi.jar when creating the class loader repository list on a 1.3 or later system. And the mail jar is
Re: cvs commit: jakarta-tomcat-4.0/catalina build.xml
Craig R. McClanahan [EMAIL PROTECTED] wrote: Sounds like a vote is in order, then. My thinking for the current approach is as follows: * If a JAR file is included in the official binary distribution of Tomcat, it needs to be put there by the standard build script. Otherwise, you end up with duplicate build scripts or targets (guaranteed to get out of sync over time) or manual intervention when creating a distribution (tedious, error-prone, and not repeatable). Agreed on this one. * If a JAR file is part of the official binary distribution of Tomcat, the build process should fail if it's not present. Otherwise, you run into the current situation with Tomcat 3.2 -- if you build 3.2 without the JSSE jar files, the build silently succeeds -- but the SSLSocketFactory you need is not built, and you cannot use this distro to run https connections even if you *do* install the JSSE jar files. No, I think that in the case of JSSE, to build the binary distribution, you HAVE to have it... I don't mind downloading an extra package if I'm building from scratch. * If a JAR file is used in the core of Tomcat, or used in example applications included with Tomcat, it must be part of the official distribution, and therefore fall under the purview of the previous two rules. Otherwise, you cannot have a install and run right away user experience, and you make your users have to do the integration. Agreed on this one too.. Thus, it all comes down to which JAR files do we consider essential? This should not be too controversial in most cases. External libraries we require include: * JSSE - These are required to build (to avoid the 3.2 syndrome described above, but are not included solely because of legal requirements) I wish there was a non-restricted JSSE implementation, but I don't care about downloading that, especially now that crypto laws are far more restrictive * JNDI - The jndi.jar file is required to compile or run on a 1.2 platform at all. Therefore, it is essential until we decide to desupport 1.2, after which it could be removed. Seriously, I don't care about 1.2, so, I'm not going to give an opinion. As long as we don't drop support for 1.3 (since it's the only one available on OS/X), I'm fine. * Servlet API - Pretty obvious that we need servlet.jar for a servlet container. DOH! Built from sources every time I build tomcat! * Regular Expressions Library - Required to implement the request filters that are a standard feature. Well, we use Jakarta-Regexp, I don't see a problem with that :) * XML Parser - Required to function, so must be included. Replaceable by any parser compatible with JAXP/1.1, however. In fact I use Crimson from XML.Apache, not the standard Sun distro... I'm fine with it... * Mail and Activation - Required for the JNDI resource factories and the corresponding example application. IMHO, these things should not be optional (see the 3.2 syndrome, above), so I removed the conditional compile stuff (and updated the BUILDING.txt to document the revised requirements). Yeah, I have them installed anyway A few conditional compilation cases remain in the current build scripts. I plan to get rid of as many of them as possible before final release. Big +1... Do other developers have different opinions/votes on this issue? I believe that if you want to build a distribution from sources, you HAVE to have EVERYTHING, it's a kind of a pain if you have to download-and-setup the first time, but then you're set for a lifetime. Also, as D.J. Berstein preaches, it allows us to have all binary builds behaving in the same exact way, so, less troubles overall when thinking about support. If you don't want to build it this way, well, get a nightly build... Pier
[PATCH] manager-howto error
Hi, In the manager app howto: http://jakarta.apache.org/tomcat/tomcat-4.0-doc/manager-howto.html The example for section Deploy A New Application is wrong. The following: http://localhost:8080/manager/install?path=/barwar=file:/path/to/bar.war ought to be: http://localhost:8080/manager/install?path=/barwar=jar:file:/path/to/bar.war!/ The attached patch fixes this, and adds an example using war=jar:http://..; thanks, --Jeff Index: webapps/tomcat-docs/manager-howto.xml === RCS file: /home/cvspublic/jakarta-tomcat-4.0/webapps/tomcat-docs/manager-howto.xml,v retrieving revision 1.3 diff -u -r1.3 manager-howto.xml --- webapps/tomcat-docs/manager-howto.xml 2001/09/13 15:49:15 1.3 +++ webapps/tomcat-docs/manager-howto.xml 2001/09/14 03:06:25 @@ -179,7 +179,9 @@ source http://localhost:8080/manager/install?path=/fooamp;war=file:/path/to/foo -http://localhost:8080/manager/install?path=/baramp;war=file:/path/to/bar.war +http://localhost:8080/manager/install?path=/baramp;war=jar:file:/path/to/bar.war!/ + +http://localhost:8080/manager/install?path=/baramp;war=jar:http://server:port/to/bar.war!/ + /source pInstall and start a new web application, attached to the specified context
[Bug 3598] New: - AccessLogInterceptor throws NPE
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3598 Summary: AccessLogInterceptor throws NPE Product: Tomcat 3 Version: 3.3.x Nightly Platform: PC URL: N/A OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Just officially logging the bug mentioned on the mailing list earlier. Just activate the interceptor will all default settings. The environment is JDK 1.3.1_01, Tomcat 3.3 from CVS. AccessLogInterceptor, line 199 is: -- fw.write(request.remoteHost().toString()); -- the request.remoteHost() returns null here. Here is the stack trace: -- 2001-09-14 10:55:52 - Ctx() : Exception in R( + /contact/inquiry.vm + null) - java.lang.NullPointerException at java.io.Writer.write(Writer.java:129) at org.apache.tomcat.modules.loggers.AccessLogInterceptor.beforeCommit(AccessLogInterceptor.java:199) at org.apache.tomcat.core.OutputBuffer.realWriteBytes(OutputBuffer.java:184) at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:360) at org.apache.tomcat.core.OutputBuffer.flush(OutputBuffer.java:318) at org.apache.tomcat.core.Response.flushBuffer(Response.java:402) at org.apache.tomcat.facade.HttpServletResponseFacade.flushBuffer(HttpServletResponseFacade.java:295) at com.binarix.velocity.PumpServlet.doPost(PumpServlet.java:453) at com.binarix.velocity.PumpServlet.doGet(PumpServlet.java:151) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:497) at org.apache.tomcat.core.Handler.invoke(Handler.java:322) at org.apache.tomcat.core.Handler.service(Handler.java:235) at org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:448) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:915) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:831) at org.apache.tomcat.modules.server.Ajp13Interceptor.processConnection(Ajp13Interceptor.java:167) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:477) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:517) at java.lang.Thread.run(Thread.java:484) --
[PATCH]: TC 3.3 DependClassLoader: Handling .jar dependencies properly
Just reformatting the e-mail to look like an actual patch. Sorry for not
following the conventions earlier.
Bojan
---
/home/groups/devel/jakarta/jakarta-tomcat/src/share/org/apache/tomcat/util/depend/DependClassLoader.java
Tue Sep 11 17:42:11 2001
+++ src/share/org/apache/tomcat/util/depend/DependClassLoader.java Thu Sep 13
+09:05:00 2001
@@ -238,9 +238,16 @@
int idx=fileN.indexOf( ! );
if( idx=0 )
fileN=fileN.substring( 0, idx) ;
- f=new File( fileN );
- if( debug 0 ) log( Jar dep +f );
- if( ! f.exists()) f=null;
+
+try{
+ f=new File(new URL(fileN).getFile());
+ if( debug 0 ) log( Jar dep +f );
+ if( ! f.exists()) f=null;
+} catch(NullPointerException npe){
+ f=null;
+} catch(MalformedURLException mue){
+ f=null;
+}
}
if( f==null ) return;
Re: cvs commit: jakarta-tomcat-4.0/catalina build.xml
Craig R. McClanahan wrote: I am not talking about what API's/jar files are required to build Tomcat 4. The only place my tests were used was to determine if the jar file should get copied into $CATALINA_HOME/common/lib when I do a build. The official distribution you build will still contain all the jar files you want. And if someone is building Tomcat 4 from source and follow your directions for building they to will get those jar files copied into common/lib. If they fail to follow your directions for configuring the build.properties file either the build will break or the required jars will not be available at runtime. Hopefully someone building from source is clueful enough to figure that out. This doesn't affect the binary distribution, which is where the support questions come from. I don't see anything wrong with making the _build_ a bit flexible instead of forcing all who build Tomcat 4 into a one size fits all mode. I think that it's very good for big projects, because it will force you to test everything (instead of leaving out parts of the code which may be broken). Example: There was a bug in Catalina with JDK 1.3 and JNDI which was caused by having 'jndi.jar' loaded in the commonCL, which was causing a conflict with the JNDI classes loaded by the system CL. Now, if you allow developers to not have jndi.jar with JDK 1.3, that pretty much guarantees that the bug will be found out much later. Of course, there are a extreme cases, like IMO the JAF and JavaMail. I say it's time to create that 'modules' repository and put these factories there (but that can wait for the next release) :) Remy
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/loggers AccessLogInterceptor.java
costin 01/09/13 21:07:46
Modified:src/share/org/apache/tomcat/modules/loggers
AccessLogInterceptor.java
Log:
Flush and close the log, patch from Mike Schrag [EMAIL PROTECTED]
Fix NPE reported by Bojan Smojver [EMAIL PROTECTED].
Submitted by: Mike Schrag [EMAIL PROTECTED]
Revision ChangesPath
1.5 +14 -1
jakarta-tomcat/src/share/org/apache/tomcat/modules/loggers/AccessLogInterceptor.java
Index: AccessLogInterceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/loggers/AccessLogInterceptor.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- AccessLogInterceptor.java 2001/09/07 04:51:45 1.4
+++ AccessLogInterceptor.java 2001/09/14 04:07:46 1.5
@@ -196,7 +196,10 @@
c = logformat.charAt(i);
switch (c) {
case 'h':
- fw.write(request.remoteHost().toString());
+ if( reqest.remoteHost().toString() != null )
+ fw.write(request.remoteHost().toString());
+ else
+ fw.write( DEFAULT );
break;
case 'l':
fw.write('-');
@@ -284,5 +287,15 @@
}
}
return 0;
+}
+
+public void engineShutdown(ContextManager cm) throws TomcatException {
+ // From: Mike Schrag [EMAIL PROTECTED]
+ try {
+ getFileWriter().flush();
+ getFileWriter().close();
+ } catch (IOException e) {
+ e.printStackTrace();
+ }
}
}
cvs commit: jakarta-tomcat/src/shell tomcat.sh
costin 01/09/13 21:11:20
Modified:src/shell tomcat.sh
Log:
Make tomcat.sh consitent with tomcat.bat, and better use of the
TOMCAT_INSTALL/TOMCAT_HOME.
TOMCAT_INSTALL is the directory where tomcat is installed, where bin/ and lib/ are
located.
TOMCAT_HOME is the local instance, where conf/, webapps/, work/ and log/ are located.
Larry did the cleanup on the .bat file, this is just cutpaste ( the shell script
looks a bit
more complex because we're also following symlinks in case tomcat.sh or a link to it
is in path - so the lazy user doesn't have to set the env )
( well, I'm a lazy user as I never set TOMCAT_HOME, too many instances on my machine
:-)
Revision ChangesPath
1.28 +26 -18jakarta-tomcat/src/shell/tomcat.sh
Index: tomcat.sh
===
RCS file: /home/cvs/jakarta-tomcat/src/shell/tomcat.sh,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- tomcat.sh 2001/08/22 04:55:33 1.27
+++ tomcat.sh 2001/09/14 04:11:20 1.28
@@ -1,6 +1,6 @@
#!/bin/sh
#
-# $Id: tomcat.sh,v 1.27 2001/08/22 04:55:33 costin Exp $
+# $Id: tomcat.sh,v 1.28 2001/09/14 04:11:20 costin Exp $
# Shell script to start and stop the server
@@ -23,7 +23,7 @@
# Follow symbolic links to the real tomcat.sh
# Extract the base dir.
# Look in well-known places if this fails
-if [ $TOMCAT_HOME = ] ; then
+if [ $TOMCAT_INSTALL = ] ; then
## resolve links - $0 may be a link to home
PRG=$0
progname=`basename $0`
@@ -38,40 +38,40 @@
fi
done
- TOMCAT_HOME_1=`dirname $PRG`/..
+ TOMCAT_INSTALL_1=`dirname $PRG`/..
if [ $DEBUG_HOMEFIND != false ] ; then
-echo Guessing TOMCAT_HOME from tomcat.sh to ${TOMCAT_HOME_1}
+echo Guessing TOMCAT_INSTALL from tomcat.sh to ${TOMCAT_INSTALL_1}
fi
-if [ -d ${TOMCAT_HOME_1}/conf ] ; then
- TOMCAT_HOME=${TOMCAT_HOME_1}
+if [ -d ${TOMCAT_INSTALL_1}/lib ] ; then
+ TOMCAT_INSTALL=${TOMCAT_INSTALL_1}
if [ $DEBUG_HOMEFIND != false ] ; then
- echo Setting TOMCAT_HOME to $TOMCAT_HOME
+ echo Setting TOMCAT_INSTALL to $TOMCAT_INSTALL
fi
fi
fi
-if [ $TOMCAT_HOME = ] ; then
+if [ $TOMCAT_INSTALL = ] ; then
# try to find tomcat
if [ -d ${HOME}/opt/tomcat/conf ] ; then
-TOMCAT_HOME=${HOME}/opt/tomcat
+TOMCAT_INSTALL=${HOME}/opt/tomcat
if [ $DEBUG_HOMEFIND != false ] ; then
- echo Defaulting TOMCAT_HOME to $TOMCAT_HOME
+ echo Defaulting TOMCAT_INSTALL to $TOMCAT_INSTALL
fi
fi
if [ -d /opt/tomcat/conf ] ; then
-TOMCAT_HOME=/opt/tomcat
+TOMCAT_INSTALL=/opt/tomcat
if [ $DEBUG_HOMEFIND != false ] ; then
- echo Defaulting TOMCAT_HOME to $TOMCAT_HOME
+ echo Defaulting TOMCAT_INSTALL to $TOMCAT_INSTALL
fi
fi
# Add other standard locations for tomcat
fi
-if [ $TOMCAT_HOME = ] ; then
-echo TOMCAT_HOME not set, you need to set it or install in a standard location
+if [ $TOMCAT_INSTALL = ] ; then
+echo TOMCAT_INSTALL not set, you need to set it or install in a standard
location
exit 1
fi
@@ -83,8 +83,19 @@
JSPC_OPTS=
fi
+if [ $TOMCAT_HOME = ] ; then
+if [ -d ./conf ] ; then
+ TOMCAT_HOME=.
+elif [ -d ../conf ] ; then
+ TOMCAT_HOME=..
+else
+ TOMCAT_HOME=$TOMCAT_INSTALL
+fi
+fi
+
## Find JAVA_HOME
+
if [ -z $JAVA_HOME ] ; then
JAVA=`which java`
if [ -z $JAVA ] ; then
@@ -106,12 +117,9 @@
oldCP=$CLASSPATH
unset CLASSPATH
-CLASSPATH=${TOMCAT_HOME}/lib/tomcat.jar
+CLASSPATH=${TOMCAT_INSTALL}/lib/tomcat.jar
# Ignore previous CLASSPATH
-#if [ $oldCP != ]; then
-#CLASSPATH=${CLASSPATH}:${oldCP}
-#fi
if [ -f ${JAVA_HOME}/jre/lib/rt.jar ] ; then
CLASSPATH=${CLASSPATH}:${JAVA_HOME}/jre/lib/rt.jar
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/aaa AccessInterceptor.java
costin 01/09/13 21:13:35
Modified:src/share/org/apache/tomcat/modules/aaa
AccessInterceptor.java
Log:
Remove the result of too much cutpaste - thanks Attila Szegedi
[EMAIL PROTECTED]
for pointing this out.
Revision ChangesPath
1.16 +6 -19
jakarta-tomcat/src/share/org/apache/tomcat/modules/aaa/AccessInterceptor.java
Index: AccessInterceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/aaa/AccessInterceptor.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- AccessInterceptor.java2001/09/10 06:43:02 1.15
+++ AccessInterceptor.java2001/09/14 04:13:35 1.16
@@ -465,7 +465,10 @@
}
class BasicAuthHandler extends Handler {
-int sbNote=0;
+// it goes back with the 401 response, not visible to the user
+static final String errorMessage=
+ htmlheadtitleNot Authorized/title/head+
+ bodyNot Authorized/body/html;
BasicAuthHandler() {
// setOrigin( Handler.ORIGIN_INTERNAL );
@@ -485,24 +488,8 @@
// and notify the user they are not authorized if BasicAuth fails
res.setContentType(text/html);// ISO-8859-1 default
- if( sbNote==0 ) {
- sbNote=req.getContextManager().getNoteId(ContextManager.REQUEST_NOTE,
- BasicAuthHandler.buff);
- }
-
- // we can recycle it because
- // we don't call toString();
- StringBuffer buf=(StringBuffer)req.getNote( sbNote );
- if( buf==null ) {
- buf = new StringBuffer();
- req.setNote( sbNote, buf );
- }
-
-buf.append(htmlheadtitleNot Authorized/title/head);
-buf.append(bodyNot Authorized/body/html);
-
-res.setContentLength(buf.length());
- res.getBuffer().write( buf );
+res.setContentLength(errorMessage.length());
+ res.getBuffer().write( errorMessage );
}
}
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/http Parameters.java
costin 01/09/13 21:16:35
Modified:src/share/org/apache/tomcat/util/http Parameters.java
Log:
Extra check, again result of a report from Bill Barker [EMAIL PROTECTED].
The name can become null if we have a conversion error ( i.e. the param contains
invalid
chars in the detected charset ). Bill reported a more complex problem, with charset
having
a wrong value - but this is a corner case and I doubt there is anything anyone can do
( if the browser doesn't send the charset and the user changes the encoding
during the session and it does so without first sending a page with the new encoding,
I don't know any way we could guess the new encoding )
Revision ChangesPath
1.18 +1 -0
jakarta-tomcat/src/share/org/apache/tomcat/util/http/Parameters.java
Index: Parameters.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/http/Parameters.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- Parameters.java 2001/09/09 03:14:41 1.17
+++ Parameters.java 2001/09/14 04:16:35 1.18
@@ -317,6 +317,7 @@
// incredibly inefficient data representation for parameters,
// until we test the new one
private void addParam( String key, String value ) {
+ if( key==null ) return;
String values[];
if (paramHashStringArray.containsKey(key)) {
String oldValues[] = (String[])paramHashStringArray.
[Bug 3572] - HttpSessionFacade.invalidate don't unbound Attributes
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3572 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2001-09-13 21:24 --- Can't reproduce with the recent build, and I think it should be fixed in the latest released build ( I fixed that recently ). If you still have this problem with the current nightly please reopen the bug and provide more details.
[Bug 3598] - AccessLogInterceptor throws NPE
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3598 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2001-09-13 21:33 --- Gee, this was quick! Bojan
Re: Tomcat 3.3 (JDK 1.1 compatibility fixes)
Any news on this one James ? Do you have any patch that could add jar:
support to SimpleClassLoader ? We could implement a workaround, but if
possible I would fix this by supporing jar URLs where not available.
Costin
On Fri, 7 Sep 2001, James THOMAS wrote:
I'm using IBM's JDK 1.1.8
I feel almost certain that it does not have a jar protocol handler.
I tried your suggestion but I still get the exception:
java.net.MalformedURLException: unknown protocol: jar
at java.lang.Throwable.init(Throwable.java:74)
at java.lang.Exception.init(Exception.java:38)
at java.io.IOException.init(IOException.java:38)
at
java.net.MalformedURLException.init(MalformedURLException.java:38)
at java.net.URL.init(URL.java:201)
at java.net.URL.init(URL.java:222)
Looking at JDK 1.1.8 javadoc it seems that a URL Handler for the protocol
is created:
If this is the first URL object being created with the specified
protocol, a stream protocol handler object, an instance of class
URLStreamHandler, is created for that protocol:
James
==
==
Thanks again James.
I think I understand now.
First question - what VM are you using ? JDK1.1.8 ( Sun and IBM ) seem to
have handlers for jar protocol ( even if it's not standard AFAIK ). Long
time ago I tested with kaffe and it worked - but I'm not sure I tested
getResource().
The real problem is not in DependClassLoader, but SimpleClassLoader, where
getResource() is implemented. Even if we 'hack' DCL to not call
getResource(), I think it would be better, as you sugest, to add code to
support the jar protocol.
The problem is in SCL.getResource(), the code is:
// a jar:-URL *could* change even between minor releases, but
// didn't between JVM's 1.1.6 and 1.3beta. Tested on JVM's from
// IBM, Blackdown, Microsoft, Sun @ Windows and Sun @ Solaris
if( r.zipEntry != null ) {
try {
return new URL(jar:file: +
r.repository.getPath() + !/ +
name);
} catch(java.net.MalformedURLException badurl) {
One thing you can try ( and may work ) is to replace this with
new URL(jar, null, r.repository.getPath() + !/ + name );
This will avoid calling the handlers ( which are used to parse the local
part ).
I agree the right solution is to add the dummy handler ( or a 'real' jar
handler ! ) in the compat package. It must at least parse the URL,
otherwise it'll brake reloading ( since getFile() is used to add the jar
location to the list of files that are checked for modifications ).
Costin
On Fri, 7 Sep 2001, James THOMAS wrote:
Thanks for the great info Costin.
Just an FYI, I did implement another solution, which was to implement a
Handler class for the jar protocol. Interestingly enough, it was
sufficient to only have a class that is responsible for the jar
protocol.
The implementation of the class could be crap because it is never used.
The explanation behind this is implementation of the DependClassLoader:
Basic Algorithm of loadClassInternal:
1) If class is already loaded, return it.
2) obtain the class as a resource from parent (but will don't construct
the Class yet). If the resource is not found, then throw a
ClassNotFoundException. This is where we are failing today because the
jar protocol does not have a handler in JDK 1.1
3) load the class from parent2 and return it if found.
4) no create the class from the resource loaded in step 2
By having a handler for the jar protocol, we get a non-null URL in step
2, thus avoiding the ClassNotFoundException. And in my testing,
parent2
was always able to load the class requested. Thus, the resource (i.e.
URL)
obtained from step 2 was never used.
===
===
Thanks James, I'm very happy to see your contributions. ( and my
appologies for not testing with 1.1 often enough ).
jakarta-tomcat-3.3-dev-src\src\share\org\apache\tomcat\util\depend\DependClassLoader.java
==
The method loadClassInternal appears to be incorrect. When loading a
class, the code first retrieves the class as a resource from the
parent
class loader. But, the return value from the getResource is not used
because the code then delegates the class loading to the parent2
class
loader (parent2.loadClass(name)). When running with JDK 1.1, the
getResource returns null because the jar protocol is not valid (the
exception message unknown protocol: jar is thrown from
SimpleClassLoader
where a
Env variables (Re: cvs commit: jakarta-tomcat/src/shell tomcat.sh)
On Fri, Sep 14, 2001 at 04:11:20AM -, [EMAIL PROTECTED] wrote: ( well, I'm a lazy user as I never set TOMCAT_HOME, too many instances on my machine :-) I think that's useful advice generally. If the startup script of your app can automagically figure out the *_HOME directory, let it. A wrongly set TOMCAT_HOME left over from a previous installation (or ANT_HOME, etc) can cause lots of confusion. --Jeff
Re: cvs commit: jakarta-tomcat-4.0/catalina build.xml
Well, I would have prefered to not have this subject opened up... My understanding of the Apache License is that a product/build distributed by ASF should contain only code and libraries that have Apache license or something that is compatible. I agree with most of Craig's argument, as long as we are sure we can indeed distribute those files in the first place ( somone more familiar with apache licensing can answer this ). And I'm not sure I agree with having compile-time dependencies on code that we can't distribute - that's the reason 3.x doesn't depend on JSSE nor J2EE ( even if it includes modules that would enable this functionality ). Also, I believe pieces of code that depend on non-distributable code should be optional - the release should be built to include them, but the code should work fine if they are not present. Costin On Thu, 13 Sep 2001, Remy Maucherat wrote: Craig R. McClanahan wrote: I am not talking about what API's/jar files are required to build Tomcat 4. The only place my tests were used was to determine if the jar file should get copied into $CATALINA_HOME/common/lib when I do a build. The official distribution you build will still contain all the jar files you want. And if someone is building Tomcat 4 from source and follow your directions for building they to will get those jar files copied into common/lib. If they fail to follow your directions for configuring the build.properties file either the build will break or the required jars will not be available at runtime. Hopefully someone building from source is clueful enough to figure that out. This doesn't affect the binary distribution, which is where the support questions come from. I don't see anything wrong with making the _build_ a bit flexible instead of forcing all who build Tomcat 4 into a one size fits all mode. I think that it's very good for big projects, because it will force you to test everything (instead of leaving out parts of the code which may be broken). Example: There was a bug in Catalina with JDK 1.3 and JNDI which was caused by having 'jndi.jar' loaded in the commonCL, which was causing a conflict with the JNDI classes loaded by the system CL. Now, if you allow developers to not have jndi.jar with JDK 1.3, that pretty much guarantees that the bug will be found out much later. Of course, there are a extreme cases, like IMO the JAF and JavaMail. I say it's time to create that 'modules' repository and put these factories there (but that can wait for the next release) :) Remy
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/depend DependClassLoader.java
costin 01/09/13 21:58:30 Modified:src/share/org/apache/tomcat/util/depend DependClassLoader.java Log: Fix from Bojan Smojver [EMAIL PROTECTED], jar deps had the protocol in it. Submitted by: Bojan Smojver [EMAIL PROTECTED] Revision ChangesPath 1.9 +6 -3 jakarta-tomcat/src/share/org/apache/tomcat/util/depend/DependClassLoader.java Index: DependClassLoader.java === RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/depend/DependClassLoader.java,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- DependClassLoader.java2001/09/07 04:25:20 1.8 +++ DependClassLoader.java2001/09/14 04:58:30 1.9 @@ -87,7 +87,7 @@ protected ClassLoader parent; protected ClassLoader parent2; -final static int debug=0; +final static int debug=10; DependManager dependM; protected Object pd; static Jdk11Compat jdkCompat=Jdk11Compat.getJdkCompat(); @@ -238,8 +238,11 @@ int idx=fileN.indexOf( ! ); if( idx=0 ) fileN=fileN.substring( 0, idx) ; - f=new File( fileN ); - if( debug 0 ) log( Jar dep +f ); + // Bojan Smojver [EMAIL PROTECTED]: remove jar: + if( fileN.startsWith( jar: )) + fileN=fileN.substring( 4 ); + f=new File(fileN); + if( debug 0 ) log( Jar dep +f + + f.exists() ); if( ! f.exists()) f=null; }
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/generators ErrorHandler.java
costin 01/09/13 22:02:03
Modified:src/share/org/apache/tomcat/modules/generators
ErrorHandler.java
Log:
Bug 3233, make error handling compatible with servlet2.3 by using the clarification
from
2.3 spec ( it wasn't technically a bug, since 2.2 leaves this part unspecified ).
Thanks [EMAIL PROTECTED] (Peter Stamfest) for the patch.
I did a small change for 3.3, since the ErrorHandler sits at a lower level and
doesn't
depend on the facade ( it is part of the set of core modules ). Since error handling
is
so dependent on the servlet api, in future we could move part of it in the facade,
but
for now it should be ok.
Submitted by: Peter Stamfest
Revision ChangesPath
1.18 +23 -1
jakarta-tomcat/src/share/org/apache/tomcat/modules/generators/ErrorHandler.java
Index: ErrorHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/generators/ErrorHandler.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- ErrorHandler.java 2001/08/25 18:14:27 1.17
+++ ErrorHandler.java 2001/09/14 05:02:03 1.18
@@ -67,8 +67,8 @@
import java.net.*;
import java.util.*;
import java.security.*;
+import java.lang.reflect.*;
-
import org.apache.tomcat.util.log.*;
/**
@@ -299,6 +299,28 @@
String name = clazz.getName();
errorPath = ctx.getErrorPage(name);
clazz = clazz.getSuperclass();
+ }
+
+ // Bug 3233, [EMAIL PROTECTED] (Peter Stamfest)
+ if (errorPath == null ) {
+ // Use introspection - the error handler is at a lower level,
+ // doesn't depend on servlet api
+ Throwable t2=null;
+ try {
+ Method m=t.getClass().getMethod( getRootCause, new Class[] {} );
+ t2 = (Throwable)m.invoke( t, new Object[] {} );
+ } catch(Exception ex) {
+ }
+
+ if (t2 != null) {
+ clazz = t2.getClass();
+ while (errorPath == null clazz != null) {
+ String name = clazz.getName();
+ errorPath = ctx.getErrorPage(name);
+ clazz = clazz.getSuperclass();
+ }
+ }
+ if (errorPath != null) t = t2;
}
if( errorPath != null ) {
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper JspC.java
craigmcc01/09/13 22:02:15
Modified:jasper/src/share/org/apache/jasper JspC.java
Log:
Support tag library descriptors without throwing NPEs.
PR: Bugzilla #3529 and #3235
Submitted by: Based on patch submitted by Peter RoBbach ([EMAIL PROTECTED])
Revision ChangesPath
1.11 +35 -8 jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JspC.java
Index: JspC.java
===
RCS file: /home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JspC.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- JspC.java 2001/09/07 18:52:14 1.10
+++ JspC.java 2001/09/14 05:02:15 1.11
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JspC.java,v 1.10
2001/09/07 18:52:14 craigmcc Exp $
- * $Revision: 1.10 $
- * $Date: 2001/09/07 18:52:14 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JspC.java,v 1.11
2001/09/14 05:02:15 craigmcc Exp $
+ * $Revision: 1.11 $
+ * $Date: 2001/09/14 05:02:15 $
*
*
*
@@ -73,6 +73,7 @@
import org.apache.jasper.compiler.TldLocationsCache;
import org.apache.jasper.servlet.JasperLoader;
+import org.apache.jasper.servlet.JspCServletContext;
import org.apache.jasper.logging.Logger;
import org.apache.jasper.logging.JasperLogger;
@@ -351,7 +352,7 @@
File classes = new File(clctxt.getRealPath(/WEB-INF/classes));
try {
if (classes.exists()) {
- urls.add(classes.toURL());
+ urls.add(classes.getCanonicalFile().toURL());
}
} catch (IOException ioe) {
// failing a toCanonicalPath on a file that
@@ -367,7 +368,7 @@
File libFile = new File(lib.toString()
+ File.separator
+ libs[i]);
- urls.add(libFile.toURL());
+ urls.add(libFile.getCanonicalFile().toURL());
} catch (IOException ioe) {
// failing a toCanonicalPath on a file that
// exists() should be a JVM regression test,
@@ -377,9 +378,25 @@
}
}
}
- URLClassLoader loader = new URLClassLoader(
- (URL[])(urls.toArray(new URL[urls.size()])),null);
- clctxt.setClassLoader(loader);
+StringTokenizer tokenizer = new StringTokenizer
+(clctxt.getClassPath(), File.pathSeparator);
+while (tokenizer.hasMoreTokens()) {
+String path = tokenizer.nextToken();
+try {
+File libFile = new File(path);
+urls.add(libFile.toURL());
+} catch (IOException ioe) {
+// Failing a toCanonicalPath on a file that
+// exists() should be a JVM regression test,
+// therefore we have permission to freak uot
+throw new RuntimeException(ioe.toString());
+}
+}
+urls.add(new File
+ (clctxt.getRealPath(/)).getCanonicalFile().toURL());
+URLClassLoader loader = new URLClassLoader
+((URL[])(urls.toArray(new URL[urls.size()])));
+clctxt.setClassLoader(loader);
CommandLineCompiler clc = new CommandLineCompiler(clctxt);
clc.compile();
@@ -628,6 +645,16 @@
mappingout = null;
}
+try {
+JspCServletContext context =
+new JspCServletContext
+(new PrintWriter(System.out),
+ new URL(file: + ubase.replace('\\','/') + /));
+tldLocationsCache = new TldLocationsCache(context);
+} catch (MalformedURLException me) {
+System.out.println(** + me);
+}
+
Enumeration e = pages.elements();
while (e.hasMoreElements())
{
[Bug 3589] - Cannot process Taglib TLD when deployed through EmbeddedManager MBean
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3589 --- Additional Comments From [EMAIL PROTECTED] 2001-09-13 22:21 --- I tried reproducing the problem with the Embedded class itself, using the included example (the Main method), and Webwork 0.95. To summarize, it worked for me. I put all the jars in my server/lib dir, and typed: java -Dcatalina.home=D:\cvs\jakarta-tomcat-4.0\build -cp jakarta-regexp- 1.2.jar;jaxp.jar;crimson.jar;catalina.jar;servlets-common.jar;servlets- cgi.jar;servlets-cgi.jar;servlets-default.jar;servlets-invoker.jar;servlets- manager.jar;servlets-snoop.jar;servlets-ssi.jar;servlets- webdav.jar;naming.jar;resources.jar;servlet.jar;bootstrap.jar;jasper- compiler.jar;jasper-runtime.jar;namingfactory.jar;tools.jar org.apache.catalina.startup.Embedded In Embedded.Main, I added: Context webwork = embedded.createContext(/webwork, home + /webapps/webwork); host.addChild(webwork); The logs are (with a few added debug lines): snip/ XmlMapper: org.apache.catalina.core.StandardContext.addServletMapping( *.action, action) XmlMapper: org.apache.catalina.core.StandardContext.addWelcomeFile( index.jsp) XmlMapper: org.apache.catalina.core.StandardContext.addTaglib( webwork, /WEB- INF/lib/webwork.jar) XmlMapper: Debug level: 3 XmlMapper: Validating = true ContextConfig[/webwork]: Scanning web.xml tag libraries ContextConfig[/webwork]: URI='webwork', ResourcePath='/WEB- INF/lib/webwork.jar' ContextConfig[/webwork]: tldConfigJar(/WEB-INF/lib/webwork.jar): Processing entry 'META-INF/taglib.tld' XmlMapper: Set locator : org.apache.crimson.parser.Parser2$DocLocator@7ebe1 Resolve: -//Sun Microsystems, Inc.//DTD JSP Tag Library 1.1//EN http://java.sun.com/j2ee/dtds/web-jsptaglib_1_1.dtd Using alternate DTD /javax/servlet/jsp/resources/web-jsptaglibrary_1_1.dtd ContextConfig[/webwork]: Scanning library JAR files ContextConfig[/webwork]: tldConfigJar(/WEB-INF/lib/webwork.jar): Processing entry 'META-INF/taglib.tld' XmlMapper: Set locator : org.apache.crimson.parser.Parser2$DocLocator@d85f79 Resolve: -//Sun Microsystems, Inc.//DTD JSP Tag Library 1.1//EN http://java.sun.com/j2ee/dtds/web-jsptaglib_1_1.dtd Using alternate DTD /javax/servlet/jsp/resources/web-jsptaglibrary_1_1.dtd ContextConfig[/webwork]: Added certificates - request attribute Valve ContextConfig[/webwork]: Pipline Configuration: ContextConfig[/webwork]: org.apache.catalina.valves.CertificatesValve/1.0 ContextConfig[/webwork]: org.apache.catalina.core.StandardContextValve/1.0 ContextConfig[/webwork]: == StandardContext[/webwork]: Configuring application event listeners snip/ To add additional info, apply this patch to the ContextConfig source: RCS file: /home/cvs/jakarta-tomcat- 4.0/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v retrieving revision 1.52 diff -r1.52 ContextConfig.java 1112a1113 e.printStackTrace(); That should tell us which operation caused the problem. Note: All this is tested using Win2k + JDK 1.4 b2
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/depend DependClassLoader.java
costin 01/09/13 22:20:32 Modified:src/share/org/apache/tomcat/util/depend DependClassLoader.java Log: Disable the debug. Revision ChangesPath 1.10 +1 -1 jakarta-tomcat/src/share/org/apache/tomcat/util/depend/DependClassLoader.java Index: DependClassLoader.java === RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/depend/DependClassLoader.java,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- DependClassLoader.java2001/09/14 04:58:30 1.9 +++ DependClassLoader.java2001/09/14 05:20:32 1.10 @@ -87,7 +87,7 @@ protected ClassLoader parent; protected ClassLoader parent2; -final static int debug=10; +final static int debug=0; DependManager dependM; protected Object pd; static Jdk11Compat jdkCompat=Jdk11Compat.getJdkCompat();
cvs commit: jakarta-tomcat-4.0 RELEASE-PLAN-4.0.txt
craigmcc01/09/13 22:20:55 Modified:.RELEASE-PLAN-4.0.txt Log: Update final Release Plan status for 4.0-rc2. Revision ChangesPath 1.15 +26 -18jakarta-tomcat-4.0/RELEASE-PLAN-4.0.txt Index: RELEASE-PLAN-4.0.txt === RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-PLAN-4.0.txt,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- RELEASE-PLAN-4.0.txt 2001/09/13 16:39:52 1.14 +++ RELEASE-PLAN-4.0.txt 2001/09/14 05:20:55 1.15 @@ -1,4 +1,4 @@ -$Id: RELEASE-PLAN-4.0.txt,v 1.14 2001/09/13 16:39:52 craigmcc Exp $ +$Id: RELEASE-PLAN-4.0.txt,v 1.15 2001/09/14 05:20:55 craigmcc Exp $ Release Plan for Apache Tomcat 4.0 == @@ -23,7 +23,7 @@ Sunday, September 9, 2001 Tomcat 4.0 Release Candidate 1 - Wednesday, September 12, 2001 Tomcat 4.0 Release Candidate 2 + Thursday, September 13, 2001Tomcat 4.0 Release Candidate 2 Monday, September 17, 2001 Tomcat 4.0 Final Release @@ -46,11 +46,6 @@ Bugs That Must Be Addressed Before Final Release: -Catalina3511Line too long (awaiting reproducible failure case) - -Catalina3515Process hanging after stopping Tomcat (awaiting -reproducible failure case) - Connectors 2997Webapp connector should recover when Tomcat is restarted Connectors 3476Cannot use other than default context when using mod_webapp @@ -58,22 +53,11 @@ Connectors 3509Apache 1.3.20 and mod_webapp and Tomcat 4b7 HANGS (likely to be the same issue as 1788) -Connectors 3510With WARP request.getScheme() returns http instead of https - Connectors 3534File Upload doesn't work with Apache, mod_webapp, Tomcat 4 Connectors 3574Basic authentication doesn't work through connector -Jasper 3079NullPointerException in JakartaCommentGenerator.generateEnd -(awaiting reproducible failure case) -Jasper 3127jsp:directive.include/ not supported (awaiting -reproducible failure case) - -Jasper 3529JSPC can't handle taglibs in RC1 (dup of 3235, -includes a proposed patch) - - Nice To Have Fixes Before Final Release: --- @@ -84,4 +68,28 @@ Servletapi 3196Javadoc errors during build Servletapi 3344Typo in javadocs + + +Unconfirmed Bugs (Awaiting Reproducible Failure Case): +- + +Catalina3511Line too long (awaiting reproducible failure case) + +Catalina3515Process hanging after stopping Tomcat (awaiting +reproducible failure case) + +Catalina3589Cannot process taglib TLD when deployed through +EmbeddedManagerMBean + +Catalina3594Have to reload page or page will not be shown +(awaiting reproducible failure case, likely user error) + +Catalina3597Shutting down takes *ages* (not confirmed against +latest Tomcat 4.0 build) + +Jasper 3079NullPointerException in JakartaCommentGenerator.generateEnd +(awaiting reproducible failure case) + +Jasper 3127jsp:directive.include/ not supported (awaiting +reproducible failure case)
