DO NOT REPLY [Bug 4559] New: - Problems with trailing slash when using Apache/Tomcat
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=4559. 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=4559 Problems with trailing slash when using Apache/Tomcat Summary: Problems with trailing slash when using Apache/Tomcat Product: Tomcat 4 Version: 4.0.1 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Connectors AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I am using Apache 1.3.19 and the built mod_webapp.so for nt/2k. Apache and Tomcat are working properly; but, when I use mod_webapp, I must add a trailing slash to the url, or I'll get a 404. For instance, using the following configuration httpd.conf: WebAppConnection conn warp localhost:8008 WebAppDeploy examples conn /examples I can reach the pages using either http://localhost:8080/examples or http://localhost/examples/ , but not with http://localhost/examples -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: SSL session attribute
Do you think that it would be smart and/or desirable to 'enforce' the check for all people that use sessions with SSL? In other words, if you have a TC session, and you're running things over SSL, we enforce the TC session ID and SSL session ID match. If there are security experts out there (Christopher?) that are willing to contribute, I'd really appreciate it. Bojan GOMEZ Henri wrote: Is the request attribute javax.servlet.request.ssl_session (in TC 3.3) a 'standard' attribute that keeps the SSL session ID? Is there a spec that defines it? No, it's not on the specs and even if you find this information on some servers (Apache + mod_ssl for example), there is still some web server where it won't be available (IIS I think) and so couldn't be forwarded by mod_jk It seems like an extremely important part of keeping the users from bumping into each others TC session 'by accident' (or should I say by cracking). Yes it's something you could use to verify that nobody is hacking your sessionid, but I feel that any serious webapp application must run under SSL -- 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 4560] New: - getParameter returning null when a value contains the equals symbol =
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=4560. 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=4560 getParameter returning null when a value contains the equals symbol = Summary: getParameter returning null when a value contains the equals symbol = Product: Tomcat 4 Version: 4.0.1 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Minor Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I'm getting a null value when I call getParameter if the value contains an equals. For example the following query string: /cfd/main?action=resetorderforward=/mainframe.jsp%3flayout=orderentry If I call getParameter(forward) the return is null. If I encode the query string as follows: /cfd/main?action=resetorderforward=/mainframe.jsp%3flayout%3dorderentry Then I get the correct string (eg. =/mainframe.jsp%3flayout%3dorderentry This works with previous versions of tomcat (3.2.3 and prior) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [TC3.2.3] Hang when using few http-threads.
I am using poolman 2.1 with apache tomcat 4. The problem i am facing is that connection pool is not accessible through jndi whereas in server window poolman gives confirmation that pool is bound to jndi name. However connection is available and working through Poolman class. I m really stuck at this problem. Any help will be highly appreciated. Regards Asif -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JNDI Problem
I am using poolman 2.1 with apache tomcat 4. The problem i am facing is that connection pool is not accessible through jndi whereas in server window poolman gives confirmation that pool is bound to jndi name. However connection is available and working through Poolman class. I m really stuck at this problem. Any help will be highly appreciated. Regards Asif -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Welcome to the Tomcat 4.0 F.A.Q. on-line forum.
Bill Barker at [EMAIL PROTECTED] wrote: I know that Jon has already pointed out that Sun is going to sue the 3.x branch out of Jakarta in five months, I don't think Jon said that, and as a Sun employee I can guarantee that Tomcat 3.x remains one of our strongholds AND the official servlet 2.2 container / jsp 1.1 engine used in the J2EE reference implementation. Probably most of the people from Sun you see on the mailing list are more connected with 4.0 as we're developing for the new release(s) of the spec, but 3.x is still one of our major focuses in terms of integration. but is there any chance of setting this up in the mean time for 3.x? Why don't you _look_ before sending emails? It has been there together with the 4.0 forum since the beginning... I just posted _my_ welcome in the 4.0 forum since it's _there_ that I'm involved :) Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4564] New: - request.getRemoteAddr() and AccesLog not working
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4564. 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=4564 request.getRemoteAddr() and AccesLog not working Summary: request.getRemoteAddr() and AccesLog not working Product: Tomcat 3 Version: 3.3 Final Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hello, there is a bug in tomcat 3.3 final that was not there in version 3.3rc2: getRemoteAddr() always return 127.0.0.1 instead of correct address. I can't use 3.3rc2 because AccesLog (the one generating apache style logs) is not working. Is there any workaround? If it helps, I'm running RedHat 7.1 with all updates and JDK 1.4beta2. Thanks, Alex -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4520] - I can not Access a context from a JSP called trought Apache
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=4520.
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=4520
I can not Access a context from a JSP called trought Apache
--- Additional Comments From [EMAIL PROTECTED] 2001-11-01 08:16 ---
ServerType standalone
ServerRoot /opt/www/apache
PidFile /opt/www/apache/logs/httpd.pid
ScoreBoardFile /opt/www/apache/logs/httpd.scoreboard
Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
MinSpareServers 5
MaxSpareServers 10
StartServers 5
MaxClients 150
MaxRequestsPerChild 0
LoadModule webapp_module libexec/mod_webapp.so
AddModule mod_webapp.c
Port 80
User nobody
Group nobody
ServerAdmin [EMAIL PROTECTED]
ServerName 207.249.0.102
DocumentRoot /opt/www/apache/htdocs
Directory /
Options FollowSymLinks
AllowOverride None
/Directory
Directory /opt/www/apache/htdocs
Options Indexes FollowSymLinks MultiViews ExecCGI
AllowOverride None
Order allow,deny
Allow from all
/Directory
IfModule mod_userdir.c
UserDir public_html
/IfModule
IfModule mod_dir.c
DirectoryIndex index.html
/IfModule
AccessFileName .htaccess
Files ~ ^\.ht
Order allow,deny
Deny from all
Satisfy All
/Files
UseCanonicalName On
IfModule mod_mime.c
TypesConfig /opt/www/apache/conf/mime.types
/IfModule
DefaultType text/plain
IfModule mod_mime_magic.c
MIMEMagicFile /opt/www/apache/conf/magic
/IfModule
HostnameLookups Off
ErrorLog /opt/www/apache/logs/error_log
LogLevel warn
LogFormat %h %l %u %t \%r\ %s %b \%{Referer}i\ \%{User-Agent}i\
combined
LogFormat %h %l %u %t \%r\ %s %b common
LogFormat %{Referer}i - %U referer
LogFormat %{User-agent}i agent
CustomLog /opt/www/apache/logs/access_log common
ServerSignature On
IfModule mod_alias.c
Alias /icons/ /opt/www/apache/icons/
Directory /opt/www/apache/icons
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
/Directory
Alias /manual/ /opt/www/apache/htdocs/manual/
Directory /opt/www/apache/htdocs/manual
Options Indexes FollowSymlinks MultiViews
AllowOverride None
Order allow,deny
Allow from all
/Directory
ScriptAlias /cgi-bin/ /opt/www/apache/cgi-bin/
Directory /opt/www/apache/cgi-bin
AllowOverride None
Options None
Order allow,deny
Allow from all
/Directory
/IfModule
IfModule mod_autoindex.c
IndexOptions FancyIndexing
AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip
AddIconByType (TXT,/icons/text.gif) text/*
AddIconByType (IMG,/icons/image2.gif) image/*
AddIconByType (SND,/icons/sound2.gif) audio/*
AddIconByType (VID,/icons/movie.gif) video/*
AddIcon /icons/binary.gif .bin .exe
AddIcon /icons/binhex.gif .hqx
AddIcon /icons/tar.gif .tar
AddIcon /icons/world2.gif .wrl .wrl.gz .vrml .vrm .iv
AddIcon /icons/compressed.gif .Z .z .tgz .gz .zip
AddIcon /icons/a.gif .ps .ai .eps
AddIcon /icons/layout.gif .html .shtml .htm .pdf
AddIcon /icons/text.gif .txt
AddIcon /icons/c.gif .c
AddIcon /icons/p.gif .pl .py
AddIcon /icons/f.gif .for
AddIcon /icons/dvi.gif .dvi
AddIcon /icons/uuencoded.gif .uu
AddIcon /icons/script.gif .conf .sh .shar .csh .ksh .tcl
AddIcon /icons/tex.gif .tex
AddIcon /icons/bomb.gif core
AddIcon /icons/back.gif ..
AddIcon /icons/hand.right.gif README
AddIcon /icons/folder.gif ^^DIRECTORY^^
AddIcon /icons/blank.gif ^^BLANKICON^^
DefaultIcon /icons/unknown.gif
ReadmeName README
HeaderName HEADER
IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t
/IfModule
IfModule mod_mime.c
AddEncoding x-compress Z
AddEncoding x-gzip gz tgz
AddLanguage da .dk
AddLanguage nl .nl
AddLanguage en .en
AddLanguage et .ee
AddLanguage fr .fr
AddLanguage de .de
AddLanguage el .el
AddLanguage he .he
AddCharset ISO-8859-8 .iso8859-8
AddLanguage it .it
AddLanguage ja .ja
AddCharset ISO-2022-JP .jis
AddLanguage kr .kr
AddCharset ISO-2022-KR .iso-kr
AddLanguage nn .nn
AddLanguage no .no
AddLanguage pl .po
AddCharset ISO-8859-2 .iso-pl
AddLanguage pt .pt
AddLanguage pt-br .pt-br
AddLanguage ltz .lu
AddLanguage ca .ca
AddLanguage es .es
AddLanguage sv .se
AddLanguage cz .cz
AddLanguage ru .ru
AddLanguage zh-tw .tw
AddLanguage tw .tw
AddCharset Big5 .Big5.big5
AddCharset WINDOWS-1251 .cp-1251
AddCharset CP866.cp866
AddCharset ISO-8859-5 .iso-ru
AddCharset KOI8-R .koi8-r
AddCharset UCS-2.ucs2
AddCharset UCS-4.ucs4
AddCharset UTF-8.utf8
IfModule mod_negotiation.c
LanguagePriority en
Re: J2EE 1.3/Tomcat/JAAS
On Thu, 1 Nov 2001, Antony Bowesman wrote: Date: Thu, 01 Nov 2001 08:47:07 +0200 From: Antony Bowesman [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: J2EE 1.3/Tomcat/JAAS Craig R. McClanahan wrote: That being said, we have tried to conform to the J2EE 1.3 platform requirements where feasible (such as with the JNDI naming context), and this one (JAAS) looks like a very useful addition. In principle, it will require a Realm implementation that speaks the JAAS APIs, plus some defined mechanism for role mapping. Any volunteers working on this already? Anyone want to contribute some code? I have a JAAS Realm that supports role mapping, however, it's using an extended Realm interface so that HttpRequest parameters can be passed to the JAAS LoginModules. It still has some open issues, such as integrating JAAS logout with the container, however, what state do you need code to be in to be contributed? As far as I'm concerned, code for optional plug-in things like this need only compile cleanly to avoid problems for other developers -- it need not be functionally complete yet. (Early check-in means you get more feedback on features as well.) I can take care of updating the build environment to optionally compile this, if you want to focus on just the code. I did some reading last night on the JAAS specs and sample programs -- I'm interested in seeing how you approached role mapping. Rgds Antony Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4520] - I can not Access a context from a JSP called trought Apache
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=4520. 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=4520 I can not Access a context from a JSP called trought Apache [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2001-11-01 08:37 --- Ok... See how in server.xml Host name=localhost ... is different from ServerName 207.249.0.102 in httpd.conf??? That's your problem.. Make sure both of them are the same, and you'll be set. Anyway, this problem will go away when my next big update will come in, deprecating the use of Host in server.xml. (Yes, it's _very_ confusing). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Can someone commit this minor fix?
The following fix enables form-based authentication to work with Apache + Tomcat. Can someone add this to tomcat 3.2? Thanks! -Mike Jennings Index: jakarta-tomcat/src/share/org/apache/tomcat/task/ApacheConfig.java === RCS file: /home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/task/Attic/ApacheConfig.java,v retrieving revision 1.12.2.2 diff -r1.12.2.2 ApacheConfig.java 202a203 mod_jk.println(JkMount /*j_security_check ajp12); 289a291 mod_jk.println(JkMount + path +*j_security_check ajp12);
DO NOT REPLY [Bug 4564] - request.getRemoteAddr() and AccesLog not working
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4564. 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=4564 request.getRemoteAddr() and AccesLog not working [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2001-11-01 08:51 --- What is your Tomcat configuration? I tried the with Tomcat standalone, and with Tomcat under Apache using ajp13 and both returned the correct remote address instead of 127.0.0.1. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tomcat 4.0 JDBC servlet clustering and sharing
Greetings All. I have been following the mailing list for a while now and I had a question regarding clustering support in Tomcat 4.0. We are looking at Tomcat as a replacement for BEA Weblogic in our organization and one of the capabilities we require is JDBC session persistence for a cluster of application servers. Weblogic supports this feature and so does Tomcat by the looks of it through PersistentManager and JDBCStore. My question is this: Is this functionality still considered experimental and is buggy, or is it simply lacking documentation? The clustering support to me would be the number one selling point in using Tomcat 4.0 over commerical offering due to the fact clustering gives Tomcat an enterprise capability. We use Weblogic for some big customer systems and the licensing costs are horrendous. If no one is actively working on the session persistence and clustering side, I am willing to volunteer my services to document and development them to the same level as other features (such as the Realms support). Thanks for any help anyone can provide. Matt Pickering -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4520] - I can not Access a context from a JSP called trought Apache
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=4520. 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=4520 I can not Access a context from a JSP called trought Apache --- Additional Comments From [EMAIL PROTECTED] 2001-11-01 09:25 --- Ok, but in case I'll have a set of virtual servers? do I need to set all of them as HOST's tags? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Does anyone see anything wrong with this fix?
As far as I can tell, the following modification to the ApacheConfig.java class will enable form-based authentication to work for people using mod_jk.conf-auto with Apache. mod_jk needs to be told to handle requests of the form /webapproot/somedir/j_security_check since a login.jsp page (for form-based authentication) may exist at /webapproot/somedir/login.jsp and may specify j_security_check as the target of a form submission. In order for the form-based authentication machinery to work, it needs to get the POST request that is going to /webapproot/somedir/j_security_check which means that pattern has to be present in the mod_jk.conf-auto ie: the following line must be in the mod_jk configuration file: JkMount /webapproot/*j_security_check ajp12 Does anyone see any potential problems with this? -Mike Jennings Index: jakarta-tomcat/src/share/org/apache/tomcat/task/ApacheConfig.java === RCS file: /home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/task/Attic/ApacheConfig.java,v retrieving revision 1.12.2.2 diff -r1.12.2.2 ApacheConfig.java 202a203 mod_jk.println(JkMount /*j_security_check ajp12); 289a291 mod_jk.println(JkMount + path +/*j_security_check ajp12);
DO NOT REPLY [Bug 4560] - getParameter returning null when a value contains the equals symbol =
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=4560. 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=4560 getParameter returning null when a value contains the equals symbol = --- Additional Comments From [EMAIL PROTECTED] 2001-11-01 09:36 --- As I understand it in the HTTP spec, '=' is a special character, and should be encoded. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4520] - I can not Access a context from a JSP called trought Apache
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=4520. 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=4520 I can not Access a context from a JSP called trought Apache --- Additional Comments From [EMAIL PROTECTED] 2001-11-01 09:40 --- Touche`... Right on the spot. That's why in the upcoming releases there won't be any notion of a Host in the Apache part of server.xml, you'll be able to configure your application once, and reuse it from several different virtualhosts configured in httpd.conf... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4571] New: - Custom Tag with scriptlet Expression attribute not compiled correctly
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=4571. 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=4571 Custom Tag with scriptlet Expression attribute not compiled correctly Summary: Custom Tag with scriptlet Expression attribute not compiled correctly Product: Tomcat 4 Version: 4.0.1 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] A custom tag with a scriptlet expression for an attribute will compile the scriptlet attribute as a string, instead of a variable. The code in the jsp: test:tasks command=%=command% The resulting compiled code: _jspx_th_test_tasks_0.setCommand(%=command%); From Sun's site: http://java.sun.com/products/jsp/tutorial/TagLibraries6.html The following tag has an attribute named date, which accepts a String value obtained by evaluating the variable today: tlt:greeting date=%= today % / -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4520] - I can not Access a context from a JSP called trought Apache
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=4520. 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=4520 I can not Access a context from a JSP called trought Apache --- Additional Comments From [EMAIL PROTECTED] 2001-11-01 10:01 --- perhaps it could be convinient in this way, so I can access some resources just for the virtual host that those resources where configured to work with, I mean Thinking about a set of virtual hosts with diferent path to a DB (or diferent user) with the same name of the resourse. maybe if the INSTALL.txt had this info it would be great! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tomcat3.2.2 bug...?
Hello Apache / Cortexity: I am a software engineer that works as an Enterprise Support Specialist at MapInfo Corporation, which is located in the United States of America. One of our main products (MapInfo's MapXtremeJava4.0) ships with TOMCAT3.2.2, and as of recent, we have been getting *customer complaints* that this version of Tomcat (i.e. version 3.2.2) is throwing the following exception for no apparent reason: 2001-10-31 04:42:40 - ContextManager: SocketException reading request, ignored - java.net.SocketException: Connection reset by peer at java.net.PlainSocketImpl.socketAvailable(Native Method) at java.net.PlainSocketImpl.socketAvailable(Compiled Code) at java.net.PlainSocketImpl.available(Compiled Code) at java.net.SocketInputStream.available(Compiled Code) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(Compiled Code) at org.apache.tomcat.service.TcpWorkerThread.runIt(Compiled Code) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(Compiled Code) at java.lang.Thread.run(Compiled Code) (NOTE: we at MapInfo are able to consistently reproduce this error ourselves, in our testing lab.) After researching this exception on the internet, I came across the following site that appears to be a bug report list hosted by BugRat, which claims this exception is a bug in the TOMCAT3.2.1 release. Here's a link to the site that says this: http://w6.metronet.com/~wjm/tomcat/2001/Jan/msg00721.html I am writing you both (i.e. both apache cortexity) in order to confirm that this is indeed a bug. Specifically, here are my questions: [1] Is this a bug in TOMCAT3.2.1??? [2] Is this a bug in TOMCAT3.2.2??? [3] If it is a bug, can we safely IGNORE it? (Or is TOMCAT broken?) [4] Lastly, if it is a bug, will there be a PATCH issued? (Or some type of fix?) Thank you in advance for any information you can give regarding this matter. Sincerely, John Dove -- John Dove MapInfo Corporation -- 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/connector/http HttpProcessor.java HttpResponseStream.java
remm01/11/01 09:59:45
Modified:catalina/src/share/org/apache/catalina/connector/http
HttpProcessor.java HttpResponseStream.java
Log:
- If the client announced it was closing the connection, repeat the
connection: close in the response.
- Don't remove the transfer encoding header if chunking is disabled.
Revision ChangesPath
1.38 +5 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java
Index: HttpProcessor.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- HttpProcessor.java2001/10/04 05:44:43 1.37
+++ HttpProcessor.java2001/11/01 17:59:45 1.38
@@ -1,6 +1,6 @@
-/* * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java,v
1.37 2001/10/04 05:44:43 remm Exp $
- * $Revision: 1.37 $
- * $Date: 2001/10/04 05:44:43 $
+/* * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java,v
1.38 2001/11/01 17:59:45 remm Exp $
+ * $Revision: 1.38 $
+ * $Date: 2001/11/01 17:59:45 $
*
*
*
@@ -106,7 +106,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.37 $ $Date: 2001/10/04 05:44:43 $
+ * @version $Revision: 1.38 $ $Date: 2001/11/01 17:59:45 $
*/
final class HttpProcessor
@@ -652,6 +652,7 @@
if (header.valueEquals
(DefaultHeaders.CONNECTION_CLOSE_VALUE)) {
keepAlive = false;
+response.setHeader(Connection, close);
}
//request.setConnection(header);
/*
1.10 +6 -7
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpResponseStream.java
Index: HttpResponseStream.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpResponseStream.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- HttpResponseStream.java 2001/10/04 05:43:20 1.9
+++ HttpResponseStream.java 2001/11/01 17:59:45 1.10
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpResponseStream.java,v
1.9 2001/10/04 05:43:20 remm Exp $
- * $Revision: 1.9 $
- * $Date: 2001/10/04 05:43:20 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpResponseStream.java,v
1.10 2001/11/01 17:59:45 remm Exp $
+ * $Revision: 1.10 $
+ * $Date: 2001/11/01 17:59:45 $
*
*
*
@@ -219,15 +219,14 @@
// If we should chunk, but chunking is forbidden by the connector,
// we close the connection
response.setHeader(Connection, close);
-} else {
-response.removeHeader(Connection, close);
}
// Don't chunk is the connection will be closed
useChunking = (useChunking !response.isCloseConnection());
-if (useChunking)
+if (useChunking) {
response.setHeader(Transfer-Encoding, chunked);
-else
+} else if (response.isChunkingAllowed()) {
response.removeHeader(Transfer-Encoding, chunked);
+}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4571] - Custom Tag with scriptlet Expression attribute not compiled correctly
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=4571. 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=4571 Custom Tag with scriptlet Expression attribute not compiled correctly [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2001-11-01 10:11 --- If you want your custom tag attribute to accept runtime expressions, you must declare it so in the tag library descriptor: taglib ... tag nametasks/name ... attribute namecommand/name ... rtexprvaluetrue/rtexprvalue ... /attribute ... /tag ... /taglib If you don't declare that your tag accepts runtime expression values, the compiler will treat the content of that attribute as a text string, which is exactly what you are seeing :-). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat3.2.2 bug...?
As far as I know, that is a problem with Internet Explorer closing the socket prematurely on an http request. Try hitting your servlet or JSP with a java.net.URL object and see if you get the same error. Also try with Netscape. My guess is that this bug is just how tomcat deals with clients that don't talk to it properly. Perhaps tomcat should just swallow this exception and not report it. Hope this helps! -Mike Jennings - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, November 01, 2001 7:21 AM Subject: Tomcat3.2.2 bug...? Hello Apache / Cortexity: I am a software engineer that works as an Enterprise Support Specialist at MapInfo Corporation, which is located in the United States of America. One of our main products (MapInfo's MapXtremeJava4.0) ships with TOMCAT3.2.2, and as of recent, we have been getting *customer complaints* that this version of Tomcat (i.e. version 3.2.2) is throwing the following exception for no apparent reason: 2001-10-31 04:42:40 - ContextManager: SocketException reading request, ignored - java.net.SocketException: Connection reset by peer at java.net.PlainSocketImpl.socketAvailable(Native Method) at java.net.PlainSocketImpl.socketAvailable(Compiled Code) at java.net.PlainSocketImpl.available(Compiled Code) at java.net.SocketInputStream.available(Compiled Code) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(Compi led Code) at org.apache.tomcat.service.TcpWorkerThread.runIt(Compiled Code) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(Compiled Code) at java.lang.Thread.run(Compiled Code) (NOTE: we at MapInfo are able to consistently reproduce this error ourselves, in our testing lab.) After researching this exception on the internet, I came across the following site that appears to be a bug report list hosted by BugRat, which claims this exception is a bug in the TOMCAT3.2.1 release. Here's a link to the site that says this: http://w6.metronet.com/~wjm/tomcat/2001/Jan/msg00721.html I am writing you both (i.e. both apache cortexity) in order to confirm that this is indeed a bug. Specifically, here are my questions: [1] Is this a bug in TOMCAT3.2.1??? [2] Is this a bug in TOMCAT3.2.2??? [3] If it is a bug, can we safely IGNORE it? (Or is TOMCAT broken?) [4] Lastly, if it is a bug, will there be a PATCH issued? (Or some type of fix?) Thank you in advance for any information you can give regarding this matter. Sincerely, John Dove -- John Dove MapInfo Corporation -- 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: Tomcat3.2.2 bug...?
You can safely ignore this exception. The explanation: This is caused by the interaction between tc 3.2.X and ie4.0 and up, ie abruptly breaks the connection when it finds a resource that it already has in cache.. 3.3 and up do not suffer this glitch .. Saludos , Ignacio J. Ortega -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: jueves 1 de noviembre de 2001 16:21 Para: [EMAIL PROTECTED]; [EMAIL PROTECTED] Asunto: Tomcat3.2.2 bug...? Hello Apache / Cortexity: I am a software engineer that works as an Enterprise Support Specialist at MapInfo Corporation, which is located in the United States of America. One of our main products (MapInfo's MapXtremeJava4.0) ships with TOMCAT3.2.2, and as of recent, we have been getting *customer complaints* that this version of Tomcat (i.e. version 3.2.2) is throwing the following exception for no apparent reason: 2001-10-31 04:42:40 - ContextManager: SocketException reading request, ignored - java.net.SocketException: Connection reset by peer at java.net.PlainSocketImpl.socketAvailable(Native Method) at java.net.PlainSocketImpl.socketAvailable(Compiled Code) at java.net.PlainSocketImpl.available(Compiled Code) at java.net.SocketInputStream.available(Compiled Code) at org.apache.tomcat.service.http.HttpConnectionHandler.processCo nnection(Compiled Code) at org.apache.tomcat.service.TcpWorkerThread.runIt(Compiled Code) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(Compiled Code) at java.lang.Thread.run(Compiled Code) (NOTE: we at MapInfo are able to consistently reproduce this error ourselves, in our testing lab.) After researching this exception on the internet, I came across the following site that appears to be a bug report list hosted by BugRat, which claims this exception is a bug in the TOMCAT3.2.1 release. Here's a link to the site that says this: http://w6.metronet.com/~wjm/tomcat/2001/Jan/msg00721.html I am writing you both (i.e. both apache cortexity) in order to confirm that this is indeed a bug. Specifically, here are my questions: [1] Is this a bug in TOMCAT3.2.1??? [2] Is this a bug in TOMCAT3.2.2??? [3] If it is a bug, can we safely IGNORE it? (Or is TOMCAT broken?) [4] Lastly, if it is a bug, will there be a PATCH issued? (Or some type of fix?) Thank you in advance for any information you can give regarding this matter. Sincerely, John Dove -- John Dove MapInfo Corporation -- 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: Does anyone see anything wrong with this fix?
I believe mod_jk's JkMount currently only accepts mappings in the form: JkMount /path/* JkMount /path/*.ext Something like: JkMount /path/*something is another way of saying: JkMount /path/* which makes the other settings written irrelevant since all requests will be mapped to Tomcat. See the: /* context based */ asterisk[1] = '\0'; in jk_uri_worker_map.c file. Tomcat 3.3 deals with this by having the generated mod_jk.conf use the JkMount /path/* approach by default. If you add forwardAll=false to the ApacheConfig line in server.xml, it will write a mod_jk.conf similar to that of Tomcat 3.2.x, but with additional mappings. These additional mappings for the context will include one like the following: JkMount /examples/jsp/security/login/j_security_check ajp13 If you want j_security_check to work in Tomcat 3.2.x without mapping all requests to Tomcat, you will need to add mappings like this. It is beyond the scope of Tomcat 3.2.x development to back port Tomcat 3.3's behavior to Tomcat 3.2.x. Cheers, Larry -Original Message- From: Michael Jennings [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 01, 2001 12:35 PM To: [EMAIL PROTECTED] Subject: Does anyone see anything wrong with this fix? As far as I can tell, the following modification to the ApacheConfig.java class will enable form-based authentication to work for people using mod_jk.conf-auto with Apache. mod_jk needs to be told to handle requests of the form /webapproot/somedir/j_security_check since a login.jsp page (for form-based authentication) may exist at /webapproot/somedir/login.jsp and may specify j_security_check as the target of a form submission. In order for the form-based authentication machinery to work, it needs to get the POST request that is going to /webapproot/somedir/j_security_check which means that pattern has to be present in the mod_jk.conf-auto ie: the following line must be in the mod_jk configuration file: JkMount /webapproot/*j_security_check ajp12 Does anyone see any potential problems with this? -Mike Jennings Index: jakarta-tomcat/src/share/org/apache/tomcat/task/ApacheConfig.java === RCS file: /home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/tas k/Attic/ApacheConfig.java,v retrieving revision 1.12.2.2 diff -r1.12.2.2 ApacheConfig.java 202a203 mod_jk.println(JkMount /*j_security_check ajp12); 289a291 mod_jk.println(JkMount + path +/*j_security_check ajp12); -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat3.2.2 bug...?
Hello Ignacio, Thank you for the quick response. Are you part of the Apache Software Foundation? Or are you part of Cortexity? Thanks again, John Dove -- John Dove MapInfo Tech Support Ignacio J. Ortega To: 'Tomcat Developers List' [EMAIL PROTECTED] [EMAIL PROTECTED] cc: '[EMAIL PROTECTED]' [EMAIL PROTECTED] s Subject: RE: Tomcat3.2.2 bug...? 11/01/01 01:19 PM You can safely ignore this exception. The explanation: This is caused by the interaction between tc 3.2.X and ie4.0 and up, ie abruptly breaks the connection when it finds a resource that it already has in cache.. 3.3 and up do not suffer this glitch .. Saludos , Ignacio J. Ortega -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: jueves 1 de noviembre de 2001 16:21 Para: [EMAIL PROTECTED]; [EMAIL PROTECTED] Asunto: Tomcat3.2.2 bug...? Hello Apache / Cortexity: I am a software engineer that works as an Enterprise Support Specialist at MapInfo Corporation, which is located in the United States of America. One of our main products (MapInfo's MapXtremeJava4.0) ships with TOMCAT3.2.2, and as of recent, we have been getting *customer complaints* that this version of Tomcat (i.e. version 3.2.2) is throwing the following exception for no apparent reason: 2001-10-31 04:42:40 - ContextManager: SocketException reading request, ignored - java.net.SocketException: Connection reset by peer at java.net.PlainSocketImpl.socketAvailable(Native Method) at java.net.PlainSocketImpl.socketAvailable(Compiled Code) at java.net.PlainSocketImpl.available(Compiled Code) at java.net.SocketInputStream.available(Compiled Code) at org.apache.tomcat.service.http.HttpConnectionHandler.processCo nnection(Compiled Code) at org.apache.tomcat.service.TcpWorkerThread.runIt(Compiled Code) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(Compiled Code) at java.lang.Thread.run(Compiled Code) (NOTE: we at MapInfo are able to consistently reproduce this error ourselves, in our testing lab.) After researching this exception on the internet, I came across the following site that appears to be a bug report list hosted by BugRat, which claims this exception is a bug in the TOMCAT3.2.1 release. Here's a link to the site that says this: http://w6.metronet.com/~wjm/tomcat/2001/Jan/msg00721.html I am writing you both (i.e. both apache cortexity) in order to confirm that this is indeed a bug. Specifically, here are my questions: [1] Is this a bug in TOMCAT3.2.1??? [2] Is this a bug in TOMCAT3.2.2??? [3] If it is a bug, can we safely IGNORE it? (Or is TOMCAT broken?) [4] Lastly, if it is a bug, will there be a PATCH issued? (Or some type of fix?) Thank you in advance for any information you can give regarding this matter. Sincerely, John Dove -- John Dove MapInfo Corporation -- 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: Can someone commit this minor fix?
I'll get into Tomcat 3.2.4 before the final release. Marc Saegesser -Original Message- From: Michael Jennings [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 01, 2001 10:51 AM To: [EMAIL PROTECTED] Subject: Can someone commit this minor fix? The following fix enables form-based authentication to work with Apache + Tomcat. Can someone add this to tomcat 3.2? Thanks! -Mike Jennings Index: jakarta-tomcat/src/share/org/apache/tomcat/task/ApacheConfig.java === RCS file: /home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/tas k/Attic/ApacheConfig.java,v retrieving revision 1.12.2.2 diff -r1.12.2.2 ApacheConfig.java 202a203 mod_jk.println(JkMount /*j_security_check ajp12); 289a291 mod_jk.println(JkMount + path +*j_security_check ajp12); -- 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/loader WebappClassLoader.java
remm01/11/01 10:45:01
Modified:catalina/src/share/org/apache/catalina/loader
WebappClassLoader.java
Log:
- Clean up the URLs. I don't know if it was actually causing some problems, but it
may have.
Revision ChangesPath
1.25 +27 -12
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
Index: WebappClassLoader.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- WebappClassLoader.java2001/10/31 23:17:37 1.24
+++ WebappClassLoader.java2001/11/01 18:45:01 1.25
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
1.24 2001/10/31 23:17:37 remm Exp $
- * $Revision: 1.24 $
- * $Date: 2001/10/31 23:17:37 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
1.25 2001/11/01 18:45:01 remm Exp $
+ * $Revision: 1.25 $
+ * $Date: 2001/11/01 18:45:01 $
*
*
*
@@ -119,12 +119,10 @@
* p
* strongIMPLEMENTATION NOTE/strong - No check for sealing violations or
* security is made unless a security manager is present.
- * p
- * strongFIXME/strong - Implement findResources.
*
* @author Remy Maucherat
* @author Craig R. McClanahan
- * @version $Revision: 1.24 $ $Date: 2001/10/31 23:17:37 $
+ * @version $Revision: 1.25 $ $Date: 2001/11/01 18:45:01 $
*/
public class WebappClassLoader
extends URLClassLoader
@@ -1007,7 +1005,7 @@
// Note : Not getting an exception here means the resource was
// found
try {
-result.addElement(new File(files[i], name).toURL());
+result.addElement(getURL(new File(files[i], name)));
} catch (MalformedURLException e) {
// Ignore
}
@@ -1020,7 +1018,7 @@
JarEntry jarEntry = jarFiles[i].getJarEntry(name);
if (jarEntry != null) {
try {
-String jarFakeUrl = jarRealFiles[i].toURL().toString();
+String jarFakeUrl = getURL(jarRealFiles[i]).toString();
jarFakeUrl = jar: + jarFakeUrl + !/ + name;
result.addElement(new URL(jarFakeUrl));
} catch (MalformedURLException e) {
@@ -1418,9 +1416,9 @@
URL[] urls = new URL[length];
for (i = 0; i length; i++) {
if (i filesLength) {
-urls[i] = files[i].toURL();
+urls[i] = getURL(files[i]);
} else if (i filesLength + jarFilesLength) {
-urls[i] = jarRealFiles[i - filesLength].toURL();
+urls[i] = getURL(jarRealFiles[i - filesLength]);
} else {
urls[i] = external[i - filesLength - jarFilesLength];
}
@@ -1652,7 +1650,7 @@
entry = new ResourceEntry();
try {
-entry.source = new File(files[i], path).toURL();
+entry.source = getURL(new File(files[i], path));
} catch (MalformedURLException e) {
return null;
}
@@ -1704,7 +1702,7 @@
entry = new ResourceEntry();
try {
-String jarFakeUrl = jarRealFiles[i].toURL().toString();
+String jarFakeUrl = getURL(jarRealFiles[i]).toString();
jarFakeUrl = jar: + jarFakeUrl + !/ + path;
entry.source = new URL(jarFakeUrl);
} catch (MalformedURLException e) {
@@ -1884,6 +1882,23 @@
return false;
return true;
+
+}
+
+
+/**
+ * Get URL.
+ */
+protected URL getURL(File file)
+throws MalformedURLException {
+
+File realFile = file;
+try {
+realFile = realFile.getCanonicalFile();
+} catch (IOException e) {
+// Ignore
+}
+return realFile.toURL();
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat3.2.2 bug...?
You have posted to tomat-dev mail list at http://jakarta.apache.org/.. Cortexity was hosting a bug tracking system at his facilities many time ago this system is not used anymore, and the bugs were imported into bugzilla, now the bug tracking system is at http://nagoya.apache.org/bugzilla/ Bugs imported from bugrat in Cortexity system can be found searching for BugRat Report#NNN in the summary line closed and resolved bugs were not imported Saludos , Ignacio J. Ortega -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: jueves 1 de noviembre de 2001 19:34 Para: Ignacio J. Ortega Cc: '[EMAIL PROTECTED]'; 'Tomcat Developers List' Asunto: RE: Tomcat3.2.2 bug...? Hello Ignacio, Thank you for the quick response. Are you part of the Apache Software Foundation? Or are you part of Cortexity? Thanks again, John Dove -- John Dove MapInfo Tech Support Ignacio J. Ortega To: 'Tomcat Developers List' [EMAIL PROTECTED] [EMAIL PROTECTED] cc: '[EMAIL PROTECTED]' [EMAIL PROTECTED] s Subject: RE: Tomcat3.2.2 bug...? 11/01/01 01:19 PM You can safely ignore this exception. The explanation: This is caused by the interaction between tc 3.2.X and ie4.0 and up, ie abruptly breaks the connection when it finds a resource that it already has in cache.. 3.3 and up do not suffer this glitch .. Saludos , Ignacio J. Ortega -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: jueves 1 de noviembre de 2001 16:21 Para: [EMAIL PROTECTED]; [EMAIL PROTECTED] Asunto: Tomcat3.2.2 bug...? Hello Apache / Cortexity: I am a software engineer that works as an Enterprise Support Specialist at MapInfo Corporation, which is located in the United States of America. One of our main products (MapInfo's MapXtremeJava4.0) ships with TOMCAT3.2.2, and as of recent, we have been getting *customer complaints* that this version of Tomcat (i.e. version 3.2.2) is throwing the following exception for no apparent reason: 2001-10-31 04:42:40 - ContextManager: SocketException reading request, ignored - java.net.SocketException: Connection reset by peer at java.net.PlainSocketImpl.socketAvailable(Native Method) at java.net.PlainSocketImpl.socketAvailable(Compiled Code) at java.net.PlainSocketImpl.available(Compiled Code) at java.net.SocketInputStream.available(Compiled Code) at org.apache.tomcat.service.http.HttpConnectionHandler.processCo nnection(Compiled Code) at org.apache.tomcat.service.TcpWorkerThread.runIt(Compiled Code) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(Compiled Code) at java.lang.Thread.run(Compiled Code) (NOTE: we at MapInfo are able to consistently reproduce this error ourselves, in our testing lab.) After researching this exception on the internet, I came across the following site that appears to be a bug report list hosted by BugRat, which claims this exception is a bug in the TOMCAT3.2.1 release. Here's a link to the site that says this: http://w6.metronet.com/~wjm/tomcat/2001/Jan/msg00721.html I am writing you both (i.e. both apache cortexity) in order to confirm that this is indeed a bug. Specifically, here are my questions: [1] Is this a bug in TOMCAT3.2.1??? [2] Is this a bug in TOMCAT3.2.2??? [3] If it is a bug, can we safely IGNORE it? (Or is TOMCAT broken?) [4] Lastly, if it is a bug, will there be a PATCH issued? (Or some type of fix?) Thank you in advance for any information you can give regarding this matter. Sincerely, John Dove -- John Dove MapInfo Corporation -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail:
Re: Can someone commit this minor fix?
Thanks! -Mike - Original Message - From: Marc Saegesser [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, November 01, 2001 10:54 AM Subject: RE: Can someone commit this minor fix? I'll get into Tomcat 3.2.4 before the final release. Marc Saegesser -Original Message- From: Michael Jennings [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 01, 2001 10:51 AM To: [EMAIL PROTECTED] Subject: Can someone commit this minor fix? The following fix enables form-based authentication to work with Apache + Tomcat. Can someone add this to tomcat 3.2? Thanks! -Mike Jennings Index: jakarta-tomcat/src/share/org/apache/tomcat/task/ApacheConfig.java === RCS file: /home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/tas k/Attic/ApacheConfig.java,v retrieving revision 1.12.2.2 diff -r1.12.2.2 ApacheConfig.java 202a203 mod_jk.println(JkMount /*j_security_check ajp12); 289a291 mod_jk.println(JkMount + path +*j_security_check ajp12); -- 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]
How does Tomcat handle discarded-request
Hi, I issues to Tomcat one request which takes kind of long time to response, when the backend servlet or bean is working on the result, I just can not wait and clicked somewhere on my browser page to issue another request, in this case, I am wondering what Tomcat to do with the previous working servlet, is it still runing until finish or Tomcat just kill the thread and force it stop. The question is closely related to connection pool, without the work finish, the connection will not be returned to pool in working bean or servlet, I suppose that Tomcat keeps the servlet thread running until it finishes, otherwise, there is no way for the servlet to finish his work and return connection. Any response is appreciated. Thanks, David -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Can someone commit this minor fix?
Please see my prior post as to why this may not do what you expect, i.e. JkMount /*j_security_check ajp12 will map *all* requests to Tomcat. :) Larry -Original Message- From: Michael Jennings [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 01, 2001 3:05 PM To: Tomcat Developers List Subject: Re: Can someone commit this minor fix? Thanks! -Mike - Original Message - From: Marc Saegesser [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, November 01, 2001 10:54 AM Subject: RE: Can someone commit this minor fix? I'll get into Tomcat 3.2.4 before the final release. Marc Saegesser -Original Message- From: Michael Jennings [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 01, 2001 10:51 AM To: [EMAIL PROTECTED] Subject: Can someone commit this minor fix? The following fix enables form-based authentication to work with Apache + Tomcat. Can someone add this to tomcat 3.2? Thanks! -Mike Jennings Index: jakarta-tomcat/src/share/org/apache/tomcat/task/ApacheConfig.java === RCS file: /home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/tas k/Attic/ApacheConfig.java,v retrieving revision 1.12.2.2 diff -r1.12.2.2 ApacheConfig.java 202a203 mod_jk.println(JkMount /*j_security_check ajp12); 289a291 mod_jk.println(JkMount + path +*j_security_check ajp12); -- 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]
RE: Can someone commit this minor fix?
Mike, [I tried sending this privately, but it bounced.] I just got caught up on the rest of the messages in tomcat-dev and it looks like this patch doesn't do what you expect. Mod_jk doesen't handle wildcards per se. It only knows two kinds of mappings JkMount /path/* and JkMount *.ext The way code is written, doing JkMount /path/*j_security_check will actually map all requests to /path/* to Tomcat. Now, that isn't necessarily a bad thing, and unless your application has lots of static data that would be better served through Apache, I think its safer to route all requests to resources inside the web application through Tomcat. All of my applications now just do a JkMount /app/* AJP13. Marc Saegesser -Original Message- From: Michael Jennings [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 01, 2001 2:08 PM To: [EMAIL PROTECTED] Subject: Re: Can someone commit this minor fix? Hi Marc, The diff to use is Index: jakarta-tomcat/src/share/org/apache/tomcat/task/ApacheConfig.java === RCS file: /home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/tas k/Attic/Apache Config.java,v retrieving revision 1.12.2.2 diff -r1.12.2.2 ApacheConfig.java 202a203 mod_jk.println(JkMount /*j_security_check ajp12); 289a291 mod_jk.println(JkMount + path +/*j_security_check ajp12); The other one you have is missing the / before *j_security_check Thanks again! -Mike - Original Message - From: Marc Saegesser [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, November 01, 2001 10:54 AM Subject: RE: Can someone commit this minor fix? I'll get into Tomcat 3.2.4 before the final release. Marc Saegesser -Original Message- From: Michael Jennings [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 01, 2001 10:51 AM To: [EMAIL PROTECTED] Subject: Can someone commit this minor fix? The following fix enables form-based authentication to work with Apache + Tomcat. Can someone add this to tomcat 3.2? Thanks! -Mike Jennings Index: jakarta-tomcat/src/share/org/apache/tomcat/task/ApacheConfig.java === RCS file: /home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/tas k/Attic/ApacheConfig.java,v retrieving revision 1.12.2.2 diff -r1.12.2.2 ApacheConfig.java 202a203 mod_jk.println(JkMount /*j_security_check ajp12); 289a291 mod_jk.println(JkMount + path +*j_security_check ajp12); -- 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: Does anyone see anything wrong with this fix?
It isn't a matter of how the '*' is interpreted, but that mod_jk will put a null terminator following the '*' if the next character isn't a '.'. Thus: JkMount /*something ... and JkMount /* ... end up being equivalent. So far no one has found time to add more sophisticated string matching. Feel free to submit a patch, though this should be against mod_jk in jakarta-tomcat-connectors. There was an earlier attempt in Tomcat 3.3 to have mod_jk work with Handler directives in the httpd.conf. This would allow Apache's pattern matching abilities to be used to map requests to Tomcat. It wasn't feasible to finish this approach, so it was removed from Tomcat 3.3. It may still get implemented in the jakarta-tomcat-connectors version of mod_jk, assuming a better approach doesn't present itself. Larry -Original Message- From: Michael Jennings [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 01, 2001 3:14 PM To: Tomcat Developers List Subject: Re: Does anyone see anything wrong with this fix? Thanks for the feedback. So /path/*.something will handle URI's like /path/sub1/sub2/file.something /path/sub1/sub2/anotherfilename.something but /path/*something will NOT handle URI's like /path/sub1/sub2/here_is_something or /path/moreofsomething or /path/sub1/sub2/sub3/something So the asterisk can only be used in conjunction with a dot as in *.something as far as URI mapping is concerned? So the real wildcard sequence is actually *. and *xyz is interpreted as *? Wouldn't it be better to make mod_jk deal with wildcards a little bit more intelligently, or am I missing something? (which is more likely) -Mike Jennings - Original Message - From: Larry Isaacs [EMAIL PROTECTED] To: 'Tomcat Developers List' [EMAIL PROTECTED] Sent: Thursday, November 01, 2001 10:42 AM Subject: RE: Does anyone see anything wrong with this fix? I believe mod_jk's JkMount currently only accepts mappings in the form: JkMount /path/* JkMount /path/*.ext Something like: JkMount /path/*something is another way of saying: JkMount /path/* which makes the other settings written irrelevant since all requests will be mapped to Tomcat. See the: /* context based */ asterisk[1] = '\0'; in jk_uri_worker_map.c file. Tomcat 3.3 deals with this by having the generated mod_jk.conf use the JkMount /path/* approach by default. If you add forwardAll=false to the ApacheConfig line in server.xml, it will write a mod_jk.conf similar to that of Tomcat 3.2.x, but with additional mappings. These additional mappings for the context will include one like the following: JkMount /examples/jsp/security/login/j_security_check ajp13 If you want j_security_check to work in Tomcat 3.2.x without mapping all requests to Tomcat, you will need to add mappings like this. It is beyond the scope of Tomcat 3.2.x development to back port Tomcat 3.3's behavior to Tomcat 3.2.x. Cheers, Larry -Original Message- From: Michael Jennings [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 01, 2001 12:35 PM To: [EMAIL PROTECTED] Subject: Does anyone see anything wrong with this fix? As far as I can tell, the following modification to the ApacheConfig.java class will enable form-based authentication to work for people using mod_jk.conf-auto with Apache. mod_jk needs to be told to handle requests of the form /webapproot/somedir/j_security_check since a login.jsp page (for form-based authentication) may exist at /webapproot/somedir/login.jsp and may specify j_security_check as the target of a form submission. In order for the form-based authentication machinery to work, it needs to get the POST request that is going to /webapproot/somedir/j_security_check which means that pattern has to be present in the mod_jk.conf-auto ie: the following line must be in the mod_jk configuration file: JkMount /webapproot/*j_security_check ajp12 Does anyone see any potential problems with this? -Mike Jennings Index: jakarta-tomcat/src/share/org/apache/tomcat/task/ApacheConfig.java === RCS file: /home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/tas k/Attic/ApacheConfig.java,v retrieving revision 1.12.2.2 diff -r1.12.2.2 ApacheConfig.java 202a203 mod_jk.println(JkMount /*j_security_check ajp12); 289a291 mod_jk.println(JkMount + path +/*j_security_check ajp12); -- 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,
Re: How does Tomcat handle discarded-request
This depends on the version of Tomcat, and to some extent whether you are running Tomcat behind another web server. - Original Message - From: Hu, Xuebing [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 01, 2001 11:57 AM Subject: How does Tomcat handle discarded-request Hi, I issues to Tomcat one request which takes kind of long time to response, when the backend servlet or bean is working on the result, I just can not wait and clicked somewhere on my browser page to issue another request, in this case, I am wondering what Tomcat to do with the previous working servlet, is it still runing until finish or Tomcat just kill the thread and force it stop. The question is closely related to connection pool, without the work finish, the connection will not be returned to pool in working bean or servlet, I suppose that Tomcat keeps the servlet thread running until it finishes, otherwise, there is no way for the servlet to finish his work and return connection. Any response is appreciated. Thanks, David -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] ** This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Does anyone see anything wrong with this fix?
Thanks! I'll take a look at the mod_jk C sources and see about submitting a patch. Thanks again for pointing out the problem. -Mike - Original Message - From: Larry Isaacs [EMAIL PROTECTED] To: 'Tomcat Developers List' [EMAIL PROTECTED] Sent: Thursday, November 01, 2001 12:32 PM Subject: RE: Does anyone see anything wrong with this fix? It isn't a matter of how the '*' is interpreted, but that mod_jk will put a null terminator following the '*' if the next character isn't a '.'. Thus: JkMount /*something ... and JkMount /* ... end up being equivalent. So far no one has found time to add more sophisticated string matching. Feel free to submit a patch, though this should be against mod_jk in jakarta-tomcat-connectors. There was an earlier attempt in Tomcat 3.3 to have mod_jk work with Handler directives in the httpd.conf. This would allow Apache's pattern matching abilities to be used to map requests to Tomcat. It wasn't feasible to finish this approach, so it was removed from Tomcat 3.3. It may still get implemented in the jakarta-tomcat-connectors version of mod_jk, assuming a better approach doesn't present itself. Larry -Original Message- From: Michael Jennings [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 01, 2001 3:14 PM To: Tomcat Developers List Subject: Re: Does anyone see anything wrong with this fix? Thanks for the feedback. So /path/*.something will handle URI's like /path/sub1/sub2/file.something /path/sub1/sub2/anotherfilename.something but /path/*something will NOT handle URI's like /path/sub1/sub2/here_is_something or /path/moreofsomething or /path/sub1/sub2/sub3/something So the asterisk can only be used in conjunction with a dot as in *.something as far as URI mapping is concerned? So the real wildcard sequence is actually *. and *xyz is interpreted as *? Wouldn't it be better to make mod_jk deal with wildcards a little bit more intelligently, or am I missing something? (which is more likely) -Mike Jennings - Original Message - From: Larry Isaacs [EMAIL PROTECTED] To: 'Tomcat Developers List' [EMAIL PROTECTED] Sent: Thursday, November 01, 2001 10:42 AM Subject: RE: Does anyone see anything wrong with this fix? I believe mod_jk's JkMount currently only accepts mappings in the form: JkMount /path/* JkMount /path/*.ext Something like: JkMount /path/*something is another way of saying: JkMount /path/* which makes the other settings written irrelevant since all requests will be mapped to Tomcat. See the: /* context based */ asterisk[1] = '\0'; in jk_uri_worker_map.c file. Tomcat 3.3 deals with this by having the generated mod_jk.conf use the JkMount /path/* approach by default. If you add forwardAll=false to the ApacheConfig line in server.xml, it will write a mod_jk.conf similar to that of Tomcat 3.2.x, but with additional mappings. These additional mappings for the context will include one like the following: JkMount /examples/jsp/security/login/j_security_check ajp13 If you want j_security_check to work in Tomcat 3.2.x without mapping all requests to Tomcat, you will need to add mappings like this. It is beyond the scope of Tomcat 3.2.x development to back port Tomcat 3.3's behavior to Tomcat 3.2.x. Cheers, Larry -Original Message- From: Michael Jennings [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 01, 2001 12:35 PM To: [EMAIL PROTECTED] Subject: Does anyone see anything wrong with this fix? As far as I can tell, the following modification to the ApacheConfig.java class will enable form-based authentication to work for people using mod_jk.conf-auto with Apache. mod_jk needs to be told to handle requests of the form /webapproot/somedir/j_security_check since a login.jsp page (for form-based authentication) may exist at /webapproot/somedir/login.jsp and may specify j_security_check as the target of a form submission. In order for the form-based authentication machinery to work, it needs to get the POST request that is going to /webapproot/somedir/j_security_check which means that pattern has to be present in the mod_jk.conf-auto ie: the following line must be in the mod_jk configuration file: JkMount /webapproot/*j_security_check ajp12 Does anyone see any potential problems with this? -Mike Jennings Index: jakarta-tomcat/src/share/org/apache/tomcat/task/ApacheConfig.java === RCS file: /home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/tas k/Attic/ApacheConfig.java,v retrieving revision 1.12.2.2 diff -r1.12.2.2 ApacheConfig.java 202a203
DO NOT REPLY [Bug 4564] - request.getRemoteAddr() and AccesLog not working
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4564. 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=4564 request.getRemoteAddr() and AccesLog not working [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | --- Additional Comments From [EMAIL PROTECTED] 2001-11-01 13:13 --- I'm reopening so that I can find it again. The bug is indeed there, but you need to hit the refresh button a few times to see it. The problem is that HttpRequest.recycle is leaving remoteAddrMB and remoteHostMB with their localhost defaults. I can fix this later if someone doesn't beat me to it. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat3.2.2 bug...?
Bugs imported from bugrat in Cortexity system can be found searching for BugRat Report#NNN in the summary line closed and resolved bugs were not imported On the official Apache bugdatabase (i.e. http://nagoya.apache.org/bugzilla/ ), I could not find my reported Tomcat3.2.x bug. I searched for BugRat Report#792 (without the quotes) ...but found nothing. I assume then, this must be one of the resolved bugs that did not get imported? Thanks Again, John Dove -- John Dove MapInfo Tech Support Ignacio J. Ortega To: '[EMAIL PROTECTED]' [EMAIL PROTECTED], 'tomcat-dev' [EMAIL PROTECTED][EMAIL PROTECTED] s cc: Subject: RE: Tomcat3.2.2 bug...? 11/01/01 02:01 PM You have posted to tomat-dev mail list at http://jakarta.apache.org/.. Cortexity was hosting a bug tracking system at his facilities many time ago this system is not used anymore, and the bugs were imported into bugzilla, now the bug tracking system is at http://nagoya.apache.org/bugzilla/ Bugs imported from bugrat in Cortexity system can be found searching for BugRat Report#NNN in the summary line closed and resolved bugs were not imported Saludos , Ignacio J. Ortega -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: jueves 1 de noviembre de 2001 19:34 Para: Ignacio J. Ortega Cc: '[EMAIL PROTECTED]'; 'Tomcat Developers List' Asunto: RE: Tomcat3.2.2 bug...? Hello Ignacio, Thank you for the quick response. Are you part of the Apache Software Foundation? Or are you part of Cortexity? Thanks again, John Dove -- John Dove MapInfo Tech Support Ignacio J. Ortega To: 'Tomcat Developers List' [EMAIL PROTECTED] [EMAIL PROTECTED] cc: '[EMAIL PROTECTED]' [EMAIL PROTECTED] s Subject: RE: Tomcat3.2.2 bug...? 11/01/01 01:19 PM You can safely ignore this exception. The explanation: This is caused by the interaction between tc 3.2.X and ie4.0 and up, ie abruptly breaks the connection when it finds a resource that it already has in cache.. 3.3 and up do not suffer this glitch .. Saludos , Ignacio J. Ortega -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: jueves 1 de noviembre de 2001 16:21 Para: [EMAIL PROTECTED]; [EMAIL PROTECTED] Asunto: Tomcat3.2.2 bug...? Hello Apache / Cortexity: I am a software engineer that works as an Enterprise Support Specialist at MapInfo Corporation, which is located in the United States of America. One of our main products (MapInfo's MapXtremeJava4.0) ships with TOMCAT3.2.2, and as of recent, we have been getting *customer complaints* that this version of Tomcat (i.e. version 3.2.2) is throwing the following exception for no apparent reason: 2001-10-31 04:42:40 - ContextManager: SocketException reading request, ignored - java.net.SocketException: Connection reset by peer at java.net.PlainSocketImpl.socketAvailable(Native Method) at java.net.PlainSocketImpl.socketAvailable(Compiled Code) at java.net.PlainSocketImpl.available(Compiled Code) at java.net.SocketInputStream.available(Compiled Code) at org.apache.tomcat.service.http.HttpConnectionHandler.processCo nnection(Compiled Code) at org.apache.tomcat.service.TcpWorkerThread.runIt(Compiled Code) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(Compiled Code) at java.lang.Thread.run(Compiled Code) (NOTE: we at MapInfo are able to consistently reproduce this error ourselves, in our testing lab.) After researching this exception on the internet, I came across the following site that appears to be a bug report list hosted by BugRat, which claims this exception is a bug in the TOMCAT3.2.1
RE: How does Tomcat handle discarded-request
Thanks, Bill for the response. Any detail? I am currently using TOMCAT 3.2.3. David -- From: Bill Barker[SMTP:[EMAIL PROTECTED]] Reply To: Tomcat Developers List Sent: Thursday, November 01, 2001 2:57 PM To: Tomcat Developers List Subject: Re: How does Tomcat handle discarded-request This depends on the version of Tomcat, and to some extent whether you are running Tomcat behind another web server. - Original Message - From: Hu, Xuebing [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 01, 2001 11:57 AM Subject: How does Tomcat handle discarded-request Hi, I issues to Tomcat one request which takes kind of long time to response, when the backend servlet or bean is working on the result, I just can not wait and clicked somewhere on my browser page to issue another request, in this case, I am wondering what Tomcat to do with the previous working servlet, is it still runing until finish or Tomcat just kill the thread and force it stop. The question is closely related to connection pool, without the work finish, the connection will not be returned to pool in working bean or servlet, I suppose that Tomcat keeps the servlet thread running until it finishes, otherwise, there is no way for the servlet to finish his work and return connection. Any response is appreciated. Thanks, David -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] ** This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. -- 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 4573] New: - All the *.sh files under bin are not executable in the release build4.0.1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4573. 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=4573 All the *.sh files under bin are not executable in the release build4.0.1 Summary: All the *.sh files under bin are not executable in the release build4.0.1 Product: Tomcat 4 Version: 4.0.1 Beta 1 Platform: Sun URL: http://jakarta.apache.org/builds/jakarta-tomcat- 4.0/release/v4.0.1/bin/ OS/Version: Solaris Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] There is a problem on the jakata-tomcat-4.0.1.zip build. After I unzip them on the solaris, all the sh.* files under bin directory don't have execution rights. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: How does Tomcat handle discarded-request
On Thu, 1 Nov 2001, Hu, Xuebing wrote: Date: Thu, 1 Nov 2001 17:03:29 -0500 From: Hu, Xuebing [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: RE: How does Tomcat handle discarded-request Thanks, Bill for the response. Any detail? I am currently using TOMCAT 3.2.3. In general, you cannot count on the server even knowing that the request was cancelled. The following scenarios are all possible: * The entire request was read before the cancel happened, so no notification is possible until the response is written back out and receives an IOException. (This is by far the most common case.) * Tomcat was able to read the headers, but does not need to read the data. In this case, it is the application (not Tomcat) that would receive an IOException when trying to process the input stream. Therefore, it is up to your application to respond appropriately. * Tomcat was unable to read the headers (because the cancel happened very quickly). It will typically log an exception and throw the request away. David Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4573] - All the *.sh files under bin are not executable in the release build4.0.1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4573. 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=4573 All the *.sh files under bin are not executable in the release build4.0.1 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2001-11-01 14:21 --- Unfortunately, the ZIP file structure does not contain Unix permission settings. Therefore, you need to use the .tar.gz version (and unpack it with gnutar if you are on Solaris) to get these bits set correctly. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/webapp/support apjava.m4 aplocal.m4 buildconf.sh formatfile.c
pier01/11/01 14:20:52 Modified:webapp INSTALL.txt Makedefs.in Makefile.in Makefile.win README.txt configure.in webapp/apache-1.3 Makefile.in Makefile.win mod_webapp.c webapp/apache-2.0 Makefile.in mod_webapp.c webapp/docs build-u.html index.html license.html webapp/include wa.h wa_config.h wa_main.h wa_request.h webapp/java Makefile.in webapp/lib Makefile.in Makefile.win webapp/support apjava.m4 aplocal.m4 buildconf.sh formatfile.c Log: Changed EMail addresses in source files. Revision ChangesPath 1.5 +1 -1 jakarta-tomcat-connectors/webapp/INSTALL.txt Index: INSTALL.txt === RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/INSTALL.txt,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- INSTALL.txt 2001/08/17 18:17:35 1.4 +++ INSTALL.txt 2001/11/01 22:20:51 1.5 @@ -129,4 +129,4 @@ Have fun... -Pier [EMAIL PROTECTED] +Pier [EMAIL PROTECTED] 1.13 +2 -2 jakarta-tomcat-connectors/webapp/Makedefs.in Index: Makedefs.in === RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/Makedefs.in,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- Makedefs.in 2001/10/10 15:30:24 1.12 +++ Makedefs.in 2001/11/01 22:20:51 1.13 @@ -55,8 +55,8 @@ # # # = # -# @author Pier Fumagalli mailto:[EMAIL PROTECTED] -# @version $Id: Makedefs.in,v 1.12 2001/10/10 15:30:24 jfclere Exp $ +# @author Pier Fumagalli mailto:[EMAIL PROTECTED] +# @version $Id: Makedefs.in,v 1.13 2001/11/01 22:20:51 pier Exp $ .SUFFIXES: .c .o .lo 1.24 +2 -2 jakarta-tomcat-connectors/webapp/Makefile.in Index: Makefile.in === RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/Makefile.in,v retrieving revision 1.23 retrieving revision 1.24 diff -u -r1.23 -r1.24 --- Makefile.in 2001/10/19 20:04:58 1.23 +++ Makefile.in 2001/11/01 22:20:51 1.24 @@ -55,8 +55,8 @@ # # # = # -# @author Pier Fumagalli mailto:[EMAIL PROTECTED] -# @version $Id: Makefile.in,v 1.23 2001/10/19 20:04:58 pier Exp $ +# @author Pier Fumagalli mailto:[EMAIL PROTECTED] +# @version $Id: Makefile.in,v 1.24 2001/11/01 22:20:51 pier Exp $ include @TGTDIR@/Makedefs 1.5 +2 -2 jakarta-tomcat-connectors/webapp/Makefile.win Index: Makefile.win === RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/Makefile.win,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- Makefile.win 2001/08/11 03:53:30 1.4 +++ Makefile.win 2001/11/01 22:20:51 1.5 @@ -55,8 +55,8 @@ # # # = # -# @author Pier Fumagalli mailto:[EMAIL PROTECTED] -# @version $Id: Makefile.win,v 1.4 2001/08/11 03:53:30 pier Exp $ +# @author Pier Fumagalli mailto:[EMAIL PROTECTED] +# @version $Id: Makefile.win,v 1.5 2001/11/01 22:20:51 pier Exp $ # Analyze and normalyze the DEBUG compilation flag !IF $(DEBUG) == true 1.15 +1 -1 jakarta-tomcat-connectors/webapp/README.txt Index: README.txt === RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/README.txt,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- README.txt2001/08/16 15:41:18 1.14 +++ README.txt2001/11/01 22:20:51 1.15 @@ -105,4 +105,4 @@ Have fun... -Pier [EMAIL PROTECTED] +Pier [EMAIL PROTECTED] 1.46 +2 -2 jakarta-tomcat-connectors/webapp/configure.in Index: configure.in === RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/configure.in,v retrieving revision 1.45 retrieving revision 1.46 diff -u -r1.45 -r1.46 --- configure.in 2001/10/19 20:03:21 1.45 +++ configure.in 2001/11/01 22:20:51 1.46 @@ -56,9 +56,9 @@ dnl = dnl
RE: How does Tomcat handle discarded-request
Hi, Craig, Here is my skeleton jsp, jsp:useBean id=workBean class=... ... /jsp:useBean % Object param1=getParameter(Param1) ; ... Object paramn = getParameter(Paramn) ; // let us say that doWork takes a few minutes to finish // and I just can not wait at the browser side and I issues another request to TOMCAT Object result = workBean.doWork(param1, ..., paramn) ; // Is IOException thrown out here? out.println(result) ; % As per your explaination, is IOException thrown out on out.println()???, since it is JSP, so my workBean has no way to talk to something at the browser side to get data. thanks, David -- From: Craig R. McClanahan[SMTP:[EMAIL PROTECTED]] Reply To: Tomcat Developers List Sent: Thursday, November 01, 2001 5:08 PM To: Tomcat Developers List Cc: Hu, Xuebing Subject: RE: How does Tomcat handle discarded-request On Thu, 1 Nov 2001, Hu, Xuebing wrote: Date: Thu, 1 Nov 2001 17:03:29 -0500 From: Hu, Xuebing [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: RE: How does Tomcat handle discarded-request Thanks, Bill for the response. Any detail? I am currently using TOMCAT 3.2.3. In general, you cannot count on the server even knowing that the request was cancelled. The following scenarios are all possible: * The entire request was read before the cancel happened, so no notification is possible until the response is written back out and receives an IOException. (This is by far the most common case.) * Tomcat was able to read the headers, but does not need to read the data. In this case, it is the application (not Tomcat) that would receive an IOException when trying to process the input stream. Therefore, it is up to your application to respond appropriately. * Tomcat was unable to read the headers (because the cancel happened very quickly). It will typically log an exception and throw the request away. David Craig -- 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 4330] - ClassCastException with DocumentBuilderFactoryImpl
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=4330. 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=4330 ClassCastException with DocumentBuilderFactoryImpl [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4577] New: - NullPointerException in HttpConnectionHandler
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=4577. 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=4577 NullPointerException in HttpConnectionHandler Summary: NullPointerException in HttpConnectionHandler Product: Tomcat 3 Version: 3.2.3 Final Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Connectors AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] NPE at line HttpConnectionHandler:144 when using HttpConnectionHandler as handler for SimpleTcpConnector Connector. Why bother checking socket for null AFTER invoking an instance method on it? -- 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/valves CertificatesValve.java
jfclere 01/11/01 15:05:21
Modified:catalina/src/share/org/apache/catalina/valves
CertificatesValve.java
Log:
Add javax.servlet.request.ssl_session to TC standalone.
Revision ChangesPath
1.8 +19 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/CertificatesValve.java
Index: CertificatesValve.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/CertificatesValve.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- CertificatesValve.java2001/07/22 20:25:15 1.7
+++ CertificatesValve.java2001/11/01 23:05:21 1.8
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/CertificatesValve.java,v
1.7 2001/07/22 20:25:15 pier Exp $
- * $Revision: 1.7 $
- * $Date: 2001/07/22 20:25:15 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/CertificatesValve.java,v
1.8 2001/11/01 23:05:21 jfclere Exp $
+ * $Revision: 1.8 $
+ * $Date: 2001/11/01 23:05:21 $
*
*
*
@@ -112,7 +112,7 @@
* amount of code that has to check for the existence of JSSE classes./p
*
* @author Craig R. McClanahan
- * @version $Revision: 1.7 $ $Date: 2001/07/22 20:25:15 $
+ * @version $Revision: 1.8 $ $Date: 2001/11/01 23:05:21 $
*/
public final class CertificatesValve
@@ -387,6 +387,21 @@
//if (debug = 2)
//log( expose: Has cipher suite + cipherSuite +
// and key size + keySize);
+
+// Expose ssl_session (getId)
+byte [] ssl_session = session.getId();
+if (ssl_session!=null) {
+StringBuffer buf=new StringBuffer();
+for(int x=0; xssl_session.length; x++) {
+String digit=Integer.toHexString((int)ssl_session[x]);
+if (digit.length()2) buf.append('0');
+if (digit.length()2) digit=digit.substring(digit.length()-2);
+buf.append(digit);
+}
+request.getRequest().setAttribute(
+javax.servlet.request.ssl_session,
+buf.toString());
+}
// If we have cached certificates, return them
Object cached = session.getValue(Globals.CERTIFICATES_ATTR);
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: How does Tomcat handle discarded-request
Generally with 3.2.x it will throw there, but it may throw later due to
buffering. And since the browser has closed the connection, no you can't
send/receive anything further. Of course, there is nothing to prevent you
inclosing your code in a try {} finally {} block if workBean needs to do
cleanup.
- Original Message -
From: Hu, Xuebing [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Thursday, November 01, 2001 2:39 PM
Subject: RE: How does Tomcat handle discarded-request
Hi, Craig,
Here is my skeleton jsp,
jsp:useBean id=workBean class=... ...
/jsp:useBean
%
Object param1=getParameter(Param1) ;
...
Object paramn = getParameter(Paramn) ;
// let us say that doWork takes a few minutes to finish
// and I just can not wait at the browser side and I issues
another request to TOMCAT
Object result = workBean.doWork(param1, ..., paramn) ;
// Is IOException thrown out here?
out.println(result) ;
%
As per your explaination, is IOException thrown out on out.println()???,
since it is JSP, so my workBean has no way to talk to something at the
browser side to get data.
thanks,
David
--
From: Craig R. McClanahan[SMTP:[EMAIL PROTECTED]]
Reply To: Tomcat Developers List
Sent: Thursday, November 01, 2001 5:08 PM
To: Tomcat Developers List
Cc: Hu, Xuebing
Subject: RE: How does Tomcat handle discarded-request
On Thu, 1 Nov 2001, Hu, Xuebing wrote:
Date: Thu, 1 Nov 2001 17:03:29 -0500
From: Hu, Xuebing [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Subject: RE: How does Tomcat handle discarded-request
Thanks, Bill for the response. Any detail? I am currently using TOMCAT
3.2.3.
In general, you cannot count on the server even knowing that the request
was cancelled. The following scenarios are all possible:
* The entire request was read before the cancel happened, so no
notification is possible until the response is written back out
and receives an IOException. (This is by far the most common case.)
* Tomcat was able to read the headers, but does not need to read
the data. In this case, it is the application (not Tomcat) that
would receive an IOException when trying to process the input
stream. Therefore, it is up to your application to respond
appropriately.
* Tomcat was unable to read the headers (because the cancel happened
very quickly). It will typically log an exception and throw the
request away.
David
Craig
--
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]
**
This message is intended only for the use of the person(s) listed above
as the intended recipient(s), and may contain information that is
PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient,
you may not read, copy, or distribute this message or any attachment.
If you received this communication in error, please notify us immediately
by e-mail and then delete all copies of this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent
through the Internet is not secure. Do not send confidential or sensitive
information, such as social security numbers, account numbers, personal
identification numbers and passwords, to us via ordinary (unencrypted)
e-mail.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Welcome to the Tomcat 4.0 F.A.Q. on-line forum.
Quoting Pier Fumagalli [EMAIL PROTECTED]: Bill Barker at [EMAIL PROTECTED] wrote: I know that Jon has already pointed out that Sun is going to sue the 3.x branch out of Jakarta in five months, I don't think Jon said that, and as a Sun employee I can guarantee that Tomcat 3.x remains one of our strongholds AND the official servlet 2.2 container / jsp 1.1 engine used in the J2EE reference implementation. Probably most of the people from Sun you see on the mailing list are more connected with 4.0 as we're developing for the new release(s) of the spec, but 3.x is still one of our major focuses in terms of integration. Pier Craig (and other Sun people out there), would you guys be able to grab one of your company lawyers for 5 minutes to ask about the TC 3.x license expiry issue (that was the issue what Jon pointed out, I believe). It would be nice to know the official version of the license interpretation. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
And in case I don't see you, good afternoon, good evening andgood bye...
One year, three months and five days. It definitely didn't last long, or not as long as I would have expected, or as long as I would have liked it. What? Oh, I believe you noticed it already: effective today I'm no longer a Sun Microsystems employee... Well folks, it has been a long and wild ride (quoting a friend of mine who was in more or less the same position as I am right now some months ago), but as all rides, you pay your toll, you get some fun, and then, the ride is over... I believe you all heard about that Sun Microsystems was having its first roll of layoffs ever, and from what I was told, my situation (working in London, employed in Dublin, and with my team in Santa Clara) was in a very dangerous position. And when managers had to come off with a name for my team, well, my name was an easy pick :) No hard feelings though. I still think that Sun is a great place to work at, most of my heroes are all still there (sigh!) from James Gosling to Joshua Bloch (some others have gone) and a bunch of friends are still working there. It's a good company, overall, maybe sometimes it takes them some time to understand how open source works (not that I know much about it), but most of the times, at the end, they get it right... And I mean, who never made a mistake or two in their lives? I just think that the projects I was dealing with (native and web-server integration with Tomcat) were not enough to justify my displaced situation (it's somehow weird when you have to attend to a phone meeting at 11 PM! :) but I was prepared, I smelled it from quite some time, and I got my confirmation today. What does it mean for me? Well, somehow, it means a lot. It means that all you folks who were waiting for my return in California will have to wait for quite some time now, more than the planned six months, I don't have the strength at the moment to chase another visa, to start it all over again. I'll settle down here in London (it's a nice town when it doesn't rain), I have a good number of friends, clubs are nice, and my cats are getting used to the upcoming cold winter. But no more of sunny California for quite a long time, no more rides on my brand new Suzuki GSX-1300R on Highway 1, no more skiing in Tahoe, no more cheap ADSL and large bandwidth access. Oh, well, I'll survive. What does that mean in terms of my involvement with the Apache Software Foundation, the Jakarta Project, Tomcat, and so on? Nothing. Nothing changes, I've been around here for a reasonable amount of years now, and I am planning to stick around for a lot more to come. The only thing changing is that I got back my independence, I got back my status of open source developer for real, and if someone asks me that one of the projects I'm working on doesn't run on my favorite platform (Windows), I can just say, go ahead, fix it yourself, I don't care. How I see it? I traded my independence as an open source developer with my dream of living in a place I love, I traded my salary for a lump of more freedom. The only thing I somehow regret, is that this time I didn't have the power of choice, but I accept it, and frankly, I'm not sad about what happened... So, from now on, Pier is me. It means that what I think, what I say or what I do is because of some strange plot at Sun. My wickedness is only mine, and it's going to be like that for quite some time (get ready :)... And in case I don't see you, good afternoon, good evening and good bye... Pier (and his two independent cats: Sharon and Becky) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: And in case I don't see you, good afternoon, good evening and good bye...
Quoting Pier Fumagalli [EMAIL PROTECTED]: And in case I don't see you, good afternoon, good evening and good bye... Pier, my apologies for the Sun related e-mail on the list today. If I only knew, I would never have sent it. :-(( I wish you all the best in your future undertakings and I really hope you'll stick around Jakarta because I'm sure your work is appreciated by all. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: And in case I don't see you, good afternoon, good evening andgood bye...
Bojan Smojver at [EMAIL PROTECTED] wrote: I wish you all the best in your future undertakings and I really hope you'll stick around Jakarta because I'm sure your work is appreciated by all. Not by _all_ AFAICS :) Read, been in a lot of flamewars myself... :) Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/server Http10Interceptor.java
billbarker01/11/01 19:14:03
Modified:src/share/org/apache/tomcat/modules/server
Http10Interceptor.java
Log:
Fix recycling the remoteAddr and remoteHost.
The remoteAddr and remoteHost would get reset to the default localhost values after
recycling.
Fix for bug 4564
Reported by: Alessandro Polverini [EMAIL PROTECTED]
Revision ChangesPath
1.27 +3 -0
jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Http10Interceptor.java
Index: Http10Interceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Http10Interceptor.java,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- Http10Interceptor.java2001/10/03 22:13:45 1.26
+++ Http10Interceptor.java2001/11/02 03:14:03 1.27
@@ -224,6 +224,9 @@
public void recycle() {
super.recycle();
if( http!=null) http.recycle();
+// recycle these to remove the defaults
+remoteAddrMB.recycle();
+remoteHostMB.recycle();
}
public void setSocket(Socket socket) throws IOException {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4564] - request.getRemoteAddr() and AccesLog not working
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4564. 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=4564 request.getRemoteAddr() and AccesLog not working [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2001-11-01 19:25 --- This is now fixed in the CVS HEAD, and should appear shortly in the nightly build. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Japanese in Portlet
Hi I like to present Japanese in portlet . Currently it does not work when I put Japanese characters in ECS objects in getContent function. Please help. Thanks Dang Tuan mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_channel.h
costin 01/11/01 20:22:59 Added: jk/native/common jk_channel.h Log: A first step in abstracting the TCP communication and adding support for faster mechanisms. Revision ChangesPath 1.1 jakarta-tomcat-connectors/jk/native/common/jk_channel.h Index: jk_channel.h === /* = * * * * The Apache Software License, Version 1.1 * * * * Copyright (c) 1999-2001 The Apache Software Foundation. * * All rights reserved.* * * * = * * * * Redistribution and use in source and binary forms, with or without modi- * * fication, are permitted provided that the following conditions are met: * * * * 1. Redistributions of source code must retain the above copyright notice * *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, Jk, 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 Software Foundation.* * * * 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 indivi- * * duals on behalf of the Apache Software Foundation. For more information * * on the Apache Software Foundation, please see http://www.apache.org/. * * * * = */ #include jk_global.h #include jk_logger.h #include jk_pool.h /** * Abstraction
Tomcat to support other keystore types?
Hi, Tomcat currently only supports Sun's default keystore: JKS. Are there any plans to change tomcat to take a keystore type as a parameter, and then run using that keystore for it's SSL? We're currently looking at the code to try and implement our keystore (which implements the java.security.keystore interface), however there are many complications. Any help/advice would be very much appreciated. Thanks, Libby Meren Computer Associates Software Engineer, eTrust PKI E-Mail: [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat to support other keystore types?
This is probably outside of the development plans for 3.2.x. I'm +1 for supporting this in 3.3.1 I'm going to let the 4.0 people answer for themselves (e.g. I'm +0). - Original Message - From: Meren, Libby [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 01, 2001 9:30 PM Subject: Tomcat to support other keystore types? Hi, Tomcat currently only supports Sun's default keystore: JKS. Are there any plans to change tomcat to take a keystore type as a parameter, and then run using that keystore for it's SSL? We're currently looking at the code to try and implement our keystore (which implements the java.security.keystore interface), however there are many complications. Any help/advice would be very much appreciated. Thanks, Libby Meren Computer Associates Software Engineer, eTrust PKI E-Mail: [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] ** This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: And in case I don't see you, good afternoon, good evening andgood bye...
You are not seeing I think ;)) Maybe you are more appreciated than you think by the people you had flamewars with ;) Enjoy your independence and if you want something else then rain in London, come and enjoy the rain here in Holland.. Mvgr, Martin -Original Message- From: Pier Fumagalli [mailto:[EMAIL PROTECTED]] Sent: Friday, November 02, 2001 3:32 AM To: Tomcat Developers List Subject: Re: And in case I don't see you, good afternoon, good evening andgood bye... Bojan Smojver at [EMAIL PROTECTED] wrote: I wish you all the best in your future undertakings and I really hope you'll stick around Jakarta because I'm sure your work is appreciated by all. Not by _all_ AFAICS :) Read, been in a lot of flamewars myself... :) Pier -- 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]
