DO NOT REPLY [Bug 9829] New: - HotSpot Virtual Machine Error with jsp includes jstl
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=9829. 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=9829 HotSpot Virtual Machine Error with jsp includes jstl Summary: HotSpot Virtual Machine Error with jsp includes jstl Product: Tomcat 4 Version: 4.0.3 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Critical Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] - Original Bug Report--- category : hotspot release : 1.4 subcategory : runtime_system type : bug synopsis : HotSpot Virtual Machine Error with jsp includes jstl description : FULL PRODUCT VERSION : java version 1.4.0 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b9 Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode) FULL OPERATING SYSTEM VERSION : Microsoft Windows 2000 [Version 5.00.2195] EXTRA RELEVANT SYSTEM CONFIGURATION : Server used : Tomcat-Standalone Apache Tomcat/4.0.3 Taglibs used : jakarta-taglibs-standard-20020514 A DESCRIPTION OF THE PROBLEM : When the server crash the following message appears : # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.0-b92 mixed mode) # # Error ID: 47454E45524154452F4F502D41500E4350500848 # # Problematic Thread: prio=5 tid=0x0BEF2AB8 nid=0x3ac runnable # I use jsp with jstl for big forms which parse xml documents so I have a regular structure that must appears with parameters change. This structure is the following : - table border =0 cellspacing=0 cellpadding=0 tr td1/tdtd2/tdtd3/tdtd4/tdtd5/tdtd6/tdtd7/tdtd8/td td9/td /tr tr tdx:out select=$globalResults/Responses/Chapter [@IDChapter='1']/Response[@row = 1 and @col = 3]/Item [@Value=1]//td tdx:out select=$globalResults/Responses/Chapter [@IDChapter='1']/Response[@row = 1 and @col = 3]/Item [@Value=2]//td tdx:out select=$globalResults/Responses/Chapter [@IDChapter='1']/Response[@row = 1 and @col = 3]/Item [@Value=3]//td tdx:out select=$globalResults/Responses/Chapter [@IDChapter='1']/Response[@row = 1 and @col = 3]/Item [@Value=4]//td tdx:out select=$globalResults/Responses/Chapter [@IDChapter='1']/Response[@row = 1 and @col = 3]/Item [@Value=5]//td tdx:out select=$globalResults/Responses/Chapter [@IDChapter='1']/Response[@row = 1 and @col = 3]/Item [@Value=6]//td tdx:out select=$globalResults/Responses/Chapter [@IDChapter='1']/Response[@row = 1 and @col = 3]/Item [@Value=7]//td tdx:out select=$globalResults/Responses/Chapter [@IDChapter='1']/Response[@row = 1 and @col = 3]/Item [@Value=8]//td tdx:out select=$globalResults/Responses/Chapter [@IDChapter='1']/Response[@row = 1 and @col = 3]/Item [@Value=9]//td /tr /table - When I paste this structure more than n times, the server crashs. STEPS TO FOLLOW TO REPRODUCE THE PROBLEM : 1. paste multiple time valid structure in jsp page 2. when this number is sufficient, the server crash EXPECTED VERSUS ACTUAL BEHAVIOR : the page must appears correctly as when there is one structure less ERROR MESSAGES/STACK TRACES THAT OCCUR : # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.0-b92 mixed mode) # # Error ID: 47454E45524154452F4F502D41500E4350500848 # # Problematic Thread: prio=5 tid=0x0BEF2AB8 nid=0x3ac runnable # This bug can be reproduced always. -- BEGIN SOURCE -- I think you just had to past a lot of same access structure to data with jstl like : table border =0 cellspacing=0 cellpadding=0 tr tdx:out select=$globalResults/Responses/Chapter[@IDChapter='1']/Response [@row = 1 and @col = 3]/Item[@Value=1]//td tdx:out select=$globalResults/Responses/Chapter[@IDChapter='1']/Response [@row = 1 and @col = 3]/Item[@Value=2]//td tdx:out select=$globalResults/Responses/Chapter[@IDChapter='1']/Response [@row = 1 and @col = 3]/Item[@Value=3]//td tdx:out select=$globalResults/Responses/Chapter[@IDChapter='1']/Response [@row = 1 and @col = 3]/Item[@Value=4]//td tdx:out select=$globalResults/Responses/Chapter[@IDChapter='1']/Response [@row = 1 and @col = 3]/Item[@Value=5]//td tdx:out select=$globalResults/Responses/Chapter[@IDChapter='1']/Response [@row = 1 and @col = 3]/Item[@Value=6]//td tdx:out select=$globalResults/Responses/Chapter[@IDChapter='1']/Response [@row = 1 and @col = 3]/Item[@Value=7]//td tdx:out select=$globalResults/Responses/Chapter[@IDChapter='1']/Response [@row = 1 and @col = 3]/Item[@Value=8]//td
Re: Help..Tomcat4x+jdk1.3+FreeBSD..Hang Why...
sonam singh wrote: hi I installed the linux-jdk1.3 and linux-ibm-jdk1.3.1 using ports in the FreeBSD. When i tried to run tomcat4+with mentioned JVM machine gets hang...Below is some of the parameter which i tried .. OsJdk TomcatRun/Or Not FreeBSD Sun1.2 4xYes FreeBSD Sun1.3 4xNo(HotSpot Error Unable to Find Pid) ..Why??? FreeBSD Sun1.4 4xNo(HotSpot Error Unable to Find Pid) ..Why??? FreeBSD IBM1.3 4xHang..Why ??? FreeBSD IBM1.3.1 4xHang..Why??? Windows98 IBM1.3 4xRun Windows98 IBM1.3.1 4xRun FreeBSD Sun1.2 3xRun FreeBSD Sun1.3 3xRun FreeBSD Sun1.3.1 3xRun FreeBSD Sun1.4 3xRun FreeBSD IBM1.3 3xRun FreeBSD IBM1.3.1 3xRun 4x:-Tomcat 4.0.1 and Tomcat4.0.3 FreeBSD4.5 Release + Linux_base6 Is there any problem with Tomcat4 or FreeBSD . Tomcat4 runs successfuly even in windows98... Can any body provide me any suggestion TC runs well on the FreeBSD I have access to: +++ bash-2.04$ uname -a FreeBSD deejai2.mch.fsc.net 4.6-RC FreeBSD 4.6-RC #4: Thu May 30 00:09:26 CEST 2002 [EMAIL PROTECTED]:/usr/src/sys/compile/DEEJAI4B i386 bash-2.04$ which java /usr/local/jdk1.3.1/bin/java bash-2.04$ java -version java version 1.3.1-p6 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-p6-martin-020531-11:18) Classic VM (build 1.3.1-p6-martin-020531-11:18, green threads, nojit) +++ The TC (from ps): +++ 38920 p3- S 25:09.33 /usr/local/jdk1.3.1/bin/i386/green_threads/java -Djav +++ The trick was to download the JVM sources apply FreeBSD patches and install the compiled JVM. The TC running on this machine is 4.1.3. Can anybody tell me whos are the developers of tomcat4x Bye Sonam __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- 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 9772] - RequestDispatcher.forward(resource) does not perform necessary checks
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=9772. 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=9772 RequestDispatcher.forward(resource) does not perform necessary checks --- Additional Comments From [EMAIL PROTECTED] 2002-06-13 07:22 --- Because the spec (even if only since 2.3) tells that no checking has to be performed the implemented behavior is OK for me. Status can be changed to WONTFIX (or another appropiate value). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] When Session Max reached, throw out oldest session
[EMAIL PROTECTED] typed the following on 05:22 PM 6/12/2002 -0400 PROPOSAL: When Session Max reached, throw out oldest session ... 1. When the maximum number of sessions is reached, change StandardManager from throwing an IllegalStateException exception, to expiring the Least Recently Used (LRUMap) session. I'm not 100% comfortable with this, if a server sets the max sessions too low and gets a lot of activity, the behavior will be confusing - users will unexpectedly lose logins or whatever their session data is, and it might be taken for a bug by the administrator. I guess I'll be happy as long as we log a warning when sessions are thrown out due to max sessions being exceeded. Kief -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Digest Authentication
I can't get Tomcat 4.1.x to authenticate a Mozilla client when using DIGEST authentication, although it works fine with IE6. The only difference I can see is that IE6 sends an extra algorithm=MD5 attribute in the Authorization header. Has anybody else seen this? Should I enter it as bug? Thanks, Kevin Jones Developmentor www.develop.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Digest again
This is a weird one. I'm using Tomcat 4.1.x. If I use BASIC authentication everything works OK If I use DIGEST authentication and I use the memory realm i.e. I have Realm className=org.apache.catalina.realm.MemoryRealm/ and !-- not used Realm className=org.apache.catalina.realm.UserDatabaseRealm debug=0 resourceName=UserDatabase/ -- then this works (in IE not Mozilla, see a previous post) But, if I reverse the above i.e. I have !-- not used Realm className=org.apache.catalina.realm.MemoryRealm/ -- and Realm className=org.apache.catalina.realm.UserDatabaseRealm debug=0 resourceName=UserDatabase/ then DIGEST doesn't work (BASIC still works) Do I need to add anything else, or should I report this as a bug? Kevin Jones Developmentor www.develop.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9832] New: - Tomcat 4 IIS redirector cannot cope with POST in SSL
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=9832.
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=9832
Tomcat 4 IIS redirector cannot cope with POST in SSL
Summary: Tomcat 4 IIS redirector cannot cope with POST in SSL
Product: Tomcat 4
Version: 4.0.3 Final
Platform: PC
OS/Version: Other
Status: NEW
Severity: Critical
Priority: Other
Component: Connector:JK/AJP (deprecated)
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I have an IIS 5 web site that is SSL enabled. I am using the isapi-
redirector.dll to connect to tomcat 4.0.3 and all works fine except if there is
a post buffer sent. When you try to read the post buffer the web server gets
hung and eventually sends back an out of memory exception.
An easy way to verify this bug would be to use the snoop.jsp page and add the
following code to the page:
String PostBuf = null;
if (request.getContentLength() 0)
{
InputStream in = request.getInputStream();
if (in == null)
{
System.out.println(InputStream was null);
}
else
{
int b;
byte inBuff[] = new byte[4096];
ByteArrayOutputStream ba = new ByteArrayOutputStream();
while ((b = in.read(inBuff)) != -1)
{
ba.write(inBuff, 0, b);
}
PostBuf = new String(ba.toByteArray());
}
}
When send a post to this page -- works fine if on port 8080. But through the
web server using SSL, it hangs
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/webapp/lib pr_info.c pr_warp.c wa_request.c
pier2002/06/13 04:06:48
Modified:webapp/apache-1.3 mod_webapp.c
webapp/apache-2.0 mod_webapp.c
webapp/include wa_request.h
webapp/lib pr_info.c pr_warp.c wa_request.c
Log:
Fixed problem with disappearing HTTP response status code. Thanks to
Stefan Norberg [EMAIL PROTECTED] for keeping up w/ me.
Revision ChangesPath
1.35 +5 -11 jakarta-tomcat-connectors/webapp/apache-1.3/mod_webapp.c
Index: mod_webapp.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/apache-1.3/mod_webapp.c,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- mod_webapp.c 10 May 2002 15:30:17 - 1.34
+++ mod_webapp.c 13 Jun 2002 11:06:47 - 1.35
@@ -292,20 +292,15 @@
}
/* Set the HTTP status of the response. */
-void wam_handler_setstatus(wa_request *r, int status) {
+void wam_handler_setstatus(wa_request *r, int status, char *message) {
request_rec *req=(request_rec *)r-data;
-req-status=status;
-}
-/* Set the HTTP status of the response. */
-void wam_handler_setstatusline(wa_request *r, char * status) {
-request_rec *req=(request_rec *)r-data;
+if ((message!=NULL) (message[0]!='\0'))
+req-status_line=apr_psprintf(req-pool,%03d %s, status, message);
-if (status !=NULL status[0]!='\0')
-req-status_line=apr_pstrdup(req-pool,status);
+req-status=status;
}
-
/* Set the MIME Content-Type of the response. */
void wam_handler_setctype(wa_request *r, char *type) {
request_rec *req=(request_rec *)r-data;
@@ -382,7 +377,6 @@
static wa_handler wam_handler = {
wam_handler_log,
wam_handler_setstatus,
-wam_handler_setstatusline,
wam_handler_setctype,
wam_handler_setheader,
wam_handler_commit,
1.11 +5 -12 jakarta-tomcat-connectors/webapp/apache-2.0/mod_webapp.c
Index: mod_webapp.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/apache-2.0/mod_webapp.c,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- mod_webapp.c 10 May 2002 15:30:17 - 1.10
+++ mod_webapp.c 13 Jun 2002 11:06:47 - 1.11
@@ -294,21 +294,15 @@
}
/* Set the HTTP status of the response. */
-static void wam_handler_setstatus(wa_request *r, int status) {
+static void wam_handler_setstatus(wa_request *r, int status, char *message) {
request_rec *req=(request_rec *)r-data;
-req-status=status;
-}
-
-/* Set the HTTP status of the response. */
-void wam_handler_setstatusline(wa_request *r, char * status) {
-request_rec *req=(request_rec *)r-data;
+if ((message!=NULL) (message[0]!='\0'))
+req-status_line=apr_psprintf(req-pool,%03d %s, status, message);
-if (status !=NULL status[0]!='\0')
-req-status_line=apr_pstrdup(req-pool,status);
+req-status=status;
}
-
/* Set the MIME Content-Type of the response. */
static void wam_handler_setctype(wa_request *r, char *type) {
request_rec *req=(request_rec *)r-data;
@@ -390,7 +384,6 @@
static wa_handler wam_handler = {
wam_handler_log,
wam_handler_setstatus,
-wam_handler_setstatusline,
wam_handler_setctype,
wam_handler_setheader,
wam_handler_commit,
1.12 +3 -5 jakarta-tomcat-connectors/webapp/include/wa_request.h
Index: wa_request.h
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/include/wa_request.h,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- wa_request.h 10 May 2002 15:30:17 - 1.11
+++ wa_request.h 13 Jun 2002 11:06:48 - 1.12
@@ -94,8 +94,7 @@
*/
struct wa_handler {
void (*log)(wa_request *r, const char *file, const int line, char *msg);
-void (*setstatus)(wa_request *r, int status);
-void (*setstatusline)(wa_request *r, char *status);
+void (*setstatus)(wa_request *r, int status, char *message);
void (*setctype)(wa_request *r, char *type);
void (*setheader)(wa_request *r, char *name, char *value);
void (*commit)(wa_request *r);
@@ -188,8 +187,7 @@
int wa_rinvoke(wa_request *r, wa_application *a);
void wa_rlog(wa_request *r, const char *f, const int l, const char *fmt, ...);
-void wa_rsetstatus(wa_request *r, int status);
-void wa_rsetstatusline(wa_request *r, char *status);
+void wa_rsetstatus(wa_request *r, int status, char *message);
void wa_rsetctype(wa_request *r, char *type);
void wa_rsetheader(wa_request *r, char *name, char *value);
void wa_rcommit(wa_request *r);
1.6 +2 -2
Re: [PROPOSAL] When Session Max reached, throw out oldest session
On Thu, 2002-06-13 at 03:43, Kief Morris wrote: [EMAIL PROTECTED] typed the following on 05:22 PM 6/12/2002 -0400 PROPOSAL: When Session Max reached, throw out oldest session ... 1. When the maximum number of sessions is reached, change StandardManager from throwing an IllegalStateException exception, to expiring the Least Recently Used (LRUMap) session. I'm not 100% comfortable with this, if a server sets the max sessions too low and gets a lot of activity, the behavior will be confusing - users will unexpectedly lose logins or whatever their session data is, and it might be taken for a bug by the administrator. I guess I'll be happy as long as we log a warning when sessions are thrown out due to max sessions being exceeded. Good idea, I will be sure to log the expiration event, and I will also ensure that the admin documentation is updated to explain this behavior. Cheers, -bob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JNDI with a custom factory not working
- Original Message - From: Ian Darwin [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED]; Arshad Mahmood [EMAIL PROTECTED] Sent: Thursday, June 13, 2002 1:48 AM Subject: Re: JNDI with a custom factory not working On June 12, 2002 07:45 am, Arshad Mahmood wrote: I am having a problem trying to use a custom factory with JNDI. I get an exception froom org.apache.naming.factory.ResourceFactory. I have added debug and it appears that my factory parameter is not being picked up from the server.xml. Can somebody familiar with the naming code point me to the classes I need to look at to trace this problem. Alternatively, if somebody can confirm that the JNDI-Howto example for a custom beanFactory works correctly in 4.1 (I have tried it and it doesn't) then I will look at my configuration again. Doesn't work for me either. Inserting a listBindings() call for java:comp/env/bean reveals nothing bound there. I have traced the problem a little further and I think I know what the problem is but I haven't got a clue how to fix it. Basically, it appears that a different NamingContext is created per thread/class loader. Let's assume that you have a tomcat instance called Standalone, a virtual host localhost and a context myapp. If you define any JNDI resources in the server.xml, then they appear to be put into a naming context call //Standalone/myapp. Your resource definitions in the web.xml go into the //Standalone/localhost/myapp context. If you attempt to read the resources from your servlet then the //Standalone/localhost/myapp context is used, this is ok for jdbc, etc because the factory is hardwired into the naming code. But if you have defined a custom factory then no definition exists in this context for that (because it's been put into the //Standalone/myapp context). I believe this also goes for any parameters that you have defined. The fix would appear to be for Tomcat to put the resources under the virtual in the first place for those defined in the server.xml. There is still an issue though for the global resources as I am not sure you can link to them because they are under a different naming context. This is an initial investigation so my analysis may be FLAWED. Remy, does this explanation of how the naming contexts are defined/used make sense ? Regards. -- 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 8013] - DefaultServlet Throws NumberFormatException
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=8013. 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=8013 DefaultServlet Throws NumberFormatException --- Additional Comments From [EMAIL PROTECTED] 2002-06-13 13:01 --- Created an attachment (id=2080) This code illustrates the multi-threading issue with the SimpleDateFormat class, but it is very inconsistent. Must be some obscure race condition. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Error 500, mod_jk issues
We're running Tomcat 4.0.3 on RedHat w/ Apache 1.3 via the mod_jk connector. We received an Error 500, which usually indicates that Tomcat is no longer running. However in this case it was, it hadn't crashed. A quick survey of the logs found these... In catalina.out: Ajp13Connector[8011] No processor available, rejecting this connection In mod_jk.log: [Wed Jun 12 13:37:04 2002] [jk_ajp13_worker.c (381)]: Error ajp13_process_callback - write failed Anyone seen this before? Is it related to this: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6068 ? Our native connector binary might be a bit old. The name of the precompiled binary we're using is mod_jk-3.3-ap13-eapi.so. Any ideas? Should we be using the mod_jk-01.so binary from the 4.0.3 build? Thanks, Nick Wesselman Digital Visions, Inc. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6068] - AJP13 bad read, IOException
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=6068. 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=6068 AJP13 bad read, IOException --- Additional Comments From [EMAIL PROTECTED] 2002-06-13 14:07 --- Will this fix make it into 4.0.4? -- 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/servlets HTMLManagerServlet.java LocalStrings.properties
glenn 2002/06/13 07:58:01 Modified:catalina/src/share/org/apache/catalina/servlets HTMLManagerServlet.java LocalStrings.properties Log: More improvements to HTMLManagerServlet, thanks to Malcolm Edgar Revision ChangesPath 1.8 +166 -144 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/HTMLManagerServlet.java Index: HTMLManagerServlet.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/HTMLManagerServlet.java,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- HTMLManagerServlet.java 10 Jun 2002 19:19:23 - 1.7 +++ HTMLManagerServlet.java 13 Jun 2002 14:58:01 - 1.8 @@ -1,65 +1,65 @@ /* - * $Header$ - * $Revision$ - * $Date$ - * - * - * - * The Apache Software License, Version 1.1 - * - * Copyright (c) 1999 The Apache Software Foundation. All rights - * reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * - * 1. Redistributions of source code must retain the above copyright - *notice, this list of conditions and the following disclaimer. - * - * 2. Redistributions in binary form must reproduce the above copyright - *notice, this list of conditions and the following disclaimer in - *the documentation and/or other materials provided with the - *distribution. - * - * 3. The end-user documentation included with the redistribution, if - *any, must include the following acknowlegement: - * This product includes software developed by the - *Apache Software Foundation (http://www.apache.org/). - *Alternately, this acknowlegement may appear in the software itself, - *if and wherever such third-party acknowlegements normally appear. - * - * 4. The names The Jakarta Project, Tomcat, and Apache Software - *Foundation must not be used to endorse or promote products derived - *from this software without prior written permission. For written - *permission, please contact [EMAIL PROTECTED] - * - * 5. Products derived from this software may not be called Apache - *nor may Apache appear in their names without prior written - *permission of the Apache Group. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED - * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES - * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE - * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR - * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF - * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND - * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, - * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT - * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF - * SUCH DAMAGE. - * - * - * This software consists of voluntary contributions made by many - * individuals on behalf of the Apache Software Foundation. For more - * information on the Apache Software Foundation, please see - * http://www.apache.org/. - * - * [Additional notices, if required by prior licensing conditions] - * - */ +* $Header$ +* $Revision$ +* $Date$ +* +* +* +* The Apache Software License, Version 1.1 +* +* Copyright (c) 1999 The Apache Software Foundation. All rights +* reserved. +* +* Redistribution and use in source and binary forms, with or without +* modification, are permitted provided that the following conditions +* are met: +* +* 1. Redistributions of source code must retain the above copyright +*notice, this list of conditions and the following disclaimer. +* +* 2. Redistributions in binary form must reproduce the above copyright +*notice, this list of conditions and the following disclaimer in +*the documentation and/or other materials provided with the +*distribution. +* +* 3. The end-user documentation included with the redistribution, if +*any, must include the following acknowlegement: +* This product includes software developed by the +*Apache Software Foundation (http://www.apache.org/). +*Alternately, this acknowlegement may appear in the software itself, +*if and wherever such third-party acknowlegements normally appear. +* +*
DO NOT REPLY [Bug 9772] - RequestDispatcher.forward(resource) does not perform necessary checks
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=9772. 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=9772 RequestDispatcher.forward(resource) does not perform necessary checks [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Bug #8013
Could someone please take a look at this bug? There is an obvious with the DefaultServlet, but it has not been resolved. I have posted a patch (which may need a try/catch block, by the way) and a test case that illustrates the problem, but it has yet to be fixed. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper2: jspc and JspCompilationContext
[EMAIL PROTECTED] wrote: There are few bugs in jspc, mostly related with the generation of the class name and the mangling. Ooops, sorry, I thought I got it right. At least for the examples webapp, it did appear to work good. It is quite hard to un-spaghetti the code without beaking anything :-( What is the problem exactly ? (or maybe you fixed it already, in which case, just commit the fix :)) It seems CommandLineCtx and JspEngineContext are almost completely duplicated. Yes, I was using your refactoring techniques to have them be more and more equivalent, until they can be removed. I think we're almost there. I did a small change and turned JspCompilationContext into an abstract class, with all the code from JspEngineContext that deals with marshalling ( and is duplicated in CLCtx ). The abstract methods are those dealing with class loader and with getting resources. Is it ok to commit it ? +1. I thought about doing it myself ;-) The goal eventually is to remove the need for having two different context classes. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8013] - DefaultServlet Throws NumberFormatException
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=8013. 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=8013 DefaultServlet Throws NumberFormatException --- Additional Comments From [EMAIL PROTECTED] 2002-06-13 16:19 --- Don't worry, I plan to apply the patch; it's just that I was a bit short on time. -- 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/core StandardWrapper.java
remm2002/06/13 09:27:24
Modified:catalina/src/share/org/apache/catalina/core
StandardWrapper.java
Log:
- Do not wait forever if a servlet doesn't want to shut itself down.
- Now the wait is 10 * 50ms.
- Fixes bug 8935, and probably a few others.
Revision ChangesPath
1.38 +9 -9
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardWrapper.java
Index: StandardWrapper.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardWrapper.java,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- StandardWrapper.java 20 Feb 2002 07:09:24 - 1.37
+++ StandardWrapper.java 13 Jun 2002 16:27:23 - 1.38
@@ -1064,18 +1064,18 @@
// Loaf a while if the current instance is allocated
// (possibly more than once if non-STM)
if (countAllocated 0) {
-boolean first = true;
-while (countAllocated 0) {
-if (first) {
+int nRetries = 0;
+while (nRetries 10) {
+if (nRetries == 0) {
log(Waiting for + countAllocated +
instance(s) to be deallocated);
-first = false;
}
try {
-Thread.sleep(1000);
+Thread.sleep(50);
} catch (InterruptedException e) {
;
}
+nRetries++;
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8935] - Deadlock with reload in manager
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8935. 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=8935 Deadlock with reload in manager [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-06-13 16:28 --- I have changed that to use a timeout. The fix will be in Tomcat 4.1.5. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JNDI with a custom factory not working
Arshad Mahmood wrote: - Original Message - From: Ian Darwin [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED]; Arshad Mahmood [EMAIL PROTECTED] Sent: Thursday, June 13, 2002 1:48 AM Subject: Re: JNDI with a custom factory not working On June 12, 2002 07:45 am, Arshad Mahmood wrote: I am having a problem trying to use a custom factory with JNDI. I get an exception froom org.apache.naming.factory.ResourceFactory. I have added debug and it appears that my factory parameter is not being picked up from the server.xml. Can somebody familiar with the naming code point me to the classes I need to look at to trace this problem. Alternatively, if somebody can confirm that the JNDI-Howto example for a custom beanFactory works correctly in 4.1 (I have tried it and it doesn't) then I will look at my configuration again. Doesn't work for me either. Inserting a listBindings() call for java:comp/env/bean reveals nothing bound there. I have traced the problem a little further and I think I know what the problem is but I haven't got a clue how to fix it. Basically, it appears that a different NamingContext is created per thread/class loader. Let's assume that you have a tomcat instance called Standalone, a virtual host localhost and a context myapp. If you define any JNDI resources in the server.xml, then they appear to be put into a naming context call //Standalone/myapp. Your resource definitions in the web.xml go into the //Standalone/localhost/myapp context. If you attempt to read the resources from your servlet then the //Standalone/localhost/myapp context is used, this is ok for jdbc, etc because the factory is hardwired into the naming code. But if you have defined a custom factory then no definition exists in this context for that (because it's been put into the //Standalone/myapp context). I believe this also goes for any parameters that you have defined. The fix would appear to be for Tomcat to put the resources under the virtual in the first place for those defined in the server.xml. There is still an issue though for the global resources as I am not sure you can link to them because they are under a different naming context. This is an initial investigation so my analysis may be FLAWED. Remy, does this explanation of how the naming contexts are defined/used make sense ? I'm not sure I understand very well, so I'll assume it's a problem with the links. The global resources defined in server.xml are not accessible by default in the web applications (because you may want to restrict some to specific webapps, etc). So you have to link them using a ResourceLink element. You can also define the resource links in the default context so that all your contexts in your host or engine will have the link, instead of having to define it in each one. The admin webapp will have full support for this shortly (I reckon that configuring this is *hard* at the moment). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9846] New: - sendRedirect using FTP
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=9846. 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=9846 sendRedirect using FTP Summary: sendRedirect using FTP Product: Tomcat 4 Version: 4.0.3 Final Platform: Sun OS/Version: Solaris Status: NEW Severity: Blocker Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Under this release of tomcat, I'm trying to send the following string in a sendRedirect ftp://ftptest:[EMAIL PROTECTED]/;. I receive java.lang.IllegalArgumentException: ftp://ftptest:[EMAIL PROTECTED]/ at org.apache.catalina.connector.HttpResponseBase.toAbsolute(HttpResponseBase.java:698) at org.apache.catalina.connector.HttpResponseBase.encodeRedirectURL(HttpResponseBase.java:959) at org.apache.catalina.connector.HttpResponseFacade.encodeRedirectURL(HttpResponseFacade.java:127) If I pass a string to a anonymous ftp site it works. Only when passing user and password does it fail. On another system using Tomcat 3.x it works as advertized. Also If I type the ftp URL directly in it works. Jim -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
tomcat 4.0 nightly builds broken since 5/30
The tomcat nightly builds are broken since 5/30. This is the last day before no good downloadable builds will be available. http://jakarta.apache.org/builds/jakarta-tomcat-4.0/ http://www.wiserlabz.com collaborative effort to promote Novell and Open Source Solutions -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JNDIRealm maintenance
John Holman wrote: Remy I wrote the original JNDIRealm which Craig committed with modifications, made major enhancements in March this year and submitted documentation updates a couple of times since (which have still not been committed). I'm prepared to maintain this component, but the difficulty of finding anyone with the time and interest to review and commit patches is a real problem, especially since Craig's involvement has reduced. Commit access would help - but the recent discussion in Jakarta indicates that more is expected of a committer than maintaining a single component so maybe that is not appropriate. Any suggestions? Regards, John. Yes, I can understand that. Apparently, slighytly more is needed now to get commit access. I can commit your patches until you get commit access. You can repost patches if they are not applied fast enough ;-) Thanks, Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Performance of JNI calls
Hi,
I've seen in the JNI aprImpl the JK_DIRECT_BUFFER_NIO flag that is newer
used.
IMO the purpose would be to use the java.nio. Package available in the
java 1.4 and JNI 1.4 specification.
Now, I've done some testing and found couple of ineresting things that I
would like to clear out.
Don't know if the testing code is valid but briefly here are some facts.
The direct buffering is slower (!) then standard byte array if there is
no copy, but faster about 20% if the array gets copied.
The most important thing that bothers me is that the java is more then 2
times slower then the GetByteArrayRegion version.
Now, I allway tought that JNI calls imposes serious performance
degradation, but I'm not so sure now.
Any comments?
MT.
jniperf.gif
Description: GIF image
NioTest.java
Description: Binary data
#include jni.h
#include stdlib.h
jint standardSize = 0;
jint advancedSize = 0;
jbyte *advancedBuffer = NULL;
jbyte *standardBuffer = NULL;
JNIEXPORT void JNICALL Java_NioTest_initStandardNative
(JNIEnv * env, jclass c, jint nSize)
{
standardSize = nSize;
standardBuffer = (jbyte *)calloc(standardSize, sizeof(jbyte));
}
JNIEXPORT void JNICALL Java_NioTest_initAdvancedNative
(JNIEnv * env, jclass c, jobject theBytes)
{
if (theBytes) {
advancedBuffer = (jbyte *)((*env)-GetDirectBufferAddress(env,theBytes));
}
if (advancedBuffer) {
advancedSize = (jint)((*env)-GetDirectBufferCapacity(env,theBytes));
memset(advancedBuffer, 0, advancedSize);
}
}
JNIEXPORT jint JNICALL Java_NioTest_callStandardNative
(JNIEnv * env, jclass c, jbyteArray theBytes)
{
jint i;
jbyte *buffer=NULL;
jboolean iscopy;
jint rv = 0;
buffer = (jbyte *)((*env)-GetByteArrayElements(env, theBytes, iscopy));
if (buffer) {
for (i = 0; i standardSize; i++) {
buffer[i] += (jbyte)i;
rv += buffer[i];
}
}
(*env)-ReleaseByteArrayElements(env, theBytes, buffer, 0);
return rv;
}
JNIEXPORT jint JNICALL Java_NioTest_callStandardNativeC
(JNIEnv * env, jclass c, jbyteArray theBytes)
{
jint i;
jint rv = 0;
(*env)-GetByteArrayRegion(env,theBytes,0,standardSize,standardBuffer);
for (i = 0; i standardSize; i++) {
standardBuffer[i] += (jbyte)i;
rv += standardBuffer[i];
}
(*env)-SetByteArrayRegion(env,theBytes,0,standardSize,standardBuffer);
return rv;
}
JNIEXPORT jint JNICALL Java_NioTest_callAdvancedNative
(JNIEnv * env, jclass c)
{
jint i;
jint rv = 0;
for (i = 0; i advancedSize; i++) {
advancedBuffer[i] += (jbyte)i;
rv += advancedBuffer[i];
}
return rv;
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: tomcat 4.0 nightly builds broken since 5/30
[EMAIL PROTECTED] wrote: The tomcat nightly builds are broken since 5/30. This is the last day before no good downloadable builds will be available. http://jakarta.apache.org/builds/jakarta-tomcat-4.0/ The plan is to rely on Gump for the nightlies. There were some issues, which got fixed. Now, we may have to wait a bit for a build to succeed ;-) My plan is to release a new Tomcat 4.1.5 milestone today or tomorrow. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JNDI with a custom factory not working
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, June 13, 2002 5:33 PM Subject: Re: JNDI with a custom factory not working Arshad Mahmood wrote: - Original Message - From: Ian Darwin [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED]; Arshad Mahmood [EMAIL PROTECTED] Sent: Thursday, June 13, 2002 1:48 AM Subject: Re: JNDI with a custom factory not working On June 12, 2002 07:45 am, Arshad Mahmood wrote: I am having a problem trying to use a custom factory with JNDI. I get an exception froom org.apache.naming.factory.ResourceFactory. I have added debug and it appears that my factory parameter is not being picked up from the server.xml. Can somebody familiar with the naming code point me to the classes I need to look at to trace this problem. Alternatively, if somebody can confirm that the JNDI-Howto example for a custom beanFactory works correctly in 4.1 (I have tried it and it doesn't) then I will look at my configuration again. Doesn't work for me either. Inserting a listBindings() call for java:comp/env/bean reveals nothing bound there. I have traced the problem a little further and I think I know what the problem is but I haven't got a clue how to fix it. Basically, it appears that a different NamingContext is created per thread/class loader. Let's assume that you have a tomcat instance called Standalone, a virtual host localhost and a context myapp. If you define any JNDI resources in the server.xml, then they appear to be put into a naming context call //Standalone/myapp. Your resource definitions in the web.xml go into the //Standalone/localhost/myapp context. If you attempt to read the resources from your servlet then the //Standalone/localhost/myapp context is used, this is ok for jdbc, etc because the factory is hardwired into the naming code. But if you have defined a custom factory then no definition exists in this context for that (because it's been put into the //Standalone/myapp context). I believe this also goes for any parameters that you have defined. The fix would appear to be for Tomcat to put the resources under the virtual in the first place for those defined in the server.xml. There is still an issue though for the global resources as I am not sure you can link to them because they are under a different naming context. This is an initial investigation so my analysis may be FLAWED. Remy, does this explanation of how the naming contexts are defined/used make sense ? I'm not sure I understand very well, so I'll assume it's a problem with the links. The global resources defined in server.xml are not accessible by default in the web applications (because you may want to restrict some to specific webapps, etc). So you have to link them using a ResourceLink element. You can also define the resource links in the default context so that all your contexts in your host or engine will have the link, instead of having to define it in each one. The admin webapp will have full support for this shortly (I reckon that configuring this is *hard* at the moment). Remy Remy, Thanks for you response. I didn't make myself very clear, I'll try again. The Problem = In the server.xml have defined a global resourcce under the name rohas/filecache. The resource params defines a factory along with other attributes. In my context I have defined a ResourceLink that maps to the global name (I have given them both the same name, I assume that doesn't make a difference). In the web.xml for my application I have defined a resource-ref that points to this resource. When I try and access the resource via an InitialContext in the init function of my servlet, I get a NamingException from org.apache.naming.factory.ResourceFactory.getObjectInstance. To look into the problem I put some debug into the org.apache.naming.NamingContext class in the lookup method. I noticed that when this class was called a few times, the name member varied between //Standalone/myapp amd //Standalone/localhost/myapp, etc. I was a bit surprised because I thought when I asked java:comp/env I would always get the same NamingContext and not different ones. I then traced the code through org.apache.naming.java.javaURLContextFactory, which in turn uses org.apache.naming.SelectorContext. The SelectorConext class uses getBoundContext to retrieve the appropriate NamingContext to which it delegated the lookup/bind/unbind, etc. The getBoundContext then uses ContextBindings.getContext to get the context (if doesn't exist then it creates a new one). *** IMPORTANT *** The member variable initialContext is overriden inside the if of this function (is this intentional). ContextBindings appears to return a NamingContext based on the class loader currenty in used. Hence the multiple contexts and why the name I am
Re: JNDI with a custom factory not working
Arshad Mahmood wrote: Remy, Thanks for you response. I didn't make myself very clear, I'll try again. The Problem = In the server.xml have defined a global resourcce under the name rohas/filecache. The resource params defines a factory along with other attributes. In my context I have defined a ResourceLink that maps to the global name (I have given them both the same name, I assume that doesn't make a difference). In the web.xml for my application I have defined a resource-ref that points to this resource. When I try and access the resource via an InitialContext in the init function of my servlet, I get a NamingException from org.apache.naming.factory.ResourceFactory.getObjectInstance. There was a simple bug until very recently which caused the resource defined in web.xml to override the one defined in server.xml (and then it didn't work). This bug has always been there, and it has been fixed to some extent in 4.1.3, although it is a partial fix (4.1.4 fixes the remaining issues). To look into the problem I put some debug into the org.apache.naming.NamingContext class in the lookup method. I noticed that when this class was called a few times, the name member varied between //Standalone/myapp amd //Standalone/localhost/myapp, etc. There is only one naming context per web application, and it is instantiated by the NamingContextListener. I don't understand how you get into that situation, and it is working fine for me overall (ie, if I do a lookup in a servlet, it always goes to the same context). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Performance of JNI calls
I'm impressed ! Did I mentioned that I love working on tomcat ( even with all the flames and 'issues' and politics ) ? On Thu, 13 Jun 2002, Mladen Turk wrote: I've seen in the JNI aprImpl the JK_DIRECT_BUFFER_NIO flag that is newer used. What's missing ( the most ) is a MsgAjp and MessageBytes impl. with a NIO ByteBuffer instead of byte[] as backend. I already put the hooks to allow a different version of MessageBytes to be used ( well, at least I tried to cover this extension - it may need some adjustmentes to deal with the conditioanl compilation ). IMO the purpose would be to use the java.nio. Package available in the java 1.4 and JNI 1.4 specification. Yes, if JDK1.4 is detected we should use NIO, and if not we should fall back. That was the plan - but your tests seem to change that. Don't know if the testing code is valid but briefly here are some facts. The direct buffering is slower (!) then standard byte array if there is no copy, but faster about 20% if the array gets copied. I assume you compare direct buffer with getByteArrayElements() with pinning ??? And the direct buffer is slower ??? The most important thing that bothers me is that the java is more then 2 times slower then the GetByteArrayRegion version. Not sure I understand. GetByteArrayRegion is supposed to be the slower that GetByteArryaElements if pinning works, and much slower than NIO, at least for any large ( ? ) buffer. At least that's (my) commons sense. Now, I allway tought that JNI calls imposes serious performance degradation, but I'm not so sure now. All my tests show that JNI has serious problems - mostly related with strings and buffer allocation/memcpy/etc. Using 'straight' JNI ( i.e. as in the book ) is horrible. But so far the buffer tricks seem to work - at least in my tests, and it seems others ( the mozilla blackwood ) are doing the same. It is possible that NIO has some bugs, but I can't see how they can mess it that badly to make it slower than GetByteArrayRegion or pinning. It's worth investigating - I was planning to work on that after we get a release out, but I'll try to find few hours. ( but first I have to compile some jsps :-) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Performance of JNI calls
Mladen Turk [EMAIL PROTECTED] wrote: The most important thing that bothers me is that the java is more then 2 times slower then the GetByteArrayRegion version. Now, I allway tought that JNI calls imposes serious performance degradation, but I'm not so sure now. That was JDK 1.2... We've gone a long way... It mostly depends on what VM you're trying it out... Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/manager/WEB-INF web.xml
remm2002/06/13 10:38:01 Modified:webapps/manager/WEB-INF web.xml Log: - Map the HTML manager to /html/*. I couldn't find any problems this would create. Revision ChangesPath 1.6 +18 -0 jakarta-tomcat-4.0/webapps/manager/WEB-INF/web.xml Index: web.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/manager/WEB-INF/web.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- web.xml 8 Apr 2002 17:46:08 - 1.5 +++ web.xml 13 Jun 2002 17:38:01 - 1.6 @@ -6,6 +6,12 @@ web-app + display-nameTomcat Manager Application/display-name + description +A scriptable management web application for the Tomcat Web Server; + Manager lets you view, load/unload/etc particular web applications. + /description + !-- Define the Manager Servlet Change servlet-class to: org.apache.catalina.servlets.HTMLManagerServlet to get a Servlet with a more intuitive HTML interface, don't change if you @@ -20,11 +26,23 @@ param-value2/param-value /init-param /servlet + servlet +servlet-nameHTMLManager/servlet-name +servlet-classorg.apache.catalina.servlets.HTMLManagerServlet/servlet-class +init-param + param-namedebug/param-name + param-value2/param-value +/init-param + /servlet !-- Define the Manager Servlet Mapping -- servlet-mapping servlet-nameManager/servlet-name url-pattern/*/url-pattern + /servlet-mapping + servlet-mapping +servlet-nameHTMLManager/servlet-name +url-pattern/html/*/url-pattern /servlet-mapping !-- Define reference to the user database for looking up roles -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/ROOT index.jsp
remm2002/06/13 10:38:28 Modified:webapps/ROOT index.jsp Log: - Link HTML manager. Revision ChangesPath 1.5 +1 -0 jakarta-tomcat-4.0/webapps/ROOT/index.jsp Index: index.jsp === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/ROOT/index.jsp,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- index.jsp 7 Jun 2002 17:50:14 - 1.4 +++ index.jsp 13 Jun 2002 17:38:28 - 1.5 @@ -66,6 +66,7 @@ tr td bgcolor=#FFDC75 bordercolor=#00 nowrap a href=adminTomcat Administration/abr +a href=manager/htmlTomcat Manager/abr nbsp; /td /tr -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JNDI with a custom factory not working
Arshad Mahmood wrote: I do get the same context when I ask for it in my web application. The problem is that I can see from the debug that my Resource definitions in the global naming resources appear to be in one context, Indeed, the global resources go into a separate context. the ResourceLink I have defined in the Context for my webapp go into another, but the one I am given when I use a lookup for java:comp/env in my servlet init function appears to have only those defined in the web.xml. Both of these should go in the same context or its subcontexts (for example, if your resource is jdbc/db, then there will be a jdbc context child of env, which will contain a db entry). Did you try to use the JNDI servlet in the servlet examples to see what was going on ? I believe it is quite useful for this. I realise you are incredibly busy, but if you have naming working, can you please try and generate one with a custom factory. As I have followed the instructions in JNDI-Howto, but the only things in the bindings when I retrieve the java:comp/env are the ones I have defined in the web.xml, and these don't allow you to specify a factory. If the definitions from web.xml override the ones from server.xml, nothing will work (ie, even if you use the default DataSource factory, the reference will be missing some attributes). You can try removing the definition in web.xml to see what happens. BTW, which version of Tomcat are you using ? Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JNDI with a custom factory not working
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, June 13, 2002 6:51 PM Subject: Re: JNDI with a custom factory not working Arshad Mahmood wrote: I do get the same context when I ask for it in my web application. The problem is that I can see from the debug that my Resource definitions in the global naming resources appear to be in one context, Indeed, the global resources go into a separate context. the ResourceLink I have defined in the Context for my webapp go into another, but the one I am given when I use a lookup for java:comp/env in my servlet init function appears to have only those defined in the web.xml. Both of these should go in the same context or its subcontexts (for example, if your resource is jdbc/db, then there will be a jdbc context child of env, which will contain a db entry). Did you try to use the JNDI servlet in the servlet examples to see what was going on ? I believe it is quite useful for this. Hmm, I will investigate further. It seemed to be that ResourceLink in the server.xml Context entry was going into a naming context with name //Standard/myapp but the one which I retrieved from the servlet was called //Standard/localhost/webapp. I will debug this further. I will have a look at the JNDI example servlet. I must confess I was using the JNDI-Howto in the docs. I realise you are incredibly busy, but if you have naming working, can you please try and generate one with a custom factory. As I have followed the instructions in JNDI-Howto, but the only things in the bindings when I retrieve the java:comp/env are the ones I have defined in the web.xml, and these don't allow you to specify a factory. If the definitions from web.xml override the ones from server.xml, nothing will work (ie, even if you use the default DataSource factory, the reference will be missing some attributes). You can try removing the definition in web.xml to see what happens. BTW, which version of Tomcat are you using ? The latest version of 4.1 from CVS (although it's a little broken because MBeanUtils does't compile, but I am not using that anyway). Thanks for your help. I will try and pin the problem down a bit more. Regards. 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: JNDI with a custom factory not working
Arshad Mahmood wrote: Hmm, I will investigate further. It seemed to be that ResourceLink in the server.xml Context entry was going into a naming context with name //Standard/myapp but the one which I retrieved from the servlet was called //Standard/localhost/webapp. I will debug this further. The context name is not important for the global context. The ResourceLink are actually yet another reference which is bound into the webapp naming context, and use a standard JNDI object factory (factory.ResourceLinkFactory). The lookup in the actual global context then just uses a static reference instead of another lookup. I will have a look at the JNDI example servlet. I must confess I was using the JNDI-Howto in the docs. Which may not be totally accurate, and don't talk at all about how it actually works. The latest version of 4.1 from CVS (although it's a little broken because MBeanUtils does't compile, but I am not using that anyway). Really ? It does build for me. What's the problem ? I do get an exception on shutdown, or when removing a context, though. Thanks for your help. I will try and pin the problem down a bit more. Sounds good. Remy -- 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/mbeans MBeanUtils.java
amyroh 2002/06/13 11:14:17
Modified:catalina/src/share/org/apache/catalina/mbeans
MBeanUtils.java
Log:
Changed the MBean names for resources for easier query.
Revision ChangesPath
1.41 +27 -27
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java
Index: MBeanUtils.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java,v
retrieving revision 1.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- MBeanUtils.java 12 Jun 2002 07:39:23 - 1.40
+++ MBeanUtils.java 13 Jun 2002 18:14:17 - 1.41
@@ -930,14 +930,14 @@
String path = ((Context)container).getPath();
if (path.length() 1)
path = /;
-name = new ObjectName(domain + :type=Environment,name= +
- environment.getName() + ,path= +
- path);
+name = new ObjectName(domain + :type=Environment,path= +
+ path + ,name= +
+ environment.getName());
} else if (container instanceof DefaultContext) {
String defaultContextName = ((DefaultContext)container).getName();
-name = new ObjectName(domain + :type=Environment,name= +
- environment.getName() + ,defaultContext= +
- defaultContextName);
+name = new ObjectName(domain + :type=Environment,defaultContext= +
+ defaultContextName + ,name= +
+ environment.getName());
}
return (name);
@@ -964,22 +964,22 @@
resource.getNamingResources().getContainer();
if (container instanceof Server) {
name = new ObjectName(domain + :type=Resource,class= +
- resource.getType()+,name= +
+ resource.getType() + ,name= +
encodedResourceName);
} else if (container instanceof Context) {
String path = ((Context)container).getPath();
if (path.length() 1)
path = /;
-name = new ObjectName(domain + :type=Resource,class= +
- resource.getType()+,name= +
- encodedResourceName + ,path= +
- path);
+name = new ObjectName(domain + :type=Resource,path= +
+ path + ,class= +
+ resource.getType() + ,name= +
+ encodedResourceName);
} else if (container instanceof DefaultContext) {
String defaultContextName = ((DefaultContext)container).getName();
-name = new ObjectName(domain + :type=Resource,class= +
- resource.getType()+,name= +
- encodedResourceName + ,defaultContext= +
- defaultContextName);
+name = new ObjectName(domain + :type=Resource,defaultContext= +
+ defaultContextName + ,class= +
+ resource.getType() + ,name= +
+ encodedResourceName);
}
return (name);
@@ -1006,22 +1006,22 @@
resourceLink.getNamingResources().getContainer();
if (container instanceof Server) {
name = new ObjectName(domain + :type=ResourceLink,class= +
- resourceLink.getType()+,name= +
+ resourceLink.getType() + ,name= +
encodedResourceLinkName);
} else if (container instanceof Context) {
String path = ((Context)container).getPath();
if (path.length() 1)
path = /;
-name = new ObjectName(domain + :type=ResourceLink,class= +
- resourceLink.getType()+,name= +
- encodedResourceLinkName + ,path= +
- path);
+name = new ObjectName(domain + :type=ResourceLink,path= +
+ path + ,class= +
+ resourceLink.getType() + ,name= +
+ encodedResourceLinkName);
} else if (container instanceof DefaultContext) {
String defaultContextName = ((DefaultContext)container).getName();
-name = new ObjectName(domain + :type=ResourceLink,class= +
+name = new ObjectName(domain +
RE: Performance of JNI calls
-Original Message- From: Pier Fumagalli [mailto:[EMAIL PROTECTED]] Sent: 13. lipanj 2002 19:35 To: Tomcat Developers List Cc: [EMAIL PROTECTED] Subject: Re: Performance of JNI calls Mladen Turk [EMAIL PROTECTED] wrote: The most important thing that bothers me is that the java is more then 2 times slower then the GetByteArrayRegion version. Now, I allway tought that JNI calls imposes serious performance degradation, but I'm not so sure now. That was JDK 1.2... We've gone a long way... It mostly depends on what VM you're trying it out... Pier It is. Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03) Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode) If I run the 'standard' test from http://www.str.com.au/jnibench/ Throughput in rows per second (bigger is better) JavaRowConsumer 95556 FineGrainedJNIRowConsumer 64360 CoarseGrainedJNIRowConsumer 53946 BytePackedJNIRowConsumer56328 SocketRowConsumer 15635 Now I've changed the CoarseGrainedJNIRowConsumer to use GetDirectBufferAddress and I'm getting the following results: Throughput in rows per second (bigger is better) JavaRowConsumer 95263 FineGrainedJNIRowConsumer 64360 CoarseGrainedJNIRowConsumer 196949 BytePackedJNIRowConsumer55379 SocketRowConsumer 15399 The direct buffer gains high througput simply couse there is no need to copy the byte arrays. All that was too suspicious for me, so what I've done is the simplest posible test, and the results are far from what my expectation was. MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources DeleteResourceLinksAction.java ListResourceLinksAction.java ResourceLinkForm.java ResourceLinksForm.java SaveResourceLinkAction.java SetUpResourceLinkAction.java
amyroh 2002/06/13 11:34:33 Added: webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources DeleteResourceLinksAction.java ListResourceLinksAction.java ResourceLinkForm.java ResourceLinksForm.java SaveResourceLinkAction.java SetUpResourceLinkAction.java Log: Add incomplete Context Resource Link support in admin tool. Revision ChangesPath 1.1 jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/DeleteResourceLinksAction.java Index: DeleteResourceLinksAction.java === /* * $Header: /home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/DeleteResourceLinksAction.java,v 1.1 2002/06/13 18:34:32 amyroh Exp $ * $Revision: 1.1 $ * $Date: 2002/06/13 18:34:32 $ * * * * The Apache Software License, Version 1.1 * * Copyright (c) 2002 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. The end-envEntry documentation included with the redistribution, if *any, must include the following acknowlegement: * This product includes software developed by the *Apache Software Foundation (http://www.apache.org/). *Alternately, this acknowlegement may appear in the software itself, *if and wherever such third-party acknowlegements normally appear. * * 4. The names The Jakarta Project, Struts, and Apache Software *Foundation must not be used to endorse or promote products derived *from this software without prior written permission. For written *permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache *nor may Apache appear in their names without prior written *permission of the Apache Group. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * * This software consists of voluntary contributions made by many * individuals on behalf of the Apache Software Foundation. For more * information on the Apache Software Foundation, please see * http://www.apache.org/. * */ package org.apache.webapp.admin.resources; import java.io.IOException; import java.util.ArrayList; import java.util.Iterator; import java.util.Locale; import javax.servlet.ServletException; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import javax.servlet.http.HttpSession; import org.apache.struts.action.Action; import org.apache.struts.action.ActionErrors; import org.apache.struts.action.ActionForm; import org.apache.struts.action.ActionForward; import org.apache.struts.action.ActionMapping; import javax.management.Attribute; import javax.management.MBeanServer; import javax.management.MBeanServerFactory; import javax.management.QueryExp; import javax.management.Query; import javax.management.ObjectInstance; import javax.management.ObjectName; import javax.management.JMException; import javax.management.MBeanAttributeInfo; import javax.management.MBeanOperationInfo; import javax.management.MBeanInfo; import org.apache.struts.util.MessageResources; import org.apache.webapp.admin.ApplicationServlet; /** * pImplementation of strongAction/strong that deletes the * specified set of resource links entries./p * * @author Amy Roh *
cvs commit: jakarta-tomcat-4.0/webapps/admin/resources deleteResourceLinks.jsp listResourceLinks.jsp listResourceLinks.jspf resourceLink.jsp resourceLinks.jspf envEntries.jspf
amyroh 2002/06/13 11:34:45 Modified:webapps/admin/resources envEntries.jspf Added: webapps/admin/resources deleteResourceLinks.jsp listResourceLinks.jsp listResourceLinks.jspf resourceLink.jsp resourceLinks.jspf Log: Add incomplete Context Resource Link support in admin tool. Revision ChangesPath 1.5 +1 -1 jakarta-tomcat-4.0/webapps/admin/resources/envEntries.jspf Index: envEntries.jspf === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/admin/resources/envEntries.jspf,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- envEntries.jspf 13 Jun 2002 18:19:48 - 1.4 +++ envEntries.jspf 13 Jun 2002 18:34:45 - 1.5 @@ -33,7 +33,7 @@ tddiv align=left class=table-normal-text html:link page='%= /resources/setUpEnvEntry.do?objectName= + URLEncoder.encode(envEntry) + parent= + - URLEncoder.encode(parentName) %' + URLEncoder.encode(parentInfo) %' controls:attribute name=envEntry attribute=name/ /html:link /div/td 1.1 jakarta-tomcat-4.0/webapps/admin/resources/deleteResourceLinks.jsp Index: deleteResourceLinks.jsp === !-- Standard Struts Entries -- %@ page language=java import=java.net.URLEncoder % %@ taglib uri=/WEB-INF/struts-bean.tld prefix=bean % %@ taglib uri=/WEB-INF/struts-html.tld prefix=html % %@ taglib uri=/WEB-INF/struts-logic.tld prefix=logic % %@ taglib uri=/WEB-INF/controls.tld prefix=controls % html:html locale=true %@ include file=../users/header.jsp % !-- Body -- body bgcolor=white background=../images/PaperTexture.gif !--Form -- html:errors/ html:form action=/resources/listResourceLinks table width=100% border=0 cellspacing=0 cellpadding=0 tr bgcolor=7171A5 td width=81% div class=page-title-text align=left bean:message key=resources.actions.resourcelk.delete/ /div /td td width=19% div align=right %@ include file=listResourceLinks.jspf % /div /td /tr /table /html:form br bean:define id=checkboxes scope=page value=true/ html:form action=/resources/deleteResourceLinks %@ include file=../buttons.jsp % br %@ include file=resourceLinks.jspf % %@ include file=../buttons.jsp % /html:form br %@ include file=../users/footer.jsp % /body /html:html 1.1 jakarta-tomcat-4.0/webapps/admin/resources/listResourceLinks.jsp Index: listResourceLinks.jsp === !-- Standard Struts Entries -- %@ page language=java import=java.net.URLEncoder % %@ taglib uri=/WEB-INF/struts-bean.tld prefix=bean % %@ taglib uri=/WEB-INF/struts-html.tld prefix=html % %@ taglib uri=/WEB-INF/struts-logic.tld prefix=logic % %@ taglib uri=/WEB-INF/controls.tld prefix=controls % html:html locale=true %@ include file=../users/header.jsp % !-- Body -- body bgcolor=white background=../images/PaperTexture.gif !--Form -- html:errors/ html:form action=/resources/listResourceLinks table width=100% border=0 cellspacing=0 cellpadding=0 tr bgcolor=7171A5 td width=81% div class=page-title-text align=left bean:message key=resources.actions.resourcelk/ /div /td td width=19% div align=right %@ include file=listResourceLinks.jspf % /div /td /tr /table /html:form br %@ include file=resourceLinks.jspf % br /body /html:html 1.1 jakarta-tomcat-4.0/webapps/admin/resources/listResourceLinks.jspf Index: listResourceLinks.jspf === controls:actions controls:action selected=true bean:message key=actions.available.actions/ /controls:action controls:action disabled=true - /controls:action controls:action url=/resources/setUpResourceLink.do bean:message key=resources.actions.resourcelk.create/ /controls:action controls:action url='%= /resources/listResourceLinks.do?forward= + URLEncoder.encode(ResourceLinks Delete List) %' bean:message key=resources.actions.resourcelk.delete/ /controls:action /controls:actions 1.1 jakarta-tomcat-4.0/webapps/admin/resources/resourceLink.jsp Index: resourceLink.jsp
RE: Performance of JNI calls
On Thu, 13 Jun 2002, Mladen Turk wrote: Throughput in rows per second (bigger is better) JavaRowConsumer 95556 FineGrainedJNIRowConsumer 64360 CoarseGrainedJNIRowConsumer 53946 BytePackedJNIRowConsumer56328 SocketRowConsumer 15635 Now I've changed the CoarseGrainedJNIRowConsumer to use GetDirectBufferAddress and I'm getting the following results: Throughput in rows per second (bigger is better) JavaRowConsumer 95263 FineGrainedJNIRowConsumer 64360 CoarseGrainedJNIRowConsumer 196949 BytePackedJNIRowConsumer55379 SocketRowConsumer 15399 The direct buffer gains high througput simply couse there is no need to copy the byte arrays. All that was too suspicious for me, so what I've done is the simplest posible test, and the results are far from what my expectation was. Your tests are checking the integer operations of the processor, I don't think the buffer allocation is a big part. At least my run is as expected - the direct buffer is a bit faster, but not by much ( since most time is in the common arithmetic ). But try running again with more loops ( I also had different results when run 10.000 times). I would also make few changes to 'warm' up - the java version has a big benefit from not having to load native .so and prepare the run. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java JspDocumentParser.java Node.java Parser.java
kinman 2002/06/13 11:56:18
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
JspDocumentParser.java Node.java Parser.java
Log:
- Patch by Jan Luehe, to fix 2 problems related to scripting variables.
1. AT_BEGIN and AT_END variables are not accessible after tag end.
2. Tags within the same tag cuases Javac compilation errors.
Revision ChangesPath
1.29 +351 -64
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- Generator.java12 Jun 2002 23:17:36 - 1.28
+++ Generator.java13 Jun 2002 18:56:18 - 1.29
@@ -185,12 +185,13 @@
public void visit(Node.CustomTag n) throws JasperException {
String name = createTagHandlerPoolName(n.getPrefix(),
- n.getShortName(),
- n.getAttributes());
+n.getShortName(),
+n.getAttributes());
n.setTagHandlerPoolName(name);
if (!names.contains(name)) {
names.add(name);
}
+
visitBody(n);
}
@@ -234,6 +235,80 @@
page.visit(new TagHandlerPoolVisitor(tagHandlerPoolNames));
}
+
+/*
+ * For every custom tag, declares its scripting variables with AT_BEGIN
+ * and AT_END scopes.
+ */
+private void declareAtBeginAtEndScriptingVariables(Node.Nodes page)
+ throws JasperException {
+
+ class ScriptingVariableDeclarationVisitor extends Node.Visitor {
+
+ /*
+ * Vector keeping track of which scripting variables have already
+ * been declared
+ */
+ private Vector scriptVars;
+
+ /*
+ * Constructor.
+ */
+ public ScriptingVariableDeclarationVisitor() {
+ scriptVars = new Vector();
+ }
+
+ public void visit(Node.CustomTag n) throws JasperException {
+
+ TagVariableInfo[] tagVarInfos = n.getTagVariableInfos();
+ VariableInfo[] varInfos = n.getVariableInfos();
+
+ if ((varInfos == null) (tagVarInfos == null)) {
+ visitBody(n);
+ }
+
+ if (varInfos != null) {
+ for (int i=0; ivarInfos.length; i++) {
+ int scope = varInfos[i].getScope();
+ String varName = varInfos[i].getVarName();
+ if (((scope == VariableInfo.AT_BEGIN)
+ || (scope == VariableInfo.AT_END))
+ varInfos[i].getDeclare()
+ !scriptVars.contains(varName)) {
+ out.printin(varInfos[i].getClassName());
+ out.print( );
+ out.print(varName);
+ out.println( = null;);
+ scriptVars.add(varName);
+ }
+ }
+ } else {
+ for (int i=0; itagVarInfos.length; i++) {
+ int scope = tagVarInfos[i].getScope();
+ String varName = tagVarInfos[i].getNameGiven();
+ if (varName == null) {
+ varName = n.getTagData().getAttributeString(
+tagVarInfos[i].getNameFromAttribute());
+ }
+ if (((scope == VariableInfo.AT_BEGIN)
+ || (scope == VariableInfo.AT_END))
+ tagVarInfos[i].getDeclare()
+ !scriptVars.contains(varName)) {
+ out.printin(tagVarInfos[i].getClassName());
+ out.print( );
+ out.print(varName);
+ out.println( = null;);
+ scriptVars.add(varName);
+ }
+ }
+ }
+
+ visitBody(n);
+ }
+ }
+
+ page.visit(new ScriptingVariableDeclarationVisitor());
+}
/**
* Generates the destroy() method which is responsible for calling the
@@ -379,6 +454,10 @@
}
*/
out.printil(JspWriter _jspx_out = null;);
+ out.println();
+
+
[VOTE] Jan Luehe
I'd like to nominate Jan Luehe as a committer to tomcat. Jan is currently a commiter for Jakarta taglib project, and has been active in implementing JSTL, the standard tag library. Jan was involved with jasper 2 from the beginning, and has contributed to writing a number of important modules in jasper 2. He has submitted a number of high quality patches recently, of which the tag pooling/reuse is an examples. Jan plans to contribute more to increase the performance of jsp pages, especially those with tag invokations. His knowledge in JSTL would make him an invaluable addition to the tomcat development community. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5629] - web.xml is not re-read using manager reload
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=5629. 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=5629 web.xml is not re-read using manager reload [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] Status|RESOLVED|REOPENED OS/Version|Solaris |All Platform|Sun |All Resolution|WONTFIX | Version|4.0.1 Final |4.0.4 Beta 3 --- Additional Comments From [EMAIL PROTECTED] 2002-06-13 19:11 --- I agree with Scott's comments. I just spent 15 minutes trying to figure out why my web.xml changes were not being read. At the very least the documentation listed by Scott should be fixed, it would be more useful to have the context re-read it's web.xml... (I've changed a few bug details to reflect the fact that this appears to be a cross-platform bug) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Performance of JNI calls
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 13. lipanj 2002 20:45 To: Mladen Turk Cc: List Tomcat-Dev Subject: Re: Performance of JNI calls Few comments on the code ( first look ): In many case there is no need to SetByteArrayRegion(), and you use JNI_ABORT with ReleaseByteArrayElements. ( for example most operations in jk are one-way ). That would improve the numbers a bit. My intention was to force copying (just to see the overall impact), and the interesting thing is that the speed is more or less like memcpy, and that was surprising. I run the test with 50.000 iterations, and the results (expected): a: ( NIO ) 60210 ms j: (java)62145 ms c: (Region) 64842 ms s: (non-pinning ArrayElements) 80893 ms Another note - in our use case, Region is much better since we don't need the whole buffer ( the packet is typically smaller than the buffer size ). With JNI_ABORT, the getArrayElements returned in 63298, and without copy back Region was 62406. I'll play more with it, it's very intersting. What's nice is that the JNI seems to be ok - so as long as we pay attention to buffers the penalty is not big ( and may be compensated by using the more efficient communication apis in APR ). Yes, it seem that the JNI behaves very well if you don't follow the book :-) Much more interesting would be the real test case with MsgAjp using ByteBuffer. If you have some alpha code I would be glad to help. MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/admin/resources listEnvEntries.jsp
manveen 2002/06/13 12:31:30 Modified:webapps/admin/resources listEnvEntries.jsp Log: envEntries.jspf should be included from within the html:form so that the value of defined beans are available to it. Revision ChangesPath 1.4 +1 -2 jakarta-tomcat-4.0/webapps/admin/resources/listEnvEntries.jsp Index: listEnvEntries.jsp === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/admin/resources/listEnvEntries.jsp,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- listEnvEntries.jsp13 Jun 2002 18:19:48 - 1.3 +++ listEnvEntries.jsp13 Jun 2002 19:31:30 - 1.4 @@ -38,13 +38,12 @@ /tr /table -/html:form - br %@ include file=envEntries.jspf % br +/html:form /body /html:html -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources ResourcesTreeBuilder.java
manveen 2002/06/13 12:34:18 Modified:webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources ResourcesTreeBuilder.java Log: Placeholders for parent and parentType added. these should be available as request parameters from ListEnvEntriesAction.java. Revision ChangesPath 1.6 +6 -5 jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/ResourcesTreeBuilder.java Index: ResourcesTreeBuilder.java === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/ResourcesTreeBuilder.java,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- ResourcesTreeBuilder.java 7 May 2002 18:54:49 - 1.5 +++ ResourcesTreeBuilder.java 13 Jun 2002 19:34:18 - 1.6 @@ -150,7 +150,8 @@ EnvironmentEntries.gif, resources.getMessage(resources.env.entries), resources/listEnvEntries.do?forward= + - URLEncoder.encode(EnvEntries List Setup), + URLEncoder.encode(EnvEntries List Setup) + + parent=myParentparentType=myParentType, content, false); root.addChild(subtree); -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Jan Luehe
+1, Keep the jasper performance patches rolling! Kin-Man Chung wrote: I'd like to nominate Jan Luehe as a committer to tomcat. Jan is currently a commiter for Jakarta taglib project, and has been active in implementing JSTL, the standard tag library. Jan was involved with jasper 2 from the beginning, and has contributed to writing a number of important modules in jasper 2. He has submitted a number of high quality patches recently, of which the tag pooling/reuse is an examples. Jan plans to contribute more to increase the performance of jsp pages, especially those with tag invokations. His knowledge in JSTL would make him an invaluable addition to the tomcat development community. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- -- 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]
cvs commit: jakarta-tomcat-4.0/webapps/admin/resources envEntries.jspf listEnvEntries.jspf
manveen 2002/06/13 12:44:42 Modified:webapps/admin/resources envEntries.jspf listEnvEntries.jspf Log: Adding parent info and pasing it to SetUpEnvEntry. Revision ChangesPath 1.6 +2 -1 jakarta-tomcat-4.0/webapps/admin/resources/envEntries.jspf Index: envEntries.jspf === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/admin/resources/envEntries.jspf,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- envEntries.jspf 13 Jun 2002 18:34:45 - 1.5 +++ envEntries.jspf 13 Jun 2002 19:44:42 - 1.6 @@ -32,7 +32,8 @@ /logic:present tddiv align=left class=table-normal-text html:link page='%= /resources/setUpEnvEntry.do?objectName= + - URLEncoder.encode(envEntry) + parent= + + URLEncoder.encode(envEntry) + +parent= + URLEncoder.encode(parentInfo) %' controls:attribute name=envEntry attribute=name/ /html:link 1.3 +2 -1 jakarta-tomcat-4.0/webapps/admin/resources/listEnvEntries.jspf Index: listEnvEntries.jspf === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/admin/resources/listEnvEntries.jspf,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- listEnvEntries.jspf 4 May 2002 17:16:51 - 1.2 +++ listEnvEntries.jspf 13 Jun 2002 19:44:42 - 1.3 @@ -8,7 +8,8 @@ - /controls:action - controls:action url=/resources/setUpEnvEntry.do + controls:action url='%= /resources/setUpEnvEntry.do?parent= + +URLEncoder.encode(parentInfo) %' bean:message key=resources.actions.env.create/ /controls:action -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Jan Luehe
+1 Costin On Thu, 13 Jun 2002, Kin-Man Chung wrote: I'd like to nominate Jan Luehe as a committer to tomcat. Jan is currently a commiter for Jakarta taglib project, and has been active in implementing JSTL, the standard tag library. Jan was involved with jasper 2 from the beginning, and has contributed to writing a number of important modules in jasper 2. He has submitted a number of high quality patches recently, of which the tag pooling/reuse is an examples. Jan plans to contribute more to increase the performance of jsp pages, especially those with tag invokations. His knowledge in JSTL would make him an invaluable addition to the tomcat development community. -- 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: [VOTE] Jan Luehe
Kin-Man Chung wrote: I'd like to nominate Jan Luehe as a committer to tomcat. Jan is currently a commiter for Jakarta taglib project, and has been active in implementing JSTL, the standard tag library. Jan was involved with jasper 2 from the beginning, and has contributed to writing a number of important modules in jasper 2. He has submitted a number of high quality patches recently, of which the tag pooling/reuse is an examples. Jan plans to contribute more to increase the performance of jsp pages, especially those with tag invokations. His knowledge in JSTL would make him an invaluable addition to the tomcat development community. +1. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9851] New: - Digest Authentication Doesn't Work Properly with Mozilla
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=9851. 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=9851 Digest Authentication Doesn't Work Properly with Mozilla Summary: Digest Authentication Doesn't Work Properly with Mozilla Product: Tomcat 4 Version: Nightly Build Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I can't get Tomcat 4.1.x to authenticate a Mozilla client when using DIGEST authentication, although it works fine with IE6. The only difference I can see is that IE6 sends an extra algorithm=MD5 attribute in the Authorization header. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9852] New: - Odd Digest and Realm Behaviour
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=9852. 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=9852 Odd Digest and Realm Behaviour Summary: Odd Digest and Realm Behaviour Product: Tomcat 4 Version: 4.1.4 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This is a weird one. I'm using Tomcat 4.1.x. If I use BASIC authentication everything works OK If I use DIGEST authentication and I use the memory realm i.e. I have Realm className=org.apache.catalina.realm.MemoryRealm/ and !-- not used Realm className=org.apache.catalina.realm.UserDatabaseRealm debug=0 resourceName=UserDatabase/ -- then this works (in IE not Mozilla, see a previous post) But, if I reverse the above i.e. I have !-- not used Realm className=org.apache.catalina.realm.MemoryRealm/ -- and Realm className=org.apache.catalina.realm.UserDatabaseRealm debug=0 resourceName=UserDatabase/ then DIGEST doesn't work (BASIC still works) Do I need to add anything else, or should I report this as a bug? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9852] - Odd Digest and Realm Behaviour
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=9852. 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=9852 Odd Digest and Realm Behaviour [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement --- Additional Comments From [EMAIL PROTECTED] 2002-06-13 21:19 --- None of the current realm implementations actually comply with the contract of the realm interface, for a variety of reasons (usually, they don't want to expose the user password). DIGEST needs either the clear text password or a more complex digest of it to work, so it doesn't work with those realms (which happen to be all of them except the MemoryRealm). So this is an enhancement, because it's not supposed to work until some sophisticated (at least if we'd like to be secure) refactoring of the realms occur. Want to help ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Jan Luehe
+1 Amy Kin-Man Chung wrote: I'd like to nominate Jan Luehe as a committer to tomcat. Jan is currently a commiter for Jakarta taglib project, and has been active in implementing JSTL, the standard tag library. Jan was involved with jasper 2 from the beginning, and has contributed to writing a number of important modules in jasper 2. He has submitted a number of high quality patches recently, of which the tag pooling/reuse is an examples. Jan plans to contribute more to increase the performance of jsp pages, especially those with tag invokations. His knowledge in JSTL would make him an invaluable addition to the tomcat development community. -- 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]
testing a parameter's value does not work-pls help!
Hi Everyone!
Hello
I am having a problem with testing the value of a parameter that a jsp page
receives.
Jsp page 1 displays a dropbox whose name is Decision and has an option All Types.
But in jsp page 2 when i do
String Decision = (String) request.getParameter(Decision);
%if(Decision.equals(All Types))%
% { %
% for (int i=0; i something ; i++) { %
TD WIDTH=100 ALIGN=CENTER%=HdrFontST%%=something
else%%%=HdrFontEND%/TD
% } %
% } %
/TR
'something else' is displayed even when Decision DOES NOT take the vale all Types.
Can someone tell me why this is happening and how I can resolve this?
Any kind of help is greatly appreciated!
Thanks and Bye!
-
Do You Yahoo!?
Sign-up for Video Highlights of 2002 FIFA World Cup
Re: [PROPOSAL] Minor fix for servletapi-4 GenericServlet
Christopher K. St. John wrote: GOMEZ Henri wrote: I propose you to make a PROPOSAL for servletapi4 patch to tomcat-dev list. My proposal is ... [delete log() msgs in GenerisServlet] From my reading of the project guidelines, minor fixes like this normally go the commit-then-review route, so I'm unclear if there need to be 3 +1's before any action is taken. There's just been the one (by Remy) so far. I realize it isn't a very exciting patch :-), but minor bugs need love too, so a couple more +1's (or a -1 if there is some problem) would be nifty. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/resources/confinstall server_2.xml
remm2002/06/13 14:42:26 Modified:resources/confinstall server_2.xml Log: - Fix confusing version number. Revision ChangesPath 1.5 +1 -1 jakarta-tomcat-4.0/resources/confinstall/server_2.xml Index: server_2.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/resources/confinstall/server_2.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- server_2.xml 15 May 2002 15:28:56 - 1.4 +++ server_2.xml 13 Jun 2002 21:42:26 - 1.5 @@ -17,7 +17,7 @@ /Connector -- -!-- Define a Coyote/JK2 AJP 1.4 Connector on port 8009 -- +!-- Define a Coyote/JK2 AJP 1.3 Connector on port 8009 -- Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8009 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/conf server.xml
remm2002/06/13 14:42:40 Modified:catalina/src/conf server.xml Log: - Fix confusing version number. Revision ChangesPath 1.60 +1 -1 jakarta-tomcat-4.0/catalina/src/conf/server.xml Index: server.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/server.xml,v retrieving revision 1.59 retrieving revision 1.60 diff -u -r1.59 -r1.60 --- server.xml22 May 2002 14:33:16 - 1.59 +++ server.xml13 Jun 2002 21:42:40 - 1.60 @@ -103,7 +103,7 @@ /Connector -- -!-- Define a Coyote/JK2 AJP 1.4 Connector on port 8009 -- +!-- Define a Coyote/JK2 AJP 1.3 Connector on port 8009 -- Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8009 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Jan Luehe
+1 Jan has done a great job on JSTL. He should continue to contribute many quality Jasper 2 patches. Justy - Original Message - From: Kin-Man Chung [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 13, 2002 12:09 PM Subject: [VOTE] Jan Luehe I'd like to nominate Jan Luehe as a committer to tomcat. Jan is currently a commiter for Jakarta taglib project, and has been active in implementing JSTL, the standard tag library. Jan was involved with jasper 2 from the beginning, and has contributed to writing a number of important modules in jasper 2. He has submitted a number of high quality patches recently, of which the tag pooling/reuse is an examples. Jan plans to contribute more to increase the performance of jsp pages, especially those with tag invokations. His knowledge in JSTL would make him an invaluable addition to the tomcat development community. -- 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/catalina/src/share/org/apache/catalina/servlets DefaultServlet.java
remm2002/06/13 15:34:42
Modified:catalina/src/share/org/apache/catalina/servlets
DefaultServlet.java
Log:
- Apply patch to fix bug 8013: DefaultServlet Throws NumberFormatException.
- Now uses Request.getDateHeader instead of using instance local date
formats, which is not thread safe.
- Patch submitted by James Carman james at carmanconsulting.com. Very
useful patch. Thanks !
Revision ChangesPath
1.56 +176 -132
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java
Index: DefaultServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
retrieving revision 1.55
retrieving revision 1.56
diff -u -r1.55 -r1.56
--- DefaultServlet.java 11 May 2002 05:06:25 - 1.55
+++ DefaultServlet.java 13 Jun 2002 22:34:42 - 1.56
@@ -763,135 +763,11 @@
ResourceInfo resourceInfo)
throws IOException {
-String eTag = getETag(resourceInfo);
-long fileLength = resourceInfo.length;
-long lastModified = resourceInfo.date;
-
-StringTokenizer commaTokenizer;
-
-String headerValue;
-
-// Checking If-Match
-headerValue = request.getHeader(If-Match);
-if (headerValue != null) {
-if (headerValue.indexOf('*') == -1) {
-
-commaTokenizer = new StringTokenizer(headerValue, ,);
-boolean conditionSatisfied = false;
-
-while (!conditionSatisfied commaTokenizer.hasMoreTokens()) {
-String currentToken = commaTokenizer.nextToken();
-if (currentToken.trim().equals(eTag))
-conditionSatisfied = true;
-}
-
-// If none of the given ETags match, 412 Precodition failed is
-// sent back
-if (!conditionSatisfied) {
-response.sendError
-(HttpServletResponse.SC_PRECONDITION_FAILED);
-return false;
-}
-
-}
-}
-
-// Checking If-Modified-Since
-headerValue = request.getHeader(If-Modified-Since);
-if (headerValue != null) {
-
-// If an If-None-Match header has been specified, if modified since
-// is ignored.
-if (request.getHeader(If-None-Match) == null) {
-
-Date date = null;
-
-// Parsing the HTTP Date
-for (int i = 0; (date == null) (i formats.length); i++) {
-try {
-date = formats[i].parse(headerValue);
-} catch (ParseException e) {
-;
-}
-}
-
-if ((date != null)
- (lastModified = (date.getTime() + 1000)) ) {
-// The entity has not been modified since the date
-// specified by the client. This is not an error case.
-response.setStatus(HttpServletResponse.SC_NOT_MODIFIED);
-return false;
-}
-
-}
-
-}
-
-// Checking If-None-Match
-headerValue = request.getHeader(If-None-Match);
-if (headerValue != null) {
-
-boolean conditionSatisfied = false;
-
-if (!headerValue.equals(*)) {
-
-commaTokenizer = new StringTokenizer(headerValue, ,);
-
-while (!conditionSatisfied commaTokenizer.hasMoreTokens()) {
-String currentToken = commaTokenizer.nextToken();
-if (currentToken.trim().equals(eTag))
-conditionSatisfied = true;
-}
+return checkIfMatch(request, response, resourceInfo)
+ checkIfModifiedSince(request, response, resourceInfo)
+ checkIfNoneMatch(request, response, resourceInfo)
+ checkIfUnmodifiedSince(request, response, resourceInfo);
-} else {
-conditionSatisfied = true;
-}
-
-if (conditionSatisfied) {
-
-// For GET and HEAD, we should respond with
-// 304 Not Modified.
-// For every other method, 412 Precondition Failed is sent
-// back.
-if ( (GET.equals(request.getMethod()))
- || (HEAD.equals(request.getMethod())) ) {
-response.setStatus(HttpServletResponse.SC_NOT_MODIFIED);
-return false;
-}
Re: [PROPOSAL] Minor fix for servletapi-4 GenericServlet
+1 That log is really annoying. Please make the change in both 2.2 and 2.3 branches. Costin On Thu, 13 Jun 2002, Christopher K. St. John wrote: Christopher K. St. John wrote: GOMEZ Henri wrote: I propose you to make a PROPOSAL for servletapi4 patch to tomcat-dev list. My proposal is ... [delete log() msgs in GenerisServlet] From my reading of the project guidelines, minor fixes like this normally go the commit-then-review route, so I'm unclear if there need to be 3 +1's before any action is taken. There's just been the one (by Remy) so far. I realize it isn't a very exciting patch :-), but minor bugs need love too, so a couple more +1's (or a -1 if there is some problem) would be nifty. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Collector.java Generator.java Node.java
kinman 2002/06/13 15:56:11
Modified:jasper2/src/share/org/apache/jasper/compiler Collector.java
Generator.java Node.java
Log:
- Moved the logc for detecting scripting variables in tags to Collector,
and fixed a bug in the logic.
Revision ChangesPath
1.2 +16 -2
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Collector.java
Index: Collector.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Collector.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- Collector.java5 Jun 2002 22:01:33 - 1.1
+++ Collector.java13 Jun 2002 22:56:11 - 1.2
@@ -88,6 +88,7 @@
private boolean usebeanSeen = false;
private boolean includeActionSeen = false;
private boolean setPropertySeen = false;
+ private boolean hasScriptingVars = false;
public void visit(Node.ParamAction n) throws JasperException {
if (n.getValue().isExpression()) {
@@ -151,6 +152,8 @@
includeActionSeen = false;
boolean setPropertySeenSave = setPropertySeen;
setPropertySeen = false;
+ boolean hasScriptingVarsSave = hasScriptingVars;
+ hasScriptingVars = false;
// Scan attribute list for expressions
Node.JspAttribute[] attrs = n.getJspAttributes();
@@ -163,17 +166,28 @@
visitBody(n);
+ if (!hasScriptingVars) {
+ // For some reason, varInfos is null when var is not defined
+ // in TEI, but tagVarInfos is empty array when var is not
+ // defined in tld.
+ hasScriptingVars = n.getVariableInfos() != null ||
+ (n.getTagVariableInfos() != null
+ n.getTagVariableInfos().length 0);
+ }
+
// Record if the tag element and its body contains any scriptlet.
n.setScriptless(! scriptingElementSeen);
n.setHasUsebean(usebeanSeen);
n.setHasIncludeAction(includeActionSeen);
n.setHasSetProperty(setPropertySeen);
+ n.setHasScriptingVars(hasScriptingVars);
// Propagate value of scriptingElementSeen up.
scriptingElementSeen = scriptingElementSeen || scriptingElementSeenSave;
usebeanSeen = usebeanSeen || usebeanSeenSave;
setPropertySeen = setPropertySeen || setPropertySeenSave;
includeActionSeen = includeActionSeen || includeActionSeenSave;
+ hasScriptingVars = hasScriptingVars || hasScriptingVarsSave;
curTagNesting--;
}
1.30 +5 -12
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- Generator.java13 Jun 2002 18:56:18 - 1.29
+++ Generator.java13 Jun 2002 22:56:11 - 1.30
@@ -1101,18 +1101,11 @@
// to a method.
ServletWriter outSave = null;
MethodsBuffer methodsBufferSave = null;
- boolean generateTagMethod = false;
- if (n.isScriptless() n.getVariableInfos() == null
- (n.getTagVariableInfos() == null
- || n.getTagVariableInfos().length == 0)) {
+ if (n.isScriptless() !n.hasScriptingVars()) {
// The tag handler and its body code can reside in a separate
// method if it is scriptless and does not have any scripting
// variable defined.
- // For some reason, varInfos is null when var is not defined
- // in TEI, but tagVarInfos is empty array when var is not
- // defined in tld.
- generateTagMethod = true;
String tagMethod = _jspx_meth_ + baseVar;
// Generate a call to this method
@@ -1177,7 +1170,7 @@
generateCustomEnd(n, handlerInfo.getTagHandlerClass(),
tagHandlerVar, tagEvalVar);
- if (generateTagMethod) {
+ if (n.isScriptless() !n.hasScriptingVars()) {
// Generate end of method
if (methodNesting 0) {
out.printil(return false;);
1.14 +12 -3
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java
Index: Node.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java,v
cvs commit: jakarta-tomcat-4.0/webapps/admin/resources envEntries.jspf listEnvEntries.jsp listEnvEntries.jspf
amyroh 2002/06/13 16:17:57
Modified:webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources
EnvEntryForm.java ResourceUtils.java
ResourcesTreeBuilder.java SetUpEnvEntryAction.java
webapps/admin/resources envEntries.jspf listEnvEntries.jsp
listEnvEntries.jspf
Log:
Minor additon and fixes for Context resources.
Revision ChangesPath
1.6 +23 -4
jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/EnvEntryForm.java
Index: EnvEntryForm.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/EnvEntryForm.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- EnvEntryForm.java 13 Jun 2002 18:19:48 - 1.5
+++ EnvEntryForm.java 13 Jun 2002 23:17:57 - 1.6
@@ -174,7 +174,26 @@
public void setParentName(String parentName) {
this.parentName = parentName;
}
+
+/**
+ * The parent type of this environment entry.
+ */
+private String parentType = null;
+
+/**
+ * Return the parent type of the environment entry this bean refers to.
+ */
+public String getParentType() {
+return this.parentType;
+}
+/**
+ * Set the parent type of the environment entry this bean refers to.
+ */
+public void setParentType(String parentType) {
+this.parentType = parentType;
+}
+
/**
* Precomputed list of entry type labels and values.
*/
1.6 +18 -17
jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/ResourceUtils.java
Index: ResourceUtils.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/ResourceUtils.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ResourceUtils.java13 Jun 2002 18:19:48 - 1.5
+++ ResourceUtils.java13 Jun 2002 23:17:57 - 1.6
@@ -103,30 +103,31 @@
*/
public static EnvEntriesForm getEnvEntriesForm(MBeanServer mserver,
String parent, String parentType) throws Exception {
-
+
ObjectName ename = null;
if ((parent == null) || (parentType == null)) {
-ename = new ObjectName(NAMINGRESOURCES_TYPE);
+ename = new ObjectName( ENVIRONMENT_TYPE + ,*);
} else {
-ename = new ObjectName( NAMINGRESOURCES_TYPE +
+ename = new ObjectName( ENVIRONMENT_TYPE +
,+parentType+= + parent);
}
+
+Iterator iterator = (mserver.queryMBeans(ename, null).iterator());
-String results[] = null;
-try {
-results = (String[]) mserver.getAttribute(ename, environments);
-} catch (Exception e) {
-// leave results null return empty forms
-}
-if (results == null) {
-results = new String[0];
+ArrayList results = new ArrayList();
+while (iterator.hasNext()) {
+ObjectInstance instance = (ObjectInstance) iterator.next();
+results.add(instance.getObjectName().toString());
}
-Arrays.sort(results);
+
+Collections.sort(results);
EnvEntriesForm envEntriesForm = new EnvEntriesForm();
-envEntriesForm.setEnvEntries(results);
+envEntriesForm.setEnvEntries((String[])
+results.toArray(new String[results.size()]));
envEntriesForm.setParentName(parent);
envEntriesForm.setParentType(parentType);
+
return (envEntriesForm);
}
1.7 +5 -6
jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/ResourcesTreeBuilder.java
Index: ResourcesTreeBuilder.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/ResourcesTreeBuilder.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- ResourcesTreeBuilder.java 13 Jun 2002 19:34:18 - 1.6
+++ ResourcesTreeBuilder.java 13 Jun 2002 23:17:57 - 1.7
@@ -150,8 +150,7 @@
EnvironmentEntries.gif,
resources.getMessage(resources.env.entries),
resources/listEnvEntries.do?forward= +
- URLEncoder.encode(EnvEntries List Setup) +
-
DO NOT REPLY [Bug 8013] - DefaultServlet Throws NumberFormatException
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=8013. 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=8013 DefaultServlet Throws NumberFormatException [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-06-13 23:18 --- I have applied the patch submitted. 4.1.5 will include the fix. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources ResourceUtils.java
manveen 2002/06/13 16:38:26
Modified:webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources
ResourceUtils.java
Log:
Set parent and parentType to empty strings (for global resources) . these are not
needed for computing the mBean for the global env entries case.
Revision ChangesPath
1.7 +18 -8
jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/ResourceUtils.java
Index: ResourceUtils.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/ResourceUtils.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- ResourceUtils.java13 Jun 2002 23:17:57 - 1.6
+++ ResourceUtils.java13 Jun 2002 23:38:26 - 1.7
@@ -111,7 +111,7 @@
ename = new ObjectName( ENVIRONMENT_TYPE +
,+parentType+= + parent);
}
-
+
Iterator iterator = (mserver.queryMBeans(ename, null).iterator());
ArrayList results = new ArrayList();
@@ -124,9 +124,19 @@
EnvEntriesForm envEntriesForm = new EnvEntriesForm();
envEntriesForm.setEnvEntries((String[])
-results.toArray(new String[results.size()]));
-envEntriesForm.setParentName(parent);
-envEntriesForm.setParentType(parentType);
+results.toArray(new String[results.size()]));
+
+if (parent != null) {
+envEntriesForm.setParentName(parent);
+} else {
+envEntriesForm.setParentName();
+}
+
+if (parentType != null) {
+envEntriesForm.setParentType(parentType);
+} else {
+envEntriesForm.setParentType();
+}
return (envEntriesForm);
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/admin/WEB-INF web.xml
remm2002/06/13 16:43:03 Modified:webapps/admin/WEB-INF web.xml Log: - Add display name (submitted by Ian Darwin). Revision ChangesPath 1.13 +5 -0 jakarta-tomcat-4.0/webapps/admin/WEB-INF/web.xml Index: web.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/web.xml,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- web.xml 4 May 2002 02:06:15 - 1.12 +++ web.xml 13 Jun 2002 23:43:03 - 1.13 @@ -6,6 +6,11 @@ web-app + display-nameTomcat Administration Application/display-name + description +Tomcat HTML based administration web application. + /description + !-- Action Servlet Configuration -- servlet servlet-nameaction/servlet-name -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8926] - Duplicate variable definition in generated Java source, related to custom tag scripting variable
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=8926. 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=8926 Duplicate variable definition in generated Java source, related to custom tag scripting variable [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-06-13 23:55 --- Fixed. See email with subject [PATCH] Custom tag scripting variables sent to tomcat-dev on 12 Jun 2002 for patch. Patch summary: 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() -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9856] New: - sendError(404) fails after getOutputStream() is called, if you have a custom 404 error-page
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=9856.
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=9856
sendError(404) fails after getOutputStream() is called, if you have a custom 404
error-page
Summary: sendError(404) fails after getOutputStream() is called,
if you have a custom 404 error-page
Product: Tomcat 4
Version: 4.0.2 Final
Platform: PC
OS/Version: Linux
Status: NEW
Severity: Normal
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
A response.sendError(404) invokation will not work correctly if it is done
after a response.getOutputStream() invokation AND you have a custom 404 error-
page.
The following code works correctly. If you have configured a custom 404 error-
page, you receive it; if you have not configured a custom error page, you will
receive a default 404 error page.
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
response.sendError(404);
}
The following code does not work correctly, but I think it should. If you have
configured a custom 404 error-page, you will receive nothing (each browser will
handle this differntly); however, if you have not configured a custom error
page, you will receive a default 404 error page.
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
response.getOutputStream();
response.sendError(404);
}
I am using Tomcat 4.0.2 final with Sun's JDK 1.4 final on Linux 7.1 on a single
Intel processor with 512 MB of memory. I am quite sure that my custom 404 error-
page is configured correctly because it is displayed when the DefaultServlet
can not find a page and when any Servlet calls sendError(404) without calling
getOutputStream().
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9846] - sendRedirect using FTP
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=9846.
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=9846
sendRedirect using FTP
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||WORKSFORME
--- Additional Comments From [EMAIL PROTECTED] 2002-06-14 00:36 ---
This works on Tomcat 4.1 (using a modified servlet which does a sendRedirect to
your URL):
GET /examples/servlet/HelloWorldExample HTTP/1.1
Host: localhost:8080
HTTP/1.1 302 Moved Temporarily
Content-Type: text/html
Location: ftp://ftptest:[EMAIL PROTECTED]/
Transfer-Encoding: chunked
Date: Fri, 14 Jun 2002 00:26:51 GMT
Server: Apache Coyote HTTP/1.1 Connector [1.0]
2ae
htmlheadtitleApache Tomcat/4.1.5 - Error report/titleSTYLE!--H1{font-
family : sans-serif,Arial,Tahoma;color : white;background-color : #0086b2;} H3{f
ont-family : sans-serif,Arial,Tahoma;color : white;background-color : #0086b2;}
BODY{font-family : sans-serif,Arial,Tahoma;color : black;background-color : whit
e;} B{color : white;background-color : #0086b2;} HR{color : #0086b2;} --/STYLE
/headbodyh1HTTP Status 302 - /h1HR size=1 noshadepbtype/b St
atus report/ppbmessage/b u/u/ppbdescription/b uThe request
ed resource () has moved temporarily to a new location./u/pHR size=1 nosh
adeh3Apache Tomcat/4.1.5/h3/body/html
0
This may have been fixed in 4.0.4. If it hasn't it is unlikely it will be fixed
in 4.0.x.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Help..Tomcat4x+jdk1.3+FreeBSD..Hang Why...
Same for me. The native one works. Try follow the instructions at: http://www.eyesbeyond.com/freebsddom/java/jdk13.html - Punky TC runs well on the FreeBSD I have access to: +++ bash-2.04$ uname -a FreeBSD deejai2.mch.fsc.net 4.6-RC FreeBSD 4.6-RC #4: Thu May 30 00:09:26 CEST 2002 [EMAIL PROTECTED]:/usr/src/sys/compile/DEEJAI4B i386 bash-2.04$ which java /usr/local/jdk1.3.1/bin/java bash-2.04$ java -version java version 1.3.1-p6 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-p6-martin-020531-11:18) Classic VM (build 1.3.1-p6-martin-020531-11:18, green threads, nojit) +++ The TC (from ps): +++ 38920 p3- S 25:09.33 /usr/local/jdk1.3.1/bin/i386/green_threads/java -Djav +++ The trick was to download the JVM sources apply FreeBSD patches and install the compiled JVM. The TC running on this machine is 4.1.3. Can anybody tell me whos are the developers of tomcat4x Bye Sonam __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- 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 RELEASE-NOTES-4.1.txt
remm2002/06/13 19:19:01 Modified:.RELEASE-NOTES-4.1.txt Log: - Status update. Revision ChangesPath 1.10 +9 -4 jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt Index: RELEASE-NOTES-4.1.txt === RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- RELEASE-NOTES-4.1.txt 13 Jun 2002 00:06:37 - 1.9 +++ RELEASE-NOTES-4.1.txt 14 Jun 2002 02:19:00 - 1.10 @@ -234,6 +234,11 @@ WebappLoader: Use introspection to instantiate the class loader. +[4.1.5] #9715 +'Out of Memory' error with static html pages +ProxyDirContext: +Use a LRU based cache instead of a simple hashtable. + [4.1.4] #9722 java.lang.ClassCastException: org.apache.catalina.connector.HttpRequestFacade @@ -290,11 +295,11 @@ Fix spec compliance bug where a tag could define scripting variables in both the TLD and the TagExtraInfo class. -[4.1.5] Generator: -Code cleanup, removing the need for a state object. +[4.1.5] Generator, PageContextImpl: +Fix tag BodyContent reuse. [4.1.5] Generator: -Fix bugs introduced with buffer reuse. +Code cleanup, removing the need for a state object. [4.1.5] Generator: Fix bug when specifying a redirect which already included part of a -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8013] - DefaultServlet Throws NumberFormatException
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=8013. 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=8013 DefaultServlet Throws NumberFormatException --- Additional Comments From [EMAIL PROTECTED] 2002-06-14 02:31 --- Created an attachment (id=2082) Add IllegalArgumentException catch blocks in the checkIfModifiedSince and checkIfUnmodifiedSince methods -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8013] - DefaultServlet Throws NumberFormatException
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=8013. 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=8013 DefaultServlet Throws NumberFormatException --- Additional Comments From [EMAIL PROTECTED] 2002-06-14 02:44 --- You need to use the latest version of the file to create the patch (version 1.56). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8013] - DefaultServlet Throws NumberFormatException
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=8013. 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=8013 DefaultServlet Throws NumberFormatException --- Additional Comments From [EMAIL PROTECTED] 2002-06-14 02:54 --- Created an attachment (id=2083) Applying the patch using revision 1.56 and the non-unified format. -- 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/servlets DefaultServlet.java
remm2002/06/13 20:19:43
Modified:catalina/src/share/org/apache/catalina/servlets
DefaultServlet.java
Log:
- Add try/catch for IAE.
- Patch submitted by James Carman james at carmanconsulting.com
Revision ChangesPath
1.57 +32 -27
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java
Index: DefaultServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
retrieving revision 1.56
retrieving revision 1.57
diff -u -r1.56 -r1.57
--- DefaultServlet.java 13 Jun 2002 22:34:42 - 1.56
+++ DefaultServlet.java 14 Jun 2002 03:19:43 - 1.57
@@ -1607,20 +1607,23 @@
HttpServletResponse response,
ResourceInfo resourceInfo)
throws IOException {
-
-long headerValue = request.getDateHeader(If-Modified-Since);
-long lastModified = resourceInfo.date;
-if (headerValue != -1) {
-
-// If an If-None-Match header has been specified, if modified since
-// is ignored.
-if ((request.getHeader(If-None-Match) == null)
- (lastModified = headerValue + 1000)) {
-// The entity has not been modified since the date
-// specified by the client. This is not an error case.
-response.setStatus(HttpServletResponse.SC_NOT_MODIFIED);
-return false;
+try {
+long headerValue = request.getDateHeader(If-Modified-Since);
+long lastModified = resourceInfo.date;
+if (headerValue != -1) {
+
+// If an If-None-Match header has been specified, if modified since
+// is ignored.
+if ((request.getHeader(If-None-Match) == null)
+ (lastModified = headerValue + 1000)) {
+// The entity has not been modified since the date
+// specified by the client. This is not an error case.
+response.setStatus(HttpServletResponse.SC_NOT_MODIFIED);
+return false;
+}
}
+} catch(IllegalArgumentException illegalArgument) {
+return false;
}
return true;
@@ -1699,17 +1702,19 @@
HttpServletResponse response,
ResourceInfo resourceInfo)
throws IOException {
-
-long lastModified = resourceInfo.date;
-long headerValue = request.getDateHeader(If-Unmodified-Since);
-if (headerValue != -1) {
-if ( lastModified headerValue ) {
-// The entity has not been modified since the date
-// specified by the client. This is not an error case.
-response.sendError(HttpServletResponse.SC_PRECONDITION_FAILED);
-return false;
+try {
+long lastModified = resourceInfo.date;
+long headerValue = request.getDateHeader(If-Unmodified-Since);
+if (headerValue != -1) {
+if ( lastModified headerValue ) {
+// The entity has not been modified since the date
+// specified by the client. This is not an error case.
+response.sendError(HttpServletResponse.SC_PRECONDITION_FAILED);
+return false;
+}
}
-
+} catch(IllegalArgumentException illegalArgument) {
+return false;
}
return true;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8013] - DefaultServlet Throws NumberFormatException
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=8013. 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=8013 DefaultServlet Throws NumberFormatException --- Additional Comments From [EMAIL PROTECTED] 2002-06-14 03:30 --- Thanks again for the patch. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9859] New: - Avoid SimpleDateFormat creation for every dispatched 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=9859. 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=9859 Avoid SimpleDateFormat creation for every dispatched request Summary: Avoid SimpleDateFormat creation for every dispatched request Product: Tomcat 4 Version: 4.0 Beta 3 Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Connector:HTTP/1.1 (deprecated) AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The Request Dispatcher code path creates new HttpRequestBase objects. Creation of the SimpleDateFormat data member - formats - of HttpRequestBase shows up as a hotspot on performance profiles. I think this can be avoided by making formats a static final variable and synchronize on formats[i] in getDateHeader (the only place where formats is used). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9859] - Avoid SimpleDateFormat creation for every dispatched 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=9859. 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=9859 Avoid SimpleDateFormat creation for every dispatched request --- Additional Comments From [EMAIL PROTECTED] 2002-06-14 04:20 --- Created an attachment (id=2084) Patch that implements the fix described in the bug. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Re: tomcat 4.0 nightly builds broken since 5/30
I've been testing all those versions... there seems to be a couple issues I have seen with each... let me test 4.1.5 and I'll let you know how it goes... t [EMAIL PROTECTED] wrote: The tomcat nightly builds are broken since 5/30. This is the last day before no good downloadable builds will be available. http://jakarta.apache.org/builds/jakarta-tomcat-4.0/ The plan is to rely on Gump for the nightlies. There were some issues, which got fixed. Now, we may have to wait a bit for a build to succeed ;-) My plan is to release a new Tomcat 4.1.5 milestone today or tomorrow. 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]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net URL.java
billbarker2002/06/13 22:34:23
Modified:util/java/org/apache/tomcat/util/net URL.java
Log:
Teach URL how to parse userInfo.
This allows URL to parse a string of the form:
ftp://user:[EMAIL PROTECTED]/
This actually doesn't fix any Tomcat problems (assuming that the string is correct
to start with), and this class is only used by TC33. I just sleep easier if the URL is
parsed correctly.
Revision ChangesPath
1.2 +8 -4
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/URL.java
Index: URL.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/URL.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- URL.java 5 Apr 2002 17:43:33 - 1.1
+++ URL.java 14 Jun 2002 05:34:23 - 1.2
@@ -695,7 +695,11 @@
start = limit;
}
if (authority.length() 0) {
-int colon = authority.indexOf(':');
+int at = authority.indexOf('@');
+if( at = 0 ) {
+userInfo = authority.substring(0,at);
+}
+int colon = authority.indexOf(':', at+1);
if (colon = 0) {
try {
port =
@@ -703,9 +707,9 @@
} catch (NumberFormatException e) {
throw new MalformedURLException(e.toString());
}
-host = authority.substring(0, colon);
+host = authority.substring(at+1, colon);
} else {
-host = authority;
+host = authority.substring(at+1);
port = -1;
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[4.0.4] Binaries available
The Tomcat 4.0.4 binaries are now available. Both the tester and Watchdog passed successfully on the build. It also includes very little changes over 4.0.4 Beta 3. Please test for showstoppers or build errors. The welcome file for the main directory references the j-t-c build directory for native connector builds, so it would be nice if this was populated with builds for JK 1.2 and Webapp. RPMs are also needed (thanks in advance Henri :)). The official release announcement will happen early next week unless some major problem is found since then. I would also like to apologize for the delays in making this release available. Downloads for the proposed final build: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/test/v4.0.4/ Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: tomcat 4.0 nightly builds broken since 5/30
[EMAIL PROTECTED] wrote: I've been testing all those versions... there seems to be a couple issues I have seen with each... let me test 4.1.5 and I'll let you know how it goes... 4.1.5 currently does not exist, but otherwise looks good. At the moment, there are some issues which still needs to be cleared out dealing with the JNDI resources handling in the admin webapp. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
