cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 jk_service_apache2.c
mturk 2002/10/18 00:35:06
Modified:jk/native2/server/apache2 jk_service_apache2.c
Log:
Fix the bug 12699.
Use the table_add instead of table_set for multivalue headers.
Revision ChangesPath
1.30 +7 -4
jakarta-tomcat-connectors/jk/native2/server/apache2/jk_service_apache2.c
Index: jk_service_apache2.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/jk_service_apache2.c,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- jk_service_apache2.c 27 Sep 2002 13:14:09 - 1.29
+++ jk_service_apache2.c 18 Oct 2002 07:35:06 - 1.30
-163,9 +163,12
ap_update_mtime(r, ap_parseHTTPdate(val));
ap_set_last_modified(r);
apr_table_set(r-headers_out, name, val);
-} else {
-/* apr_table_add(r-headers_out, name, val); */
- apr_table_set(r-headers_out, name, val);
+} else {
+/* All other headers may have multiple values like
+ * Set-Cookie, so use the table_add to allow that.
+ */
+ apr_table_add(r-headers_out, name, val);
+/* apr_table_set(r-headers_out, name, val); */
}
}
#endif
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13733] - Unpack War files
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13733. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13733 Unpack War files [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-10-17 15:04 --- It is normal that Tomcat is case sensitive. At best, this is an Ant problem. Try to use another tool to generate a WAR. I'm worried that it worked with 4.1.8. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 12699] - Only one cookie sent back to Apache2 with mod_jk2 and Tomcat4.1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12699. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12699 Only one cookie sent back to Apache2 with mod_jk2 and Tomcat4.1 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-10-18 07:40 --- Fixed in the CVS. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5 CoyoteConnector.java
billbarker2002/10/17 22:58:53
Modified:coyote/src/java/org/apache/coyote/tomcat5
CoyoteConnector.java
Log:
Port from tomcat4, including Jon's suggested optimization.
Revision ChangesPath
1.3 +9 -5
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteConnector.java
Index: CoyoteConnector.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteConnector.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- CoyoteConnector.java 10 Oct 2002 09:07:33 - 1.2
+++ CoyoteConnector.java 18 Oct 2002 05:58:53 - 1.3
-661,7 +661,11
*/
public void setProxyName(String proxyName) {
-this.proxyName = proxyName;
+if(proxyName != null proxyName.length() 0) {
+this.proxyName = proxyName;
+} else {
+this.proxyName = null;
+}
}
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13726] - WAR files does not unpack/extract automatically
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13726. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13726 WAR files does not unpack/extract automatically --- Additional Comments From [EMAIL PROTECTED] 2002-10-18 06:48 --- Guys. but i have already set the autoDeploy to true and still the war file is not expanded.. why is this so? I have placed the war file in my directory. Whenever i restart tomcat it would extract it. Upon deploying a new verion on my project I am deleting the extracted folder of my project and replacing my project (war file) with a new updated one. Then i initiate this commmand to my browser(from the manager app) http://localhost:8080/manager/install?path=/samplewar=jar:file:/usr/local/tomcat/webapps/sample.war!/ In tomcat 4.0.4 whenever i install a war file in the manager app it always extracts my war but in 4.1.12 it does'nt. I'm on a production environment that restarting tomcat itself is not appropriate. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13392] - When tag pooling is enabled, release() is not called on tag instances
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13392. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13392 When tag pooling is enabled, release() is not called on tag instances [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-10-18 02:26 --- If other containers call release() in between re-uses of the same tag, those containers are broken -- they violate the tag handler instance lifecycle as described in the JSP specification. Misbehavior by other implementations is NOT a valid reason to make Tomcat broken as well. Please do not bother to reopen this bug again. Craig McClanahan J2EE Web Layer Architect -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 12549] - j_security_check is not handled correctly when authenticated
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12549. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12549 j_security_check is not handled correctly when authenticated --- Additional Comments From [EMAIL PROTECTED] 2002-10-18 02:22 --- This bug also occurs in Tomcat 4.1.12 on Windows 2000. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 11891] - JspC does not work for webapps
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11891.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11891
JspC does not work for webapps
--- Additional Comments From [EMAIL PROTECTED] 2002-10-18 06:53 ---
Greg,
Yes I had the problems with normal JSP compilation as well, and it was due to
an unchecked cast. Here is the change that resolves it:
JSPCompilationContext.java 145:
boolean isPAckageNeeded= false;
if ( options instanceof JspC )
{
isPAckageNeeded= ((JspC)options).isOutputDirSet();//if not -dd option
}
I can now precompile and also use standard JSP compilation.
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties
luehe 2002/10/17 15:56:02
Modified:jasper2/src/share/org/apache/jasper/compiler Validator.java
jasper2/src/share/org/apache/jasper/resources
messages.properties
Log:
Check array returned by TagExtraInfo.getVariableInfo() for non-emptiness instead of
just null
Revision ChangesPath
1.45 +6 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java
Index: Validator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java,v
retrieving revision 1.44
retrieving revision 1.45
diff -u -r1.44 -r1.45
--- Validator.java17 Oct 2002 21:38:56 - 1.44
+++ Validator.java17 Oct 2002 22:56:02 - 1.45
-796,7 +796,9
// has one or more variable subelements to have a TagExtraInfo
// class that returns a non-null object.
TagExtraInfo tei = tagInfo.getTagExtraInfo();
- if (tei != null tei.getVariableInfo(tagData) != null
+ if (tei != null
+ tei.getVariableInfo(tagData) != null
+ tei.getVariableInfo(tagData).length 0
tagInfo.getTagVariableInfos() != null
tagInfo.getTagVariableInfos().length 0) {
err.jspError(jsp.error.non_null_tei_and_var_subelems,
1.47 +2 -2
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties
Index: messages.properties
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties,v
retrieving revision 1.46
retrieving revision 1.47
diff -u -r1.46 -r1.47
--- messages.properties 12 Oct 2002 18:55:30 - 1.46
+++ messages.properties 17 Oct 2002 22:56:02 - 1.47
-132,7 +132,7
jsp.warning.unknown.element.in.attribute=Warning: Unknown element {0} in attribute
jsp.error.more.than.one.taglib=More than one taglib in the TLD: {0}
jsp.warning.teiclass.is.null=Could not load TagExtraInfo class {0}: {1}
-jsp.error.non_null_tei_and_var_subelems=Tag {0} has one or more variable
subelements and a TagExtraInfo class that returns a non-null object
+jsp.error.non_null_tei_and_var_subelems=Tag {0} has one or more variable
subelements and a TagExtraInfo class that returns one or more VariableInfo
jsp.error.parse.error.in.TLD=Parse Error in the tag library descriptor: {0}
jsp.error.unable.to.open.TLD=Unable to open the tag library descriptor: {0}
jsp.buffer.size.zero=Buffer size = 0
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Collector.java Dumper.java Generator.java ImplicitTagLibraryInfo.java JspDocumentParser.java JspUtil.java Mark.java Node.java Parser.java ScriptingVariabler.java TagFileProcessor.java TagLibraryInfoImpl.java Validator.java
luehe 2002/10/17 13:43:07
Modified:jasper2/src/share/org/apache/jasper/compiler Collector.java
Dumper.java Generator.java
ImplicitTagLibraryInfo.java JspDocumentParser.java
JspUtil.java Mark.java Node.java Parser.java
ScriptingVariabler.java TagFileProcessor.java
TagLibraryInfoImpl.java Validator.java
Log:
Reduced visibility of classes to package scope
Revision ChangesPath
1.6 +3 -3
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Collector.java
Index: Collector.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Collector.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- Collector.java4 Sep 2002 23:45:29 - 1.5
+++ Collector.java17 Oct 2002 20:43:06 - 1.6
-72,7 +72,7
* author Mark Roth
*/
-public class Collector {
+class Collector {
/**
* A visitor for collecting information on the page and the body of
1.3 +3 -3
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Dumper.java
Index: Dumper.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Dumper.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Dumper.java 16 Jul 2002 19:30:51 - 1.2
+++ Dumper.java 17 Oct 2002 20:43:06 - 1.3
-64,7 +64,7
import org.xml.sax.Attributes;
import org.apache.jasper.JasperException;
-public class Dumper {
+class Dumper {
static class DumpVisitor extends Node.Visitor {
private int indent = 0;
1.110 +4 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.109
retrieving revision 1.110
diff -u -r1.109 -r1.110
--- Generator.java9 Oct 2002 17:41:13 - 1.109
+++ Generator.java17 Oct 2002 20:43:06 - 1.110
-88,7 +88,7
* author Denis Benoit
*/
-public class Generator {
+class Generator {
private static final Class[] OBJECT_CLASS = { Object.class};
private ServletWriter out;
1.12 +4 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ImplicitTagLibraryInfo.java
Index: ImplicitTagLibraryInfo.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ImplicitTagLibraryInfo.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- ImplicitTagLibraryInfo.java 16 Oct 2002 00:03:10 - 1.11
+++ ImplicitTagLibraryInfo.java 17 Oct 2002 20:43:06 - 1.12
-74,7 +74,7
*
* author Jan Luehe
*/
-public class ImplicitTagLibraryInfo extends TagLibraryInfo {
+class ImplicitTagLibraryInfo extends TagLibraryInfo {
private static final String WEB_INF_TAGS = /WEB-INF/tags;
private static final String TAG_FILE_SUFFIX = .tag;
1.19 +4 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspDocumentParser.java
Index: JspDocumentParser.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspDocumentParser.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- JspDocumentParser.java29 Aug 2002 23:27:36 - 1.18
+++ JspDocumentParser.java17 Oct 2002 20:43:06 - 1.19
-80,7 +80,7
* author Jan Luehe
*/
-public class JspDocumentParser extends DefaultHandler
+class JspDocumentParser extends DefaultHandler
implements LexicalHandler, TagConstants {
private static final String XMLNS = xmlns:;
1.20 +4 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspUtil.java
Index: JspUtil.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspUtil.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- JspUtil.java 15 Oct 2002 22:34:46 - 1.19
+++ JspUtil.java 17 Oct 2002 20:43:06 - 1.20
-97,7 +97,7
* author Shawn Bayern
* author Mark Roth
*/
DO NOT REPLY [Bug 12699] - Only one cookie sent back to Apache2 with mod_jk2 and Tomcat4.1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12699.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12699
Only one cookie sent back to Apache2 with mod_jk2 and Tomcat4.1
--- Additional Comments From [EMAIL PROTECTED] 2002-10-17 15:35
---
Delighted to. I'm appending servlet code (a modified version of
HelloWorldExample), the HTTP request I submit via telnet to port 80 on my
machine, and the responses from apache with JK1 and apache with JK2.
---servlet code-
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class HelloWorldExample extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
response.setContentType(text/html);
response.addCookie(new Cookie(fee, fie));
response.addCookie(new Cookie(foe, fum));
response.addCookie(new Cookie(foo, bar));
PrintWriter out = response.getWriter();
out.println(html);
out.println(head);
String title = Hello, World!;
out.println(title + title + /title);
out.println(/head);
out.println(body bgcolor=\white\);
out.println(h1 + title + /h1);
out.println(/body);
out.println(/html);
}
}
-HTTP REQUEST---
GET /examples/servlet/HelloWorldExample HTTP/1.1
Host: bn.mypoints.com
Connection: close
-HTTP RESPONSE, JK1-
HTTP/1.1 200 OK
Date: Thu, 17 Oct 2002 15:27:37 GMT
Server: Apache/2.0.43 (Unix) mod_ssl/2.0.43 OpenSSL/0.9.6g mod_jk/1.2.0
Set-Cookie: fee=fie
Set-Cookie: foe=fum
Set-Cookie: foo=bar
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=ISO-8859-1
71
html
head
titleHello, World!/title
/head
body bgcolor=white
h1Hello, World!/h1
/body
/html
0
HTTP RESPONSE, JK2
HTTP/1.1 200
Date: Thu, 17 Oct 2002 15:24:32 GMT
Server: Apache/2.0.43 (Unix) mod_ssl/2.0.43 OpenSSL/0.9.6g mod_jk2/2.0.0
Content-Type: text/html; charset=ISO-8859-1
Set-Cookie: foo=bar
Content-Length: 113
Connection: close
html
head
titleHello, World!/title
/head
body bgcolor=white
h1Hello, World!/h1
/body
/html
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13755] New: - Coyote connector cannot run from read-only directory (security hole)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13755. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13755 Coyote connector cannot run from read-only directory (security hole) Summary: Coyote connector cannot run from read-only directory (security hole) Product: Tomcat 4 Version: 4.1.12 Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Connector:Coyote HTTP/1.1 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The Coyote connector cannot run from read-only media (whether due to permissions, or if carried around on a CD or if running from a classroom setting.) This is because the connector attempts to create tomcat-users.xml.new in the conf directory. If it cannot write this file, tomcat crashes on startup. For security reasons, the conf directory must not be writable by anyone except root. Tomcat 4.0 did not have this problem; it could be carried around on a CD and allow development and testing on any computer you happened to sit down on without installing on the computer. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: jakarta-tomcat-connectors/jk will no longer build
Costin, Costin Manolache wrote: No, the tomcat4 package shouldn't compile with tomcat5. I think we need a way to distinguish tomcat4 from tomcat5 in the conditions. Or a flag that is set by the tomcat5 build ( probably better ). I added a org.apache.ajp.tomcat5 package in jakarta-tomcat-connectors/jk. This package contains no classes as the org.apache.ajp.tomcat4 classes will need to be ported so that they do not use the HttpRequestBase class. Also, I made jakarta-tomcat-connectors/jk/build.xml handle concurrent building of the tomcat4 and tomcat5 packages when both Tomcat 4.x and Tomcat 5 are present. This was what was causing my build to break: build.xml was automatically detecting my Tomcat 4 build even when I had catalina.home set to my Tomcat 5 build. So, everything now builds fine except that the Ajp13 connector will not work with Tomcat 5 since there are no tomcat5 classes at this time. Patrick -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13723] - Bootstrap: Class loader creation threw exception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13723. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13723 Bootstrap: Class loader creation threw exception --- Additional Comments From [EMAIL PROTECTED] 2002-10-17 18:10 --- I've seen this on Windows 98 with JDK 1.2.2, and it may be the same with other Windows versions and this old JDK. I noticed that it can be fixed by turning off the JIT, e.g. by setting JAVA_COMPILER=NONE. Looks like a JIT bug to me. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13755] - Coyote connector cannot run from read-only directory (security hole)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13755. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13755 Coyote connector cannot run from read-only directory (security hole) [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-10-18 06:22 --- My mistake. It was the JNDI connector that caused the unable to rename problem. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
[5]: ant native for Connectors fails:
Trying to build Jakarta Tomcat Connectors from 5.0.0 source: In jakarta-tomcat-connectors/jk Ant native complains about cc not being found, on Solaris 8, I have gcc in /em/opt/bin/gcc. I have no idea how to tell ant that it should use gcc or /em/opt/bin/gcc instead of cc, and no idea how to configure the args to libtool that it should gcc instead of cc. I'd like to figure this out, but need assistance. Assuming this isn't a known bug, is this something that should be reported as a bug using bugzilla? Paul -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Possible mod_jk patch with ap_get_server_name
[EMAIL PROTECTED] wrote: Hi, I am a new subscriber and have a potential patch to mod_jk. It uses the apache api to get the s-servername value. This has a benefit in that is pays attention to the UseCanonicalName setting within apache. So if a site has lots of ServerAlias entries only 1 entry in server.xml is needed if UseCanonicalName is on for that VirtualHost. The patch was against the jakarta-tomcat-connectors-4.1.12 source I downloaded and I have tested it with Apache/1.3.26 and Tomcat 3.2.3 in a virtual hosted situation with some vhosts enabled via UseCanonicalName and some not. Comments welcome, it seems to work fine. --- mod_jk.c.orig Thu Oct 17 18:06:21 2002 +++ mod_jk.cThu Oct 17 18:07:06 2002 @@ -466,7 +466,7 @@ s-remote_host = NULL_FOR_EMPTY(s-remote_host); s-remote_addr = NULL_FOR_EMPTY(r-connection-remote_ip); -s-server_name = (char *)(r-hostname ? r-hostname : r-server- server_hostname); +s-server_name = ap_get_server_name(r); s-server_port = htons( r-connection-local_addr.sin_port ); s-server_software = (char *)ap_get_server_version(); It's seems correct. JF, Mladen what do you think ? -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13741] New: - TagSupport not release all attributes
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13741.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13741
TagSupport not release all attributes
Summary: TagSupport not release all attributes
Product: Tomcat 4
Version: Nightly Build
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Servlet JSP API
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
At the servlet 4.0 Implementation at javax.servlet.jsp.tagext.TagSupport
is a bug:
The release method not release all attibutes:
/**
* Release state.
*
* @see Tag#release()
*/
public void release() {
parent = null;
}
better is
public void release() {
parent = null;
}
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Possible mod_jk patch with ap_get_server_name
Hi, I am a new subscriber and have a potential patch to mod_jk. It uses the apache api to get the s-servername value. This has a benefit in that is pays attention to the UseCanonicalName setting within apache. So if a site has lots of ServerAlias entries only 1 entry in server.xml is needed if UseCanonicalName is on for that VirtualHost. The patch was against the jakarta-tomcat-connectors-4.1.12 source I downloaded and I have tested it with Apache/1.3.26 and Tomcat 3.2.3 in a virtual hosted situation with some vhosts enabled via UseCanonicalName and some not. Comments welcome, it seems to work fine. --- mod_jk.c.orig Thu Oct 17 18:06:21 2002 +++ mod_jk.cThu Oct 17 18:07:06 2002 -466,7 +466,7 s-remote_host = NULL_FOR_EMPTY(s-remote_host); s-remote_addr = NULL_FOR_EMPTY(r-connection-remote_ip); -s-server_name = (char *)(r-hostname ? r-hostname : r-server- server_hostname); +s-server_name = ap_get_server_name(r); s-server_port = htons( r-connection-local_addr.sin_port ); s-server_software = (char *)ap_get_server_version(); -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [5]: ant native for Connectors fails:
Brzezinski, Paul J wrote: Trying to build Jakarta Tomcat Connectors from 5.0.0 source: In jakarta-tomcat-connectors/jk Ant native complains about cc not being found, on Solaris 8, I have gcc in /em/opt/bin/gcc. I have no idea how to tell ant that it should use gcc or /em/opt/bin/gcc instead of cc, and no idea how to configure the args to libtool that it should gcc instead of cc. I'd like to figure this out, but need assistance. Assuming this isn't a known bug, is this something that should be reported as a bug using bugzilla? You could put /em/opt/bin/ in PATH before compiling ? export PATH=/em/opt/bin:$PATH Or set the ant project property : buid.native.cc=/em/opt/bin/gcc -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Bugzilla bug # 11501...
I'm running into the problem outlined in bug # 11501. After searching quite a bit, I'm still confused as to how this symlink issue can be worked around. I'm trying to upgrade to 4.1.12, but this error has been a big problem. Any assistance would be greatly appreciated... Is the allowLinking option supposed to enable me to turn on symlinking, thus resolving this issue of having jars/tld's outside of the webapps dir? If so, where specifically is the appropriate place to add this option? Thanks in advance, - Matt -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13731] New: - Final request, response, session and other variables.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13731. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13731 Final request, response, session and other variables. Summary: Final request, response, session and other variables. Product: Tomcat 4 Version: 4.1.12 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Provide a capability to declare request, response, session and other variables in jspService function as final. As tunable feature, just like others, in tomcat`s web.xml file. Why need this feature? To use request, response, session variables in anonymous implementations of classes. For example - declaration of iterator through elements, which includes some other JSP file (statically). And usage of this iterator in other JSP file. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13658] - javax.servlet.request.key_size attribute isn't being set
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13658. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13658 javax.servlet.request.key_size attribute isn't being set [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2002-10-18 05:41 --- Having tested against JVM 1.4.1 (Windows), I'm afraid that it still works for me. I'll test against Solaris at some point, but I don't know how soon it will be that I can find the machine and time. I don't know why the 4.1 nightlies were stopped (and don't have enough permissions to set them up again). There have been several changes to the SSL handling since 4.1.12, but AFAIK, none of them should have affected key_size (or, cipher_suite, that key_size depends on). You can pick up the latest jar from the gump build, http://gump.covalent.net/jars/latest/jakarta-tomcat-connectors/tomcat- util.jar that has all of the SSL specific stuff for the Coyote Connector. Just replace the one on $CATALINA_HOME/server/lib. Feel free to re-open with more information. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13723] - Bootstrap: Class loader creation threw exception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13723. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13723 Bootstrap: Class loader creation threw exception [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED --- Additional Comments From [EMAIL PROTECTED] 2002-10-18 05:43 --- Thanks to Hans Bergsten, I set an envirionmental variable JAVA_COMPILER=NONE and the bug is fixed. Thanks once again. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: Possible mod_jk patch with ap_get_server_name
-Original Message- From: Henri Gomez +s-server_name = ap_get_server_name(r); s-server_port = htons( r-connection-local_addr.sin_port ); s-server_software = (char *)ap_get_server_version(); It's seems correct. JF, Mladen what do you think ? Beter use the following: s-server_name = ap_get_server_name(r); s-server_port = ap_get_server_port(r); That's how it's done on JK2. MT. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
WHY DOES TOMCAT SUSPEND ITSELF?
Hello everybody! I have Tomcat 4.x as Servlet Container and I have seen that sometimes the following strange thing happens When Tomcat doesn't receive requests for a period of time (that can take minutes or hours) it suspends itself and I must restart the service manually because Tomcat doesn't answer to the users' requests any more. In fact when this happens and then a user tries to connect to Tomcat he waits for an answer forever without success until the connection is closed by the Web Browser because it is timed out. Is there some setting in Tomcat to avois this? Has someone already had such problem? If yes, how did he solve it? I hope someone can help me Thanks in advance. Luca
Re: Vote results + Security Audit redirection
[reposting from my subscribed account] For what it's worth, I'm not disagreeing that there needs to be another list. Clearly, really serious security issues should at least be delayed from being made public. However, I think there needs to be a bit more paranoia about how this list manifests itself. Any behind closed doors discussions have the potential for alienating the non-committer community. Determining what conversations are appropriate for this other list is a very slippery slope. It's already been proposed that votes for new committers be discussed there first. What's next? And if the other list starts being used for determining what should be discussed on the other list, it's all over. Sort of like the U.S. congress being in charge of their own pay raises. As a non-committer but long-time subscriber to this list, my opinion is that _all_ messages on the other list must absolutely show up here eventually, at some delay. Otherwise, there is no longer any transparency. (This is also the biggest reason it's better than CCed e-mails; because the messages will always be public at some point.) Anyway, just my non-binding $0.02, -Paul Ignacio J. Ortega wrote: From: Paul Speed [mailto:pspeed;progeeks.com] Sent: Thursday, October 17, 2002 4:15 PM The nice thing about your current way of dicussing security issues (CC e-mail threads) is that it's a real pain in the butt. In other words, likely only to be used in the cases of necessity. Not really, CC'ed threads are easy to manage simply reply to all and things goes smoothly, the problem the new mail list tries to solve, is much more simple, Are those how can fix and are interested in the problem, informed quickly? are those interested not forgotten in some part of the eamil theread? are part of the thread more private than intended only because some people unadvertely forgotten some other fellow email in the CC?.. all of that can be alleviated if not solved simply by using a closed maillist.. Fixes are ever public, and CVs comments are more than sufficient to see the problem and the fix being done.. so the open end of all threads in the new list is guaranteed now.. Saludos, Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Vote results + Security Audit redirection
[reposting from my subscribed account] For what it's worth, I'm not disagreeing that there needs to be another list. Clearly, really serious security issues should at least be delayed from being made public. However, I think there needs to be a bit more paranoia about how this list manifests itself. Any behind closed doors discussions have the potential for alienating the non-committer community. Determining what conversations are appropriate for this other list is a very slippery slope. It's already been proposed that votes for new committers be discussed there first. What's next? And if the other list starts being used for determining what should be discussed on the other list, it's all over. Sort of like the U.S. congress being in charge of their own pay raises. As a non-committer but long-time subscriber to this list, my opinion is that _all_ messages on the other list must absolutely show up here eventually, at some delay. Otherwise, there is no longer any transparency. (This is also the biggest reason it's better than CCed e-mails; because the messages will always be public at some point.) Anyway, just my non-binding $0.02, -Paul Ignacio J. Ortega wrote: From: Paul Speed [mailto:pspeed;progeeks.com] Sent: Thursday, October 17, 2002 4:15 PM The nice thing about your current way of dicussing security issues (CC e-mail threads) is that it's a real pain in the butt. In other words, likely only to be used in the cases of necessity. Not really, CC'ed threads are easy to manage simply reply to all and things goes smoothly, the problem the new mail list tries to solve, is much more simple, Are those how can fix and are interested in the problem, informed quickly? are those interested not forgotten in some part of the eamil theread? are part of the thread more private than intended only because some people unadvertely forgotten some other fellow email in the CC?.. all of that can be alleviated if not solved simply by using a closed maillist.. Fixes are ever public, and CVs comments are more than sufficient to see the problem and the fix being done.. so the open end of all threads in the new list is guaranteed now.. Saludos, Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Bug 13736
Bill Barker wrote:
I don't remember anything like that for 3.3.x (and nothing even close is
open in BZ). But, then again, I don't imagine that very many people
try and
use the Http10Connector in production, and Coyote is only available in the
nightly for 3.3 until 3.3.2 comes out.
o.a.t.u.net.PoolTcpEndpoint won't close the ServerSocket itself without
shutting down. It looks like the root cause is from the JVM, nio, O/S, or
some other place we can't see.
(forwarding to tomcat-dev)
Ok, I looked at it more, and the TCP endpoint code considers an
exception during accept a normal event:
From PoolTcpEndpoint:
try {
if (running) {
accepted = factory.acceptSocket(serverSocket);
catch (SocketException e) {
// TCP stacks can throw SocketExceptions when the client
// disconnects. We don't want this to shut down the
// endpoint, so ignore it. Is there a more robust
// solution? Should we compare the message string to
// Connection reset by peer?
// socket exceptions just after closing endpoint (when
// running=false) aren't even logged
if (running != false) {
String msg = sm.getString(endpoint.err.nonfatal,
serverSocket, e);
log(msg, e, Log.INFORMATION);
}
}
OTOH, I don't think this should be the case, and I think we should
stop/start the server socket in that particular case, as was done in the
old HTTP connector:
try {
socket = serverSocket.accept();
} catch (IOException e) {
try {
// If reopening fails, exit
synchronized (threadSync) {
if (started !stopped)
log(accept error: , e);
if (!stopped) {
serverSocket.close();
serverSocket = open();
}
}
The root of the problem could be a defiency in the JVM's network code,
but IMO this shouldn't kill the connector.
Remy
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Vote results + Security Audit redirection
Sorry about the double post. It looked like the other one went out with the original non-subscriber address. -Paul Paul Speed wrote: [reposting from my subscribed account] [snip] -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java Node.java Parser.java TagLibraryInfoImpl.java Validator.java
luehe 2002/10/17 14:38:56
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Node.java Parser.java TagLibraryInfoImpl.java
Validator.java
Log:
Check for null before enumerating over array returned by TagInfo.getAttributes() and
TagInfo.getTagVariableInfos() (see Bugzilla 13619).
Revision ChangesPath
1.111 +5 -8
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.110
retrieving revision 1.111
diff -u -r1.110 -r1.111
--- Generator.java17 Oct 2002 20:43:06 - 1.110
+++ Generator.java17 Oct 2002 21:38:56 - 1.111
-2109,9 +2109,6
String tagHandlerVar,
String tagEvalVar) {
- VariableInfo[] varInfos = n.getVariableInfos();
- TagVariableInfo[] tagVarInfos = n.getTagVariableInfos();
-
if (n.getBody() != null) {
if (n.implementsIterationTag()) {
out.printin(int evalDoAfterBody = );
-3081,8 +3078,8
out.printil( // Sync up variables with caller's page context: );
TagVariableInfo[] tagVariableInfo = tagInfo.getTagVariableInfos();
-
-for( int i = 0; i tagVariableInfo.length; i++ ) {
+for( int i = 0; tagVariableInfo != null
+ i tagVariableInfo.length; i++ ) {
// XXX - Spec bug: Note, we don't know the value of
// this attribute at translation time, because we're defining
// the tag, and we don't know how page authors will call it.
1.35 +4 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java
Index: Node.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- Node.java 17 Oct 2002 20:43:06 - 1.34
+++ Node.java 17 Oct 2002 21:38:56 - 1.35
-1183,7 +1183,7
boolean result = false;
TagAttributeInfo[] attributes = tagInfo.getAttributes();
- for (int i = 0; i attributes.length; i++) {
+ for (int i = 0; attributes != null i attributes.length; i++) {
if (attributes[i].getName().equals(name)
attributes[i].isFragment()) {
result = true;
1.35 +4 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java
Index: Parser.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- Parser.java 17 Oct 2002 20:43:06 - 1.34
+++ Parser.java 17 Oct 2002 21:38:56 - 1.35
-1718,7 +1718,7
if (n instanceof Node.CustomTag) {
TagInfo tagInfo = ((Node.CustomTag)n).getTagInfo();
TagAttributeInfo[] tldAttrs = tagInfo.getAttributes();
- for (int i=0; itldAttrs.length; i++) {
+ for (int i=0; tldAttrs != null itldAttrs.length; i++) {
if (name.equals(tldAttrs[i].getName())) {
if (tldAttrs[i].isFragment()) {
return TagInfo.BODY_CONTENT_SCRIPTLESS;
1.20 +15 -10
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java
Index: TagLibraryInfoImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- TagLibraryInfoImpl.java 17 Oct 2002 20:43:06 - 1.19
+++ TagLibraryInfoImpl.java 17 Oct 2002 21:38:56 - 1.20
-372,13 +372,18
);
}
}
- TagAttributeInfo[] tagAttributeInfo
-= new TagAttributeInfo[attributeVector.size()];
- attributeVector.copyInto(tagAttributeInfo);
- TagVariableInfo[] tagVariableInfos
-= new TagVariableInfo[variableVector.size()];
- variableVector.copyInto(tagVariableInfos);
+ TagAttributeInfo[] tagAttributeInfo = null;
+ if (attributeVector.size() 0) {
+tagAttributeInfo = new TagAttributeInfo[attributeVector.size()];
+
DO NOT REPLY [Bug 13742] New: - TagSupport not release all attributes
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13742.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13742
TagSupport not release all attributes
Summary: TagSupport not release all attributes
Product: Tomcat 4
Version: Nightly Build
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Servlet JSP API
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
At the servlet 4.0 Implementation at javax.servlet.jsp.tagext.TagSupport
is a bug:
The release method not release all attibutes:
/**
* Release state.
*
* @see Tag#release()
*/
public void release() {
parent = null;
}
better is
public void release() {
parent = null;
id = null ;
values = null ;
pageContext = null ;
}
I have trouble with this implementation at Tag Pooling!
}
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13726] - WAR files does not unpack/extract automatically
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13726. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13726 WAR files does not unpack/extract automatically --- Additional Comments From [EMAIL PROTECTED] 2002-10-18 08:54 --- Here are the logs upon installing the said war file. 2002-10-18 14:41:37 HTMLManager: list: Listing contexts for virtual host 'localhost' 2002-10-18 14:42:17 Manager: install: Installing web application at '/sample' from 'jar:file:/usr/local/tomcat/webapps/sample.war!/' 2002-10-18 14:42:17 StandardHost[localhost]: Installing web application at context path /sample from URL jar:file:/usr/local/tomcat/webapps/sample.war!/ 2002-10-18 14:42:18 WebappLoader[/sample]: Deploying class repositories to work directory /var/jakarta-tomcat- 4.1.12.TEST/work/Standalone/localhost/sample 2002-10-18 14:42:18 ContextConfig[/sample]: Missing application web.xml, using defaults only 2002-10-18 14:42:18 StandardManager[/sample]: Seeding random number generator class java.security.SecureRandom 2002-10-18 14:42:18 StandardManager[/sample]: Seeding of random number generator has been completed 2002-10-18 14:42:18 StandardWrapper[/sample:default]: Loading container servlet default 2002-10-18 14:42:18 StandardWrapper[/sample:invoker]: Loading container servlet invoker -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-5 build.xml
patrickl2002/10/17 11:20:29
Modified:.build.xml
Log:
Adjust properties for building jakarta-tomcat-connectors/jk
Revision ChangesPath
1.47 +1 -2 jakarta-tomcat-5/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
retrieving revision 1.46
retrieving revision 1.47
diff -u -r1.46 -r1.47
--- build.xml 17 Oct 2002 03:00:03 - 1.46
+++ build.xml 17 Oct 2002 18:20:28 - 1.47
-144,8 +144,7
echo== Building: tomcat-jk /echo
ant dir=${jtc.home}/jk target=build-main
- property name=tomcat41.home value=${tomcat.build}/
- property name=catalina.home value=${tomcat.build}/
+ property name=tomcat5.home value=${catalina.build}/
property name=commons-logging.jar value=${commons-logging.jar}/
property name=jmx.jar value=${jmx.jar}/
/ant
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Vote results + Security Audit redirection
For what it's worth, I'm not disagreeing that there needs to be another list. Clearly, really serious security issues should at least be delayed from being made public. However, I think there needs to be a bit more paranoia about how this list manifests itself. Any behind closed doors discussions have the potential for alienating the non-committer community. Determining what conversations are appropriate for this other list is a very slippery slope. It's already been proposed that votes for new committers be discussed there first. What's next? And if the other list starts being used for determining what should be discussed on the other list, it's all over. Sort of like the U.S. congress being in charge of their own pay raises. As a commiter I voted +1 if the discussions on the list where ONLY about security and not features and others devel related subjects. It shouldn't be a 'behind closed doors' discussion area. As a non-committer but long-time subscriber to this list, my opinion is that _all_ messages on the other list must absolutely show up here eventually, at some delay. Otherwise, there is no longer any transparency. (This is also the biggest reason it's better than CCed e-mails; because the messages will always be public at some point.) Since the discussion will be about security, we could send a digest in the CVS fixes as soon as the thread has been closed and problems fixed. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13736] - Socket closed unexpectedly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13736. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13736 Socket closed unexpectedly [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||REMIND --- Additional Comments From [EMAIL PROTECTED] 2002-10-17 16:44 --- Since you are the first one to report this, you'll have to do some debugging work if you want it fixed. It looks like problems that were reported with TC 3.3.x, and that were never actually reproduceable (ie, which look more like VM problems than something else). -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-connectors/naming/src/org/apache/naming/core BaseContext.java
costin 2002/10/17 09:44:14
Added: naming/src/org/apache/naming/core BaseContext.java
Log:
Moved the context stuff in a separate class.
This will allow creation of both simple contexts and dir contexts
( by extending BaseContext/BaseDirContext )
Revision ChangesPath
1.1
jakarta-tomcat-connectors/naming/src/org/apache/naming/core/BaseContext.java
Index: BaseContext.java
===
/*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Tomcat, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
* [Additional notices, if required by prior licensing conditions]
*
*/
package org.apache.naming.core;
import java.util.*;
import javax.naming.*;
import javax.naming.directory.DirContext;
import javax.naming.directory.Attributes;
import javax.naming.directory.Attribute;
import javax.naming.directory.ModificationItem;
import javax.naming.directory.SearchControls;
import org.apache.tomcat.util.res.StringManager;
// Based on a merge of various catalina naming contexts
// Name is used - it provide better oportunities for reuse and optimizations
/**
* Base Context implementation. Use it if the source doesn't support attributes.
*
* Implements all JNDI methods with reasonable defaults or UnsuportedOperation.
*
* IMPORTANT: all contexts should use setters/getters for configuration, instead
* of the Hashtable. The default constructor will use introspection to configure
* and may provide ( via a hook ? ) JMX management on all contexts.
*
* All methods use Name variant. They should expect an arbitrary implementation, but
* it's recommended to check if ServerName is used - and take advantage of the
* specific features ( MessageBytes, etc ).
*
* @author Remy Maucherat
* @author Costin Manolache
*/
public class BaseContext extends BaseNaming implements Context {
public BaseContext() {
super();
}
public BaseContext(Hashtable env) {
super(env);
}
// Context impl
/**
* Retrieves the named object. If name is empty, returns a new instance
* of this context (which represents the same naming context as this
DO NOT REPLY [Bug 13741] - TagSupport not release all attributes
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13741. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13741 TagSupport not release all attributes [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-10-17 16:55 --- *** This bug has been marked as a duplicate of 13392 *** -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-connectors/naming/src/org/apache/naming/core BaseNaming.java
costin 2002/10/17 09:47:14 Added: naming/src/org/apache/naming/core BaseNaming.java Log: Moved the base behavior and the methods that someone should override in the base class. More changes are needed to further simplify the task of creating new contexts. Added the first dep on tomcat-util ( we'll also use MessageBytes ), IntrospectionUtils will be used to push the Hashtable into setters ( so that our contexts will fill more like ant tasks ). Some more attemts to document it :-) Revision ChangesPath 1.1 jakarta-tomcat-connectors/naming/src/org/apache/naming/core/BaseNaming.java Index: BaseNaming.java === /* * * * The Apache Software License, Version 1.1 * * Copyright (c) 1999 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. The end-user documentation included with the redistribution, if *any, must include the following acknowlegement: * This product includes software developed by the *Apache Software Foundation (http://www.apache.org/). *Alternately, this acknowlegement may appear in the software itself, *if and wherever such third-party acknowlegements normally appear. * * 4. The names The Jakarta Project, Tomcat, and Apache Software *Foundation must not be used to endorse or promote products derived *from this software without prior written permission. For written *permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache *nor may Apache appear in their names without prior written *permission of the Apache Group. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * * This software consists of voluntary contributions made by many * individuals on behalf of the Apache Software Foundation. For more * information on the Apache Software Foundation, please see * http://www.apache.org/. * * [Additional notices, if required by prior licensing conditions] * */ package org.apache.naming.core; import java.util.*; import javax.naming.*; import javax.naming.directory.DirContext; import javax.naming.directory.Attributes; import javax.naming.directory.Attribute; import javax.naming.directory.ModificationItem; import javax.naming.directory.SearchControls; import org.apache.tomcat.util.res.StringManager; // Based on a merge of various catalina naming contexts // Name is used - it provide better oportunities for reuse and optimizations /** * This is the base class for our naming operations, for easy reading. * * pCreating a new context: * ul * liCreate a new class, extending BaseContext or BaseDirContext ( second * if you want to support attributes ). * liAdd setters for configuration. The setters will be called autmatically, * like in ant, from the initial env settings. * liOverride methods that are defined in BaseNaming. Default behavior * is provided for all. * liIf performance is a concern or have special behavior - override Context and * DirContext methods. That shouldn't be needed in most cases. * /ul * * This class is designed to minimize the ammount of code that is required to * create a new context. The usual DirContext interface has way too many methods, * so implementation requires a lot of typing. * * Our contexts are
DO NOT REPLY [Bug 13499] - Jasper throws an exception on an immediate pageContext.forward()
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13499. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13499 Jasper throws an exception on an immediate pageContext.forward() --- Additional Comments From [EMAIL PROTECTED] 2002-10-17 19:00 --- Can I prod someone into taking a look at this? I realize this is a low-importance bug to most folks, but it seems a simple change. Following the code path in JspWriterImpl.clear() is simple -- the only actual call is to ensureOpen(), which will throw an exception if the stream has been closed. This is a legitimate check even in the case of a null buffer. As I said in my previous comment, the check and exception I removed don't seem to do anything useful. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13392] - When tag pooling is enabled, release() is not called on tag instances
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13392. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13392 When tag pooling is enabled, release() is not called on tag instances --- Additional Comments From [EMAIL PROTECTED] 2002-10-18 09:13 --- OK! The Tomcat handling is correct but: a) at second TagHandler call at same page can changed the sematic with tag pooling is on. Strange! b) the class javax.servlet.jsp.tagext.TagSupport must clear all instance variable at release() called (s. my bug report 13742) -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13741] - TagSupport not release all attributes
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13741. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13741 TagSupport not release all attributes --- Additional Comments From [EMAIL PROTECTED] 2002-10-17 15:52 --- PLease see complete description at Bug 13741! sorry! -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13392] - When tag pooling is enabled, release() is not called on tag instances
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13392. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13392 When tag pooling is enabled, release() is not called on tag instances [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2002-10-18 02:09 --- I would think that this is certainly a bug: 1. judging by the number of duplicate bugs reports targeting it. 2. The behaviour is a gotcha for developers. 3. Other major appservers are handling the behaviour as expected. 4. Why should there be any differences in behaviour when tag pooling is turned on or off. Developers should be transparent to it. System Admin perhaps will be more interested, since it is system-tuning related. 5. It is normal to save tag attribute values in tag instance variables. If release() is not called, there is no way to reset them right. I hope no one is going to suggest saving the tag attribute value in the request's attribute, if so where should the code to remove these attributes be? in release()??? Maucherat, if this is a bug for the Jasper, could you just forward it to the person in charge? Or maybe we should clarify this issue with SUN or the tomcat community at large regarding http://jakarta.apache.org/taglibs/guidelines.html thanks. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13742] - TagSupport not release all attributes
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13742. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13742 TagSupport not release all attributes [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-10-17 16:45 --- Do not file duplicates (your first report is already a duplicate). *** This bug has been marked as a duplicate of 13741 *** -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-connectors/naming/src/org/apache/naming/core BaseDirContext.java
costin 2002/10/17 09:45:14
Modified:naming/src/org/apache/naming/core BaseDirContext.java
Log:
Remove all 'simple context' code.
Remove all 'base behavior' and special methods code.
All that remains is base implementation for DirContext methods,
using the simplified BaseNaming methods and/or default behavior.
Revision ChangesPath
1.3 +3 -655
jakarta-tomcat-connectors/naming/src/org/apache/naming/core/BaseDirContext.java
Index: BaseDirContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/naming/src/org/apache/naming/core/BaseDirContext.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- BaseDirContext.java 8 Oct 2002 18:46:42 - 1.2
+++ BaseDirContext.java 17 Oct 2002 16:45:14 - 1.3
-101,130 +101,14
* author Remy Maucherat
* author Costin Manolache
*/
-public class BaseDirContext implements DirContext {
+public class BaseDirContext extends BaseContext implements DirContext {
-/**
- * Builds a base directory context.
- */
public BaseDirContext() {
-this.env=new Hashtable();
+super();
}
-/**
- * Builds a base directory context using the given environment.
- */
public BaseDirContext(Hashtable env) {
-this.env=new Hashtable();
-if (env != null ) {
-Enumeration envEntries = env.keys();
-while (envEntries.hasMoreElements()) {
-String entryName = (String) envEntries.nextElement();
-this.env.put(entryName, env.get(entryName));
-}
-}
-}
-
-// - Instance Variables
-
-/**
- * Environment. All context config info.
- * XXX IntrospectionDirContext should call the right setters.
- */
-protected Hashtable env;
-
-/**
- * Default name parser for this context.
- * XXX This should be combined with the Tomcat mapper, and
- * optimized for MessageBytes.
- */
-protected final NameParser nameParser = new NameParserImpl();
-
-/**
- * Cached.
- * deprecated ? Should be implemented via notes or other mechanism.
- * Or via config.
- */
-protected boolean cached = true;
-protected int cacheTTL = 5000; // 5s
-protected int cacheObjectMaxSize = 32768; // 32 KB
-
-
-/** Prefix used for URL-based namming lookup. It must be removed
- * from all names.
- * Deprecated ? Do we need it ?
- */
-protected String urlPrefix=;
-
-// - Properties
-
-// XXX Introspection should be used to turn the Hashtable attributes
-// into setters.
-
-public void setURLPrefix( String s ) {
-urlPrefix=s;
-}
-
-/**
- * Set cached attribute. If false, this context will be skipped from caching
- */
-public void setCached(boolean cached) {
-this.cached = cached;
-}
-
-/**
- * Is cached ?
- */
-public boolean isCached() {
-return cached;
-}
-
-
-/**
- * Set cache TTL.
- */
-public void setCacheTTL(int cacheTTL) {
-this.cacheTTL = cacheTTL;
-}
-
-
-/**
- * Get cache TTL.
- */
-public int getCacheTTL() {
-return cacheTTL;
-}
-
-
-/**
- * Set cacheObjectMaxSize.
- */
-public void setCacheObjectMaxSize(int cacheObjectMaxSize) {
-this.cacheObjectMaxSize = cacheObjectMaxSize;
-}
-
-
-/**
- * Get cacheObjectMaxSize.
- */
-public int getCacheObjectMaxSize() {
-return cacheObjectMaxSize;
-}
-
-// Lifecycle methods ?
-
-/**
- * Allocate resources for this directory context.
- */
-public void allocate() {
-; // No action taken by the default implementation
-}
-
-
-/**
- * Release any resources allocated for this directory context.
- */
-public void release() {
-; // No action taken by the default implementation
+super();
}
// Abstract methods
-287,524 +171,6
throw new OperationNotSupportedException();
}
-// Utils
-
-
-/**
- * Returns true if writing is allowed on this context.
- */
-protected boolean isWritable(Name name) {
-return ContextAccessController.isWritable(name);
-}
-
-
-/**
- * Throws a naming exception is Context is not writable.
-
Re: Vote results + Security Audit redirection
Paul Speed wrote: Any behind closed doors discussions have the potential for alienating the non-committer community. Determining what conversations are appropriate for this other list is a very slippery slope. It's :-) Yes, I think I know what you mean. Trust me, you're not the only one who things that, and 'closed doors' is the last thing I want. I see it more like an 'open doors' situation ( private Cc: - a larger group ). already been proposed that votes for new committers be discussed there first. What's next? And if the other list starts being used for No, I just sugested that it would be nice to avoid some of the incidents that happened in the past. I admit - in most cases I do send a private mail to the person and few private mails to some other commiters to ask their opinions. Jumping directly and making the proposal is not the best strategy IMO, and at least I never did that without at least a second opinion. So the only thing that will change is having this 'do you think it's a good idea' sent to everyone. And avoid 'no, I don't think so because ...' in the public list. As a non-committer but long-time subscriber to this list, my opinion is that _all_ messages on the other list must absolutely show up here eventually, at some delay. Otherwise, there is no longer any transparency. (This is also the biggest reason it's better than CCed e-mails; because the messages will always be public at some point.) I agree for most part. And I think that an all-commiter list is better than Cc: chains with few people, it's more inclusive and better for everyone. Regarding all-messages to the list - I agree, all information should get to tomcat-dev, ( unless whoever posts it wants to keep it private ). One of the reasons Cc: is used is because some people don't want certain issues to become public ( for example me asking Remy really dumb questions on JNDI :-). I think it would be better if most of the Cc: will go to the commiters list, and most of the commiters list will go to tomcat-dev. Both are improvements over current situation IMO. And besides - if someone really wants to be on the commiters list, there is a way to do it, and we are all happy to get more people involved ( and on the list ) :-) Costin -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13392] - When tag pooling is enabled, release() is not called on tag instances
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13392. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13392 When tag pooling is enabled, release() is not called on tag instances [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-10-17 16:55 --- *** Bug 13741 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 10541] - Content-length header should be automatically set for buffered Servlets/JSPs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10541 Content-length header should be automatically set for buffered Servlets/JSPs [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|tomcat- |[EMAIL PROTECTED] |[EMAIL PROTECTED] | Status|REOPENED|NEW -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13723] - Bootstrap: Class loader creation threw exception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13723. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13723 Bootstrap: Class loader creation threw exception [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 10541] - Content-length header should be automatically set for buffered Servlets/JSPs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10541 Content-length header should be automatically set for buffered Servlets/JSPs [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2002-10-17 22:12 --- I'll reopen the bug, since I also seem to have an itch with it. The major problem is that it's hard to know ( from connector side ) when you have this case, and the END will follow imediately after the first chunk. The only way to detect it is higher - and distinguish between a SEND that happens normally and the SEND+END that happens when the JSP/servlet finishes the request and the container is automatically flushing the buffer. I don't see any other solution, at least at container level - you can't guess that END will follow. The problem is finding the exact point where the flushing happens. Remy - if you want to close this, please mark it as REMIND or LATER, I'll fix it ( if I figure out how :-) -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13741] - TagSupport not release all attributes
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13741. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13741 TagSupport not release all attributes --- Additional Comments From [EMAIL PROTECTED] 2002-10-17 16:45 --- *** Bug 13742 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13700] - XML parser goes Internet when parsing a TLD
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13700. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13700 XML parser goes Internet when parsing a TLD --- Additional Comments From [EMAIL PROTECTED] 2002-10-17 14:32 --- Under common/endorsed, just drop xercesImpl.jar and xmlParserAPIs.jar (download it from xml.apache.org). Now Xerces will replace Crimson... I assume you are using 4.1.12. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Vote results + Security Audit redirection
It sounds like there is already a closed forum for discussing security, CC'ing all who might be interested. Making it a list just makes lives easier for all involved, and the whole thread is not lost and always exclusive only to those CC'd. (If the messages are eventually forwarded to the dev list or archived). People are saying that they are worried about something that is already going on, in a slightly different form. As long as the committers are responsible with this other list, things should only be better. Maybe the automatic forward (with a delay) will serve to keep everybody responsible on into the future. How hard is that to set up?? Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] 10/17/02 8:14:59 AM The nice thing about your current way of dicussing security issues (CC e-mail threads) is that it's a real pain in the butt. In other words, likely only to be used in the cases of necessity. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Fw: javadoc on web site
Since noone has responded on the user list, I'm posting this here, hoping someone will put those files back up. -warner - Original Message - From: Warner Onstine [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 16, 2002 10:32 PM Subject: javadoc on web site Hi guys, Don't know if anyone has noticed this but the javadoc: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/catalina/docs/api/index.html is missing, as well as missing from the 4.1.2 release distribution. I really need to look at this documentation if anyone has this available on-line (btw - I'm not in the mood to debug Tomcat's latest build quirks, like what I need to download, what it needs to be called and where it needs to go to even attempt building from source, last time I tried that I spent 1.5 hours trying to set all the variables and figure out where to get the right jars from ;-). Thanks in advance. -warner +warner onstine+ -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-connectors/naming/src/org/apache/naming/modules/memory MemoryNamingContext.java
costin 2002/10/17 09:49:30
Modified:naming/src/org/apache/naming/modules/memory
MemoryNamingContext.java
Log:
Fix lookup signature
Revision ChangesPath
1.3 +3 -4
jakarta-tomcat-connectors/naming/src/org/apache/naming/modules/memory/MemoryNamingContext.java
Index: MemoryNamingContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/naming/src/org/apache/naming/modules/memory/MemoryNamingContext.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- MemoryNamingContext.java 8 Oct 2002 18:46:43 - 1.2
+++ MemoryNamingContext.java 17 Oct 2002 16:49:30 - 1.3
-107,7 +107,6
*/
protected Hashtable bindings;
-
public void setBindings( Hashtable bindings ) {
this.bindings = bindings;
}
-273,7 +272,7
}
// XXX Make it iterative, less objects
-private NamingEntry findNamingEntry(Name name, boolean resolveLinks, Object o)
+private NamingEntry findNamingEntry(Name name, boolean resolveLinks)
throws NamingException
{
if (name.isEmpty()) {
-304,14 +303,14
}
}
-public Object lookup(Name name, boolean resolveLinks, Object o)
+public Object lookup(Name name, boolean resolveLinks)
throws NamingException
{
// Removing empty parts
while ((!name.isEmpty()) (name.get(0).length() == 0))
name = name.getSuffix(1);
-NamingEntry entry=findNamingEntry( name, resolveLinks, o );
+NamingEntry entry=findNamingEntry( name, resolveLinks );
if( entry.type == NamingEntry.CONTEXT ) {
return ((BaseDirContext) entry.value).lookup(name.getSuffix(1),
resolveLinks, o);
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-catalina/catalina/src/conf catalina.properties
remm2002/10/17 07:52:03 Added: catalina/src/conf catalina.properties Log: - Add my catalina.properties proposal (it this is voted down, the file can be removed, renamed or enhanced further). - This file would eventually get abstracted through a JNDI dircontext. In the default configuration, Tomcat would use that file, but remote JNDI providers could also be used, as for the rest of the cionfig if everything switches to JNDI. - The resource would be included in the classpath inside bootstrap..jar in the default distribution. Revision ChangesPath 1.1 jakarta-tomcat-catalina/catalina/src/conf/catalina.properties Index: catalina.properties === # # List of comma-separated packages that start with or equal this string # will cause a security exception to be thrown when # passed to checkPackageAccess unless the # corresponding RuntimePermission (accessClassInPackage.+package) has # been granted. package.access=sun. # # List of comma-separated packages that start with or equal this string # will cause a security exception to be thrown when # passed to checkPackageDefinition unless the # corresponding RuntimePermission (defineClassInPackage.+package) has # been granted. # # by default, no packages are restricted for definition, and none of # the class loaders supplied with the JDK call checkPackageDefinition. # #package.definition= # # List of comma-separated paths defining the contents of the common # classloader. Prefixes should be used to define what is the repository type. # Path may be relative to the CATALINA_HOME path or absolute. If left as blank, # the JVM system loader will be used as Catalina's common loader. # Examples: # foo: Add this folder as a class repository # foo/*.jar: Add all the JARs of the specified folder as class # repositories # foo/bar.jar: Add bar.jar as a class repository common.loader=common/classes,common/lib/*.jar # # List of comma-separated paths defining the contents of the server # classloader. Prefixes should be used to define what is the repository type. # Path may be relative to the CATALINA_HOME path or absolute. If left as blank, # the common loader will be used as Catalina's server loader. # Examples: # foo: Add this folder as a class repository # foo/*.jar: Add all the JARs of the specified folder as class # repositories # foo/bar.jar: Add bar.jar as a class repository server.loader=server/classes,server/lib/*.jar # # List of comma-separated paths defining the contents of the shared # classloader. Prefixes should be used to define what is the repository type. # Path may be relative to the CATALINA_BASE path or absolute. If left as blank, # the common loader will be used as Catalina's shared loader. # Examples: # foo: Add this folder as a class repository # foo/*.jar: Add all the JARs of the specified folder as class # repositories # foo/bar.jar: Add bar.jar as a class repository shared.loader=shared/classes,shared/lib/*.jar -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13759] New: - Tomcat Coyote hangs at fill() spending 100% CPU
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13759. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13759 Tomcat Coyote hangs at fill() spending 100% CPU Summary: Tomcat Coyote hangs at fill() spending 100% CPU Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote HTTP/1.1 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I've just seen this with Linux OS, but this maybe can be at any platform. After some hours working, some threads (1 or 2) of Tomcat begins to spend 100% CPU. Tomcat respond to new request but very very slowlly. Here I attach the thread trace of the threads spending 100% CPU: CPU1 states: 0,0% user, 7,0% system, 0,0% nice, 92,5% idle Mem: 1029620K av, 762008K used, 267612K free, 0K shrd, 157844K buff Swap: 1060248K av, 0K used, 1060248K free 219684K cached $5$3$2$2PID to kill: $2ill PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 20060 root 15 0 297M 297M 67604 R99,9 29,5 135:44 java 764 jas 15 0 1096 1096 812 R 7,0 0,1 0:07 top 1 root 8 0 504 504 440 S 0,0 0,0 0:07 init 2 root 8 0 00 0 SW0,0 0,0 0:00 keventd ... Thread-13 daemon prio=1 tid=0x0x8d053b0 nid=0x4e5c runnable [bc3ff000..bc3ff8ac] at org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:777) at org.apache.coyote.http11.InternalInputBuffer$InputStreamInputBuffer.doRead(InternalInputBuffer.java:807) at org.apache.coyote.http11.filters.IdentityInputFilter.end(IdentityInputFilter.java:203) at org.apache.coyote.http11.InternalInputBuffer.endRequest(InternalInputBuffer.java:398) at org.apache.coyote.http11.Http11Processor.process(Http11Processor..java:418) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:380) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint..java:508) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:518) at java.lang.Thread.run(Thread.java:536) -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Vote results + Security Audit redirection
Costin Manolache wrote: Paul Speed wrote: Any behind closed doors discussions have the potential for alienating the non-committer community. Determining what conversations are appropriate for this other list is a very slippery slope. It's :-) Yes, I think I know what you mean. Trust me, you're not the only one who things that, and 'closed doors' is the last thing I want. I see it more like an 'open doors' situation ( private Cc: - a larger group ). Phew. I feel better already. Seriously. already been proposed that votes for new committers be discussed there first. What's next? And if the other list starts being used for No, I just sugested that it would be nice to avoid some of the incidents that happened in the past. I admit - in most cases I do send a private mail to the person and few private mails to some other commiters to ask their opinions. Jumping directly and making the proposal is not the best strategy IMO, and at least I never did that without at least a second opinion. So the only thing that will change is having this 'do you think it's a good idea' sent to everyone. And avoid 'no, I don't think so because ...' in the public list. Yeah, I see where you're coming from, but some of that should end up public. Fine line. For example, let me paint a (hopefully) brief picture. I'm probably one of your more avid non-committers: I still read (and to some extent participate) even though I haven't used tomcat professionally in over two years. I've been on the list for maybe three years... lost count. During a period of unemployment a year ago, my itch was to bring the SSI stuff up to spec and so I mostly rewrote the SSI servlet and associated classes. These were accepted and committed to head. All was well and even kept up on recommending people stay away from the older version when issues would crop up in bugzilla. Eventually I got a job and spent a few months off the list. During that time someone else also found the old SSI code lacking and rewrote it again without ever noticing that there was alreay a newer better version. Unfortunately, the committers didn't notice either and all of my work was blown away. Sad, but such is life sometimes. Anyway, long story short, this person was made committer shorlty after that, persumably just to maintain the SSI code. There was some controversy on this list at the time about whether or not this was appropriate since there hadn't been many other contributions from said person. If I hadn't witnessed this conversation, it really would have added insult to injury when they were made committer. Instead, it was no big deal at all other than a little disappointment. So, that's probably why your earlier committer vote proposal comment grabbed my interest in this thread. Ok, so not brief. Oh well, -Paul As a non-committer but long-time subscriber to this list, my opinion is that _all_ messages on the other list must absolutely show up here eventually, at some delay. Otherwise, there is no longer any transparency. (This is also the biggest reason it's better than CCed e-mails; because the messages will always be public at some point.) I agree for most part. And I think that an all-commiter list is better than Cc: chains with few people, it's more inclusive and better for everyone. Regarding all-messages to the list - I agree, all information should get to tomcat-dev, ( unless whoever posts it wants to keep it private ). One of the reasons Cc: is used is because some people don't want certain issues to become public ( for example me asking Remy really dumb questions on JNDI :-). I think it would be better if most of the Cc: will go to the commiters list, and most of the commiters list will go to tomcat-dev. Both are improvements over current situation IMO. And besides - if someone really wants to be on the commiters list, there is a way to do it, and we are all happy to get more people involved ( and on the list ) :-) Costin -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 11042] - Misleading comment in server.xml
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11042. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11042 Misleading comment in server.xml --- Additional Comments From [EMAIL PROTECTED] 2002-10-18 09:55 --- Hi Tomcat commiters!!! This is an easy to solve mispelling. How can this bug be open since 07-22? Still bad comment at Tomcat 5. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13731] - Final request, response, session and other variables.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13731. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13731 Final request, response, session and other variables. --- Additional Comments From [EMAIL PROTECTED] 2002-10-18 09:57 --- Created an attachment (id=3528) Patch to fix this problem, against 4.1.12 tomcat version -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13731] - Final request, response, session and other variables.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13731. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13731 Final request, response, session and other variables. --- Additional Comments From [EMAIL PROTECTED] 2002-10-18 09:58 --- I have added a patch against 4.1.12 tomcat source to fix this problem. However it simply forces all to be final. Please evalute it on including in cvs tree. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: uri mapping problems
-Original Message- From: Mladen Turk If there are not such limitations then we'll need some sort of reverse prefix mapping. Or just put the pcre in the apr-util, and you'll be able to match the things limited only by your imagination :-) MT. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-connectors/naming/src/org/apache/naming/core BaseDirContext.java BaseNaming.java
costin 2002/10/17 10:32:23
Modified:naming/src/org/apache/naming/core BaseDirContext.java
BaseNaming.java
Log:
As usual, I need to compile it before commit.
Revision ChangesPath
1.4 +0 -15
jakarta-tomcat-connectors/naming/src/org/apache/naming/core/BaseDirContext.java
Index: BaseDirContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/naming/src/org/apache/naming/core/BaseDirContext.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- BaseDirContext.java 17 Oct 2002 16:45:14 - 1.3
+++ BaseDirContext.java 17 Oct 2002 17:32:23 - 1.4
-134,21 +134,6
throw new OperationNotSupportedException();
}
-public void size() throws NamingException
-{
-throw new OperationNotSupportedException(size);
-}
-
-public Name childNameAt( int i ) throws NamingException
-{
-return null;
-}
-
-public Object childAt( int i ) throws NamingException
-{
-return null;
-}
-
public DirContext createSubcontext(Name name, Attributes attrs)
throws NamingException
{
1.2 +4 -3
jakarta-tomcat-connectors/naming/src/org/apache/naming/core/BaseNaming.java
Index: BaseNaming.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/naming/src/org/apache/naming/core/BaseNaming.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- BaseNaming.java 17 Oct 2002 16:47:14 - 1.1
+++ BaseNaming.java 17 Oct 2002 17:32:23 - 1.2
-68,6 +68,7
import javax.naming.directory.ModificationItem;
import javax.naming.directory.SearchControls;
import org.apache.tomcat.util.res.StringManager;
+import org.apache.tomcat.util.IntrospectionUtils;
// Based on a merge of various catalina naming contexts
// Name is used - it provide better oportunities for reuse and optimizations
-122,9 +123,9
// XXX We need a mechanism to select properties for
// this task. Maybe all contexts should use as property prefix
the
// class name ? Or base class name ?
-IntrospectionUtil.setProperty( this, entryName, entryValue );
+IntrospectionUtils.setAttribute( this, entryName, entryValue );
} catch(Exception ex ) {
-System.out.println(Unsuported property + entryName + +
ex.getMassage());
+System.out.println(Unsuported property + entryName + +
ex.getMessage());
}
}
}
-299,7 +300,7
throws NamingException
{
// Override if needed
-Object value = lookup(oldName, false, null);
+Object value = lookup(oldName, false);
bind(newName, value, null, false);
unbind(oldName, true);
}
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13733] New: - Unpack War files
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13733. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13733 Unpack War files Summary: Unpack War files Product: Tomcat 4 Version: 4.1.13 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The problem occur when Tomcat try to unpack a war file. I discovered that ANT 1.5 make a directory name lower case when it found it is all upper case, automatically, when creating a war (jar) file. On the other side, Tomcat is case sensitive concerning the WEB-INF directory. What happen,the application is not loaded because it can't find the web.xml. That happen just with web.xml, All the other files under lib or classes are zipped correctly. The problem, i believe is inside Tomcat 4.1.12 and up because opening the war file with winzip is possible see that web-inf is lower case (just for web.xml) AND the same war file deployed on Tomcat 4.1.8 works fine. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-connectors/naming/src/org/apache/naming/core ServerName.java
costin 2002/10/17 09:48:28
Modified:naming/src/org/apache/naming/core ServerName.java
Log:
Fix the comments. Still no implementation ( it's not very important
for now, using normal contexts / names and getting the functionality
is more important )
Revision ChangesPath
1.2 +9 -6
jakarta-tomcat-connectors/naming/src/org/apache/naming/core/ServerName.java
Index: ServerName.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/naming/src/org/apache/naming/core/ServerName.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ServerName.java 1 Oct 2002 18:42:16 - 1.1
+++ ServerName.java 17 Oct 2002 16:48:28 - 1.2
-63,14 +63,16
import javax.naming.*;
/**
- * Extended version for Attribute. All our dirContexts should return objects
- * of this type. Methods that take attribute param should use this type
- * of objects for performance.
+ * Implementation of Name with support for extra information.
*
- * This is an extension of the 'note' in tomcat 3.3. Each attribute will have an
- * 'ID' ( small int ) and an associated namespace. The attributes are recyclable.
+ * An extra feature ( not yet implemneted ) is the support for
+ * MessageBytes. This allows tomcat to operate lookup operations
+ * on the original message, without creating Strings.
*
- * The attribute is designed for use in server env, where performance is important.
+ * Another feature is support for extra information that can be cached.
+ * This brakes a bit the JNDI requirements, as Contexts can modify the
+ * Name and add anotations. The main benefit is that after the first
+ * lookup it'll be possible to avoid some expensive operations.
*
* author Costin Manolache
*/
-101,6 +103,7
}
/**
+ * Factory method to create server names.
*/
public static Name getName( String s ) throws InvalidNameException {
return new ServerName( s );
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: Vote results + Security Audit redirection
From: Paul Speed [mailto:pspeed;progeeks.com] Sent: Thursday, October 17, 2002 4:15 PM The nice thing about your current way of dicussing security issues (CC e-mail threads) is that it's a real pain in the butt. In other words, likely only to be used in the cases of necessity. Not really, CC'ed threads are easy to manage simply reply to all and things goes smoothly, the problem the new mail list tries to solve, is much more simple, Are those how can fix and are interested in the problem, informed quickly? are those interested not forgotten in some part of the eamil theread? are part of the thread more private than intended only because some people unadvertely forgotten some other fellow email in the CC?.. all of that can be alleviated if not solved simply by using a closed maillist.. Fixes are ever public, and CVs comments are more than sufficient to see the problem and the fix being done.. so the open end of all threads in the new list is guaranteed now.. Saludos, Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13735] New: - Error code 302 in error-page XML tag prevents Authentication type FORM from working
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13735. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13735 Error code 302 in error-page XML tag prevents Authentication type FORM from working Summary: Error code 302 in error-page XML tag prevents Authentication type FORM from working Product: Tomcat 4 Version: 4.0.3 Final Platform: All OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Catalina:Modules AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Simply put, when I use Authentication type FORM and I route error code 302 – temporarily unavailable to my error handling routine my error routine runs instead of my login form. However, if I comment out the references to error code 302 in my web.xml – the login screen displays and everything work fine. The only difference between working and not working was commenting out error- code 302. Here’s my XML !-- 302 temp unavailable error-page error-code302/error-code location/servlet/Cert_MyCode.ErrorHandlerMaster/location /error-page -- security-constraint web-resource-collection web-resource-nameAdmin area/web-resource-name url-pattern/Cert_MyHtml/Secured/Admin1.html/url-pattern /web-resource-collection auth-constraint role-nameMyAdmin/role-name /auth-constraint /security-constraint login-config auth-methodFORM/auth-method form-login-config form-login-page/Cert_MyHtml/SecuredLogin.html/form-login- page form-error-page/Cert_MyHtml/SecuredLoginError.html/form- error-page /form-login-config /login-config -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
uri mapping problems
Hi, I am fighting with the mapping of mod_jk2. (Apache-2.0). I have noted that things like [uri:/*_servlet_vehicle/*] is not working. Any hints? Cheers Jean-frederic -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Possible mod_jk patch with ap_get_server_name
Mladen Turk wrote: -Original Message- From: Henri Gomez +s-server_name = ap_get_server_name(r); s-server_port = htons( r-connection-local_addr.sin_port ); s-server_software = (char *)ap_get_server_version(); It's seems correct. JF, Mladen what do you think ? Beter use the following: s-server_name = ap_get_server_name(r); s-server_port = ap_get_server_port(r); That's how it's done on JK2. Ok, commited to jk 1.2.1-dev, for Apache 1.3 and 2.0. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13736] New: - Socket closed unexpectedly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13736. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13736 Socket closed unexpectedly Summary: Socket closed unexpectedly Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Other Status: NEW Severity: Critical Priority: Other Component: Connector:Coyote HTTP/1.1 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I am running Tomcat 4.1.12 under Windows NT 4 and using JDK 1.4.0_02. Every few days I get this error on console: org.apache.tomcat.util.log.CommonLogHandler log INFO: Endpoint ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=80] ignored exception: java.net.SocketException: socket closed java.net.SocketException: socket closed at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:343) at java.net.ServerSocket.implAccept(ServerSocket.java:438) at java.net.ServerSocket.accept(ServerSocket.java:409) at org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket (DefaultServerSocketFactory.java:107) at org.apache.tomcat.util.net.PoolTcpEndpoint.acceptSocket (PoolTcpEndpoint.java:335) at org.apache.tomcat.util.net.TcpWorkerThread.runIt (PoolTcpEndpoint.java:483) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadPool.java:533) at java.lang.Thread.run(Thread.java:536) It seems that socket for port 80 is closed and the server stops responding, CPU usage goes to 100% and this error then repeats forever (for every request), but it is not logged to any log file, just to console. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Possible mod_jk patch with ap_get_server_name
* Mladen Turk ([EMAIL PROTECTED]) wrote : Hi, Beter use the following: s-server_name = ap_get_server_name(r); s-server_port = ap_get_server_port(r); Ack, if only I had read that a few days ago! ;-) Paul -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-connectors/jk/native/apache-1.3 mod_jk.c
hgomez 2002/10/18 03:23:16 Modified:jk/native/apache-2.0 mod_jk.c jk/native/apache-1.3 mod_jk.c Log: make sure that servername/serverport will works with VirtualHost with or without UseCanonicalName. Providd by [EMAIL PROTECTED], and validated by Mladen which does it the same way in jk2... Revision ChangesPath 1.57 +8 -6 jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c Index: mod_jk.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v retrieving revision 1.56 retrieving revision 1.57 diff -u -r1.56 -r1.57 --- mod_jk.c 10 Sep 2002 15:08:13 - 1.56 +++ mod_jk.c 18 Oct 2002 10:23:15 - 1.57 @@ -479,13 +479,15 @@ ); /* get server name */ -s-server_name= (char *)(r-hostname ? r-hostname : - r-server-server_hostname); - +/* s-server_name= (char *)(r-hostname ? r-hostname : r-server-server_hostname); */ +/* XXX : Ã la jk2 */ + s-server_name = ap_get_server_name(r); /* get the real port (otherwise redirect failed) */ -apr_sockaddr_port_get(port,r-connection-local_addr); -s-server_port = port; +/* apr_sockaddr_port_get(port,r-connection-local_addr); */ +/* s-server_port = port; */ +/* XXX : Ã la jk2 */ + s-server_port = ap_get_server_port(r); s-server_software = (char *)ap_get_server_version(); 1.30 +11 -3 jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c Index: mod_jk.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c,v retrieving revision 1.29 retrieving revision 1.30 diff -u -r1.29 -r1.30 --- mod_jk.c 30 Jul 2002 02:13:04 - 1.29 +++ mod_jk.c 18 Oct 2002 10:23:15 - 1.30 @@ -466,9 +466,17 @@ s-remote_host = NULL_FOR_EMPTY(s-remote_host); s-remote_addr = NULL_FOR_EMPTY(r-connection-remote_ip); -s-server_name = (char *)(r-hostname ? r-hostname : r-server-server_hostname); + +/* get server name */ +/* s-server_name = (char *)(r-hostname ? r-hostname : r-server-server_hostname); */ +/* XXX : Ã la jk2 */ + s-server_name = ap_get_server_name(r); -s-server_port = htons( r-connection-local_addr.sin_port ); +/* get the real port (otherwise redirect failed) */ +/* s-server_port = htons( r-connection-local_addr.sin_port ); */ +/* XXX : Ã la jk2 */ + s-server_port = ap_get_server_port(r); + s-server_software = (char *)ap_get_server_version(); s-method = (char *)r-method; -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-connectors/naming/src/org/apache/naming/modules/fs FileDirContext.java
costin 2002/10/17 09:49:03
Modified:naming/src/org/apache/naming/modules/fs FileDirContext.java
Log:
Fix broken licence comment.
Fix the lookup signature.
Revision ChangesPath
1.3 +1 -16
jakarta-tomcat-connectors/naming/src/org/apache/naming/modules/fs/FileDirContext.java
Index: FileDirContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/naming/src/org/apache/naming/modules/fs/FileDirContext.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- FileDirContext.java 8 Oct 2002 18:46:43 - 1.2
+++ FileDirContext.java 17 Oct 2002 16:49:03 - 1.3
-13,21 +13,6
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
- * 2. Re/*
- *
- *
- * The Apache Software License, Version 1.1
- *
- * Copyright (c) 1999 The Apache Software Foundation. All rights
- * reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- *
- * 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer.
- *
* 2. Rey appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
-257,7 +242,7
* return the object bound to name
* exception NamingException if a naming exception is encountered
*/
-public Object lookup(Name nameObj, boolean resolveLinkx, Object o)
+public Object lookup(Name nameObj, boolean resolveLinkx)
throws NamingException
{
if( log.isDebugEnabled() ) log.debug( lookup + nameObj );
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-catalina/catalina build.xml
patrickl2002/10/17 11:20:04
Modified:catalina build.xml
Log:
Adjust properties for building jakarta-tomcat-connectors/jk
Revision ChangesPath
1.26 +1 -2 jakarta-tomcat-catalina/catalina/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/build.xml,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- build.xml 17 Oct 2002 03:17:52 - 1.25
+++ build.xml 17 Oct 2002 18:20:03 - 1.26
-652,8 +652,7
target name=build-tomcat-jk
ant dir=${tomcat-jk.home} target=build-main
- property name=tomcat41.home value=${catalina.deploy}/
- property name=catalina.home value=${catalina.deploy}/
+ property name=tomcat5.home value=${catalina.deploy}/
property name=commons-logging.jar value=${commons-logging.jar}/
property name=jmx.jar value=${jmx.jar}/
/ant
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_global.h
mturk 2002/10/18 04:25:44 Modified:jk/native2/include jk_global.h Log: Change the exposed version number and string to 2.0.2 Revision ChangesPath 1.15 +3 -3 jakarta-tomcat-connectors/jk/native2/include/jk_global.h Index: jk_global.h === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_global.h,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- jk_global.h 24 Sep 2002 22:45:18 - 1.14 +++ jk_global.h 18 Oct 2002 11:25:44 - 1.15 -86,8 +86,8 /** START OF AREA TO MODIFY BEFORE RELEASING */ #define JK_VERMAJOR 2 #define JK_VERMINOR 0 -#define JK_VERFIX 0 -#define JK_VERSTRING2.0.0 +#define JK_VERFIX 2 +#define JK_VERSTRING2.0.2 /* Beta number */ #define JK_VERBETA 1 -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_map.c
mturk 2002/10/18 04:45:25
Modified:jk/native2/common jk_map.c
Log:
Add the key checksum processing from APR table.
This speeds up the get/put table operations a lot.
Revision ChangesPath
1.22 +61 -5 jakarta-tomcat-connectors/jk/native2/common/jk_map.c
Index: jk_map.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_map.c,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- jk_map.c 10 Jun 2002 21:55:06 - 1.21
+++ jk_map.c 18 Oct 2002 11:45:25 - 1.22
-72,23 +72,63
typedef struct jk_map_private {
char **names;
void **values;
+apr_uint32_t *keys;
int capacity;
int size;
} jk_map_private_t;
+#if APR_CHARSET_EBCDIC
+#define CASE_MASK 0xbfbfbfbf
+#else
+#define CASE_MASK 0xdfdfdfdf
+#endif
+
+/* Compute the checksum for a key, consisting of the first
+ * 4 bytes, normalized for case-insensitivity and packed into
+ * an int...this checksum allows us to do a single integer
+ * comparison as a fast check to determine whether we can
+ * skip a strcasecmp
+ */
+#define COMPUTE_KEY_CHECKSUM(key, checksum)\
+{ \
+const char *k = (key); \
+apr_uint32_t c = (apr_uint32_t)*k; \
+(checksum) = c;\
+(checksum) = 8; \
+if (c) { \
+c = (apr_uint32_t)*++k;\
+checksum |= c; \
+} \
+(checksum) = 8; \
+if (c) { \
+c = (apr_uint32_t)*++k;\
+checksum |= c; \
+} \
+(checksum) = 8; \
+if (c) { \
+c = (apr_uint32_t)*++k;\
+checksum |= c; \
+} \
+checksum = CASE_MASK; \
+}
+
static void *jk2_map_default_get(jk_env_t *env, jk_map_t *m,
const char *name)
{
int i;
jk_map_private_t *mPriv;
-
+apr_uint32_t checksum;
+
if(name==NULL )
return NULL;
mPriv=(jk_map_private_t *)m-_private;
+COMPUTE_KEY_CHECKSUM(name, checksum);
+
for(i = 0 ; i mPriv-size ; i++) {
-if(0 == strcmp(mPriv-names[i], name)) {
+if (mPriv-keys[i] == checksum
+strcmp(mPriv-names[i], name) == 0) {
/*fprintf(stderr, jk_map.get found %s %s \n, name, mPriv-values[i]
); */
return mPriv-values[i];
}
-105,6 +145,7
if(mPriv-size = mPriv-capacity) {
char **names;
void **values;
+apr_uint32_t *keys;
int capacity = mPriv-capacity + CAPACITY_INC_SIZE;
names = (char **)m-pool-calloc(env, m-pool,
-112,7 +153,9
values = (void **)m-pool-calloc(env, m-pool,
sizeof(void *) * capacity);
-if( names== NULL || values==NULL ) {
+keys = (apr_uint32_t *)m-pool-calloc(env, m-pool,
+ sizeof(apr_uint32_t) * capacity);
+if( names== NULL || values==NULL || keys==NULL) {
env-l-jkLog(env, env-l, JK_LOG_ERROR,
map.realloc(): AllocationError\n);
return JK_ERR;
-125,9 +168,13
if (mPriv-capacity mPriv-values)
memcpy(values, mPriv-values, sizeof(void *) * mPriv-capacity);
+
+if (mPriv-capacity mPriv-keys)
+memcpy(keys, mPriv-keys, sizeof(apr_uint32_t) * mPriv-capacity);
mPriv-names = ( char **)names;
mPriv-values = ( void **)values;
+mPriv-keys = keys;
mPriv-capacity = capacity;
return JK_OK;
-144,14 +191,18
int rc = JK_ERR;
int i;
jk_map_private_t *mPriv;
+apr_uint32_t checksum;
if( name==NULL )
return JK_ERR;
mPriv=(jk_map_private_t *)m-_private;
+COMPUTE_KEY_CHECKSUM(name, checksum);
+
for(i = 0 ; i mPriv-size ; i++) {
-if(0 == strcmp(mPriv-names[i], name)) {
+if (mPriv-keys[i] == checksum
+strcmp(mPriv-names[i], name) == 0) {
break;
}
}
-175,6 +226,7
mPriv-names[mPriv-size] = (char *)name;
*/
mPriv-names[mPriv-size] =
DO NOT REPLY [Bug 13759] - Tomcat Coyote hangs at fill() spending 100% CPU
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13759. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13759 Tomcat Coyote hangs at fill() spending 100% CPU [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-10-18 12:53 --- This line is a blocking I/O call, so I don't see how it would hang there, unless the call returns 0 (but I don't think it's supposed to), in which case a loop condition might occur. You'll have to debug this further, as the report doesn't allow to reproduce it nor isolate any particular problem. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 3888] - WebappClassLoader: Lifecycle error : CL stopped
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888
WebappClassLoader: Lifecycle error : CL stopped
--- Additional Comments From [EMAIL PROTECTED] 2002-10-18 14:36 ---
Hi.
I experienced the same problem and have been trying to find out something about
it. What I did is I modified the
org.apache.catalina.loader.WebappClassLoader.java and provoke an Exception in
it. Actually there are two places where this 'error' can occur, but in my case
it happens while trying to load a class.
So my debug part starts in line 1304 (tomcat 4.1.12) and looks like:
public Class loadClass(String name, boolean resolve)
throws ClassNotFoundException {
if (debug = 2)
log(loadClass( + name + , + resolve + ));
Class clazz = null;
String test = null;
// Don't load classes if class loader is stopped
if (!started) {
log(###CLASS[ + name + ]### Lifecycle error : CL stopped);
try {
test.length();
}
catch(Exception e) {
e.printStackTrace();
}
...
When the error occurs (strangely not on the first touch of a jar package,
instead only every after the first) it produces (in my case) the following output:
WebappClassLoader: ###CLASS[org.apache.log4j.helpers.NullEnumeration]###
Lifecycle error : CL stopped
java.lang.NullPointerException
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1317)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1274)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:322)
at org.apache.log4j.Category.getAllAppenders(Category.java:394)
at
org.apache.velocity.runtime.log.SimpleLog4JLogSystem.shutdown(SimpleLog4JLogSystem.java:200)
at
org.apache.velocity.runtime.log.SimpleLog4JLogSystem.finalize(SimpleLog4JLogSystem.java:194)
at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)
at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83)
at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)
So it looks like that the Finalizer calls (in my case) velocity's
SimpleLog4JLogSystem's finalize method which it self calls Log4J's Category's
getAllAppenders method calls. This uses the static method from NullEnumeration
to return an instance variable. The problem is that this instance
is created by new NullEnumeration() so I guess that then this class has to be
found with the help of catalina's WebappClassLoader.
Please find here an extract:
public class NullEnumeration implements Enumeration {
private static final NullEnumeration instance = new NullEnumeration();
...
public static NullEnumeration getInstance() {
return instance;
}
...
Perhaps this NullEnumeration should be instantiated once in Log4J's init
procedure in order to have an instance already loaded in memory and the class
already resolved or velocity should not try to close all appenders in its
finalize. In my case I have a start-up servlet in my webapp which now contains
the following line in it's init method:
logger.debug(Log4J instance now in memory: +
org.apache.log4j.helpers.NullEnumeration.getInstance());
And this works fine for me... So I am not an expert, but I hope that helps
everybody to sort out their problems because after all I don't think that this
is a proper bug. Due to the fact that is my first active part, comments and
critics of this posts are very welcome.
Best regards
Carsten Woelk
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cookies with mod_jk 1.2 load balancing and tomcat 4.1.12
How is the cookie written with mod_jk 1.2 and tomcat 4.1.12 to accomplish load balancing? With mod_jk 1.1 and tomcat 3.3 my JSESSIONID would be equal to blah.server_id where blah was the session and .server_id I thought was appended by mod_jk in order to direct the traffic back to the appropriate worker. I've been unsuccessfully trying to get mod_jk 1.2 and tomcat 4.1.12 working with apache 1.3.x and while apache connects to tomcat just fine, the .server_id is never appended to the session and I keep getting bounced from server to server. In addition to mod_jk 1.2, I've also tried mod_jk 1.1 and mod_jk 2.0.1 all with the same issue. Maybe if someone can point me towards the code that is supposed to do the session rewrite I can try to add some debugging to help me discover the problem. Thanks, Jason -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_worker.h
mturk 2002/10/18 08:21:01 Modified:jk/native2/include jk_worker.h Log: Add maxEndpoints option Revision ChangesPath 1.28 +11 -1 jakarta-tomcat-connectors/jk/native2/include/jk_worker.h Index: jk_worker.h === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_worker.h,v retrieving revision 1.27 retrieving revision 1.28 diff -u -r1.27 -r1.28 --- jk_worker.h 14 Oct 2002 06:32:49 - 1.27 +++ jk_worker.h 18 Oct 2002 15:21:01 - 1.28 -162,6 +162,16 */ struct jk_map *endpointMap; +/* Maximum number of endpoints per worker. + The default value is 0, meaning unlimited. + */ +int maxEndpoints; + +/* Indicates that worker has reached maximum number of 'used' + connections. + */ +int in_max_epcount; + /** Request pool cache. XXX We may use a pool of requests. */ struct jk_objCache *rPoolCache; -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_ajp13.c
mturk 2002/10/18 08:23:52
Modified:jk/native2/common jk_worker_ajp13.c
Log:
Add max_connections option that checks the number of used endpoints.
If the specified number is reached then the load balancer has the chance
to try another worker. This is very usefull in situations when having multiple
servers and you wish to finer grade the lb_factor.
Perhaps the option param can have another name?
Revision ChangesPath
1.41 +17 -0 jakarta-tomcat-connectors/jk/native2/common/jk_worker_ajp13.c
Index: jk_worker_ajp13.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_worker_ajp13.c,v
retrieving revision 1.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- jk_worker_ajp13.c 15 Oct 2002 09:38:29 - 1.40
+++ jk_worker_ajp13.c 18 Oct 2002 15:23:52 - 1.41
-160,6 +160,8
ajp13-level=atoi( value );
} else if( strcmp( name, channel )==0 ) {
ajp13-channelName=value;
+} else if( strcmp( name, max_connections )==0 ) {
+ajp13-maxEndpoints=atoi(value);
} else {
return JK_ERR;
}
-585,6 +587,21
ajp13-cs-lock( env, ajp13-cs );
{
+if (ajp13-maxEndpoints
+ajp13-maxEndpoints = ajp13-endpointMap-size(env,
ajp13-endpointMap)) {
+/* The maximum number of connections is reached */
+ajp13-in_max_epcount = JK_TRUE;
+if( ajp13-cs != NULL )
+ajp13-cs-unLock( env, ajp13-cs );
+if( ajp13-mbean-debug 0 )
+env-l-jkLog(env, env-l, JK_LOG_DEBUG,
+ ajp13.getEndpoint(): maximum %d endpoints for %s
reached\n,
+ ajp13-maxEndpoints,
+ ajp13-mbean-name);
+return JK_ERR;
+}
+ajp13-in_max_epcount = JK_FALSE;
+
jkb=env-createBean2( env, ajp13-mbean-pool, endpoint, NULL );
if( jkb==NULL ) {
if( ajp13-cs != NULL )
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13764] New: - Documentation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13764. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13764 Documentation Summary: Documentation Product: Tomcat 4 Version: Unknown Platform: All OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Webapps:Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I think that the SSL-Howto Documentation should include the overview/usage of security constraints and the use of user-data-constraints under the security-constraint section of the web.xml. I found this only after searching all the tomcat documentation on the web. If you could include the role of transport-guarantee and how it plays into things...that would be great! -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
[JK2] disable shm for threaded servers?
Hi, Can we disable shm (better ignore) for the servers that doesn't benefit at all from it? Meaning WIN32, perhaps others (depending on build?) Reason? Bunch of log error messages and checking that only waste CPU time. MT. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13392] - When tag pooling is enabled, release() is not called on tag instances
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13392. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13392 When tag pooling is enabled, release() is not called on tag instances --- Additional Comments From [EMAIL PROTECTED] 2002-10-18 15:55 --- It's interesting that such a practical adjustment is not made. We could change Tomcat and support many tag libraries unchanged. The choice is made to have ALL the tag developers release new versions of their tag libraries. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 3888] - WebappClassLoader: Lifecycle error : CL stopped
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888 WebappClassLoader: Lifecycle error : CL stopped --- Additional Comments From [EMAIL PROTECTED] 2002-10-18 17:28 --- If that is effectively the cause of the error, maybe log4j or Velocity could take care of the needed instanciation. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13392] - When tag pooling is enabled, release() is not called on tag instances
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13392. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13392 When tag pooling is enabled, release() is not called on tag instances --- Additional Comments From [EMAIL PROTECTED] 2002-10-18 17:31 --- If this is not compliant with the spec, it could have been broken at random by any particular implementation, unless all other implementors consider Jasper's behavior as the example to follow. It should be noted that unless there's heavy tag usage (such as in the admin webapp), tag pooling brings only a small performance increase, so it's fine to disable it. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13736] - Socket closed unexpectedly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13736. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13736 Socket closed unexpectedly --- Additional Comments From [EMAIL PROTECTED] 2002-10-18 17:47 --- Try JDK 1.4.1 to see if it helps (worse case, you'll get a nice performance boost), and maybe upgrading to a newer Windows OS if possible (Win 2k has a more reliable TCP/IP stack I think). At least make sure NT 4 SP 6 has been applied. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-catalina/catalina/src/conf catalina.policy
jfarcand2002/10/18 10:47:06
Modified:catalina/src/conf catalina.policy
Log:
Since we are granting file:${catalina.home}/server/- all permissions, we don't
need to grant special permissions for Admin and Manager applications.
Revision ChangesPath
1.4 +1 -10 jakarta-tomcat-catalina/catalina/src/conf/catalina.policy
Index: catalina.policy
===
RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/conf/catalina.policy,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- catalina.policy 1 Aug 2002 04:59:24 - 1.3
+++ catalina.policy 18 Oct 2002 17:47:06 - 1.4
-73,15 +73,6
permission java.security.AllPermission;
};
-// These permissions apply to the privileged admin and manager web applications
-grant codeBase file:${catalina.home}/server/webapps/admin/WEB-INF/classes/- {
-permission java.security.AllPermission;
-};
-
-grant codeBase file:${catalina.home}/server/webapps/admin/WEB-INF/lib/struts.jar {
-permission java.security.AllPermission;
-};
-
// == WEB APPLICATION PERMISSIONS =
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [JK2] disable shm for threaded servers?
Mladen Turk wrote: Hi, Can we disable shm (better ignore) for the servers that doesn't benefit at all from it? Meaning WIN32, perhaps others (depending on build?) Reason? Bunch of log error messages and checking that only waste CPU time. MT. +1 ( you can add disable=1 on the [shm] - it should work fine ). But in this case I think a memory area should be used for that purpose. The use of shm is for dynamic config changes and monitoring. It's not yet fully implemented, but jk_status uses it. -- Costin -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Bug 13736
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Friday, October 18, 2002 1:17 AM
Subject: Re: Bug 13736
Bill Barker wrote:
I don't remember anything like that for 3.3.x (and nothing even close is
open in BZ). But, then again, I don't imagine that very many people
try and
use the Http10Connector in production, and Coyote is only available in
the
nightly for 3.3 until 3.3.2 comes out.
o.a.t.u.net.PoolTcpEndpoint won't close the ServerSocket itself without
shutting down. It looks like the root cause is from the JVM, nio, O/S,
or
some other place we can't see.
(forwarding to tomcat-dev)
Ok, I looked at it more, and the TCP endpoint code considers an
exception during accept a normal event:
From PoolTcpEndpoint:
try {
if (running) {
accepted = factory.acceptSocket(serverSocket);
catch (SocketException e) {
// TCP stacks can throw SocketExceptions when the client
// disconnects. We don't want this to shut down the
// endpoint, so ignore it. Is there a more robust
// solution? Should we compare the message string to
// Connection reset by peer?
// socket exceptions just after closing endpoint (when
// running=false) aren't even logged
if (running != false) {
String msg = sm.getString(endpoint.err.nonfatal,
serverSocket, e);
log(msg, e, Log.INFORMATION);
}
}
OTOH, I don't think this should be the case, and I think we should
stop/start the server socket in that particular case, as was done in the
old HTTP connector:
try {
socket = serverSocket.accept();
} catch (IOException e) {
try {
// If reopening fails, exit
synchronized (threadSync) {
if (started !stopped)
log(accept error: , e);
if (!stopped) {
serverSocket.close();
serverSocket = open();
}
}
The root of the problem could be a defiency in the JVM's network code,
but IMO this shouldn't kill the connector.
+1. As I said above, it probably hasn't shown up in 3.3 mostly because
AJP13 has many fewer accepts.
Remy
--
To unsubscribe, e-mail:
mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:tomcat-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: [JK2] disable shm for threaded servers?
-Original Message- +1 ( you can add disable=1 on the [shm] - it should work fine ). But in this case I think a memory area should be used for that purpose. The use of shm is for dynamic config changes and monitoring. It's not yet fully implemented, but jk_status uses it. Know that, I was thinking more like a IF_HAVE_SHM, to skip the entire thing like in HAVE_JNI. If the JK2 can work without it then we should be able to switch it off entirely like APR, JNI etc. MT. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Bug 13736
Bill Barker wrote: +1. As I said above, it probably hasn't shown up in 3.3 mostly because AJP13 has many fewer accepts. I'll fix it then. You have to be careful that no IOException should end up in that code, otherwise, for each one the server socket will be restarted (not good). With HTTP/1.1, the only thing that can happen is when there's an exception in the accept, which apparently screws up the server socket. It would be nice if this was thouroughly tested for problems after I commit the fix. Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: [5] ClassLoader hell. Again.
Is this the cause of the error? I see that org/apache/commons/logging/LogFactory is used in a couple places, but in my case it consistently throws the exception in AprImpl.class. Details for my config, if they're relevant: OS: Solaris 8 UltraSPARC Java: J2SDK1.4.1 Jakarta-Tomcat: 5.0.0 Apache: 2.0.40 jniModeSo: inprocess Catalina.out contents: Oct 18, 2002 1:43:36 PM org.apache.commons.modeler.Registry loadRegistry INFO: Loading registry information Oct 18, 2002 1:43:36 PM org.apache.commons.modeler.Registry getRegistry INFO: Creating new Registry instance Oct 18, 2002 1:43:37 PM org.apache.commons.modeler.Registry getServer INFO: Creating MBeanServer Oct 18, 2002 1:43:38 PM org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on port 8080 Oct 18, 2002 1:43:38 PM org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on port 8082 Starting service Tomcat-Standalone Apache Tomcat/5.0 Oct 18, 2002 1:43:40 PM org.apache.catalina.startup.ContextConfig authenticatorConfig INFO: Configured an authenticator for method BASIC Oct 18, 2002 1:43:42 PM org.apache.catalina.startup.ContextConfig tldScan INFO: Processed tld jar /WEB-INF/lib/struts.jar 457 Oct 18, 2002 1:43:42 PM org.apache.catalina.startup.ContextConfig authenticatorConfig INFO: Configured an authenticator for method FORM Oct 18, 2002 1:43:49 PM org.apache.catalina.startup.ContextConfig authenticatorConfig INFO: Configured an authenticator for method FORM Oct 18, 2002 1:43:50 PM org.apache.catalina.startup.ContextConfig authenticatorConfig INFO: Configured an authenticator for method FORM Oct 18, 2002 1:43:50 PM org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on port 8080 Oct 18, 2002 1:43:50 PM org.apache.jk.server.JkMain newHandler SEVERE: Can't create apr java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory at org.apache.jk.apr.AprImpl.clinit(AprImpl.java:340) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:140) at org.apache.jk.server.JkMain.newHandler(JkMain.java:514) at org.apache.jk.server.JkMain.start(JkMain.java:336) at org.apache.jk.server.JkCoyoteHandler.start(JkCoyoteHandler.java:164) at org.apache.coyote.tomcat5.CoyoteConnector.start(Unknown Source) at org.apache.catalina.core.StandardService.start(Unknown Source) at org.apache.catalina.core.StandardServer.start(Unknown Source) at org.apache.catalina.startup.Catalina.start(Unknown Source) at org.apache.catalina.startup.Catalina.execute(Unknown Source) at org.apache.catalina.startup.Catalina.process(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Unknown Source) [Snip] -- mailto:Paul.Brzezinski;EDS.com Enterprise Distributed Capabilities EDS Corporation 248-265-8283 : -Original Message- : From: Costin Manolache [mailto:cmanolache;yahoo.com] : Sent: Wednesday, October 16, 2002 11:21 PM : To: [EMAIL PROTECTED] : Subject: Re: [5] ClassLoader hell. Again. : : : Answering my own mail, it seems Log is loaded twice, once : during init ( and it may be related with my setup, as I have : few log uses in the startup code ), and then it is loaded : again from the webapp loader, but this time it's a different : instance ( due to reverse order ). And somehow the check for : assignment happens with the original Log instance. : : If this is correct - we can either make commons-logging(-api) a : special case, or make sure it is not used in any code from : the common loader ( the use from the container loader should : be ok ). : : I love ClassLoaders :-) : : Costin : : : Costin Manolache wrote: : : This time I have problems with commons-logging. It seems : : org.apache.commons.logging.LogConfigurationException: Class : org.apache.commons.logging.impl.Log4JCategoryLog does not : implement Log : at : : org.apache.commons.logging.impl.LogFactoryImpl.getLogConstruct : or(LogFactoryImpl.java:435) : : It seems Log is loaded by the common loader, : Log4JCategoryLog by the : webapp loader. And they don't match. : : Same thing works fine in 4.1.12. : : I can fix this by moving commons-logging and log4j at top : level, but : that's just a workaround. : : Remy - any idea of what changed ? : : Costin : : -- : Costin : : : : -- : To unsubscribe, e-mail: : mailto:tomcat-dev-: [EMAIL PROTECTED] : For : additional commands, : e-mail: mailto:tomcat-dev-help;jakarta.apache.org : -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands,
DO NOT REPLY [Bug 13772] New: - Class loader HOWTO needs to href security HOWTO for WebappX
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13772. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13772 Class loader HOWTO needs to href security HOWTO for WebappX Summary: Class loader HOWTO needs to href security HOWTO for WebappX Product: Tomcat 4 Version: 4.1.12 Platform: PC URL: http://localhost:8080/tomcat-docs/class-loader- howto.html OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Webapps:Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The Class Loader HOWTO makes no mention of the default security constraints in catalina.policy which prevent ...WEB-INF/lib/ and ...WEB-INF/classes/ files and packages from being loaded. As a result, the information in the HOW-TO is not sufficient to successfully load classes. It would help if there was a hyperlink in the WebappX discussion (and perhaps similar ones elsewhere) to inform the beginner that there is more to it than merely dropping files and directories under the appropriate spots in WEB-INF. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13736] - Socket closed unexpectedly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13736. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13736 Socket closed unexpectedly [EMAIL PROTECTED] changed: What|Removed |Added OS/Version|Other |Windows NT/2K --- Additional Comments From [EMAIL PROTECTED] 2002-10-18 18:35 --- SP6 is already installed on this machine, and I already tried JDK 1.4.1 to check if that fixed anything, but I still got the same error. Unfortunately I don't have permissions to upgrade the operating system on this machine because of some stupid corporate policies :( What I did was to downgrade to the previous version running (JDK 1.3 and Tomcat 4.0.4) which solved the problem, but It would be nice (and useful) to able to use the latest Tomcat. Unfortunately I can't test various versions of Tomcat on this machine since it's a production server, and of course I never get this error on my development machines. (Running Win2000 and WinXP) -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: [5]: ant native for Connectors fails: (more)
Excellent, that fixed the problem of ant spawning libtool w/cc.
There are two other issues that popped up now:
1. in the file jk_channel_socket.c in directory
jakarta-tomcat-5.0.0-src/jakarta-tomcat-connectors/jk/native2/common must be
compiled with -DBSD_COMP on Solaris 8.
2. when building the native (as opposed to the native2) connectors, jni_md.h
isn't found presumably because the -I${java.home}/../include/solaris isn't
set in build.xml.
I did try to search bugzilla to see if these two issues are already being
tracked, but didn't find anything, which could just be about me not knowing
how to search the bug database...
Comments, advice, feedback encouraged...
Paul
--
mailto:Paul.Brzezinski;EDS.com
Enterprise Distributed Capabilities
EDS Corporation
248-265-8283
: -Original Message-
: From: Henri Gomez [mailto:hgomez;apache.org]
: Sent: Friday, October 18, 2002 4:16 AM
: To: Tomcat Developers List
: Subject: Re: [5]: ant native for Connectors fails:
:
:
: Brzezinski, Paul J wrote:
: Trying to build Jakarta Tomcat Connectors from 5.0.0 source:
:
: In jakarta-tomcat-connectors/jk
:
: Ant native complains about cc not being found, on Solaris 8, I have
: gcc in /em/opt/bin/gcc. I have no idea how to tell ant
: that it should
: use gcc or /em/opt/bin/gcc instead of cc, and no idea how
: to configure
: the args to libtool that it should gcc instead of cc.
:
: I'd like to figure this out, but need assistance.
:
: Assuming this isn't a known bug, is this something that should be
: reported as a bug using bugzilla?
:
: You could put /em/opt/bin/ in PATH before compiling ?
:
: export PATH=/em/opt/bin:$PATH
:
: Or set the ant project property :
:
: buid.native.cc=/em/opt/bin/gcc
:
:
:
:
:
: --
: To unsubscribe, e-mail:
: mailto:tomcat-dev-: [EMAIL PROTECTED]
: For
: additional commands,
: e-mail: mailto:tomcat-dev-help;jakarta.apache.org
:
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 3888] - WebappClassLoader: Lifecycle error : CL stopped
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888 WebappClassLoader: Lifecycle error : CL stopped --- Additional Comments From [EMAIL PROTECTED] 2002-10-18 18:47 --- added ceki for his input. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13386] - JK2 connector for Apache2: missing -DBSD_COMP for C compiler
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13386. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13386 JK2 connector for Apache2: missing -DBSD_COMP for C compiler --- Additional Comments From [EMAIL PROTECTED] 2002-10-18 18:50 --- File: jk_channel_socket.c FIONBIO doesn't get set unless BSD_COMP is defined on Solaris 8. in the file jk_channel_socket.c in directory jakarta-tomcat-connectors-4.1.12- src/jk/native2/common must be compiled with -DBSD_COMP on Solaris 8. in the file jk_channel_socket.c in directory jakarta-tomcat-5.0.0-src/jakarta- tomcat-connectors/jk/native2/common must be compiled with -DBSD_COMP on Solaris 8. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13673] - Exception in StandardSession when writing a session manager
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13673. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13673 Exception in StandardSession when writing a session manager [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-10-18 18:51 --- Pilot error. RTFM. Sorry for the wasted bandwidth. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
[PROPOSAL] JK2 uriMap using native regex
Hi, I've posted a uriMap code that matches uri's using regular expressions couple of weeks ago. There was a consensus that we need to wait until 2.1 and eventually that we use the regex from APR (if it ever will be there). Ok, so I'm proposing that we make our own regex code (?). Why? 1. Apache2 has pcre.lib and pcreposix.lib as a part of standard distribution 2. Apache1.3.x has a regex.lib 3. For IIS we may use the standard pcre-3.9 or the one from Apache2 (they are the same) 4. Most unixes has pcre or regex as part of standard distribution. 5. If ever pcre gets to the APR we may use that one like any other. So, we will need single file with jk2_regex_compile, jk2_regex_match and will be able to use any of the upper combinations? Thoughts? MT. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
