[jakarta-tomcat-connectors] util has been updated ...
with the latest code from tomcat 3.3. you didn't see the commit mail message, 'cause it was too big :)
Problems With multi part Request
I have this problem uploading files to the Server using a mulitpart Request
I tried this code to print the Request streams to the Output in my JSP Prog
java.io.InputStream inst = request.getInputStream();
int inm;
while( (inm = inst.read())-1){
out.write((char) inm);
}
When I upload a txt file the Server receives the full file and prints it to
the response printwriter. But When I upload non ASCII data. Like
Images(gif/jpeg) the Stream just gets cut off just on the first character of
the uploaded file (All param like the filename and content type reaches but
any data after the file contents is discarded) . It seems that the Server is
not accepting these binary data.
The Code Worked well when I was using Tomcat standalone but now I am having
problems when it is running alongside apache.
Is there Some changes I have to do on Apache or Tomcat to start receiving
the uploaded Files
Kindly lead me to the light,
Warmest Regards,
Anil Oommen
[EMAIL PROTECTED]
RE: [PATCH] for mod_jk/ajp13 memory leaks.
I found some more memory leaks in mod_jk. The biggest one is in mod_jk.c when there is a virtual host section in httpd.conf. Multiple conf structures are allocated, but only one was being cleaned up. Another leak was in jk_ajp13_worker.c. We were calling jk_open_pool on the endpoint object and never calling jk_close_pool when the endpoint was shut down. The attached diff files are against the latest tomcat_33 branch. If anyone is interested, I'd be happy to provide the same diffs for tomcat_32 and the tomcat-jakarta-connectors project. I'd also be happy to enter a bug if necessary. Thanks for these very important fixes. I'll commit then to TC 3.3 and JTC (which came from TC 3.3 CVS). I think Marc Saegesser will be interest in fixes for tomcat_32. Regards
RE: connector status in tomcat 4
Ok, another question then. Please, What is it that the connector has to be able to do? Is it sufficient if it simply can forward the HTTP request to tomcat or does it need to play around with it? I guess it must do something or the disscusion on ajp13/jk and warp/webapp wouldn't be. The web-server connector forward request to tomcat and add some information, like the SESSION-COOKIES. In return the tomcat add a var, jvmroute, which is used in load-balancing config to be sure that the same tomcat will serve the next queries for that session. The connector use a simple protocol, ajp12/13/14, to forward the request. You may imagine a web-connector forwarding the request using HTTP protocol, but this one is more complex to handle. // Erik -Original Message- From: kevin seguin [mailto:[EMAIL PROTECTED]] Sent: Monday, May 28, 2001 5:47 PM To: [EMAIL PROTECTED] Subject: Re: connector status in tomcat 4 for example, in my case, currently all i care about is being able to forward requests based on uri from iis and netscape to tomcat. so, for me, ajp does what i need it to, while warp/webapp currently does not (no iis/netscape support yet). hence, i would pick ajp. now, i'm not saying one is better than the other. i'm just saying that one might be better than the other in certain circumstances, and now you have a choice.
RE: connector status in tomcat 4
GOMEZ Henri at [EMAIL PROTECTED] wrote: In that case, what is the point of warp. Is it going to be faster, more scalable or something? warp is a whole new developpement using very recent lib tools like APR. And a bunch of other features and improvements, but it seems that no one ever listen to what I write - technically speaking :) :) :) :) What's the technicals improvements apart of the use of APR, technically speaking ? If not why was it created? That's a good question and who has the answer ? I do, and the mailing list archive... Check out for subjects like WARP :) The first time we saw something about Warp is in the announcement of Tomcat 4.0 m4. I couldn't find any discussion on tomcat-dev (or tomcat-user) about starting a new connector (mod_webapp) instead adding features to ajp13 and using mod_jk ;( Could help me find the initial thread on mod_webapp/warp ?) Regards = List: tomcat-dev Subject: Tomcat 4.0 Milestone 4 From: Craig R. McClanahan [EMAIL PROTECTED] Date: 2000-11-01 0:09:41 [Download message RAW] Hey folks, I'm planning on cutting a fourth milestone of Tomcat 4.0 tomorrow (Wednesday) evening. This milestone will reflect all of the changes that occurred in the servlet 2.3 and JSP 1.2 specifications between public draft and proposed final draft (and there were a *bunch* of them), completion of the remaining new 2.3/1.2 functionality, and several bug fixes. This will be the last big push of spec-related functionality additions for Tomcat 4.0. Now, we can turn our attention more towards bug fixes and performance tuning. You can help in that process by downloading and playing with the Tomcat 4.0 milestone. I'd like to see us shake it out enough to be production quality by Christmas time. Besides bug fixing and tuning, I know of several pieces of functionality yet to be added that are being worked on, including: * Web connectors (using a new connector protocol called mod_warp that is aware of webapp configuration settings, so you will not have to configure things twice). * JNDI context support (like that used in J2EE servers) for the env-entry and resource-ref configuration parameters in the deployment descriptor. If you are interested in contributing to Tomcat 4.0, there is a wish list document in file catalina/STATUS.html in the jakarta-tomcat-4.0 source tree. Feel free to propose new ideas, or to volunteer to work on one of these. Craig McClanahan =
TagBeginGenerator
Hi, can anyone help me? I really can't work this out. This is a jsp with 2 tags. this jsp works in Win2000 + tomcat321 and gets exceptions in RedHat6.2 + tomcat321. What is the problem? %@ taglib uri="../db-taglib.tld" prefix="db" %%@ taglib uri="../ma-taglib.tld" prefix="ma" %...db:connection id="conn" url="jdbc :oracle:thin:@abc.xxx.net:1521 :orcl" db:userIduser/db:userId db :passwordabcd/db :password/db:connection // so far the tag works fine. however when I add one more tag as // following, it gives the exception. db:query id="abc" connection="conn" select * from table_abc/db:query... exception: java.lang.NullPointerException at org.apache.jasper.compiler.TagBeginGenerator.generateSetters(TagBeginGenerator.java:196) at org.apache.jasper.compiler.TagBeginGenerator.generateServiceMethodStatements(TagBeginGenerator.java:291) at org.apache.jasper.compiler.TagBeginGenerator.generate(TagBeginGenerator.java:360)...
Problem+Fix concerning static error pages in Tomcat 3.2.2
I'm using Tomcat 3.2.2 (relase) and have configured static .html files as error pages. We used JSP pages before, and everything was fine... However since we're using static files, Tomcat will enter an infinite loop and eventually crash with a stack overflow (with a good change of leaving Tomcat in a defunct state). We traced down this problem and have found a way to fix it, but I'm not sure if this is correct. All this is related to the ContextManager class: 1) Both handleStatus and handleError will call 'getHandlerForPath' when an error page was configured. 2) getHandlerForPath returns a the Handler for the error page. (since we're using static files, this will be a FileHandler). So far, so good. 3) Eventually handleStatus and handleError will do a 'errorServlet.service( req, res )' to service the error. This is were things go wrong. The problem is, that 'req' passed to the 'errorServlet.service( req, res )' call is the original request, while getHandlerForPath creates a new request internally with the error's request URI. Since the handler (FileHandler) is called with the original request URI, it will try to service a file matching that request, not the static file we configured. This, in turn, will cause and error and, in our case, an infinite loop. This can lead to very strange situations. For example, if an .jsp page generates an error and the error refers to an (existing) static file, it will actually end up showing the .jsp source file contents! The quick and dirty fix we use here is to simply add 'req.setRequestURI( ctx.getPath() + errorPath);' after the 'getHandlerForPath' calls in both handleError and handleStatus methods. I'm not really sure if we are allowed to modify the request in such a way, but error attributes are also set in this request and it seems to work fine for us. But this raises another question: why construct a completely new request and response in getHandlerForPath, and then throw it away? Cheers, Peer Heijnen
problems with resultSet
hi, Hi! I'm using Tomcat and JSP but there are problem, my JSP don' work. I have this code in my JSP (code.) Statement s=cn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_ READ_ONLY); (more code) In begin of my JSP there is this code line %@ page language=java import=java.sql.*,java.io.*,java.util.* % but when I run the server and JSP, it appears this error Error: 500 Localizacion: pag.jsp Error interno del servlet: org.apache.jasper.JasperException: No se puede compilar la clase para JSPC:\TOMCAT\work\localhost_8080%. java:81: No variable TYPE_SCROLL_INSENSITIVE defined in interface java.sql.ResultSet. Statement s=cn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_ READ_ONLY); ^ C:\TOMCAT\work\localhost_8080%..java:81: No variable CONCUR_READ_ONLY defined in interface java.sql.ResultSet. Statement s=cn.createStatement(ResultSet.TYPE_SCROLL_INS ENSITIVE,ResultSet.CONCUR_READ_ONLY); ^ C:\TOMCAT\work\localhost_8080%..java:84: Method absolute(int) not found in interface java.sql.ResultSet. rs.absolute(5); Can anyone out there help me? Thanks in advance, Enrique.
RE: connector status in tomcat 4
-Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] What is it that the connector has to be able to do? Is it sufficient if it simply can forward the HTTP request to tomcat or does it need to play around with it? I guess it must do something or the disscusion on ajp13/jk and warp/webapp wouldn't be. The web-server connector forward request to tomcat and add some information, like the SESSION-COOKIES. In return the tomcat add a var, jvmroute, which is used in load-balancing config to be sure that the same tomcat will serve the next queries for that session. I guess that with information you mean all the HTTP-headers in the request and forward request is the parameters in the POST or GET (or any of the other HTTP commands). The connector use a simple protocol, ajp12/13/14, to forward the request. You may imagine a web-connector forwarding the request using HTTP protocol, but this one is more complex to handle. Ok. Is there any written specification för the ajp protocol adn where can I find it? // Erik
Re: Problem+Fix concerning static error pages in Tomcat 3.2.2
Sorry, I made a mistake in my previous post. The fix we use is 'req.setServletPath( ctx.getPath() + / + errorPath )', and _not_ 'req.setRequestURI( ctx.getPath() + errorPath )' as stated in my message. Cheers, Peer Heijnen
cvs commit: jakarta-tomcat-4.0/tester/web/WEB-INF web.xml
craigmcc01/05/29 10:55:40
Modified:tester/src/bin tester.xml
tester/web/WEB-INF web.xml
Added: tester/web ErrorPage09.jsp ErrorPage10.jsp
Log:
Additional tests for JSP errorPage declarations.
Revision ChangesPath
1.46 +15 -0 jakarta-tomcat-4.0/tester/src/bin/tester.xml
Index: tester.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/tester/src/bin/tester.xml,v
retrieving revision 1.45
retrieving revision 1.46
diff -u -r1.45 -r1.46
--- tester.xml2001/05/12 04:58:27 1.45
+++ tester.xml2001/05/29 17:55:31 1.46
@@ -329,6 +329,21 @@
status=200
outContent=ErrorPage06 PASSED - HTML/
+!-- == Exception Mapping (JSP Error Page) --
+
+tester host=${host} port=${port} protocol=${protocol}
+ request=${context.path}/ErrorPage09
+ debug=${debug}
+ status=200
+ outContent=ErrorPage10 PASSED/
+
+tester host=${host} port=${port} protocol=${protocol}
+ request=${context.path}/WrappedErrorPage09
+ debug=${debug}
+ status=200
+ outContent=ErrorPage10 PASSED/
+
+
/target
1.1 jakarta-tomcat-4.0/tester/web/ErrorPage09.jsp
Index: ErrorPage09.jsp
===
%@ page contentType=text/plain errorPage=/ErrorPage10.jsp %%
// Write a FAILED message that should get replaced by the error text
out.println(ErrorPage09 FAILED - Original response returned);
// Throw the specified exception
int i = 1;
if (i 0) {
throw new ArrayIndexOutOfBoundsException
(ErrorPage09 Threw ArrayIndexOutOfBoundsException);
}
%
1.1 jakarta-tomcat-4.0/tester/web/ErrorPage10.jsp
Index: ErrorPage10.jsp
===
%@ page contentType=text/plain isErrorPage=true %%
// Accumulate all the reasons this request might fail
StringBuffer sb = new StringBuffer();
Object value = null;
if (exception == null) {
sb.append( exception is missing/);
} else {
if (!(exception instanceof java.lang.ArrayIndexOutOfBoundsException)) {
sb.append( exception class is );
sb.append(exception.getClass().getName());
sb.append(/);
}
if (!ErrorPage09 Threw
ArrayIndexOutOfBoundsException.equals(exception.getMessage())) {
sb.append( exception message is );
sb.append(exception.getMessage());
sb.append(/);
}
}
// Report ultimate success or failure
if (sb.length() 1)
out.println(ErrorPage10 PASSED);
else
out.println(ErrorPage10 FAILED - + sb.toString());
%
%
out.println(EXCEPTION: + exception);
%
1.35 +20 -0 jakarta-tomcat-4.0/tester/web/WEB-INF/web.xml
Index: web.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/tester/web/WEB-INF/web.xml,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- web.xml 2001/05/12 04:58:27 1.34
+++ web.xml 2001/05/29 17:55:37 1.35
@@ -109,6 +109,11 @@
filter-mapping
filter-nameHttpFilter/filter-name
+url-pattern/WrappedErrorPage09/url-pattern
+/filter-mapping
+
+filter-mapping
+filter-nameHttpFilter/filter-name
url-pattern/WrappedForward00/url-pattern
/filter-mapping
@@ -392,6 +397,11 @@
/servlet
servlet
+servlet-nameErrorPage09/servlet-name
+jsp-file/ErrorPage09.jsp/jsp-file
+/servlet
+
+servlet
servlet-nameForward00/servlet-name
servlet-classorg.apache.tester.Forward00/servlet-class
/servlet
@@ -768,6 +778,16 @@
servlet-mapping
servlet-nameErrorPage08/servlet-name
url-pattern/WrappedErrorPage08/url-pattern
+/servlet-mapping
+
+servlet-mapping
+servlet-nameErrorPage09/servlet-name
+url-pattern/ErrorPage09/url-pattern
+/servlet-mapping
+
+servlet-mapping
+servlet-nameErrorPage09/servlet-name
+url-pattern/WrappedErrorPage09/url-pattern
/servlet-mapping
servlet-mapping
RE: Problem+Fix concerning static error pages in Tomcat 3.2.2
Could you please supply a sample webapp that demonstrates this? Static error pages seem to work OK for me. -Original Message- From: Peer Heijnen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 29, 2001 5:52 AM To: tomcat-dev Subject: Problem+Fix concerning static error pages in Tomcat 3.2.2 I'm using Tomcat 3.2.2 (relase) and have configured static .html files as error pages. We used JSP pages before, and everything was fine... However since we're using static files, Tomcat will enter an infinite loop and eventually crash with a stack overflow (with a good change of leaving Tomcat in a defunct state). We traced down this problem and have found a way to fix it, but I'm not sure if this is correct. All this is related to the ContextManager class: 1) Both handleStatus and handleError will call 'getHandlerForPath' when an error page was configured. 2) getHandlerForPath returns a the Handler for the error page. (since we're using static files, this will be a FileHandler). So far, so good. 3) Eventually handleStatus and handleError will do a 'errorServlet.service( req, res )' to service the error. This is were things go wrong. The problem is, that 'req' passed to the 'errorServlet.service( req, res )' call is the original request, while getHandlerForPath creates a new request internally with the error's request URI. Since the handler (FileHandler) is called with the original request URI, it will try to service a file matching that request, not the static file we configured. This, in turn, will cause and error and, in our case, an infinite loop. This can lead to very strange situations. For example, if an .jsp page generates an error and the error refers to an (existing) static file, it will actually end up showing the .jsp source file contents! The quick and dirty fix we use here is to simply add 'req.setRequestURI( ctx.getPath() + errorPath);' after the 'getHandlerForPath' calls in both handleError and handleStatus methods. I'm not really sure if we are allowed to modify the request in such a way, but error attributes are also set in this request and it seems to work fine for us. But this raises another question: why construct a completely new request and response in getHandlerForPath, and then throw it away? Cheers, Peer Heijnen
Re: [ANNOUNCEMENT] Tomcat 3.2.2 released
Nice one Marc. Dave. [EMAIL PROTECTED] From: Marc Saegesser [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: [ANNOUNCEMENT] Tomcat 3.2.2 released Date: Mon, 28 May 2001 22:58:11 -0500 I am pleased to announce that the Tomcat 3.2.2 release is now available for download at http://jakarta.apache.org/builds/tomcat/release/v3.2.2 Tomcat 3.2.2 is a maintenance release that fixes several bugs from version 3.2.1 and corrects all known specification compliance issues. The release notes file in src/doc/readme covers the details of the Tomcat 3.2.2 release. Tomcat 3.2.2 is now the latest production quality Tomcat release. Users of version 3.2.1 and earlier release are encouraged to update to this release. Marc A. Saegesser _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
RE: Issues with Tomcat 3.2.1, JSPs and I18N ( Implicit character tran slation ??? )
Title: RE: Issues with Tomcat 3.2.1, JSPs and I18N ( Implicit character tran slation ??? ) Nope, I'm not using a servlet to load the jsp resource. -Original Message- From: Edmund Lai [SMTP:[EMAIL PROTECTED]] Sent: Sunday, May 27, 2001 6:44 PM To: [EMAIL PROTECTED] Subject: Re: Issues with Tomcat 3.2.1, JSPs and I18N ( Implicit character tran slation ??? ) Are you using a servlet to load the jsp resource by using a RequestDispatcher.include()? If so, setting content-type in the page directive should have no effect. This is an excerpt from the Servlet 2.2 API doc The included servlet cannot change the response status code or set headers; any attempt to make a change is ignored. -- Ed A couple of other factors 1. Yes I'm setting the contentType to text/html; charset=UTF-8 in the Page Directiive 2. Yes the browser is set to use the UTF-8 encoding. 2. Yes I realize that the jsps are compiled into a servlet but while looking at the jsp compiled java src file it appears that the servlet uses a specialized class JspWriter to handle printing to the output stream. 3. ECS had a similar issue in previous versions. There are some tricky issues with how streams are handled so that you don't run into implicit and screwy character encoding issues. I would appreciate any feedback, I'm going to dig through the Tomcat source to see if I can find the root problem and would hate to do that if there was an easy answer that I'm missing. Thanks. Chris Halverson Christopher R. Halverson nCube [EMAIL PROTECTED] Never underestimate the ability of any human to delude themselves, and convince others their delusion is absolute __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
RE: Issues with Tomcat 3.2.1, JSPs and I18N ( Implicit character tran slation ??? )
Title: RE: Issues with Tomcat 3.2.1, JSPs and I18N ( Implicit character tran slation ??? ) Even when I remove the oracle and xml factors I get the same thing. I'll try it against 3.3. It looks like JSPWriter is queering the char coding. -Original Message- From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]] Sent: Sunday, May 27, 2001 7:08 PM To: [EMAIL PROTECTED] Subject: Re: Issues with Tomcat 3.2.1, JSPs and I18N ( Implicit character tran slation ??? ) Hi Chris, Can you reproduce this in normal JSP ( without oracle ) ? Can you send me a small webapp where I can reproduce it ? Does it happens in 3.3 too ? I am trying to solve (most) I18N bugs and problems for 3.3, it's very tricky but can be done :-) Costin On Fri, 25 May 2001, Chris Halverson wrote: I'm running Tomcat 3.2.1 on a Solaris box JDK 1.3 and using ECS1.4.1 for generating HTML I can save CJKV characters to my back end Oracle db, retrieve them, and display them if I'm using a servlet. Doesn't matter whether I use ECS or string handling. The browser recognizes that I'm sending in UTF-8 encoding and handles the characters just fine. However when I use the same code to get the data from the DB and run it through a JSP page I get gobbledygook. A couple of other factors 1. Yes I'm setting the contentType to text/html; charset=UTF-8 in the Page Directiive 2. Yes the browser is set to use the UTF-8 encoding. 2. Yes I realize that the jsps are compiled into a servlet but while looking at the jsp compiled java src file it appears that the servlet uses a specialized class JspWriter to handle printing to the output stream. 3. ECS had a similar issue in previous versions. There are some tricky issues with how streams are handled so that you don't run into implicit and screwy character encoding issues. I would appreciate any feedback, I'm going to dig through the Tomcat source to see if I can find the root problem and would hate to do that if there was an easy answer that I'm missing. Thanks. Chris Halverson Christopher R. Halverson nCube [EMAIL PROTECTED] Never underestimate the ability of any human to delude themselves, and convince others their delusion is absolute
cvs commit: jakarta-tomcat-connectors/util/src/java/org/apache/tomcat/util/buf package.html
seguin 01/05/29 13:16:20 Modified:util/src/java/org/apache/tomcat/util/buf package.html Log: added html and body tags. fixed h1 tag so that entire file wasn't h1. Revision ChangesPath 1.2 +4 -2 jakarta-tomcat-connectors/util/src/java/org/apache/tomcat/util/buf/package.html Index: package.html === RCS file: /home/cvs/jakarta-tomcat-connectors/util/src/java/org/apache/tomcat/util/buf/package.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- package.html 2001/05/29 06:22:53 1.1 +++ package.html 2001/05/29 20:16:18 1.2 @@ -1,4 +1,5 @@ -H1Buffers and Encodingsh1 +htmlbody +H1Buffers and Encodings/h1 This package contains buffers and utils to perform encoding/decoding of buffers. That includes byte to char conversions, URL encodings, etc. @@ -17,4 +18,5 @@ My benchmarks ( I'm costin :-) show only small differences between C2B, B2C and hand-written codders/decoders, so UTF8Decoder may be disabled. -p \ No newline at end of file +p +/body/html
RE: connector status in tomcat 4
Ok. Is there any written specification för the ajp protocol adn where can I find it? You could find both ajp13 and ajp14 protocol documentation in at least : jakarta-tomcat-connectors/jk/src/doc/
cvs commit: jakarta-tomcat-connectors/jk/src/java/org/apache/ajp Ajp13Packet.java
seguin 01/05/29 16:03:01
Modified:jk/src/java/org/apache/ajp Ajp13Packet.java
Log:
added some javadocs.
added set/getEncoding methods + encoding attribute.
Revision ChangesPath
1.4 +67 -11
jakarta-tomcat-connectors/jk/src/java/org/apache/ajp/Ajp13Packet.java
Index: Ajp13Packet.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/src/java/org/apache/ajp/Ajp13Packet.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- Ajp13Packet.java 2001/05/16 23:23:31 1.3
+++ Ajp13Packet.java 2001/05/29 23:02:59 1.4
@@ -74,38 +74,94 @@
public static final String DEFAULT_CHAR_ENCODING = 8859_1;
-byte buff[]; // Holds the bytes of the packet
-int pos; // The current read or write position in the buffer
+/**
+ * encoding to use when converting byte[] - string
+ */
+String encoding = DEFAULT_CHAR_ENCODING;
+
+/**
+ * Holds the bytes of the packet
+ */
+byte buff[];
+
+/**
+ * The current read or write position in the buffer
+ */
+int pos;
+/**
+ * This actually means different things depending on whether the
+ * packet is read or write. For read, it's the length of the
+ * payload (excluding the header). For write, it's the length of
+ * the packet as a whole (counting the header). Oh, well.
+ */
int len;
-// This actually means different things depending on whether the
-// packet is read or write. For read, it's the length of the
-// payload (excluding the header). For write, it's the length of
-// the packet as a whole (counting the header). Oh, well.
/**
* Create a new packet with an internal buffer of given size.
+ * @param size packet size
*/
public Ajp13Packet( int size ) {
buff = new byte[size];
}
+/**
+ * Create a new packet with given bytes
+ * @param b this packet's bytes.
+ */
public Ajp13Packet( byte b[] ) {
buff = b;
}
+/**
+ * Set the encoding to use for byte[] - string
+ * conversions.
+ * @param encoding the encoding to use.
+ */
+public void setEncoding(String encoding) {
+this.encoding = encoding;
+}
+
+/**
+ * Get the encoding used for byte[] - string
+ * conversions.
+ * @return the encoding used.
+ */
+public String getEncoding() {
+return encoding;
+}
+
+/**
+ * Get the internal buffer
+ * @return internal buffer
+ */
public byte[] getBuff() {
return buff;
}
-
+
+/**
+ * Get length.
+ * @return length -- This actually means different things depending on whether
the
+ * packet is read or write. For read, it's the length of the
+ * payload (excluding the header). For write, it's the
length of
+ * the packet as a whole (counting the header). Oh, well.
+ */
public int getLen() {
return len;
}
-
+
+/**
+ * Get offset into internal buffer.
+ * @return offset
+ */
public int getByteOff() {
return pos;
}
+/**
+ * Set offset into internal buffer.
+ * @param c new offset
+ */
public void setByteOff(int c) {
pos=c;
}
@@ -190,7 +246,7 @@
* code, where it saves a round of copying. A null string is
* encoded as a string with length 0.
*/
-public void appendString( String str ) {
+public void appendString(String str) throws UnsupportedEncodingException {
// Dual use of the buffer - as Ajp13Packet and as OutputBuffer
// The idea is simple - fewer buffers, smaller footprint and less
// memcpy. The code is a bit tricky, but only local to this
@@ -206,7 +262,7 @@
// XXX i don't have OutputBuffer in tc4... ks.
// fix this later...
//
-byte[] bytes = str.getBytes();
+byte[] bytes = str.getBytes(encoding);
appendBytes(bytes, 0, bytes.length);
/*
@@ -328,7 +384,7 @@
// System.out.println(null string + length);
return null;
}
-String s = new String( buff, pos, length, DEFAULT_CHAR_ENCODING );
+String s = new String(buff, pos, length, encoding);
pos += length;
pos++; // Skip the terminating \0
cvs commit: jakarta-tomcat-connectors/jk/src/java/org/apache/ajp/test TestAll.java TestAjp13.java
seguin 01/05/29 16:05:58
Modified:jk build.properties.sample build.xml
jk/src/java/org/apache/ajp/test TestAjp13.java
Added: jk/src/java/org/apache/ajp/test TestAll.java
Log:
the beginnings of some junit testing
Revision ChangesPath
1.2 +17 -1 jakarta-tomcat-connectors/jk/build.properties.sample
Index: build.properties.sample
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/build.properties.sample,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- build.properties.sample 2001/05/29 05:47:29 1.1
+++ build.properties.sample 2001/05/29 23:05:52 1.2
@@ -2,9 +2,25 @@
# sample build.properties for ajp connector.
# edit to taste...
#
-# $Id: build.properties.sample,v 1.1 2001/05/29 05:47:29 seguin Exp $
+# $Id: build.properties.sample,v 1.2 2001/05/29 23:05:52 seguin Exp $
#
+#
+# tomcat 4 internals
+#
catalina.jar = ../../jakarta-tomcat-4.0/build/server/lib/catalina.jar
+
+#
+# servlet api 2.3
+#
servlet.jar = ../../jakarta-servletapi-4/dist/lib/servlet.jar
+
+#
+# utils.
+#
tomcat-util.jar = ../util/build/lib/tomcat-util.jar
+
+#
+# junit jar
+#
+junit.jar=f:/dev/junit/junit.jar
1.6 +40 -1 jakarta-tomcat-connectors/jk/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/build.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- build.xml 2001/05/29 05:47:15 1.5
+++ build.xml 2001/05/29 23:05:53 1.6
@@ -6,6 +6,26 @@
property name=jk.build value=${basedir}/build/
+!-- Should all tests fail if one does? --
+property name=test.failonerror value=true/
+
+!-- The test runner to execute --
+property name=test.runner value=junit.textui.TestRunner/
+property name=test.entry value=org.apache.ajp.test.TestAll/
+
+path id=test.classpath
+pathelement location=${jk.build}/classes/
+ pathelement location=${tomcat-util.jar}/
+ pathelement location=${junit.jar}/
+/path
+
+path id=build-main.classpath
+ pathelement location=${tomcat-util.jar}/
+pathelement location=${catalina.jar}/
+pathelement location=${servlet.jar}/
+ pathelement location=${junit.jar}/
+/path
+
target name=build-prepare
mkdir dir=${jk.build}/
mkdir dir=${jk.build}/classes/
@@ -16,13 +36,13 @@
javac srcdir=src/java
destdir=${jk.build}/classes
-classpath=${tomcat-util.jar}:${catalina.jar}:${servlet.jar}
deprecation=on
debug=on
optimize=off
verbose=off
excludes=**/CVS/**
exclude name=org/apache/ajp/tomcat4/** if=tomcat4.skip/
+ classpath refid=build-main.classpath/
/javac
!-- Copy static resource files --
@@ -36,6 +56,25 @@
basedir=${jk.build}/classes
/
/target
+
+target name=test if=test.entry depends=build-main
+description=Run all unit test cases
+!--
+ junit printsummary=yes fork=on haltonfailure=yes
+ formatter type=plain usefile=false/
+ test name=${test.entry}/
+classpath refid=test.classpath/
+ /junit
+ --
+
+ java classname=${test.runner} fork=yes
+ failonerror=${test.failonerror}
+ !--jvmarg value=${java.protocol.handler.pkgs}/--
+ arg value=${test.entry}/
+ classpath refid=test.classpath/
+ /java
+/target
+
!-- BUILD: Create Jk Javadocs === --
target name=javadoc
1.3 +227 -57
jakarta-tomcat-connectors/jk/src/java/org/apache/ajp/test/TestAjp13.java
Index: TestAjp13.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/src/java/org/apache/ajp/test/TestAjp13.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- TestAjp13.java2001/05/17 23:55:33 1.2
+++ TestAjp13.java2001/05/29 23:05:57 1.3
@@ -7,79 +7,249 @@
import java.net.*;
import java.util.*;
-public class TestAjp13 {
+// junit
+import junit.framework.*;
-public static void main(String[] args) throws Exception {
-ServerSocket server = new ServerSocket(8009);
-System.out.println(TestAjp13 running...);
-Socket socket = server.accept();
-Ajp13 ajp13 = new Ajp13();
-MimeHeaders headers = new MimeHeaders();
-AjpRequest request = new AjpRequest();
-ajp13.setSocket(socket);
+public class
Re: mod_webapp under Linux
it looks like the problem is you're using apache 1.3 (not multi-thread on non-win32 systems) with a multi-threaded build of apr (pthread_sigmask is an export from libpthread.so). i'm just guessing, but i imagine you can build apr in single-thread mode... Dave Oxley wrote: I'm running RH7.1 with kernel 2.4.5 and I have statically compiled and installed apr dated 28/5/2001. mod_webapp compiles but apache doesn't start with the following output: Syntax error on line 1 of /usr/local/tomcat4-CVS/conf/mod_webapp.conf: Cannot load /usr/local/tomcat4-CVS/bin/connector/mod_webapp.so into server: /usr/local/tomcat4-CVS/bin/connector/mod_webapp.so: undefined symbol: pthread_sigmask /usr/local/apache/bin/apachectl start: httpd could not be started Anyone got an idea about the undefined symbol? Dave. [EMAIL PROTECTED] _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Re: Problems With multi part Request
Are you using ajp13 to connect apache to tomcat?
Re: mod_webapp under Linux
kevin seguin at [EMAIL PROTECTED] wrote: it looks like the problem is you're using apache 1.3 (not multi-thread on non-win32 systems) with a multi-threaded build of apr (pthread_sigmask is an export from libpthread.so). i'm just guessing, but i imagine you can build apr in single-thread mode... Yes, it's a bug in the current APR release with Linux... (Digging into it) Pier
Re: Problem+Fix concerning static error pages in Tomcat 3.2.2
I use virtual hosts, but don't think that is the cause, although I have not traced this down (I will check that aswell). As I think of it, the webapp could simply be empty one with a web.xml like: ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN http://java.sun.com/j2ee/dtds/web-app_2_2.dtd; web-app error-page error-code404/error-code location/errors/404.html/location /error-page /web-app Now, when I request any file through Tomcat, it will fail (error 500: Stack overflow). When a JSP is specified for location, it works fine. Tomcat outputs a correct message from the CM about the requested error page, but FileHandler outputs the originally requested path as requested file. I will set up an independent Tomcat installation and try this again without virtual hosts. If I have the time today, I will wrap up a webapp and post the .war file. - Original Message - From: Marc Saegesser [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, May 29, 2001 8:54 PM Subject: RE: Problem+Fix concerning static error pages in Tomcat 3.2.2 Could you please supply a sample webapp that demonstrates this? Static error pages seem to work OK for me. -Original Message- From: Peer Heijnen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 29, 2001 5:52 AM To: tomcat-dev Subject: Problem+Fix concerning static error pages in Tomcat 3.2.2 I'm using Tomcat 3.2.2 (relase) and have configured static .html files as error pages. We used JSP pages before, and everything was fine... However since we're using static files, Tomcat will enter an infinite loop and eventually crash with a stack overflow (with a good change of leaving Tomcat in a defunct state). We traced down this problem and have found a way to fix it, but I'm not sure if this is correct. All this is related to the ContextManager class: 1) Both handleStatus and handleError will call 'getHandlerForPath' when an error page was configured. 2) getHandlerForPath returns a the Handler for the error page. (since we're using static files, this will be a FileHandler). So far, so good. 3) Eventually handleStatus and handleError will do a 'errorServlet.service( req, res )' to service the error. This is were things go wrong. The problem is, that 'req' passed to the 'errorServlet.service( req, res )' call is the original request, while getHandlerForPath creates a new request internally with the error's request URI. Since the handler (FileHandler) is called with the original request URI, it will try to service a file matching that request, not the static file we configured. This, in turn, will cause and error and, in our case, an infinite loop. This can lead to very strange situations. For example, if an .jsp page generates an error and the error refers to an (existing) static file, it will actually end up showing the .jsp source file contents! The quick and dirty fix we use here is to simply add 'req.setRequestURI( ctx.getPath() + errorPath);' after the 'getHandlerForPath' calls in both handleError and handleStatus methods. I'm not really sure if we are allowed to modify the request in such a way, but error attributes are also set in this request and it seems to work fine for us. But this raises another question: why construct a completely new request and response in getHandlerForPath, and then throw it away? Cheers, Peer Heijnen
JDBC DataSource setting
Does Tomcat 3.2.1 support setting a JDBC DataSource I know that I've seen messages about Tomcat 4.0 supporting it? If so how do I go about setting this up Tomcat 3.2.1? -Ben
