Re: CVS problem
I mucked with the CVS repository ( had no choice ) and fixed my CVS problems. I moved the SSIServlet.java,v file ( which had no java source ) into /tmp. This fixed the problems I had with core dumping when trying to check out old versions of jakarta-tomcat-4.0. Now I'll work on combining the two SSI implementations together. -Dan Dan Sandberg wrote: How? I'm not running any CVS commands. You need admin access to delete the #cvs.wfl or #cvs.lock files, which I don't have. If there's a way for me to fix this, please let me know. -Dan Remy Maucherat wrote: Trying to tag the CVS with 4.1.7 ... cvs server: [03:59:27] waiting for dsandberg's lock in /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets cvs server: [04:00:00] waiting for dsandberg's lock in /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets Dan, can you fix it ASAP ? 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10674] New: - Unable to get POST data from request
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=10674. 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=10674 Unable to get POST data from request Summary: Unable to get POST data from request Product: Tomcat 4 Version: 4.1.3 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote HTTP/1.1 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The POST data cannot be got from the request if the content type is application/x-www-form-urlencoded;charset=utf-8. From CoyoteRequest.java, the POST data will only be parsed if the content type is exactly the same as application/x-www-form-urlencoded. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
jar_cache files
Nobody has an idea about this. how are used jar_cache* files in Tomcat ?? -Message d'origine- De : Arnaud HERITIER [mailto:[EMAIL PROTECTED]] Envoye : mercredi 10 juillet 2002 16:19 A : 'Tomcat Users List' Cc : Tomcat-Dev (E-mail) Objet : RE: jar_cache files Under AIX 4.3.3, when I do a rm -rf /tmp/jar_cache* the command don't failed. It is normal ??? This files aren't used after bootstrap of webapps ??? Arnaud -Message d'origine- De : Mark Prins [mailto:[EMAIL PROTECTED]] Envoye : mercredi 10 juillet 2002 15:27 A : 'Tomcat Users List' Objet : RE: jar_cache files tomcat keeps a lock on all the current jar_cache files; if you write a batch file that runs once a day that removes them the directory shouldn't clutter with outdated cache files. a batchfile with something like: cd \temp del /F /Q jar_cache*.tmp this will generate error messages for files that are in use, but you don't want to delete those anyway.. Mark -Original Message- From: Arnaud HERITIER [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 10, 2002 2:07 PM To: 'Tomcat Users List' Subject: RE: jar_cache files But if there are several tomcat servers on the same server, how can I recognize which jar_cache file belong to which server ??? -Message d'origine- De : Skondras P. [mailto:[EMAIL PROTECTED]] Envoye : mercredi 10 juillet 2002 13:55 A : Tomcat Users List Objet : Re: jar_cache files You can delete them after stoping tomcat and before starting it again This is at least what i do. Arnaud HERITIER wrote: Hello. For a customer I developped a webapp which will be deployed under Tomcat 4.0.1 (Because of the validation cycle which can't allow me to upgrade the release easily). When TC starts, it creates in the temp directory several jar_cache* files. I suppose that it represents all jars in all webapps. But this files are never deleted :-( The production team ask me if this files can be deleted ?? And if yes, when ??? Are this jars used only at the boot time or during all the life of TC ?? Thanks. Arnaud HERITIER EAI Consulting Sopra Group T?l. : +33 (0)1 53 33 44 74 email : [EMAIL PROTECTED] Ce message est exclusivement destin? aux personnes dont le nom figure ci-dessus. Il peut contenir des informations confidentielles dont la divulgation est ? ce titre rigoureusement interdite. Dans l'hypoth?se o? vous avez re?u ce message par erreur, merci de le renvoyer ? l'adresse e-mail ci-dessus et de d?truire toute copie. This message may contain confidential and proprietary material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- 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 10671] - Major issues with jsp:param in jsp:include and jsp:forward
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10671. 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=10671 Major issues with jsp:param in jsp:include and jsp:forward [EMAIL PROTECTED] changed: What|Removed |Added Component|Unknown |Jasper 2 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4 CoyoteRequest.java
remm2002/07/11 01:33:23
Modified:coyote/src/java/org/apache/coyote/tomcat4 CoyoteRequest.java
Log:
- Port code from the old HTTP connector: parse out ;charset=
- Should fix bug 10674.
Revision ChangesPath
1.25 +14 -6
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteRequest.java
Index: CoyoteRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteRequest.java,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- CoyoteRequest.java3 Jul 2002 17:43:24 - 1.24
+++ CoyoteRequest.java11 Jul 2002 08:33:22 - 1.25
@@ -1925,7 +1925,16 @@
if (!getMethod().equalsIgnoreCase(POST))
return;
-if (!(application/x-www-form-urlencoded.equals(getContentType(
+String contentType = getContentType();
+if (contentType == null)
+contentType = ;
+int semicolon = contentType.indexOf(';');
+if (semicolon = 0) {
+contentType = contentType.substring(0, semicolon).trim();
+} else {
+contentType = contentType.trim();
+}
+if (!(application/x-www-form-urlencoded.equals(contentType)))
return;
int len = getContentLength();
@@ -1943,7 +1952,6 @@
readPostBody(formData, len);
parameters.processParameters(formData, 0, len);
} catch (Throwable t) {
-t.printStackTrace(); // TEMP
; // Ignore
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10674] - Unable to get POST data from request
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=10674. 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=10674 Unable to get POST data from request [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-07-11 08:37 --- This should be fixed in CVS (the code to parse out the ;charset was missing in Coyote). 4.1.8 will have the fix. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: webapp- who handles static content: Tomcat or Apache (* OFF TOPIC *)
Interesting idea to split the static content onto a different server. Does anyone know how a browser like IE handles this kind of situation, I know that with HTTP 1.1 the server will leave the connection open for further requests so that images/styles, etc should be able to go through the same connection as the original call. Will IE open a single connection to images.foo.com to retrieve all the images on a page, or will it open a new connection per image. What happens with an SSL based page, will I get annoying messages because I am getting insecure content. I assume I will have to put an SSL certificate on the image server as well. Regards. - Original Message - From: Pier Fumagalli [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, July 11, 2002 2:00 AM Subject: Re: webapp- who handles static content: Tomcat or Apache Pier Fumagalli [EMAIL PROTECTED] wrote: Cute... You can have some... Visit your local tobacconist. Anyhow, you'll see my reasoning when the article gets published. Few other folks having the same problems we do (very high loads + servlets) don't have the same problem as well It's actually way easier and better (in terms of what solutions it allows you to have), to move them away entirely from the web application at all... People doing GIFs HTMLs and CCS are (in our case), completely separate from JSP/Servlet writers, so I don't even need to give them acceess to the web application files... They can't overwrite or even touch any of the dynamic content... Finally the article (and together with it its full response) is up... http://www.onjava.com/ http://www.onjava.com/pub/a/onjava/2002/07/17/web.html Page one, at the bottom. Pier -- [Perl] combines all the worst aspects of C and Lisp: a billion of different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco] -- 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 gump.xml
remm2002/07/11 02:59:07 Modified:.gump.xml Log: - Add commons-logging-api.jar property (it will also need to be added in the commons-logging project definition). Revision ChangesPath 1.4 +2 -0 jakarta-tomcat-4.0/gump.xml Index: gump.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/gump.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- gump.xml 11 Jun 2002 19:45:34 - 1.3 +++ gump.xml 11 Jul 2002 09:59:07 - 1.4 @@ -77,6 +77,8 @@ depend property=commons-pool.jar project=commons-pool/ depend property=commons-logging.jar project=commons-logging runtime=true/ + depend property=commons-logging-api.jar project=commons-logging +runtime=true/ /ant depend project=jakarta-ant/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10621] - Admin webapp: adding new contexts requires restart
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=10621. 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=10621 Admin webapp: adding new contexts requires restart [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2002-07-11 10:10 --- This report is really incomplete. I think this works for me; if there's a problem, you can check the state of your context with the manager webapp, and by looking at the logs. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[5.0] [VOTE] New branches and repositories
New repositories are needed to host the new Tomcat 5.0 code, including the new servlet JSP API, Catalina, Coyote 2.0 and protocol handlers, Jasper. A) For the Servlet JSP API, I think a new separate repository is needed (jakarta-servletapi-5 to follow the current conventions). Or we could put it in the HEAD of jakarta-servletapi (and the old 2.1 API goes in a branch). B) For Catalina, we could either use a new repository, named either j-t-catalina or j-t-5.0, or use the HEAD of j-t-4.0 (the current code would then be branched). C) Coyote 2.0 will be in the HEAD of j-t-c. Coyote 1.0 will be put in a separate branch. D) Tomcat specific glue code (if some is needed) would go in either j-t-5.0, the HEAD of j-t-4.0, or the HEAD of j-t. E) Jasper 2+ goes in the HEAD of j-t-j. The current Jasper 2 will go in a branch. ballot A) Servlet 2.4 JSP 2.0 API 1. [ ] Use new jakarta-servletapi-5 2. [ ] Use the HEAD of jakarta-servletapi 3. [ ] Other: B) Catalina 2.0 1. [ ] Use new jakarta-tomcat-catalina 2. [ ] Use new jakarta-tomcat-5.0 3. [ ] Use the HEAD of jakarta-tomcat-4.0 4. [ ] Other: C) Coyote 2.0 1. [ ] Yes, use the HEAD of jakarta-tomcat-connectors 2. [ ] No, use: D) Tomcat 5.0 1. [ ] Use new jakarta-tomcat-5.0 2. [ ] Use the HEAD of jakarta-tomcat-4.0 3. [ ] Use the HEAD of jakarta-tomcat 4. [ ] Other: E) Jasper 2.0 1. [ ] Yes, use the HEAD of jakarta-tomcat-jasper 2. [ ] No, use: /ballot Thanks for voting ;-) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [VOTE] New branches and repositories
ballot A) Servlet 2.4 JSP 2.0 API 1. [X] Use new jakarta-servletapi-5 2. [ ] Use the HEAD of jakarta-servletapi 3. [ ] Other: B) Catalina 2.0 1. [X] Use new jakarta-tomcat-catalina 2. [ ] Use new jakarta-tomcat-5.0 3. [ ] Use the HEAD of jakarta-tomcat-4.0 4. [ ] Other: C) Coyote 2.0 1. [X] Yes, use the HEAD of jakarta-tomcat-connectors 2. [ ] No, use: D) Tomcat 5.0 1. [ ] Use new jakarta-tomcat-5.0 2. [ ] Use the HEAD of jakarta-tomcat-4.0 3. [X] Use the HEAD of jakarta-tomcat 4. [ ] Other: E) Jasper 2.0 1. [X] Yes, use the HEAD of jakarta-tomcat-jasper 2. [ ] No, use: /ballot Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [VOTE] New branches and repositories
Remy Maucherat wrote: New repositories are needed to host the new Tomcat 5.0 code, including the new servlet JSP API, Catalina, Coyote 2.0 and protocol handlers, Jasper. A) For the Servlet JSP API, I think a new separate repository is needed (jakarta-servletapi-5 to follow the current conventions). Or we could put it in the HEAD of jakarta-servletapi (and the old 2.1 API goes in a branch). B) For Catalina, we could either use a new repository, named either j-t-catalina or j-t-5.0, or use the HEAD of j-t-4.0 (the current code would then be branched). C) Coyote 2.0 will be in the HEAD of j-t-c. Coyote 1.0 will be put in a separate branch. D) Tomcat specific glue code (if some is needed) would go in either j-t-5.0, the HEAD of j-t-4.0, or the HEAD of j-t. E) Jasper 2+ goes in the HEAD of j-t-j. The current Jasper 2 will go in a branch. ballot A) Servlet 2.4 JSP 2.0 API 1. [X] Use new jakarta-servletapi-5 2. [ ] Use the HEAD of jakarta-servletapi 3. [ ] Other: B) Catalina 2.0 1. [ ] Use new jakarta-tomcat-catalina 2. [X] Use new jakarta-tomcat-5.0 3. [ ] Use the HEAD of jakarta-tomcat-4.0 4. [ ] Other: C) Coyote 2.0 1. [X] Yes, use the HEAD of jakarta-tomcat-connectors 2. [ ] No, use: D) Tomcat 5.0 1. [X] Use new jakarta-tomcat-5.0 2. [ ] Use the HEAD of jakarta-tomcat-4.0 3. [ ] Use the HEAD of jakarta-tomcat 4. [ ] Other: E) Jasper 2.0 1. [X] Yes, use the HEAD of jakarta-tomcat-jasper 2. [ ] No, use: /ballot Thanks for voting ;-) 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]
Re: webapp- who handles static content: Tomcat or Apache (* OFFTOPIC *)
Arshad Mahmood [EMAIL PROTECTED] wrote: Interesting idea to split the static content onto a different server. Does anyone know how a browser like IE handles this kind of situation, I know that with HTTP 1.1 the server will leave the connection open for further requests so that images/styles, etc should be able to go through the same connection as the original call. Will IE open a single connection to images.foo.com to retrieve all the images on a page, or will it open a new connection per image. What happens with an SSL based page, will I get annoying messages because I am getting insecure content. I assume I will have to put an SSL certificate on the image server as well. When using SSL, or if you want to use keepalive fully, the optimal thing to do for convenience would be to do what we used to do @ VNU 5 months ago, the application is somewhere, and images/static are under a certain path (for instance in our case /v6_) . The browser can reuse the connection, and the server can use the same certificate for both... The problem we're solving by splitting the servers is splitting the load as well. As you might know, on our www server, when we separated out images the load went from an average of 3.50 daily, to 1.50, and the images server is just an very very basic and skinny HTTPd 2.0 with Worker... Far less heavy than the full web server on the main www... :) Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [VOTE] New branches and repositories
Quoting Remy Maucherat [EMAIL PROTECTED]: ballot A) Servlet 2.4 JSP 2.0 API 1. [X] Use new jakarta-servletapi-5 2. [ ] Use the HEAD of jakarta-servletapi 3. [ ] Other: B) Catalina 2.0 1. [X] Use new jakarta-tomcat-catalina 2. [ ] Use new jakarta-tomcat-5.0 3. [ ] Use the HEAD of jakarta-tomcat-4.0 4. [ ] Other: C) Coyote 2.0 1. [X] Yes, use the HEAD of jakarta-tomcat-connectors 2. [ ] No, use: D) Tomcat 5.0 1. [X] Use new jakarta-tomcat-5.0 2. [ ] Use the HEAD of jakarta-tomcat-4.0 3. [ ] Use the HEAD of jakarta-tomcat 4. [ ] Other: E) Jasper 2.0 1. [X] Yes, use the HEAD of jakarta-tomcat-jasper 2. [ ] No, use: /ballot Which make Tomcat 5.0 a glue for edge packages (I feel it more modular) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_jni.c
mturk 2002/07/11 04:38:13
Modified:jk/native2/common jk_worker_jni.c
Log:
Introduce the worker.jni hooks.
There are 4 types of hooks right now:
1. onStartup : executes on load, redirect i/o and registeres natives
2. onInit : executes on load
3. onClose : executes on shutdown
4. onShutdown : executes on shutdown and unloads VM
All the hooks executes the java class=xxx but in the different process stages
of the connector.
Revision ChangesPath
1.26 +105 -70 jakarta-tomcat-connectors/jk/native2/common/jk_worker_jni.c
Index: jk_worker_jni.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_worker_jni.c,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- jk_worker_jni.c 10 Jul 2002 17:41:40 - 1.25
+++ jk_worker_jni.c 11 Jul 2002 11:38:12 - 1.26
@@ -84,6 +84,13 @@
#define JAVA_BRIDGE_CLASS_NAME (org/apache/jk/apr/TomcatStarter)
#define JAVA_BRIDGE_CLASS_APRI (org/apache/jk/apr/AprImpl)
+/* The class will be executed when the connector is started */
+#define JK2_WORKER_HOOK_STARTUP 0
+#define JK2_WORKER_HOOK_INIT1
+#define JK2_WORKER_HOOK_CLOSE 2
+/* The class will be executed when the connector is about to be destroyed */
+#define JK2_WORKER_HOOK_SHUTDOWN3
+
struct jni_worker_data {
jclass jk_java_bridge_class;
jclass jk_java_bridge_apri_class;
@@ -97,6 +104,7 @@
char **classNameOptions;
char **args;
int nArgs;
+int hook;
};
typedef struct jni_worker_data jni_worker_data_t;
@@ -112,30 +120,32 @@
main,
([Ljava/lang/String;)V);
if(!p-jk_main_method) {
- env-l-jkLog(env, env-l, JK_LOG_EMERG, Can't find main(String [])\n);
- return JK_ERR;
+env-l-jkLog(env, env-l, JK_LOG_EMERG, Can't find main(String [])\n);
+return JK_ERR;
}
-
-p-jk_setout_method =
+/* Only the startup hook can redirect the stdout/stderr */
+if (p-hook == JK2_WORKER_HOOK_STARTUP) {
+p-jk_setout_method =
(*jniEnv)-GetStaticMethodID(jniEnv, p-jk_java_bridge_apri_class,
setOut,
(Ljava/lang/String;)V);
-if(!p-jk_setout_method) {
- env-l-jkLog(env, env-l, JK_LOG_EMERG, Can't find
AprImpl.setOut(String));
- return JK_ERR;
-}
+if(!p-jk_setout_method) {
+env-l-jkLog(env, env-l, JK_LOG_EMERG,
+ Can't find AprImpl.setOut(String));
+return JK_ERR;
+}
-p-jk_seterr_method =
+p-jk_seterr_method =
(*jniEnv)-GetStaticMethodID(jniEnv, p-jk_java_bridge_apri_class,
setErr,
(Ljava/lang/String;)V);
-if(!p-jk_seterr_method) {
- env-l-jkLog(env, env-l, JK_LOG_EMERG, Can't find
AprImpl.setErr(String)\n);
- return JK_ERR;
+if(!p-jk_seterr_method) {
+env-l-jkLog(env, env-l, JK_LOG_EMERG,
+ Can't find AprImpl.setErr(String)\n);
+return JK_ERR;
+}
}
-
-
return JK_OK;
}
@@ -154,7 +164,7 @@
char *value=valueP;
jni_worker_data_t *jniWorker;
int mem_config = 0;
-
+
if(! _this || ! _this-worker_private) {
env-l-jkLog(env, env-l, JK_LOG_ERROR,
In validate, assert failed - invalid parameters\n);
@@ -162,6 +172,16 @@
}
jniWorker = _this-worker_private;
+if (strcmp(mbean-name, worker.jni:onStartup) == 0)
+jniWorker-hook = JK2_WORKER_HOOK_STARTUP;
+else if (strncmp(mbean-name, worker.jni:onInit,
+sizeof(worker.jni:onInit) -1)== 0)
+jniWorker-hook = JK2_WORKER_HOOK_INIT;
+else if (strncmp(mbean-name, worker.jni:onClose,
+sizeof(worker.jni:onClose) -1)== 0)
+jniWorker-hook = JK2_WORKER_HOOK_CLOSE;
+else if (strcmp(mbean-name, worker.jni:onShutdown) == 0)
+jniWorker-hook = JK2_WORKER_HOOK_SHUTDOWN;
if( strcmp( name, stdout )==0 ) {
jniWorker-stdout_name = value;
@@ -178,10 +198,6 @@
} else {
jniWorker-className = value;
}
-/* XXX Instead of ARG=start split to something like:
- * startup=start
- * shutdown=stop
- */
} else if( strcmp( name, ARG )==0 ) {
jniWorker-args[jniWorker-nArgs]=value;
jniWorker-nArgs++;
@@ -273,9 +289,9 @@
Loaded %s\n, jniWorker-className);
/* Instead of loading mod_jk2.so from java, use the JNI RegisterGlobals.
- XXX Need
cvs commit: jakarta-tomcat-connectors/jk/conf workers2.properties
mturk 2002/07/11 04:40:48
Modified:jk/conf workers2.properties
Log:
Introduce the worker.jni hooks.
worker.jni:onStartup executes on load
worker.jni:onInit executes on load
can be followed by extra chars (worker.jni.onInit123)
worker.jni:onClose can be followed by extra chars
worker.jni:onShutdown executes on unload and destroys VM
Revision ChangesPath
1.15 +8 -2 jakarta-tomcat-connectors/jk/conf/workers2.properties
Index: workers2.properties
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/conf/workers2.properties,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- workers2.properties 1 Jul 2002 23:53:07 - 1.14
+++ workers2.properties 11 Jul 2002 11:40:48 - 1.15
@@ -75,13 +75,19 @@
#OPT=-Djava.compiler=NONE
disabled=1
-[worker.jni:jniCmd1]
-info=Command to be executed by the VM. This one will start tomcat.
+[worker.jni:onStartup]
+info=Command to be executed by the VM on startup. This one will start tomcat.
class=org/apache/jk/apr/TomcatStarter
ARG=start
disabled=1
stdout=${serverRoot}/logs/stdout.log
stderr=${serverRoot}/logs/stderr.log
+
+[worker.jni:onShutdown]
+info=Command to be executed by the VM on shutdown. This one will stop tomcat.
+class=org/apache/jk/apr/TomcatStarter
+ARG=stop
+disabled=1
[uri:/jkstatus/*]
info=Display status information and checks the config file for changes.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
mod_jk2 worker_jni hooks
Some more explanation of the worker jni hooks. Why the hooks? To be able to execute a particular class during a different process stage. There are 4 types of hooks (as briefly explained in the commit mail): 1. onStartup (worker.jni:onStartup) This hook will register the native functions for the AprImpl, redirect the stdout/stderr if set and run the specified class. Only one worker can be executed on startup. 2. onInit (worker.jni:onInit) Executes on startup but doesn't redirect nor registers natives. There can be any number of workers in this stage and they are distinguished by name suffix (worker.jni:onInit1, etc..) The patch uses strncmp for hook type checking. 3. onClose (worker.jni:onClose) Executes when the connector is about to be destroyed. There can be any number of workers in this stage and they are distinguished by name suffix (worker.jni:onClose1, etc..) The patch uses strncmp for hook type checking. 4. onShutdown (worker.jni:onShutdown) Executes when the connector is about to be destroyed. It also waits for TC shutdown signal, and then destroys the jvm. Only one worker can be executed on shutdown. The order of worker execution is their order in the workers2.properties file. I'm looking for a way to rearrange that (at least onStartup and onShutdown) accordingly to the hook order, and then the config order. MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10683] New: - some problems with JSP documents in xml syntax
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=10683.
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=10683
some problems with JSP documents in xml syntax
Summary: some problems with JSP documents in xml syntax
Product: Tomcat 4
Version: Unknown
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Normal
Priority: Other
Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Usually I use normal jsp syntax but I now tried out the xml compliant syntax
form and found three peculiarities. My estimation is that these are due to bugs
within jasper but since I am not an expert on the xml-like jsp form, I'm
insecure. Well, I would like to post a little example that depicts the three
things that might be bugs. Within this example I also explain each bug and give
reference to the paragraphs within the JSP 1.2 specification if I can.
The three issues I have are:
a) treatment of xml comments
b) treatment of mixed element content when taglib elements are involved
c) attribute expression evaluation
I am pretty sure that b) is a bug. a) is a low prio thing and c) is a blocker
for me.
But see the following example for details.
(If you also want to run it, you will need to have the EL-based JSTL core
taglib installed.)
jsp:root
xmlns:jsp=http://java.sun.com/JSP/Page;
xmlns:c=http://java.sun.com/jstl/core;
html
body
ul
li
Request time attribute expressions don't seem to work
in jsp documents, or maybe I'm doing sth. wrong.
According to the JSP spec. paragraph 5.3.11, the quoting
convention used in jsp documents is as follows:
a href=%= response.encodeURL('thispage.jsp') %
However, the expression inside the href attribute
is not being evaluated.
/a
br /
/li
li
If an xml element contains mixed content, e.g. plain text
and other xml elements, then the resulting output is not
correct in every case. If plain text is directly preceding
a taglib element, then the taglib output is written to the
jsp-outputstream prior to the plain text.
For example, note that the following JSTL tag should deliver
its output behind this text here, but within the webpage the
taglib output will appear first.
c:out value=THIS TEXT SHOULD NOT APPEAR FIRST. /
br /
If however the plain text preceding a taglib element is
interleaved with other xml elements, as it is done here, then
everything works fine again.
br /
c:out value=TAGLIB TEXT /
See ? (And plain text behind a taglib element is also save.)
br /
/li
li
In the resulting page, the javascript at the end of this page
is missing. The comment around the javascript part is needed
by some browsers. I could place the body of the
script element into a CDATA section but I believe
that it is a bug to erase xml comments from the
source page. Also, if I would just place a jsp:text
element arount the javascript, this would also
erase the xml comment. Unfortunately the JSP spec
doesn't explicitly mention the treatment of xml comments
and whether they should be erased or not.
In addition to that it is a pity that the SAX API's
don't really report the occurence of xml comments.
Only the org.xml.sax.ext.LexicalHelper does, but it
is an optional extension to SAX2 and can only be plugged
in as an attribute to the parser. ;(
/li
/ul
/body
script language=javascript
!--
function veryImportantFunction()
{
alert(An xml-comment is an xml-comment and may not be skipped.);
}
//--
/script
/html
/jsp:root
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [VOTE] New branches and repositories
Remy, Below are my votes. I like the idea of using repositories without versions numbers for the Catalina, Jasper, and Tomcat code. It always seemed to me to be a pain to create a new CVS repository every time there is a new release instead of just creating a branch for the old release. Patrick Remy Maucherat wrote: ballot A) Servlet 2.4 JSP 2.0 API 1. [X] Use new jakarta-servletapi-5 2. [ ] Use the HEAD of jakarta-servletapi 3. [ ] Other: B) Catalina 2.0 1. [X] Use new jakarta-tomcat-catalina 2. [ ] Use new jakarta-tomcat-5.0 3. [ ] Use the HEAD of jakarta-tomcat-4.0 4. [ ] Other: C) Coyote 2.0 1. [X] Yes, use the HEAD of jakarta-tomcat-connectors 2. [ ] No, use: D) Tomcat 5.0 1. [ ] Use new jakarta-tomcat-5.0 2. [ ] Use the HEAD of jakarta-tomcat-4.0 3. [X] Use the HEAD of jakarta-tomcat 4. [ ] Other: E) Jasper 2.0 1. [X] Yes, use the HEAD of jakarta-tomcat-jasper 2. [ ] No, use: /ballot -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
StandardContext .. getPath()
Hi, I can't find the answer to this question anywhere, although I expect its quite simple.. I've created my own context class, subclassing StandardContext, and I want it to be able to read a config file, but I'm having problems getting a path from tc. How can I get the real path to ~/webapps, or get CATALINA_HOME for my context to use in its hunt for its config file? I realise I may have missed the blindingly obvious here, for which I appologise in advance. d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [VOTE] New branches and repositories
On Thu, 11 Jul 2002, Remy Maucherat wrote: ballot A) Servlet 2.4 JSP 2.0 API 1. [X] Use new jakarta-servletapi-5 2. [ ] Use the HEAD of jakarta-servletapi 3. [ ] Other: B) Catalina 2.0 1. [X] Use new jakarta-tomcat-catalina 2. [ ] Use new jakarta-tomcat-5.0 3. [ ] Use the HEAD of jakarta-tomcat-4.0 4. [ ] Other: C) Coyote 2.0 1. [X] Yes, use the HEAD of jakarta-tomcat-connectors 2. [ ] No, use: D) Tomcat 5.0 1. [X] Use new jakarta-tomcat-5.0 2. [ ] Use the HEAD of jakarta-tomcat-4.0 3. [ ] Use the HEAD of jakarta-tomcat 4. [ ] Other: That's a hard one... I would like it to go in jakarta-tomcat, but the current CVS organization is a mess and would create more problems. I'm actually more on jakarta-tomcat-5 ( without the .0 - since 5.1 will be in this CVS too ) E) Jasper 2.0 1. [X] Yes, use the HEAD of jakarta-tomcat-jasper 2. [ ] No, use: /ballot -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup BootstrapService.java
jfclere 2002/07/11 06:47:02
Modified:catalina/src/share/org/apache/catalina/startup
BootstrapService.java
Log:
Prevent NPE when DaemonContext is not well initialised.
Revision ChangesPath
1.16 +9 -7
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/BootstrapService.java
Index: BootstrapService.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/BootstrapService.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- BootstrapService.java 9 Jul 2002 10:46:16 - 1.15
+++ BootstrapService.java 11 Jul 2002 13:47:02 - 1.16
@@ -128,9 +128,11 @@
/* Read the arguments from the Daemon context */
if (context!=null) {
arguments = context.getArguments();
-for (int i = 0; i arguments.length; i++) {
-if (arguments[i].equals(-debug)) {
-debug = 1;
+if (arguments!=null) {
+for (int i = 0; i arguments.length; i++) {
+if (arguments[i].equals(-debug)) {
+debug = 1;
+}
}
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[GUMP] Build Failure - jakarta-tomcat-4.0
This email is autogenerated from the output from:
http://jakarta.apache.org/builds/gump/2002-07-11/jakarta-tomcat-4.0.html
Buildfile: build.xml
deploy-prepare:
deploy-static:
deploy:
[echo] Target: Catalina - Deploy ...
flags:
flags.display:
[echo] --- Build environment for Catalina ---
[echo] If ${property_name} is displayed, then the property is not set)
[echo] --- Build options ---
[echo] full.dist=${full.dist}
[echo] build.sysclasspath=only
[echo] compile.debug=${compile.debug}
[echo] compile.deprecation=${compile.deprecation}
[echo] compile.optimize=${compile.optimize}
[echo] --- Ant Flags ---
[echo] style task available (required)=true
[echo] --- JDK ---
[echo] jdk.1.2.present=true
[echo] jdk.1.3.present=true
[echo] jdk.1.4.present=${jdk.1.4.present}
[echo] --- Source Dependencies ---
[echo] jtc.home.present=true
[echo] --- Required Libraries ---
[echo] beanutils.present=true
[echo] collections.present=true
[echo] digester.present=true
[echo] jaxp.present=true
[echo] jndi.present=true
[echo] logging.present=true
[echo] regexp.present=true
[echo] servlet.present=true
[echo] --- Optional Libraries ---
[echo] daemon.present=${daemon.present}
[echo] dbcp.present=true
[echo] jaas.present=true
[echo] javamail.present=true
[echo] jmx.present=true
[echo] jsse.present=true
[echo] jta.present=true
[echo] junit.present=true
[echo] ldap.present=true
[echo] modeler.present=true
[echo] pool.present=true
[echo] tyrex.present=${tyrex.present}
[echo] --- Required JARs ---
[echo] jndi.jar.present(except JDK 1.3+)=true
[echo] regexp.jar.present=true
[echo] servlet.jar.present=true
[echo] xerces.jar.present(except JDK 1.4+ or xerces2)=true
[echo] xerces2.jars.present(except JDK 1.4+ or xerces1)=${xerces2.jars.present}
[echo] --- Optional JARs ---
[echo] daemon.jar.present=${daemon.jar.present}
[echo] dbcp.jar.present=true
[echo] jaas.jar.present=true
[echo] javamail.jar.present=true
[echo] jdbc20ext.jar.present=true
[echo] jmx.jar.present=true
[echo] jta.jar.present=true
[echo] junit.jar.present=${junit.jar.present}
[echo] ldap.jar.present=true
[echo] modeler.jar.present=true
[echo] pool.jar.present=true
[echo] tyrex.jar.present=${tyrex.jar.present}
[echo] --- Conditional compilation flags ---
[echo] compile.daemon=${compile.daemon}
[echo] compile.dbcp=true
[echo] compile.jaas=true
[echo] compile.javamail=true
[echo] compile.jmx=true
[echo] compile.jndi=true
[echo] compile.jsse=true
[echo] compile.jta=true
[echo] compile.junit=true
[echo] compile.ldap=true
[echo] compile.ssi=true
[echo] compile.tyrex=${compile.tyrex}
[echo] --- Distribution flags ---
[echo] copy.daemon.jar=${copy.daemon.jar}
[echo] copy.dbcp.jar=true
[echo] copy.jaas.jar=true
[echo] copy.jdbc20ext.jar=true
[echo] copy.javamail.jar=true
[echo] copy.jmx.jar=true
[echo] copy.jndi.jar=${copy.jndi.jar}
[echo] copy.jta.jar=true
[echo] copy.ldap.jar=${copy.ldap.jar}
[echo] copy.logging.jar=true
[echo] copy.modeler.jar=true
[echo] copy.pool.jar=true
[echo] copy.tyrex.jar=${copy.tyrex.jar}
[echo] copy.xerces.jar=true
[echo] copy.xerces2.jars=${copy.xerces2.jars}
build-prepare:
copy-activation.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/lib
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/lib
copy-daemon.jar:
copy-dbcp.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/lib
copy-jaas.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/server/lib
copy-jdbc20ext.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/lib
copy-jmx.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/server/lib
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/server/lib
copy-jndi.jar:
copy-jsse.jar:
copy-jta.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/lib
copy-ldap.jar:
copy-modeler.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/server/lib
copy-pool.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/lib
copy-tyrex.jar:
copy-xerces.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/endorsed
copy-xerces2.jars:
build-static:
BUILD FAILED
OFF TOPIC: RE: [5.0] [VOTE] New branches and repositories
As a lay person trying to learn, can I ask a question about the benefits of repository vs branch? Since I haven't really used CVS, I don't know the +/-, but would have proposed: A) Servlet 2.4 JSP 2.0 API Use new jakarta-servletapi-5.0 B) Catalina 2.0 Use new jakarta-tomcat-catalina-2.0 C) Coyote 2.0 use new jakarta-tomcat-connectors-2.0 D) Tomcat 5.0 Use new jakarta-tomcat-5.0 E) Jasper 2.0 use new jakarta-tomcat-jasper-2.0 Which would seem more consistent, for someone just trying to dip in for the first time. Mitchell Evan Marx[EMAIL PROTECTED] ATT IP Network Configuration Provisioning Development -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 11, 2002 9:37 AM To: Tomcat Developers List Subject: Re: [5.0] [VOTE] New branches and repositories On Thu, 11 Jul 2002, Remy Maucherat wrote: ballot A) Servlet 2.4 JSP 2.0 API 1. [X] Use new jakarta-servletapi-5 2. [ ] Use the HEAD of jakarta-servletapi 3. [ ] Other: B) Catalina 2.0 1. [X] Use new jakarta-tomcat-catalina 2. [ ] Use new jakarta-tomcat-5.0 3. [ ] Use the HEAD of jakarta-tomcat-4.0 4. [ ] Other: C) Coyote 2.0 1. [X] Yes, use the HEAD of jakarta-tomcat-connectors 2. [ ] No, use: D) Tomcat 5.0 1. [X] Use new jakarta-tomcat-5.0 2. [ ] Use the HEAD of jakarta-tomcat-4.0 3. [ ] Use the HEAD of jakarta-tomcat 4. [ ] Other: That's a hard one... I would like it to go in jakarta-tomcat, but the current CVS organization is a mess and would create more problems. I'm actually more on jakarta-tomcat-5 ( without the .0 - since 5.1 will be in this CVS too ) E) Jasper 2.0 1. [X] Yes, use the HEAD of jakarta-tomcat-jasper 2. [ ] No, use: /ballot -- 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: [5.0] [VOTE] New branches and repositories
ballot A) Servlet 2.4 JSP 2.0 API 1. [X] Use new jakarta-servletapi-5 2. [ ] Use the HEAD of jakarta-servletapi 3. [ ] Other: B) Catalina 2.0 1. [X] Use new jakarta-tomcat-catalina 2. [ ] Use new jakarta-tomcat-5.0 3. [ ] Use the HEAD of jakarta-tomcat-4.0 4. [ ] Other: C) Coyote 2.0 1. [X] Yes, use the HEAD of jakarta-tomcat-connectors 2. [ ] No, use: D) Tomcat 5.0 1. [2] Use new jakarta-tomcat-5.0 2. [ ] Use the HEAD of jakarta-tomcat-4.0 3. [ ] Use the HEAD of jakarta-tomcat 4. [1] Other: jakarta-tomcat-5 I agree with Costin that it is confusing to be building Tomcat 4.1.x in the jakarta-tomcat-4.0 repository. E) Jasper 2.0 1. [X] Yes, use the HEAD of jakarta-tomcat-jasper 2. [ ] No, use: /ballot Larry -- 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 9361] - jsp:param calls URLEncoder.encode() without null check
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=9361. 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=9361 jsp:param calls URLEncoder.encode() without null check [EMAIL PROTECTED] changed: What|Removed |Added Component|Servlet JSP API |Jasper 2 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [VOTE] New branches and repositories
[EMAIL PROTECTED] wrote: D) Tomcat 5.0 1. [X] Use new jakarta-tomcat-5.0 2. [ ] Use the HEAD of jakarta-tomcat-4.0 3. [ ] Use the HEAD of jakarta-tomcat 4. [ ] Other: That's a hard one... I would like it to go in jakarta-tomcat, but the current CVS organization is a mess and would create more problems. I'm actually more on jakarta-tomcat-5 ( without the .0 - since 5.1 will be in this CVS too ) Yes, that makes sense (the current 4.0 in the repository name is awkward), and it's an easy change. Unless somebody has something against it, I'll consider vote 1. to be jakarta-tomcat-5. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10690] New: - ServletOutputStream blocks thread when cancelling download in IE
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=10690.
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=10690
ServletOutputStream blocks thread when cancelling download in IE
Summary: ServletOutputStream blocks thread when cancelling
download in IE
Product: Tomcat 4
Version: 4.1.0
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Normal
Priority: Other
Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
The ServletOutputStream blocks on write (actually on its internal flush) in a
special case: when download with IE from a jsp and cancelling during save.
The ServletOutputStream blocks, and so does the thread serving it. In the
single-thread servlet model, this also locks the servlet.
---
Related problems have been posted at the user and dev mailing lists, see:
http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg19692.html
http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg16648.html
---
details of configuration:
server: standalone Apache Tomcat 4.1-dev for JavaTM Web Services Developer Pack
1.0 EA2
jsp:
%@ page import=java.io.* %
%
// let the filename point to a large text file
String filename = D:\\log.csv;
System.out.println( Before download );
try {
FileReader file_reader = new FileReader( filename );
BufferedReader reader = new BufferedReader( file_reader );
File log_file = new File( filename );
long length = log_file.length();
log_file = null;
response.setContentType (application/excell);
response.setHeader (Content-Disposition, attachment; filename=\ +
filename + \);
response.setContentLength( (int)length );
ServletOutputStream outs = response.getOutputStream();
String line = reader.readLine();
// debug code to print something for every line that is being pushed.
int l = 1;
while ( line != null ) {
outs.println( line );
System.out.println(line + l++ );
line = reader.readLine();
}
reader.close();
file_reader.close();
outs.flush();
outs.close();
}
catch ( Exception e ) {
e.printStackTrace();
}
System.out.println( After download. If you see this, the thread has been freed. );
%
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10691] New: - staring tomcat gives indication that tomcat is starting but never that it is started
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=10691. 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=10691 staring tomcat gives indication that tomcat is starting but never that it is started Summary: staring tomcat gives indication that tomcat is starting but never that it is started Product: Tomcat 4 Version: 4.1.7 Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When you start tomcat using the startup script in the bin folder there are a couple of messages generated. They state that tomcat is starting but never when it has finished starting and is started. It would be nice to get a message when the starting is over and the tomcat is started. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10690] - ServletOutputStream blocks thread when cancelling download in IE
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=10690. 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=10690 ServletOutputStream blocks thread when cancelling download in IE [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-07-11 14:26 --- I strongly doubt that. If the client disconnects, an exception will be raised and the request processing will stop. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: StandardContext .. getPath()
I'll answer my own question.. getServletContext() returns null until start() (or in my case super.start()) has been called, whereafter I can use ServletContext.getRealPath() d. -Original Message- From: Danny Angus [mailto:[EMAIL PROTECTED]] Sent: 11 July 2002 14:22 To: Tomcat-Dev@Jakarta. Apache. Org Subject: StandardContext .. getPath() Hi, I can't find the answer to this question anywhere, although I expect its quite simple.. I've created my own context class, subclassing StandardContext, and I want it to be able to read a config file, but I'm having problems getting a path from tc. How can I get the real path to ~/webapps, or get CATALINA_HOME for my context to use in its hunt for its config file? I realise I may have missed the blindingly obvious here, for which I appologise in advance. d. -- 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: [PATCH] Custom tag scripting variables
Jan, I found another issue, while trying to port our application from weblogic. It seems that if you have declared variables with the same name in tags that are nested (even when the tags are different tags) it creates the same problem where the code cannot be compiled. The fix is going to have to not only look for self nested tags, but self nested tags that declare the same variable names. If the short tag name was added to the variable name in addition to the counter that was added with the patch, I think it would fix the problem. But the first declaration needs the tag it is being declared for specified. example: fci:collection //declares iPerPage variables fci:element //declares a iPerPage variable /fci:element /fci:collection Pete Gordon On Wednesday, June 12, 2002, at 05:59 PM, Jan Luehe wrote: As discussed with Kin-Man, the following patch (for Jasper2) addresses two issues related to scripting variables exposed by custom tags (via TagExtraInfo class or TLD): ISSUE 1: +++ According to the JSP spec, scripting variables with scope AT_BEGIN or AT_END are supposed to be visible from the begin element or end element, respectively, of the custom tag that is exposing them, all the way to the *end* of the page. This currently is not the case. The attached patch addresses this problem by determining the AT_BEGIN and AT_END scripting variables of any custom tag and declaring them as local variables of the _jspService() method. ISSUE 2: +++ If a custom tag exposing scripting variables is nested inside itself, its scripting variables get declared multiple times within the same scope of the generated code, resulting in compilation errors. This problem has been filed as bug #8926 (Synopsis: Duplicate variable definition in generated Java source, related to custom tag scripting variable). The attached patch addresses this problem by declaring AT_BEGIN and AT_END scripting variables once (as local variables of the _jspService() method, see above), and declaring NESTED scripting variables only at the outermost nesting level of their custom tag, where nesting level corresponds the number of times the custom tag is nested inside itself. Example: g:h a:b -- nesting level 0, declares NESTED scripting variables c:d e:f a:b -- nesting level 1, saves scripting variables a:b -- nesting level 2, saves scripting variables /a:b -- restores scripting variables /a:b -- restores scripting variables a:b -- nesting level 1, saves scripting variables /a:b -- restores scripting variables /e:f /c:d /a:b a:b -- nesting level 0, does not declare any NESTED scripting variables /a:b /g:h If a:b exposes any NESTED scripting variables, those variables are going to be declared only once in the generated code, namely by the *first* a:b at nesting level 0. Any a:b with a nesting level 0 saves (in its begin element) the current values of all its scripting variables to locale variables (named for the scripting variable and the custom tag's nesting level) before synchronizing the scripting variables as defined by the JSP spec. In its end element, the custom tag restores the original values of the scripting variables (that is, the values the scripting variables had when the tag's begin element was encountered). In addition, this patch stores a custom tag's scripting variables with the custom tag itself, so the scripting variables don't need to be determined over and over again. This has resulted in two new accessor methods for Node.CustomTag: public TagVariableInfo[] getTagVariableInfos() public VariableInfo[] getVariableInfos() Let me know if there are any problems with this patch. Thanks, Jan Executing ssh-askpass to query the password... Warning: Remote host denied X11 forwarding, perhaps xauth program could not be run on the server side. ? build.properties ? build ? src/share/org/apache/jasper/compiler/Generator.java.SAVE cvs server: Diffing . cvs server: Diffing doc cvs server: Diffing src cvs server: Diffing src/bin cvs server: Diffing src/share cvs server: Diffing src/share/org cvs server: Diffing src/share/org/apache cvs server: Diffing src/share/org/apache/jasper cvs server: Diffing src/share/org/apache/jasper/compiler Index: src/share/org/apache/jasper/compiler/Generator.java === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compil er/Generator.java,v retrieving revision 1.23 diff -u -r1.23 Generator.java --- src/share/org/apache/jasper/compiler/Generator.java 10 Jun 2002 21:08:30 -1.23 +++ src/share/org/apache/jasper/compiler/Generator.java 12
DO NOT REPLY [Bug 10698] - Error - jk_tcp_socket_recvfull failed in mod_jk
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=10698. 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=10698 Error - jk_tcp_socket_recvfull failed in mod_jk [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |tomcat- ||[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [5.0] [VOTE] New branches and repositories
A) Servlet 2.4 JSP 2.0 API 1. [X] Use new jakarta-servletapi-5 2. [ ] Use the HEAD of jakarta-servletapi 3. [ ] Other: B) Catalina 2.0 1. [X] Use new jakarta-tomcat-catalina 2. [ ] Use new jakarta-tomcat-5.0 3. [ ] Use the HEAD of jakarta-tomcat-4.0 4. [ ] Other: C) Coyote 2.0 1. [X] Yes, use the HEAD of jakarta-tomcat-connectors 2. [ ] No, use: D) Tomcat 5.0 1. [X] Use new jakarta-tomcat-5.0 2. [ ] Use the HEAD of jakarta-tomcat-4.0 3. [ ] Use the HEAD of jakarta-tomcat 4. [ ] Other: Agree in call 5 not 5.0.. E) Jasper 2.0 1. [X] Yes, use the HEAD of jakarta-tomcat-jasper 2. [ ] No, use: /ballot Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10699] New: - Apache SOAP 2.3 will not operate properly
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=10699. 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=10699 Apache SOAP 2.3 will not operate properly Summary: Apache SOAP 2.3 will not operate properly Product: Tomcat 4 Version: 4.0.4 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Enhancement Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When trying to utilize custom type serializers and fault listeners on Tomcat 4.0.4 the SOAP message seems to be improperly marshaled to/from a SOAP server instance. Standard data types like int, String, and long operate ok, but custom faults, types, and standard list types (HashTable, Vector) are improperly marshaled from a SOAP client request and therefore, the wrong (or null) type and fault serializers get called resulting in an unhanded server exception. I can supply the class files and the directory structure of the Tomcat installation as support material, but have not found a way to do so on this 'new' bug interface. We have also had trouble getting the Tomcat 4 framework into a debugger (and do not have this problem with Tomcat 3.X), so we are still trying to find a class name and specific set of exceptions which happen when SOAP fails with Tomcat 4. Note that SOAP seems to work fine and debug properly on Tomcat 3.X (tried ALL). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10699] - Apache SOAP 2.3 will not operate properly
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=10699. 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=10699 Apache SOAP 2.3 will not operate properly --- Additional Comments From [EMAIL PROTECTED] 2002-07-11 15:31 --- Created an attachment (id=2319) Classes and deploy descriptors for moving data across SOAP -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jar_cache files
On Thu, 11 Jul 2002, Arnaud HERITIER wrote: Date: Thu, 11 Jul 2002 10:21:58 +0200 From: Arnaud HERITIER [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Tomcat-Dev (E-mail) [EMAIL PROTECTED] Subject: jar_cache files Nobody has an idea about this. how are used jar_cache* files in Tomcat ?? Tomcat doesn't directly use jar_cache files at all. Presumably they are created by the JDK when things like java.util.jar.JarFile are used. It also may be specific to the particular JDK you are running. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: getRequestURI()
The must remain encoded requirement for getRequestURI(), as was stated in the response by lin on the Macromedia forum thread, refers to any URL encoding that was done by the client to transmit characters like '/' and '' in a URI. This doesn't address the question of whether session ids (which the servlet spec requires to be included as a path parameter) should be striped or not. The specs defining the syntax of URIs (RFC 2396) clearly identify things after a semicolon as path parameters. What's not obvious is whether they should be considered part of the request URI or not. I would suggest that consistency with the way query string parameters are handled (they are stripped off) would be sufficient reasoning to conclude that path parameters should be removed as well. But it is not clear cut. It doesn't appear that there are any Watchdog tests for this particular scenario, and the same is likely true of the actual TCK. However, there is a presumtive comment at the begining of the servlet spec that is relevant: A reference implementation (RI) has been made available which provides a behavioral benchmark for this specification. Where the specification leaves implementation of a particular feature open to interpretation, implementors may use the reference implementation as a model of how to carry out the intention of the specification. Tomcat, which is the basis of the RI for the servlet spec (the official RI is the J2EE reference implementaiton, which includes Tomcat code for the web container) has never, AFAIK, left the session id in the value returned by getRequestURI(), which implies (based on the paragraph quoted above) that this is indeed the intended behavior. The way to find out for sure is to ask for an interpretation from the servlet specification lead, Danny Coward [EMAIL PROTECTED]. As it happens, the topic of whether we should or should not strip path parameters was brought up to the JSR-154 (Servlet 2.4) expert group just last week, although not specifically referring to jsessionid parameters. I suspect a formal requirement (one way or the other) will end up getting put into Servlet 2.4. In the mean time, and in the absence of any interpretation by the spec lead, the behavior of the J2EE RI (which is identical to Tomcat's behavior in this respect because it uses Tomcat code for this) should be presumed to be correct. Craig McClanahan On Thu, 11 Jul 2002, Eddie Bush wrote: Date: Thu, 11 Jul 2002 01:03:54 -0500 From: Eddie Bush [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: getRequestURI() Look at what Bob posted. I'd listen to the spec before I listened to anyone else - hold that up to their nose. It's black and white. Alex Kachanov wrote: -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] To: Tomcat Developers List Subject: Re: getRequestURI() Ah - now I feel stupid. I was thinking he was saying encodeURL didn't put it there. According to what your interpretation is he things getRequestURI doesn't get it back. :-/ No, I tell that getRequestURI in Tomcat returns file name only - and I'm FINE with that. While, in JRun getRequestURI returns file name + jsessionid - and I'm not FINE with that. Macromedia support tells that Jrun behavior is according to the specification, and that all other AS are wrong and JRun is right in this particular case. Then, who IS right? -- 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]
Building mod_jk2 on Solaris 8 + a question.
FYI: In building the jk2 module on Solaris 8, I had to include add the -DBSD_COMP compiler flag when making in $jk/native2/server/apache13. Could someone with jk/jk2 experience answer a few questions for me? Namely, what are the differences between jk and jk2, and is the jk2 configuration any different than jk? I have been using the webapp module, and am switching to add some load balancing. Thanks. benjamin vandgrift ekos project team ph#: 502.564.9375x242 mob: 859.333.7320 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
jsp:include problem with Compression Filter
Hello (Amy),
I have found yet another problem with compression filter.
If jsp page uses include action:
jsp:include page=/pageToInclude.jsp flush=true/
then a new request is send to server. The result will be compressed
and then compressed once again in the calling page, which make
the result look pretty ugly ;-)
I have found a pretty simple workaround of this problem.
Include action should be extended with parameter gzip:
jsp:include page=/pageToInclude.jsp flush=true
jsp:param name=gzip value=false/
/jsp:include
Compression filter will check the request for this parameter
and decide if the page should be compressed or not:
// Are we allowed to compress ?
String s = (String) ((HttpServletRequest)request).getParameter(gzip);
if (false.equals(s)) {
if (debug 0) {
System.out.println(got parameter gzip=false -- don't compress,
just chain filter);
}
chain.doFilter(request, response);
return;
}
I have attached the modified Files to this mail. A bit more debugging info
was added to CompressionResponseStream.
Let me know if you have better idea to solve the problem.
BTW, the problem 9434 seems also to be fixed with previous check in.
Regards,
Dmitri Valdin
(See attached file: filter.zip)
--
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn
Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das
unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you are not the
intended recipient (or have received this e-mail in error) please notify the sender
immediately and destroy this e-mail. Any unauthorized copying, disclosure or
distribution of the material in this e-mail is strictly forbidden.
=?iso-8859-1?Q?filter.zip?=
Description: Zip archive
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [VOTE] New branches and repositories
A) Servlet 2.4 JSP 2.0 API 1. [X] Use new jakarta-servletapi-5 2. [ ] Use the HEAD of jakarta-servletapi 3. [ ] Other: B) Catalina 2.0 1. [X] Use new jakarta-tomcat-catalina 2. [ ] Use new jakarta-tomcat-5.0 3. [ ] Use the HEAD of jakarta-tomcat-4.0 4. [ ] Other: C) Coyote 2.0 1. [X] Yes, use the HEAD of jakarta-tomcat-connectors 2. [ ] No, use: D) Tomcat 5.0 1. [ ] Use new jakarta-tomcat-5.0 2. [ ] Use the HEAD of jakarta-tomcat-4.0 3. [ ] Use the HEAD of jakarta-tomcat 4. [X] Other: jakarta-tomcat-5 E) Jasper 2.0 1. [X] Yes, use the HEAD of jakarta-tomcat-jasper 2. [ ] No, use: /ballot -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [VOTE] New branches and repositories
ballot A) Servlet 2.4 JSP 2.0 API 1. [X] Use new jakarta-servletapi-5 2. [ ] Use the HEAD of jakarta-servletapi 3. [ ] Other: B) Catalina 2.0 1. [X] Use new jakarta-tomcat-catalina 2. [ ] Use new jakarta-tomcat-5.0 3. [ ] Use the HEAD of jakarta-tomcat-4.0 4. [ ] Other: C) Coyote 2.0 1. [ ] Yes, use the HEAD of jakarta-tomcat-connectors 2. [ ] No, use: D) Tomcat 5.0 1. [X] Use new jakarta-tomcat-5.0 2. [ ] Use the HEAD of jakarta-tomcat-4.0 3. [ ] Use the HEAD of jakarta-tomcat 4. [ ] Other: E) Jasper 2.0 1. [X] Yes, use the HEAD of jakarta-tomcat-jasper 2. [ ] No, use: /ballot -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [VOTE] New branches and repositories
ballot A) Servlet 2.4 JSP 2.0 API 1. [X] Use new jakarta-servletapi-5 2. [ ] Use the HEAD of jakarta-servletapi 3. [ ] Other: B) Catalina 2.0 1. [ ] Use new jakarta-tomcat-catalina 2. [X] Use new jakarta-tomcat-5.0 3. [ ] Use the HEAD of jakarta-tomcat-4.0 4. [ ] Other: C) Coyote 2.0 1. [X] Yes, use the HEAD of jakarta-tomcat-connectors 2. [ ] No, use: D) Tomcat 5.0 1. [X] Use new jakarta-tomcat-5.0 2. [ ] Use the HEAD of jakarta-tomcat-4.0 3. [ ] Use the HEAD of jakarta-tomcat 4. [ ] Other: E) Jasper 2.0 1. [X] Yes, use the HEAD of jakarta-tomcat-jasper 2. [ ] No, use: /ballot -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10710] New: - Tomcat will not serve a file with %25 in the URI
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=10710. 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=10710 Tomcat will not serve a file with %25 in the URI Summary: Tomcat will not serve a file with %25 in the URI Product: Tomcat 4 Version: 4.0.4 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote HTTP/1.1 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If you try to serve up a file from tomcat with a % in the name, tomcat gets upset. EX: my%file.mp3 http://server/files/my%25file.mp3 Tomcat debug info states: HttpProcessor[8080][4] An incoming request is being assigned HttpProcessor[8080][4] The incoming request has been awaited HttpProcessor[8080][4] Normalized: '/files/my%25file.mp3' to 'null' HttpProcessor[8080][4] Invalid request URI: '/files/my%25file.mp3' -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10711] New: - [PATCH] relative filenames with ../ do not work for JSP-includes
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=10711. 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=10711 [PATCH] relative filenames with ../ do not work for JSP-includes Summary: [PATCH] relative filenames with ../ do not work for JSP- includes Product: Tomcat 4 Version: 4.1.7 Platform: All URL: http://www.freiheit.com/users/hzeller/RelativeUri- BUG.patch.gz OS/Version: Other Status: NEW Severity: Critical Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Including relative files that start with ../ in JSPs, like jsp:include name=../../foo.jsp/ does not work anymore with Jasper2. Symptom The java file in generated at the expected place, but the the relative filename is not assembled correctly, so that the compiler does not compile it. Solution The problem is, that the filename seems not to be assembled correctly if ../ are in the path. Tracking this down revealed, that at several places this makes problems since the same place can have different names (for instance in looking up the URL classloader). Calling getCanonicalPath() in some places would help, but it is better to make the URI canonical in the first place. See patch at http://www.freiheit.com/users/hzeller/RelativeUri-BUG.patch.gz It is against a current CVS checkout. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10713] New: - [PATCH] Backslashes quoting quotes in attributes does not work
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=10713. 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=10713 [PATCH] Backslashes quoting quotes in attributes does not work Summary: [PATCH] Backslashes quoting quotes in attributes does not work Product: Tomcat 4 Version: 4.1.7 Platform: All URL: http://www.freiheit.com/users/hzeller/BackslashInAttribu teValue-BUG.patch.gz OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] [version: current CVS] Using the quoting character '\' (backslash) in Tag-Attributes does not work as expected. Writing this for instance my:tag value=foo\bar\/ won't work, since the before bar is regarded as closing quote for the attribute. Symptom: a JspException with 'jsp.error.attribute.noequal' is thrown, since the remaining bar... is regarded as name of the next attribute which of course has not equals sign. Solution: overread the next character if a backslash is seen. An conservative implementation of this fix you find at http://www.freiheit.com/users/hzeller/BackslashInAttributeValue-BUG.patch.gz this is against a current CVS. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10563] - Multiple compiles for multiple requests
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=10563.
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=10563
Multiple compiles for multiple requests
--- Additional Comments From [EMAIL PROTECTED] 2002-07-11 20:07 ---
Probably better in JspCompilationContext, since there is the place, where
the isOutDated() is checked. And: it should be synchronized with the
jspCompiler object, not the Compiler.class, since this would serialize
compilation completely; synchronizing the compiler will only serialize
attempts to compile the same file.
--[ from JspCompilationContext.compile() ] --
if (jspCompiler.isOutDated()) {
try {
synchronized (jspCompiler) {
if (jspCompiler.isOutDated()) {
jspCompiler.compile();
reload = true;
}
}
} catch (Exception ex) {
//
}
}
---
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10714] New: - JSP does not compile if useBean tag refers to bean w/o package name in WEB-INF/classes
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=10714. 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=10714 JSP does not compile if useBean tag refers to bean w/o package name in WEB-INF/classes Summary: JSP does not compile if useBean tag refers to bean w/o package name in WEB-INF/classes Product: Tomcat 4 Version: 4.0.4 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] To reproduce: 1) Create a web module directory 2) Create a JavaBean directly under WEB-INF/classes (i.e. don't create -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10714] - JSP does not compile if useBean tag refers to bean w/o package name in WEB-INF/classes
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=10714. 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=10714 JSP does not compile if useBean tag refers to bean w/o package name in WEB-INF/classes --- Additional Comments From [EMAIL PROTECTED] 2002-07-11 20:54 --- Created an attachment (id=2323) WAR file of web app which reproduces the problem -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10714] - JSP does not compile if useBean tag refers to bean w/o package name in WEB-INF/classes
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=10714. 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=10714 JSP does not compile if useBean tag refers to bean w/o package name in WEB-INF/classes --- Additional Comments From [EMAIL PROTECTED] 2002-07-11 21:00 --- Ooops, that got sumbitted on return in description text field. To reproduce: 1) Create a web module directory 2) Create a JavaBean directly under WEB-INF/classes (don't create a package under WEB-INF/classes) 3) Create a JSP at the web module root which refers to the bean with a useBean tag. 4) The JSP does not compile. I have added an attachment containing a web module which reproduces this problem. The web module contains identical JavaBeans pkg.PackageBean and NoPackageBean in the WEB-INF/classes directory. It contains identical PackageBeanJSP.jsp and NoPackageBeanJSP.jsp files at the root of the web module. NoPackageBeanJSP.jsp cannot be run on the server. I marked this as normal, but I think it possibly has higher priority, because it's likely to fool new users of the server who are writing their first web app and are experimenting with the JSP spec (I have seen this happen to people). In Netbeans, we use Tomcat as the execution environment for web app development and it is particularly important that people can write HelloWorld style application as they begin to use the environment. Ana -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10714] - JSP does not compile if useBean tag refers to bean w/o package name in WEB-INF/classes
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=10714. 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=10714 JSP does not compile if useBean tag refers to bean w/o package name in WEB-INF/classes [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-07-11 21:16 --- You must specify: %@ page import=NoPackageBean % Otherwise the compiler will look in the same package as the JSP page. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10710] - Tomcat will not serve a file with %25 in the URI
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=10710. 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=10710 Tomcat will not serve a file with %25 in the URI [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-07-11 21:40 --- In 4.0.x, this is done for security reasons, and will not be fixed. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10714] - JSP does not compile if useBean tag refers to bean w/o package name in WEB-INF/classes
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=10714. 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=10714 JSP does not compile if useBean tag refers to bean w/o package name in WEB-INF/classes --- Additional Comments From [EMAIL PROTECTED] 2002-07-11 22:24 --- This is not a very intuitive workaround. I doubt it that a beginner user who finds that the bean that they tried to use is not available, and who understands the nature of the problem will be able to figure out that adding an import statement would going to fix it. I think it's worth addressing this because it raises the bar of entry for the technology and I have seen people being stumped by this issue several times. I looked at the spec and it doesn't say anything explicit about package names for Beans, though of course all the examples of beans have fully qualified names in them. It could be argued that this could be resolved by simply clarifying the spec, but it seems like a backwards argument to me: it's an argument on how the JSP should behave on the basis of the default behaviour of servlets. But the intended audience of JSP includes page authors who are not necessarily familiar with servlets. I think it would be equally valid to argue that the JSP classloader should resolve this type of situation. Also, clarifying it at the level of the spec won't help beginner web tier programmers, who typically won't read the spec. I guess the current behaviour of Tomcat is spec compliant anyway, and I'll take this to JSR 152. Ana -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Include directive in Tomcat4
This question should really be asked on tomcat-users. You cannot use the context path in an include. If you want to deploy this with the full paths, deploy it as the default webapp, ie with / as the context path (into webapps/ROOT). -Original Message- From: Alfian Hadi [mailto:[EMAIL PROTECTED]] Sent: 10 July 2002 05:17 To: [EMAIL PROTECTED] Subject: Include directive in Tomcat4 Hi all, I am facing problem using include directive in tomcat 4.0.4. Here is the situation: I create a new folder named: test under webapps (webapps/test). The folder test contains two files: - index.jsp - hello.html In index.jsp, this is what I have for the directive: %@ include file = /test/hello.html % Then I received this error: org.apache.jasper.compiler.CompileException: /index.jsp(3,38) File /test/hello.html not found It seems that I cannot use the absolute path for include directive with tomcat. This is just a simple sample. Actually I have a working JSP application that I need to deploy on tomcat 4 and it cannot work because the application use a lot of absolute path for the include directive. Any ideas ? Thanks. - Alfian - -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10714] - JSP does not compile if useBean tag refers to bean w/o package name in WEB-INF/classes
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=10714. 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=10714 JSP does not compile if useBean tag refers to bean w/o package name in WEB-INF/classes --- Additional Comments From [EMAIL PROTECTED] 2002-07-12 00:12 --- The real problem is that, as of JDK1.4, you can no longer import afile that is not in a package. See http://java.sun.com/j2se/1.4/compatibility.html under Source Compatibility,item 8, second subitem: The compiler now rejects import statements that import a type from the unnamed namespace This probably accounts forthe original bug report. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10720] New: - bug 6400 Tag Libraries not deploying in 4.0.2 final - Linux - Resolved ?
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=10720. 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=10720 bug 6400 Tag Libraries not deploying in 4.0.2 final - Linux - Resolved ? Summary: bug 6400 Tag Libraries not deploying in 4.0.2 final - Linux - Resolved ? Product: Tomcat 4 Version: 4.0.4 Final Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: Major Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hello. I'm facing the BUG 6400 under a Linux Redhat 7.2 Jar Taglibs are not deploying. :( JDK: Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.3.1-FCS) Java HotSpot(TM) Client VM (build Blackdown-1.3.1-FCS, mixed mode) TOMCAT: 4.0.4 Final here are an extract of taglib.tld under xxx.jar\METAINF (The xxx.JAR in under WEB-INF\lib) ?xml version=1.0 encoding=ISO-8859-1 ? !DOCTYPE taglib PUBLIC -//Sun Microsystems, Inc.//DTD JSP Tag Library 1.2//EN http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd; taglib tlib-version1.2/tlib-version jsp-version1.2/jsp-version short-nametest/short-name uri/test/uri . . . /taglib At JSP..: %@ taglib uri=/test prefix=test % And, I have the following error: org.apache.jasper.JasperException: File /test not found at org.apache.jasper.compiler.TagLibraryInfoImpl. (TagLibraryInfoImpl.java:214) at org.apache.jasper.compiler.TagLibraryInfoImpl. (TagLibraryInfoImpl.java:174) I tested creating a temp directory under CATALINA_HOME. And it doesn't works either. Thanks -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10720] - bug 6400 Tag Libraries not deploying in 4.0.2 final - Linux - Resolved ?
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=10720. 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=10720 bug 6400 Tag Libraries not deploying in 4.0.2 final - Linux - Resolved ? --- Additional Comments From [EMAIL PROTECTED] 2002-07-12 00:37 --- Hello. I'm facing the BUG 6400 under a Linux Redhat 7.2 Jar Taglibs are not deploying. :( JDK: Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.3.1-FCS) Java HotSpot(TM) Client VM (build Blackdown-1.3.1-FCS, mixed mode) TOMCAT: 4.0.4 Final here are an extract of taglib.tld under xxx.jar\METAINF (The xxx.JAR in under WEB-INF\lib) ?xml version=1.0 encoding=ISO-8859-1 ? !DOCTYPE taglib PUBLIC -//Sun Microsystems, Inc.//DTD JSP Tag Library 1.2//EN http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd; taglib tlib-version1.2/tlib-version jsp-version1.2/jsp-version short-nametest/short-name uri/test/uri . . . /taglib At JSP..: %@ taglib uri=/test prefix=test % And, I have the following error: org.apache.jasper.JasperException: File /test not found at org.apache.jasper.compiler.TagLibraryInfoImpl. (TagLibraryInfoImpl.java:214) at org.apache.jasper.compiler.TagLibraryInfoImpl. (TagLibraryInfoImpl.java:174) I tested creating a temp directory under CATALINA_HOME. And it doesn't works either. Thanks -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
