[PATCH] ajp13 post 8K
Fixed that one :-)
---
jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Ajp13ConnectorR
equest.java.origWed Nov 15 00:04:02 2000
+++
jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Ajp13ConnectorR
equest.java Wed Nov 15 00:04:32 2000
@@ -249,7 +249,7 @@
public int doRead() throws IOException
{
-if(pos blen) {
+if(pos = blen) {
refeelReadBuffer();
}
return bodyBuff[pos++];
Thanks to kenneth topp [EMAIL PROTECTED] for providing
an example which allow me to replay the game
Thanks to apply this to both 3.2 and 3.3 branch (same ajp code).
Also in TC 3.3 apply the same modification to
org.apache.tomcat.modules.server.Ajp13 :
@@ -300,7 +300,7 @@
public int doRead() throws IOException
{
-if(pos blen) {
+if(pos = blen) {
refeelReadBuffer();
}
return bodyBuff[pos++];
Two bugs less in TC ;-)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[PROPOSED 3.2B7 PATCH] error displayed for case mismatch in JSP URL
In Tomcat 3.2b7 (and earlier), invoking
http://localhost:8080/test/jsp/Helloworld.jsp results in an NPE in
JspCompiler.isOutDated(). This occurs because getRealPath() returns
null since the 'w' should be uppercase, hence it is considered an
"unsafe" path. To make this error return "file not found", I propose
the following patches for 3.2b7.
= JspCompiler.java Patch =
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/JspCompiler.java,v
retrieving revision 1.14.2.1
diff -u -r1.14.2.1 JspCompiler.java
--- JspCompiler.java2000/07/25 20:45:09 1.14.2.1
+++ JspCompiler.java2000/11/15 12:13:12
@@ -304,7 +304,11 @@
public boolean isOutDated() {
File jspReal = null;
-jspReal = new File(ctxt.getRealPath(jsp.getPath()));
+String realPath = ctxt.getRealPath(jsp.getPath());
+if (realPath == null)
+return true;
+
+jspReal = new File(realPath);
File classFile = new File(getClassFileName());
if (classFile.exists()) {
==
= JspReader.java patch =
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/JspReader.java,v
retrieving revision 1.16.2.4
diff -u -r1.16.2.4 JspReader.java
--- JspReader.java 2000/11/06 04:08:14 1.16.2.4
+++ JspReader.java 2000/11/15 12:12:29
@@ -171,6 +171,9 @@
? file.getAbsolutePath()
: context.getRealPath(file.toString());
+ if (longName == null)
+ throw new FileNotFoundException(file.toString());
+
int fileid = registerSourceFile(longName);
if (fileid == -1)
This probably won't eliminate the head scratching, but at least they will
be scratching their heads for the right reason. :-) Also, this will make
section 6.7 in the Readme correct about the error seen due to a case mismatch.
If no one objects, I'll commit these changes this afternoon.
Cheers,
Larry
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/jasper/runtime JspRuntimeLibrary.java
larryi 00/11/15 06:53:07
Modified:src/share/org/apache/jasper/runtime JspRuntimeLibrary.java
Log:
Port fix for: Conversion of String to boolean was erroneous
Submitted by: Gareth Morgan [EMAIL PROTECTED]
Revision ChangesPath
1.6 +4 -4
jakarta-tomcat/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java
Index: JspRuntimeLibrary.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- JspRuntimeLibrary.java2000/07/25 12:13:53 1.5
+++ JspRuntimeLibrary.java2000/11/15 14:53:07 1.6
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java,v
1.5 2000/07/25 12:13:53 glenn Exp $
- * $Revision: 1.5 $
- * $Date: 2000/07/25 12:13:53 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java,v
1.6 2000/11/15 14:53:07 larryi Exp $
+ * $Revision: 1.6 $
+ * $Date: 2000/11/15 14:53:07 $
*
*
*
@@ -322,7 +322,7 @@
} else if (t.equals(boolean.class)) {
boolean[] tmpval = new boolean[values.length];
for (int i = 0 ; i values.length; i++)
- tmpval[i] = Boolean.getBoolean (values[i]);
+ tmpval[i] = (Boolean.valueOf(values[i])).booleanValue();
method.invoke (bean, new Object[] {tmpval});
} else if (t.equals(short.class)) {
short[] tmpval = new short[values.length];
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
BugRat Report #388 has been filed.
Bug report #388 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com:/BugRatViewer/ShowReport/388 REPORT #388 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: serious Confidence: public Environment: Release: 3.1 JVM Release: 1.2.2 Operating System: Linux OS Release: RedHat 6.2 Platform: Intel Synopsis: GET header defaults to be iso-8859-1 encoded which breaks intl' forms passed by GET Description: In org.apache.tomcat.service.http.Constants, CharacterEncoding.Default is used to specify the supposed encoding of request URI. while I understand, that this is standard it completely disallows forms with non-8859-1 characters to be sent and processed via GET. It would be nice to be able to specify this encoding on at least per-system basis, it would be cool to be able to set this encoding on per-context basis, but i'm afraid, that by the time of decoding URI, the servlet is not yet known, since it is choosen on the URI basis ;-)) Title: BugRat Report # 388 BugRat Report # 388 Project: Tomcat Release: 3.1 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: serious Confidence: public Submitter: Skopal Jakub ([EMAIL PROTECTED]) Date Submitted: Nov 15 2000, 10:13:20 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: GET header defaults to be iso-8859-1 encoded which breaks intl' forms passed by GET Environment: (jvm, os, osrel, platform) 1.2.2, Linux, RedHat 6.2, Intel Additional Environment Description: Report Description: In org.apache.tomcat.service.http.Constants, CharacterEncoding.Default is used to specify the supposed encoding of request URI. while I understand, that this is standard it completely disallows forms with non-8859-1 characters to be sent and processed via GET. It would be nice to be able to specify this encoding on at least per-system basis, it would be cool to be able to set this encoding on per-context basis, but i'm afraid, that by the time of decoding URI, the servlet is not yet known, since it is choosen on the URI basis ;-)) View this report online... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
BugRat Report #389 has been filed.
Bug report #389 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com:/BugRatViewer/ShowReport/389 REPORT #389 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: serious Confidence: public Environment: Release: 3.2 beta6 + beta7 JVM Release: SUN JDK1.2.2 and JDK1.3 Operating System: Solaris 7 OS Release: Sun 5.7 Generic_106541_11 Platform: E450 Synopsis: AJP13 - buffer overread for POST data with apache and mod_jk Description: I'm using using a servlet to read data POSTed by a html form, everything works ok unless one of the fields get longer than about 1400 characters. If that happens tomcat produces the follow errors. (Static trace from tomcat 3.2beta-7) java.lang.ArrayIndexOutOfBoundsException at org.apache.tomcat.service.connector.Ajp13ConnectorRequest.doRead(Ajp13ConnectorRequest.java:255) at org.apache.tomcat.service.connector.Ajp13ConnectorRequest.doRead(Ajp13ConnectorRequest.java:262) at org.apache.tomcat.core.BufferedServletInputStream.doRead(BufferedServletInputStream.java:111) at org.apache.tomcat.core.BufferedServletInputStream.read(BufferedServletInputStream.java:144) at javax.servlet.http.HttpUtils.parsePostData(HttpUtils.java:235) at org.apache.tomcat.util.RequestUtil.readFormData(RequestUtil.java:101) at org.apache.tomcat.core.RequestImpl.handleParameters(RequestImpl.java:691) at org.apache.tomcat.core.RequestImpl.getParameterValues(RequestImpl.java:259) at org.apache.tomcat.core.RequestImpl.getParameter(RequestImpl.java:250) at org.apache.tomcat.facade.HttpServletRequestFacade.getParameter(HttpServletRequestFacade.java:222) at org.apache.jasper.servlet.JspServlet.preCompile(JspServlet.java:326) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:370) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:799) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:745) at org.apache.tomcat.service.connector.Ajp13ConnectionHandler.processConnection(Ajp13ConnectionHandler.java:160) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:407) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498) at java.lang.Thread.run(Thread.java:479) It looks like a buffer is being overread here. Notes that my jsp page is nowhere in the stack trace so this must be an internal tomcat problem. I've reproduced the bug under both JDK1.2.2 and JDK1.3.0 from Sun, and for both tomcat 3.2 beta6 and beta7 Title: BugRat Report # 389 BugRat Report # 389 Project: Tomcat Release: 3.2 beta6 + beta7 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: serious Confidence: public Submitter: _Anonymous ([EMAIL PROTECTED]) Date Submitted: Nov 15 2000, 10:25:40 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: AJP13 - buffer overread for POST data with apache and mod_jk Environment: (jvm, os, osrel, platform) SUN JDK1.2.2 and JDK1.3, Solaris 7, Sun 5.7 Generic_106541_11, E450 Additional Environment Description: Apache 1.3.12 and mod_jk.so Report Description: I'm using using a servlet to read data POSTed by a html form, everything works ok unless one of the fields get longer than about 1400 characters. If that happens tomcat produces the follow errors. (Static trace from tomcat 3.2beta-7) java.lang.ArrayIndexOutOfBoundsException at org.apache.tomcat.service.connector.Ajp13ConnectorRequest.doRead(Ajp13ConnectorRequest.java:255) at org.apache.tomcat.service.connector.Ajp13ConnectorRequest.doRead(Ajp13ConnectorRequest.java:262) at org.apache.tomcat.core.BufferedServletInputStream.doRead(BufferedServletInputStream.java:111) at org.apache.tomcat.core.BufferedServletInputStream.read(BufferedServletInputStream.java:144) at javax.servlet.http.HttpUtils.parsePostData(HttpUtils.java:235) at org.apache.tomcat.util.RequestUtil.readFormData(RequestUtil.java:101) at org.apache.tomcat.core.RequestImpl.handleParameters(RequestImpl.java:691) at org.apache.tomcat.core.RequestImpl.getParameterValues(RequestImpl.java:259) at org.apache.tomcat.core.RequestImpl.getParameter(RequestImpl.java:250) at org.apache.tomcat.facade.HttpServletRequestFacade.getParameter(HttpServletRequestFacade.java:222) at org.apache.jasper.servlet.JspServlet.preCompile(JspServlet.java:326) at
BugRat Report #390 has been filed.
Bug report #390 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com:/BugRatViewer/ShowReport/390 REPORT #390 Details. Project: Tomcat Category: Feature Requests SubCategory: New Feature Class: swbug State: received Priority: high Severity: serious Confidence: public Environment: Release: Tomcatr 3.2 beta6+7 JVM Release: Sun JDK1.2.2 + JDK1.3 Operating System: Solaris 7 OS Release: SunOs 5.7 Generic_106541-1 Platform: E450 3.5GB 4*ultrasparc II 300Mhz Synopsis: (more readable report) AJP13 - buffer overread for POST data with apache and mod_jk Description: I'm using using a servlet to read data POSTed by a html form, everything works ok unless one of the fields get longer than about 1400 characters. If that happens tomcat produces the follow error:P (Static trace from tomcat 3.2beta-7) P java.lang.ArrayIndexOutOfBoundsException at org.apache.tomcat.service.connector.Ajp13ConnectorRequest.doRead(Ajp13ConnectorRequest.java:255)BR at org.apache.tomcat.service.connector.Ajp13ConnectorRequest.doRead(Ajp13ConnectorRequest.java:262)BR at org.apache.tomcat.core.BufferedServletInputStream.doRead(BufferedServletInputStream.java:111)BR at org.apache.tomcat.core.BufferedServletInputStream.read(BufferedServletInputStream.java:144)BR at javax.servlet.http.HttpUtils.parsePostData(HttpUtils.java:235)BR at org.apache.tomcat.util.RequestUtil.readFormData(RequestUtil.java:101)BR at org.apache.tomcat.core.RequestImpl.handleParameters(RequestImpl.java:691)BR at org.apache.tomcat.core.RequestImpl.getParameterValues(RequestImpl.java:259)BR at org.apache.tomcat.core.RequestImpl.getParameter(RequestImpl.java:250)BR at org.apache.tomcat.facade.HttpServletRequestFacade.getParameter(HttpServletRequestFacade.java:222)BR at org.apache.jasper.servlet.JspServlet.preCompi! le(JspServlet.java:326)BR at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:370)BR at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)BR at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404)BR at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)BR at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:799)BR at org.apache.tomcat.core.ContextManager.service(ContextManager.java:745)BR at org.apache.tomcat.service.connector.Ajp13ConnectionHandler.processConnection(Ajp13ConnectionHandler.java:160)BR at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:407)BR at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498)BR at java.lang.Thread.run(Thread.java:479)P It looks like a buffer is being overread here. Notes that my jsp page is nowhere in the stack trace so this must be an internal tomcat problem. I've reproduced the bug under both JDK1.2.2 and JDK1.3.0 from Sun, and for both tomcat 3.2 beta6 and beta7 Title: BugRat Report # 390 BugRat Report # 390 Project: Tomcat Release: Tomcatr 3.2 beta6+7 Category: Feature Requests SubCategory: New Feature Class: swbug State: received Priority: high Severity: serious Confidence: public Submitter: Barry Adams ([EMAIL PROTECTED]) Date Submitted: Nov 15 2000, 10:38:34 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: (more readable report) AJP13 - buffer overread for POST data with apache and mod_jk Environment: (jvm, os, osrel, platform) Sun JDK1.2.2 + JDK1.3, Solaris 7, SunOs 5.7 Generic_106541-1, E450 3.5GB 4*ultrasparc II 300Mhz Additional Environment Description: apache 1.3.12 and mod_jk.so Report Description: I'm using using a servlet to read data POSTed by a html form, everything works ok unless one of the fields get longer than about 1400 characters. If that happens tomcat produces the follow error: (Static trace from tomcat 3.2beta-7) java.lang.ArrayIndexOutOfBoundsException at org.apache.tomcat.service.connector.Ajp13ConnectorRequest.doRead(Ajp13ConnectorRequest.java:255) at org.apache.tomcat.service.connector.Ajp13ConnectorRequest.doRead(Ajp13ConnectorRequest.java:262) at org.apache.tomcat.core.BufferedServletInputStream.doRead(BufferedServletInputStream.java:111) at org.apache.tomcat.core.BufferedServletInputStream.read(BufferedServletInputStream.java:144) at javax.servlet.http.HttpUtils.parsePostData(HttpUtils.java:235) at org.apache.tomcat.util.RequestUtil.readFormData(RequestUtil.java:101) at org.apache.tomcat.core.RequestImpl.handleParameters(RequestImpl.java:691) at org.apache.tomcat.core.RequestImpl.getParameterValues(RequestImpl.java:259) at org.apache.tomcat.core.RequestImpl.getParameter(RequestImpl.java:250) at org.apache.tomcat.facade.HttpServletRequestFacade.getParameter(HttpServletRequestFacade.java:222) at org.apache.jasper.servlet.JspServlet.preCompi! le(JspServlet.java:326) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:370) at
Interesting issue with Java and Cygwin under WIN32
We have identified an interesting issue, which I am not sure how to resolve (if it ever will), and it is not directly relevant to Jakarta. In our application, in order to leverage the work that has been done for operating in a Unix environment (rcX.d scripts, utility scripts), we have decided to use Cygwin to provide a similar environment when working on a Win32 environment. What it interesting to note is that we find problems with platform dependent Java items (like fileSeparator, pathSeparator), which take it from the host environment and prevent from setting it up externally. In fact, I would like the ability to override the Win32 default in a CygWin environment. Any ideas ? Opinions ? Thanks, Arieh -- Arieh Markel Sun Microsystems Inc. Network Storage500 Eldorado Blvd. MS UBRM11-194 e-mail: [EMAIL PROTECTED] Broomfield, CO 80021 Let's go Panthers Phone: (303) 272-8547 x78547 (e-mail me with subject SEND PUBLIC KEY to get public key) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Servlet - Jini - Tomcat3.1
- Original Message - Flavio, It is not clear from your description what you are trying to do. . does your server issue a query to obtain a Jini service reference from a lookup server ? Exactly, my servlet just make an unicast to receive from the lookup server the Registrar (LookupLocator.GETREGISTRAR) . The exception appears after that call. If it helps, I am trying to connect a servlet to a JavaSpace and TransactionManager (mahalo) services. . are you expecting that the Jini service will upload the WAR over the net to be incorporated ? This I didn't understand... (???) Arieh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
BugRat Report #391 has been filed.
Bug report #391 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com:/BugRatViewer/ShowReport/391 REPORT #391 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Environment: Release: 3.1 JVM Release: Sun JDK 1.3 Operating System: Solaris OS Release: 2.6 Platform: SPARC Synopsis: socket.close() doesn't always close underlying connection in HttpConnectionHandler Description: In the main HttpConnectionHandler loop, the call to socket.close() sometimes fails to close the underlying socket and thus the connection to the browser. The result is a spinning Netscape/IE icon while the browser thinks there is more page to load. The problem only appears when we are using the Oracle JDBC driver in OCI8 mode. If we don't use JDBC, or if we use the "thin" driver, the connection-close problem disappears. Title: BugRat Report # 391 BugRat Report # 391 Project: Tomcat Release: 3.1 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Submitter: Bill Schneider ([EMAIL PROTECTED]) Date Submitted: Nov 15 2000, 11:21:55 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: socket.close() doesn't always close underlying connection in HttpConnectionHandler Environment: (jvm, os, osrel, platform) Sun JDK 1.3, Solaris, 2.6, SPARC Additional Environment Description: Report Description: In the main HttpConnectionHandler loop, the call to socket.close() sometimes fails to close the underlying socket and thus the connection to the browser. The result is a spinning Netscape/IE icon while the browser thinks there is more page to load. The problem only appears when we are using the Oracle JDBC driver in OCI8 mode. If we don't use JDBC, or if we use the "thin" driver, the connection-close problem disappears. Workaround: null View this report online... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Servlet - Jini - Tomcat3.1
From: "Flávio Rodrigo M. de Carvalho" [EMAIL PROTECTED] To: "Arieh Markel" [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Servlet - Jini - Tomcat3.1 - Original Message - Flavio, It is not clear from your description what you are trying to do. . does your server issue a query to obtain a Jini service reference from a lookup server ? Exactly, my servlet just make an unicast to receive from the lookup server the Registrar (LookupLocator.GETREGISTRAR) . The exception appears after that call. If it helps, I am trying to connect a servlet to a JavaSpace and TransactionManager (mahalo) services. . are you expecting that the Jini service will upload the WAR over the net to be incorporated ? This I didn't understand... (???) The fact that an exception of casting happens on a class expected to be WARConnection leads me to believe that the code you have is expecting to have a 'war' file downloaded from over the network. So my question is if what you intended to do is the following: . access an object from the JavaSpace and have that object become/incorporate a web-application to the Tomcat container I really can't see how there is a relationship between the Jini Lookup invocation and the exception thrown. I wonder if you could post the code (the method) in which this happens. Arieh Arieh -- Arieh Markel Sun Microsystems Inc. Network Storage500 Eldorado Blvd. MS UBRM11-194 e-mail: [EMAIL PROTECTED] Broomfield, CO 80021 Let's go Panthers Phone: (303) 272-8547 x78547 (e-mail me with subject SEND PUBLIC KEY to get public key) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Need help for redirector of iplanet to Tomcat
Hello every one, I have great deal of problems to get the Netscape redirector working. I followed the Ho-To . installation steps religiously, but got still no luck. My environment is the following: -IPlanet Enterprise Web Server 4.1 (SP3) - Tomcat V3.2 beta-07 - Jdk1.2.2 After I installed nsapi_redirect.dll I could not start Web Server, I got the following diagnostic: Web Server: [14/Nov/2000:01:56:12] info ( 274): iPlanet-WebServer-Enterprise/4.1SP3 BB1-09/17/2000 02:30 [14/Nov/2000:01:56:13] failure ( 274): Configuration initialization failed: Error running init function jk_init: unknown error NSAPI redirector: [jk_worker.c (98)]: Into wc_open [jk_worker.c (217)]: Into build_worker_map, creating 2 workers [jk_worker.c (223)]: build_worker_map, creating worker ajp12 [jk_worker.c (154)]: Into wc_create_worker [jk_worker.c (168)]: wc_create_worker, about to create instance ajp12 of ajp12 [jk_ajp12_worker.c (264)]: Into ajp12_worker_factory [jk_worker.c (177)]: wc_create_worker, about to validate and init ajp12 [jk_ajp12_worker.c (182)]: Into jk_worker_t::validate [jk_ajp12_worker.c (194)]: In jk_worker_t::validate for worker ajp12 contact is localhost:8007 [jk_worker.c (187)]: wc_create_worker, done [jk_worker.c (233)]: build_worker_map, removing old ajp12 worker [jk_worker.c (223)]: build_worker_map, creating worker ajp13 [jk_worker.c (154)]: Into wc_create_worker [jk_worker.c (164)]: wc_create_worker NULL factory for ajp13 [jk_worker.c (239)]: build_worker_map failed to create workerajp13 [jk_nsapi_plugin.c (129)]: In init_workers_on_other_threads, failed [jk_nsapi_plugin.c (271)]: jk_init, a second passed [jk_worker.c (98)]: Into wc_open [jk_worker.c (217)]: Into build_worker_map, creating 2 workers [jk_worker.c (223)]: build_worker_map, creating worker ajp12 [jk_worker.c (154)]: Into wc_create_worker [jk_worker.c (168)]: wc_create_worker, about to create instance ajp12 of ajp12 [jk_ajp12_worker.c (264)]: Into ajp12_worker_factory [jk_worker.c (177)]: wc_create_worker, about to validate and init ajp12 [jk_ajp12_worker.c (182)]: Into jk_worker_t::validate [jk_ajp12_worker.c (194)]: In jk_worker_t::validate for worker ajp12 contact is localhost:8007 [jk_worker.c (187)]: wc_create_worker, done [jk_worker.c (233)]: build_worker_map, removing old ajp12 worker [jk_worker.c (223)]: build_worker_map, creating worker ajp13 [jk_worker.c (154)]: Into wc_create_worker [jk_worker.c (164)]: wc_create_worker NULL factory for ajp13 [jk_worker.c (239)]: build_worker_map failed to create workerajp13 [jk_nsapi_plugin.c (129)]: In init_workers_on_other_threads, failed [jk_nsapi_plugin.c (271)]: jk_init, a second passed Im wondering, what could be wrong with the ajp13 ? I made sure that the port 8009 is not in use, but still no luck . Thanks Bo Yang P.S I also attached my obj.conf and Obj.cof: # Sun Netscape Alliance - obj.conf # You can edit this file, but comments and formatting changes # might be lost when the admin server makes changes. # Use only forward slashes in pathnames--backslashes can cause # problems. See the documentation for more information. Init fn="flex-init" access="C:/Netscape/Server4/https-bo_yang/logs/access" format.access="%Ses-client.ip% - %Req-vars.auth-user% [%SYSDATE%] \"%Req-reqpb.clf-request%\" %Req-srvhdrs.clf-status% %Req-srvhdrs.content-length%" Init fn="load-types" mime-types="mime.types" Init fn="load-modules" funcs="jk_init,jk_service" shlib="E:/Tools/Servlet_Jsp/Tomcat/bin/netscape/nt4/i386/nsapi_redirect.dll" Init fn="jk_init" worker_file="E:/Tools/Servlet_Jsp/Tomcat/conf/workers.properties" log_level="debug" log_file="E:/Tools/Servlet_Jsp/Tomcat/logs/nsapi.log" Object name="default" NameTrans fn="pfx2dir" from="/ns-icons" dir="C:/Netscape/Server4/ns-icons" name="es-internal" NameTrans fn="pfx2dir" from="/mc-icons" dir="C:/Netscape/Server4/ns-icons" name="es-internal" NameTrans fn="pfx2dir" from="/help" dir="C:/Netscape/Server4/manual/https/ug" name="es-internal" NameTrans fn="pfx2dir" from="/manual" dir="C:/Netscape/Server4/manual/https" name="es-internal" NameTrans fn="document-root" root="C:/Netscape/Server4/docs" NameTrans fn="assign-name" from="/servlet/*" name="servlet" NameTrans fn="assign-name" from="/examples/*" name="servlet" PathCheck fn="nt-uri-clean" PathCheck fn="check-acl" acl="default" PathCheck fn="find-pathinfo" PathCheck fn="find-index" index-names="index.html,home.html" ObjectType fn="type-by-extension" ObjectType fn="force-type" type="text/plain" Service method="(GET|HEAD)" type="magnus-internal/imagemap" fn="imagemap" Service method="(GET|HEAD)" type="magnus-internal/directory" fn="index-common" Service method="(GET|HEAD)" type="*~magnus-internal/*" fn="send-file" AddLog fn="flex-log" name="access" /Object Object name="cgi" ObjectType fn="force-type"
Re: [PATCH] ajp13 post 8K
Actually, thank you. very much. Argh... I should have spent some time
tracing that.. I hope I would have found that one.
tomcat 3.2 is really ready to go, IMO.
Congrats on a great release,
Kenneth Topp
On Wed, 15 Nov 2000, GOMEZ Henri wrote:
Fixed that one :-)
---
jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Ajp13ConnectorR
equest.java.orig Wed Nov 15 00:04:02 2000
+++
jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Ajp13ConnectorR
equest.java Wed Nov 15 00:04:32 2000
@@ -249,7 +249,7 @@
public int doRead() throws IOException
{
-if(pos blen) {
+if(pos = blen) {
refeelReadBuffer();
}
return bodyBuff[pos++];
Thanks to kenneth topp [EMAIL PROTECTED] for providing
an example which allow me to replay the game
Thanks to apply this to both 3.2 and 3.3 branch (same ajp code).
Also in TC 3.3 apply the same modification to
org.apache.tomcat.modules.server.Ajp13 :
@@ -300,7 +300,7 @@
public int doRead() throws IOException
{
-if(pos blen) {
+if(pos = blen) {
refeelReadBuffer();
}
return bodyBuff[pos++];
Two bugs less in TC ;-)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ajpv13 protocol
Is there a separate mod_jk list? I've posted a severe bug for ajp13, and I would like to contribute, but I don't see a TODO for mod_jk or much discussion on plans for mod_jk and related containers. That's because right now ( AFAIK ) there is no imediate plan for mod_jk. It works well enough ( IMHO ), and future enhancements will be made only if anyone will volunteer to do so. I am willing and interested to help , but I'll not start or drive this. A possible TODO list: 1. Callbacks - allow tomcat to use more of the servers features, like authentication, sub-requests, etc - including configuration 2. Performance - do not send the full request, most of the time only few headers are used and if all are needed we can make a callback. Also, the request is already parsed by Apache/IIS/NES, so we can skip this on tomcat. 3. More work on "in-process/JNI" mode - there is a lot of un-exploited speed and features out there, including the integration of Interceptors and server Modules/filters/SAFs. ( that's on my todo list for 1 year, but I never had the time to start :-( 4. Integration with mod_warp ( when ready ) - mod_warp will add a lot of new features, and we must find a way to either join the 2 modules. For example, mod_jk has support for many web servers, and mod_wrap will support automatic configuration - it would be great if we could merge them. If you are interested in helping with mod_jk - I'm sure you'll have your own preferences - let us know, send code, drive this ! Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need help for redirector of iplanet to Tomcat
Hi, Costin: First of all thank you very much for you reply (to tell the truth, I started to lose the light at the end of the tunnel). Since we are entirely Java shop, I used pre-compiled mod_jk, and my platform is Windows NT 4.0 (SP6) IPlanet4.1(SP3), Yes, I tried to run Tomcat with the "ajp12" only, but I got the same errors. If you have any built by yourself redirector could you share with me it please. Thanks Bo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
WWW-Authentication with Tomcat
How can I do a www-authentication with a jsp page ? I tried to set a header in the response of a page, and that bought up the popup uid/pwd window, but how do I get the values back ? Thanks Shahed - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need help for redirector of iplanet to Tomcat
First of all thank you very much for you reply (to tell the truth, I started to lose the light at the end of the tunnel). Since we are entirely Java shop, I used pre-compiled mod_jk, and my platform is Windows NT 4.0 (SP6) IPlanet4.1(SP3), Yes, I tried to run Tomcat with the "ajp12" only, but I got the same errors. If you have any built by yourself redirector could you share with me it please. Unfortunately ( or fortunately for me :-) I don't use windows. I could build it for Linux, but my evaluation version of IPlanet expired, I'll need to get a new one, etc - a lot of time that I don't have right now. In 1-2 weeks I'll have a bit more time, but my todo list is already very long - if anyone on the list will help, it would be great. I would also be interested to find if anyone else is using NES or IIS or AOL with tomcat :-). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
A question regarding source release.
Hello, I work for a company called Open Cloud. We have implemented a set of patches against tomcat 3.2b4 that allows the servlet engine to be distributed. If servlets are written specially requests can be restarted if a given servlet engine node fails. We do load balancing and distribute the session object with the same state equally across members of a cluster. So heres the situation: We are considering releasing these patches to give to the tomcat project, but they require a closed source, commercial product of ours. Are these patches useful given that they require this product ? I am not subscribed to the email alias, so if you want to reply/flame please email me directly. Cheers, -David -- David Ferry Open Cloud [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/service/connector Ajp13ConnectorRequest.java
hgomez 00/11/15 03:40:03
Modified:src/share/org/apache/tomcat/service/connector
Ajp13ConnectorRequest.java
Log:
Submitted by: [EMAIL PROTECTED]
Correct ajp13 bug when posting data more than 8k
Revision ChangesPath
1.16 +4 -4
jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Ajp13ConnectorRequest.java
Index: Ajp13ConnectorRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Ajp13ConnectorRequest.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- Ajp13ConnectorRequest.java2000/11/02 21:44:56 1.15
+++ Ajp13ConnectorRequest.java2000/11/15 11:40:03 1.16
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Ajp13ConnectorRequest.java,v
1.15 2000/11/02 21:44:56 costin Exp $
- * $Revision: 1.15 $
- * $Date: 2000/11/02 21:44:56 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Ajp13ConnectorRequest.java,v
1.16 2000/11/15 11:40:03 hgomez Exp $
+ * $Revision: 1.16 $
+ * $Date: 2000/11/15 11:40:03 $
*
*
*
@@ -246,7 +246,7 @@
public int doRead() throws IOException
{
-if(pos blen) {
+if(pos = blen) {
refeelReadBuffer();
}
return bodyBuff[pos++];
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/service/connector Ajp13ConnectorRequest.java
hgomez 00/11/15 04:03:00
Modified:src/share/org/apache/tomcat/service/connector Tag: tomcat_32
Ajp13ConnectorRequest.java
Log:
Submitted by: [EMAIL PROTECTED]
Fix the ajp13 bug when post is 8k
Revision ChangesPath
No revision
No revision
1.5.2.1 +4 -4
jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Ajp13ConnectorRequest.java
Index: Ajp13ConnectorRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Ajp13ConnectorRequest.java,v
retrieving revision 1.5
retrieving revision 1.5.2.1
diff -u -r1.5 -r1.5.2.1
--- Ajp13ConnectorRequest.java2000/06/23 10:32:39 1.5
+++ Ajp13ConnectorRequest.java2000/11/15 12:03:00 1.5.2.1
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Ajp13ConnectorRequest.java,v
1.5 2000/06/23 10:32:39 shachor Exp $
- * $Revision: 1.5 $
- * $Date: 2000/06/23 10:32:39 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Ajp13ConnectorRequest.java,v
1.5.2.1 2000/11/15 12:03:00 hgomez Exp $
+ * $Revision: 1.5.2.1 $
+ * $Date: 2000/11/15 12:03:00 $
*
*
*
@@ -249,7 +249,7 @@
public int doRead() throws IOException
{
-if(pos blen) {
+if(pos = blen) {
refeelReadBuffer();
}
return bodyBuff[pos++];
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
New Configuration tested
Tested Tomcat v3.1 NT4 SP6 Apache 1.3.14 SUN JDK1.3 And it works just fine. http://jakarta.apache.org/cvsweb/index.cgi/~checkout~/jakarta-tomcat/src/doc/Attic/Tomcat%2bApache-HOWTO?content-type=text/plain was very helpful and easily understood thank you very much. Jeff Maas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
sessionID within URL and loadbalance (was: WAP and sessionIDs)
Hi all,
The patch below fix a bug that didnt let tomcat to
run in loadbalance configuration, while having the session managed only in URL.
The mail problem with load balancing is that the
jvmRoute param (which is the tomcat name as known from apache side) must be
added to the session (ie. Assuming the sessionid was xxx it have to be changed
to xxx.t1 assuming that t1 is the name of that tomcat instance).
Now, tomcat handle jvmRoute at his side by adding
that parameter to the jsessionid cookie. THIS IS A BUG, since encode URL still
use the original sessionID (without the .jvmRoute).
In order to fix that sessionID must be changed so it
contains jvmRoute (assuming we have it). Please see the code fix below.
Please approve this (and merge with the code ASAP),
since cellular phones, which use WAP (and does not support cookies) cant work
with loadbalnce configuration of apache+tomcat.
Thanks in advance.
--Shai Fultheim.
Shai Fultheim
Chief Technology Officer
BRM Seed
E-Mail: [EMAIL PROTECTED]
Mobile: 972-53-866-459
Office: 972-2-5891-459
Index: tomcat/request/SessionInterceptor.java
===
RCS file: /home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/request/SessionInterceptor.java,v
retrieving revision 1.24.2.2
diff -u -w -r1.24.2.2 SessionInterceptor.java
--- tomcat/request/SessionInterceptor.java 2000/11/11 02:07:02 1.24.2.2
+++ tomcat/request/SessionInterceptor.java 2000/11/15 22:44:05
@@ -75,6 +75,7 @@
* This
implementation only handles Cookies sessions, please extend or
* add
new interceptors for other methods.
*
+ * @author Shai Fultheim [[EMAIL PROTECTED]] Session contains jsIdent
*/
public
class SessionInterceptor extends
BaseInterceptor
{
@@ -112,8 +113,6 @@
if
((foundAt=uri.indexOf(sig))!=-1){
sessionId=uri.substring(foundAt+sig.length());
- // I hope the optimizer
does it's job:-)
- sessionId = fixSessionId(
request, sessionId );
// rewrite URL, do I need
to do anything more?
request.setRequestURI(uri.substring(0, foundAt));
@@ -126,24 +125,6 @@
return 0;
}
-
/** Fix the session id. If the session is not valid return null.
- *
It will also clean up the session from load-balancing strings.
- * @return sessionId, or null if not valid
- */
-
private String fixSessionId(Request request, String sessionId){
- //
GS, We piggyback the JVM id on top of the session cookie
- //
Separate them ...
-
- if(
debug0 ) cm.log( Orig sessionId
+ sessionId );
- if
(null != sessionId) {
- int idex =
sessionId.lastIndexOf(SESSIONID_ROUTE_SEP);
- if(idex 0) {
- sessionId
= sessionId.substring(0, idex);
- }
- }
- return
sessionId;
-
}
-
public int beforeBody( Request rrequest,
Response response ) {
String
reqSessionId = response.getSessionId();
if( debug0 )
cm.log(Before Body + reqSessionId );
@@ -159,11 +140,6 @@
sessionPath = /;
}
- // GS, piggyback the jvm
route on the session id.
- String jvmRoute =
rrequest.getJvmRoute();
- if(null != jvmRoute) {
-
reqSessionId = reqSessionId + SESSIONID_ROUTE_SEP + jvmRoute;
- }
Cookie cookie = new
Cookie(JSESSIONID,
reqSessionId);
Index: tomcat/session/StandardManager.java
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/session/Attic/StandardManager.java,v
retrieving revision 1.11
diff -u -w -r1.11 StandardManager.java
--- tomcat/session/StandardManager.java 2000/06/18 20:14:13 1.11
+++ tomcat/session/StandardManager.java 2000/11/15 22:44:06
@@ -1,5 +1,5 @@
/*
- * $Header:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/session/Attic/StandardManager.java,v
1.11 2000/06/18 20:14:13 jon Exp $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/session/Attic/StandardManager.java,v
1.11 2000/06/18 20:14:13 jon Exp $
*
$Revision: 1.11 $
*
$Date: 2000/06/18 20:14:13 $
*
@@ -102,6 +102,7 @@
*
@author Craig R. McClanahan
*
@author [EMAIL PROTECTED]
*
@author a href=mailto:[EMAIL PROTECTED]Jon S.
Stevens/a
+ * @author Shai Fultheim [[EMAIL PROTECTED]] Get jsIdent
*
@version $Revision: 1.11 $ $Date: 2000/06/18 20:14:13 $
*/
public
final class StandardManager implements Runnable {
@@ -351,7 +352,7 @@
* @exception IllegalStateException
if a new session cannot be
* instantiated for any reason
*/
-
public HttpSession getNewSession() {
+
public HttpSession getNewSession(String jsIdent) {
if ((maxActiveSessions
= 0)
(sessions.size() =
maxActiveSessions))
@@ -375,7 +376,7 @@
session.setValid(true);
session.setCreationTime(System.currentTimeMillis());
session.setMaxInactiveInterval(this.maxInactiveInterval);
- session.setId(SessionUtil.generateSessionId());
+ session.setId(SessionUtil.generateSessionId(jsIdent));
return (session);
}
Index:
tomcat/session/StandardSessionInterceptor.java
Re: Tomcat 4.0 -- JSP XML representation problems
Pierre Delisle wrote: I cannot really use the XML representation, because the jsp:cdata tag doesn't work with current Tomcat-4.0-devel. I get classCastExceptions if I try to use this tag. But you could still use ![CDATA[ ... ]] for your CDATA. jsp:cdata should be in tomcat-4.0 befroe the end of the week. ARG!!! I was using code like this: jsp:cdata![CDATA[ ... quoted stuff here... ]]/jsp:cdata and this resulted in ClassCastExceptions. But deleting the jsp:cdata tags and it worked! One problem remains: I cannot emit a well-formed XML document because there are leading blank lines. Consider this document: ?xml version="1.0" encoding="UTF-8"? jsp:root xmlns:jsp ="http://java.sun.com/jsp_1_2" ![CDATA[ ?xml version="1.0" encoding="UTF-8"? ]] /jsp:root The jsp:root tag is converted to a blank line. I get blank lines in my document before my (quoted) ?xml... declaration. Has anyone found a work-around to this? With XSLT, one is able to specify the output style (eg "xml" or "html") and you are able to specify the resulting declaration (eg. ?xml version="1.0"? ). Perhaps similiar functionality should be considered for the jsp:root tag. -- boyd - Boyd Waters [EMAIL PROTECTED] National Radio Astronomy Observatory http://www.nrao.edu PO Box 0 Socorro, NM 87801 505.835.7346 http://www.zocalo.net/~waters [EMAIL PROTECTED] - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 4.0 -- JSP XML representation problems
Boyd Waters wrote: [...] One problem remains: I cannot emit a well-formed XML document because there are leading blank lines. Consider this document: ?xml version="1.0" encoding="UTF-8"? jsp:root xmlns:jsp ="http://java.sun.com/jsp_1_2" ![CDATA[ ?xml version="1.0" encoding="UTF-8"? ]] /jsp:root The jsp:root tag is converted to a blank line. I get blank lines in my document before my (quoted) ?xml... declaration. Has anyone found a work-around to this? [...] It's a bit ugly, but this should work: ?xml version="1.0" encoding="UTF-8"?jsp:root xmlns:jsp ="http://java.sun.com/jsp_1_2"![CDATA[ ?xml version="1.0" encoding="UTF-8"? ]] /jsp:root In other words, place all elements upto an including the CDATA start tag on the first line. Since these elements are consumed by the JSP container, the blank lines you see in your version are caused by the line feed characters after each element. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
BugRat Report #394 has been filed.
Bug report #394 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com:/BugRatViewer/ShowReport/394 REPORT #394 Details. Project: Servlet API Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: serious Confidence: public Environment: Release: SERVLET_2_3_JSP_1_2 JVM Release: 1.3.0beta_refresh-b09 Operating System: Linux OS Release: RedHat 6.2 kernel 2.2.14-12 Platform: x86 Synopsis: NullPointerExceptions caused by javax.servlet.ServletRequestWrapper.getInputStream() Description: The method javax.servlet.ServletRequestWrapper.getInputStream() simply returns null, but the JavaDoc comments for that method say that it shouldn't. Here's what the JavaDoc comment says: "The default behavior of this method is to return getInputStream() on the wrapped request object." This can cause servlet containers to throw obscure NullPointerExceptions at times. Title: BugRat Report # 394 BugRat Report # 394 Project: Servlet API Release: SERVLET_2_3_JSP_1_2 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: serious Confidence: public Submitter: Jason Brittain ([EMAIL PROTECTED]) Date Submitted: Nov 15 2000, 07:00:26 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: NullPointerExceptions caused by javax.servlet.ServletRequestWrapper.getInputStream() Environment: (jvm, os, osrel, platform) 1.3.0beta_refresh-b09, Linux, RedHat 6.2 kernel 2.2.14-12, x86 Additional Environment Description: Report Description: The method javax.servlet.ServletRequestWrapper.getInputStream() simply returns null, but the JavaDoc comments for that method say that it shouldn't. Here's what the JavaDoc comment says: "The default behavior of this method is to return getInputStream() on the wrapped request object." This can cause servlet containers to throw obscure NullPointerExceptions at times. Workaround: null View this report online - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bug with Win98 -- tomcat
Jim, I got your Tomcat launcher solution to the Win98 Tomcat problem from the tomcat archive. I wanted to let you know it works great! I had tomcat running under jdk1.2.2. Then I did some work with j2ee, reinstalled tomcat under jdk1.3 and then somehow couldn't get tomcat to work again. It would start a new MS-Dos window and the new Dos window would flash and disappear. After trying many different combinations of bat setup files and MS-Dos memory settings, I found your entry in the archive (search on 'start tomcat') and tried your JustGo_v12.zip file. The JStart.exe and JStop.exe worked perfectly the first time! Thanks! Pat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 3.2 status -- no taglibs in jars
Brian Bucknam wrote: Craig says all the critical bugs are fixed, and it seems maybe they are. However, there is still a problem (see bug #215) in TagLibraryInfoImpl which makes it so that tag libraries cannot be packaged in .jar files. (3.2b7 (and 3.1) at least not on Windows, have not tested on *nix.) I marked this bug "serious" when I entered it because you can 'work around it' if you un-jar the tag library into WEB-INF/classes and rename the taglib.tld file, then refer to the .tld file from your JSP's. But if 3.2 is supposed to represent the JSP 1.1 spec, then it clearly states that packaging a tag library in a jar inside WEB-INF/lib is supposed to be a possibility. Maybe this is "critical"? This problem occurs because the jar file is being copied into the work directory. However, this should not be done (there is in fact a comment in the code saying "Take this stuff out when taglib changes are thoroughly tested".) I have commented out that code section and the test I ran worked fine. I'll commit the patch right now and I'd appreciate if you could run some exhaustive tests. -- Pierre On a separate topic, we're having some classloader problems where classes supposedly available in .jars in WEB-INF/lib come up as "NoClassDefFound" as supporting classes for some servlets and JSP pages. Moving these jars to jakarta-tomcat/lib solves the problem. I haven't had time to track down exactly where the problem is, but it seems wrong that the web-app classloader that loads the servlets JSP's seems to be ignoring the lib jars, or acting as if the classes in those jars came from a different loader. I probably should get better details before bringing this to the list, but I saw Rickard Öberg's mention of a getResource() problem... My $.02, Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 3.2 status -- no taglibs in jars
Pierre Delisle wrote: Brian Bucknam wrote: However, there is still a problem (see bug #215) in TagLibraryInfoImpl which makes it so that tag libraries cannot be packaged in .jar files. (3.2b7 (and 3.1) at least not on Windows, have not tested on *nix.) I marked this bug "serious" when I entered it because you can 'work around it' if you un-jar the tag library into WEB-INF/classes and rename the taglib.tld file, then refer to the .tld file from your JSP's. But if 3.2 is supposed to represent the JSP 1.1 spec, then it clearly states that packaging a tag library in a jar inside WEB-INF/lib is supposed to be a possibility. Maybe this is "critical"? This problem occurs because the jar file is being copied into the work directory. However, this should not be done (there is in fact a comment in the code saying "Take this stuff out when taglib changes are thoroughly tested".) I have commented out that code section and the test I ran worked fine. I'll commit the patch right now and I'd appreciate if you could run some exhaustive tests. I'd be glad to test this in my scenario and any others you suggest. I haven't tried simply commenting out or removing the code that says "Take this stuff out..." because that would remove the entire section devoted opening the jar and finding the .tld inside. Maybe I'm missing something, but this doesn't sound like the right fix. I agree that it seems unnecessary to copy the jar to the work directory, but the rest of that code (ZipEntry.getNextEntry() while != TLD) seems needed. Am I missing something? Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FW: lock
Sorry, typo in the Cc: -Original Message- From: Larry Isaacs To: 'Pierre Delisle ' Cc: '[EMAIL PROTECTED]' Sent: 11/15/00 9:55 PM Subject: RE: lock Hi Pierre, I saw the same thing a little after 5:00 PM when I tried a commit some changes to this directory. After about 5 minutes of this, I aborted and logged out of jakarta.apache.org. I have tried to commit two more times with the same result. I'm supprised to see my username on the "lock". I thought it was a "lock" that was more general, not something tagged to me. I'm not aware of anything intentional on my part that created this "lock". I have been using WinCVS 1.1b15/16 for a while with no problems. Any suggestions on how I might release this "lock" from my end? Otherwise, hope this can be fixed from the server side. Larry -Original Message- From: Pierre Delisle To: [EMAIL PROTECTED] Sent: 11/15/00 9:21 PM Subject: lock Larry, I cannot commit to tomcat_32. I've been getting this message for the last 5 minutes: . cvs server: [18:18:18] waiting for larryi's lock in /home/cvs/jakarta-tomcat/src /share/org/apache/jasper/compiler cvs server: [18:18:48] waiting for larryi's lock in /home/cvs/jakarta-tomcat/src /share/org/apache/jasper/compiler ... Any idea? -- Pierre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Patch for bug report #362 (and a patch for a logging error)
"Craig R. McClanahan" wrote: Serge Knystautas wrote: [snip] The way I got this to work was to overload the setter method to take both a String and an Object... this got it working through Jasper Servlet but not jspc. I don't know if that's a violation of the spec or the way to handle this issue. Yep, it is, and again this is made explicit in JSP 1.2 :-(. I've been agonizing over this days reading over the spec again and again and immersing myself in the bean API. First, I really don't think the spec intends to require attr='%="value"%' and in fact in JSP 1.2 it specifies how you write your tag to support attr="value". I endeavored to use the bean API as the JSP spec tells me to. After I finish my tag, I created a TagnameBeanInfo which returns an array of PropertyDescriptor objects defining my properties. Then I write a TagnamePropertynamePropertyEditor class and set this on the PropertyDescriptor for that property that is a java.lang.Object. My TagnamePropertynamePropertyEditor class overrides setAsText(String) which according to section 4.2 of the JSP 1.2 spec, should allow me to pass a String constant to this property. So my problem is... there's no way in Tomcat 3.2b7 to do attr="value" if your attr is an Object property. I can use Tomcat 3.1 and could use Tomcat 4.0 (assuming this part is implemented), but not Tomcat 3.2b7. The "rigor" was added to prevent you from passing a String constant directly to an Object property, but the way to support this through a PropertyEditor class is not added. I see this as an isolated but critical flaw in the implementation of the spec. As I see it, you can either relax the recent restriction made (by allowing a String to convert to an Object... my 2 line patch) or you can add support for tags with a PropertyEditor. I don't really want to hold up Tomcat 3.2, and since it doesn't really need to support JSP 1.2 just yet, I would suggest making it so that tags can pass a String constant directly to an Object property (which in my opinion complies with JSP 1.1, even though not JSP 1.2). Anyway, I hope this sheds some light on my plight, and maybe someone can decide on a remedy. I believe the patch to add support for PropertyEditors is non-trivial, otherwise I'd try to write it myself and submit. Maybe Eduardo can also shed light on this issue and how he envisions the spec migration happening. Anyway, seems that if spec compliance is an issue, we should have Tomcat 3.2 be uniform in both jspc and the Jasper Servlet. That is *definitely* true. Unfortunately, I'm not the person most versed with the JSP compiler. Pierre Delisle is, and he will also be back on Monday. I haven't had the chance to test this, as I've been spending my time trying to figure a way out for my tags rather than make sure they don't work. ;) Serge Knystautas Loki Technologies http://www.lokitech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
BugRat Report #388 was linked to Bug #52(apparently by:Nick Bauman)
BugRat Report #388 was linked to Bug #52 (logged in as:Nick Bauman) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
BugRat Bug #52 was closed (apparently by: Nick Bauman)
Bug #52 was closed by Person #0 Synopsis: GET header defaults to be iso-8859-1 encoded which breaks intl' forms passed by GET (logged in as: Nick Bauman) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Closing Bug Reports?
Hans, I closed it for you. What the heck, what is BugRat doing now? It's been much better since Nacho and I fixed it (ie, hasn't been wedging mysql and sending my system spinning with a load average of, 80.69!) Now mind you, I've submitted out SQL fixes to BugRat back to Tim Endres and he doesn't seem interested. I kind get the feeling that he doesn't believe that the SQL was even a problem, like it's our imagination. *sigh* On Tue, 14 Nov 2000, Hans Bergsten wrote: I tried to find a way to close the following Bug Report through the admin interface, but no matter which option I choose I only get the admin menu: Bug report #380 has just been filed. [...] Synopsis: Sessions don't work without cookies If someone else has more BugRat karma than I do, please close this one since I have committed a solution to the tomcat_32 branch. Hans -- Nicolaus Bauman Software Engineer Simplexity Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[BUG REPORTING] Jakarta BugRat has been upgraded
Hello Jakarta Horde, BugRat has been upgraded to use Tomcat 3.2b7 + Apache 1.3.14 + mod_jserv. I will be adding cvsweb.cgi and anon cvs for the bugrat sources as I have been "patching" (or rather just hacking the hell out of) BugRat to whip it into shape. These are the things I've added that you won't find in the original sources: 1) report linking and closing audit trail 2) basic authentication for administrators 3) query optimization for searches (thanks to Mr. Ortega) Soon: 4) Fixes for the "workarounds" and "how to reproduce" fields so they display properly If anyone is considering BugRat for their internal BugTracking system, I would caution them that it's pretty well unusable without 3 and unpleasant without 1 2 *** Please let me know via this email if you notice any problems *** -Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 3.2 status -- no taglibs in jars
On Wed, 15 Nov 2000, Brian Bucknam wrote: On a separate topic, we're having some classloader problems where classes supposedly available in .jars in WEB-INF/lib come up as "NoClassDefFound" as supporting classes for some servlets and JSP pages. Moving these jars to jakarta-tomcat/lib solves the problem. I haven't had time to track down exactly where the problem is, but it seems wrong that the web-app classloader that loads the servlets JSP's seems to be ignoring the lib jars, or acting as if the classes in those jars came from a different loader. I probably should get better details before bringing this to the list, but I saw Rickard Öberg's mention of a getResource() problem... My $.02, Brian Regarding Tomcat 3.1 I've been talking to people at work who also use Tomcat and we've all come to the conclusion that the classloader for each context mapping is: A) Strange B) Slow C) To be avoided In other words, when in doubt, we end up sticking the classes and jars in Tomcat's classpath, (even the WEB-INF/classes directory!) and giving up on servlet reloading. Hopefully Tomcat 3.2 isn't as bad.
code miss notice
Hi Tomcat-Dev..
I've found some miss code in Tomcat.
So I notice you miss point.
In code of "apache/tomcat/task/ApacheConfig.java",
pw.println("AddType test/jsp .jsp"); /*this is a miss
code, I think...'test' is replaced with 'text' */
--- pw.println("AddType
text/jsp .jsp");
Re: Closing Bug Reports?
Nick, Hans, I closed it for you. What the heck, what is BugRat doing now? It's been much better since Nacho and I fixed it (ie, hasn't been wedging mysql and sending my system spinning with a load average of, 80.69!) Now mind you, I've submitted out SQL fixes to BugRat back to Tim Endres and he doesn't seem interested. I kind get the feeling that he doesn't believe that the SQL was even a problem, like it's our imagination. *sigh* Thanks. I hope we can replace it with something else soon. Jon, what's the status of Scarab? Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com
Re: WWW-Authentication with Tomcat
You need to set up the web-app to require authentication. In the web.xml in the WEB-APP directory you need to add a security-constraint element and a login-config element. There are examples in the examples web-app. --Danno shahed wrote: How can I do a www-authentication with a jsp page ? I tried to set a header in the response of a page, and that bought up the popup uid/pwd window, but how do I get the values back ? Thanks Shahed - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
