DO NOT REPLY [Bug 7682] New: - Unable to initiate filter properly if Filter class is loaded by Catalina System Classloader
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=7682. 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=7682 Unable to initiate filter properly if Filter class is loaded by Catalina System Classloader Summary: Unable to initiate filter properly if Filter class is loaded by Catalina System Classloader Product: Tomcat 4 Version: 4.0.3 Final Platform: PC OS/Version: Other Status: NEW Severity: Minor Priority: Other Component: Connector:Webapp AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I add my filter classes to '%CATALINA_HOME/bin/catalina.sh' to make the catalina load them up from another directory not in catalina. But catalina can't start the filters... Below is the part of the log message. 2002-04-02 16:51:37 StandardContext[]: Starting filters 2002-04-02 16:51:37 StandardContext[]: Starting filter 'WSAFilter' 2002-04-02 16:51:37 StandardContext[]: Exception starting filter WSAFilter java.lang.NoSuchMethodError at com.isprint.accessmatrix.wsa.proxy.WSAServletFilter.setFilterConfig (WSAServletFilter.java:86) at com.isprint.accessmatrix.wsa.proxy.WSAServletFilter.init (WSAServletFilter.java:56) at org.apache.catalina.core.ApplicationFilterConfig.getFilter (ApplicationFilterConfig.java:254) at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef (ApplicationFilterConfig.java:314) at org.apache.catalina.core.ApplicationFilterConfig.init (ApplicationFilterConfig.java:120) at org.apache.catalina.core.StandardContext.filterStart (StandardContext.java:3064) at org.apache.catalina.core.StandardContext.start (StandardContext.java:3382) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123) at org.apache.catalina.core.StandardHost.start(StandardHost.java:614) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123) at org.apache.catalina.core.StandardEngine.start (StandardEngine.java:343) at org.apache.catalina.core.StandardService.start (StandardService.java:388) at org.apache.catalina.core.StandardServer.start (StandardServer.java:506) at org.apache.catalina.startup.Catalina.start(Catalina.java:781) at org.apache.catalina.startup.Catalina.execute(Catalina.java:681) at org.apache.catalina.startup.Catalina.process(Catalina.java:179) at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243) 2002-04-02 16:51:37 StandardContext[]: Context startup failed due to previous errors 2002-04-02 16:51:37 StandardContext[]: Stopping 2002-04-02 16:51:37 StandardContext[]: Stopping filters -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6908] - JavaCompiler interface setOutputDir always called with null parameter
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=6908. 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=6908 JavaCompiler interface setOutputDir always called with null parameter --- Additional Comments From [EMAIL PROTECTED] 2002-04-02 10:13 --- Created an attachment (id=1462) compiler wrapper test-app -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6908] - JavaCompiler interface setOutputDir always called with null parameter
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=6908. 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=6908 JavaCompiler interface setOutputDir always called with null parameter [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2002-04-02 10:16 --- I have retested this bug and I am still seeing calls to setOutputDir with a null parameter. I have attached a simple web-app that demonstrates the problem. It wraps the SunJaveCompiler Class in the DummyCompiler (in WEB-INF\src\nl\secorp\jsp\compiler\DummyCompiler.java) The following is printed to stdout if http://localhost:8080/compiler- test/index.jsp is requested: == START STDOUT === setEncoding(UTF8) setClasspath(c:\program files\java\j2re1.4.0\lib\rt.jar;c:\jakarta-tomcat-4.0 \bin\bootstrap.jar;C:/jakarta-tomcat-4.0/webapps/compiler-test/WEB- INF/classes;C:/jakarta-tomcat-4.0/webapps/compiler-test/WEB- INF/classes;C:/jakarta-tomcat-4.0/classes/;C:/jakarta-tomcat-4.0/lib/jasper- compiler.jar;C:/jakarta-tomcat-4.0/lib/jasper-runtime.jar;C:/jakarta-tomcat- 4.0/lib/naming-factory.jar;C:/jakarta-tomcat- 4.0/lib/nl.secorp.guid.jar;C:/jakarta-tomcat- 4.0/lib/nl.secorp.jsp.jar;C:/jakarta-tomcat- 4.0/lib/org.eclipse.java.compiler.jar;C:/jakarta-tomcat- 4.0/common/classes/;C:/jakarta-tomcat-4.0/common/lib/mm.mysql-2.0.11- bin.jar;C:/jakarta-tomcat-4.0/common/lib/naming-common.jar;C:/jakarta-tomcat- 4.0/common/lib/naming-resources.jar;C:/jakarta-tomcat- 4.0/common/lib/servlet.jar;C:/jakarta-tomcat-4.0/common/lib/tools.jar) setOutputDir(null) setMsgOutput() setClassDebugInfo(false) compile(C:\jakarta-tomcat-4.0\work\localhost\compiler-test\\index$jsp.java) == END STDOUT === -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6909] - source parameter to compile method called with mangled file path
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=6909. 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=6909 source parameter to compile method called with mangled file path --- Additional Comments From [EMAIL PROTECTED] 2002-04-02 10:20 --- This is only a problem in relation to bug 6908. I currently have to determine the compiler output directory based on the source filename since the setOutputDir is called with a null parameter. The duplicated backslash is preventing me from cleanly seperating the filename from the directory without specifically having to check for the double backslash (which might be a problem if this bug is fixed) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6908] - JavaCompiler interface setOutputDir always called with null parameter
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=6908. 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=6908 JavaCompiler interface setOutputDir always called with null parameter --- Additional Comments From [EMAIL PROTECTED] 2002-04-02 10:31 --- I have a feeling that the command line jsp compiler works OK since it uses CommandLineContext CommandLineContext.getJavacOutputDir returns scratchdir JspEngineContext.getJavacOutputDir returns null! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Absolute URI problem
In http spec: 5.1.2 Request-URI ... To allow for transition to absoluteURIs in all requests in future versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies. ... i think version 3.3.1 ive download has such problem... it does not support absolute URI in requsets... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Mod_jk v/s mod_webapp
Thank Constin,that really helped. Are there any advantages of WARP over APJ? I mean why would I want to use one over the other? I could tell you that packet encoding in ajp13 and warp is very similar. Did there is advantages to use warp over ajp ? Hard to tell but the question is elsewhere, advantage of mod_warp over mod_jk. mod_warp use warp protocol, require Apache Portable Runtime and is known to works under Apache 1.3/2.0 original mod_jk, 1.1 in tomcat cvs, and 1.2 in jakarta-tomcat-connectors cvs works with all major webservers (Apache 1.3/2.0, IIS, NES/iPlanet/Domino) So using jk instead of warp depend on webserver you want to have it. If need today, or tomorrow IIS/NES/DOMINO, use mod_jk, if you only need to use Apache 1.3/2.0 and have APR ready, you can use also mod_warp. Using mod_warp implies also you have tomcat 4.x as servlet engine, whereas mod_jk via ajp13 support tomcat 3.2, 3.3, 4.x. If you have today TC 3.2/3.3 and plan to upgrade at a later time to tomcat 4.x, mod_jk is the preferred choice. Another point is load-balancing/fault-tolerance. If you want to built tomcat farms behind your web server, mod_jk is the good choice, mod_warp didn't support that feature today. I don't like either - the only reason I use ajp13 is backward compatibility and the fact that all versions of tomcat supports it. yep Ok, the history is a bit complicated, it started with ajp11 and ajp12 ( first text based, second binary ). Ajp12 evolved into ajp13 - using same encoding but with some extensions ( to deal with persistent connections ). Looking back - and forward - I think using CDR or XDR would have been ( or will be ) much better choices for marshalling, and a subset of RPC or IIOP for protocol. Jk2 supports multiple protocols, and one of the reasons is to allow a future migration to a more standard protocol. I take a look at XDR (didn't know where to find info about CDR). ajp13 is very similar to XDR, and even less bd/cpu cosuming since XDR want to have 4 bytes (32bits) padded messages whereas ajp13 could use only single byte. Why waste cycle to send unused bytes and waste cycles to decode unused bytes. ;) We're not the only one inventing protocols - look at DCOP :-) And it seems full IIOP ( or at least using an existing ORB ) does have performance impact, or did for KDE people. Yes, it's clear that a full protocol like IIOP/DCOM is something like using a tank to kill a fly, at least in 99% of time operation which is to forward request and replies. The current marshalling/unmarshalling is really similar to what XDR provide (data type are : smallint (16bits), int (32ints), strings, raw datas (opaque data in XDR), boolean), enums like headers type are present as smallint). Maybe we could add small strings à la MacOs/Pascal ( strings of less than 256 chars), having there first byte indicating length) and also add hyperint (64bits). But one thing I'd like to see in future ajp, is the unmarshalling of headers, ie separate reply headers datas from reply datas. It will help in web-server side to works on such headers, determine and alter some of them. Plus it would not easily allow the kind of transports we are using or want to use ( unix sockets, JNI, doors, etc ). yes However using a minimal subset ( we only deal with strings, ints, arrays of string and very simple method calls ) would eliminate most of the confusion and maybe even provide more interoperability. Anyway - ajp13 is here to stay - but I hope it'll be the last binary protocol we invent for jk. ajp13 is perfect for the current works, ie forwarding request/replies (just need to add some headers packets separated from data packets). It's fast, but need to be extended (that's the ajp14 goal), to allow authentification, configuration informations and better error handling between web-server and tomcat servers. May be we could/should add doc on ajp13 format like the one in XDR (RFC 1832) : 1. AJP13 DATA TYPES Each of the sections that follow describes a data type defined in AJP13, shows how it is declared in the language, and includes a graphic illustration of its encoding. For each data type in the language we show a general paradigm declaration. Note that angle brackets ( and ) denote variablelength sequences of data and square brackets ([ and ]) denote fixed-length sequences of data. n, m and r denote integers. For the full language specification and more formal definitions of terms such as identifier and declaration, refer to section 2: The AJP13 Language Specification. For some data types, more specific examples are included. A more extensive example of a data description is in section 3: An Example of an AJP13 Data Description. 1.1 Byte and Unsigned Byte We defines 8-bit (1-byte) numbers called byte and unsigned byte. Ranges are [-128,127] for Byte and [0,255] for Unsigned Byte. They are represented in two's complement notation.
RE: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
did somebody report these patches to apache 1.3 ?
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 02, 2002 2:42 AM
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0
mod_jk.c
costin 02/04/01 16:42:11
Modified:jk/native/apache-2.0 mod_jk.c
Log:
If jk config is broken, report the error - but don't exit.
Revision ChangesPath
1.41 +4 -4
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.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- mod_jk.c 28 Feb 2002 22:45:50 - 1.40
+++ mod_jk.c 2 Apr 2002 00:42:11 - 1.41
@@ -60,7 +60,7 @@
* Description: Apache 2 plugin for Jakarta/Tomcat
*
* Author: Gal Shachor [EMAIL PROTECTED]
*
* Henri Gomez [EMAIL PROTECTED]
*
- * Version: $Revision: 1.40 $
*
+ * Version: $Revision: 1.41 $
*
***
/
/*
@@ -1507,9 +1507,9 @@
/* if(map_alloc(init_map)) { */
if( ! map_read_properties(init_map, conf-worker_file)) {
if( map_size( init_map ) == 0 ) {
-jk_error_exit(APLOG_MARK, APLOG_EMERG, s,
- pconf, No worker file and no
worker options in httpd.conf \n
- use JkWorkerFile or JkWorker to
set workers);
+ap_log_error(APLOG_MARK, APLOG_STARTUP |
APLOG_NOERRNO, APLOG_EMERG,
+ NULL, No worker file and no
worker options in httpd.conf \n
+ use JkWorkerFile to set workers\n);
return;
}
}
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7686] - Issue with pathInfo in complex include() scenarios
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=7686. 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=7686 Issue with pathInfo in complex include() scenarios [EMAIL PROTECTED] changed: What|Removed |Added Severity|Minor |Normal -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0mod_jk.c
I will apply the patch to 1.3.
Are we still maintaining the second copy of jk in 3.3 tree ?
Larry - can we start removing the duplicated util and c code ?
IMHO the j-t-c code ( the 'native1' side ) is as stable as the
one in 3.3, and it would simplify our life to deal with a single
one.
Costin
did somebody report these patches to apache 1.3 ?
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 02, 2002 2:42 AM
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0
mod_jk.c
costin 02/04/01 16:42:11
Modified:jk/native/apache-2.0 mod_jk.c
Log:
If jk config is broken, report the error - but don't exit.
Revision ChangesPath
1.41 +4 -4
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.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- mod_jk.c 28 Feb 2002 22:45:50 - 1.40
+++ mod_jk.c 2 Apr 2002 00:42:11 - 1.41
@@ -60,7 +60,7 @@
* Description: Apache 2 plugin for Jakarta/Tomcat
*
* Author: Gal Shachor [EMAIL PROTECTED]
*
* Henri Gomez [EMAIL PROTECTED]
*
- * Version: $Revision: 1.40 $
*
+ * Version: $Revision: 1.41 $
*
***
/
/*
@@ -1507,9 +1507,9 @@
/* if(map_alloc(init_map)) { */
if( ! map_read_properties(init_map, conf-worker_file)) {
if( map_size( init_map ) == 0 ) {
-jk_error_exit(APLOG_MARK, APLOG_EMERG, s,
- pconf, No worker file and no
worker options in httpd.conf \n
- use JkWorkerFile or JkWorker to
set workers);
+ap_log_error(APLOG_MARK, APLOG_STARTUP |
APLOG_NOERRNO, APLOG_EMERG,
+ NULL, No worker file and no
worker options in httpd.conf \n
+ use JkWorkerFile to set workers\n);
return;
}
}
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/servlet JspServlet.java
glenn 02/04/02 08:10:40
Modified:jasper/src/share/org/apache/jasper CommandLineContext.java
EmbededServletOptions.java
JspCompilationContext.java JspEngineContext.java
Options.java
jasper/src/share/org/apache/jasper/compiler
CommandLineCompiler.java CommentGenerator.java
ExpressionGenerator.java GetPropertyGenerator.java
IncludeGenerator.java JspCompiler.java
ScriptletGenerator.java SetPropertyGenerator.java
TldLocationsCache.java
jasper/src/share/org/apache/jasper/logging Logger.java
jasper/src/share/org/apache/jasper/runtime
BodyContentImpl.java
jasper/src/share/org/apache/jasper/servlet JspServlet.java
Log:
Cleanup Java 1.4 javadoc errors
Revision ChangesPath
1.9 +11 -8
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/CommandLineContext.java
Index: CommandLineContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/CommandLineContext.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- CommandLineContext.java 1 Feb 2002 21:54:21 - 1.8
+++ CommandLineContext.java 2 Apr 2002 16:10:39 - 1.9
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/CommandLineContext.java,v
1.8 2002/02/01 21:54:21 kinman Exp $
- * $Revision: 1.8 $
- * $Date: 2002/02/01 21:54:21 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/CommandLineContext.java,v
1.9 2002/04/02 16:10:39 glenn Exp $
+ * $Revision: 1.9 $
+ * $Date: 2002/04/02 16:10:39 $
*
*
*
@@ -179,7 +179,8 @@
}
/**
- * What is the scratch directory we are generating code into?
+ * The scratch directory to generate code into.
+ *
* FIXME: In some places this is called scratchDir and in some
* other places it is called outputDir.
*/
@@ -188,7 +189,8 @@
}
/**
- * What is the scratch directory we are generating code into?
+ * The scratch directory to generate code into for javac.
+ *
* FIXME: In some places this is called scratchDir and in some
* other places it is called outputDir.
*/
@@ -259,8 +261,9 @@
}
/**
- * What's the content type of this JSP? Content type includes
- * content type and encoding.
+ * The content type of this JSP.
+ *
+ * Content type includes content type and encoding.
*/
public String getContentType() {
return contentType;
@@ -341,7 +344,7 @@
/**
* Gets a resource as a stream, relative to the meanings of this
* context's implementation.
- *@returns a null if the resource cannot be found or represented
+ * @return a null if the resource cannot be found or represented
* as an InputStream.
*/
public java.io.InputStream getResourceAsStream(String res) {
1.8 +17 -12
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/EmbededServletOptions.java
Index: EmbededServletOptions.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/EmbededServletOptions.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- EmbededServletOptions.java3 Dec 2001 15:47:39 - 1.7
+++ EmbededServletOptions.java2 Apr 2002 16:10:39 - 1.8
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/EmbededServletOptions.java,v
1.7 2001/12/03 15:47:39 larryi Exp $
- * $Revision: 1.7 $
- * $Date: 2001/12/03 15:47:39 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/EmbededServletOptions.java,v
1.8 2002/04/02 16:10:39 glenn Exp $
+ * $Revision: 1.8 $
+ * $Date: 2002/04/02 16:10:39 $
*
*
*
@@ -84,23 +84,28 @@
public boolean keepGenerated = true;
/**
- * Do you want support for large files? What this essentially
- * means is that we generated code so that the HTML data in a JSP
- * file is stored separately as opposed to those constant string
- * data being used literally in the generated servlet.
+ * Flag support for large files.
+ *
+ * What this essentially means is that we generated code so that
+ * the HTML data in a JSP file is stored
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/servlet JspServlet.java
glenn 02/04/02 08:11:13
Modified:jasper/src/share/org/apache/jasper Tag: tomcat_40_branch
CommandLineContext.java EmbededServletOptions.java
JspCompilationContext.java JspEngineContext.java
Options.java
jasper/src/share/org/apache/jasper/compiler Tag:
tomcat_40_branch CommandLineCompiler.java
CommentGenerator.java ExpressionGenerator.java
GetPropertyGenerator.java IncludeGenerator.java
JspCompiler.java ScriptletGenerator.java
SetPropertyGenerator.java TldLocationsCache.java
jasper/src/share/org/apache/jasper/logging Tag:
tomcat_40_branch Logger.java
jasper/src/share/org/apache/jasper/runtime Tag:
tomcat_40_branch BodyContentImpl.java
jasper/src/share/org/apache/jasper/servlet Tag:
tomcat_40_branch JspServlet.java
Log:
Cleanup Java 1.4 javadoc errors
Revision ChangesPath
No revision
No revision
1.6.2.2 +10 -7
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/CommandLineContext.java
Index: CommandLineContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/CommandLineContext.java,v
retrieving revision 1.6.2.1
retrieving revision 1.6.2.2
diff -u -r1.6.2.1 -r1.6.2.2
--- CommandLineContext.java 1 Feb 2002 22:20:37 - 1.6.2.1
+++ CommandLineContext.java 2 Apr 2002 16:11:12 - 1.6.2.2
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/CommandLineContext.java,v
1.6.2.1 2002/02/01 22:20:37 kinman Exp $
- * $Revision: 1.6.2.1 $
- * $Date: 2002/02/01 22:20:37 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/CommandLineContext.java,v
1.6.2.2 2002/04/02 16:11:12 glenn Exp $
+ * $Revision: 1.6.2.2 $
+ * $Date: 2002/04/02 16:11:12 $
*
*
*
@@ -179,7 +179,8 @@
}
/**
- * What is the scratch directory we are generating code into?
+ * The scratch directory to generate code into.
+ *
* FIXME: In some places this is called scratchDir and in some
* other places it is called outputDir.
*/
@@ -188,7 +189,8 @@
}
/**
- * What is the scratch directory we are generating code into?
+ * The scratch directory to generate code into for javac.
+ *
* FIXME: In some places this is called scratchDir and in some
* other places it is called outputDir.
*/
@@ -259,8 +261,9 @@
}
/**
- * What's the content type of this JSP? Content type includes
- * content type and encoding.
+ * The content type of this JSP.
+ *
+ * Content type includes content type and encoding.
*/
public String getContentType() {
return contentType;
1.6.2.2 +18 -13
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/EmbededServletOptions.java
Index: EmbededServletOptions.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/EmbededServletOptions.java,v
retrieving revision 1.6.2.1
retrieving revision 1.6.2.2
diff -u -r1.6.2.1 -r1.6.2.2
--- EmbededServletOptions.java30 Nov 2001 22:17:39 - 1.6.2.1
+++ EmbededServletOptions.java2 Apr 2002 16:11:12 - 1.6.2.2
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/EmbededServletOptions.java,v
1.6.2.1 2001/11/30 22:17:39 larryi Exp $
- * $Revision: 1.6.2.1 $
- * $Date: 2001/11/30 22:17:39 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/EmbededServletOptions.java,v
1.6.2.2 2002/04/02 16:11:12 glenn Exp $
+ * $Revision: 1.6.2.2 $
+ * $Date: 2002/04/02 16:11:12 $
*
*
*
@@ -84,24 +84,29 @@
public boolean keepGenerated = true;
/**
- * Do you want support for large files? What this essentially
- * means is that we generated code so that the HTML data in a JSP
- * file is stored separately as opposed to those constant string
- * data being used literally in the generated servlet.
+ * Flag support for large files.
+ *
+ * What this essentially means is that we generated code so that
+ * the HTML data in a JSP file is stored separately as opposed
+ * to those constant string data being used literally in the
DO NOT REPLY [Bug 7682] - Unable to initiate filter properly if Filter class is loaded by Catalina System Classloader
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=7682. 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=7682 Unable to initiate filter properly if Filter class is loaded by Catalina System Classloader [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-04-02 16:28 --- This is not a bug ... it is user error. If you consult the class loader documentation shipped with Tomcat (http://localhost:8080/tomcat-docs/class-loader-howto.html), you will see that the system class loader is *above* the common class loader that contains servlet.jar. Therefore, any classes loaded from the system class loader will not be able to find the servlet API classes, so you won't be able to put filters or servlets there. PLEASE do what the documentation tells you to do! Put your shared classes into the standard directories (lib or common/lib) and you will not have any problems like this. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Mod_jk v/s mod_webapp
James Williamson [EMAIL PROTECTED] wrote: Umm, I posted a bug about this, what about the now infamous 404 (Apache started after Tomcat issue) and the fact that the manager app doesn't work when you try to create a new application due to apache indexing the apps when it starts. The only solution/workaround/kludge being to restart Apache? The other thing being; because mod_webapp ignores the rewrited filename preferring to still look at the raw uri means things like mod_rewrite don't apply (which for many people is an absolute necessity). Check the user lists to witness the frustration. James, your it, you go ahead and fix it... It _WORKS_FOR_ME_ :) Pier Pier, I gladly will (or have done), in fact I've rewritten mod_webapp which resolves the common complains: 1) How can I get Apache to serve static content and Tomcat dynamic content 2) 404 Apache errors 3) Using mod_rewrite and other Apache rewriting mechanisms I take it you're no longer interested in supporting/developing this connector, I really don't mind taking over this responsibility since I could really do with getting these patches tested. Other things I've nearly resolved are Windows compatibility and the mod_ssl issue. Let me know what your thoughts are. Regards, James Williamson www.nameonthe.net -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Issue with pathInfo in complex include() scenarios
Hi, I have discovered a strange behaviour in Tomcat 4.0.3. When using inclusion like requestDispatcher().include() in servlets or jsp:include page=... / in JSP pages, pathInfo parameters don't work as expected, and should probably not be used. This problem appears when you create a servlet that uses the pathInfo part of the request to include another resource from the context, especially a JSP page. Example: You have a context test and a servlet test02 that is called like /test/test02/somefile. Then in test02 you use the pathInfo /somefile to do something like requestDispatcher(/test02/somefile).include(request, response). Now let's say somefile can be some.jsp and test.html, which are pages in the context. If in some.jsp there is a statement jsp:include page=/test02/test.html, and you call /test/test02/some.jsp in the browser, inclusion won't work, and you will even run in an ugly endless inclusion loop. HOWEVER if you change from using pathInfo to old style parameters (like /test/test02?file=some.jsp and jsp:include page=test02?file=test.html it works fine. However, I see no reason for the pathInfo parameter case not working as well. I have set up a bug in the Tomcat Bugzilla database and created a small war archive (http://www.sysmics.de/download/test.war) that illustrates the problem and gives plenty of cases. Please have a look at the /index.html page for an overview. It would be nice if someone could confirm if this is really a bug in Tomcat or not. Best Regards, Alex. --- Alexander Kandzior Alkacon GbR Im Meisengrund 4a 50996 Koeln, DE Tel: +49 (0)2236 963491 Fax: +49 (0)2236 963492 Email: [EMAIL PROTECTED] http://www.alkacon.de -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Mod_jk v/s mod_webapp
James Williamson [EMAIL PROTECTED] wrote: I gladly will (or have done), in fact I've rewritten mod_webapp which resolves the common complains: 1) How can I get Apache to serve static content and Tomcat dynamic content Good... Patch... 2) 404 Apache errors When Tomcat is started _before_ Apache? Good... Patch... 3) Using mod_rewrite and other Apache rewriting mechanisms Great... Patch I take it you're no longer interested in supporting/developing this connector, I really don't mind taking over this responsibility since I could really do with getting these patches tested. I didn't say that... I just said that for what matters to me (meaning, for what I use it, it works allright)... That's far from saying that I'm no longer interested on it... If you have patches, I'll be more than glad to review and incorporate Other things I've nearly resolved are Windows compatibility and the mod_ssl issue. Let me know what your thoughts are. Windows compatibility, did you use the new APR locking mechanism or the old one? Mod_SSL, I don't use it... :) Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7689] New: - Performance problem with Xerces parser
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=7689. 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=7689 Performance problem with Xerces parser Summary: Performance problem with Xerces parser Product: Tomcat 4 Version: 4.0.4 Beta 2 Platform: All OS/Version: All Status: NEW Severity: Minor Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I noticed a severe performance problem with the Xerces parser. Tomcat was taking longer to initialize after I started using Sun XMLPack/Spring02 for XML parsing (includes Xerces 2.0.0). Time went up in ~1,5s for a 1500MHz machine (Windows 2000, JDK 1.4.0, Tomcat 4.0.4-beta2). I investigated it with OptimizeIt! and found that Xerces was spending virtually all of this additional time by calling java.util.zip.InflaterInputStream.read() -- i.e., it's reading data from a compressed file (I guess Tomcat stores XML config files in jars) one byte at a time, instead of using buffered reads, here: XMLEntityManager.RewindableInputStream.read() is reading data without any buffering. This is usually slow in any stream, but particularly slow in the zipped streams. There is a lot of memory management / GC overhead, as the InflaterInputStream.read() method is allocating 600,000 'byte[1]' objs. Back to JDK1.4.0's built-in parser (Crimson), the performance is OK again and the abnormal time and allocation behaviors disappear. Xerces 2.0.1 behaves the same. The root of all evil seems to be places like: org.apache.catalina.startup.ContextConfig.defaultConfig(XMLMapper) which is clearly building an unbuffered FileInputStream and starting to parse the XML data from this stream. Maybe adding a buffered stream to this pipeline wouldn't hurt here, and help a lot when using Xerces. I wonder if the time savings wouldn't be very important for complex Tomcat setups (my config is extremely simple, basically the default Tomcat install). I believe the problem doesn't happen with older parsers like Crimson because these parsers may extract the data from compressed files before parsing it, or maybe they add some buffer streams in the pipeline, while Xerces2 is obviously not doing any; each single byte is read individually and pays the full I/O pipeline overhead. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7690] New: - org.apache.coyote.tomcat4.CoyoteConnector logs all remote IP addresses as 127.0.0.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=7690. 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=7690 org.apache.coyote.tomcat4.CoyoteConnector logs all remote IP addresses as 127.0.0.1 Summary: org.apache.coyote.tomcat4.CoyoteConnector logs all remote IP addresses as 127.0.0.1 Product: Tomcat 4 Version: 4.0.4 Beta 2 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I found that the org.apache.coyote.tomcat4.CoyoteConnector connector logs all remote IP addresses as 127.0.0.1. This behavior is different than that of org.apache.catalina.connector.http.HttpConnector. i.e. if you swap out org.apache.coyote.tomcat4.CoyoteConnector with org.apache.catalina.connector.http.HttpConnector in the below config file, the access log file will contain the client's true IP address. With the Coyote connector it always prints out the localhost address. Server port=8005 shutdown=SHUTDOWN debug=0 Service name=Tomcat-Standalone Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=80 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=443 acceptCount=10 debug=0 connectionTimeout=2/ Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=443 minProcessors=5 maxProcessors=75 enableLookups=true acceptCount=10 debug=0 scheme=https secure=true Factory className=org.apache.catalina.net.SSLServerSocketFactory clientAuth=false protocol=TLS/ /Connector Engine name=Standalone defaultHost=localhost debug=0 Logger className=org.apache.catalina.logger.FileLogger prefix=catalina_log. suffix=.txt timestamp=true/ Host name=localhost debug=0 appBase=webapps unpackWARs=true Valve className=org.apache.catalina.valves.AccessLogValve directory=logs prefix=localhost_access_log. suffix=.txt pattern=common/ Logger className=org.apache.catalina.logger.FileLogger directory=logs prefix=localhost_log. suffix=.txt timestamp=true/ Context path= docBase=ROOT debug=0 reloadable=true/ /Host /Engine /Service /Server -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
ISAPI or IIS ?
I'll start updating the IIS stuff - there are 2 dirs in jk1 - iis and isapi. Which one is used ? From what I can read 'isapi' is newer and seems more generic, is this right ? Do we need both for jk2 ? ( BTW, lots of duplicated code will go away or be moved to the core, and the registry reading stuff should be refactored in a jk_config_registry ) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Mod_jk v/s mod_webapp
On Tue, 2 Apr 2002, GOMEZ Henri wrote: Thank Constin,that really helped. Are there any advantages of WARP over APJ? I mean why would I want to use one over the other? The protocol difference is not significant - both are encoding strings and ints in an efficient ( but non-standard ) way, and use similar protocol semantics. There are few differences at the API level ( i.e. the number and content of the message ), with ajp sending fewer packets, but that's unrelated with the wire protocol. Now, the big question is if there is really any advantage in using WARP/AJP over a standard encoding like XDR. My current opinion is _no_, it was a mistake to invent our own protocol. It is true that AJP and WARP are a bit more 'compact', and that means less data. I highly doubt this plays any real role. Did there is advantages to use warp over ajp ? Hard to tell but the question is elsewhere, advantage of mod_warp over mod_jk. Actually I don't think mod_webapp or mod_jk has any inherent advantage. Yes, jk is more mature and has loadbalancing and more server support - but this can be implemented in webapp (or anything else ) as well. It's just a matter of people - jk had many developers contributing to it, more than any other tomcat component ( AFAIK ). It's also a matter of evolution - mod_jk started by implementing the ajp12 protocol and beeing backward compatible with mod_jserv ( actually a lot of code has been refactored from it ). You can still use mod_jserv with 3.x, and you can use mod_jk with anything from jserv to tomcat4. Throwing it away and starting from scratch was a big mistake IMHO, and making webapp specific to tomcat4.0 / APR / etc was a bigger one. I take a look at XDR (didn't know where to find info about CDR). ajp13 is very similar to XDR, and even less bd/cpu cosuming since XDR want to have 4 bytes (32bits) padded messages whereas ajp13 could use only single byte. Why waste cycle to send unused bytes and waste cycles to decode unused bytes. ;) CDR is part of IIOP, part of Corba spec. Some would argue that 4 bytes alligned structures are more efficient to process on 32-bit processors. For now we'll definitely stay with ajp13, but long term I would rather use a standard encoding and protocol - if the penalty is reasonably small. Yes, it's clear that a full protocol like IIOP/DCOM is something like using a tank to kill a fly, at least in 99% of time operation which is to forward request and replies. NFS is also 99% sending files, and has similar performance needs. I agree IIOP/DCOM are overkill, and the full XDR/RPC is too much. But using a subset may be worth it. May be we could/should add doc on ajp13 format like the one in XDR (RFC 1832) : Great, check it in :-) 1. AJP13 DATA TYPES ... ( but keep it to what we have - i.e. strings/ints/arrays ) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7692] New: - Coyote causes StackOverflowError when HTTP transmission interrupted
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=7692. 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=7692 Coyote causes StackOverflowError when HTTP transmission interrupted Summary: Coyote causes StackOverflowError when HTTP transmission interrupted Product: Tomcat 4 Version: 4.0.4 Beta 2 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Blocker Priority: Other Component: Connector:Coyote AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] It is fairly easy to cause Coyote to enter a loop which ends up in a StackOverflowError and renders it unusable. With a fairly large web page as test content (say around 50kB), use a browser to download it; then refresh repeatedly, before the whole page content has had a chance to get to you. Stack trace is as follows: java.lang.StackOverflowError at org.apache.coyote.http11.filters.ChunkedOutputFilter.doWrite(ChunkedOutputFilter.java:166) at org.apache.coyote.http11.filters.ChunkedOutputFilter.doWrite(ChunkedOutputFilter.java:166) at org.apache.coyote.http11.filters.ChunkedOutputFilter.doWrite(ChunkedOutputFilter.java:166) at org.apache.coyote.http11.filters.ChunkedOutputFilter.doWrite(ChunkedOutputFilter.java:166) (and so on!) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: ISAPI or IIS ?
i think the isapi directory was an experiment that was never followed through on. pretty sure you want to go with the stuff in the iis directory. i don't think you need both. -kevin. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 02, 2002 11:09 AM To: Tomcat Developers List Subject: ISAPI or IIS ? I'll start updating the IIS stuff - there are 2 dirs in jk1 - iis and isapi. Which one is used ? From what I can read 'isapi' is newer and seems more generic, is this right ? Do we need both for jk2 ? ( BTW, lots of duplicated code will go away or be moved to the core, and the registry reading stuff should be refactored in a jk_config_registry ) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
I wouldn't bother maintaining the duplicated source in
jakarta-tomcat.
I have some updates almost ready that use the util source
out of j-t-c rather than its local copy. I was also going
to have it build and include http11 and coyote as well.
I haven't had the time to play much with these. I would,
at minimum, add a disabled Coyote connector on port 8081.
Any recommendations on doing more, such as having it enabled
by default? Is it in good enough shape to use for 8080?
I will likely delete the duplicated util source fairly soon.
The duplicated native1 source a little later. I haven't yet
compared the native1 sources to ensure j-t-c isn't missing
any patches.
Cheers,
Larry
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 02, 2002 10:53 AM
To: Tomcat Developers List
Subject: RE: cvs commit:
jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
I will apply the patch to 1.3.
Are we still maintaining the second copy of jk in 3.3 tree ?
Larry - can we start removing the duplicated util and c code ?
IMHO the j-t-c code ( the 'native1' side ) is as stable as the
one in 3.3, and it would simplify our life to deal with a single
one.
Costin
did somebody report these patches to apache 1.3 ?
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 02, 2002 2:42 AM
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0
mod_jk.c
costin 02/04/01 16:42:11
Modified:jk/native/apache-2.0 mod_jk.c
Log:
If jk config is broken, report the error - but don't exit.
Revision ChangesPath
1.41 +4 -4
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.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- mod_jk.c 28 Feb 2002 22:45:50 - 1.40
+++ mod_jk.c 2 Apr 2002 00:42:11 - 1.41
@@ -60,7 +60,7 @@
* Description: Apache 2 plugin for Jakarta/Tomcat
*
* Author: Gal Shachor [EMAIL PROTECTED]
*
* Henri Gomez [EMAIL PROTECTED]
*
- * Version: $Revision: 1.40 $
*
+ * Version: $Revision: 1.41 $
*
***
/
/*
@@ -1507,9 +1507,9 @@
/* if(map_alloc(init_map)) { */
if( ! map_read_properties(init_map, conf-worker_file)) {
if( map_size( init_map ) == 0 ) {
-jk_error_exit(APLOG_MARK, APLOG_EMERG, s,
- pconf, No worker file and no
worker options in httpd.conf \n
- use JkWorkerFile or JkWorker to
set workers);
+ap_log_error(APLOG_MARK, APLOG_STARTUP |
APLOG_NOERRNO, APLOG_EMERG,
+ NULL, No worker file and no
worker options in httpd.conf \n
+ use JkWorkerFile to set workers\n);
return;
}
}
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To
unsubscribe, e-mail:
mailto:tomcat-dev- [EMAIL PROTECTED]
For
additional commands,
e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:tomcat-dev- [EMAIL PROTECTED]
For
additional commands,
e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
On Tue, 2 Apr 2002, Larry Isaacs wrote: I have some updates almost ready that use the util source out of j-t-c rather than its local copy. I was also going to have it build and include http11 and coyote as well. I haven't had the time to play much with these. I would, at minimum, add a disabled Coyote connector on port 8081. Any recommendations on doing more, such as having it enabled by default? Is it in good enough shape to use for 8080? I think it's in good shape, but there are still changes going on. Jk2/java is also stable ( IMHO ), but there's little benefit for 3.3 to use it - 4.0 would see more improvements. My plan is to make jk2 use the same connector code with coyote, and merge the Request and lower layer ( just the protocol will be different ). This will likely add some unstability, so it can wait. I will likely delete the duplicated util source fairly soon. The duplicated native1 source a little later. I haven't yet compared the native1 sources to ensure j-t-c isn't missing any patches. Thanks. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 Makefile
costin 02/04/02 11:03:12
Modified:jk/native2/server/apache2 Makefile
Log:
Fixed the makefile.
Now you can use gnumake to compile mod_jk.
We support 2 build methods: ant and gnumake.
We may add .dsp if needed ( I prefer to use ant ).
One thing I want to avoid is having 'special' makefiles for each
platform.
Revision ChangesPath
1.2 +49 -19jakarta-tomcat-connectors/jk/native2/server/apache2/Makefile
Index: Makefile
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/Makefile,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- Makefile 31 Dec 2001 19:56:13 - 1.1
+++ Makefile 2 Apr 2002 19:03:12 - 1.2
@@ -1,37 +1,65 @@
-# Gnu makefile is required
+# Gnu makefile and libtool are required
# use -D options to overrides defaults
-
#ifndef APACHE2_HOME
APACHE2_HOME=/opt/apache2
#endif
+JK_DIR := ../..
+BUILD_DIR = ${JK_DIR}/../build/WEB-INF/jk2/apache2
+
+
+# Extract EXTRA_CFLAGS and EXTRA_CPPFLAGS - same flags used during apache2
+# compilation
include ${APACHE2_HOME}/build/config_vars.mk
-# Yes, we use the same properties as ant
+
+# Yes, we use the same properties file as ant
include ../../../build.properties
+LIBTOOL=${APACHE2_HOME}/build/libtool
+
+# It doesn't hurt if we include all
+INCLUDES= -I${JK_DIR}/include \
+ -I${APACHE2_HOME}/include \
+ -I${JAVA_HOME}/include \
+ -I${JAVA_HOME}/include\linux \
+ -I${JAVA_HOME}/include\hp-ux
+
+JK_CFLAGS=-DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 -DHAS_APR -DHAVE_JNI
+
+## Based on rules.mk ##
+ALL_CFLAGS = $(EXTRA_CFLAGS) $(NOTEST_CFLAGS) $(CFLAGS)
+ALL_CPPFLAGS = $(DEFS) $(EXTRA_CPPFLAGS) $(NOTEST_CPPFLAGS) $(CPPFLAGS)
+ALL_LDFLAGS = $(EXTRA_LDFLAGS) $(NOTEST_LDFLAGS) $(LDFLAGS)
+ALL_LIBS = $(EXTRA_LIBS) $(NOTEST_LIBS) $(LIBS)
+ALL_INCLUDES = $(INCLUDES) $(EXTRA_INCLUDES)
+
+# Compile commands
+COMPILE = $(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(ALL_INCLUDES)
+
+SH_COMPILE = $(LIBTOOL) --mode=compile $(COMPILE) -prefer-pic
+MOD_LINK = $(LIBTOOL) --mode=link $(CC) -module -shared $(LT_LDFLAGS)
$(ALL_LDFLAGS)
+
+#
# -- File list creation
# Same behavior as ant - 'all files from a dir'.
# Excludes are not yet implemented.
-JK_DIR := ../..
-BUILD_DIR = ${JK_DIR}/../build/WEB-INF/jk2/apache2
COMMON_C_FILES := $(wildcard ${JK_DIR}/common/*.c )
+JNI_C_FILES := $(wildcard ${JK_DIR}/jni/*.c )
A2_C_FILES := $(wildcard ${JK_DIR}/server/apache2/*.c )
H_FILES := $(wildcard ${JK_DIR}/include/*.h )
COMMON_LO_FILES := $(patsubst ${JK_DIR}/common/%, ${BUILD_DIR}/%, \
$(patsubst %c, %lo, ${COMMON_C_FILES} ))
+JNI_LO_FILES := $(patsubst ${JK_DIR}/jni/%, ${BUILD_DIR}/%, \
+ $(patsubst %c, %lo, ${JNI_C_FILES} ))
A2_LO_FILES := $(patsubst ${JK_DIR}/server/apache2/%, ${BUILD_DIR}/%, \
$(patsubst %c, %lo, ${A2_C_FILES} ))
# -- Compile rules
-JK_CFLAGS=-I${JK_DIR}/include -I${JAVA_HOME}/include \
- ${EXTRA_CPPFLAGS} ${EXTRA_CFLAGS} \
- -I${APACHE2_HOME}/include
-
.PHONY: all
@@ -39,25 +67,27 @@
VPATH=.:../../common
.c.lo:
- ${LIBTOOL} --mode=compile ${CC} ${CFLAGS} -c $ -o $
+ ${SH_COMPILE} -c $ -o $
${BUILD_DIR}/%.lo: ${JK_DIR}/common/%.c
- ${LIBTOOL} --mode=compile ${CC} ${CFLAGS} ${JK_CFLAGS} -c $ -o $@
+ ${SH_COMPILE} -c $ -o $@
+
+${BUILD_DIR}/%.lo: ${JK_DIR}/jni/%.c
+ ${SH_COMPILE} -c $ -o $@
${BUILD_DIR}/%.lo: ${JK_DIR}/server/apache2/%.c
- ${LIBTOOL} --mode=compile ${CC} ${CFLAGS} ${JK_CFLAGS} -c $ -o $@
+ ${SH_COMPILE} -c $ -o $@
# -- Targets
-all: prepare ${APACHE2_HOME}/modules/mod_jk.so
+all: prepare ${BUILD_DIR}/mod_jk2.so ${BUILD_DIR}/jkjni.so
-${APACHE2_HOME}/modules/mod_jk.so: ${BUILD_DIR}/libjk.la
- ( cd ${BUILD_DIR} ; ${LIBTOOL} --mode=finish libjk.la )
- ( cd ${BUILD_DIR} ; ${LIBTOOL} --mode=install --debug cp libjk.la
${APACHE2_HOME}/modules )
+${BUILD_DIR}/jkjni.so: ${JNI_LO_FILES}
+ $(MOD_LINK) -o $@ $^
-${BUILD_DIR}/libjk.la: ${COMMON_LO_FILES} ${A2_LO_FILES}
- ${LIBTOOL} --mode=link ${CC} $ -o $@
+${BUILD_DIR}/mod_jk2.so: ${COMMON_LO_FILES} ${A2_LO_FILES}
+ ${MOD_LINK} -o $@ $^
${COMMON_C_FILES} ${A2_C_FILES}: ${H_FILES}
@@ -65,4 +95,4 @@
mkdir -p ${BUILD_DIR}
clean:
- rm ${BUILD_DIR}/*.lo ${BUILD_DIR}/*.la ${BUILD_DIR}/*.o
\ No newline at end of file
+ rm -rf
cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 jk_logger_apache2.c jk_service_apache2.c
costin 02/04/02 11:03:22
Modified:jk/native2/server/apache2 jk_logger_apache2.c
jk_service_apache2.c
Log:
Small fixes
Revision ChangesPath
1.17 +4 -1
jakarta-tomcat-connectors/jk/native2/server/apache2/jk_logger_apache2.c
Index: jk_logger_apache2.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/jk_logger_apache2.c,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- jk_logger_apache2.c 26 Mar 2002 03:04:54 - 1.16
+++ jk_logger_apache2.c 2 Apr 2002 19:03:22 - 1.17
@@ -141,7 +141,6 @@
/* XXX It'll go away with env and per thread data !! */
buf = (char *) malloc(HUGE_BUFFER_SIZE);
rc = vsprintf(buf, fmt, args);
-free(buf);
#else
rc = vsnprintf(buf, HUGE_BUFFER_SIZE, fmt, args);
#endif
@@ -157,6 +156,10 @@
} else {
ap_log_error( file, line, APLOG_ERR | APLOG_NOERRNO, 0, s, buf);
}
+
+#ifdef NETWARE
+free(buf);
+#endif
return rc ;
}
1.14 +3 -3
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.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- jk_service_apache2.c 24 Mar 2002 19:22:19 - 1.13
+++ jk_service_apache2.c 2 Apr 2002 19:03:22 - 1.14
@@ -59,7 +59,7 @@
* Description: Apache 2 plugin for Jakarta/Tomcat
* Author: Gal Shachor [EMAIL PROTECTED]
* Henri Gomez [EMAIL PROTECTED]
- * Version: $Revision: 1.13 $
+ * Version: $Revision: 1.14 $
*/
#include apu_compat.h
@@ -277,8 +277,8 @@
while( ll 0 ) {
unsigned long toSend=(llCHUNK_SIZE) ? CHUNK_SIZE : ll;
r = ap_rwrite((const char *)bb, toSend, s-ws_private );
-env-l-jkLog(env, env-l, JK_LOG_INFO,
- service.write() %ld (%ld) out of %ld \n,toSend, r,
ll );
+/* env-l-jkLog(env, env-l, JK_LOG_INFO, */
+/* service.write() %ld (%ld) out of %ld \n,toSend, r, ll );
*/
ll-=CHUNK_SIZE;
bb+=CHUNK_SIZE;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_workerEnv.c
costin 02/04/02 11:03:55
Modified:jk/native2/jni jk_channeljni_native.c jk_jni_aprImpl.c
jk/native2/common jk_workerEnv.c
Log:
Small fixes
Revision ChangesPath
1.3 +2 -8 jakarta-tomcat-connectors/jk/native2/jni/jk_channeljni_native.c
Index: jk_channeljni_native.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/jni/jk_channeljni_native.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- jk_channeljni_native.c21 Feb 2002 11:17:17 - 1.2
+++ jk_channeljni_native.c2 Apr 2002 19:03:54 - 1.3
@@ -55,16 +55,10 @@
* *
* = */
-/***
- * Description: JNI callbacks implementation for the JNI in process adapter*
- * Author: Gal Shachor [EMAIL PROTECTED] *
- * Version: $Revision: 1.2 $ *
- ***/
-
-#include jk_jnicb.h
#include jk_service.h
#include jk_pool.h
#include jk_env.h
+#include jni.h
int jk2_channel_jni_javaSendPacket
@@ -73,7 +67,7 @@
/*
-
+ Wrapper for the real JNI channel method
*/
JNIEXPORT jint JNICALL
Java_org_apache_jk_common_ChannelJni_sendPacket
1.7 +1 -1 jakarta-tomcat-connectors/jk/native2/jni/jk_jni_aprImpl.c
Index: jk_jni_aprImpl.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/jni/jk_jni_aprImpl.c,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- jk_jni_aprImpl.c 21 Feb 2002 11:17:17 - 1.6
+++ jk_jni_aprImpl.c 2 Apr 2002 19:03:54 - 1.7
@@ -139,7 +139,7 @@
Java_org_apache_jk_apr_AprImpl_sendSignal(JNIEnv *jniEnv, jobject _jthis, jint
signo,
jlong target)
{
-
+
return 0;
}
1.23 +2 -1 jakarta-tomcat-connectors/jk/native2/common/jk_workerEnv.c
Index: jk_workerEnv.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_workerEnv.c,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- jk_workerEnv.c26 Mar 2002 03:03:43 - 1.22
+++ jk_workerEnv.c2 Apr 2002 19:03:54 - 1.23
@@ -59,7 +59,7 @@
* Description: Workers controller *
* Author: Gal Shachor [EMAIL PROTECTED] *
* Author: Henri Gomez [EMAIL PROTECTED] *
- * Version: $Revision: 1.22 $ *
+ * Version: $Revision: 1.23 $ *
***/
#include jk_env.h
@@ -551,6 +551,7 @@
jkb=env-createBean2(env, wEnv-pool,config, );
env-alias(env, config:, config);
wEnv-config=jkb-object;
+wEnv-config-file = NULL;
wEnv-config-workerEnv = wEnv;
wEnv-config-map = wEnv-initData;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Absolute URI problem
3.3.1 can't have such a problem, since it isn't a HTTP/1.1 server. :) To have a HTTP/1.1 server you need to download the Coyote Beta from http://jakarta.apache.org/builds/jakarta-tomcat-connectors/coyote/release/v1 .0-b4/ Coyote can handle absolute URIs AFAIK. - Original Message - From: Nikolay Petrov [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, April 02, 2002 2:59 AM Subject: Absolute URI problem In http spec: 5.1.2 Request-URI ... To allow for transition to absoluteURIs in all requests in future versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies. ... i think version 3.3.1 ive download has such problem... it does not support absolute URI in requsets... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7681] - Tomcat does not work properly in multithread environment
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=7681. 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=7681 Tomcat does not work properly in multithread environment [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-04-02 19:08 --- This is invalid, because by definition if your object instance is to be shared between two threads, it must be synced (or at least, the init must be synced here). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/apache-1.3 mod_jk.c
costin 02/04/02 11:10:43
Modified:jk/native/apache-1.3 mod_jk.c
Log:
Port the change from apache2 - don't exit on jk error.
Revision ChangesPath
1.24 +5 -4 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.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- mod_jk.c 4 Dec 2001 19:51:01 - 1.23
+++ mod_jk.c 2 Apr 2002 19:10:42 - 1.24
@@ -61,7 +61,7 @@
* Author: Gal Shachor [EMAIL PROTECTED] *
* Dan Milstein [EMAIL PROTECTED]*
* Henri Gomez [EMAIL PROTECTED] *
- * Version: $Revision: 1.23 $ *
+ * Version: $Revision: 1.24 $ *
***/
/*
@@ -1305,9 +1305,9 @@
#endif
/* we add the URI-WORKER MAP since workers using AJP14 will
feed it */
- worker_env.uri_to_worker = conf-uw_map;
+worker_env.uri_to_worker = conf-uw_map;
worker_env.virtual = *; /* for now */
- worker_env.server_name = (char *)ap_get_server_version();
+worker_env.server_name = (char *)ap_get_server_version();
if(wc_open(init_map, worker_env, conf-log)) {
/* we don't need this any more so free it */
map_free(init_map);
@@ -1316,7 +1316,8 @@
}
}
-jk_error_exit(APLOG_MARK, APLOG_EMERG, s, p, Error while opening the workers);
+aplog_error(APLOG_MARK, APLOG_ERR, NULL,
+Error while opening the workers, jk will not work\n);
}
/*
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7692] - Coyote causes StackOverflowError when HTTP transmission interrupted
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=7692. 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=7692 Coyote causes StackOverflowError when HTTP transmission interrupted [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-04-02 19:15 --- This has been fixed already (the code which builds the filter chain is more robust, and avoids loops). *** This bug has been marked as a duplicate of 7534 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7534] - StackOverflowError in ChunkedOutputFilter.doWrite()
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=7534. 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=7534 StackOverflowError in ChunkedOutputFilter.doWrite() [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-04-02 19:15 --- *** Bug 7692 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
- Original Message -
From: [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Tuesday, April 02, 2002 7:52 AM
Subject: RE: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0
mod_jk.c
I will apply the patch to 1.3.
Are we still maintaining the second copy of jk in 3.3 tree ?
Maintaining: no AFAIK.
Larry - can we start removing the duplicated util and c code ?
IMHO the j-t-c code ( the 'native1' side ) is as stable as the
one in 3.3, and it would simplify our life to deal with a single
one.
+1
Costin
did somebody report these patches to apache 1.3 ?
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 02, 2002 2:42 AM
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0
mod_jk.c
costin 02/04/01 16:42:11
Modified:jk/native/apache-2.0 mod_jk.c
Log:
If jk config is broken, report the error - but don't exit.
Revision ChangesPath
1.41 +4 -4
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.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- mod_jk.c 28 Feb 2002 22:45:50 - 1.40
+++ mod_jk.c 2 Apr 2002 00:42:11 - 1.41
@@ -60,7 +60,7 @@
* Description: Apache 2 plugin for Jakarta/Tomcat
*
* Author: Gal Shachor [EMAIL PROTECTED]
*
* Henri Gomez [EMAIL PROTECTED]
*
- * Version: $Revision: 1.40 $
*
+ * Version: $Revision: 1.41 $
*
***
/
/*
@@ -1507,9 +1507,9 @@
/* if(map_alloc(init_map)) { */
if( ! map_read_properties(init_map, conf-worker_file)) {
if( map_size( init_map ) == 0 ) {
-jk_error_exit(APLOG_MARK, APLOG_EMERG, s,
- pconf, No worker file and no
worker options in httpd.conf \n
- use JkWorkerFile or JkWorker to
set workers);
+ap_log_error(APLOG_MARK, APLOG_STARTUP |
APLOG_NOERRNO, APLOG_EMERG,
+ NULL, No worker file and no
worker options in httpd.conf \n
+ use JkWorkerFile to set workers\n);
return;
}
}
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7690] - org.apache.coyote.tomcat4.CoyoteConnector logs all remote IP addresses as 127.0.0.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=7690. 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=7690 org.apache.coyote.tomcat4.CoyoteConnector logs all remote IP addresses as 127.0.0.1 --- Additional Comments From [EMAIL PROTECTED] 2002-04-02 19:30 --- It turns out it is not implemented (although I thought it was). I will port some code from the old HTTP/1.1 connector to fix this. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7008] - facade.HttpServletRequestFacade.getParameter(HttpServletRequestFacade.java:277) -- java.lang.ArrayIndexOutOfBoundsException
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=7008. 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=7008 facade.HttpServletRequestFacade.getParameter(HttpServletRequestFacade.java:277) -- java.lang.ArrayIndexOutOfBoundsException [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Priority|Other |Medium Resolution|FIXED | Version|3.3.1 Release Candidate 1 |3.3.1 Final --- Additional Comments From [EMAIL PROTECTED] 2002-04-02 19:48 --- [JDK] 1.3.1_01[Browser] IE 5.0 [OS] NT4SP6a - java.lang.ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(Native Method) at org.apache.tomcat.util.buf.CharChunk.append(CharChunk.java:271) at org.apache.tomcat.util.http.Parameters.processParameters(Parameters.java:464) at org.apache.tomcat.util.http.Parameters.processParameters(Parameters.java:501) at org.apache.tomcat.util.http.Parameters.handleQueryParameters(Parameters.java:278) at org.apache.tomcat.core.Request.handleQueryParameters(Request.java:456) at org.apache.tomcat.facade.HttpServletRequestFacade.getParameter(HttpServletRequestFacade.java:277) at MyServlet.load(MyServlet.java:120) at MyServlet.processRequest(MyServlet.java:92) at MyServlet.doGet(MyServlet.java:582) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:574) at org.apache.tomcat.core.Handler.invoke(Handler.java:322) at org.apache.tomcat.core.Handler.service(Handler.java:235) at org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:485) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:917) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:833) at org.apache.tomcat.modules.server.Ajp12Interceptor.processConnection(Ajp12Interceptor.java:221) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:494) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:516) at java.lang.Thread.run(Thread.java:484) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Absolute URI problem
3.3.1 can't have such a problem, since it isn't a HTTP/1.1 server. :) Yes indeed ;-) To have a HTTP/1.1 server you need to download the Coyote Beta from http://jakarta.apache.org/builds/jakarta-tomcat-connectors/coyote/release/v1 .0-b4/ Coyote can handle absolute URIs AFAIK. The old HTTP/1.1 connector was also working with abs URLs AFAIK. It wasn't supported in some of the earlier Coyote releases. I plan to make a new Coyote release once I add the support for getRemoteHost/Addr in the TC 4 adapter. Is it ok with you ? Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tyrex exception when using tomcat 4.0.4 (b1 and b2)
I've been using TC4 for a while now. I'm using the MS SQL Server JDBC drivers (and have been for a while), and install them as a resource in TC using the Tyrex JNDI implementation. In TC 4.0.3 everything works fine, however in TC 4.0.4 (b1 and b2) I get exceptions. I'm simply doing the following ctx = new javax.naming.InitialContext(); ds = (javax.sql.DataSource)ctx.lookup(java:comp/env/jdbc/WhitePages); conn = ds.getConnection(); conn.setAutoCommit(false); and I'm getting an exception java.sql.SQLException: Commit not supported in enlisted connections. at tyrex.jdbc.EnlistedConnection.commit(EnlistedConnection.java:154) at com.develop.ewebjava.lab.GetPessimistic.doGet(GetPessimistic.java:60) If I look at the class returned through getConnection I get this hierarchy tyrex.jdbc.EnlistedConnection tyrex.jdbc.AbstractTyrexConnectionImpl java.lang.Object and for the interface hierarchy java.sql.Connection tyrex.tm.EnlistedResource If I run the same code in TC 4.03 then it all works fine and the class hierarchy looks like this com.microsoft.jdbc.sqlserver.SQLServerConnection com.microsoft.jdbc.base.BaseConnection java.lang.Object so it looks like tyrex in 4.0.4 is wrapping the JDBC connection with its own class. There is no change to the tyrex.jar file, however the TyrexDataSourceFactory and TyrexTransactionFactory classes in TC/lib/naming-factory.jar have changed. I've just added this into Bugzilla, although I'm not sure it's a bug (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7693). If anybody could say 'do this' and it would fix the problem I'd be grateful, Kevin Jones Developmentor www.develop.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Jasper: JSP compilation options
I would like to precompile JSP pages (and deploy them as servlets). I am looking for the documentation /comments on the jspc compiler-I have looked through the JspC.java but there are not comment about different compiler options. Any comments, suggestions? Thank you for your help. Leo Asinovsky, office (617) 503-9483 mobile (617)388-6832 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Another proposal for java.ext.dirs
All, I admit my previous method for protecting Tomcat from conflicting system extensions proved to be a bit flawed. However, I still would like to add some protection against these conflicts since this tends to be a difficult to diagnose problem for a lot of new Tomcat users. On the other hand, I don't think we want to prevent knowledgable users from using their installed extensions to support their installation. So, here is what I propose. Note that I am in favor of checking the installed extensions so this proposal should be complimentary to any checking that might be implemented in the Tomcat code: 1. Add the following to each Java execution line in the wrapper scripts: Unix: -Djava.ext.dirs=$JAVA_EXT_DIRS Windows: -Djava.ext.dirs=%JAVA_EXT_DIRS% 2. Add the following lines in setclasspath.bat and setclasspath.sh: Unix: if [ -z $JAVA_EXT_DIRS ]; then echo Disabling installed Java extensions. Set the echo JAVA_EXT_DIRS environment variable to the following value echo to enable installed Java extensions: echo $JAVA_HOME/jre/lib/ext fi Windows: if not %JAVA_EXT_DIRS% == goto gotJavaExtDirs echo Disabling installed Java extensions. Set the echo JAVA_EXT_DIRS environment variable to the following value echo to enable installed Java extensions: echo %JAVA_HOME%\jre\lib\ext :gotJavaExtDirs 3. If the user does not defined JAVA_EXT_DIRS (the default case), the java.ext.dirs property is set to and the above status message is printed. Then, if the user defines JAVA_EXT_DIRS, the existing behavior is enabled. Since new Tomcat users primarily use the installed scripts, this is a good way to protect Tomcat without preventing other custom scripts or launchers from enforcing a different standard. Does this sound like a reasonable approach? It would be nice to have this property setting in the Bootstrap.java class, but unfortunately, you must set the java.endorsed.dirs property when the JVM is started as it is immediately put in the JVM's bootstrap classpath. As Costin mentioned, it's not necessarily a good idea because of the complexity issue; this is similar to what is done to ignore the classpath. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Absolute URI problem
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, April 02, 2002 11:51 AM Subject: Re: Absolute URI problem 3.3.1 can't have such a problem, since it isn't a HTTP/1.1 server. :) Yes indeed ;-) To have a HTTP/1.1 server you need to download the Coyote Beta from http://jakarta.apache.org/builds/jakarta-tomcat-connectors/coyote/release/v1 .0-b4/ Coyote can handle absolute URIs AFAIK. The old HTTP/1.1 connector was also working with abs URLs AFAIK. It wasn't supported in some of the earlier Coyote releases. I plan to make a new Coyote release once I add the support for getRemoteHost/Addr in the TC 4 adapter. Is it ok with you ? Fine with me. I've got a couple of enhancements in tomcat3 pending (e.g. doing the RemoteHost lookup per-connection instead of per-request), but they aren't urgent. And it will probably be a few days before I find the time for them. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] for SimpleSessionStore.java (3.3.1)
Greetings,
The attached patch fixes a bug in the tomcat 3.3.1
org.apache.tomcat.modules.SimpleSessionStore class . In the original,
an attempt is made to cast a java.lang.String into an
org.apache.tomcat.core.ServerSession (line 124) which causes a
ClassCastException.
Angus Cameron
--- SimpleSessionStore.java.origFri Mar 22 18:53:11 2002
+++ SimpleSessionStore.java Tue Apr 2 12:07:58 2002
@@ -121,7 +121,7 @@
// remove all non-serializable objects from session
Enumeration sessionEnum=sM.getSessionIds();
while( sessionEnum.hasMoreElements() ) {
- ServerSession session = (ServerSession)sessionEnum.nextElement();
+ ServerSession session = sM.findSession( (String)sessionEnum.nextElement()
+);
ClassLoader oldLoader=(ClassLoader)ctx.getContainer().
getNote(oldLoader);
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
InvokerServlet wrapper exception handling...
I think I found a bug in InvokerServlet.java.
The current code in the 4.0.3 for some reason removes a wrapper
that it may not have allocated from the context on exception in
wrapper.allocate().(pls, see code/comments below for explanation).
Problem manifests itself, if you have a servlet (let's call it MyServlet)
that is
run via InvokerServlet (i.e. http://host/servlet/myServlet) and you want to
assign some init-params to MyServlet via web.xml. If MyServlet generates
an exception in its init() method it will be removed from the context and
all
of its parameters will be dropped as well. So if invoked again without
restarting the server, the wrapper will be recreated with and empty
parameter
list.
I've tested a simple fix that removes suspect line:
context.removeChild(wrapper);
It works. If my thinking is correct could someone tell me how
to get this change into a CVS tree.
Thanks, KN
public final class InvokerServlet
extends HttpServlet implements ContainerServlet {
...
public void serveRequest(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException
{
...
Wrapper wrapper = null;
...
wrapper = (Wrapper) context.findChild(servletClass);
...
if (wrapper != null) {
// goes here if you put a servlet /servlet section in the
web.xml
...
context.addServletMapping(pattern, wrapper.getName());
} else {
// creation of wrapper if doesn't exists
wrapper = context.createWrapper();
...
context.addChild(wrapper);
context.addServletMapping(pattern, name);
...
}
try
{
instance = wrapper.allocate();
} catch(ServletException e)
{
context.removeServletMapping(pattern); // ok, paired with
addServletMapping above
context.removeChild(wrapper); // PROBLEM! should not be called
if we did not created the wrapper.
}
}
...
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
FW: Unsubscribing
Please could you take me off the Developers mailing list. I have tried every way of unsubscribing from this but your unsubscribe software does not seem to work. Can someone write to me about this and tell me why it is not possible to unsubscribe? Please remove me. NOW. Best regards Mark Hogarth
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler CommandLineCompiler.java
kinman 02/04/02 15:38:13
Modified:jasper/src/share/org/apache/jasper CommandLineContext.java
jasper/src/share/org/apache/jasper/compiler
CommandLineCompiler.java
Log:
- Fixed 5471 and 7488, where jspc generates package names that are not
legal Java names.
I decided not to use the patch submitted by Alain Coetmeur, but to reuse
codes in CommandLineCompiler that mangles class names. But thanks anyway.
Revision ChangesPath
1.10 +16 -17
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/CommandLineContext.java
Index: CommandLineContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/CommandLineContext.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- CommandLineContext.java 2 Apr 2002 16:10:39 - 1.9
+++ CommandLineContext.java 2 Apr 2002 23:38:13 - 1.10
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/CommandLineContext.java,v
1.9 2002/04/02 16:10:39 glenn Exp $
- * $Revision: 1.9 $
- * $Date: 2002/04/02 16:10:39 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/CommandLineContext.java,v
1.10 2002/04/02 23:38:13 kinman Exp $
+ * $Revision: 1.10 $
+ * $Date: 2002/04/02 23:38:13 $
*
*
*
@@ -216,33 +216,32 @@
/**
* The package name for the generated class.
+ * The final package is assembled from the one specified in -p, and
+ * the one derived from the path to jsp file.
*/
public String getServletPackageName() {
-//get the path to the jsp file
-int indexOfSlash = getJspFile().lastIndexOf('/');
+//Get the path to the jsp file. Note that the jspFile, by the
+ //time it gets here, would have been normalized to use '/'
+ //as file separator.
+
+ int indexOfSlash = getJspFile().lastIndexOf('/');
String pathName;
if (indexOfSlash != -1) {
pathName = getJspFile().substring(0, indexOfSlash);
} else {
pathName = /;
}
-//Assemble the package name from the base package name speced on
+
+//Assemble the package name from the base package name specified on
//the command line and the package name derived from the path to
//the jsp file
String packageName = ;
-if (servletPackageName != null !servletPackageName.equals()) {
+if (servletPackageName != null) {
packageName = servletPackageName;
}
-if (packageName.equals()) {
-packageName = pathName.replace('/', '.');
-} else {
-packageName += pathName.replace('/', '.');
-}
-//strip off any leading '.' in the package name
-if (!packageName.equals() packageName.charAt(0) == '.') {
-packageName = packageName.substring(1);
-}
-return packageName;
+packageName += pathName.replace('/', '.');
+
+return CommandLineCompiler.manglePackage(packageName);
}
/**
1.5 +43 -16
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/CommandLineCompiler.java
Index: CommandLineCompiler.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/CommandLineCompiler.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- CommandLineCompiler.java 2 Apr 2002 16:10:39 - 1.4
+++ CommandLineCompiler.java 2 Apr 2002 23:38:13 - 1.5
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/CommandLineCompiler.java,v
1.4 2002/04/02 16:10:39 glenn Exp $
- * $Revision: 1.4 $
- * $Date: 2002/04/02 16:10:39 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/CommandLineCompiler.java,v
1.5 2002/04/02 23:38:13 kinman Exp $
+ * $Revision: 1.5 $
+ * $Date: 2002/04/02 23:38:13 $
*
* The Apache Software License, Version 1.1
*
@@ -61,6 +61,7 @@
import java.io.File;
import java.io.IOException;
+import java.util.StringTokenizer;
import org.apache.jasper.Constants;
import org.apache.jasper.JspCompilationContext;
@@ -86,8 +87,6 @@
jsp = new File(ctxt.getJspFile());
outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();
packageName = ctxt.getServletPackageName();
- if( packageName == null )
- packageName = ;
pkgName = packageName;
setMangler(this);
@@ -163,30
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler CommandLineCompiler.java
kinman 02/04/02 15:50:36
Modified:jasper/src/share/org/apache/jasper Tag: tomcat_40_branch
CommandLineContext.java
jasper/src/share/org/apache/jasper/compiler Tag:
tomcat_40_branch CommandLineCompiler.java
Log:
- Applied fixes from the head branch that fixed 5471 and 7488
Revision ChangesPath
No revision
No revision
1.6.2.3 +17 -18
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/CommandLineContext.java
Index: CommandLineContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/CommandLineContext.java,v
retrieving revision 1.6.2.2
retrieving revision 1.6.2.3
diff -u -r1.6.2.2 -r1.6.2.3
--- CommandLineContext.java 2 Apr 2002 16:11:12 - 1.6.2.2
+++ CommandLineContext.java 2 Apr 2002 23:50:36 - 1.6.2.3
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/CommandLineContext.java,v
1.6.2.2 2002/04/02 16:11:12 glenn Exp $
- * $Revision: 1.6.2.2 $
- * $Date: 2002/04/02 16:11:12 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/CommandLineContext.java,v
1.6.2.3 2002/04/02 23:50:36 kinman Exp $
+ * $Revision: 1.6.2.3 $
+ * $Date: 2002/04/02 23:50:36 $
*
*
*
@@ -216,33 +216,32 @@
/**
* The package name for the generated class.
+ * The final package is assembled from the one specified in -p, and
+ * the one derived from the path to jsp file.
*/
public String getServletPackageName() {
-//get the path to the jsp file
-int indexOfSlash = getJspFile().lastIndexOf('/');
+//Get the path to the jsp file. Note that the jspFile, by the
+ //time it gets here, would have been normalized to use '/'
+ //as file separator.
+
+ int indexOfSlash = getJspFile().lastIndexOf('/');
String pathName;
if (indexOfSlash != -1) {
pathName = getJspFile().substring(0, indexOfSlash);
} else {
pathName = /;
}
-//Assemble the package name from the base package name speced on
+
+//Assemble the package name from the base package name specified on
//the command line and the package name derived from the path to
//the jsp file
String packageName = ;
-if (servletPackageName != null !servletPackageName.equals()) {
+if (servletPackageName != null) {
packageName = servletPackageName;
}
-if (packageName.equals()) {
-packageName = pathName.replace('/', '.');
-} else {
-packageName += pathName.replace('/', '.');
-}
-//strip off any leading '.' in the package name
-if (!packageName.equals() packageName.charAt(0) == '.') {
-packageName = packageName.substring(1);
-}
-return packageName;
+packageName += pathName.replace('/', '.');
+
+return CommandLineCompiler.manglePackage(packageName);
}
/**
@@ -344,7 +343,7 @@
/**
* Gets a resource as a stream, relative to the meanings of this
* context's implementation.
- *@returns a null if the resource cannot be found or represented
+ * @return a null if the resource cannot be found or represented
* as an InputStream.
*/
public java.io.InputStream getResourceAsStream(String res) {
No revision
No revision
1.2.2.3 +43 -16
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/CommandLineCompiler.java
Index: CommandLineCompiler.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/CommandLineCompiler.java,v
retrieving revision 1.2.2.2
retrieving revision 1.2.2.3
diff -u -r1.2.2.2 -r1.2.2.3
--- CommandLineCompiler.java 2 Apr 2002 16:11:12 - 1.2.2.2
+++ CommandLineCompiler.java 2 Apr 2002 23:50:36 - 1.2.2.3
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/CommandLineCompiler.java,v
1.2.2.2 2002/04/02 16:11:12 glenn Exp $
- * $Revision: 1.2.2.2 $
- * $Date: 2002/04/02 16:11:12 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/CommandLineCompiler.java,v
1.2.2.3 2002/04/02 23:50:36 kinman Exp $
+ * $Revision: 1.2.2.3 $
+ * $Date: 2002/04/02 23:50:36 $
*
* The Apache Software License, Version 1.1
*
@@ -61,6 +61,7 @@
import
DO NOT REPLY [Bug 7488] - JspC generates wrong package with -webapp on PC/DOS/NT/Win2k
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=7488. 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=7488 JspC generates wrong package with -webapp on PC/DOS/NT/Win2k --- Additional Comments From [EMAIL PROTECTED] 2002-04-02 23:53 --- Fixed. BTW, class names are already properly mangled. If you can a test case that shows otherwise, reopen the bug. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7488] - JspC generates wrong package with -webapp on PC/DOS/NT/Win2k
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=7488. 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=7488 JspC generates wrong package with -webapp on PC/DOS/NT/Win2k [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5471] - jspc -webapp option is broken due to namespace collisions
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=5471. 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=5471 jspc -webapp option is broken due to namespace collisions [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/session SimpleSessionStore.java
bojan 02/04/02 16:02:14
Modified:src/share/org/apache/tomcat/modules/session
SimpleSessionStore.java
Log:
Slightly modified fix for SimpleSessionStore from Angus Cameron.
Revision ChangesPath
1.19 +1 -1
jakarta-tomcat/src/share/org/apache/tomcat/modules/session/SimpleSessionStore.java
Index: SimpleSessionStore.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/session/SimpleSessionStore.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- SimpleSessionStore.java 1 Sep 2001 00:56:37 - 1.18
+++ SimpleSessionStore.java 3 Apr 2002 00:02:14 - 1.19
@@ -119,7 +119,7 @@
SimpleSessionManager sM = getManager( ctx );
// remove all non-serializable objects from session
- Enumeration sessionEnum=sM.getSessionIds();
+ Enumeration sessionEnum=sM.getSessions();
while( sessionEnum.hasMoreElements() ) {
ServerSession session = (ServerSession)sessionEnum.nextElement();
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] for SimpleSessionStore.java (3.3.1)
Thanks Angus. The fix is now in CVS. Bojan On Wed, 2002-04-03 at 06:39, Angus Cameron wrote: Greetings, The attached patch fixes a bug in the tomcat 3.3.1 org.apache.tomcat.modules.SimpleSessionStore class . In the original, an attempt is made to cast a java.lang.String into an org.apache.tomcat.core.ServerSession (line 124) which causes a ClassCastException. Angus Cameron -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: FW: Unsubscribing
The failure of an organization usually begins with the little things this seems to be a recurring problem that is simple to fix why can't we fix it. Create a web page so people can manually over-ride the obviously flawed Opt - In / but Not out list.. todd http://www.wiserlabz.com collaborative effort to promote Novell and Open Source solutions Mark Hogarth wrote: Please could you take me off the Developers mailing list. I have tried every way of unsubscribing from this but your unsubscribe software does not seem to work. Can someone write to me about this and tell me why it is not possible to unsubscribe? Please remove me. NOW. Best regards Mark Hogarth -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/admin/connector - New directory
manveen 02/04/02 16:21:00 jakarta-tomcat-4.0/webapps/admin/connector - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: FW: Unsubscribing
On Tue, 2 Apr 2002, todd tredeau wrote: Date: Tue, 02 Apr 2002 19:15:52 -0500 From: todd tredeau [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: FW: Unsubscribing The failure of an organization usually begins with the little things this seems to be a recurring problem that is simple to fix why can't we fix it. Create a web page so people can manually over-ride the obviously flawed Opt - In / but Not out list.. The top two reasons for problems (and this covers about 95% of the cases): * The user tries to unsubscribe from a different address than they subscribed with. * The user's mail server mangles the mail headers in such a way that the mailing list software cannot identify the subscription address. The confirmation message that subscribers get when they first sign on includes information about how to unsubscribe in spite of difficulties like the above, by including the address as part of the unsubscribe request. Alas, I guess it's too much to expect users to read the instructions :-). On the other hand, improving the administration of mailing lists is always possible. Concrete suggestions about what to do (and/or volunteering time to make it so) are more likely to cause positive change -- have you got a specific suggestion for what such a page should look like, and (more importantly) what it should functionally do? Or other ways to improve the initial subscription message to make this process more clear? todd http://www.wiserlabz.com collaborative effort to promote Novell and Open Source solutions Craig Mark Hogarth wrote: Please could you take me off the Developers mailing list. I have tried every way of unsubscribing from this but your unsubscribe software does not seem to work. Can someone write to me about this and tell me why it is not possible to unsubscribe? Please remove me. NOW. Best regards Mark Hogarth -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/apache-1.3 mod_jk.c
bojan 02/04/02 16:49:19 Modified:jk/native/apache-1.3 mod_jk.c Log: Use ap_log_error, rather then old aplog_error Revision ChangesPath 1.25 +3 -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.24 retrieving revision 1.25 diff -u -r1.24 -r1.25 --- mod_jk.c 2 Apr 2002 19:10:42 - 1.24 +++ mod_jk.c 3 Apr 2002 00:49:19 - 1.25 @@ -61,7 +61,7 @@ * Author: Gal Shachor [EMAIL PROTECTED] * * Dan Milstein [EMAIL PROTECTED]* * Henri Gomez [EMAIL PROTECTED] * - * Version: $Revision: 1.24 $ * + * Version: $Revision: 1.25 $ * ***/ /* @@ -1316,8 +1316,8 @@ } } -aplog_error(APLOG_MARK, APLOG_ERR, NULL, -Error while opening the workers, jk will not work\n); +ap_log_error(APLOG_MARK, APLOG_ERR, NULL, + Error while opening the workers, jk will not work\n); } /* -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
aplog_error
I've committed a patch to mod_jk.c (apache 1.3) that changes aplog_error into ap_log_error (which I found to be the proper call in Apache 1.3), but since I'm not all that familiar with Apache, I'm not 100% sure I did the right thing. Could some of the mod_jk gurus please verify that this is correct... Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7662] - javax.servlet.ServletContext;
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=7662. 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=7662 javax.servlet.ServletContext; [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-04-03 01:04 --- Because it can be a security risk to allow one web application to access the ServletContext of another, this is a configurable option that defaults to disallowing such requests. To make it work, set the crossContext attribute of the Context element for your webapp to true. See the Server Configuration Reference documentation for more details -- after you start Tomcat, it is available at: http://localhost:8080/tomcat-docs/config/ Please re-open this bug report if you have crossContext properly set to true and are still experiencing this problem. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7700] New: - [PATCH] Anchors don't work when session tracking is handled by URL rewrite
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=7700. 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=7700 [PATCH] Anchors don't work when session tracking is handled by URL rewrite Summary: [PATCH] Anchors don't work when session tracking is handled by URL rewrite Product: Tomcat 4 Version: Nightly Build Platform: All URL: http://www.kare.uklinux.net/pub/tomcat- HttpResponseBase.patch OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Connector:HTTP/1.1 (deprecated) AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When tomcat executes HttpServletRequest.encodeURL(String) it appends query arguments before the URI anchor element. for example: /foo.do;jsessionid=xx#anchor?args=val it should be /foo.do;jsessionid=xxx?args=val#anchor Referenced patch also removes deprecated HttpUtils code and replaces it with other Servlet API functionality. Patch also removes unnecessary imports and cleans up the code a bit. http://www.kare.uklinux.net/pub/tomcat-HttpResponseBase.patch Cheers, [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native/apache-1.3 mod_jk.c
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 3 April 2002 10:49 AM To: [EMAIL PROTECTED] Subject: cvs commit: jakarta-tomcat-connectors/jk/native/apache-1.3 mod_jk.c bojan 02/04/02 16:49:19 Modified:jk/native/apache-1.3 mod_jk.c Log: Use ap_log_error, rather then old aplog_error Revision ChangesPath 1.25 +3 -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.24 retrieving revision 1.25 diff -u -r1.24 -r1.25 --- mod_jk.c 2 Apr 2002 19:10:42 - 1.24 +++ mod_jk.c 3 Apr 2002 00:49:19 - 1.25 @@ -61,7 +61,7 @@ * Author: Gal Shachor [EMAIL PROTECTED] * * Dan Milstein [EMAIL PROTECTED] * * Henri Gomez [EMAIL PROTECTED] * - * Version: $Revision: 1.24 $ * + * Version: $Revision: 1.25 $ * ***/ /* @@ -1316,8 +1316,8 @@ } } -aplog_error(APLOG_MARK, APLOG_ERR, NULL, -Error while opening the workers, jk will not work\n); +ap_log_error(APLOG_MARK, APLOG_ERR, NULL, + Error while opening the workers, jk will not work\n); } /* -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: aplog_error
On 3 Apr 2002, Bojan Smojver wrote: I've committed a patch to mod_jk.c (apache 1.3) that changes aplog_error into ap_log_error (which I found to be the proper call in Apache 1.3), but since I'm not all that familiar with Apache, I'm not 100% sure I did the right thing. Could some of the mod_jk gurus please verify that this is correct... It is correct - I cut and pasted from the wrong place. ( thanks ! ) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: aplog_error
Phew! It always makes me nervous when I have to fix something I don't fully understand. Just curious, when I build mod_jk 1.2 for Apache 1.3 (this is on RedHat Linux), through buildconf.sh, configure [params] amd make, I always have problems with this: --- make[1]: Entering directory `/usr/src/jakarta/jakarta-tomcat-connectors/jk/native/apache-1.3' make[1]: *** No rule to make target `mod_jk.', needed by `libjk.a'. Stop. --- The fix it trivial, but not proper (I just put 'OBJEXT=o' into apache-1.3/Makefile). Is it my environment (libtool, autoconf, automake etc.) doing this or is this a real problem? Bojan On Wed, 2002-04-03 at 11:18, [EMAIL PROTECTED] wrote: On 3 Apr 2002, Bojan Smojver wrote: I've committed a patch to mod_jk.c (apache 1.3) that changes aplog_error into ap_log_error (which I found to be the proper call in Apache 1.3), but since I'm not all that familiar with Apache, I'm not 100% sure I did the right thing. Could some of the mod_jk gurus please verify that this is correct... It is correct - I cut and pasted from the wrong place. ( thanks ! ) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7700] - [PATCH] Anchors don't work when session tracking is handled by URL rewrite
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=7700. 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=7700 [PATCH] Anchors don't work when session tracking is handled by URL rewrite --- Additional Comments From [EMAIL PROTECTED] 2002-04-03 01:31 --- Same patch seems to be applicable for org.apache.coyote.tomcat4.CoyoteResponse. Cheers, [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7702] New: - [PATCH] Speed up Tomcat a tiny bit
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=7702. 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=7702 [PATCH] Speed up Tomcat a tiny bit Summary: [PATCH] Speed up Tomcat a tiny bit Product: Tomcat 4 Version: Nightly Build Platform: All URL: http://www.kare.uklinux.net/pub/tomcat-speed.patch OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Referenced patch replaces array copy for-loops with System.arraycopy(). This should be faster as it doesn't do any array bounds checking. And it also replaces java.util.List Iterations with a for-loop that accesses List instance with index number (List.get(int)) and thus avoids the overhead of Iterator instance. This patch is not a major speed improvement, but should speed up things a tiny bit... Cheers, [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Classloader issue with Embedded tomcat and WAR deployment
I figured it out. For the curious, I was specifying a loader for my root context, but that wasn't being propogated to any WAR files, only to servlets explicitly added to the root context at startup time. I had to set the parent classloader on the host which was loading the WAR files. Rich -Original Message- From: Richard Unger Sent: Monday, April 01, 2002 4:36 PM To: '[EMAIL PROTECTED]' Subject: Classloader issue with Embedded tomcat and WAR deployment I'm making a tomcat 4.0.3 module for netbeans, and I'm running into an odd problem with the org.apache.catalina.loader.WebappClassLoader. I'm utilizing the Embedded class to build my server, and I'm using the HostConfig mechanism for rolling in WAR files. I have no trouble loading individual servlets, but when I start the server with a WAR file in place, I get a NoClassDefFoundError: javax/servlet/http/HttpServlet. The error is masked by a catch( Throwable t) clause in HostConfig::deployApps, but when I explicitly print the stack trace, it looks like: java.lang.NoClassDefFoundError: javax/servlet/http/HttpServlet at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:493) at java.security.SecureClassLoader.defineClass(SecureClassLoader. java:111) at org.apache.catalina.loader.WebappClassLoader.findClassInternal (WebappClassLoader.java:1631) at org.apache.catalina.loader.WebappClassLoader.findClass(WebappC lassLoader.java:926) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappC lassLoader.java:1360) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappC lassLoader.java:1243) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardW rapper.java:865) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper. java:808) at org.apache.catalina.core.StandardContext.loadOnStartup(Standar dContext.java:3266) at org.apache.catalina.core.StandardContext.start(StandardContext .java:3395) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase. java:785) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:454) at org.apache.catalina.core.StandardHost.install(StandardHost.java:723) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:331) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:398) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConf ig.java:232) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(L ifecycleSupport.java:156) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1131) at org.apache.catalina.core.StandardHost.start(StandardHost.java:614) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:343) at org.apache.catalina.startup.Embedded.start(Embedded.java:957) at org.netbeans.modules.httpserver.TomcatServer.start(Unknown Source) at org.netbeans.modules.httpserver.HttpServerModule$1.run(Unknown Source) Delving into StandardWrapper line 865, I see the classloader attempting to load the servlet residing in the WAR file. This servlet extends HttpServlet, and that's where my error is coming from. However, if I stick in a line: classLoader.loadClass(javax.servlet.http.HttpServlet) before line 865, everything works fine. I'm guessing this is because HttpServlet gets loaded in an earlier run of StandardWrapper::loadServlet() (like when the DefaultServlet gets loaded). Must I explicitly set the parent classloader for the org.apache.catalina.loader.WebappLoader? How? Rich -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7700] - [PATCH] Anchors don't work when session tracking is handled by URL rewrite
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=7700. 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=7700 [PATCH] Anchors don't work when session tracking is handled by URL rewrite [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-04-03 05:34 --- /foo.do;jsessionid=xx#anchor?args=val is correct. /foo.do;jsessionid=xxx?args=val#anchor makes no sense at all. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7681] - Tomcat does not work properly in multithread environment
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=7681. 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=7681 Tomcat does not work properly in multithread environment --- Additional Comments From [EMAIL PROTECTED] 2002-04-03 06:46 --- Of course, I agree. But it is not the case: my bean is a session bean, so the object should be created only once per user session, while now, its constructor often gets called twice per one user session (two objects are created, and the second one replaces the first one in session object. That means, any state preserved by a page in first frame will then be discarded by a second frame, that also created such object. Synchronization won't help unless I made all bean methods static synchronized, but then I won't need any bean. (Actually, I do have my methods synchronized; but I see no reason why session beans should be created more than once per user session). Also, as I said, in generated servlet there is a synchronized (session) block - and session object is always different (see HttpRequestFacade.getSession method - it always created a new StandardSessionFacade), so there is no use to make that block synchronized, and synchronization pays significant role in performance decrease... I'm leaving the state of this bug as it is - if You accept the explanation, please reopen it. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tyrex exception when using tomcat 4.0.4 (b1 and b2)
Hi! I experienced the same problem. The matter is that TC 4.0.4bX has slightly modified org.apache.naming.factory.TyrexDataSourceFactory class. Old one returned EnabledDataSource (didn't work properly either), new one - ServerDataSource. I tried to complain to Tyrex guys, but seems they are retired (a year ago at least). That's why I switched to DBCP and happy now. Kevin Jones wrote: I've been using TC4 for a while now. I'm using the MS SQL Server JDBC drivers (and have been for a while), and install them as a resource in TC using the Tyrex JNDI implementation. In TC 4.0.3 everything works fine, however in TC 4.0.4 (b1 and b2) I get exceptions. I'm simply doing the following ctx = new javax.naming.InitialContext(); ds = (javax.sql.DataSource)ctx.lookup(java:comp/env/jdbc/WhitePages); conn = ds.getConnection(); conn.setAutoCommit(false); and I'm getting an exception java.sql.SQLException: Commit not supported in enlisted connections. at tyrex.jdbc.EnlistedConnection.commit(EnlistedConnection.java:154) at com.develop.ewebjava.lab.GetPessimistic.doGet(GetPessimistic.java:60) If I look at the class returned through getConnection I get this hierarchy tyrex.jdbc.EnlistedConnection tyrex.jdbc.AbstractTyrexConnectionImpl java.lang.Object and for the interface hierarchy java.sql.Connection tyrex.tm.EnlistedResource If I run the same code in TC 4.03 then it all works fine and the class hierarchy looks like this com.microsoft.jdbc.sqlserver.SQLServerConnection com.microsoft.jdbc.base.BaseConnection java.lang.Object so it looks like tyrex in 4.0.4 is wrapping the JDBC connection with its own class. There is no change to the tyrex.jar file, however the TyrexDataSourceFactory and TyrexTransactionFactory classes in TC/lib/naming-factory.jar have changed. I've just added this into Bugzilla, although I'm not sure it's a bug (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7693). If anybody could say 'do this' and it would fix the problem I'd be grateful, Kevin Jones Developmentor www.develop.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Lev AssinovskyPeterlink Web ProgrammerSt. Petersburg, Russia Tel/Fax: +7 812 3275343 197022 ul.Chapigina 7Á E-mail: [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Unsubscribing
todd tredeau [EMAIL PROTECTED] wrote: The failure of an organization usually begins with the little things this seems to be a recurring problem that is simple to fix why can't we fix it. Create a web page so people can manually over-ride the obviously flawed Opt - In / but Not out list.. You got time to do it? Then volunteer... Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
