Filters and Transfer-Encoding: chunked
I am facing a problem when useing a filter. The problem is that the "Transfer-Encoding" header does not appear to be getting set. In this case the filter is doing some simple xsl transformations and passing on the results to the response's output stream. Unfortunatly because the content is not being chunked by Tomcat the socket just sits there open. I'm not sure how tomcat knows to chunk the data. When working with an unfiltered jsp page the data gets chunked as expected. Does the filter need to do anything to "chunk" the data? Thanks, Robert Petersen
Re: [STATUS] Tomcat 3.2.2 beta 2
Marc, thanks many times for making this happen. I would like to ask about the status of one particular issue. This is a long outstanding issue whose one effect is that you can not serve files with file names containing multibyte characters. I can still reproduce this problem in 3.2.2 b2. I talked to Costin about this some time ago, and from what I understand, he thinks this problem is difficult to tackle in the 3.2 source base, and that the solution is only possible in 3.3 and 4.0, so I don't much hope that this can be fixed for 3.2.2 final. Either way, I think this should be at least documented in the release notes. To reproduce: 1) Create a file under the document base and name it so it contains characters in a multibyte character set (Japanese, Korean, ...) 2) Type its URL into a web browser I didn't see a bugzilla entry for this, should I create one ? Costin, do you know anything about this issue ? Is my description accurate ? Thanks Petr - Original Message - From: "Marc Saegesser" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, March 24, 2001 12:02 AM Subject: [STATUS] Tomcat 3.2.2 beta 2 The tomcat_322_b2 tag is now available. The binary and source distributions have been uploaded. I've got a couple more download tests to finish before I update the website and send the announcement messages. If anyone has binaries that they want included in the distribution please send them to me and I'll add them to the download area. Thanks for everyone help getting this release wrapped up.
Listeners
Tomcat 4.0 stops configuring listeners if one of the listeners in the list isn't present, should it carry on configuring the rest of the listeners it finds? The spec is silent on this and it seems odd that if somebody (maybe accidentally) deletes a listener class all other following listeners are not configured (any listener preceding the missing listener would already have been initialised). I've also raised this as a bug, Thanks, Kevin
RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
--- Steve Downey [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, March 26, 2001 1:08 PM To: [EMAIL PROTECTED] Subject: Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet Hi Mel, In my view, jasper is composed from at least 5 big components: 1. The jsp-java translator. 2. The java-class compiler 3. The Mangler ( managing name mappings ) 4. Runtime - that should be completely independent of all other pieces, since jasper-generated servlets should run without jasper ( as simple servlets ) 5. Interface with the serlvet container ( JspServlet, JspInterceptor and the associated classes). ( putting all other components togheter ) Layer 5 has to include the JspC/CommandLineXXX components, also. They have to provide an environment that looks to the rest of the JSP compiler like a web context, while actually interacting more closely with the filesystem. I'm not going to make it a primary goal to fix JspC, but I should be able to make the components reusable so that a new version of JspC could be refactored to use the same classes as this new version of JspServlet. Mangler needs some work, too. JspC and JspServlet have drifted in their implementations. The bane of code sharing by cut and paste. I will try to address this as well. Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/?.refer=text
RE: [STATUS] Tomcat 3.2.2 beta 2
Petr, Bug 875 may be related to what your seeing. I can duplicate this one. Bug 463 looks like it might be the same problem. Neither of these will be addressed in Tomcat 3.2.2, but once that release is out the code freeze will be lifted an we can work on addressing these and other issues. I don't see a bug report about entering Japanese text in the URL. Note that RFD2396 doesn't support non-ASCII characters in URIs and also doesn't specify what character encoding should be used for %HH escaped characters. The Internationalization resources on the W3C site say that the preferred encoding is UTF-8. Can you verify that the Japanese characters you enter in the URL are actually being correctly encoded in the HTTP request? http://www.w3.org/International/O-URL-and-ident.html Marc Saegesser -Original Message- From: Petr Jiricka [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 27, 2001 5:30 AM To: [EMAIL PROTECTED] Subject: Re: [STATUS] Tomcat 3.2.2 beta 2 Marc, thanks many times for making this happen. I would like to ask about the status of one particular issue. This is a long outstanding issue whose one effect is that you can not serve files with file names containing multibyte characters. I can still reproduce this problem in 3.2.2 b2. I talked to Costin about this some time ago, and from what I understand, he thinks this problem is difficult to tackle in the 3.2 source base, and that the solution is only possible in 3.3 and 4.0, so I don't much hope that this can be fixed for 3.2.2 final. Either way, I think this should be at least documented in the release notes. To reproduce: 1) Create a file under the document base and name it so it contains characters in a multibyte character set (Japanese, Korean, ...) 2) Type its URL into a web browser I didn't see a bugzilla entry for this, should I create one ? Costin, do you know anything about this issue ? Is my description accurate ? Thanks Petr - Original Message - From: "Marc Saegesser" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, March 24, 2001 12:02 AM Subject: [STATUS] Tomcat 3.2.2 beta 2 The tomcat_322_b2 tag is now available. The binary and source distributions have been uploaded. I've got a couple more download tests to finish before I update the website and send the announcement messages. If anyone has binaries that they want included in the distribution please send them to me and I'll add them to the download area. Thanks for everyone help getting this release wrapped up.
Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
--- Glenn Nielsen [EMAIL PROTECTED] wrote: I have made some changes to the Jasper code in Tomcat 4 that you might want to look at. I will definitely be looking at TC 4. 1. In general the Java SecurityManager implemenation in Tomcat 4 and Jasper has significant improvements and is much cleaner. I copied some of this in my current implementation. Shoudn't be too hard to keep it in when I port. 2. Jasper class loading is much simpler in the Tomcat 4 version. It uses a single URLClassLoader for each JSP page, this allowed me to simplify a great deal how Jasper handles generation of class and package names (no more need to do incremental .java and .class files). And it removed alot of overhead at both JSP translation and runtime when Jasper tries to figure out which incremental class file to use/check. This sped up JSP compiles by 33% and runtime execution by 25%. The refactoring I propose would indeed use one class-loader per page. My current implementation does this leveraging a subclass of JasperLoader but I'll explore using URLClassLoader. I would need to make sure that it is compatible with jdk1.1 (a tc3.3 requirement) so if I used URLClassLoader, I'd need to provide a jdk1.1 replacement ala the way tomcat startup does. This actually should be pretty easy since I'm getting the loader via a factory method. And before you ask, I just don't have the time to back port these changes in TC3.3. Don't worry - I totally understand this! :-) mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/?.refer=text
Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/session SimpleSessionStore.java
--- [EMAIL PROTECTED] wrote: However, this does point to the need for default behavior of tomcat session generation code (or any interceptor or module code) in the absence of expected configuration info in server.xml. That's a good point, but I'm wondering how could it be implemented. The whole idea of modules is that each can be replaced with a better version ( for example a more secure or more efficient scheme to generate the ids ), so we can't just check for specific modules. Well, there is a solution ( I'm not sure how can we code it ) - have an automated way to run watchdog and sanity to validate the config files. If watchdog/sanity are passing - then probably the config is valid :-) I'm not sure exactly the best way to do it here, since I have not had the time to follow all the code involved with session management. However, I do know that request.getSession() is a fundamental method of the API that should NOT crash just because the deployer has not specified a configuration option. The implementation of a specification should ALWAYS supply a default behavior that either works gracefully with default options OR fails gracefully while informing the deployment engineer or developer about the missing/incorrect configuration settings. If SimpleSessionManager/ServletSession can not work with a 'null' value for the Session ID, then it needs to fail gracefully or it needs to supply a default id generator. Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/?.refer=text
Re: Cause found [was Re: How do I use a non-apache naming servicewith tomcat 4?]
Craig,Remy, downloading the latest nightly build resolved my problem... thanks! ...but only after I dropped that 'big everything' jar into the common/lib folder. So there seems to be a chicken egg thing regarding what order certain components need to be in for the new tomcat to play with an alternative naming service. My InstanceListener class goes into server/lib just fine, but the support class (I.e. the one containing javax.naming) needs to go in the common area. Can you tell me why this would be? I know it's something to do with the new classloading scheme but I can't see why it would matter. -Thom "Craig R. McClanahan" wrote: On Mon, 26 Mar 2001, T. Park wrote: Hi Remy, I'm running tomcat 4 beta 1. I'll download tonight's latest build and see how I fare with that. Thanks so much for the support! -Thom p.s. is there a b2 drop in the near future - I'm trying to focus my integration efforts on the nearest milestone build. There will be soon, but I've been notified that someone is working on a "real" patch for the sealing violation problems under JDK 1.3 JVMs. I'd like to give him a chance to finish before cutting beta 2. Since I'm going to be at O'Reilly Java Conference for the remainder of this week (I'm speaking at 4:15 on Thursday about Web Application Architectures), the earliest possible time for a beta 2 release will be this weekend. In the mean time, working with a recent nightly build will save you the time it takes to deal with issues that have already been fixed (and there have been around 200 CVS commits on Tomcat 4.0 since beta 1). Craig -- http://www.borland.com/newsgroups http://www.borland.com/devsupport/disclaim.html
Re: Multi-byte character support.
Kazuhiro, thank you for your reply, I will investigate the possibility of using tomcat 3.2.b2 - however it is likely I will need to await 3.2.2 milestone before considering it as a release candidate. -Thom Thom, From: "T. Park" [EMAIL PROTECTED] Subject: Multi-byte character support. Date: Mon, 26 Mar 2001 10:32:31 -0800 Message-ID: [EMAIL PROTECTED] Tomcat 3.2[.1] doesn't seem to like static html pages (or servlets for that matter) that offer multi-byte (non-latin) characters. Tomcat 3.2.2b2 has many i18n improvements. Would you use and check 3.2.2b3 if possible? Of cource, a few i18n problem (for example, ServletRequest#getProperty method don't return value in Unicode) isn't resolved in 3.2.2. But they will resolve them in 3.3 4.0. Kazuhiro Kazama ([EMAIL PROTECTED])NTT Network Innovation Laboratories
Re: ajp13 and tomcat restart - next (final) release + AJ13 PROPOSAL
Henri, 1) Moving op-recoverable -- I looked more carefully, and you're right -- the uploadmode flag is guarding against the situation I was thinking about. So it's fine the way it was. One (minor) naming note -- that flag gets set if there is more than 8K of request data, which can happen due to a file upload, but could also just happen normally (via a few big TEXTAREA's, for instance). So it's more large_request_mode, than upload_mode. Just to mention it... 2) Adding context/webapp load/unload. Great idea, but... One of the biggest problems with ajp13 right now is that there is no general way for TC to send a message to the Web Server. The commands you're adding would need to be sent from Tomcat to Apache, but that can only be done once Apache has forwarded a request to Tomcat and is waiting for a response (and a user servlet has its hands on the connection at that point). So I'm not sure how to add the feature you're looking for. If we could add that, we could also have Tomcat inform the web server of a general shutdown, so we could be more proactive about recycling TCP connections. -Dan GOMEZ Henri wrote: Looks about ready for more general testing. I like the new ajp13_operation. Two things: 1) l. 648 (op-recoverable = JK_FALSE). I set op-recoverable to JK_FALSE just after detected upload mode (dropped var) Find included the latest .c since I miss diff cmd under W2K rigth now. Where could we put code in Ajp13Interceptor which could be informed of context load/unload ? I'd like to add context/webapp load/unload la mod_warp :) will be new cmds in JK : LOADEDCONTEXT + WEBAPP STRING #define JK_AJP13_LOADED_CONTEXT (unsigned char)8 UNLOADEDCONTEXT + WEBAPP STRING #define JK_AJP13_UNLOADED_CONTEXT (unsigned char)9 Another proposal Strongest ACL (LOGIN + SECRET STRING + PROTOCOL SETS) #define JK_AJP13_LOGIN (unsigned char)10 Comments ? Name: jk_ajp13_worker.c jk_ajp13_worker.cType: unspecified type (application/octet-stream) Encoding: quoted-printable -- Dan Milstein // [EMAIL PROTECTED]
Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
1) I don't off-hand know of any other generalized way to make a portable JSP compiler that can be plugged into any servlet 2.2 engine other than as a servlet. I'm not sure how that limits us feature-wise, other than the fact that it adds a layer of indirection between the request on the container and the actual ultimate jsp servlet. A small performance price to pay for portability. The only problem is that the price is much higher that that: - JspServlet must manage the servlet lifecycle - the container can no longer treat jsp-generate-servlets the same as regular servlets - initialization - how can you pass init parameters to the jsp ? This is one of the worst hacks and source of counteless problems ( AFAIK - I couldn't find any clean way to do that ) - class loader problems - again, the JspServlet must duplicate and override the class loading decisions of the container - other problems and issues My point is that the servlet abstraction may not provide enough API support for what jasper need - in order to make it work you have to duplicate services that should be ofered by containers ( class loading, init, reloading, admin, etc ). I don't want to discourage you from doing that - any refactoring will help and we badly need that. I just want to give you an alternate view, based on my experience - before you repeat mistakes we've already done :-) 2) One major point of the refactoring is to minimize the role that the JspServlet plays. In the model I'm advocating it only does a couple of things: initializes jasper (i.e., creates the JspFactory) and maintain a cache of JspPageHandlers to which it passes the requests. Given this, the same role could be played by other entry mechanisms. +1 Costin
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/startup StopTomcat.java
costin 01/03/27 12:27:42
Modified:src/share/org/apache/tomcat/startup StopTomcat.java
Log:
A quick fix for StopTomcat - if the file is not found ( probably because
we run from a different machine or tomcat was rebuilt ) but
command-line params are present ( port for example ), we'll execute
instead of throwing exception.( and ignore that ajp12.id is not found )
Revision ChangesPath
1.7 +33 -27
jakarta-tomcat/src/share/org/apache/tomcat/startup/StopTomcat.java
Index: StopTomcat.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/startup/StopTomcat.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- StopTomcat.java 2001/03/25 21:53:16 1.6
+++ StopTomcat.java 2001/03/27 20:27:41 1.7
@@ -81,6 +81,8 @@
String host=null;
int port=-1;
String secret;
+// explicit command line params ( for port, host or secret )
+boolean commandLineParams=false;
public StopTomcat()
{
@@ -135,35 +137,36 @@
void stopTomcat() throws Exception {
String tchome=getTomcatHome();
- if( secret==null ) {
- try {
- BufferedReader rd=new BufferedReader
- ( new FileReader( tchome + "/conf/ajp12.id"));
- String line=rd.readLine();
-
- if( port 0 ) {
- try {
- port=Integer.parseInt( line );
- } catch(NumberFormatException ex ) {
- ex.printStackTrace();
- }
+ // read TOMCAT_HOME/conf/ajp12.id unless command line params
+ // specify a port/host/secret
+ try {
+ BufferedReader rd=new BufferedReader
+ ( new FileReader( tchome + "/conf/ajp12.id"));
+ String line=rd.readLine();
+
+ if( port 0 ) {
+ try {
+ port=Integer.parseInt( line );
+ } catch(NumberFormatException ex ) {
+ ex.printStackTrace();
}
-
- line=rd.readLine();
- if( host==null ) host=line;
- line=rd.readLine();
- if( secret==null ) secret=line;
- if( "".equals( secret ) )
- secret=null;
-
- } catch( IOException ex ) {
- //ex.printStackTrace();
- System.out.println("Can't read " + tchome + "/conf/ajp12.id");
- System.out.println(ex.toString());
- return;
}
+
+ line=rd.readLine();
+ if( host==null ) host=line;
+ line=rd.readLine();
+ if( secret==null ) secret=line;
+ } catch( IOException ex ) {
+ //ex.printStackTrace();
+ System.out.println("Can't read " + tchome + "/conf/ajp12.id");
+ // System.out.println(ex.toString());
+ if( ! commandLineParams )
+ return;
}
-
+
+ if( "".equals( secret ) )
+ secret=null;
+
System.out.println("Stoping tomcat on " + host + ":" +port +" "
+ secret);
InetAddress address=null;
@@ -257,6 +260,7 @@
}
if (arg.equals("-host") ) {
i++;
+ commandLineParams=true;
if (i args.length)
host=args[i];
else
@@ -264,6 +268,7 @@
}
if (arg.equals("-port") ) {
i++;
+ commandLineParams=true;
if (i args.length)
port=Integer.parseInt( args[i] );
else
@@ -271,7 +276,8 @@
}
if (arg.equals("-pass") ) {
i++;
- if (i args.length)
+ commandLineParams=true;
+ if (i args.length)
secret=args[i];
else
return false;
cvs commit: jakarta-tomcat-4.0/catalina/src/conf web.xml
amyroh 01/03/27 12:34:01 Modified:catalina/src/conf web.xml Log: Addition of SsiInvokerServlet definition and the mapping for SSI Revision ChangesPath 1.15 +27 -0 jakarta-tomcat-4.0/catalina/src/conf/web.xml Index: web.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/web.xml,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- web.xml 2001/03/14 22:36:36 1.14 +++ web.xml 2001/03/27 20:34:00 1.15 @@ -58,6 +58,27 @@ load-on-startup4/load-on-startup /servlet + !-- SSIInvoker Servlet -- + servlet +servlet-namessi/servlet-name +servlet-classorg.apache.catalina.servlets.SsiInvokerServlet/servlet-class +init-param + !-- debug 0 == debug enabled -- + param-namedebug/param-name + param-value0/param-value +/init-param +init-param + !-- time in seconds before the SSI page expires -- + param-nameexpires/param-name + param-value666/param-value +/init-param +init-param + !-- 0 == false; 1 == true -- + param-namebuffered/param-name + param-value1/param-value +/init-param +load-on-startup5/load-on-startup + /servlet !-- The mapping for the default servlet -- servlet-mapping @@ -79,6 +100,12 @@ url-pattern*.jsp/url-pattern /servlet-mapping + !-- The mapping for SSI-- + servlet-mapping +servlet-namessi/servlet-name +url-pattern*.shtml/url-pattern + /servlet-mapping + !-- Set the default session timeout (in seconds) -- session-config session-timeout30/session-timeout
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/ssi - New directory
amyroh 01/03/27 12:34:28 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/ssi - New directory
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets SsiInvokerServlet.java
amyroh 01/03/27 12:36:50
Added: catalina/src/share/org/apache/catalina/servlets
SsiInvokerServlet.java
Log:
Servlet to process SSI requests
Revision ChangesPath
1.1
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/SsiInvokerServlet.java
Index: SsiInvokerServlet.java
===
/*
* SsiInvokerServlet.java
* $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/SsiInvokerServlet.java,v
1.1 2001/03/27 20:36:50 amyroh Exp $
* $Revision: 1.1 $
* $Date: 2001/03/27 20:36:50 $
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* "This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/)."
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
*Foundation" must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called "Apache"
*nor may "Apache" appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
* [Additional notices, if required by prior licensing conditions]
*
*/
package org.apache.catalina.servlets;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.io.BufferedInputStream;
import java.io.ByteArrayOutputStream;
import java.util.Date;
import java.util.TimeZone;
import java.util.Locale;
import java.util.StringTokenizer;
import java.text.SimpleDateFormat;
import javax.servlet.ServletException;
import javax.servlet.ServletContext;
import javax.servlet.ServletOutputStream;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.naming.directory.DirContext;
import javax.naming.directory.Attribute;
import javax.naming.directory.Attributes;
import javax.naming.NamingException;
import javax.naming.InitialContext;
import org.apache.catalina.Globals;
import org.apache.catalina.util.RequestUtil;
import org.apache.catalina.util.ssi.SsiCommand;
import org.apache.catalina.util.ssi.SsiMediator;
import org.apache.catalina.util.ssi.ServletOutputStreamWrapper;
import org.apache.naming.resources.Resource;
import org.apache.naming.resources.ResourceAttributes;
/**
* Servlet to process SSI requests within a webpage.
* Mapped to a path from within web.xml.
*
* @author Bip Thelin
* @version $Revision: 1.1 $, $Date: 2001/03/27 20:36:50 $
*/
public final class SsiInvokerServlet extends HttpServlet {
/** Debug level for
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets SsiInvokerServlet.java
amyroh 01/03/27 12:44:25
Modified:catalina/src/share/org/apache/catalina/servlets
SsiInvokerServlet.java
Log:
Update submitted by Bip Thelin --
"changed any dependencies on Craig's ResourceInfo class which I included as an
Inline class. This makes the code more streamlined and maintainable."
Revision ChangesPath
1.2 +7 -161
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/SsiInvokerServlet.java
Index: SsiInvokerServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/SsiInvokerServlet.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- SsiInvokerServlet.java2001/03/27 20:36:50 1.1
+++ SsiInvokerServlet.java2001/03/27 20:44:24 1.2
@@ -1,8 +1,8 @@
/*
* SsiInvokerServlet.java
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/SsiInvokerServlet.java,v
1.1 2001/03/27 20:36:50 amyroh Exp $
- * $Revision: 1.1 $
- * $Date: 2001/03/27 20:36:50 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/SsiInvokerServlet.java,v
1.2 2001/03/27 20:44:24 amyroh Exp $
+ * $Revision: 1.2 $
+ * $Date: 2001/03/27 20:44:24 $
*
*
*
@@ -69,6 +69,8 @@
import java.io.OutputStream;
import java.io.BufferedInputStream;
import java.io.ByteArrayOutputStream;
+import java.net.URL;
+import java.net.URLConnection;
import java.util.Date;
import java.util.TimeZone;
import java.util.Locale;
@@ -90,15 +92,13 @@
import org.apache.catalina.util.ssi.SsiCommand;
import org.apache.catalina.util.ssi.SsiMediator;
import org.apache.catalina.util.ssi.ServletOutputStreamWrapper;
-import org.apache.naming.resources.Resource;
-import org.apache.naming.resources.ResourceAttributes;
/**
* Servlet to process SSI requests within a webpage.
* Mapped to a path from within web.xml.
*
* @author Bip Thelin
- * @version $Revision: 1.1 $, $Date: 2001/03/27 20:36:50 $
+ * @version $Revision: 1.2 $, $Date: 2001/03/27 20:44:24 $
*/
public final class SsiInvokerServlet extends HttpServlet {
/** Debug level for this servlet. */
@@ -113,17 +113,6 @@
/** The Mediator object for the SsiCommands. */
private static SsiMediator ssiMediator = null;
-/** JNDI resources name. */
-protected static final String RESOURCES_JNDI_NAME = "java:/comp/Resources";
-
-/** The set of SimpleDateFormat formats to use in getDateHeader(). */
-protected static final SimpleDateFormat[] formats = {
- new SimpleDateFormat("EEE, dd MMM HH:mm:ss zzz", Locale.US),
- new SimpleDateFormat("EE, dd-MMM-yy HH:mm:ss zzz", Locale.US),
- new SimpleDateFormat("EEE d HH:mm:ss ", Locale.US)
-};
-protected final static TimeZone gmtZone = TimeZone.getTimeZone("GMT");
-
/** The start pattern */
private final static byte[] bStart = {
(byte)'',(byte)'!',(byte)'-',(byte)'-',(byte)'#'
@@ -134,11 +123,6 @@
(byte)'-',(byte)'-',(byte)''
};
-static {
-formats[0].setTimeZone(gmtZone);
-formats[1].setTimeZone(gmtZone);
-formats[2].setTimeZone(gmtZone);
-}
//- Public methods.
/**
@@ -154,7 +138,6 @@
;
}
try {
-// adapted from JSSI
value = getServletConfig().getInitParameter("expires");
expires = Long.valueOf(value);
} catch (NumberFormatException e) {
@@ -219,10 +202,9 @@
HttpServletResponse res)
throws IOException, ServletException {
-DirContext resources = getResources();
ServletContext servletContext = getServletContext();
String path = getRelativePath(req);
-ResourceInfo resourceInfo = new ResourceInfo(path, resources);
+ URL resource = servletContext.getResource(path);
if (debug 0)
log("SsiInvokerServlet.requestHandler()\n" +
@@ -239,7 +221,7 @@
return;
}
- if (!resourceInfo.exists) {
+ if (resource==null) {
res.sendError(res.SC_NOT_FOUND, path);
return;
}
@@ -250,12 +232,12 @@
}
OutputStream out = null;
-InputStream resourceInputStream =
- servletContext.getResourceAsStream(path);
+ URLConnection resourceInfo = resource.openConnection();
+InputStream resourceInputStream = resourceInfo.getInputStream();
InputStream in = new BufferedInputStream(resourceInputStream, 4096);
ByteArrayOutputStream soonOut =
- new
SSI feature addition to tomcat4 by Bip Thelin
Thanks to great work by Bip Thelin, SSI feature is now added to tomcat 4. Stay tune for CGI/SSI exec command. Amy
cvs commit: jakarta-tomcat/src/doc Tomcat-on-NetWare-HowTo.html
marcsaeg01/03/27 13:29:30 Added: src/doc Tag: tomcat_32 Tomcat-on-NetWare-HowTo.html Log: Adding new "how to" document for Tomcat on NetWare. Submitted by:Mike Anderson [[EMAIL PROTECTED]] Revision ChangesPath No revision No revision 1.1.2.1 +348 -0jakarta-tomcat/src/doc/Attic/Tomcat-on-NetWare-HowTo.html
Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
--- [EMAIL PROTECTED] wrote: 1) I don't off-hand know of any other generalized way to make a portable JSP compiler that can be plugged into any servlet 2.2 engine other than as a servlet. I'm not sure how that limits us feature-wise, other than the fact that it adds a layer of indirection between the request on the container and the actual ultimate jsp servlet. A small performance price to pay for portability. The only problem is that the price is much higher that that: - JspServlet must manage the servlet lifecycle - the container can no longer treat jsp-generate-servlets the same as regular servlets This is a limitation of the servlet api and thus the lack of access to a consistent set of servlet engine features necessary for full servlet life-cycle management that can be relied upon. Besides, who said that the container was guaranteed full-lifecycle management of ANY servlet? Any servlet could be created/loaded dynamically and managed by some other servlet without the container ever knowing about it (assuming the SecurityManager allowed it, of course :-). - initialization - how can you pass init parameters to the jsp ? This is one of the worst hacks and source of counteless problems ( AFAIK - I couldn't find any clean way to do that ) How exactly do you solve this with JspInterceptor? The specification doesn't really seem to cover init-params for individual JSP pages. The JSP container has no responsibility to provide individualized init-params for JSP servlets, only to invoke jspInit() prior to service(). In the absence of a specified mechanism, it is the responsibility of the JSP page author to initialize his page by implementing the jspInit() method (from which he/she can optionally load params from whereever he/she sees fit). In other words, this is not a limitation of JspServlet, but rather a limitation of the JSP specification. - class loader problems - again, the JspServlet must duplicate and override the class loading decisions of the container - other problems and issues This, again is more a limitation (or too much freedom) in how servlet containers are implemented. My point is that the servlet abstraction may not provide enough API support for what jasper need - in order to make it work you have to duplicate services that should be ofered by containers ( class loading, init, reloading, admin, etc ). The glass is half-full as well - because at least with the servlet api it is _possible_ to implement those services portably and thus provide a portable JSP compiler. And yes, it would be great if the JspServlet didn't have to implement redundant container services, that in no way really limits JspServlet's ability to fullfill all JSP specification features. And again - what is the alternative? I can't write a JspInterceptor solution for WebLogic or JRun. I don't want to discourage you from doing that - any refactoring will help and we badly need that. I just want to give you an alternate view, based on my experience - before you repeat mistakes we've already done :-) The mistakes aren't in using a servlet-based approach. This sort of feature (a plug-in to provid jsp compilation and loading services to a web server) is exactly what servlets are for. This in itself in no way limits what you can do with JSPs because all features of the JSP spec should be attainable through a servlet implementation. This DOES limit the reliance Jasper can have on value-added container features beyond the servlet API, but hey, you have to draw the line somewhere. The way to look at it is that a JspInterceptor-style solution is a value-added feature of the tomcat servlet engine. That is a positive. The portability of JspServlet is also a positive. Cheers, Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/?.refer=text
cvs commit: jakarta-tomcat/src/native/mod_jk/common jk_util.c jk_util.h
hgomez 01/03/27 13:58:26
Modified:src/native/mod_jk/common jk_util.c jk_util.h
Log:
Add time stamp support in mod_jk.log
Revision ChangesPath
1.5 +39 -5 jakarta-tomcat/src/native/mod_jk/common/jk_util.c
Index: jk_util.c
===
RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/common/jk_util.c,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- jk_util.c 2001/02/05 23:22:04 1.4
+++ jk_util.c 2001/03/27 21:58:26 1.5
@@ -55,8 +55,9 @@
/***
* Description: Utility functions (mainly configuration) *
+ * Author: Henri Gomez [EMAIL PROTECTED] *
* Author: Gal Shachor [EMAIL PROTECTED] *
- * Version: $Revision: 1.4 $ *
+ * Version: $Revision: 1.5 $ *
***/
@@ -86,6 +87,7 @@
#define DEFAULT_WORKER JK_AJP12_WORKER_NAME
#define WORKER_LIST_PROPERTY_NAME ("worker.list")
#define DEFAULT_LB_FACTOR (1.0)
+#define LOG_FORMAT ("log_format")
#define HUGE_BUFFER_SIZE (8*1024)
#define LOG_LINE_SIZE(1024)
@@ -95,6 +97,27 @@
};
typedef struct file_logger file_logger_t;
+/*
+ * define the log format, we're using by default the one from error.log
+ *
+ * [Mon Mar 26 19:44:48 2001] [jk_uri_worker_map.c (155)]: Into
jk_uri_worker_map_t::uri_worker_map_alloc
+ * log format used by apache in error.log
+ */
+#ifndef JK_TIME_FORMAT
+#define JK_TIME_FORMAT "[%a %b %d %H:%M:%S %Y] "
+#endif
+
+char * jk_log_fmt = JK_TIME_FORMAT;
+
+static void set_time_str(char * str, int len)
+{
+ time_t t = time(NULL);
+ struct tm *tms;
+
+ tms = localtime(t);
+ strftime(str, len, jk_log_fmt, tms);
+}
+
static int JK_METHOD log_to_file(jk_logger_t *l,
int level,
const char *what)
@@ -211,17 +234,23 @@
if(f != file) {
f++;
}
-
+
#ifdef WIN32
-used = _snprintf(buf, HUGE_BUFFER_SIZE, "[%s (%d)]: ", f, line);
+ set_time_str(buf, HUGE_BUFFER_SIZE);
+ used = strlen(buf);
+used += _snprintf(buf[used], HUGE_BUFFER_SIZE, " [%s (%d)]: ", f, line);
#elif defined(NETWARE) // until we get a snprintf function
buf = (char *) malloc(HUGE_BUFFER_SIZE);
if (NULL == buf)
return -1;
-used = sprintf(buf, "[%s (%d)]: ", f, line);
+ set_time_str(buf, HUGE_BUFFER_SIZE);
+ used = strlen(buf);
+used += sprintf(buf[used], " [%s (%d)]: ", f, line);
#else
-used = snprintf(buf, HUGE_BUFFER_SIZE, "[%s (%d)]: ", f, line);
+ set_time_str(buf, HUGE_BUFFER_SIZE);
+ used = strlen(buf);
+used += snprintf(buf[used], HUGE_BUFFER_SIZE, " [%s (%d)]: ", f, line);
#endif
if(used 0) {
return 0; /* [V] not sure what to return... */
@@ -363,6 +392,11 @@
}
return JK_FALSE;
+}
+
+void jk_set_log_format(char * logformat)
+{
+ jk_log_fmt = (logformat) ? logformat : JK_TIME_FORMAT;
}
double jk_get_lb_factor(jk_map_t *m,
1.3 +3 -1 jakarta-tomcat/src/native/mod_jk/common/jk_util.h
Index: jk_util.h
===
RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/common/jk_util.h,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- jk_util.h 2000/11/10 18:48:50 1.2
+++ jk_util.h 2001/03/27 21:58:26 1.3
@@ -56,7 +56,7 @@
/***
* Description: Various utility functions *
* Author: Gal Shachor [EMAIL PROTECTED] *
- * Version: $Revision: 1.2 $ *
+ * Version: $Revision: 1.3 $ *
***/
#ifndef _JK_UTIL_H
#define _JK_UTIL_H
@@ -106,6 +106,8 @@
int jk_get_worker_cache_size(jk_map_t *m,
const char *wname,
int def);
+
+void jk_set_log_format(char *logformat);
int jk_get_worker_list(jk_map_t *m,
char ***list,
cvs commit: jakarta-tomcat/src/native/mod_jk/apache1.3 mod_jk.c
hgomez 01/03/27 14:01:20
Modified:src/native/mod_jk/apache1.3 mod_jk.c
Log:
Add support for timestamp in mod_jk.log
New var is JkLogStampFormat and use strftime
format ie : "[%a %b %d %H:%M:%S %Y] "
nota the " " to make it a single param
Revision ChangesPath
1.7 +11 -1 jakarta-tomcat/src/native/mod_jk/apache1.3/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/apache1.3/mod_jk.c,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- mod_jk.c 2001/03/21 07:12:26 1.6
+++ mod_jk.c 2001/03/27 22:01:18 1.7
@@ -58,6 +58,7 @@
* See ../common/jk_service.h for general mod_jk info *
* Author: Gal Shachor [EMAIL PROTECTED] *
* Dan Milstein [EMAIL PROTECTED]*
+ * Henri Gomez [EMAIL PROTECTED] *
* Version: $ $*
***/
@@ -698,6 +699,14 @@
}
+static const char * jk_set_log_fmt(cmd_parms *cmd,
+void *dummy,
+char * log_format)
+{
+ jk_set_log_format(log_format);
+ return NULL;
+}
+
static const command_rec jk_cmds[] =
{
/*
@@ -729,7 +738,8 @@
"Full path to the Jakarta Tomcat module log file"},
{"JkLogLevel", jk_set_log_level, NULL, RSRC_CONF, TAKE1,
"The Jakarta Tomcat module log level, can be debug, info, error or emerg"},
-
+{"JkLogStampFormat", jk_set_log_fmt, NULL, RSRC_CONF, TAKE1,
+ "The Jakarta Tomcat module log format, follow strftime synthax"},
/*
* Apache has multiple SSL modules (for example apache_ssl, stronghold
* IHS ...). Each of these can have a different SSL environment names
cvs commit: jakarta-tomcat/src/native/mod_jk/apache2.0 mod_jk.c
hgomez 01/03/27 14:02:36
Modified:src/native/mod_jk/apache2.0 mod_jk.c
Log:
Add support for timestamp in mod_jk.log
New var is JkLogStampFormat and use strftime
format ie : "[%a %b %d %H:%M:%S %Y] "
nota the " " to make it a single param
Also since Apache 2.0 alpha 15, ap_get_remote_host
need another param
Revision ChangesPath
1.10 +14 -4 jakarta-tomcat/src/native/mod_jk/apache2.0/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/apache2.0/mod_jk.c,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- mod_jk.c 2001/03/13 23:34:33 1.9
+++ mod_jk.c 2001/03/27 22:02:34 1.10
@@ -327,7 +327,7 @@
s-protocol = r-protocol;
s-remote_host = (char *)ap_get_remote_host(r-connection,
- r-per_dir_config,
+ r-per_dir_config, REMOTE_NAME,
REMOTE_HOST);
s-remote_host = NULL_FOR_EMPTY(s-remote_host);
@@ -448,7 +448,7 @@
return NULL;
}
-static const char *jk_set_wroker_file(cmd_parms *cmd,
+static const char *jk_set_worker_file(cmd_parms *cmd,
void *dummy,
char *worker_file)
{
@@ -487,9 +487,17 @@
return NULL;
}
+static const char * jk_set_log_fmt(cmd_parms *cmd,
+ void *dummy,
+ char * log_format)
+{
+ jk_set_log_format(log_format);
+ return NULL;
+}
+
static const command_rec jk_cmds[] =
{
-{"JkWorkersFile", jk_set_wroker_file, NULL, RSRC_CONF, TAKE1,
+{"JkWorkersFile", jk_set_worker_file, NULL, RSRC_CONF, TAKE1,
"the name of a worker file for the Jakarta servlet containers"},
{"JkMount", jk_mount_context, NULL, RSRC_CONF, TAKE23,
"A mount point from a context to a Tomcat worker"},
@@ -499,6 +507,8 @@
"Full path to the Jakarta Tomcat module log file"},
{"JkLogLevel", jk_set_log_level, NULL, RSRC_CONF, TAKE1,
"The Jakarta Tomcat module log level, can be debug, info, error or emerg"},
+{"JkLogStampFormat", jk_set_log_fmt, NULL, RSRC_CONF, TAKE1,
+ "The Jakarta Tomcat module log format, follow strftime synthax"},
{NULL}
};
@@ -725,7 +735,7 @@
if(map_alloc(init_map)) {
if(map_read_properties(init_map, conf-worker_file)) {
- ap_add_version_component(pconf,
"mod_jk");
+ ap_add_version_component(pconf, "mod_jk");
if(wc_open(init_map, conf-log)) {
return;
}
jk_ajp13_worker.c
Could I commit the latest jk_ajp13_worker.c I send to list ? It works fine for more than 1 week...
ajp1X protocol security
I'm just recently getting more intimate with Tomcat's architecture and I'm wondering what provisions and plans are in place for security in the protocols btw http servers and the servlet engine. What are the vulnerabilities now and how are people using Tomcat in production protecting themselves? Firewalling access to ports 8007/8009? Sorry if this is a FAQ, I just didn't a clear definition of the status and the future plans documented anywhere. cheers, -Ian -- Ian Kallen [EMAIL PROTECTED] | AIM: iankallen
RE: ajp1X protocol security
I'm just recently getting more intimate with Tomcat's architecture and I'm wondering what provisions and plans are in place for security in the protocols btw http servers and the servlet engine. What are the vulnerabilities now and how are people using Tomcat in production protecting themselves? Firewalling access to ports 8007/8009? Sorry if this is a FAQ, I just didn't a clear definition of the status and the future plans documented anywhere. Welcome you Covalent ;) I proposed sometimes ago to add strongest ACL to ajp13 along with many protocols add-ons. ajp13 didn't use a login mechanism between Apache and TC. Something to add.
RE: jk_ajp13_worker.c
I commit NOW :-) "Entre truands, les bnfices, a se partage, la rclusion, a s'additionne." -- Michel Audiard -Original Message- From: Dan Milstein [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 28, 2001 12:28 AM To: [EMAIL PROTECTED] Subject: Re: jk_ajp13_worker.c I would say go for it. It's a hotly desired feature, so hopefully it will see some good testing. Nice work, -Dan GOMEZ Henri wrote: Could I commit the latest jk_ajp13_worker.c I send to list ? It works fine for more than 1 week... -- Dan Milstein // [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/native/mod_jk/common jk_ajp13_worker.c
hgomez 01/03/27 14:42:04
Modified:src/native/mod_jk/common jk_ajp13_worker.c
Log:
The long awaited :) correction to tomcat restart problem.
No need to restart apache now
Will need a little adjustement, ie instead of 3
fixed loop try to connect 2 * times the numbers of
workers matching the requested URL (Dan ?)
Revision ChangesPath
1.6 +224 -111 jakarta-tomcat/src/native/mod_jk/common/jk_ajp13_worker.c
Index: jk_ajp13_worker.c
===
RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/common/jk_ajp13_worker.c,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- jk_ajp13_worker.c 2001/03/06 20:22:22 1.5
+++ jk_ajp13_worker.c 2001/03/27 22:42:04 1.6
@@ -54,10 +54,11 @@
*/
/***
- * Description: Bi-directional protocol. *
+ * Description: Bi-directional protocol. *
+ * Author: Henri Gomez [EMAIL PROTECTED] *
* Author: Costin [EMAIL PROTECTED] *
* Author: Gal Shachor [EMAIL PROTECTED] *
- * Version: $Revision: 1.5 $ *
+ * Version: $Revision: 1.6 $ *
***/
#include "jk_pool.h"
@@ -75,6 +76,9 @@
#define JK_INTERNAL_ERROR (-2)
#define MAX_SEND_BODY_SZ(DEF_BUFFER_SZ - 6)
+struct ajp13_operation;
+typedef struct ajp13_operation ajp13_operation_t;
+
struct ajp13_endpoint;
typedef struct ajp13_endpoint ajp13_endpoint_t;
@@ -111,6 +115,18 @@
unsigned left_bytes_to_send;
};
+/*
+ * little struct to avoid multiples ptr passing
+ * this struct is ready to hold upload file fd
+ * to add upload persistant storage
+ */
+struct ajp13_operation {
+ jk_msg_buf_t*request; /* original request storage */
+ jk_msg_buf_t*reply; /* reply storage (chuncked by ajp13 */
+ int uploadfd; /* future persistant storage id */
+ int recoverable;/* if exchange could be conducted on another
TC */
+};
+
static void reset_endpoint(ajp13_endpoint_t *ep)
{
ep-reuse = JK_FALSE;
@@ -343,6 +359,7 @@
len = 0;
}
+ /* the right place to add file storage for upload */
if(read_into_msg_buff(ep, r, msg, l, len)) {
r-content_read += len;
return JK_AJP13_HAS_RESPONSE;
@@ -529,123 +546,219 @@
"In jk_endpoint_t::done, NULL parameters\n");
return JK_FALSE;
}
-
-static int JK_METHOD service(jk_endpoint_t *e,
- jk_ws_service_t *s,
- jk_logger_t *l,
- int *is_recoverable_error)
-{
-jk_log(l,
- JK_LOG_DEBUG,
- "Into jk_endpoint_t::service\n");
-if(e e-endpoint_private s is_recoverable_error) {
-ajp13_endpoint_t *p = e-endpoint_private;
-jk_msg_buf_t *msg = jk_b_new((p-pool));
+/*
+ * send request to Tomcat via Ajp13
+ * - first try to find reuseable socket
+ * - if no one available, try to connect
+ * - send request, but send must be see as asynchronous,
+ * since send() call will return noerror about 95% of time
+ * Hopefully we'll get more information on next read.
+ *
+ * nb: reqmsg is the original request msg buffer
+ * repmsg is the reply msg buffer which could be scratched
+ */
+static int send_request(jk_endpoint_t *e,
+ jk_ws_service_t *s,
+ jk_logger_t *l,
+ ajp13_endpoint_t *p,
+ ajp13_operation_t *op)
+{
+ /*
+ * First try to reuse open connections...
+ */
+ while((p-sd 0) !connection_tcp_send_message(p, op-request, l)) {
+ jk_log(l, JK_LOG_ERROR, "Error sending request try another pooled
connection\n");
+ jk_close_socket(p-sd);
+ p-sd = -1;
+ reuse_connection(p, l);
+ }
+
+ /*
+ * If we failed to reuse a connection, try to reconnect.
+ */
+ if(p-sd 0) {
+ connect_to_tomcat(p, l);
+ if(p-sd = 0) {
+ /*
+ * After we are connected, each error that we are going to
+ * have is probably unrecoverable
+ */
+ op-recoverable = JK_FALSE;
+ if(!connection_tcp_send_message(p,
RE: jk_ajp13_worker.c
What about my previous propositions on ajp13 extensions which may became ajp14 "Entre truands, les bnfices, a se partage, la rclusion, a s'additionne." -- Michel Audiard -Original Message- From: Dan Milstein [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 28, 2001 12:28 AM To: [EMAIL PROTECTED] Subject: Re: jk_ajp13_worker.c I would say go for it. It's a hotly desired feature, so hopefully it will see some good testing. Nice work, -Dan GOMEZ Henri wrote: Could I commit the latest jk_ajp13_worker.c I send to list ? It works fine for more than 1 week... -- Dan Milstein // [EMAIL PROTECTED]
Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
- JspServlet must manage the servlet lifecycle - the container can no longer treat jsp-generate-servlets the same as regular servlets This is a limitation of the servlet api and thus the lack of access to a consistent set of servlet engine features necessary for full servlet life-cycle management that can be relied upon. Besides, who said that the container was guaranteed full-lifecycle management of ANY servlet? Any servlet could be created/loaded dynamically and managed by some other servlet without the container ever knowing about it (assuming the SecurityManager allowed it, of course :-). True, but a container can be smart ( and unload unused servlets, provide nice monitoring, etc ). - initialization - how can you pass init parameters to the jsp ? This is one of the worst hacks and source of counteless problems ( AFAIK - I couldn't find any clean way to do that ) How exactly do you solve this with JspInterceptor? A JSP is treated the same way as a servlet - it gets a ServletConfig with the right info from web.xml, etc. There is no distinction between the way a regular servlet is treated and a jasper-generated servlet. The specification doesn't really seem to cover init-params for individual JSP pages. The JSP ??? servletjsp-file/foo.jsp/jsp-file init-paramnamefoo/name.. AFAIK you should be able to define init params for jsps the same as you do for servlets ( unless I'm missing something here). container has no responsibility to provide individualized init-params for JSP servlets, only to invoke jspInit() prior to service(). In the absence I thought it does... Even tought that never worked very well :-) The glass is half-full as well - because at least with the servlet api it is _possible_ to implement those services portably and thus provide a portable JSP compiler. Almost everything is possible ( in a turing machine :-). The problem is at what cost, and if that's the best solution. And again - what is the alternative? I can't write a JspInterceptor solution for WebLogic or JRun. Unfortunately that's true - and it's a good reason to have JspServlet. But if you have control over the servlet container ( for example using an internal extension mechanism - like the interceptor in tc3 or valve in tc4 ) it would be much better to use a rich API that allows full control over jasper, and lets the container do what it is supposed to do - manage servlets. The mistakes aren't in using a servlet-based approach. This sort of feature (a plug-in to provid jsp compilation and loading services to a web server) is exactly what servlets are for. This in itself in no way limits what you can do with JSPs because all features of the JSP spec should be attainable through a servlet implementation. I'm still looking for a solution to deal with the init-param ( except for re-parsing web.xml ) I'm not saying it's a mistake to have a servlet-based approach, but that having a full API and letting the container manager servlets and jasper do the compilation could be a better solution. The way to look at it is that a JspInterceptor-style solution is a value-added feature of the tomcat servlet engine. That is a positive. The portability of JspServlet is also a positive. +1 ( and to my defense - I did the fixes to allow JspServlet to be still be used in tomcat 3.3, for people who want a slower jsp :-) Mel, what I'm trying to explain is not that JspServlet is bad, but that we need a refactoring to expose more if Jasper API and cleanly separate the components - so we can use JspServlet and interceptors ( or valves ). A lot of the code in jasper is written with the assumption that JspServlet is the entry point ( i.e. with workarounds and hacks for this case ) - and then we have JspC and JspInterceptor that adds another round of hacks and workarounds. And it would help a lot to keep this in mind while doing the refactoring - i.e. to distinguish between what's jasper's core functionality ( convert a .jsp file to a java file ) and what's a hack and duplication of container's functionality for JspServlet's use. For example JspLoader, some of the manglers, some of the JspEngine and context. If we are going for a refactoring, it would be a good idea to clean up and fix more than just JspServlet. Costin
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler JspParseEventListener.java
horwat 01/03/27 15:56:24
Modified:jasper/src/share/org/apache/jasper/compiler
JspParseEventListener.java
Log:
Handle empty element case. This patch allows jasper to work with xerces-1.3.0
Revision ChangesPath
1.23 +7 -5
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java
Index: JspParseEventListener.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- JspParseEventListener.java2001/02/04 01:05:13 1.22
+++ JspParseEventListener.java2001/03/27 23:56:24 1.23
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
1.22 2001/02/04 01:05:13 glenn Exp $
- * $Revision: 1.22 $
- * $Date: 2001/02/04 01:05:13 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
1.23 2001/03/27 23:56:24 horwat Exp $
+ * $Revision: 1.23 $
+ * $Date: 2001/03/27 23:56:24 $
*
*
*
@@ -1097,8 +1097,10 @@
public void handleJspCdata(Mark start, Mark stop, char[] data)
throws JasperException
{
- handleCharData(start, stop, data);
-xo.append("jsp:cdata", null, data);
+ if (data != null) {
+ handleCharData(start, stop, data);
+xo.append("jsp:cdata", null, data);
+ }
}
/**
Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
On Tue, 27 Mar 2001 [EMAIL PROTECTED] wrote: - initialization - how can you pass init parameters to the jsp ? This is one of the worst hacks and source of counteless problems ( AFAIK - I couldn't find any clean way to do that ) From the application developer's perspective, you do this: servlet servlet-nameMyJspPageServlet/servlet-name jsp-file/path/to/myjsppage.jsp/jsp-file init-param param-namename/param-name param-valuevalue/param-value /init-param /servlet The approach to implementing this in Catalina is also pretty ugly, but it does work ... Craig
Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
On Tue, 27 Mar 2001, Mel Martinez wrote: The glass is half-full as well - because at least with the servlet api it is _possible_ to implement those services portably and thus provide a portable JSP compiler. When Tomcat 4.0 was created, one of the goals was to eliminate all the Jasper dependencies on servlet container code (with the goal of a portable JSP environment). We were completely successful except for two (initially) and now only one issue: specifying a classpath for the Java compiler. In a JDK 1.1 environment, there is no portable solution to this problem. In JDK 1.2 or later, you can have a portable solution as long as the web app classloader is a subclass of URLClassLoader (as it is in Tomcat 4.0), because you can ask the URLClassLoader what it's repositories are and therefore reconstruct a reasonable class path in most circumstances. The portability goal is definitely achievable in a Java2 world. Craig
Re: JDBC-Session store
On Tue, 27 Mar 2001, Kief Morris wrote: Bip Thelin typed the following on 01:56 PM 3/26/2001 -0800 According to the STATUS.html(which doesn't seem to be up to date) no one seems to have volunteered for the JDBC-Session store. If that is truly the case I would like to volunteer for that part. Excellent! Let us know if you need any help. Kief Kief, a while back (when the work on PersistentManager was going on), the need for a little refactoring work on Manager vs. StandardManager would be useful. Have you thought any more about what we should do here? Craig
Re: Listeners
On Tue, 27 Mar 2001, Kevin Jones wrote: Tomcat 4.0 stops configuring listeners if one of the listeners in the list isn't present, should it carry on configuring the rest of the listeners it finds? The spec is silent on this and it seems odd that if somebody (maybe accidentally) deletes a listener class all other following listeners are not configured (any listener preceding the missing listener would already have been initialised). Here's the rationale for this behavior (and the fact that Tomcat also marks the app unavailable if it didn't initialize all the listeners and filters successfully): Let's say you are implementing user authentication yourself, and using filters. You specify connection information to a database in your filter params, but mistype the password so that the connection cannot be established, so your filter's init() method throws an exception. If Tomcat just logged this as a warning and went on deploying your app, it would now be running with *no* authentication, potentially exposing sensitive information. Is that what you *really* want to have happen? One might argue missing listeners would be less severe a risk than missing filters, but IMHO that isn't the container's judgement to make -- the user has an incomplete application deployed; better to make them go fix it rather than trying to run only part of it. I've also raised this as a bug, Thanks, Kevin Craig
Re: Cause found [was Re: How do I use a non-apache naming servicewith tomcat 4?]
On Tue, 27 Mar 2001, T. Park wrote: Craig,Remy, downloading the latest nightly build resolved my problem... thanks! Cool. ...but only after I dropped that 'big everything' jar into the common/lib folder. So there seems to be a chicken egg thing regarding what order certain components need to be in for the new tomcat to play with an alternative naming service. My InstanceListener class goes into server/lib just fine, but the support class (I.e. the one containing javax.naming) needs to go in the common area. Can you tell me why this would be? I know it's something to do with the new classloading scheme but I can't see why it would matter. The reason something would need to be in "common" is if it needs to be visible to both the Catalina classloader and a webapp class loader. If you consult the classloaders.html doc for Catalina, you will see that this is the only configurable place that these two hierarchies meet. It sounds like there must be things in your "big everything" JAR that meet that description. -Thom Craig
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector HttpResponseBase.java
remm01/03/27 21:15:15
Modified:catalina/src/share/org/apache/catalina/connector
HttpResponseBase.java
Log:
- Fix for bug 1081.
Revision ChangesPath
1.29 +6 -8
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java
Index: HttpResponseBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- HttpResponseBase.java 2001/03/14 02:17:21 1.28
+++ HttpResponseBase.java 2001/03/28 05:15:14 1.29
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java,v
1.28 2001/03/14 02:17:21 craigmcc Exp $
- * $Revision: 1.28 $
- * $Date: 2001/03/14 02:17:21 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java,v
1.29 2001/03/28 05:15:14 remm Exp $
+ * $Revision: 1.29 $
+ * $Date: 2001/03/28 05:15:14 $
*
*
*
@@ -99,7 +99,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.28 $ $Date: 2001/03/14 02:17:21 $
+ * @version $Revision: 1.29 $ $Date: 2001/03/28 05:15:14 $
*/
public class HttpResponseBase
@@ -578,8 +578,8 @@
HttpServletRequest hreq = (HttpServletRequest) request.getRequest();
HttpSession session = hreq.getSession(false);
- if ((session != null) session.isNew()
- getContext().getCookies()) {
+ if ((session != null) session.isNew() (getContext() != null)
+ getContext().getCookies()) {
Cookie cookie = new Cookie(Globals.SESSION_COOKIE_NAME,
session.getId());
cookie.setMaxAge(-1);
@@ -1044,8 +1044,6 @@
String absolute = toAbsolute(location);
setStatus(SC_MOVED_TEMPORARILY);
setHeader("Location", absolute);
-//setContentLength(0);
- //flushBuffer();
}
Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
On Tue, 27 Mar 2001, Craig R. McClanahan wrote: The glass is half-full as well - because at least with the servlet api it is _possible_ to implement those services portably and thus provide a portable JSP compiler. When Tomcat 4.0 was created, one of the goals was to eliminate all the Jasper dependencies on servlet container code (with the goal of a portable JSP environment). We were completely successful except for two (initially) and now only one issue: specifying a classpath for the Java compiler. ... The portability goal is definitely achievable in a Java2 world. The only problem is that maybe trying to make jasper independent of the container is the wrong goal... The price is ugly ( or at least complex ) and inefficient code ( not only because of the overhead, but also because of the missed oportunities for optimizations ). A quick test is very simple - in 3.3 compare the speed of running jsps via JspServlet and JspInterceptor. ( or with the JspServlet in 4.0 if you think the 3.x JspServlet is bad ). I'm not saying that having a JSP implementation packaged as a servlet and reimplementing functions of the servlet container is bad or impossible - just that a solution where the container does servlet management and jasper deals with converting jsps to servlets may result in cleaner code and better performance. I don't remember reading anywhere in the JSP spec that jasper must be implemented as a servlet, or that it must be independent of the servlet container. And I don't think having a good design for jasper's API that allows it to take advantage of the container would make it less portable - and JspServlet can still be used to plug jasper in un-cooperating containers. So far jasper has been one of the most stable pieces on tomcat ( most bugs I know about are related with the interfacing between jasper and the container ). And it has a huge potential for performance improvement - if we do the right refactoring and provide the right internal APIs. Costin
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector ResponseBase.java
remm01/03/27 21:35:25
Modified:catalina/src/share/org/apache/catalina/connector
ResponseBase.java
Log:
- Fix for bug 453.
This has the potential to break stuff when using HTTP/1.1, although this is
unlikely.
Revision ChangesPath
1.11 +11 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/ResponseBase.java
Index: ResponseBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/ResponseBase.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- ResponseBase.java 2001/01/13 22:28:48 1.10
+++ ResponseBase.java 2001/03/28 05:35:24 1.11
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/ResponseBase.java,v
1.10 2001/01/13 22:28:48 craigmcc Exp $
- * $Revision: 1.10 $
- * $Date: 2001/01/13 22:28:48 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/ResponseBase.java,v
1.11 2001/03/28 05:35:24 remm Exp $
+ * $Revision: 1.11 $
+ * $Date: 2001/03/28 05:35:24 $
*
*
*
@@ -88,7 +88,7 @@
* the connector-specific methods need to be implemented.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.10 $ $Date: 2001/01/13 22:28:48 $
+ * @version $Revision: 1.11 $ $Date: 2001/03/28 05:35:24 $
*/
public abstract class ResponseBase
@@ -464,7 +464,13 @@
} catch (IOException e) {
;
}
-return (new PrintWriter(output));
+try {
+if (this.stream == null)
+this.stream = createOutputStream();
+} catch (IOException e) {
+return null;
+}
+return (new PrintWriter(this.stream));
} else {
RE: Listeners
Here's the rationale for this behavior (and the fact that Tomcat also marks the app unavailable if it didn't initialize all the listeners and filters successfully): But it doesn't, at least not in the latest nightly. I have a listener configured and the class file is missing. Tomcat seems not to have initialised any of the listeners but the application is still available. Let's say you are implementing user authentication yourself, and using filters. You specify connection information to a database in your filter params, but mistype the password so that the connection cannot be established, so your filter's init() method throws an exception. If Tomcat just logged this as a warning and went on deploying your app, it would now be running with *no* authentication, potentially exposing sensitive information. Is that what you *really* want to have happen? One might argue missing listeners would be less severe a risk than missing filters, but IMHO that isn't the container's judgement to make -- the user has an incomplete application deployed; better to make them go fix it rather than trying to run only part of it. But it is a judgement the container is making - In my app it doesn't matter much if the filters/listeners are missing. I would argue that for listeners the behaviour should be the same as for load-on-startup servlets and that the principle of least surprise would be applied. I would guess that initially most listeners would be ported from load-on-startup servlets (mine are), of one of those servlets was missing the application still started, and the servlets still executed. Least surprise tells me that listeners should behave the same way. Is there some way we could configure this in server.xml or do you think that is overkill. BTW should we also add a note in the spec. about this? Kevin Jones DevelopMentor www.develop.com -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: 28 March 2001 04:14 To: Tomcat-Dev Subject: Re: Listeners On Tue, 27 Mar 2001, Kevin Jones wrote: Tomcat 4.0 stops configuring listeners if one of the listeners in the list isn't present, should it carry on configuring the rest of the listeners it finds? The spec is silent on this and it seems odd that if somebody (maybe accidentally) deletes a listener class all other following listeners are not configured (any listener preceding the missing listener would already have been initialised). Here's the rationale for this behavior (and the fact that Tomcat also marks the app unavailable if it didn't initialize all the listeners and filters successfully): Let's say you are implementing user authentication yourself, and using filters. You specify connection information to a database in your filter params, but mistype the password so that the connection cannot be established, so your filter's init() method throws an exception. If Tomcat just logged this as a warning and went on deploying your app, it would now be running with *no* authentication, potentially exposing sensitive information. Is that what you *really* want to have happen? One might argue missing listeners would be less severe a risk than missing filters, but IMHO that isn't the container's judgement to make -- the user has an incomplete application deployed; better to make them go fix it rather than trying to run only part of it. I've also raised this as a bug, Thanks, Kevin Craig
FW: Tomcat 4 service
I posted this to tomcat-user with no response. Does such a beast exist? If not I'll volunteer to port the Tomcat 3.2 code. Just point me at it! Kevin Jones DevelopMentor www.develop.com -Original Message- From: Kevin Jones [mailto:[EMAIL PROTECTED]] Sent: 27 March 2001 22:44 To: Tomcat-User Subject: Tomcat 4 service I have tomcat 3.2 running as a service under W2K. I seem to remember that this wasn't available for Tomcat 4 (running it as a service that is), or is the code now available? Thanks, Kevin Jones DevelopMentor www.develop.com
Re: Multi-byte character support.
From: "Java Poop" [EMAIL PROTECTED] Subject: Re: Multi-byte character support. Date: Mon, 26 Mar 2001 22:33:36 -0800 Message-ID: [EMAIL PROTECTED] What are the il8n limitations in 3.2.1? For example, there are the following limitations: 1, The getParameter method in ServletRequest class returns non-Unicode strings. If a HTTP GET or POST request is done by a HTML form, servlet can't know its charset because the request don't have its charset information. The HTML 4.0 specification recommends to encode UTF-8 strings but most of systems don't do it. Tomcat 3.2 treats parameters like their charset is ISO-8859-1. Other servlet container may return Unicode strings by its own encoding detection method but it is tricky and don't work under some situation. For avoiding this problem, Servlet 2.3 API has setCharacterEncoding method and Tomcat 4.0 based on it. Because Tomcat 3.2 based on Servlet 2.2 API, we can't use this method. But Costin will provide an extension module for Tomcat 3.3 (for example, specify the default encoding per context). 2, A JSP content's encoding may not be recognized correctly. This cause is a lack of a function to specify JSP content's encoding (JSP output encoding is specified by contentType attribute of Page directive). JSP 1.2 has new pageEncoding attribute of Page directive. And a file localization method, it is proposed by Arieh, may provide another solution. Kazuhiro Kazama ([EMAIL PROTECTED]) NTT Network Innovation Laboratories
Re: Tomcat 4 service
I believe that the only change you require is to create a suitable wrapper.properties, you should be able to use the existing jk_nt_service.exe. I had this working a few weeks ago but I tried my existing configuration on the latest build and the service fails to startup. I am currently in the process of trying to figure out what the issue is. Regards, Arshad - Original Message - From: "Kevin Jones" [EMAIL PROTECTED] To: "Tomcat-Dev" [EMAIL PROTECTED] Sent: Wednesday, March 28, 2001 7:52 AM Subject: FW: Tomcat 4 service I posted this to tomcat-user with no response. Does such a beast exist? If not I'll volunteer to port the Tomcat 3.2 code. Just point me at it! Kevin Jones DevelopMentor www.develop.com -Original Message- From: Kevin Jones [mailto:[EMAIL PROTECTED]] Sent: 27 March 2001 22:44 To: Tomcat-User Subject: Tomcat 4 service I have tomcat 3.2 running as a service under W2K. I seem to remember that this wasn't available for Tomcat 4 (running it as a service that is), or is the code now available? Thanks, Kevin Jones DevelopMentor www.develop.com
