Re: [Q] WebappClassloader violates J2SE policy syntax?
Glenn Nielsen wrote:
Jeanfrancois Arcand wrote:
Hi,
I've noticed a characteristic in the tomcat
loader.WebappClassloader and was wondering whether someone have any
recollection or insight as to why we did it that way.
Classes loaded with this classloader get a jar: tacked as prefix in
their codesource.
The javadoc has this to say:
IMPLEMENTATION NOTE - The class loader generates source URLs which
include the full JAR URL when a class is loaded from a JAR file,
which allows setting security permission at the class level, even
when a class is contained inside a JAR.
Which is indeed true and an interesting feature.
However, it violates the j2se policy syntax because the users
expectation of /- no longer works
In other words, with some structure like:
applications/web-modules/web_1
/WEB-INF/lib/foo.jar
...
/web_2
...
If the user wishes to grant permission X to all web module code, they
expect the following to work as documented in the policy syntax:
grant codeBase file:.../applications/web-modules/- {
permission X;
};
Turns out it doesn't, because WebappClassloader will make the
codesource something like jar:file:./foo.jar!/MyClass.class,
which will not match the grant.
I've see the norte inside the RELEASE-NOTES file, but would like to
know why exactly.
Merci,
-- Jeanfrancois
You can do the grant to the entire jar file like this:
jar:file:/foo.jar!/-
The jar:file syntax is no longer required in Tomcat 4.1, the code for
Tomcat 5
must have been forked before this change, or the documentation didn't
get updated.
I did a quick search of the release notes and found that it was changed
in Tomcat
4.1.1 to fix bugzilla bug 8611. The change was needed to fix a bug with
sealed
jar files.
The patch was ported. The CodeSource object, as well as the package
definition, are made from the file: URL.
definePackage(packageName, entry.manifest,
entry.codeBase);
...
CodeSource codeSource =
new CodeSource(entry.codeBase, entry.certificates);
...
entry.codeBase = getURL(jarRealFiles[i]);
The implementation note should be removed, as it is no loger true
starting in 4.1.x.
Remy
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors KEYS
mturk 2002/11/27 00:20:30 Modified:.KEYS Log: no message Revision ChangesPath 1.9 +32 -32jakarta-tomcat-connectors/KEYS Index: KEYS === RCS file: /home/cvs/jakarta-tomcat-connectors/KEYS,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- KEYS 30 Sep 2002 12:38:39 - 1.8 +++ KEYS 27 Nov 2002 08:20:30 - 1.9 @@ -165,36 +165,36 @@ =1iBa -END PGP PUBLIC KEY BLOCK- -Type Bits/KeyIDDate User ID -pub 1024D/43BBFD13 2002-09-30 Mladen Turk [EMAIL PROTECTED] +Type Bits/KeyID Date User ID +pub 1024D/881EBC94 2002/11/27 Mladen Turk [EMAIL PROTECTED] --BEGIN PGP PUBLIC KEY BLOCK- -Version: GnuPG v1.0.6 (MingW32) -Comment: For info see http://www.gnupg.org - -mQGiBD2YNHURBACDBSCbUgp0h+B6rvr3egm9z2BTjG5WLtDUroUvcootGoi0jzJr -YVM9ej/e6vhUxGDbzihIK03uVY4VerhgSPu2dzt0+ohCaLFDUlehHkYb/QIpwHce -ynqDLatKL556JRA4+XsfoJWb0onped7CqdUpkejlqRtcXJ3sCADnHWCBTwCg4ASI -neHU8wPj/NwwkFv1iAFlSJMD/i4GdYyuL9cWjHPPt61zSOYQEcMbrlUmcKwMIqt1 -zPAoKlxCQwsn4SeCt6oUJBhnlRR7wSfFi5Ym2fcxpUHU8Wp67C5EB7myMPlbFbTn -Och7AvqtsYuIEz3pFqBB5j12nkQadH6Us4/eXUTJtuBrfi1L2YkUi7RXJKgeN1Yu -9ilwA/9aOuKvrMjjxdP/2Ij4n2FlgvTUeClbGwBGa96N9DqEjaneIXKcY3jez3Pl -p+P2FinxvKckDBRpO0P7q/6w+93/hor9XY3odpR3o7yz83TE8SoLUOwxvARQYyma -99ki+uEv8+HuC6inz2zon25JRFxWsag8wcySk2hXtI5r/eNSqrQjTWxhZGVuIFR1 -cmsgPG10dXJrQG1hcHBpbmdzb2Z0LmNvbT6IVwQTEQIAFwUCPZg0dQULBwoDBAMV -AwIDFgIBAheAAAoJEJERKMNDu/0TIs4AoMbzFQIMNu6oeiVBwLgATlAxqM1dAJ9Z -dolS0ZIA3t/AyN2DJBK/+o0U4LkCDQQ9mDSBEAgA3O+TzrJ8QJZ9AJAQQOjcdR3M -bcrmXWu/epWcq75lv3lkn7KW9QuDaVcDXpYwi7+okT4+VZId2xDpeOROqF5tokHB -fuMkw8KdLHoS5CMng9XoBVWmkMJiO+KB9nApgjc1f68M752gpKajOY1ziHS8OyxH -Gg1/xWw/SK5UuzuzNQpu4prYYIq6j5m1CmiDcSsoq4IyTj4P+pKSjGQ3KEXO5HPX -w//zd3/o8Q00v1ItjvA24azWoUBZPZCBlqwUR/aSAeJV26jrqGpZMEZg64OTNXi/ -yUO2DfYRcgh0q9BahG9ZNi+0YekMkQAIX33qg2ImpjR77o2HV96t2iGzxvP3HwAD -BQf+LDflFGj4+juKJOcPr+6RCV6fsXs797drZSwP77Zm4gQQZm14kU9OLU6PXtNt -P6yn8VZbffHamfMb6n32x7x40hcjfbseiQ42+r969D4F5hoBlrF2VPBpQgvdgLX2 -V887KyPExl9BVg/nTyEvuvJOokNhZDMj0uATOmkAGrnBfloeBPtqgVA4zdKT15wT -+pAkZFXP6Tr8CrPqtLwnaAtWDdcTgvGgLo4Tcoeca5J7kUJW63E6zrqIhbSf6y8A -/+7+f/JtdoboYEjT8my4UhCLykWMklNXIV+hnIbg3oIkB2v6T5TWf8UrMuMeKgKQ -noM//QpcnyamTJ2zrX32aBfYfYhGBBgRAgAGBQI9mDSBAAoJEJERKMNDu/0TBzcA -n223BnGVjqZ0dgybl5VOXHfBDNDJAJ9lBRAdGytkoPX9LpN+oZvO/tsnYw== -=YuIT --END PGP PUBLIC KEY BLOCK- +-BEGIN PGP PUBLIC KEY BLOCK- +Version: GnuPG v1.0.6 (MingW32) + +mQGiBD3kfmsRBAD02S+HNaMX+TNdMIFs1PEEwSBOxoFd8Mh51nt8eS5Kp9+v747Q +lQIUPgmhOWWQa33HGapTe3b9CQuc9mGf1eR0NyRK5S2hjoYkEb7oPVNL5PMDcJ5M +uwBSU7pG1LossNUuhsTgEQdFR4gci+ElPilQtUriv1O579YkNNVwRDUBtwCg9fcq +DNvStKj67bvzGIRrr99w2MMEAOxCHKBd69uFzPkL0+7lFoJY/IyW6xJaCXWQGE8g +P9ZgWtfYDLliuUhsmGP10JxuAYEOk3cMGy84a7ez589GWqGXXutpJmX3lY/cr8G+ +fyIT0MWxCDkKpyxz5k3XaCYigKbxrrJ+HhP7R9cZsC9kj18q9mWdku24sLEdhA+g +ewNcBADPghjTG6HOFCJb3xS6r3dbI3JVREyVPOSCWJY+A6RrRHfY4Ohw0zTt9zLi +OpuBdrpNE64bh3ftQhXg33A61fdJ19WS6YJ2WdwKlQtUiA60m8/D9qAwebuJ+1yM +LaUw3UUA5c38BiOgGND3bQp09fOR/JL5rYMopnZngByokc1AwbQ9TWxhZGVuIFR1 +cmsgKE1sYWRlbiBUdXJrIFNpZ25pbmcgS2V5KSA8bXR1cmtAbWFwcGluZ3NvZnQu +Y29tPohdBBMRAgAdBQI95H5rBQkSz/eABQsHCgMEAxUDAgMWAgECF4AACgkQ0gmc +8IgevJSonACfRTku5Y3bBbpG7stbMv2TiojjKxAAoJq170XCq4kvBiJHhfqcKL0v +v9c9uQINBD3kfngQCADen9IZs4qYqkBZ0Hq3Qk0sMClrsSBnh6bKYXUlmjb3YMo8 +i9m7CiwYIowElHvBRBw/0KFWIvwGAk2hcRuSN6nmR3Lnt8iw9Q68zJBAN8SeD0FP +pQ2Riv9tKeVfQyyOt4hzANLGV2JTk47eOrIyAskRfgR2RdMv5sn/gv8LjDBTE7rE +X4UW1xrtHI9mLQ7kbPLErLBA03S3HZX/dZQUF7+rd1oZYIfo54SgCu3YWwCA1zqb +fQXjcKjgRBf62AlvDAjHdVDGd9uGU8w64zs8yyQSFM0mJ91Gn3YUE2qEF7yV7NKT +fgiSTXlCWCp/IRQBwSj9qhbt08zbE9/LLfLD4ZMvAAMHCADCPYBsfyRdYdoeruFw +4Zf5Vh14jzHH2PJmKQgEmgIEMIAaU6vU/skHMFz9e7NXCBS7YXkjG6trLG/BGb7R +kI/lZpIQ9za/NeHQuxaOHCJuP9vcNpjeSWToF40C39Bdnu6I6Lf68DJQo5zxqfnD +XBRXQEB62S9irNEn/BP5pXjPrqWBJEkUVo/JnEDL+ljUfYXR1oqul35pvVa2XOrV +0VsWkkEQn/ZmYhmnt+HDWmne+CZi8N9n6uoO9YZSMneBIBbN7j8SFlzmrXLZlwRU +sPE74k9kxWWSvvIX+JZVs03oRARrNbVvoArWSlWPhGmqgva3N04m+sWYECfFWU68 +YB2OiEwEGBECAAwFAj3kfngFCRLP94AACgkQ0gmc8IgevJT9PACfZbZeXuiTvTWc +ECLcb/hHsrA+NEMAoOvwi2DsvrSry/4HC6WaNx7xlIes +=PiR7 +-END PGP PUBLIC KEY BLOCK- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14877] - Coyote HTTP not using the port numbers I specify in server.xml
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14877. 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=14877 Coyote HTTP not using the port numbers I specify in server.xml --- Additional Comments From [EMAIL PROTECTED] 2002-11-27 08:36 --- You will find the ports settings in 'conf/jk2.properties'. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14885] New: - Tomcat hangs after bad https request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14885. 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=14885 Tomcat hangs after bad https request Summary: Tomcat hangs after bad https request Product: Tomcat 4 Version: 4.0.3 Final Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If you make a request SSL request to Tomcat on the none SSL port Tomcat hangs up and will not process any further requests. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14888] New: - Incorrect jsp:plugin tag translation
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=14888. 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=14888 Incorrect jsp:plugin tag translation Summary: Incorrect jsp:plugin tag translation Product: Tomcat 4 Version: Unknown Platform: PC URL: http://localhost OS/Version: Windows 9x Status: NEW Severity: Normal Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In Tomcat 4.1.12 I wrote: % String str=abc; % jsp:plugin type=applet code=Snake width=500 height=400 jsp:params jsp:param name=gracz value=%= str % / /jsp:params jsp:fallback Install JRE... /jsp:fallback /jsp:plugin The line is translated: out.println(OBJECT classid=\clsid:8AD9C840-044E-11D1-B3E9-00805F499D93\ width=\500\ + height=\400\ + codebase=\http://java.sun.com/products/plugin/1.2.2/jinstall-1_2_2- win.cab#Version=1,2,2,0\); out.println(PARAM name=\java_code\ value=\Snake\); out.println(PARAM name=\type\ value=\application/x-java-applet;\); out.println(PARAM name=\gracz\ value= str ); ... This gives a name of the String parameter instead of its value. In Tomcat 4.0.5 it gives: out.println (OBJECT classid=\clsid:8AD9C840-044E-11D1-B3E9-00805F499D93 \ width=\500\ height=\400\ codebase=\http://java.sun.com/products/plugin/1.2.2/jinstall-1_2_2- win.cab#Version=1,2,2,0\); out.println (PARAM name=\java_code\ value=\Snake\); out.println (PARAM name=\type\ value=\application/x-java- applet;\); String _jspxString = null; _jspxString = str ; out.println (PARAM name=\gracz\ value=\+ _jspxString + \); ... That gives the value of the String variable. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [ANNOUNCEMENT] Apache Tomcat 4.1.16 Alpha released
In the RELEASE-NOTES I saw that changes are ordered chronologically. [4.1.1] bla [4.1.2] bla [4.1.3] bla [4.1.4] bla Isn't more usefull to have the last changes in the top of each list ??? [4.1.16] bla [4.1.15] bla [4.1.14] bla [4.1.13] bla It's just an opinion ( mine ;-) ). Arnaud H. -Message d'origine- De : Remy Maucherat [mailto:[EMAIL PROTECTED]] Envoye : mardi 26 novembre 2002 23:32 A : Tomcat Developers List; Tomcat Users List Objet : [ANNOUNCEMENT] Apache Tomcat 4.1.16 Alpha released Apache Tomcat 4.1.16 Alpha has just been released. Please help improve upcoming Tomcat releases by testing it. Note: This release is intended only for testing purposes, not for production use. Downloads: http://www.apache.org/dist/jakarta/jakarta-tomcat-4.0/release/ v4.1.16-alpha/ Significant changes over 4.1.15 Alpha include minor performance improvements and bugfixes. The full list of changes is available in the release notes. http://www.apache.org/dist/jakarta/jakarta-tomcat-4.0/release/v4.1.16-alpha/ RELEASE-NOTES Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: custom error page rewrite uri
Hi, I can confirm this is not working as intended on Apache 4.1.x But I can't be of any more help other than to suggest you file a bug? Jim -Original Message- From: Alexius Luke [mailto:[EMAIL PROTECTED]] Sent: 25 November 2002 05:29 To: [EMAIL PROTECTED] Subject: custom error page rewrite uri Hi all, I use Apache Tomcat 4.1.12 on Linux.For my aplications need I have configured a custom error jsp age for the error-code 404.So when any irrelevant url is requested this jsp page is invoked. error-page error-code404/error-code location/error_request.jsp/location /error-page http://localhost:8080/irrelevantpage I need to get the requested irrelevant uri in the error_request.jsp page and process accordingly.But in my jsp when I use the request.getRequestURI() it gives me the current pages uri (i.e) /error_request.jsp instead of /irrelevantpage. could anybody help me Is there any place in the configuration files to specify this or is it this wat that the container works. Thanx in advance, p.s. In tomcat3.2 it works as I expect.But in tomcat4.1.12 it isnt. -Alexius Luke -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp_common.cjk_connect.c
Costin,
Why were the log levels changed from LOG_ERROR to LOG_INFO, a connection failure
to tomct is a real fatal error when handling a request. Shouldn't it be at the
JK_LOG_ERROR level?
Regards,
Glenn
[EMAIL PROTECTED] wrote:
costin 2002/10/30 14:12:20
Modified:jk/native/common jk_ajp_common.c jk_connect.c
Log:
More trimming for error messages.
Now only one line ( and hopefully more informative ) is displayed if
we can't send the request to tomcat.
Revision ChangesPath
1.32 +11 -5 jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c
Index: jk_ajp_common.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- jk_ajp_common.c 30 Oct 2002 21:17:34 - 1.31
+++ jk_ajp_common.c 30 Oct 2002 22:12:20 - 1.32
@@ -623,7 +623,9 @@
}
}
-jk_log(l, JK_LOG_ERROR, ERROR connecting to tomcat. Tomcat is probably not started. Failed errno = %d\n, errno);
+jk_log(l, JK_LOG_INFO,
+ Error connecting to tomcat. Tomcat is probably not started or is listenning on the wrong port. Failed errno = %d\n,
+ errno);
return JK_FALSE;
}
@@ -869,7 +871,7 @@
return JK_FALSE;
}
} else {
-jk_log(l, JK_LOG_ERROR, Error connecting to the Tomcat process.\n);
+jk_log(l, JK_LOG_INFO, Error connecting to the Tomcat process.\n);
return JK_FALSE;
}
}
@@ -1175,15 +1177,19 @@
return JK_FALSE;
}
-jk_log(l, JK_LOG_ERROR, ERRORO: Receiving from tomcat failed, recoverable operation. err=%d\n, i);
+jk_log(l, JK_LOG_ERROR, ERROR: Receiving from tomcat failed, recoverable operation. err=%d\n, i);
}
else
-jk_log(l, JK_LOG_ERROR, ERROR: sending request to tomcat failed in send loop. err=%d\n, i);
+jk_log(l, JK_LOG_INFO, sending request to tomcat failed in send loop. err=%d\n, i);
jk_close_socket(p-sd);
p-sd = -1;
ajp_reuse_connection(p, l);
}
+
+/* Log the error only once per failed request. */
+jk_log(l, JK_LOG_ERROR, Error connecting to tomcat. Tomcat is probably not started or is listenning on the wrong port. Failed errno = %d\n, errno);
+
} else {
jk_log(l, JK_LOG_ERROR, In jk_endpoint_t::service, NULL parameters\n);
}
1.6 +2 -2 jakarta-tomcat-connectors/jk/native/common/jk_connect.c
Index: jk_connect.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_connect.c,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- jk_connect.c 4 Sep 2002 11:31:33 - 1.5
+++ jk_connect.c 30 Oct 2002 22:12:20 - 1.6
@@ -174,7 +174,7 @@
jk_log(l, JK_LOG_DEBUG, jk_open_socket, return, sd = %d\n, sock);
return sock;
}
-jk_log(l, JK_LOG_ERROR, jk_open_socket, connect() failed errno = %d\n, errno);
+jk_log(l, JK_LOG_INFO, jk_open_socket, connect() failed errno = %d\n, errno);
jk_close_socket(sock);
} else {
#ifdef WIN32
--
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]
[4.1.16] Benchmarks
Could someone (Peter ?) do some quick benchmarks (with the HTTP/1.1 connector preferably) comparing 4.1.12 to 4.1.16 ? I'd like to see if my OptimizeIt work is translating into something in the real world, and unfortunately, I only have access to one computer at the moment (so I can't do any reliable benchmarking). Thanks, Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [4.1.16] Benchmarks
Howdy, I'll see if I can get around do it. FWIW, I've been profiling our app on every tomcat version since 4.0.4 (all -LE-jdk14, all running on Solaris 8), and the tomcat classes certainly have gone down as far as CPU time and memory requirements. Unfortunately I didn't record their improvement in a meaningful way, but I'll keep that in mind for the future. I've been using OptimizeIt as well. So while this isn't a direct response to your request / confirmation of your work, it is anecdotal evidence... Yoav Shapira Millennium ChemInformatics -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 27, 2002 8:07 AM To: Tomcat Developers List Subject: [4.1.16] Benchmarks Could someone (Peter ?) do some quick benchmarks (with the HTTP/1.1 connector preferably) comparing 4.1.12 to 4.1.16 ? I'd like to see if my OptimizeIt work is translating into something in the real world, and unfortunately, I only have access to one computer at the moment (so I can't do any reliable benchmarking). Thanks, Remy -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14895] New: - ServletRequestListener not unregistered when reloading a Webapp Context
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=14895. 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=14895 ServletRequestListener not unregistered when reloading a Webapp Context Summary: ServletRequestListener not unregistered when reloading a Webapp Context Product: Tomcat 5 Version: 5.0.0 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Minor Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When reloading a webapp via the manager app a ServletRequestListener gets for every request to the reloaded webapp as many notifications as reloads have been performed before. In other words: the unregistration of formally registered listeners seems not to work properly. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
System.setProperty() virtualisable inside a webapp?
I'm in the position of needing to use a third-party class library within a web application. This library uses the System.getProperty/setProperty mechanisms to control its configuration. However, I need several instances of the web application, each with this library configured in a slightly different fashion. Is it possible (currently, or with classloader tweaks) to virtualise the set of properties available through the System object to each web application? Cheers, jan PS. I'd appreciate a CC: on this so it lands in the right mailbox. -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287088 Fax +44 (0)117 9287112 http://ioctl.org/jan/ Not as randy or clumsom as a blaster. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14896] New: - Pager Tag Library prb under Tomcat 4.1.12
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=14896. 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=14896 Pager Tag Library prb under Tomcat 4.1.12 Summary: Pager Tag Library prb under Tomcat 4.1.12 Product: Tomcat 4 Version: 4.1.12 Platform: All OS/Version: All Status: NEW Severity: Critical Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I'm deployng a web aplication under Tomcat 4.1.12. I've some problem using Pager Tag Library from jsptags.com. You can find it at http://jsptags.com/tags/navigation/pager/pager-taglib-1.1.html This problem occurs only with Tomact 4.1.12, but not with Tomcat 4.0.2. Thank Raffy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14790] - getServletContext().getResource(file) returns invalid JNDI URL
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=14790. 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=14790 getServletContext().getResource(file) returns invalid JNDI URL [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-11-27 15:23 --- From the javadocs: The path must begin with a / and is interpreted as relative to the current context root. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14898] New: - File Upload problem
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=14898. 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=14898 File Upload problem Summary: File Upload problem Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Blocker Priority: Other Component: Catalina:Modules AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi, I have a servlet that uses com.oreilly.servlet.multipart package to upload files. Files are uploaded (text and binary) but truncated : the first 126 characters disapears. My servlet works fine on my devlopment environment (IBM Visual Age for Java with WebSphere test environment). regards -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler TagLibraryInfoImpl.java
luehe 2002/11/27 08:00:15 Modified:jasper2/src/share/org/apache/jasper/compiler TagLibraryInfoImpl.java Log: small javadoc improvement Revision ChangesPath 1.26 +8 -3 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java Index: TagLibraryInfoImpl.java === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java,v retrieving revision 1.25 retrieving revision 1.26 diff -u -r1.25 -r1.26 --- TagLibraryInfoImpl.java 14 Nov 2002 22:22:38 - 1.25 +++ TagLibraryInfoImpl.java 27 Nov 2002 16:00:14 - 1.26 @@ -407,6 +407,11 @@ * Parses the tag file directives of the given TagFile and turns them into * a TagInfo. * + * @param elem The tag-file element in the TLD + * @param uri The location of the TLD, in case the tag file is specified + * relative to it + * @param jarFile The JAR file, in case the tag file is packaged in a JAR + * * @return TagInfo correspoding to tag file directives */ private TagFileInfo createTagFileInfo(TreeNode elem, String uri, -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp_common.c jk_connect.c
Glenn Nielsen wrote:
Costin,
Why were the log levels changed from LOG_ERROR to LOG_INFO, a connection
failure to tomct is a real fatal error when handling a request. Shouldn't
it be at the JK_LOG_ERROR level?
It'll be logged at ERROR level -
+jk_log(l, JK_LOG_ERROR, Error connecting to tomcat. Tomcat is
probably not started or is listenning on the wrong port. Failed errno =
%d\n, errno); +
( instead of the Can't find servlet handler :-)
I just limited the number of messages that are logged at ERROR level
for each failed connection, you should see a single error message.
If you want more verbosity - you'll get it as info.
Costin
Regards,
Glenn
[EMAIL PROTECTED] wrote:
costin 2002/10/30 14:12:20
Modified:jk/native/common jk_ajp_common.c jk_connect.c
Log:
More trimming for error messages.
Now only one line ( and hopefully more informative ) is displayed if
we can't send the request to tomcat.
Revision ChangesPath
1.32 +11 -5
jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c
Index: jk_ajp_common.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c,v
retrieving revision 1.31 retrieving revision 1.32
diff -u -r1.31 -r1.32
--- jk_ajp_common.c30 Oct 2002 21:17:34 - 1.31
+++ jk_ajp_common.c30 Oct 2002 22:12:20 - 1.32
@@ -623,7 +623,9 @@
}
}
-jk_log(l, JK_LOG_ERROR, ERROR connecting to tomcat. Tomcat is
probably not started. Failed errno = %d\n, errno);
+jk_log(l, JK_LOG_INFO,
+ Error connecting to tomcat. Tomcat is probably not started
or is listenning on the wrong port. Failed errno = %d\n,
+ errno);
return JK_FALSE;
}
@@ -869,7 +871,7 @@
return JK_FALSE;
}
} else {
-jk_log(l, JK_LOG_ERROR, Error connecting to the Tomcat
process.\n);
+jk_log(l, JK_LOG_INFO, Error connecting to the Tomcat
process.\n);
return JK_FALSE;
}
}
@@ -1175,15 +1177,19 @@
return JK_FALSE;
}
-jk_log(l, JK_LOG_ERROR, ERRORO: Receiving from tomcat
failed, recoverable operation. err=%d\n, i);
+jk_log(l, JK_LOG_ERROR, ERROR: Receiving from tomcat
failed, recoverable operation. err=%d\n, i);
}
else
-jk_log(l, JK_LOG_ERROR, ERROR: sending request to
tomcat failed in send loop. err=%d\n, i);
+jk_log(l, JK_LOG_INFO, sending request to tomcat
failed in send loop. err=%d\n, i);
jk_close_socket(p-sd);
p-sd = -1;
ajp_reuse_connection(p, l);
}
+
+/* Log the error only once per failed request. */
+jk_log(l, JK_LOG_ERROR, Error connecting to tomcat. Tomcat is
probably not started or is listenning on the wrong port. Failed errno =
%d\n, errno); +
} else {
jk_log(l, JK_LOG_ERROR, In jk_endpoint_t::service, NULL
parameters\n);
}
1.6 +2 -2
jakarta-tomcat-connectors/jk/native/common/jk_connect.c
Index: jk_connect.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_connect.c,v
retrieving revision 1.5 retrieving revision 1.6
diff -u -r1.5 -r1.6
--- jk_connect.c 4 Sep 2002 11:31:33 - 1.5
+++ jk_connect.c 30 Oct 2002 22:12:20 - 1.6
@@ -174,7 +174,7 @@
jk_log(l, JK_LOG_DEBUG, jk_open_socket, return, sd =
%d\n, sock); return sock;
}
-jk_log(l, JK_LOG_ERROR, jk_open_socket, connect() failed
errno = %d\n, errno);
+jk_log(l, JK_LOG_INFO, jk_open_socket, connect() failed errno
= %d\n, errno);
jk_close_socket(sock);
} else {
#ifdef WIN32
--
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 14898] - File Upload problem
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=14898. 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=14898 File Upload problem [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2002-11-27 16:31 --- Posting and putting data works. If you believe this is really broken, please provide an easy to use (and as simple as possible) test case to reprodudce this. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler JspDocumentParser.java ParserController.java
luehe 2002/11/27 08:42:26
Modified:jasper2/src/share/org/apache/jasper/compiler
JspDocumentParser.java ParserController.java
Log:
Applied patch provided by Ryan Lubke to fix encoding issue:
When processing a JSP document, pass the document's raw input stream
to the SAX parser, that is, do not apply the autodetected encoding to
it (the SAX parser will figure out the encoding itself).
Revision ChangesPath
1.30 +7 -7
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspDocumentParser.java
Index: JspDocumentParser.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspDocumentParser.java,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- JspDocumentParser.java11 Nov 2002 19:26:28 - 1.29
+++ JspDocumentParser.java27 Nov 2002 16:42:26 - 1.30
@@ -119,7 +119,7 @@
*/
public JspDocumentParser(ParserController pc,
String path,
- InputStreamReader reader,
+ InputStream inStream,
boolean isTagFile,
boolean directivesOnly) {
this.parserController = pc;
@@ -128,7 +128,7 @@
this.taglibs = this.pageInfo.getTagLibraries();
this.err = pc.getCompiler().getErrorDispatcher();
this.path = path;
- this.inputSource = new InputSource(reader);
+ this.inputSource = new InputSource(inStream);
this.isTagFile = isTagFile;
this.directivesOnly = directivesOnly;
this.isTop = true;
@@ -141,13 +141,13 @@
*/
public static Node.Nodes parse(ParserController pc,
String path,
-InputStreamReader reader,
+InputStream inStream,
Node parent,
boolean isTagFile,
boolean directivesOnly)
throws JasperException {
- JspDocumentParser handler = new JspDocumentParser(pc, path, reader,
+ JspDocumentParser handler = new JspDocumentParser(pc, path, inStream,
isTagFile,
directivesOnly);
Node.Nodes pageNodes = null;
1.27 +43 -29
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ParserController.java
Index: ParserController.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ParserController.java,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- ParserController.java 7 Nov 2002 22:19:13 - 1.26
+++ ParserController.java 27 Nov 2002 16:42:26 - 1.27
@@ -180,46 +180,60 @@
throws FileNotFoundException, JasperException, IOException {
Node.Nodes parsedPage = null;
-InputStreamReader reader = null;
String absFileName = resolveFileName(inFileName);
JarFile jarFile = (JarFile) ctxt.getTagFileJars().get(inFileName);
-try {
-// Figure out what type of JSP document and encoding type we are
- // dealing with
-String encoding = figureOutJspDocument(absFileName, jarFile);
+ // Figure out what type of JSP document and encoding type we are
+ // dealing with
+ String encoding = figureOutJspDocument(absFileName, jarFile);
- if (isTopFile) {
- pageInfo.setIsXml(isXml);
- isTopFile = false;
- } else {
- compiler.getPageInfo().addDependant(absFileName);
- }
+ if (isTopFile) {
+ pageInfo.setIsXml(isXml);
+ isTopFile = false;
+ } else {
+ compiler.getPageInfo().addDependant(absFileName);
+ }
-// dispatch to the proper parser
-reader = JspUtil.getReader(absFileName, encoding, jarFile, ctxt,
-err);
-if (isXml) {
-parsedPage = JspDocumentParser.parse(this, absFileName,
- reader, parent,
+ // Dispatch to the proper parser
+ if (isXml) {
+ InputStream inStream = null;
+ try {
+ inStream = JspUtil.getInputStream(absFileName, jarFile, ctxt,
+ err);
+ parsedPage = JspDocumentParser.parse(this, absFileName,
+ inStream, parent,
Re: [4.1.16] Benchmarks
yeah, I can do that on a simple set this weekend and on a large webapp next week :) peter Remy Maucherat wrote: Could someone (Peter ?) do some quick benchmarks (with the HTTP/1.1 connector preferably) comparing 4.1.12 to 4.1.16 ? I'd like to see if my OptimizeIt work is translating into something in the real world, and unfortunately, I only have access to one computer at the moment (so I can't do any reliable benchmarking). Thanks, Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_global.h
mturk 2002/11/27 09:12:05 Modified:jk/native2/include jk_global.h Log: Change the version number to the 2.0.3 and mark as not nonreleased. The exposed version will be mod_jk2/2.0.3-beta-1. Perhaps we should change the beta to dev? Revision ChangesPath 1.16 +4 -4 jakarta-tomcat-connectors/jk/native2/include/jk_global.h Index: jk_global.h === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_global.h,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- jk_global.h 18 Oct 2002 11:25:44 - 1.15 +++ jk_global.h 27 Nov 2002 17:12:05 - 1.16 @@ -86,14 +86,14 @@ /** START OF AREA TO MODIFY BEFORE RELEASING */ #define JK_VERMAJOR 2 #define JK_VERMINOR 0 -#define JK_VERFIX 2 -#define JK_VERSTRING2.0.2 +#define JK_VERFIX 3 +#define JK_VERSTRING2.0.3 /* Beta number */ #define JK_VERBETA 1 #define JK_BETASTRING 1 /* set JK_VERISRELEASE to 1 when release (do not forget to commit!) */ -#define JK_VERISRELEASE 1 +#define JK_VERISRELEASE 0 /** END OF AREA TO MODIFY BEFORE RELEASING */ #define PACKAGE mod_jk2/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2 CHANGES.txt
mturk 2002/11/27 09:12:40 Modified:jk/native2 CHANGES.txt Log: Open the 2.0.3 version. Revision ChangesPath 1.6 +3 -1 jakarta-tomcat-connectors/jk/native2/CHANGES.txt Index: CHANGES.txt === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/CHANGES.txt,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- CHANGES.txt 25 Nov 2002 15:29:38 - 1.5 +++ CHANGES.txt 27 Nov 2002 17:12:40 - 1.6 @@ -1,6 +1,8 @@ JAKARTA TOMCAT CONNECTORS 2 (JK2) CHANGELOG: -*-text-*- Last modified at [$Date$] +Changes with JK2 2.0.3: + Changes with JK2 2.0.2: * Fix the bug 14293. Thanks to Martin Kraemer for his help. [Jean-Frederic Clere] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [ANNOUNCEMENT] JK2-2.0.2 released
Mladen Turk wrote: Hi to all, JK2 2.0.2 has been released and is available at : http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/release/v 2.0.2/ For now binaries are available for WIN32 only: linux binaries and rpms to be released tomorrow ;) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_global.h
[EMAIL PROTECTED] wrote: mturk 2002/11/27 09:12:05 Modified:jk/native2/include jk_global.h Log: Change the version number to the 2.0.3 and mark as not nonreleased. The exposed version will be mod_jk2/2.0.3-beta-1. Perhaps we should change the beta to dev? +1 to switch jk/jk2 to -dev, it's the Apache HTTPD numbering schema -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12628] - Jasper puts a lock on .jsp pages that it has compiled
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=12628. 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=12628 Jasper puts a lock on .jsp pages that it has compiled [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-11-27 18:09 --- *** This bug has been marked as a duplicate of 10127 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10127] - tomcat 4.0.4 locks jsp files
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10127. 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=10127 tomcat 4.0.4 locks jsp files [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-11-27 18:09 --- *** Bug 12628 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeansmbeans-descriptors.xml
Hi Bill, my friend Xerces doesn't like your latest change: SEVERE: Parse Error at line 325 column 11: The content of element type mbean must match (attribute*,constructor*,notification*,operation*). org.xml.sax.SAXParseException: The content of element type mbean must match (attribute *,constructor*,notification*,operation*). at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Sou rce) Remove the / at the end of the description element :-) +attributename=disableUploadTimeout + description=Should Tomcat ignore setting a timeout for uploads? / + type=boolean/ Should be attributename=disableUploadTimeout description=Should Tomcat ignore setting a timeout for uploads? type=boolean/ -- Jeanfrancois [EMAIL PROTECTED] wrote: billbarker2002/11/26 23:45:19 Modified:catalina/src/share/org/apache/catalina/mbeans mbeans-descriptors.xml Log: Porting from 4.x branch. Revision ChangesPath 1.11 +5 -1 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/mbeans-descriptors.xml Index: mbeans-descriptors.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/mbeans-descriptors.xml,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- mbeans-descriptors.xml 22 Nov 2002 22:25:17 - 1.10 +++ mbeans-descriptors.xml 27 Nov 2002 07:45:19 - 1.11 @@ -318,6 +318,10 @@ description=Should Tomcat perform all authentications? type=boolean/ +attributename=disableUploadTimeout + description=Should Tomcat ignore setting a timeout for uploads? / + type=boolean/ + /mbean -- 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 14877] - Coyote HTTP not using the port numbers I specify in server.xml
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14877. 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=14877 Coyote HTTP not using the port numbers I specify in server.xml --- Additional Comments From [EMAIL PROTECTED] 2002-11-27 18:32 --- Would you be so kind as to elaborate more. Lets say I want setup 10 servers using port pairs - http port 8080 channel port 8100 - http port 8081 channel port 8101 ... - http port 8089 channel port 8109 Where would I specify these ten channel ports? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/coreStandardValveContext.java ApplicationFilterChain.java ApplicationFilterFactory.javaDummyRequest.java StandardPipeline.java StandardWrapperValve.java
Hi Remy,
the Administration Tool throw the following exception with your latest
change in ApplicationFilterFactory
java.lang.ClassCastException
at
org.apache.catalina.core.ApplicationFilterFactory.createFilterChain(ApplicationFilterFactory.java:150)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:713)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:464)
The problem is at line
+if (securityManager == null) {
+Request req = (Request) request;
The request is an instance of
org.apache.catalina.core.ApplicationHttpRequest, who extends
HttpServletRequestWrapper and who cannot be casted into a Request object
(IMBW). I will investigate further
Any ideas?
-- Jeanfrancois
[EMAIL PROTECTED] wrote:
remm2002/11/25 13:03:50
Modified:catalina/src/share/org/apache/catalina/core
ApplicationFilterChain.java
ApplicationFilterFactory.java DummyRequest.java
StandardPipeline.java StandardWrapperValve.java
Added: catalina/src/share/org/apache/catalina/core
StandardValveContext.java
Log:
- Optimize valves and filters processing (more optimization of
the filter part coming).
- Use request fields instead of allocating objects on each invocation.
Revision ChangesPath
1.4 +5 -5 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationFilterChain.java
Index: ApplicationFilterChain.java
===
RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationFilterChain.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ApplicationFilterChain.java 16 Oct 2002 15:42:09 - 1.3
+++ ApplicationFilterChain.java 25 Nov 2002 21:03:50 - 1.4
@@ -329,7 +329,7 @@
void release() {
this.filters.clear();
-this.iterator = iterator;
+this.iterator = null;
this.servlet = null;
}
1.4 +18 -4 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationFilterFactory.java
Index: ApplicationFilterFactory.java
===
RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationFilterFactory.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ApplicationFilterFactory.java 12 Sep 2002 00:09:27 - 1.3
+++ ApplicationFilterFactory.java 25 Nov 2002 21:03:50 - 1.4
@@ -98,6 +98,9 @@
public static final String DISPATCHER_TYPE_ATTR=org.apache.catalina.core.DISPATCHER_TYPE;
public static final String DISPATCHER_REQUEST_PATH_ATTR=org.apache.catalina.core.DISPATCHER_REQUEST_PATH;
+private static final SecurityManager securityManager =
+System.getSecurityManager();
+
// --- Constructors
@@ -142,7 +145,18 @@
return (null);
// Create and initialize a filter chain object
-ApplicationFilterChain filterChain = new ApplicationFilterChain();
+ApplicationFilterChain filterChain = null;
+if (securityManager == null) {
+Request req = (Request) request;
+filterChain = (ApplicationFilterChain) req.getFilterChain();
+if (filterChain == null) {
+filterChain = new ApplicationFilterChain();
+req.setFilterChain(filterChain);
+}
+} else {
+// Security: Do not recycle
+filterChain = new ApplicationFilterChain();
+}
filterChain.setServlet(servlet);
1.2 +25 -4 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/DummyRequest.java
Index: DummyRequest.java
===
RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/DummyRequest.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- DummyRequest.java 9 Oct 2002 08:01:11 - 1.1
+++ DummyRequest.java 25 Nov 2002 21:03:50 - 1.2
@@ -91,6 +91,7 @@
import javax.naming.NamingException;
import javax.naming.Binding;
import javax.naming.directory.DirContext;
+import javax.servlet.FilterChain;
import javax.servlet.RequestDispatcher;
import javax.servlet.Servlet;
import javax.servlet.ServletContext;
@@ -112,6 +113,7 @@
import org.apache.catalina.HttpRequest;
import org.apache.catalina.Logger;
import org.apache.catalina.Response;
+import org.apache.catalina.ValveContext;
import org.apache.catalina.Wrapper;
import org.apache.catalina.deploy.ApplicationParameter;
import org.apache.catalina.util.Enumerator;
@@ -149,6
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans mbeans-descriptors.xml
jfarcand2002/11/27 10:35:38 Modified:catalina/src/share/org/apache/catalina/mbeans mbeans-descriptors.xml Log: Fix a minor XML mistake ;-) Revision ChangesPath 1.12 +2 -2 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/mbeans-descriptors.xml Index: mbeans-descriptors.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/mbeans-descriptors.xml,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- mbeans-descriptors.xml27 Nov 2002 07:45:19 - 1.11 +++ mbeans-descriptors.xml27 Nov 2002 18:35:38 - 1.12 @@ -319,7 +319,7 @@ type=boolean/ attributename=disableUploadTimeout - description=Should Tomcat ignore setting a timeout for uploads? / + description=Should Tomcat ignore setting a timeout for uploads? type=boolean/ /mbean -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [ANNOUNCEMENT] JK2-2.0.2 released
Hi, im having problems with the 4.1.12 version of tomcat, with this version i cant run servlets, only jsps. the only way that i can make a servlet run is under the context of examples, if i put in another place ( even if a context if defined in the server.xml) doesnt work, Do you have an clue of whats wrong?? Thks in advance Ing. Carlos Ventura Molina Servicios Administrativos Computacionales ITESM Campus Chihuahua Tel. (52 14) 4395000 ext. 4018 Web Site: http://www.chi.itesm.mx -Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 27, 2002 10:35 AM To: Tomcat Developers List Subject: Re: [ANNOUNCEMENT] JK2-2.0.2 released Mladen Turk wrote: Hi to all, JK2 2.0.2 has been released and is available at : http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/release /v 2.0.2/ For now binaries are available for WIN32 only: linux binaries and rpms to be released tomorrow ;) -- 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: [ANNOUNCEMENT] JK2-2.0.2 released
Read the release info on the 4.1.12 version. The invoker servlet has been turned off for security reasons. You have to hand authorize the servlets through your web.xml. At 12:44 PM 11/27/2002 -0700, you wrote: Hi, im having problems with the 4.1.12 version of tomcat, with this version i cant run servlets, only jsps. the only way that i can make a servlet run is under the context of examples, if i put in another place ( even if a context if defined in the server.xml) doesnt work, Do you have an clue of whats wrong?? Thks in advance Ing. Carlos Ventura Molina Servicios Administrativos Computacionales ITESM Campus Chihuahua Tel. (52 14) 4395000 ext. 4018 Web Site: http://www.chi.itesm.mx -Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 27, 2002 10:35 AM To: Tomcat Developers List Subject: Re: [ANNOUNCEMENT] JK2-2.0.2 released Mladen Turk wrote: Hi to all, JK2 2.0.2 has been released and is available at : http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/release /v 2.0.2/ For now binaries are available for WIN32 only: linux binaries and rpms to be released tomorrow ;) -- 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] Micael --- This electronic mail transmission and any accompanying documents contain information belonging to the sender which may be confidential and legally privileged. This information is intended only for the use of the individual or entity to whom this electronic mail transmission was sent as indicated above. If you are not the intended recipient, any disclosure, copying, distribution, or action taken in reliance on the contents of the information contained in this transmission is strictly prohibited. If you have received this transmission in error, please delete the message. Thank you -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/coreStandardValveContext.java ApplicationFilterChain.java ApplicationFilterFactory.javaDummyRequest.java StandardPipeline.java StandardWrapperValve.java
Jeanfrancois Arcand wrote:
Hi Remy,
the Administration Tool throw the following exception with your latest
change in ApplicationFilterFactory
java.lang.ClassCastException
at
org.apache.catalina.core.ApplicationFilterFactory.createFilterChain(ApplicationFilterFactory.java:150)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:713)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:464)
The problem is at line
+if (securityManager == null) {
+Request req = (Request) request;
The request is an instance of
org.apache.catalina.core.ApplicationHttpRequest, who extends
HttpServletRequestWrapper and who cannot be casted into a Request object
(IMBW). I will investigate further
Any ideas?
I forgot some cases, apparently. I'll revert part of the changes
tomorrow and work on improving the filter chain instead of trying to
recycle it (using a complex collection is really overkill).
Remy
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads ThreadPool.java
remm2002/11/27 12:12:17
Modified:util/java/org/apache/tomcat/util/threads ThreadPool.java
Log:
- Replace the Vector with an array. The code is equivalent (or at least it
should be).
- If this is Not Good (TM), -1 and revert ;-)
- I have questions on the TP and related code. Would it be possible to
consider refactoring it, or is it a bad idea ?
Revision ChangesPath
1.4 +13 -16
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java
Index: ThreadPool.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ThreadPool.java 2 Jul 2002 19:57:49 - 1.3
+++ ThreadPool.java 27 Nov 2002 20:12:17 - 1.4
@@ -87,7 +87,7 @@
/*
* Where the threads are held.
*/
-protected Vector pool;
+protected ControlRunnable[] pool = null;
/*
* A monitor thread that monitors the pool for idel threads.
@@ -151,6 +151,8 @@
adjustLimits();
+pool = new ControlRunnable[maxThreads];
+
openThreads(minSpareThreads);
monitor = new MonitorRunnable(this);
}
@@ -247,8 +249,7 @@
}
// If we are here it means that there is a free thred. Take it.
-c = (ControlRunnable)pool.lastElement();
-pool.removeElement(c);
+c = pool[currentThreadCount - currentThreadsBusy - 1];
currentThreadsBusy++;
}
c.runIt(r);
@@ -273,9 +274,9 @@
stopThePool = true;
monitor.terminate();
monitor = null;
-for(int i = 0 ; i (currentThreadCount - currentThreadsBusy) ; i++) {
+for(int i = 0 ; i (currentThreadCount - currentThreadsBusy - 1) ;
i++) {
try {
-((ControlRunnable)(pool.elementAt(i))).terminate();
+pool[i].terminate();
} catch(Throwable t) {
/*
* Do nothing... The show must go on, we are shutting
@@ -304,9 +305,9 @@
maxSpareThreads;
for(int i = 0 ; i toFree ; i++) {
-ControlRunnable c = (ControlRunnable)pool.firstElement();
-pool.removeElement(c);
+ControlRunnable c = pool[currentThreadCount - currentThreadsBusy -
1];
c.terminate();
+pool[currentThreadCount - currentThreadsBusy - 1] = null;
currentThreadCount --;
}
}
@@ -324,7 +325,7 @@
}
currentThreadsBusy--;
-pool.addElement(c);
+pool[currentThreadCount - currentThreadsBusy - 1] = c;
notify();
}
@@ -382,12 +383,8 @@
toOpen = maxThreads;
}
-if(0 == currentThreadCount) {
-pool = new Vector(toOpen);
-}
-
for(int i = currentThreadCount ; i toOpen ; i++) {
-pool.addElement(new ControlRunnable(this));
+pool[i - currentThreadsBusy] = new ControlRunnable(this);
}
currentThreadCount = toOpen;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5 CoyoteConnector.java
remm2002/11/27 12:14:44 Modified:coyote/src/java/org/apache/coyote/tomcat5 CoyoteConnector.java Log: - Update version number. Revision ChangesPath 1.5 +7 -5 jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteConnector.java Index: CoyoteConnector.java === RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteConnector.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- CoyoteConnector.java 26 Nov 2002 03:26:56 - 1.4 +++ CoyoteConnector.java 27 Nov 2002 20:14:43 - 1.5 @@ -188,7 +188,7 @@ * Descriptive information about this Connector implementation. */ private static final String info = -org.apache.coyote.tomcat5.CoyoteConnector2/1.0; +org.apache.coyote.tomcat5.CoyoteConnector/2.0; /** @@ -266,6 +266,7 @@ private StringManager sm = StringManager.getManager(Constants.Package); + /** * Flag to disable setting a seperate time-out for uploads. * If codetrue/code, then the codetimeout/code parameter is @@ -273,6 +274,7 @@ * parameter is used to control uploads. */ private boolean disableUploadTimeout = false; + /** * Has this component been initialized yet? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
euro character problem with tomcat compression Filter
Hí techies! I'm having problems adding the tomcat compression Filter version 4.0.3 to my webapp. Some characters (like euro symbol ) that are printed in my jsp page with a method which return a field of a MSSQLServer table, are printed with the '?' symbol. I've modified the CompressionFilter.java servlet and modified the code. Before the call of doFilter method I set the request to my encoding: request.setCharacterEncoding(iso-8859-1); chain.doFilter(request, response); But this also does not work. Any solution or idea ? Sorry for my English. Thanks, Sergio
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationFilterFactory.java
remm2002/11/27 12:34:20
Modified:catalina/src/share/org/apache/catalina/core
ApplicationFilterFactory.java
Log:
- Using an instanceof seems worth it to avoid an object creation.
Revision ChangesPath
1.5 +5 -4
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationFilterFactory.java
Index: ApplicationFilterFactory.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationFilterFactory.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ApplicationFilterFactory.java 25 Nov 2002 21:03:50 - 1.4
+++ ApplicationFilterFactory.java 27 Nov 2002 20:34:20 - 1.5
@@ -146,7 +146,7 @@
// Create and initialize a filter chain object
ApplicationFilterChain filterChain = null;
-if (securityManager == null) {
+if ((securityManager == null) (request instanceof Request)) {
Request req = (Request) request;
filterChain = (ApplicationFilterChain) req.getFilterChain();
if (filterChain == null) {
@@ -155,6 +155,7 @@
}
} else {
// Security: Do not recycle
+// Cannot recycle when under a request dispatcher
filterChain = new ApplicationFilterChain();
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/coreStandardValveContext.java ApplicationFilterChain.java ApplicationFilterFactory.javaDummyRequest.java StandardPipeline.java StandardWrapperValve.java
Jeanfrancois Arcand wrote:
Hi Remy,
the Administration Tool throw the following exception with your latest
change in ApplicationFilterFactory
java.lang.ClassCastException
at
org.apache.catalina.core.ApplicationFilterFactory.createFilterChain(ApplicationFilterFactory.java:150)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:713)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:464)
The problem is at line
+if (securityManager == null) {
+Request req = (Request) request;
The request is an instance of
org.apache.catalina.core.ApplicationHttpRequest, who extends
HttpServletRequestWrapper and who cannot be casted into a Request object
(IMBW). I will investigate further
Any ideas?
I experimented with using an instanceof, as saving an object allocation
seems like a good idea. Let me know if there's a problem, and I'll fix
it tomorrow (going to bed now; yawn :) ).
Remy
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp_common.cjk_connect.c
That sounds good. It wasn't obvious to me that a failed connection would
still get logged at the ERROR level.
Thanks for cleaning up these error messages.
Glenn
Costin Manolache wrote:
Glenn Nielsen wrote:
Costin,
Why were the log levels changed from LOG_ERROR to LOG_INFO, a connection
failure to tomct is a real fatal error when handling a request. Shouldn't
it be at the JK_LOG_ERROR level?
It'll be logged at ERROR level -
+jk_log(l, JK_LOG_ERROR, Error connecting to tomcat. Tomcat is
probably not started or is listenning on the wrong port. Failed errno =
%d\n, errno); +
( instead of the Can't find servlet handler :-)
I just limited the number of messages that are logged at ERROR level
for each failed connection, you should see a single error message.
If you want more verbosity - you'll get it as info.
Costin
Regards,
Glenn
[EMAIL PROTECTED] wrote:
costin 2002/10/30 14:12:20
Modified:jk/native/common jk_ajp_common.c jk_connect.c
Log:
More trimming for error messages.
Now only one line ( and hopefully more informative ) is displayed if
we can't send the request to tomcat.
Revision ChangesPath
1.32 +11 -5
jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c
Index: jk_ajp_common.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c,v
retrieving revision 1.31 retrieving revision 1.32
diff -u -r1.31 -r1.32
--- jk_ajp_common.c30 Oct 2002 21:17:34 - 1.31
+++ jk_ajp_common.c30 Oct 2002 22:12:20 - 1.32
@@ -623,7 +623,9 @@
}
}
-jk_log(l, JK_LOG_ERROR, ERROR connecting to tomcat. Tomcat is
probably not started. Failed errno = %d\n, errno);
+jk_log(l, JK_LOG_INFO,
+ Error connecting to tomcat. Tomcat is probably not started
or is listenning on the wrong port. Failed errno = %d\n,
+ errno);
return JK_FALSE;
}
@@ -869,7 +871,7 @@
return JK_FALSE;
}
} else {
-jk_log(l, JK_LOG_ERROR, Error connecting to the Tomcat
process.\n);
+jk_log(l, JK_LOG_INFO, Error connecting to the Tomcat
process.\n);
return JK_FALSE;
}
}
@@ -1175,15 +1177,19 @@
return JK_FALSE;
}
-jk_log(l, JK_LOG_ERROR, ERRORO: Receiving from tomcat
failed, recoverable operation. err=%d\n, i);
+jk_log(l, JK_LOG_ERROR, ERROR: Receiving from tomcat
failed, recoverable operation. err=%d\n, i);
}
else
-jk_log(l, JK_LOG_ERROR, ERROR: sending request to
tomcat failed in send loop. err=%d\n, i);
+jk_log(l, JK_LOG_INFO, sending request to tomcat
failed in send loop. err=%d\n, i);
jk_close_socket(p-sd);
p-sd = -1;
ajp_reuse_connection(p, l);
}
+
+/* Log the error only once per failed request. */
+jk_log(l, JK_LOG_ERROR, Error connecting to tomcat. Tomcat is
probably not started or is listenning on the wrong port. Failed errno =
%d\n, errno); +
} else {
jk_log(l, JK_LOG_ERROR, In jk_endpoint_t::service, NULL
parameters\n);
}
1.6 +2 -2
jakarta-tomcat-connectors/jk/native/common/jk_connect.c
Index: jk_connect.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_connect.c,v
retrieving revision 1.5 retrieving revision 1.6
diff -u -r1.5 -r1.6
--- jk_connect.c 4 Sep 2002 11:31:33 - 1.5
+++ jk_connect.c 30 Oct 2002 22:12:20 - 1.6
@@ -174,7 +174,7 @@
jk_log(l, JK_LOG_DEBUG, jk_open_socket, return, sd =
%d\n, sock); return sock;
}
-jk_log(l, JK_LOG_ERROR, jk_open_socket, connect() failed
errno = %d\n, errno);
+jk_log(l, JK_LOG_INFO, jk_open_socket, connect() failed errno
= %d\n, errno);
jk_close_socket(sock);
} else {
#ifdef WIN32
--
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]
--
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/coreStandardValveContext.java ApplicationFilterChain.java ApplicationFilterFactory.javaDummyRequest.java StandardPipeline.java StandardWrapperValve.java
Yep...works fine.
Have nice dream and think of me shaving snow at -15 degre celsius :-(
-- Jeanfrancois
Remy Maucherat wrote:
Jeanfrancois Arcand wrote:
Hi Remy,
the Administration Tool throw the following exception with your
latest change in ApplicationFilterFactory
java.lang.ClassCastException
at
org.apache.catalina.core.ApplicationFilterFactory.createFilterChain(ApplicationFilterFactory.java:150)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:713)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:464)
The problem is at line
+if (securityManager == null) {
+Request req = (Request) request;
The request is an instance of
org.apache.catalina.core.ApplicationHttpRequest, who extends
HttpServletRequestWrapper and who cannot be casted into a Request
object (IMBW). I will investigate further
Any ideas?
I experimented with using an instanceof, as saving an object
allocation seems like a good idea. Let me know if there's a problem,
and I'll fix it tomorrow (going to bed now; yawn :) ).
Remy
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[5] [Proposal] Adding an authorization interface
Hi, I would like to propose the following re-factorisation of the current Realm interface. Righ now, Realm contains 3 methods related to authorization: hasRole hasUserDataPermission hasResourcePermission I would like to create a new interface called Authorizator(and a default AuthorizatorBase) that will take care of those methods. I just think those methods should be grouped together, and I think they are not directly related to the Realm concepts (better separation of concepts). It will allows peoples to change the current resource authorization mechanism without having to modify the Realm interface. Precisely, the method will have the following signature: public boolean hasResourcePermission(HttpRequest request, HttpResponse response, SecurityConstraint constraint, Context context) public boolean hasRolePermission(HttpRequest request, HttpResponse response, String role); public boolean hasUserDataPermission(HttpRequest request, HttpResponse response, SecurityConstraint constraint, Context context) In the current implementation, those methods will get invoked by the AuthenticatorBase and when the user call isUserInRole(). This factorisation will provide the ability to replace/extend the default AuthorizatorBase (that implement the Servlet security-constraint stuffs...section SRV 12.7) by another mechanism: LDAP, NFS, Database, File base, JSR 115, etc. This way peoples will be able to grant/denied permissions not only based on the web.xml content, but also using other technologies. Althrough it is possible to do that with the current Tomcat 5 codebase, I recommend we create this extra interface. For J2EE 1.4, I was able to implement JSR 115 without having to much problems, but I'm sure having a specialized interface will make implementation easier. The Realm.hasRole will be deprecated in order to achieve that re-factorisation. What do you think? Thanks, -- Jeanfrancois -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] [Proposal] Adding an authorization interface
On Wed, 27 Nov 2002, Jeanfrancois Arcand wrote: I would like to create a new interface called Authorizator(and a default AuthorizatorBase) that will take care of those methods. I'd be a lot more willing to buy in to Authorizer and AuthorizerBase :-). The initial Realm design definitely combined the concepts of authentication and authorization. Since the current direction in Java APIs seems to be to split these, it makes sense for us to do so as well. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JspC enhancement
Hi, I'd like to propose a change to org.apache.jasper.JspC in Tomcat4.1.12. Specifically, I'd like to introduce a new command line argument: -pp to apply a package name prefix and create the package name based on the jsp directory structure. Tomcat4's -p option applies the package name prefix, but creates all the jsps in the same package. This leads to duplicate class problems if two jsps in different directories share the same name. BACKGROUND: Our company used to use JspC in Tomcat3 to precompile our JSPs for deployment. Tomcat3 JspC used to generate package names for the JSPs that were based on the directory structure of the jsp directory. We've recently moved to Tomcat4, and this feature apparently didn't carry over to Tomcat4 codeline. EXAMPLE: Given a directory structure of: /jsp/index.jsp /jsp/employee/index.jsp Tomcat3 using JspC like this: java org.apache.jasper.JspC -d . -p foo.bar would yield package and class names of: package foo.bar.jsp; public class index extends HttpJspBase package foo.bar.jsp.employee; public class index extends HttpJspBase Tomcat4 using JspC like this: java org.apache.jasper.JspC -d . -p foo.bar would yield package and class names of: package foo.bar; public class index_jsp extends HttpJspBase package foo.bar; public class index_jsp extends HttpJspBase We'd get a duplicate class definition error here. Thus Tomcat4 using my proposed JspC like this: java org.apache.jasper.JspC -d . -pp foo.bar would yield package and class names of: package foo.bar.jsp; public class index_jsp extends HttpJspBase package foo.bar.jsp.employee; public class index_jsp extends HttpJspBase I'd love to get this committed to the tomcat4 sources. Any suggestions? I've included the code at the end of the email. Sincerely, Brent Jenkins /* * $Header: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java,v 1.12.2.1 2002/08/21 17:54:24 kinman Exp $ * $Revision: 1.12.2.1 $ * $Date: 2002/08/21 17:54:24 $ * * * * The Apache Software License, Version 1.1 * * Copyright (c) 1999 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. The end-user documentation included with the redistribution, if *any, must include the following acknowlegement: * This product includes software developed by the *Apache Software Foundation (http://www.apache.org/). *Alternately, this acknowlegement may appear in the software itself, *if and wherever such third-party acknowlegements normally appear. * * 4. The names The Jakarta Project, Tomcat, and Apache Software *Foundation must not be used to endorse or promote products derived *from this software without prior written permission. For written *permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache *nor may Apache appear in their names without prior written *permission of the Apache Group. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * * This software consists of voluntary contributions made by many * individuals on behalf of the Apache Software Foundation. For more * information on the Apache Software Foundation, please see * http://www.apache.org/. * */ package org.apache.jasper; import java.io.*; import java.net.*; import java.util.*; import org.apache.jasper.compiler.JspReader; import org.apache.jasper.compiler.ServletWriter; import org.apache.jasper.compiler.Compiler; import org.apache.jasper.compiler.TldLocationsCache; import org.apache.jasper.servlet.JasperLoader; import
Build Suggestion
I have a suggestion for the tomcat 4 build process, really more of a doc issue I suppose. The jasper2 tree of the jakarta-tomcat-jasper head does not currently compile. That's probably fine, since it appears to be a dev branch, but it wasn't intuitively obvious (at least to me) what was causing my tc4 build failures. From reading the build docs, it seemed all I should have needed was a checkout of jakarta-tomcat-4.0 and jakarta-tomcat-jasper (and all of the other miscellany, of course :) Unless the two repositories are going to follow the same tagging guidelines, with head being the current stable and separate tags for new dev branches, I think we should make note of which jasper branch is required to build the current tc4 head (in this case tomcat_4_branch). I will commit a short note in BUILDING.txt if this is agreeable. I've been AWOL from the list for a little while, so I apologize if this issue has already been discussed. I'm still in the process of catching up with the recent posts. - Christopher P.S. A question that probably shows how absent I've been recently, but are we not doing builds for jasper? My first inclination when cvs jasper was not compiling was to grab a recent stable build, but I could find none in jakarta.apache.org/builds. Just wondering ... /** * Pleurez, pleurez, mes yeux, et fondez vous en eau! * La moitie de ma vie a mis l'autre au tombeau. * * - Corneille */ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12787] - request.getRequestURI() returns garbage when included in some tags
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=12787. 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=12787 request.getRequestURI() returns garbage when included in some tags --- Additional Comments From [EMAIL PROTECTED] 2002-11-27 23:19 --- I believe I have found the cause of this bug. It is related to the MsgAjp class in the JK server. So this bug probably only appears when using an AJP connection to Tomcat. First of all, it does not only occur when using tag extensions. Any time the page is flushed before request.getRequestURI is called, you will see this bug. I am attaching a very minimal JSP that demonstrates this problem. Call it normally, and the request URI is fine. Call it with a flush request parameter, and the request URI has been changed to a fragment of the filler text at the top of the file. If you pop open the source for org.apache.jk.common.HandlerRequest (I'm working with Tomcat 4.1.12) and go to line 433, you can see where the request URI is initially set, using the msg.getBytes method. On MsgAjp, however, the getBytes (MessageBytes) method does NOT clone it's buffer, it simply gives the MessageBytes object a reference to the buffer. That buffer is then reused when flushing the output stream, causing this problem. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12787] - request.getRequestURI() returns garbage when included in some tags
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=12787. 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=12787 request.getRequestURI() returns garbage when included in some tags --- Additional Comments From [EMAIL PROTECTED] 2002-11-27 23:21 --- Created an attachment (id=3977) A JSP that demonstrates this bug -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JspC enhancement
I like the way JspC works in Tomcat 4.0.x (at least from 4.0.4 and forward). As far as I can tell, it does exactly what you want without the need for extra options (it generates directory-based packages by default). I'm sorry I still haven't found the time to look into the problems with the Tomcat 4.1.x version of JspC, but maybe someone who's close to the Jasper2 source can explain why the Tomcat 4.0.x JspC approach had to be changed for Tomcat 4.1.x, and what the problems are with getting it back to its original behavior at this point? Before we start adding new options, I'd like to understand why we can't just preserve the features we had in TC 4.0.x. Hans Brent Jenkins wrote: Hi, I'd like to propose a change to org.apache.jasper.JspC in Tomcat4.1.12. Specifically, I'd like to introduce a new command line argument: -pp to apply a package name prefix and create the package name based on the jsp directory structure. Tomcat4's -p option applies the package name prefix, but creates all the jsps in the same package. This leads to duplicate class problems if two jsps in different directories share the same name. BACKGROUND: Our company used to use JspC in Tomcat3 to precompile our JSPs for deployment. Tomcat3 JspC used to generate package names for the JSPs that were based on the directory structure of the jsp directory. We've recently moved to Tomcat4, and this feature apparently didn't carry over to Tomcat4 codeline. EXAMPLE: Given a directory structure of: /jsp/index.jsp /jsp/employee/index.jsp Tomcat3 using JspC like this: java org.apache.jasper.JspC -d . -p foo.bar would yield package and class names of: package foo.bar.jsp; public class index extends HttpJspBase package foo.bar.jsp.employee; public class index extends HttpJspBase Tomcat4 using JspC like this: java org.apache.jasper.JspC -d . -p foo.bar would yield package and class names of: package foo.bar; public class index_jsp extends HttpJspBase package foo.bar; public class index_jsp extends HttpJspBase We'd get a duplicate class definition error here. Thus Tomcat4 using my proposed JspC like this: java org.apache.jasper.JspC -d . -pp foo.bar would yield package and class names of: package foo.bar.jsp; public class index_jsp extends HttpJspBase package foo.bar.jsp.employee; public class index_jsp extends HttpJspBase I'd love to get this committed to the tomcat4 sources. Any suggestions? I've included the code at the end of the email. Sincerely, Brent Jenkins /* * $Header: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java,v 1.12.2.1 2002/08/21 17:54:24 kinman Exp $ * $Revision: 1.12.2.1 $ * $Date: 2002/08/21 17:54:24 $ * * * * The Apache Software License, Version 1.1 * * Copyright (c) 1999 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. The end-user documentation included with the redistribution, if *any, must include the following acknowlegement: * This product includes software developed by the *Apache Software Foundation (http://www.apache.org/). *Alternately, this acknowlegement may appear in the software itself, *if and wherever such third-party acknowlegements normally appear. * * 4. The names The Jakarta Project, Tomcat, and Apache Software *Foundation must not be used to endorse or promote products derived *from this software without prior written permission. For written *permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache *nor may Apache appear in their names without prior written *permission of the Apache Group. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT * OF THE USE OF THIS SOFTWARE, EVEN IF
Re: [5] [Proposal] Adding an authorization interface
IMO - I would rather see us using JAAS directly as API instead of defining our own. I already mentioned that I would preffer using JNDI for abstracting the informations about user/group. In general, the fewer interfaces we define, the better it is. Costin Jeanfrancois Arcand wrote: Hi, I would like to propose the following re-factorisation of the current Realm interface. Righ now, Realm contains 3 methods related to authorization: hasRole hasUserDataPermission hasResourcePermission I would like to create a new interface called Authorizator(and a default AuthorizatorBase) that will take care of those methods. I just think those methods should be grouped together, and I think they are not directly related to the Realm concepts (better separation of concepts). It will allows peoples to change the current resource authorization mechanism without having to modify the Realm interface. Precisely, the method will have the following signature: public boolean hasResourcePermission(HttpRequest request, HttpResponse response, SecurityConstraint constraint, Context context) public boolean hasRolePermission(HttpRequest request, HttpResponse response, String role); public boolean hasUserDataPermission(HttpRequest request, HttpResponse response, SecurityConstraint constraint, Context context) In the current implementation, those methods will get invoked by the AuthenticatorBase and when the user call isUserInRole(). This factorisation will provide the ability to replace/extend the default AuthorizatorBase (that implement the Servlet security-constraint stuffs...section SRV 12.7) by another mechanism: LDAP, NFS, Database, File base, JSR 115, etc. This way peoples will be able to grant/denied permissions not only based on the web.xml content, but also using other technologies. Althrough it is possible to do that with the current Tomcat 5 codebase, I recommend we create this extra interface. For J2EE 1.4, I was able to implement JSR 115 without having to much problems, but I'm sure having a specialized interface will make implementation easier. The Realm.hasRole will be deprecated in order to achieve that re-factorisation. What do you think? Thanks, -- Jeanfrancois -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
how do i find the patch for bug 12699
Hi tomcat developers, I am using the tomcat 4.0 and 4.1 series and experiencing the problem described in bug 12699: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12699 i.e. only the final cookie added to a servlet response is actually returned. The bug indicates that it has been fixed in the CVS. How do I figure out what the patch was so I can apply or adapt it to the version I am using and build a fixed tomcat? many thanks, Greg Klanderman -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] [Proposal] Adding an authorization interface
Costin Manolache wrote:
IMO - I would rather see us using JAAS directly as API
instead of defining our own.
Can you elaborate a little more? JAAS will certainly help for user/group
authentication/authorization, but I don't think you can use it for
granting/denying web resources (JSR 115 is exactly doing that). With
115, you can use the normal policy statement to grant web resources
permission:
ex (for the admin tool)
grant codeBase file://admin , principal
org.apache.catalina.realm.GenericRealm tomcat {
// Role Mapped for this Grant : admin
permission javax.security.jacc.WebResourcePermission *.jsp ,
DELETE,GET,HEAD,OPTIONS,POST,PUT,TRACE;
// Role Mapped for this Grant : admin
permission javax.security.jacc.WebRoleRefPermission action ,
admin;
// Role Mapped for this Grant : admin
permission javax.security.jacc.WebResourcePermission *.html ,
DELETE,GET,HEAD,OPTIONS,POST,PUT,TRACE;
// Role Mapped for this Grant : admin
permission javax.security.jacc.WebResourcePermission *.do ,
DELETE,GET,HEAD,OPTIONS,POST,PUT,TRACE;
};
will get translated to javax.security.jacc.WebResourcePermission,
WebRoleRefPermission and WebUserDataPermission. In order to only use
JAAS, we will have to:
(1) Associate the Subject with an access control context (already done
in Tomcat 5)
(2) Define are own set of permission object/mapping.
If we decide to go with only JAAS, then I recommend we use JSR 115
instead of redefining something. But I would prefer opening the API for
other technologies instead of limitating us with JAAS. Of course we can
ship with a JAAS/115 default implementation. Between Tomcat and JAAS, we
will need an interface. That's what I'm proposing. Righ now both
authentication and authorization are in Realm.
I already mentioned that I would preffer using JNDI for
abstracting the informations about user/group. In general, the
fewer interfaces we define, the better it is.
Authorizer and AuthorizerBase (proper english this time :-) ) are not
about user/group, but about granting web resources to user and group.
JNDI can used for replacing/improving the Realm implementation, but IMO
not to grant/denied web resources (OK we can always define our JNDI
permissions). Is that was you mean or do I miss something with JNDI?
Thanks,
-- Jeanfrancois
Costin
Jeanfrancois Arcand wrote:
Hi,
I would like to propose the following re-factorisation of the current
Realm interface. Righ now, Realm contains 3 methods related to
authorization:
hasRole
hasUserDataPermission
hasResourcePermission
I would like to create a new interface called Authorizator(and a default
AuthorizatorBase) that will take care of those methods. I just think
those methods should be grouped together, and I think they are not
directly related to the Realm concepts (better separation of
concepts). It will allows peoples to change the current resource
authorization mechanism without having to modify the Realm interface.
Precisely, the method will have the following signature:
public boolean hasResourcePermission(HttpRequest request,
HttpResponse response,
SecurityConstraint constraint,
Context
context)
public boolean hasRolePermission(HttpRequest request,
HttpResponse
response,
String role);
public boolean hasUserDataPermission(HttpRequest request,
HttpResponse response,
SecurityConstraint constraint,
Context context)
In the current implementation, those methods will get invoked by the
AuthenticatorBase and when the user call isUserInRole().
This factorisation will provide the ability to replace/extend the
default AuthorizatorBase (that implement the Servlet
security-constraint stuffs...section SRV 12.7) by another mechanism:
LDAP, NFS, Database, File base, JSR 115, etc. This way peoples will be
able to grant/denied permissions not only based on the web.xml content,
but also using other technologies. Althrough it is possible to do that
with the current Tomcat 5 codebase, I recommend we create this extra
interface. For J2EE 1.4, I was able to implement JSR 115 without having
to much problems, but I'm sure having a specialized interface will make
implementation easier.
The Realm.hasRole will be deprecated in order to achieve that
re-factorisation.
What do you think?
Thanks,
-- Jeanfrancois
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] [Proposal] Adding an authorization interface
Jeanfrancois Arcand wrote:
Costin Manolache wrote:
IMO - I would rather see us using JAAS directly as API
instead of defining our own.
Can you elaborate a little more? JAAS will certainly help for user/group
authentication/authorization, but I don't think you can use it for
granting/denying web resources (JSR 115 is exactly doing that). With
115, you can use the normal policy statement to grant web resources
permission:
I was thinking at authentication ( this is the main use of Realm AFAIK ).
JAAS is also used for authorization ( I don't know about JSR115),
but in tomcat case the mapper and the web.xml stuff controls this,
and I don't see any good reason to change this.
ex (for the admin tool)
grant codeBase file://admin , principal
org.apache.catalina.realm.GenericRealm tomcat {
// Role Mapped for this Grant : admin
permission javax.security.jacc.WebResourcePermission *.jsp ,
DELETE,GET,HEAD,OPTIONS,POST,PUT,TRACE;
// Role Mapped for this Grant : admin
permission javax.security.jacc.WebRoleRefPermission action ,
admin;
// Role Mapped for this Grant : admin
permission javax.security.jacc.WebResourcePermission *.html ,
DELETE,GET,HEAD,OPTIONS,POST,PUT,TRACE;
// Role Mapped for this Grant : admin
permission javax.security.jacc.WebResourcePermission *.do ,
DELETE,GET,HEAD,OPTIONS,POST,PUT,TRACE;
};
will get translated to javax.security.jacc.WebResourcePermission,
WebRoleRefPermission and WebUserDataPermission. In order to only use
JAAS, we will have to:
Why would someone use this instead of web.xml ?
I don't mind having the security config consistent with the policy
( I never liked how it's done in web.xml ). However at least from my
point of view the more interesting issue is integrating with the web
server semantics and syntax ( and how to write the authorization
definition in httpd.conf ).
(1) Associate the Subject with an access control context (already done
in Tomcat 5)
(2) Define are own set of permission object/mapping.
If we decide to go with only JAAS, then I recommend we use JSR 115
instead of redefining something. But I would prefer opening the API for
other technologies instead of limitating us with JAAS. Of course we can
ship with a JAAS/115 default implementation. Between Tomcat and JAAS, we
will need an interface. That's what I'm proposing. Righ now both
authentication and authorization are in Realm.
What's wrong with using JAAS as an interface ? After all that's
the purpose of JAAS - an interface for authorization ( and authentication ).
I'm not sure we're talking about the same things.
I already mentioned that I would preffer using JNDI for
abstracting the informations about user/group. In general, the
fewer interfaces we define, the better it is.
Authorizer and AuthorizerBase (proper english this time :-) ) are not
about user/group, but about granting web resources to user and group.
JNDI can used for replacing/improving the Realm implementation, but IMO
not to grant/denied web resources (OK we can always define our JNDI
permissions). Is that was you mean or do I miss something with JNDI?
I mentioned JNDI as an API to access (abstract) information about users.
JAAS for authentication.
If by authorization you mean deciding in an URL can be accessed by a user -
I think the mapper ( or a similar valve ) is the best solution, using
the informations in web.xml.
Since the problem of mapping this into httpd.conf semantics is alrady
very complex ( and not completely resolved), I would need a lot of arguments
in opening this up to arbitrary user code - that would be close to
impossible to integrate with the web server and have consistent behavior.
Having the web server call tomcat for each static page in order to call
this authorization hook is not acceptable.
Costin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] [Proposal] Adding an authorization interface
Costin Manolache wrote:
Jeanfrancois Arcand wrote:
Costin Manolache wrote:
IMO - I would rather see us using JAAS directly as API
instead of defining our own.
Can you elaborate a little more? JAAS will certainly help for user/group
authentication/authorization, but I don't think you can use it for
granting/denying web resources (JSR 115 is exactly doing that). With
115, you can use the normal policy statement to grant web resources
permission:
I was thinking at authentication ( this is the main use of Realm AFAIK ).
JAAS is also used for authorization ( I don't know about JSR115),
but in tomcat case the mapper and the web.xml stuff controls this,
and I don't see any good reason to change this.
ex (for the admin tool)
grant codeBase file://admin , principal
org.apache.catalina.realm.GenericRealm tomcat {
// Role Mapped for this Grant : admin
permission javax.security.jacc.WebResourcePermission *.jsp ,
DELETE,GET,HEAD,OPTIONS,POST,PUT,TRACE;
// Role Mapped for this Grant : admin
permission javax.security.jacc.WebRoleRefPermission action ,
admin;
// Role Mapped for this Grant : admin
permission javax.security.jacc.WebResourcePermission *.html ,
DELETE,GET,HEAD,OPTIONS,POST,PUT,TRACE;
// Role Mapped for this Grant : admin
permission javax.security.jacc.WebResourcePermission *.do ,
DELETE,GET,HEAD,OPTIONS,POST,PUT,TRACE;
};
will get translated to javax.security.jacc.WebResourcePermission,
WebRoleRefPermission and WebUserDataPermission. In order to only use
JAAS, we will have to:
Why would someone use this instead of web.xml ?
Because you can start using the java.security.Provider.checkPermission
for granting/denying resources.
I don't mind having the security config consistent with the policy
( I never liked how it's done in web.xml ). However at least from my
point of view the more interesting issue is integrating with the web
server semantics and syntax ( and how to write the authorization
definition in httpd.conf ).
I agree and I would like to work also on itbut I think we don't
speak about the same level of authentication. I mean URL autorization,
i.e. the way we , at runtime, enforce the security constraint defined in
web.xml.
(1) Associate the Subject with an access control context (already done
in Tomcat 5)
(2) Define are own set of permission object/mapping.
If we decide to go with only JAAS, then I recommend we use JSR 115
instead of redefining something. But I would prefer opening the API for
other technologies instead of limitating us with JAAS. Of course we can
ship with a JAAS/115 default implementation. Between Tomcat and JAAS, we
will need an interface. That's what I'm proposing. Righ now both
authentication and authorization are in Realm.
What's wrong with using JAAS as an interface ? After all that's
the purpose of JAAS - an interface for authorization ( and authentication ).
I'm not sure we're talking about the same things.
You cannot grant/denied URL using JAAS as it is right now. In order to
achieve that, you need something like JSR 115.
I already mentioned that I would preffer using JNDI for
abstracting the informations about user/group. In general, the
fewer interfaces we define, the better it is.
Authorizer and AuthorizerBase (proper english this time :-) ) are not
about user/group, but about granting web resources to user and group.
JNDI can used for replacing/improving the Realm implementation, but IMO
not to grant/denied web resources (OK we can always define our JNDI
permissions). Is that was you mean or do I miss something with JNDI?
I mentioned JNDI as an API to access (abstract) information about users.
JAAS for authentication.
+1...but this is not related to my proposal.
If by authorization you mean deciding in an URL can be accessed by a user -
I think the mapper ( or a similar valve ) is the best solution, using
the informations in web.xml.
Exactly. The similar valve :-) is the AuthenticatorBase, who delegate
part of the authorization decision to the RealmBase, as well as part of
authentication. I'm +1 to delegate the authentication to the RealBase,
but -1 to delegate the authorization (this is how it is implemented
right now). What I recommend is to remove the authorization code from
the RealmBase and move it to the AutorizerBase. It's just refactoring
one class into 2. Then we will be able to use JAAS (or 115, LDAP, NFS,
etc.) in a cleaner way.
Using JAAS as an interface will have to happen somewhere in
AuthenticatorBase RealmBase. Since in JAAS there is a clear separation
between authentication/autorization, why not have the same separation in
Tomcat by having Realm Authorizer (instead of only Realm).
Thanks
-- Jeanfrancois
Since the problem of mapping this into httpd.conf semantics is alrady
very complex ( and not completely resolved), I would need a lot of arguments
in opening
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans mbeans-descriptors.xml
billbarker2002/11/27 18:57:14 Modified:catalina/src/share/org/apache/catalina/mbeans mbeans-descriptors.xml Log: Fix typo in last commit. Thanks to Jeanfrancois for catching this. Revision ChangesPath 1.73 +2 -2 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/mbeans-descriptors.xml Index: mbeans-descriptors.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/mbeans-descriptors.xml,v retrieving revision 1.72 retrieving revision 1.73 diff -u -r1.72 -r1.73 --- mbeans-descriptors.xml27 Nov 2002 07:41:32 - 1.72 +++ mbeans-descriptors.xml28 Nov 2002 02:57:14 - 1.73 @@ -320,7 +320,7 @@ type=boolean/ attributename=disableUploadTimeout - description=Should Tomcat ignore setting a timeout for uploads? / + description=Should Tomcat ignore setting a timeout for uploads? type=boolean/ /mbean -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] [Proposal] Adding an authorization interface
Jeanfrancois Arcand wrote: Why would someone use this instead of web.xml ? Because you can start using the java.security.Provider.checkPermission for granting/denying resources. Not sure this would be the most efficient solution - the mapper is ( or will be ) optimized on the way it is used in tomcat. But I see your point - and I think it would be nice to use similar concepts or API. If by authorization you mean deciding in an URL can be accessed by a user - I think the mapper ( or a similar valve ) is the best solution, using the informations in web.xml. Exactly. The similar valve :-) is the AuthenticatorBase, who delegate part of the authorization decision to the RealmBase, as well as part of authentication. I'm +1 to delegate the authentication to the RealBase, but -1 to delegate the authorization (this is how it is implemented right now). What I recommend is to remove the authorization code from the RealmBase and move it to the AutorizerBase. It's just refactoring one class into 2. Then we will be able to use JAAS (or 115, LDAP, NFS, etc.) in a cleaner way. Using JAAS as an interface will have to happen somewhere in AuthenticatorBase RealmBase. Since in JAAS there is a clear separation between authentication/autorization, why not have the same separation in Tomcat by having Realm Authorizer (instead of only Realm). I agree that authenticate and authorize are 2 different hooks and need to be separated. Let me think about it - and maybe get some other opinions. I would very much preffer a consistent mechanism for all the hooks in tomcat. In 3.3 there is one interface ( BaseInterceptor ) where all the possible hooks are defined ( with a number of problems we already know regarding ordering, but that's a different issue ). In 4.x Valves are used as the main extension mechanism, but also Listeners, Realms, Connectors and few other interfaces - and I would very much prefer a solution that is more consistent and simpler. For example - move it at Coyote level and use an ActionCode for authorization. Things are not very well defined for chaining the coyote actions, but it can be done easily. All hooks could be defined as coyote Actions - instead of having a specific Authorizer interface you'll have an authorizer action. Does it sound acceptable ? I would mention that this is how authorization is implemented in apache ( and most web servers ), and it would probably make it easier to integrate. Well, there is just a style difference between having a generic hook and having one specific interface like Authorizer, but for a lot of people understanding the hook mechanism and the particular hooks is easier than dealing with dozens of slightly different interfaces. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet JasperLoader.java JspServletWrapper.java
luehe 2002/11/27 20:18:08
Modified:jasper2/src/share/org/apache/jasper Constants.java
EmbededServletOptions.java
JspCompilationContext.java
jasper2/src/share/org/apache/jasper/compiler Compiler.java
Generator.java ImplicitTagLibraryInfo.java
JspRuntimeContext.java JspUtil.java Node.java
TagFileProcessor.java TagLibraryInfoImpl.java
jasper2/src/share/org/apache/jasper/servlet
JasperLoader.java JspServletWrapper.java
Log:
Avoid conflicts between tag files that are located in different
directories and therefore are considered to belong to different
implicit tag libraries.
The path of a tag file is now reflected in the directory in which the
corresponding tag handler is stored, and in the name of the package to
which the tag handler is assigned.
This change also avoids conflicts between tag files with the same name
and path under /META-INF/tags/ and /WEB-INF/tags/, by adding meta or
web, respectively, to the directory and package names of the
respective tag handlers.
Revision ChangesPath
1.10 +1 -2
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/Constants.java
Index: Constants.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/Constants.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- Constants.java16 Nov 2002 04:20:09 - 1.9
+++ Constants.java28 Nov 2002 04:18:07 - 1.10
@@ -158,8 +158,7 @@
/**
* The default package name for tag handlers generated from tag files
*/
-public static final String TAG_FILE_PACKAGE_NAME
- = org.apache.jsp.tagfile;
+public static final String TAG_FILE_PACKAGE_NAME = org.apache.jsp.tag;
/**
* Servlet context and request attributes that the JSP engine
1.13 +10 -9
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/EmbededServletOptions.java
Index: EmbededServletOptions.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/EmbededServletOptions.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- EmbededServletOptions.java16 Nov 2002 04:20:09 - 1.12
+++ EmbededServletOptions.java28 Nov 2002 04:18:07 - 1.13
@@ -435,12 +435,14 @@
if (classpath != null)
this.classpath = classpath;
+ /*
+ * scratchdir
+ */
String dir = config.getInitParameter(scratchdir);
-
-if (dir != null)
+if (dir != null) {
scratchDir = new File(dir);
-else {
-// First we try the Servlet 2.2 javax.servlet.context.tempdir property
+} else {
+// First try the Servlet 2.2 javax.servlet.context.tempdir property
scratchDir = (File) context.getAttribute(Constants.TMP_DIR);
if (scratchDir == null) {
// Not running in a Servlet 2.2 container.
@@ -449,8 +451,7 @@
if (dir != null)
scratchDir = new File(dir);
}
-}
-
+}
if (this.scratchDir == null) {
Constants.message(jsp.error.no.scratch.dir, Logger.FATAL);
return;
1.25 +68 -54
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspCompilationContext.java
Index: JspCompilationContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspCompilationContext.java,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- JspCompilationContext.java28 Oct 2002 18:16:19 - 1.24
+++ JspCompilationContext.java28 Nov 2002 04:18:07 - 1.25
@@ -91,7 +91,7 @@
private Hashtable tagFileJars;
private boolean isPackagedTagFile;
-private String servletClassName;
+private String className;
private String jspUri;
private boolean isErrPage;
private String servletPackageName;
@@ -301,40 +301,45 @@
*/
public String getServletClassName() {
- if (isTagFile) {
- return tagInfo.getTagName();
- }
-
-if (servletClassName != null) {
-return servletClassName;
+if (className != null) {
+return className;
}
-int iSep = jspUri.lastIndexOf('/') + 1;
-int iEnd = jspUri.length();
-StringBuffer modifiedClassName =
-
[ANNOUNCEMENT] JK2-2.0.2 released
Hi to all, JK2 2.0.2 has been released and is available at : http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/release/v 2.0.2/ For now binaries are available for WIN32 only: Changes between JK2 2.0.1 and JK2 2.0.2: * Fix the bug 14293. Thanks to Martin Kraemer for his help. [Jean-Frederic Clere] * Don't send initial chunk for chunked encoding, fix #14282 [Costin Manolache] * Fix the POST data on JNI [Mladen Turk] * Remove the deprecated message for path [Costin Manolache] * Add the regular expressions to uriMap. The regex uris are differentiated to normal one by starting with dollar ($) sign. [Mladen Turk] * Add the max_connections to the wajp13 worker. [Mladen Turk] * Add the hostMap cache [Mladen Turk] * Allow the lb:name scheme inside the [channel.xxx] [Mladen Turk] * Duplicate all global directives on each vhost that has inheritGlobals set. Directives are created using createBean only if not found. Beside directives, the webapps are duplicated to. [Mladen Turk] Regards, MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [ANNOUNCEMENT] JK2-2.0.2 released
Mladen Turk wrote: Hi to all, JK2 2.0.2 has been released and is available at : http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/release/v 2.0.2/ For now binaries are available for WIN32 only: I will do the Solaris8 binaries tomorrow morming (I am at GMT+1). Changes between JK2 2.0.1 and JK2 2.0.2: * Fix the bug 14293. Thanks to Martin Kraemer for his help. [Jean-Frederic Clere] * Don't send initial chunk for chunked encoding, fix #14282 [Costin Manolache] * Fix the POST data on JNI [Mladen Turk] * Remove the deprecated message for path [Costin Manolache] * Add the regular expressions to uriMap. The regex uris are differentiated to normal one by starting with dollar ($) sign. [Mladen Turk] * Add the max_connections to the wajp13 worker. [Mladen Turk] * Add the hostMap cache [Mladen Turk] * Allow the lb:name scheme inside the [channel.xxx] [Mladen Turk] * Duplicate all global directives on each vhost that has inheritGlobals set. Directives are created using createBean only if not found. Beside directives, the webapps are duplicated to. [Mladen Turk] Regards, MT. -- 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]
Comment on doc for Jk/Jk2 distributed with Tomcat 4.1
Hi, This is for the author of the document available at http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/index.html based on my experience with trying to connect apache 1.3.27 to Tomcat 4.1.12. In the Apache HowTo section, there is a subsection Using Tomcat auto-configure. I would like to ask the author to please clarify this. I know that Tomcat 3 offered a feature to create a configuration file that was suitable for use by Apache; I believe this feature was invoked by some magic option passed to Tomcat at start time. But I cannot find anything similar in Tomcat 4. Is it still there? Please help and/or clarify that document. I would also like to ask for clarification of the mod_jk versus mod_jk2 question. The document mentions jk2 briefly as the best thing to use in the beginning, but the rest of the document seems to be focused on jk version 1.2, which I believe is just mod_jk or jk for short. THANKS. chris... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
AW: euro character problem with tomcat compression Filter
try, to set the response encoding to 8559-15 cu Torsten -Ursprüngliche Nachricht- Von: Sergio [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 27. November 2002 21:18 An: 'Tomcat Developers List' Betreff: euro character problem with tomcat compression Filter Hí techies! I'm having problems adding the tomcat compression Filter version 4.0.3 to my webapp. Some characters (like euro symbol ) that are printed in my jsp page with a method which return a field of a MSSQLServer table, are printed with the '?' symbol. I've modified the CompressionFilter.java servlet and modified the code. Before the call of doFilter method I set the request to my encoding: request.setCharacterEncoding(iso-8859-1); chain.doFilter(request, response); But this also does not work. Any solution or idea ? Sorry for my English. Thanks, Sergio -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_global.h
mturk 2002/11/27 23:36:31
Modified:jk/native2/include jk_global.h
Log:
Change the versioning scheme.
If the JK_VERISRELEASE is 0, then the '-dev' suffix will be added.
If the JK_VERBETA is greater then 0, the '-beta-X' suffix will be added.
So for example:
JK_VERISRELEASE 0, JK_VERBETA 1 - mod_jk2/2.0.3-dev-beta-1
JK_VERISRELEASE 0, JK_VERBETA 0 - mod_jk2/2.0.3-dev
JK_VERISRELEASE 1, JK_VERBETA 1 - mod_jk2/2.0.3-beta-1
JK_VERISRELEASE 0, JK_VERBETA 0 - mod_jk2/2.0.3
Revision ChangesPath
1.17 +22 -8 jakarta-tomcat-connectors/jk/native2/include/jk_global.h
Index: jk_global.h
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_global.h,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- jk_global.h 27 Nov 2002 17:12:05 - 1.16
+++ jk_global.h 28 Nov 2002 07:36:31 - 1.17
@@ -90,7 +90,7 @@
#define JK_VERSTRING2.0.3
/* Beta number */
-#define JK_VERBETA 1
+#define JK_VERBETA 0
#define JK_BETASTRING 1
/* set JK_VERISRELEASE to 1 when release (do not forget to commit!) */
#define JK_VERISRELEASE 0
@@ -100,12 +100,19 @@
/* Build JK_EXPOSED_VERSION and JK_VERSION */
#define JK_EXPOSED_VERSION_INT PACKAGE JK_VERSTRING
+
#if ( JK_VERISRELEASE == 1 )
-#define JK_EXPOSED_VERSION JK_EXPOSED_VERSION_INT
-#undef JK_VERBETA
-#define JK_VERBETA 255
+ #define JK_RELEASE_STR JK_EXPOSED_VERSION_INT
+#else
+ #define JK_RELEASE_STR JK_EXPOSED_VERSION_INT -dev
+#endif
+
+#if ( JK_VERBETA == 0 )
+#define JK_EXPOSED_VERSION JK_RELEASE_STR
+#undef JK_VERBETA
+#define JK_VERBETA 255
#else
-#define JK_EXPOSED_VERSION JK_EXPOSED_VERSION_INT -beta- JK_BETASTRING
+#define JK_EXPOSED_VERSION JK_RELEASE_STR -beta- JK_BETASTRING
#endif
#define JK_MAKEVERSION(major, minor, fix, beta) (((major) 24) + ((minor) 16)
+ ((fix) 8) + (beta))
@@ -193,7 +200,14 @@
/* Some compileers support 'inline'. How to guess ?
#define INLINE inline
*/
-#define INLINE
+
+/* For VC the __inline keyword is available in both C and C++.*/
+#if defined(_WIN32) defined(_MSC_VER)
+#define INLINE __inline
+#else
+/* XXX: Other compilers? */
+#define INLINE
+#endif
#define JK_WORKER_FILE_TAG (worker_file)
#define JK_MOUNT_FILE_TAG (worker_mount_file)
@@ -201,7 +215,7 @@
#define JK_LOG_FILE_TAG (log_file)
#define JK_WORKER_NAME_TAG (worker)
-#define JK_WORKER_FILE_DEF (workers.properties)
+#define JK_WORKER_FILE_DEF (${serverRoot}/conf/workers2.properties)
#define JK_LOG_LEVEL_DEF(emerg)
#define JK_TRUE (1)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
AW: euro character problem with tomcat compression Filter
sorry, iso-8859-15 -Ursprüngliche Nachricht- Von: Torsten Fohrer [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 28. November 2002 08:28 An: 'Tomcat Developers List' Betreff: AW: euro character problem with tomcat compression Filter try, to set the response encoding to 8559-15 cu Torsten -Ursprüngliche Nachricht- Von: Sergio [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 27. November 2002 21:18 An: 'Tomcat Developers List' Betreff: euro character problem with tomcat compression Filter Hí techies! I'm having problems adding the tomcat compression Filter version 4.0.3 to my webapp. Some characters (like euro symbol ) that are printed in my jsp page with a method which return a field of a MSSQLServer table, are printed with the '?' symbol. I've modified the CompressionFilter.java servlet and modified the code. Before the call of doFilter method I set the request to my encoding: request.setCharacterEncoding(iso-8859-1); chain.doFilter(request, response); But this also does not work. Any solution or idea ? Sorry for my English. Thanks, Sergio -- 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]
