Re: Cannot Build WebApp on Solaris 2.8
Jay Ebert wrote: APR was included with webapp-module-1.0-tc40.src.tar. Earlier today I downloaded apr-0.9.1 and successfully built libapr.so but the make at the Webapp-module-1.0-tc40 level failed with: make[1]: Exiting directory /export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40/apr make[]: Installing APR library in /export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40/lib *** Error code 1 make: Fatal error: Command failed for target `apr-build' I just can't seem to get the right pieces to build mod_webapp.so on Solaris 2.8. Any suggestions ? Try using the cvs of mod_webapp I have fixed APR related problems some week ago. It is not possible to use Webapp-module-1.0-tc40 with apr-0.9.1. -Original Message- From: jean-frederic clere [mailto:[EMAIL PROTECTED]] Sent: Monday, September 30, 2002 1:32 AM To: Tomcat Developers List Subject: Re: Cannot Build WebApp on Solaris 2.8 Jay Ebert wrote: I followed the Building the WebApp module exactly and cannot build the webapp module for Solaris 2.8 using gcc 2.95. After a successful ./configure ... , I get the following errors on the make: Which APR are you using? wcarweb1:/export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40 # make make[1]: Entering directory lib make[1]: Invoking make build /opt/sfw/bin//gcc -g -O2-DSOLARIS2=8 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -I/export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40/apr/includ e -I/export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40/include -c wa_main.c -o wa_main.o In file included from /export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40/apr/include/ apr_general.h:61, from /export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40/include/wa.h :77, from wa_main.c:59: /export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40/apr/include/ apr.h:198: #error Can not determine the proper size for apr_int64_t /export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40/apr/include/ apr.h:253: #error Can not determine the proper size for ssize_t /export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40/apr/include/ apr.h:256: #error Can not determine the proper size for size_t /export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40/apr/include/ apr.h:265: #error Can not determine the proper size for apr_int64_t *** Error code 1 make: Fatal error: Command failed for target `wa_main.o' Current working directory /export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40/lib *** Error code 1 make: Fatal error: Command failed for target `template' Current working directory /export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40 *** Error code 1 make: Fatal error: Command failed for target `lib-build' -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[VOTE] JK2 2.1
Hi, Since there has been general concensus that we should use the APR for every supported API call. Here is my design proposal. General: [x] Drop HAS_APR flags and dissalow building of JK2 without APR [ ] Keep everything like it is (the rest doesn't interests me) Regular expressions: [ ] Add pcre from httpd-2.0 to the common/pcre [x] Add pcre from httpd-2.0 to the srclib/pcre [ ] Wait if pcre ever comes to the apr-util Pools: [ ] Use the real apr_pool_t. [x] Keep the jk_pool_apr wrapper renaming it to the jk_pool Sockets: [x] Use only apr_socket and drop the socket, renaming apr to socket. [ ] Keep supporting socket. File I/O: [x] Use the APR for file i/o replacing stdio/stdlib calls [ ] Keep the old fopen/fwrite/etc... code Static buildings: [x] Enable Static/Dynamic APR builds of JK2 for non-Apache2 connectors [ ] Enable only dynamic builds MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: tomcat 3.3.2 cleanup
Costin Manolache wrote: Henri Gomez wrote: Costin Manolache wrote: Henri Gomez wrote: If everybody agree, what about removing src/native for tomcat 3.3.2 ? +1 Yes or no ? Actually, another way is to move mod_jserv in j-t-c, and remove src/native completely. It seems a good idea, should we get mod_jserv from tc 3.3 cvs or from jserv repository ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Cookie values
Hi! I had a problem with accented characters Cookie values, and also just a little longer Strings. Tomcat threw an IllegalArgumentException in maybeQuote like this: java.lang.IllegalArgumentException: =?ISO-8859-1?Q? (keinotekoinen_AND_=E4lykkyys)?= =?ISO-8859-1?Q?_AND_NOT_nodetype:ALL=5FCONTENT?= at org.apache.tomcat.util.http.ServerCookie.maybeQuote (ServerCookie.java:315) at org.apache.tomcat.util.http.ServerCookie.appendCookieValue (ServerCookie.java:248) at org.apache.coyote.tomcat4.CoyoteResponse.addCookie (CoyoteResponse.java:853) at org.apache.coyote.tomcat4.CoyoteResponseFacade.addCookie (CoyoteResponseFacade.java:278) [...etc] I searched the web and found a couple of other people asking the same question, but no answers. So, Sun's javax.servlet.http.Cookie and Tomcat's javadocs say that the Cookie's value can be anything, but also that If you use a binary value, you may want to use BASE64 encoding. and that With Version 0 cookies, values should not contain white space, brackets, parentheses, equals signs, commas, double quotes, slashes, question marks, at signs, colons, and semicolons. That's a contradiction, isn't it? BASE64 results in data that may have white space (newlines). But the Netscape's cookie definition says This string is a sequence of characters excluding semi-colon, comma and white space. If there is a need to place such data in the name or value, some encoding method such as URL style %XX encoding is recommended, though no encoding is defined or required. And so with URLEncoding this thing finally works! But I'd say that BASE64 is a bug in Sun's and Tomcat's javadocs. And maybe also Tomcat should be able to handle such values without throwing an exception... Tell me I'm wrong, or go fix the javadocs! References: http://java.sun.com/j2ee/sdk_ 1.3/techdocs/api/javax/servlet/http/Cookie.html#setValue(java.lang.String) http://jakarta.apache.org/tomcat/tomcat-4.0- doc/servletapi/javax/servlet/http/Cookie.html#setValue(java.lang.String) http://wp.netscape.com/newsref/std/cookie_spec.html -- Antti Rauramo Index Information Technologies [EMAIL PROTECTED] +358-40-5190209 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat/src/native/mod_jserv jserv.h jserv_ajpv11.cjserv_ajpv12.c jserv_balance.c mod_jserv.c
[EMAIL PROTECTED] wrote: costin 2002/09/30 13:51:11 Modified:src/native/mod_jserv jserv.h jserv_ajpv11.c jserv_ajpv12.c jserv_balance.c mod_jserv.c Log: Update the workspace with various fixes from java-jserv. Revision ChangesPath 1.2 +2 -2 jakarta-tomcat/src/native/mod_jserv/jserv.h It seems costin started to move remaining jserv code to tc 3.3.x. Could you send us notice when everything could be moved to jtc, in jserv (next to jk/webapp). Regards -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: tomcat 3.3.2 cleanup
Henri Gomez wrote: Costin Manolache wrote: Henri Gomez wrote: Costin Manolache wrote: Henri Gomez wrote: If everybody agree, what about removing src/native for tomcat 3.3.2 ? +1 Yes or no ? Actually, another way is to move mod_jserv in j-t-c, and remove src/native completely. It seems a good idea, should we get mod_jserv from tc 3.3 cvs or from jserv repository ? We _have_ to merge them so it does not matter. I would prefer java-jserv since it has my BS2000 changes. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] JK2 2.1
General: [+0] Drop HAS_APR flags and dissalow building of JK2 without APR [ ] Keep everything like it is (the rest doesn't interests me) Regular expressions: [ ] Add pcre from httpd-2.0 to the common/pcre [ ] Add pcre from httpd-2.0 to the srclib/pcre [+1] Wait if pcre ever comes to the apr-util Noone looks against it in apr-util. I have to find time to do it. Pools: [+0] Use the real apr_pool_t. [] Keep the jk_pool_apr wrapper renaming it to the jk_pool Sockets: [+0] Use only apr_socket and drop the socket, renaming apr to socket. [ ] Keep supporting socket. File I/O: [+1] Use the APR for file i/o replacing stdio/stdlib calls [ ] Keep the old fopen/fwrite/etc... code Static buildings: [+1] Enable Static/Dynamic APR builds of JK2 for non-Apache2 connectors [-1] Enable only dynamic builds I am not sure that all the platforms I have could run with a dynamic linked APR Cheers Jean-frederic -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: THE SOURCE, LUKE: JBoss/Tomcat Mystery
On Mon, 30 Sep 2002, micael wrote: Date: Mon, 30 Sep 2002 23:07:58 -0700 From: micael [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: THE SOURCE, LUKE: JBoss/Tomcat Mystery Below is the source index.html I am getting when I access tomcat in the embedded JBoss/Tomcat server. This index.html, so far as I can tell is nowhere in the application. It is not the ROOT index.html. I can take the ROOT index.html and every other index.html I can find on the site out and it still runs. Where in holy hannah is this? That is crazy, but I have done a lot of internet coding and this is a real puzzler to me. Where is the following coming from: Since this problem only seens to appear with the JBoss integration, I'd suggest asking about problems like this on the JBoss mailing lists. Nobody here is going to know anything about how JBoss chose to integrate Tomcat (unless they also happen to be JBoss users), so we have no clue how the JBoss folks have configured the embedded Tomcat installation they are using.. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] JK2 2.1
Even if I agree with using APR in JK 2.1, I think we should first focus on having a stable JK 2.0 before starting thinking about JK 2.1. Branching now since premature. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JK2 Tagged as JK2_2_0_0_rel
Mladen Turk wrote: Jakarta... Size is 401274 bytes Could you sign that if it OK. I forget to update KEYS prior tagging. Where is the source tarball ? URL needed... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: THE SOURCE, LUKE: JBoss/Tomcat Mystery
Okay. I did not know what the problem was until I got the answer, is the reason. (What a mouthful.) I now see it was an integration problem and not a tomcat problem. mea culpa, sorry ladies and gents. At 01:09 AM 10/1/2002 -0700, you wrote: On Mon, 30 Sep 2002, micael wrote: Date: Mon, 30 Sep 2002 23:07:58 -0700 From: micael [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: THE SOURCE, LUKE: JBoss/Tomcat Mystery Below is the source index.html I am getting when I access tomcat in the embedded JBoss/Tomcat server. This index.html, so far as I can tell is nowhere in the application. It is not the ROOT index.html. I can take the ROOT index.html and every other index.html I can find on the site out and it still runs. Where in holy hannah is this? That is crazy, but I have done a lot of internet coding and this is a real puzzler to me. Where is the following coming from: Since this problem only seens to appear with the JBoss integration, I'd suggest asking about problems like this on the JBoss mailing lists. Nobody here is going to know anything about how JBoss chose to integrate Tomcat (unless they also happen to be JBoss users), so we have no clue how the JBoss folks have configured the embedded Tomcat installation they are using.. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JK2 Tagged as JK2_2_0_0_rel
Henri Gomez wrote: Mladen Turk wrote: Jakarta... Size is 401274 bytes Could you sign that if it OK. I forget to update KEYS prior tagging. Where is the source tarball ? URL needed... The only thing I have found is http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/release/v2.0.0/src/jakarta-tomcat-connectors-jk2-2.0.0.tar.gz But: It does not contain configure, therefore it cannot be the release file :-( It also miss a README in the main directory (at least to tell where the sources are). The name of the directory is jakarta-tomcat-connectors-jk2-2.0.0 that is wrong. -- 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 12860] - Cannot access Tomcat Administration context because struts error
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=12860. 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=12860 Cannot access Tomcat Administration context because struts error --- Additional Comments From [EMAIL PROTECTED] 2002-10-01 08:36 --- Just for the record... I've tried jakarta-tomcat-4.1.11-LE-jdk14.zip and it works. But jakarta-tomcat-4.1.11-LE-jdk14.tar.gz fails on Windows 2000. I think binaries should be the same whatever the compression method used (zip or tar.gz). But it seems it's not!!! What's the diference between zip and tar.gz distribution??? ;-) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: JK2 Tagged as JK2_2_0_0_rel
Configure ? Know what it is, but has no tools to create one... README ? We need to create one or not and put in in the cvs. -Original Message- From: jean-frederic clere The name of the directory is jakarta-tomcat-connectors-jk2-2.0.0 that is wrong. What would be the correct one? MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] JK2 2.1
-Original Message- From: Henri Gomez Even if I agree with using APR in JK 2.1, I think we should first focus on having a stable JK 2.0 before starting thinking about JK 2.1. That's good one :). I agree with that, but would like to make the load balancer to have a timeout connection-recovery option, cause that's the only way to have JK2 serve more then 5 concurent connections (depending on the system performance), and to be 'stable' or even 'usable'. Just don't wish to write the same thing twice... Branching now since premature. Why? MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] JK2 2.1
Mladen Turk wrote: -Original Message- From: Henri Gomez Even if I agree with using APR in JK 2.1, I think we should first focus on having a stable JK 2.0 before starting thinking about JK 2.1. That's good one :). As I said it's premature to discuss what should be in JK 2.1 until JK 2.0 is in a stable state. JK2 will be adopted by users if they saw that it's both stable and as a regular release rate. Many sites won't use JK2 until it became an Apache release, which has allways been a proof of quality. So my recommandation, we'll be to finish JK 2.0, before thinking to JK 2.1 I agree with that, but would like to make the load balancer to have a timeout connection-recovery option, cause that's the only way to have JK2 serve more then 5 concurent connections (depending on the system performance), and to be 'stable' or even 'usable'. Just don't wish to write the same thing twice... Branching now since premature. Why? - fixing bugs in 2 branches is a nigthmare. - confusion for users when they'll see a stable 1.2.0, a beta 2.0 and a dev 2.1. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] JK2 2.1
De: Mladen Turk [mailto:[EMAIL PROTECTED]] Enviado el: 1 de octubre de 2002 9:16 Althought i agree with the overall goals for a 2.1 release ( i should say they are nor very ambitious for point release), i agree with Henri too in the comments he mades, is a bit premature to open a 2.1 relase, without even have finished our current release, just now support users is very very cumbersome, and adding another item to our support bag, can only make this worse.. And i agree with Henri also ( and i dont understand your writing it twice argument ) that to open a Branch right now, is another development nightmare.. Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 bldjk.qcsrc
hgomez 2002/10/01 03:35:10
Modified:jk/native/apache-2.0 bldjk.qcsrc
Log:
Fix misc errors CL
Revision ChangesPath
1.3 +4 -3 jakarta-tomcat-connectors/jk/native/apache-2.0/bldjk.qcsrc
Index: bldjk.qcsrc
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/bldjk.qcsrc,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- bldjk.qcsrc 30 Sep 2002 15:43:37 - 1.2
+++ bldjk.qcsrc 1 Oct 2002 10:35:10 - 1.3
@@ -97,7 +97,7 @@
INCDIR('/home/apache/jk/native/common' +
'/QIBM/ProdData/HTTPA/Include')
-CRTCMOD MODULE(MOD_JK/JNI_WORKER) +
+CRTCMOD MODULE(MOD_JK/JK_JNI_WOR) +
SRCSTMF('/home/apache/jk/native/common/jk_jni_worker.c') +
DEFINE('AS400' 'HAVE_JNI' 'OS400_JVM_12' 'USE_APACHE_MD5') +
TEXT('jk_jni_worker.c') +
@@ -105,8 +105,9 @@
LANGLVL(*ANSI) +
TGTCCSID(*JOB) +
OPTION(*LOGMSG )+
-INCDIR('/home/apache/jk/native/common')
-
+INCDIR('/home/apache/jk/native/common' +
+ '/QIBM/ProdData/HTTPA/Include')
+
CRTCMOD MODULE(MOD_JK/JK_LB_WORK) +
SRCSTMF('/home/apache/jk/native/common/jk_lb_worker.c') +
DEFINE('AS400' 'HAVE_JNI' 'USE_APACHE_MD5') +
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_global.h
hgomez 2002/10/01 03:41:50 Modified:jk/native/common jk_global.h Log: iSeries need USE_VSPRINTF and USE_SPRINTF Revision ChangesPath 1.24 +2 -2 jakarta-tomcat-connectors/jk/native/common/jk_global.h Index: jk_global.h === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_global.h,v retrieving revision 1.23 retrieving revision 1.24 diff -u -r1.23 -r1.24 --- jk_global.h 30 Sep 2002 15:40:18 - 1.23 +++ jk_global.h 1 Oct 2002 10:41:49 - 1.24 @@ -213,7 +213,7 @@ #define vsnprintf _vsnprintf #endif -#ifdef NETWARE +#if defined(NETWARE) || defined(AS400) #define USE_SPRINTF #define USE_VSPRINTF #endif -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_version.h
hgomez 2002/10/01 03:45:57 Modified:jk/native/common jk_version.h Log: Set version to mod_jk 1.2.1 beta Revision ChangesPath 1.4 +3 -3 jakarta-tomcat-connectors/jk/native/common/jk_version.h Index: jk_version.h === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_version.h,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- jk_version.h 13 Oct 2001 17:36:36 - 1.3 +++ jk_version.h 1 Oct 2002 10:45:57 - 1.4 @@ -68,13 +68,13 @@ #define JK_VERMAJOR 1 #define JK_VERMINOR 2 #define JK_VERFIX 0 -#define JK_VERSTRING1.2.0 +#define JK_VERSTRING1.2.1 /* 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_jk/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JK 1.2.1-beta
I started the JK 1.2.1 beta since I discovered many problems in iSeries build which will make necessary a JK 1.2.1 release to support iSeries. BTW, while working on JNI support in iSeries i saw many suspects area, in making pointer - int - jlong which make me think that JNI is jk 1.2.1 need a serious review. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 bldjk.qcsrc
hgomez 2002/10/01 04:01:30 Modified:jk/native/apache-2.0 bldjk.qcsrc Log: mod_jk module missing in CRTSRVPGM Revision ChangesPath 1.4 +2 -1 jakarta-tomcat-connectors/jk/native/apache-2.0/bldjk.qcsrc Index: bldjk.qcsrc === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/bldjk.qcsrc,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- bldjk.qcsrc 1 Oct 2002 10:35:10 - 1.3 +++ bldjk.qcsrc 1 Oct 2002 11:01:30 - 1.4 @@ -208,7 +208,8 @@ '/QIBM/ProdData/HTTPA/Include') CRTSRVPGM SRVPGM(MOD_JK/MOD_JK) + - MODULE(MOD_JK/JK_AJP_COM MOD_JK/JK_AJP12_W + + MODULE(MOD_JK/MOD_JK + + MOD_JK/JK_AJP_COM MOD_JK/JK_AJP12_W + MOD_JK/JK_AJP13 MOD_JK/JK_AJP13_W + MOD_JK/JK_AJP14 MOD_JK/JK_AJP14_W + MOD_JK/JK_CONNECT MOD_JK/JK_CONTEXT + -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] JK2 2.1
-Original Message- From: Ignacio J. Ortega And i agree with Henri also ( and i dont understand your writing it twice argument ) that to open a Branch right now, is another development nightmare.. Well, didn't think that it would require a new branch. Ok, can we at least agree to the following. 1. Apache2 uses APR 2. IIS uses APR 3. Apache1 can use the APR. Or to be specific: There is only one build configuration right now that doesn't necessary need the APR, but is crippled to use only the socket connector. My question is that make sense? You may name the version whatever you like 2.1.0 or 2.0.1, doesn't matter at all to me, but simply drop the option to build without APR. Would It be such a big step forward to open a new branch, I don't think so. MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] JK2 2.1
Well, didn't think that it would require a new branch. Ok, can we at least agree to the following. 1. Apache2 uses APR 2. IIS uses APR 3. Apache1 can use the APR. Did iPlanet/NES could use APR on Netware, I'm waiting for Mike Anderson advices. Also we should be very carefull with APR since APR standalone is 0.9.1 and the one bundled with Apache 2.0.42 report to be 0.9.2. I allready worked on providing apr and apr-utils as standalone shared libs, which could be used with Apache 1.3 under Linux for example, but we should know which configure flags should be use, ie --enable-threads or --without-threads since Apache 1.3 is non threaded on at least Linux platforms. Or to be specific: There is only one build configuration right now that doesn't necessary need the APR, but is crippled to use only the socket connector. My question is that make sense? You may name the version whatever you like 2.1.0 or 2.0.1, doesn't matter at all to me, but simply drop the option to build without APR. We speaked about use of APR in JK2 many times in the past, take a look at tomcat-dev mailing list archive. Making APR mandatory for JK2 was never planned for 2.0 but for 2.1, which will be a whole different story. Would It be such a big step forward to open a new branch, I don't think so. It's really a nightmare to manage 2 differents branches at the same time and port/backport fixes in two branches. That was the case for JK when living in Tomcat 3.2.x and 3.3.x repositories, it's also the case for Tomcat 4.0.x and 4.1.x. One of the goal when I started jakarta-tomcat-connectors was to remove the duplicate works in jk TC 3.2/3.3 and I really against seeing the same on JK2 in JTC. I wonder what's the problem using #idef HAVE_APR in JK2 today ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: JSP Compilation Issues (Multiple Domains)
Can we get the sync changes in the 4.1.x releases as we also have problems with this and currently maintain our own jasper code base with the sync code in it. -Original Message- From: Kin-Man Chung [mailto:[EMAIL PROTECTED]] Sent: Monday, September 30, 2002 9:47 PM To: [EMAIL PROTECTED] Subject: Re: JSP Compilation Issues (Multiple Domains) If you are using JDK javac for compiling the servlet generated by the JSP compiler, then you probably ran into the problem that the javac not being thread-safe. In Tomcat 5 the javac compilation is synchronized, so that the compilation is serialized. Guess that fix is not ported to 4.1.5. :-( I always assume that JSP pages would be deployed precompiled, and simultaneous compilation under development mode is rare. Maybe my assumption is wrong? Date: Mon, 30 Sep 2002 18:30:48 -0700 From: Joseph Kiok [EMAIL PROTECTED] Subject: JSP Compilation Issues (Multiple Domains) To: [EMAIL PROTECTED] X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600. X-Priority: 3 X-MSMail-priority: Normal Hi All, I'm currently running multiple domains (2 specifically) on top of Apache/Tomcat. It seems that when I hit both domains at the same time (using 2 browser windows), I get a JSP compilation error most (85%) of the time. However, when I reload the page with no JSP code change, it'll compile properly. (Some of the time like 10-15%, it won't recompile until I touch the file manually) Note: It doesn't happen when I only access one domain. PROBLEM SUMMARY: When loading JSPs on multiple domains (hosts) simultaneously, a JSP compile error is generated. SYSTEM COMPONENTS: - Solaris 2.8 - JDK 1.4.0_01 - Tomcat 4.1.12 - Apache 1.3.20 SOLUTIONS TRIED (FAILED): - Configured different workers for each domains (hosts) as recommended in the tomcat mod_jk document. - Downloaded the source of tomcat and recompiled everything on our environment. Any help would be appreciated. Thanks. Best regards, Joseph Kiok -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2 README.txt
mturk 2002/10/01 04:56:39 Added: jk/native2 README.txt Log: Add the README to the jk2. Revision ChangesPath 1.1 jakarta-tomcat-connectors/jk/native2/README.txt Index: README.txt === README for JK2 -- The newest JK2 is a rewrite of JK. The native part has been completly restructured and the configuration has been simplified a lot. Even if it works with Apache 1.3, JK2 has been developed with Apache 2.0 in mind, and thus is better suited for multi-threaded servers like IIS, NES/iPlanet. JK2 has a better separation between protocol and physical layer. As such JK2 support fast unix-socket, and could be extended to support others communications channels. Better it's suited for JNI and JDK 1.4 fast IO APIs. How to obtain the JK2 and Apache Portable Runtime sources: -- NOTE: If you downloaded a source distribution from our website or a mirror (the file is called jakarta-tomcat-connectors-jk2-X.X.X.src.tar.gz) you don't need to obtain any other file. Please follow this chapter only if you want to obtain the latest CVS version of the sources. Check out the module sources from CVS using the following commands: cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic login (Logging in to [EMAIL PROTECTED]) CVS password: anoncvs cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic \ checkout jakarta-tomcat-connectors Once CVS downloads the jakarta-tomcat-connectors module sources, we need to download the APR (Apache Portable Runtime) sources. To do this simply use a release version of APR: - You can download it from http://www.apache.org/dist/apr/. - The file is called the file is apr-X.X.X.tar.gz You will also need the APR-UTIL (a companion library to APR). To do this simply use a release version of APR: - You can download it from http://www.apache.org/dist/apr/. - The file is called the file is apr-util-X.X.X.tar.gz When the APR sources are in place, we need to create the configure scripts. It is done by running the command: ./support/buildconf.sh WARNING: - The JK2 should be considered initial-release quality code. It has not been subjected to the same stresses on its stability and security that the mod_jk releases have enjoyed, so there is a greater possibility of undiscovered vulnerabilities to stability or security. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Antwort: Re: administration web, struts-config.xml
Hi I just found out that I can't change the forward Roles List Setup directly to listRoles.jsp because the form bean 'rolesForm' is not set yet. I have to change the UsersTreeBuilder.java to get rid of the additional Forwarding. It's not necessary to forward afterwards again to listRoles (Roles List Setup) because the form bean 'rolesForm' is already instantianted. I've just changed the forward request parameter. TreeControlNode groups = new TreeControlNode (Global Administer Groups, Groups.gif, resources.getMessage(users.treeBuilder.groupsNode), users/listGroups.do?databaseName= + URLEncoder.encode(databaseName) + forward= + URLEncoder.encode(Groups List), content, false); TreeControlNode roles = new TreeControlNode (Global Administer Roles, Roles.gif, resources.getMessage(users.treeBuilder.rolesNode), users/listRoles.do?databaseName= + URLEncoder.encode(databaseName) + forward= + URLEncoder.encode(Roles List), content, false); TreeControlNode users = new TreeControlNode (Global Administer Users, Users.gif, resources.getMessage(users.treeBuilder.usersNode), users/listUsers.do?databaseName= + URLEncoder.encode(databaseName) + forward= + URLEncoder.encode(Users List), content, false); Amy Roh [EMAIL PROTECTED] An: Tomcat Developers List [EMAIL PROTECTED] rg Kopie: Thema: Re: administration web, struts-config.xml 30.09.2002 21:41 Bitte antworten an Tomcat Developers List Oliver Wulff wrote: Hi I use Tomcat 4.10. When I want to show the available roles the ListRolesAction has to be called. I guess that it will be called twice. Here is a snippet of org.apache.webapp.admin.users.UsersTreeBuilder: ... TreeControlNode roles = new TreeControlNode (Global Administer Roles, Roles.gif, resources.getMessage(users.treeBuilder.rolesNode), users/listRoles.do?databaseName= + URLEncoder.encode(databaseName) + forward= + URLEncoder.encode(Roles List Setup), content, false); ... and a snippet of the struts-config.xml: ... forwardname=Roles List path=/users/listRoles.jsp redirect=false/ forwardname=Roles List Setup path=/users/listRoles.do?forward=Roles+List redirect=false/ ... As you can see from the source code the request will be dispatched to Roles List Setup which is again listRoles.do. Does that make sense? It still works if I define the Roles List Setup like this: forwardname=Roles List Setup path=/users/listRoles.jsp redirect=false/ This is the same as the above Roles List Setup definition since listRoles.do?forward=Roles+List calls listRoles.jsp. So it doesn't matter whether you use forward Roles List or to call directly listRoles.jsp since Roles List forwards to listRoles.jsp. Amy Regards Oliver *** BITTE BEACHTEN *** Diese Nachricht (wie auch allfällige Anhänge dazu) beinhaltet möglicherweise vertrauliche oder gesetzlich geschützte Daten oder Informationen. Zum Empfang derselben ist (sind) ausschliesslich die genannte(n) Person(en) bestimmt. Falls Sie diese Nachricht irrtümlicherweise erreicht hat, sind Sie höflich gebeten, diese unter Ausschluss jeder Reproduktion zu zerstören und
RE: [VOTE] JK2 2.1
-Original Message- From: Henri Gomez We speaked about use of APR in JK2 many times in the past, take a look at tomcat-dev mailing list archive. Know that, but often people change opinions, you cannot blame to occasionally put that back on ;) Making APR mandatory for JK2 was never planned for 2.0 but for 2.1, which will be a whole different story. Would It be such a big step forward to open a new branch, I don't think so. It's really a nightmare to manage 2 differents branches at the same time Think you miss me. Things like using APR as mandatory reflects only the build procedure, and IMO doesn't require a new branch. I even didn't think that 2.1 needs to be a new branch (3.0 perhaps). The new branch needs to be technologically different to be a new branch thought, and see no reason why the 2.0.3 wouldn't be with the APR boundled in. But if the rest of community think it does, I'll 'Adopt'. I wonder what's the problem using #idef HAVE_APR in JK2 today ? None really (except that its messy), but you can find things like that even inside the code that can be used only in the APR supported connectors. But, as I said, I can Adopt ;) MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13172] New: - Port incorrect in getServerPort and in access log
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=13172. 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=13172 Port incorrect in getServerPort and in access log Summary: Port incorrect in getServerPort and in access log Product: Tomcat 4 Version: Unknown Platform: Sun OS/Version: Solaris Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When protocol is http, getServerPort returns 80 even when port is 8080. When protocol is https, getServerPort returns 443 even when port is 6443. I also notice this in logs. This is for version 4.0.5 and does not occur in 4.0.4 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13173] New: - NPE thrown by ELException.toString() if not originally created with a root cause exception.
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=13173. 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=13173 NPE thrown by ELException.toString() if not originally created with a root cause exception. Summary: NPE thrown by ELException.toString() if not originally created with a root cause exception. Product: Tomcat 5 Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Jasper2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Given: ELException ele = new ELException(); String str = ele.toString(). Resulting stacktrace: java.lang.NullPointerException [java] at javax.servlet.jsp.el.ELException.toString(ELException.java:139) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JK 1.2.1-beta
Hi Henri, I would like to propose one change before the JK 1.2.1 release. I have noticed that on tomcat-user there are questions like: What do these mod_jk.log entries mean? There are some common problems which can happen using mod_jk in production which generate error messages which are great for those debugging C code but are difficult for those using mod_jk in production to understand. Here are some examples of common errors reported on a production system. [Mon May 13 04:08:46 2002] [jk_ajp_common.c (933)]: Error ajp_process_callback - write failed This really means that the remote browser client aborted the HTTP request. This can happen when Tomcat is overloaded and request latency increases significantly. [Mon May 13 07:44:41 2002] [jk_uri_worker_map.c (595)]: In jk_uri_worker_map_t::map_uri_to_worker, wrong parameters Not sure what this means, I would have to go back and review the code again. [Mon May 13 11:38:27 2002] [jk_ajp_common.c (652)]: ajp_connection_tcp_get_message: Error - jk_tcp_socket_recvfull failed [Mon May 13 11:38:27 2002] [jk_ajp_common.c (1013)]: Error reading reply [Mon May 13 11:38:27 2002] [jk_ajp_common.c (1150)]: In jk_endpoint_t::service, ajp_get_reply failed in send loop 0 This means that all of Tomcats AjpProcessor's are in use and Tomcat rejected the connection. i.e. Tomcat is overloaded or the Connector maxProcessors needs to be increased. But you get a series of three errors rather than one human readable error. [Mon May 13 11:38:33 2002] [jk_connect.c (151)]: jk_open_socket, connect() failed errno = 146 [Mon May 13 11:38:33 2002] [jk_ajp_common.c (599)]: In jk_endpoint_t::ajp_connect_to_endpoint, failed errno = 146 [Mon May 13 11:38:33 2002] [jk_ajp_common.c (844)]: Error connecting to the Tomcat process. This means that the Tomcat AjpConnector socket isn't open. This at least ends up with an error that may help someone diagnose the problem. But you do end up with three error messages rather than just one. Trying to interpret these error messages is a common question on tomcat-user. My proposal: 1. Change these errors messages so that they accurately identify what happened. 2. For these common errors only report one error rather than a series of three. 3. Add documentation to the mod_jk docs about what these errors mean. Regards, Glenn Henri Gomez wrote: I started the JK 1.2.1 beta since I discovered many problems in iSeries build which will make necessary a JK 1.2.1 release to support iSeries. BTW, while working on JNI support in iSeries i saw many suspects area, in making pointer - int - jlong which make me think that JNI is jk 1.2.1 need a serious review. -- 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: JSP Compilation Issues (Multiple Domains)
Another way to fix this would be to install the external compiler jikes and configure Jasper 2 to use this. I would also like to see a servlet init parameter added to jasper that can enable or disable synchronized JSP compiles. This way those who know they have a thread safe way to compile JSP's don't get hit by the synchronize. Regards, Glenn John Trollinger wrote: Can we get the sync changes in the 4.1.x releases as we also have problems with this and currently maintain our own jasper code base with the sync code in it. -Original Message- From: Kin-Man Chung [mailto:[EMAIL PROTECTED]] Sent: Monday, September 30, 2002 9:47 PM To: [EMAIL PROTECTED] Subject: Re: JSP Compilation Issues (Multiple Domains) If you are using JDK javac for compiling the servlet generated by the JSP compiler, then you probably ran into the problem that the javac not being thread-safe. In Tomcat 5 the javac compilation is synchronized, so that the compilation is serialized. Guess that fix is not ported to 4.1.5. :-( I always assume that JSP pages would be deployed precompiled, and simultaneous compilation under development mode is rare. Maybe my assumption is wrong? Date: Mon, 30 Sep 2002 18:30:48 -0700 From: Joseph Kiok [EMAIL PROTECTED] Subject: JSP Compilation Issues (Multiple Domains) To: [EMAIL PROTECTED] X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600. X-Priority: 3 X-MSMail-priority: Normal Hi All, I'm currently running multiple domains (2 specifically) on top of Apache/Tomcat. It seems that when I hit both domains at the same time (using 2 browser windows), I get a JSP compilation error most (85%) of the time. However, when I reload the page with no JSP code change, it'll compile properly. (Some of the time like 10-15%, it won't recompile until I touch the file manually) Note: It doesn't happen when I only access one domain. PROBLEM SUMMARY: When loading JSPs on multiple domains (hosts) simultaneously, a JSP compile error is generated. SYSTEM COMPONENTS: - Solaris 2.8 - JDK 1.4.0_01 - Tomcat 4.1.12 - Apache 1.3.20 SOLUTIONS TRIED (FAILED): - Configured different workers for each domains (hosts) as recommended in the tomcat mod_jk document. - Downloaded the source of tomcat and recompiled everything on our environment. Any help would be appreciated. Thanks. Best regards, Joseph Kiok -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: JSP Compilation Issues (Multiple Domains)
+1 to the sync option -Original Message- From: Glenn Nielsen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 01, 2002 9:45 AM To: Tomcat Developers List Subject: Re: JSP Compilation Issues (Multiple Domains) Another way to fix this would be to install the external compiler jikes and configure Jasper 2 to use this. I would also like to see a servlet init parameter added to jasper that can enable or disable synchronized JSP compiles. This way those who know they have a thread safe way to compile JSP's don't get hit by the synchronize. Regards, Glenn John Trollinger wrote: Can we get the sync changes in the 4.1.x releases as we also have problems with this and currently maintain our own jasper code base with the sync code in it. -Original Message- From: Kin-Man Chung [mailto:[EMAIL PROTECTED]] Sent: Monday, September 30, 2002 9:47 PM To: [EMAIL PROTECTED] Subject: Re: JSP Compilation Issues (Multiple Domains) If you are using JDK javac for compiling the servlet generated by the JSP compiler, then you probably ran into the problem that the javac not being thread-safe. In Tomcat 5 the javac compilation is synchronized, so that the compilation is serialized. Guess that fix is not ported to 4.1.5. :-( I always assume that JSP pages would be deployed precompiled, and simultaneous compilation under development mode is rare. Maybe my assumption is wrong? Date: Mon, 30 Sep 2002 18:30:48 -0700 From: Joseph Kiok [EMAIL PROTECTED] Subject: JSP Compilation Issues (Multiple Domains) To: [EMAIL PROTECTED] X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600. X-Priority: 3 X-MSMail-priority: Normal Hi All, I'm currently running multiple domains (2 specifically) on top of Apache/Tomcat. It seems that when I hit both domains at the same time (using 2 browser windows), I get a JSP compilation error most (85%) of the time. However, when I reload the page with no JSP code change, it'll compile properly. (Some of the time like 10-15%, it won't recompile until I touch the file manually) Note: It doesn't happen when I only access one domain. PROBLEM SUMMARY: When loading JSPs on multiple domains (hosts) simultaneously, a JSP compile error is generated. SYSTEM COMPONENTS: - Solaris 2.8 - JDK 1.4.0_01 - Tomcat 4.1.12 - Apache 1.3.20 SOLUTIONS TRIED (FAILED): - Configured different workers for each domains (hosts) as recommended in the tomcat mod_jk document. - Downloaded the source of tomcat and recompiled everything on our environment. Any help would be appreciated. Thanks. Best regards, Joseph Kiok -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Ping: sources for jsp2el.jar !
The sources for jsp20el.jar are from the JSTL project. There's a special build target there that produeces this JAR. We're doing this until the EL gets its own project at jakarta-commons or such. Shawn Bayern should be able to help answer any questions in this area. - Mark Costin Manolache wrote: It seems Justyna was the last person to access the file, and Remy was the first. If anyone knows where are the sources for that jar - please let me know. ( or just check them in ). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JK 1.2.1-beta
Glenn Nielsen wrote: Hi Henri, I would like to propose one change before the JK 1.2.1 release. I have noticed that on tomcat-user there are questions like: What do these mod_jk.log entries mean? There are some common problems which can happen using mod_jk in production which generate error messages which are great for those debugging C code but are difficult for those using mod_jk in production to understand. Here are some examples of common errors reported on a production system. [Mon May 13 04:08:46 2002] [jk_ajp_common.c (933)]: Error ajp_process_callback - write failed This really means that the remote browser client aborted the HTTP request. This can happen when Tomcat is overloaded and request latency increases significantly. [Mon May 13 07:44:41 2002] [jk_uri_worker_map.c (595)]: In jk_uri_worker_map_t::map_uri_to_worker, wrong parameters Not sure what this means, I would have to go back and review the code again. [Mon May 13 11:38:27 2002] [jk_ajp_common.c (652)]: ajp_connection_tcp_get_message: Error - jk_tcp_socket_recvfull failed [Mon May 13 11:38:27 2002] [jk_ajp_common.c (1013)]: Error reading reply [Mon May 13 11:38:27 2002] [jk_ajp_common.c (1150)]: In jk_endpoint_t::service, ajp_get_reply failed in send loop 0 This means that all of Tomcats AjpProcessor's are in use and Tomcat rejected the connection. i.e. Tomcat is overloaded or the Connector maxProcessors needs to be increased. But you get a series of three errors rather than one human readable error. [Mon May 13 11:38:33 2002] [jk_connect.c (151)]: jk_open_socket, connect() failed errno = 146 [Mon May 13 11:38:33 2002] [jk_ajp_common.c (599)]: In jk_endpoint_t::ajp_connect_to_endpoint, failed errno = 146 [Mon May 13 11:38:33 2002] [jk_ajp_common.c (844)]: Error connecting to the Tomcat process. This means that the Tomcat AjpConnector socket isn't open. This at least ends up with an error that may help someone diagnose the problem. But you do end up with three error messages rather than just one. Trying to interpret these error messages is a common question on tomcat-user. My proposal: 1. Change these errors messages so that they accurately identify what happened. 2. For these common errors only report one error rather than a series of three. 3. Add documentation to the mod_jk docs about what these errors mean. Good idea, who's candidate ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/conf catalina.policy
Hi Glenn, your last addition seems, IMO, to open a security isssue with classes located under the o.a.c.util directory. Actually, maybe not for Tomcat 4.1, but for 5.0, I have created a class called SecurityAudit.java that contains some security check. If we port your latest changes, this class will be exposed to malicious uses. Also, Is there a reason why we are giving the defineClassInPackage? I think two solutions are available (1) move sensitive classes to another package (2) create a public package where we want to give access to some internal class. What is your recommendation? Thanks, -- Jeanfrancois [EMAIL PROTECTED] wrote: glenn 2002/09/30 12:59:47 Modified:catalina/src/conf catalina.policy Log: Allow defineClassInPackage for util due to Request Parametermap needs Revision ChangesPath 1.28 +3 -1 jakarta-tomcat-4.0/catalina/src/conf/catalina.policy Index: catalina.policy === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/catalina.policy,v retrieving revision 1.27 retrieving revision 1.28 diff -u -r1.27 -r1.28 --- catalina.policy 8 Sep 2002 18:04:02 - 1.27 +++ catalina.policy 30 Sep 2002 19:59:47 - 1.28 @@ -121,6 +121,8 @@ // Required for sevlets and JSP's permission java.lang.RuntimePermission accessClassInPackage.org.apache.catalina.util; permission java.lang.RuntimePermission accessClassInPackage.org.apache.catalina.util.*; + permission java.lang.RuntimePermission defineClassInPackage.org.apache.catalina.util; + permission java.lang.RuntimePermission defineClassInPackage.org.apache.catalina.util.*; // Required for running servlets generated by JSPC permission java.lang.RuntimePermission accessClassInPackage.org.apache.jasper.runtime; -- 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 13172] - Port incorrect in getServerPort and in access log
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=13172. 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=13172 Port incorrect in getServerPort and in access log [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/conf catalina.policy
Right, there are no security sensitive classes in Tomcat 4 o.a.c.util. I advocated at one time identifying which packages within o.a.c contain security sensitive code and which don't. And documenting this so that a security sensitive class doesn't get added to a package considered public. For starters, o.a.c.util could be identified as a package where no security sensitive classes can be located. And with JSR 115 incorporating JAAS into J2EE, perhaps it would be best to have a o.a.c.security package. Regards, Glenn Jean-Francois Arcand wrote: Hi Glenn, your last addition seems, IMO, to open a security isssue with classes located under the o.a.c.util directory. Actually, maybe not for Tomcat 4.1, but for 5.0, I have created a class called SecurityAudit.java that contains some security check. If we port your latest changes, this class will be exposed to malicious uses. Also, Is there a reason why we are giving the defineClassInPackage? I think two solutions are available (1) move sensitive classes to another package (2) create a public package where we want to give access to some internal class. What is your recommendation? Thanks, -- Jeanfrancois [EMAIL PROTECTED] wrote: glenn 2002/09/30 12:59:47 Modified:catalina/src/conf catalina.policy Log: Allow defineClassInPackage for util due to Request Parametermap needs Revision ChangesPath 1.28 +3 -1 jakarta-tomcat-4.0/catalina/src/conf/catalina.policy Index: catalina.policy === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/catalina.policy,v retrieving revision 1.27 retrieving revision 1.28 diff -u -r1.27 -r1.28 --- catalina.policy8 Sep 2002 18:04:02 -1.27 +++ catalina.policy30 Sep 2002 19:59:47 -1.28 @@ -121,6 +121,8 @@ // Required for sevlets and JSP's permission java.lang.RuntimePermission accessClassInPackage.org.apache.catalina.util; permission java.lang.RuntimePermission accessClassInPackage.org.apache.catalina.util.*; + permission java.lang.RuntimePermission defineClassInPackage.org.apache.catalina.util; + permission java.lang.RuntimePermission defineClassInPackage.org.apache.catalina.util.*; // Required for running servlets generated by JSPC permission java.lang.RuntimePermission accessClassInPackage.org.apache.jasper.runtime; -- 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]
jk 1.2.0 error reported on tomcat-user
Someone has an idea of what could be the problem with ap_ctx-get ? It seems the user make use of ApacheToolbox. - This may add some info: I compiled Apache with ApacheToolbox. The modules are static but it has DSO support in it. Then again, I would expect an error much earlier in the load process then an undefined symbol. - I downloaded the binary of mod_jk.so from Jakarta's downloads in /builds/jakarta-tomcat-connectors/jk/release/v1.2.0/bin/linux/i386. I am running Apache 1.3.26 with Tomcat 4.05 on Red Hat Linux release 7.1 (Seawolf). The binary is compiled for 7.2, however. That may explain the following error when trying to start Apache: [root@dev bin]# ./apachectl configtest Syntax error on line 208 of /usr/local/apache-new/conf/httpd.conf: Cannot load /usr/local/apache-new/libexec/mod_jk.so into server: /usr/local/apache-new/libexec/mod_jk.so: undefined symbol: ap_ctx_get Any ideas? Do I need to upgrade gcc, possibly? What do the binaries rely upon? Thanks in advance, Ben Ricker -- Ben Ricker [EMAIL PROTECTED] Wellinx.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
mod_webapp for Apache 2, Win32
Hello, I'd like to setup Apache 2.0.42 + TomCat 4.1 with mod_webapp on Win NT. I found mod_webapp binary for Apache 1.3. It works fine. But Apache 2 requires another mod_webapp binary. I failed to find it on ASF web sites. I found only sources. I've downloaded jakarta-tomcat-connectors-4.1.12-src.zip. It contains readme.txt with following text: NO, IT DOES NOT RUN WITH WINDOWS (your images don't appear and the whole thing hangs?) AND SINCE I DON'T USE NEITHER POSSESS A MICROSOFT WINDOWS BASED MACHINE, THERE ARE NO CURRENT PLANS ON MAKING IT WORK OVER THERE (from my side). Does it mean that it cannot be compiled for Win NT? Or it means that mod_webapp can be compiled for Win NT, but it will work unstable? I tried to compile mod_webapp with Apache 2 sources. Compilation was successful. Only linking errors remained: mod_webapp.obj : error LNK2001: unresolved external symbol _wa_pool mod_webapp.obj : error LNK2001: unresolved external symbol _wa_cconnection mod_webapp.obj : error LNK2001: unresolved external symbol _wa_init mod_webapp.obj : error LNK2001: unresolved external symbol _wa_deploy mod_webapp.obj : error LNK2001: unresolved external symbol _wa_capplication mod_webapp.obj : error LNK2001: unresolved external symbol _wa_cvirtualhost mod_webapp.obj : error LNK2001: unresolved external symbol _wa_startup mod_webapp.obj : error LNK2001: unresolved external symbol _wa_shutdown mod_webapp.obj : error LNK2001: unresolved external symbol _wa_rfree mod_webapp.obj : error LNK2001: unresolved external symbol _wa_rinvoke mod_webapp.obj : error LNK2001: unresolved external symbol _wa_ralloc mod_webapp.obj : error LNK2001: unresolved external symbol _apr_filename_of_pathname Could smb. give me a hint how can I overcome this? Or may be smb. could let me know where can I get mod_webapp binary for Apache 2? In the Internet I found a lot of similar questions. Many people want to get mod_webapp for Apache 2, but nobody can. It would be a good idea to make mod_webapp working under Win32 and put binaries on ASF site. Best regards, Alexander Klimuk ICQ 148557477 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13081] - ScriptingVariableVisitor#setScriptingVars does not account for scriptlet scopes
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=13081. 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=13081 ScriptingVariableVisitor#setScriptingVars does not account for scriptlet scopes --- Additional Comments From [EMAIL PROTECTED] 2002-10-01 16:48 --- See evaluation of 13132 for additional information. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: tomcat 3.3.2 cleanup
Henri Gomez wrote: Costin Manolache wrote: Henri Gomez wrote: Costin Manolache wrote: Henri Gomez wrote: If everybody agree, what about removing src/native for tomcat 3.3.2 ? +1 Yes or no ? Actually, another way is to move mod_jserv in j-t-c, and remove src/native completely. It seems a good idea, should we get mod_jserv from tc 3.3 cvs or from jserv repository ? I would prefer the one in tc3.3. The only difference - few extra comments, a kill_timeout ( which seems right ), and use of 'tomcat' in a name. If you want to use the one in jserv - that's ok too. -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat/src/native/mod_jserv jserv.h jserv_ajpv11.c jserv_ajpv12.c jserv_balance.c mod_jserv.c
Henri Gomez wrote: [EMAIL PROTECTED] wrote: costin 2002/09/30 13:51:11 Modified:src/native/mod_jserv jserv.h jserv_ajpv11.c jserv_ajpv12.c jserv_balance.c mod_jserv.c Log: Update the workspace with various fixes from java-jserv. Revision ChangesPath 1.2 +2 -2 jakarta-tomcat/src/native/mod_jserv/jserv.h It seems costin started to move remaining jserv code to tc 3.3.x. Could you send us notice when everything could be moved to jtc, in jserv (next to jk/webapp). I think this commit included all the remaining differences. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: tomcat 3.3.2 cleanup
jean-frederic clere wrote: Henri Gomez wrote: Costin Manolache wrote: Henri Gomez wrote: Costin Manolache wrote: Henri Gomez wrote: If everybody agree, what about removing src/native for tomcat 3.3.2 ? +1 Yes or no ? Actually, another way is to move mod_jserv in j-t-c, and remove src/native completely. It seems a good idea, should we get mod_jserv from tc 3.3 cvs or from jserv repository ? We _have_ to merge them so it does not matter. I would prefer java-jserv since it has my BS2000 changes. Ok, my 3-rd post on this subject :-) I merged them - now your fixes are in tc3.3 as well, and can be moved to j-t-c. I think j-t-c is the right place for this. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] JK2 2.1
IMO: one of the main goals of jk2 was modularity, i.e. jk2 is composed of components, each component can use and do whatever it likes without affecting the other components. I totally agree that jk2.1 should use APR ( I'll send my vote on each point ) - but I don't think the old code should be removed yet - there's no reason. The only problem is that we'll have to maintain 2 versions - the APR one and the old/original component. But that's a good thing IMO - the old one is already stable and shouldn't be changed except for bug fixes ( in the same way important bug fixes are backported from tomcat5 to 4.1 or from 4.1 to 4.0 ). I am +1 on creating a separate target/makefiles that will exclude the 'old'/non-apr components, or changing the code so that the APR components will be used by default in 2.1. I see no reason to remove components that work well and are tested. And a branch shouldn't be needed - it should be perfectly possible to do whatever we want in the new components. The only thing that needs to be stable for that ( or change in all components ) is the 'object model' ( including configuration, factories, etc ). Right now I'm convinced that a future version of jk2 should either switch to or provide support for NSCOM and COM. Most likely this should be done on top, i.e. add an IDL and a COM factory for each component and use some conditional compilation to make sure that each jk component is compiled as COM on windows, NSCOM if mozilla COM is available ( i.e. on unix ). The only thing that I still need to check is if it is possible to also hook into gnome or kde object models. Costin Mladen Turk wrote: -Original Message- From: Ignacio J. Ortega And i agree with Henri also ( and i dont understand your writing it twice argument ) that to open a Branch right now, is another development nightmare.. Well, didn't think that it would require a new branch. Ok, can we at least agree to the following. 1. Apache2 uses APR 2. IIS uses APR 3. Apache1 can use the APR. Or to be specific: There is only one build configuration right now that doesn't necessary need the APR, but is crippled to use only the socket connector. My question is that make sense? You may name the version whatever you like 2.1.0 or 2.0.1, doesn't matter at all to me, but simply drop the option to build without APR. Would It be such a big step forward to open a new branch, I don't think so. MT. -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] JK2 2.1
Mladen Turk wrote: We speaked about use of APR in JK2 many times in the past, take a look at tomcat-dev mailing list archive. Know that, but often people change opinions, you cannot blame to occasionally put that back on ;) That's right. I totally agree that all new code and features should use APR. But I don't agree ( and I haven't seen any argument/reason ) that we should drop the non-APR components or we shouldn't allow a build without APR. That's pretty simple - the object model doesn't use APR and there's no need to ( there's no or minimal platform-specific code in it ). And the non-apr components are stable and there's no reason to change them. Just create new components. Sometime in future ( say 6 months after jk2.0 release is out ) we can discuss deprecating the old components and maybe after jk2.1 is released we can discuss removing them for jk2.2. Making APR mandatory for JK2 was never planned for 2.0 but for 2.1, which will be a whole different story. It's really a nightmare to manage 2 differents branches at the same time Think you miss me. Things like using APR as mandatory reflects only the build procedure, and IMO doesn't require a new branch. I even didn't think that 2.1 needs to be a new branch (3.0 perhaps). The new branch needs to be technologically different to be a new branch thought, and see no reason why the 2.0.3 wouldn't be with the APR boundled in. But if the rest of community think it does, I'll 'Adopt'. I don't think APR ( or anything else :-) should be 'mandatory'. Recommended - yes, default - yes. But if the 'modularity' and 'component' goals are met, then it should be possible to use any kind of components in the system, including those that don't use APR. And since we already have a (complete and functional ) set of components supporting the minimal features ( i.e. basic socket communication ) - and most of the code is stable ( as it's very close to jk1.x ), I see no reason to remove them or to not allow a build with those components only. If you want cleaner code - just create a new component ( copy the old one for example ), remove HAVE_APR and make it require APR. I wonder what's the problem using #idef HAVE_APR in JK2 today ? None really (except that its messy), but you can find things like that even inside the code that can be used only in the APR supported connectors. But, as I said, I can Adopt ;) No problem with removing the mess - in new components that will be default in 2.1. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Ping: sources for jsp2el.jar !
Mark Roth wrote: The sources for jsp20el.jar are from the JSTL project. There's a special build target there that produeces this JAR. We're doing this until the EL gets its own project at jakarta-commons or such. Ok, I found it. It's basically doing a copy and then replaces the package name in all files. Wow... Since EL is part of JSP2.0 spec I think it's more than justified to make it part of jakarta-tomcat project - or keep it as part of jakarta-taglibs. Or have the EL part in jakarta-commons. But one option should be choosen and pursued - like have a formal vote in jakarta-commons, and if it doesn't pass fall back to a sub-project of either taglibs or tomcat. This hack is just too ugly. Costin Shawn Bayern should be able to help answer any questions in this area. - Mark Costin Manolache wrote: It seems Justyna was the last person to access the file, and Remy was the first. If anyone knows where are the sources for that jar - please let me know. ( or just check them in ). -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] JK2 2.1
Well, what I was yelling about was the core components, like load balancer, uriMap, uriEnv. We can write our own functionality, copy the code from the APR, or something else if faster. These are the components that cannot easily be supported using #idfef HAS_APR #elif MOZILLA #else... So, we need a decision, are we going to use (for example) apr_time_now(), write our own, using #ifdef #else, or what for those core components? Other thing. If we say that core components has to be 'non-mandatory' of any component like apr or nspr or whatever, the code like #ifdef HAS_APR must not be in such a component, or it loose its meaning like component free. And what is component free code (APR doesn't belong to that category, it is more a system abstraction layer like posix). Is it better to use the fopen or apr_file_open? Take a look at one of the 'core components' jk_config_file (the first one that I found): #ifdef AS400 fp = fopen(workerFile, w, o_ccsid=0); #else fp = fopen(workerFile, w); #endif Is this abstractive code enough ;) So... If you wish make some draft about what are the core components, what is 'mandatory' inside them and what is not, so that we know how to write the code for such a component. -Original Message- From: news [mailto:[EMAIL PROTECTED]] On Behalf Of Costin Manolache Sent: Tuesday, October 01, 2002 7:13 PM To: [EMAIL PROTECTED] Subject: RE: [VOTE] JK2 2.1 MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13081] - ScriptingVariableVisitor#setScriptingVars does not account for scriptlet scopes
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=13081.
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=13081
ScriptingVariableVisitor#setScriptingVars does not account for scriptlet scopes
--- Additional Comments From [EMAIL PROTECTED] 2002-10-01 18:21 ---
This problem is mostly unrelated to bug 13132 referenced in the last comment.
This is extremely easy to reproduce and I believe still well within the scope of
the JSP specification. Take for instance a very simple snippet of JSP code:
prefix:outerTag
prefix:innerTag id=x /
prefix:innerTag id=x /
/prefix:outerTag
This snippet will work fine in 4.1.x, but with one minor modification the page
will no longer compile.
prefix:outerTag
% if (true) { %
prefix:innerTag id=x /
% } %
prefix:innerTag id=x /
/prefix:outerTag
We have this in our pages. Even in our pages that are made up almost entirely
of tags, we have conditional statements like this. We feel that they are
REQUIRED because the overhead of the generated code required to invoke a tag is
too high when compared to a simple conditional check such as this.
As long as scriptlets are supported in JSP, this construct should be handled
correctly by Jasper or at least be made to conditionally handle this situation
via a configuration mechanism as I suggest in the original bug comments. I
would be more than willing to put together a patch for this configurable
support, if it would be accepted by the development team. Otherwise, it isn't
worth my time to build a patch and be constantly out of sync with the base
Tomcat codebase.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Streaming content with mod_webapp
Hi! I developped a servlet that outputs straming content (a html chat without reload). On my test machine (using tomcat and the catalina http connector) this works fine. But when I switch to a machie where tomcat ist connected to an apache webserver via mod_webap/warp connector, the streaming doesn't work. The second problem is, that with tomcat/http when the user closes his browser an exception ist thrown. This exception is never thrown with mod_webapp. So there's no way to find out, when the connection was closed and the streaming can be stopped. Is there a solution for that problem or a workaround? Thanks. Michael. __ Gesendet von Yahoo! Mail - http://mail.yahoo.de Möchten Sie mit einem Gruß antworten? http://grusskarten.yahoo.de -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] JK2 2.1
Mladen Turk wrote: Hi, Since there has been general concensus that we should use the APR for every supported API call. Here is my design proposal. General: [ ] Drop HAS_APR flags and dissalow building of JK2 without APR [ ] Keep everything like it is (the rest doesn't interests me) As I said, my option is: [X] Leave the existing components, create all new components based on APR. and make sure plugability works. In future - deprecate the non-apr components after 2.0 is released and default to apr-only components in 2.1, remove non-apr components after 2.1 is released ( i.e. for 2.2 ). I think that maximises the stability of the code. Regular expressions: [ ] Add pcre from httpd-2.0 to the common/pcre [ ] Add pcre from httpd-2.0 to the srclib/pcre [X] Wait if pcre ever comes to the apr-util If we wait to much - one of the first 2 choices. Pools: [X] Use the real apr_pool_t. [ ] Keep the jk_pool_apr wrapper renaming it to the jk_pool With the mention: use the real apr_pool_t in new code, let jk_pool_apr in the code related to component model ( and all new apr components can get and use the real apr_pool_t from jk_pool_apr struct ). Sockets: [x] Use only apr_socket and drop the socket, renaming apr to socket. [ ] Keep supporting socket. Use only apr_socket and default to it for 2.1, but without removing the old jk_socket ( until 2.2 ) File I/O: [x] Use the APR for file i/o replacing stdio/stdlib calls [ ] Keep the old fopen/fwrite/etc... code Same as before. Static buildings: [x] Enable Static/Dynamic APR builds of JK2 for non-Apache2 connectors [ ] Enable only dynamic builds -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/naming/src/org/apache/naming/core BaseDirContext.java ContextAccessController.java DirContextHelper.java JndiPermission.java NameParserImpl.java NamingContextBindingsEnumeration.java NamingContextEnumeration.java ServerAttribute.java ServerAttributes.java ServerName.java
costin 2002/10/01 11:42:17 Added: naming/src/org/apache/naming/core BaseDirContext.java ContextAccessController.java DirContextHelper.java JndiPermission.java NameParserImpl.java NamingContextBindingsEnumeration.java NamingContextEnumeration.java ServerAttribute.java ServerAttributes.java ServerName.java Log: Initial version - compile but probably doesn't run ( well, it did work at some stage ). This code is a refactored version of what's in catalina - I tried to merge different variants and standardise on use of Name. The reason of using Name - as I mentioned earlier - is the possible optimizations ( like using MessageBytes, caching, etc ), String is a very inflexible object. I added more comments to BaseDirContext on what I would like to do ( introspection-based config, etc ). Revision ChangesPath 1.1 jakarta-tomcat-connectors/naming/src/org/apache/naming/core/BaseDirContext.java Index: BaseDirContext.java === /* * * * The Apache Software License, Version 1.1 * * Copyright (c) 1999 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. The end-user documentation included with the redistribution, if *any, must include the following acknowlegement: * This product includes software developed by the *Apache Software Foundation (http://www.apache.org/). *Alternately, this acknowlegement may appear in the software itself, *if and wherever such third-party acknowlegements normally appear. * * 4. The names The Jakarta Project, Tomcat, and Apache Software *Foundation must not be used to endorse or promote products derived *from this software without prior written permission. For written *permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache *nor may Apache appear in their names without prior written *permission of the Apache Group. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * * This software consists of voluntary contributions made by many * individuals on behalf of the Apache Software Foundation. For more * information on the Apache Software Foundation, please see * http://www.apache.org/. * * [Additional notices, if required by prior licensing conditions] * */ package org.apache.naming.core; import java.util.*; import javax.naming.*; import javax.naming.directory.DirContext; import javax.naming.directory.Attributes; import javax.naming.directory.Attribute; import javax.naming.directory.ModificationItem; import javax.naming.directory.SearchControls; import org.apache.tomcat.util.res.StringManager; //import org.apache.naming.NameParserImpl; // Based on a merge of various catalina naming contexts // Name is used - it provide better oportunities for reuse and optimizations /** * Base Directory Context implementation. All j-t-c/naming contexts should * extend it. * * Implements all JNDI methods - if you just extend it you'll get UnsuportedOperation. * XXX Should it also act as introspector proxy or should we use a separate context ? * The intention is to allow use 'introspection magic' and bean-like DirContexts. * * IMPORTANT: all contexts should use
cvs commit: jakarta-tomcat-connectors/naming/src/org/apache/naming/res - New directory
costin 2002/10/01 11:42:39 jakarta-tomcat-connectors/naming/src/org/apache/naming/res - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/naming/src/org/apache/naming/modules/memory MemoryNamingContext.java NamingEntry.java memoryURLContextFactory.java
costin 2002/10/01 11:46:06
Added: naming/src/org/apache/naming/modules/memory
MemoryNamingContext.java NamingEntry.java
memoryURLContextFactory.java
Log:
The 'memory' context - used to be the java:, but it can be used
for other things and as a generic context.
Revision ChangesPath
1.1
jakarta-tomcat-connectors/naming/src/org/apache/naming/modules/memory/MemoryNamingContext.java
Index: MemoryNamingContext.java
===
/*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Tomcat, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
* [Additional notices, if required by prior licensing conditions]
*
*/
package org.apache.naming.modules.memory;
import java.util.Hashtable;
import java.util.Enumeration;
import javax.naming.*;
import javax.naming.directory.*;
import javax.naming.spi.NamingManager;
import org.apache.naming.core.*;
import org.apache.tomcat.util.res.*;
/**
* In-memory context.
*
* IMPLEMENTATION. We use NamingEntry stored in a tree of hashtables.
*
* @author Remy Maucherat
* @author Costin Manolache
*/
public class MemoryNamingContext extends BaseDirContext {
public MemoryNamingContext()
throws NamingException
{
super();
}
/**
* Builds a naming context using the given environment.
*/
public MemoryNamingContext(Hashtable env)
throws NamingException
{
super( env );
this.bindings = new Hashtable();
}
// - Instance Variables
/**
* The string manager for this package.
*/
protected static StringManager sm =
StringManager.getManager(org.apache.naming.res);
/**
* Bindings in this Context.
*/
protected Hashtable bindings;
public void setBindings( Hashtable bindings ) {
this.bindings = bindings;
}
// Context Methods
/**
* Unbinds the named object. Removes the terminal atomic name in name
* from the target context--that named by all but the terminal
cvs commit: jakarta-tomcat-connectors/naming/src/org/apache/naming/modules/java ContextBindings.java SelectorContext.java javaURLContextFactory.java
costin 2002/10/01 11:46:30
Added: naming/src/org/apache/naming/modules/java
ContextBindings.java SelectorContext.java
javaURLContextFactory.java
Log:
The java: impl.
Mostly copied from tomcat.
Revision ChangesPath
1.1
jakarta-tomcat-connectors/naming/src/org/apache/naming/modules/java/ContextBindings.java
Index: ContextBindings.java
===
/*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Tomcat, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
* [Additional notices, if required by prior licensing conditions]
*
*/
package org.apache.naming.modules.java;
import java.util.Hashtable;
import javax.naming.NamingException;
import javax.naming.Context;
import org.apache.tomcat.util.res.StringManager;
import org.apache.naming.core.*;
// this can be a nice generic util that binds per thread or CL any object.
/**
* Handles the associations :
* ul
* liCatalina context name with the NamingContext/li
* liCalling thread with the NamingContext/li
* /ul
*
* @author Remy Maucherat
*/
public class ContextBindings {
private static org.apache.commons.logging.Log log=
org.apache.commons.logging.LogFactory.getLog( ContextBindings.class );
// -- Variables
/**
* Bindings name - naming context. Keyed by name.
*/
private static Hashtable contextNameBindings = new Hashtable();
/**
* Bindings thread - naming context. Keyed by thread id.
*/
private static Hashtable threadBindings = new Hashtable();
/**
* Bindings thread - name. Keyed by thread id.
*/
private static Hashtable threadNameBindings = new Hashtable();
/**
* Bindings class loader - naming context. Keyed by CL id.
*/
private static Hashtable clBindings = new Hashtable();
/**
* Bindings class loader - name. Keyed by CL id.
*/
private static Hashtable clNameBindings = new Hashtable();
/**
* The string manager for this package.
*/
protected static StringManager sm =
cvs commit: jakarta-tomcat-connectors/naming/src/org/apache/naming/modules/id IdContext.java
costin 2002/10/01 11:48:29
Added: naming/src/org/apache/naming/modules/id IdContext.java
Log:
A future 'id:' context - for registering and supporting hooks and notes.
What I would like is to use JNDI to deal with all naming issues, and
both notes and hooks have this characteristic and should be at visible
( and configured ) via JNDI.
Revision ChangesPath
1.1
jakarta-tomcat-connectors/naming/src/org/apache/naming/modules/id/IdContext.java
Index: IdContext.java
===
package org.apache.naming.modules.id;
/**
* Store int handles in a DirContext.
*
* This replaces the 3.3 notes mechanism ( which were stored in ContextManager ).
* The context name is the 'namespace' for the notes ( Request, Container, etc ).
* One subcontext will be created for each note, with the id, description, etc.
*
* This is also used for Coyote hooks - to create the int hook id.
*
* Example:
* id:/coyote/hooks/commit - 1
* id:/coyote/hooks/pre_request - 2 ...
*
* id:/t33/hooks/pre_request - 1 ...
*
* id:/t33/ContextManager/myNote1 - 1
*
* The bound object is an Integer ( for auto-generated ids ).
*
* XXX Should it be a complex object ? Should we allow pre-binding of
* certain objects ?
* XXX Persistence: can we bind a Reference to persistent data ?
*/
public class IdContext {
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/naming/src/org/apache/naming/handler/jndi DirContextURLConnection.java DirContextURLStreamHandler.java DirContextURLStreamHandlerFactory.java Handler.java package.html
costin 2002/10/01 11:49:15
Added: naming/src/org/apache/naming/handler package.html
naming/src/org/apache/naming/handler/jndi
DirContextURLConnection.java
DirContextURLStreamHandler.java
DirContextURLStreamHandlerFactory.java Handler.java
package.html
Log:
The URL handler.
Revision ChangesPath
1.1
jakarta-tomcat-connectors/naming/src/org/apache/naming/handler/package.html
Index: package.html
===
h2URL handlersh2
This package contains URL handlers that allow access to jndi resources.
1.1
jakarta-tomcat-connectors/naming/src/org/apache/naming/handler/jndi/DirContextURLConnection.java
Index: DirContextURLConnection.java
===
/*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Tomcat, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
* [Additional notices, if required by prior licensing conditions]
*
*/
package org.apache.naming.handler.jndi;
import java.net.URL;
import java.net.URLConnection;
import java.io.*;
import java.security.Permission;
import java.util.Date;
import java.util.Enumeration;
import java.util.Vector;
import javax.naming.NamingException;
import javax.naming.NamingEnumeration;
import javax.naming.NameClassPair;
import javax.naming.directory.DirContext;
import javax.naming.directory.Attribute;
import javax.naming.directory.Attributes;
import org.apache.naming.core.JndiPermission;
import org.apache.naming.util.AttributeHelper;
// import org.apache.naming.resources.Resource;
// import org.apache.naming.resources.ResourceAttributes;
/**
* Connection to a JNDI directory context.
* p/
* Note: All the object attribute names are the WebDAV names, not the HTTP
* names, so this class overrides some methods from URLConnection to do the
* queries using the right names. Content handler is also not used; the
* content is directly returned.
*
* @author a href=mailto:[EMAIL PROTECTED];Remy Maucherat/a
* @author Costin Manolache
*/
public class DirContextURLConnection
extends URLConnection
{
cvs commit: jakarta-tomcat-connectors/naming/src/org/apache/naming/util AttributeHelper.java DomXml.java RecyclableNamingEnumeration.java
costin 2002/10/01 11:49:49
Added: naming/src/org/apache/naming/res LocalStrings.properties
LocalStrings_es.properties
LocalStrings_ja.properties
naming/src/org/apache/naming/util AttributeHelper.java
DomXml.java RecyclableNamingEnumeration.java
Log:
Other imported files
Revision ChangesPath
1.1
jakarta-tomcat-connectors/naming/src/org/apache/naming/res/LocalStrings.properties
Index: LocalStrings.properties
===
contextBindings.unknownContext=Unknown context name : {0}
contextBindings.noContextBoundToThread=No naming context bound to this thread
contextBindings.noContextBoundToCL=No naming context bound to this class loader
selectorContext.noJavaUrl=This context must be accessed throught a java: URL
namingContext.contextExpected=Name is not bound to a Context
namingContext.nameNotBound=Name {0} is not bound in this Context
namingContext.readOnly=Context is read only
namingContext.invalidName=Name is not valid
namingContext.alreadyBound=Name {0} is already bound in this Context
namingContext.noAbsoluteName=Can't generate an absolute name for this namespace
1.1
jakarta-tomcat-connectors/naming/src/org/apache/naming/res/LocalStrings_es.properties
Index: LocalStrings_es.properties
===
# $Id: LocalStrings_es.properties,v 1.1 2002/10/01 18:49:49 costin Exp $
# language es
# package org.apache.naming
contextBindings.unknownContext=Contexto {0} desconocido
contextBindings.noContextBoundToThread=No hay contexto de nombres asociado a este
hilo
selectorContext.noJavaUrl=Este contexto debe de ser accedido a traves de una URL de
tipo java:
namingContext.contextExpected=El nombre no esta asociado a ningun Contexto
namingContext.nameNotBound=El nombre {0} no este asociado a este contexto
namingContext.readOnly=El contexto es de solo lectura
namingContext.invalidName=Nombre no valido
namingContext.noAbsoluteName=No se puede generar un nombre absoluto para este
espacio de nombres
namingContext.alreadyBound=El nombre {0} este ya asociado en este Contexto
1.1
jakarta-tomcat-connectors/naming/src/org/apache/naming/res/LocalStrings_ja.properties
Index: LocalStrings_ja.properties
===
contextBindings.unknownContext=\u672a\u77e5\u306e\u30b3\u30f3\u30c6\u30ad\u30b9\u30c8\u540d\u3067\u3059
: {0}
contextBindings.noContextBoundToThread=\u3053\u306e\u30b9\u30ec\u30c3\u30c9\u306b\u30d0\u30a4\u30f3\u30c9\u3055\u308c\u308b\u30b3\u30f3\u30c6\u30ad\u30b9\u30c8\u306b\u306f\u540d\u524d\u304c\u3042\u308a\u307e\u305b\u3093
contextBindings.noContextBoundToCL=\u3053\u306e\u30af\u30e9\u30b9\u30ed\u30fc\u30c0\u306b\u30d0\u30a4\u30f3\u30c9\u3055\u308c\u308b\u30b3\u30f3\u30c6\u30ad\u30b9\u30c8\u306b\u306f\u540d\u524d\u304c\u3042\u308a\u307e\u305b\u3093
selectorContext.noJavaUrl=\u3053\u306e\u30b3\u30f3\u30c6\u30ad\u30b9\u30c8\u306fjava:
URL\u3092\u7528\u3044\u3066\u30a2\u30af\u30bb\u30b9\u3055\u308c\u306d\u3070\u306a\u308a\u307e\u305b\u3093
namingContext.contextExpected=\u540d\u524d\u304c\u30b3\u30f3\u30c6\u30ad\u30b9\u30c8\u306b\u30d0\u30a4\u30f3\u30c9\u3055\u308c\u3066\u3044\u307e\u305b\u3093
namingContext.nameNotBound=\u540d\u524d {0}
\u306f\u3053\u306e\u30b3\u30f3\u30c6\u30ad\u30b9\u30c8\u306b\u30d0\u30a4\u30f3\u30c9\u3055\u308c\u3066\u3044\u307e\u305b\u3093
namingContext.readOnly=\u30b3\u30f3\u30c6\u30ad\u30b9\u30c8\u306f\u30ea\u30fc\u30c9\u30aa\u30f3\u30ea\u30fc\u3067\u3059
namingContext.invalidName=\u540d\u524d\u306f\u7121\u52b9\u3067\u3059
namingContext.alreadyBound=\u540d\u524d {0}
\u306f\u3059\u3067\u306b\u3053\u306e\u30b3\u30f3\u30c6\u30ad\u30b9\u30c8\u306b\u30d0\u30a4\u30f3\u30c9\u3055\u308c\u3066\u3044\u307e\u3059
namingContext.noAbsoluteName=\u3053\u306e\u540d\u524d\u7a7a\u9593\u306b\u7d76\u5bfe\u540d\u3092\u751f\u6210\u3067\u304d\u307e\u305b\u3093
1.1
jakarta-tomcat-connectors/naming/src/org/apache/naming/util/AttributeHelper.java
Index: AttributeHelper.java
===
/*
*
*
* 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
DO NOT REPLY [Bug 7207] - Redeployment Problem under Tomcat 4.0.2
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=7207. 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=7207 Redeployment Problem under Tomcat 4.0.2 --- Additional Comments From [EMAIL PROTECTED] 2002-10-01 19:22 --- Is this similar to #8969? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13081] - ScriptingVariableVisitor#setScriptingVars does not account for scriptlet scopes
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=13081.
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=13081
ScriptingVariableVisitor#setScriptingVars does not account for scriptlet scopes
--- Additional Comments From [EMAIL PROTECTED] 2002-10-01 19:46 ---
I do believe the problem stated in 13132 does apply to your situation. Remember
13132 started out with this code fragment:
% if (condition) { %
i18n:message key=some.key id=myID/
% } else { %
i18n:message key=some.other.key id=myID/
% }
%
which is exactly what you are trying to do. The purpose of the example I gave in
the evaluation of 13132 is to show that some developers may rely on AT_END
variables to be declared after the call to the tag handler's doEndTag() method,
so that a nested tag may declare an AT_END variable of the same name, but with a
different type than an AT_END variable declared by the enclosing tag.
Would the workaround that I suggested for bug 13132 work for you, i.e., do
something like the following:
prefix:outerTag
% if (true) { %
prefix:innerTag id=x /
% } %
prefix:innerTag id=y /
/prefix:outerTag
I am little reluctant adding a configuration property for this, as it would not
be portable across containers.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13183] New: - CoyoteConnector doesn't work with https
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=13183. 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=13183 CoyoteConnector doesn't work with https Summary: CoyoteConnector doesn't work with https Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Critical Priority: Other Component: Connector:Coyote JK 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The request provides the wrong information, when I access a page with https request.getServerPort() provides the expected info, but request.scheme() still returns http and request.isSecure() returns 'false'. If I switch to Ajp13Connector, everything works as expected. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Cache question
Hello all. Cache question. I have a jsp form that is being forward from a login page that is doing validation from a database. The jsp form has buttons and a click on each specific button will set a hidden input a specific value and and the action will go to another jsp page, where depending on what the hidden input was set to , will jsp forward to the page that is requested. But on click a javascript back, INPUT TYPE=button VALUE=Cancel onClick=javascript:history.go(-1)or the browser back button we get the previous page, but a click on any different button will go to the page you were just at, not the page it should go to. I have http 1.1 configured on my tomcat and I know that if on the page where the buttons reside, I add this : % //HTTP 1.1 response.setHeader(Cache-Control,no-cache); //HTTP 1.0 //response.setHeader(Pragma,no-cache); //prevents caching at the proxy server //response.setDateHeader (Expires, 0);% Then if I click on let say button a to go to a.jsp and click back , I get this: 'Warning: Page has Expired The page you requested was created using information you submitted in a form. This page is no longer available. As a security precaution, Internet Explorer does not automatically resubmit your information for you. To resubmit your information and view this Web page, click the Refresh button. ' Is there any way to just to see the previous page and have it have, now lets say a click on button b to go to b.jsp and not to the cached a.jsp Thanks __ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13185] New: - Parallel JSP requests get crossed reponses from Tomcat.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13185. 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=13185 Parallel JSP requests get crossed reponses from Tomcat. Summary: Parallel JSP requests get crossed reponses from Tomcat. Product: Tomcat 4 Version: 4.0.4 Final Platform: PC OS/Version: Linux Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have a JSP page that is pre-compiled. Meaning I've visited the page with my browser before I do this. I get two browsers running on either the same machine or different machines with different IP's. I request the same page with two different GET paramenters. I'm hitting the link at the same time on the two browsers. The response is unpredictable. Some times one browswer fails to get a response. Sometimes the second browser gets the page intended for the first browser. etc. This is very severe. Both connections are https because the information is confidential to our customers. There is a possibility that one of our customers could see another's information. I'm serving these pages from RH Linux 7.3 and Tomcat-Catalina 4.0.4 Thanks, Rick CTO, Syngenium, Inc. [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12810] - socket write error clicking between pages to fast
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=12810. 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=12810 socket write error clicking between pages to fast [EMAIL PROTECTED] changed: What|Removed |Added Severity|Enhancement |Major --- Additional Comments From [EMAIL PROTECTED] 2002-10-01 21:57 --- This happens for all IE clients requesting non text/html resources. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13183] - CoyoteConnector doesn't work with https
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=13183. 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=13183 CoyoteConnector doesn't work with https [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-10-01 22:00 --- *** This bug has been marked as a duplicate of 12998 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13130] - Tomcat service does not recognize resources from a network shared drive..
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=13130. 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=13130 Tomcat service does not recognize resources from a network shared drive.. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-10-01 22:11 --- This is a windows problem not a Tomcat one.. you would need to set the user in the service, to one user whose profile has the needed mapped drive, althougth it's not a very recommend practice in a security environment.. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12810] - socket write error clicking between pages to fast
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=12810. 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=12810 socket write error clicking between pages to fast [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2002-10-01 22:17 --- oops, pressed the wrong button.. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12810] - socket write error clicking between pages to fast
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=12810. 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=12810 socket write error clicking between pages to fast --- Additional Comments From [EMAIL PROTECTED] 2002-10-01 22:34 --- My very minimal testing with points towards IE issuing multiple get requests, one for the HEAD and another to GET the content if the content type isn't text/html. Deploying identical files under a JBoss/Tomcat bundle shows this behavior with 4.12, and not with 4.0x. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12810] - socket write error clicking between pages to fast
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=12810. 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=12810 socket write error clicking between pages to fast [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-10-01 22:16 --- This is not a problem, maybe an excessive logging, this happens when the user aborts the connection, that is exactly what the reporter by pressing refresh quickly.. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common HandlerRequest.java
nacho 2002/10/01 16:14:13 Modified:jk/java/org/apache/jk/common HandlerRequest.java Log: tomcatAuthentication must default to true ( tomcat ignores auth done in the HTTP server ) to match the tc4.0 and tc3.3 behaviour and Revision ChangesPath 1.16 +1 -1 jakarta-tomcat-connectors/jk/java/org/apache/jk/common/HandlerRequest.java Index: HandlerRequest.java === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/HandlerRequest.java,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- HandlerRequest.java 26 Aug 2002 09:54:34 - 1.15 +++ HandlerRequest.java 1 Oct 2002 23:14:13 - 1.16 @@ -323,7 +323,7 @@ int secretNote; boolean decoded=true; -boolean tomcatAuthentication; +boolean tomcatAuthentication=true; public int invoke(Msg msg, MsgContext ep ) throws IOException -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tomcat 4.1.12 and Servlet Access 404 Errors: BUG?
I cannot access a webapp with the normal http://localhost:8080/myapp/servlet/mydirectory.MyServlet with Tomcat 4.1.12. (Also, the embedded Tomcat 4.1.12 in JBoss 3.0.3 runs fine except that it won't access the examples servlets.) The error shown is a 404 The requested resource (/myapp/servlet/mydirectory.MyServlet) is not available.. The same thing runs fine with Tomcat 4.1.0., both with and without JBoss. Is this a BUG in Tomcat 4.1.12, or are there new constraints on reaching servlets from outside the container in 4.1.12? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.1.12 and Servlet Access 404 Errors: BUG?
micael wrote: I cannot access a webapp with the normal http://localhost:8080/myapp/servlet/mydirectory.MyServlet with Tomcat 4.1.12. (Also, the embedded Tomcat 4.1.12 in JBoss 3.0.3 runs fine except that it won't access the examples servlets.) The error shown is a 404 The requested resource (/myapp/servlet/mydirectory.MyServlet) is not available.. The same thing runs fine with Tomcat 4.1.0., both with and without JBoss. Is this a BUG in Tomcat 4.1.12, or are there new constraints on reaching servlets from outside the container in 4.1.12? For security reasons (see the release notes for details), the invoker servlet is disabled by default now. This servlet is what makes /webapp/servlet/... paths invoke the given servlet. It's recommended that you give explicit servlet definitions and mappings in the webapps's web.xml instead. Michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.1.12 and Servlet Access 404 Errors: BUG?
Thanks, Michael. Actually, I think this is a good thing. Micael At 12:26 PM 10/2/2002 +1000, you wrote: micael wrote: I cannot access a webapp with the normal http://localhost:8080/myapp/servlet/mydirectory.MyServlet with Tomcat 4.1.12. (Also, the embedded Tomcat 4.1.12 in JBoss 3.0.3 runs fine except that it won't access the examples servlets.) The error shown is a 404 The requested resource (/myapp/servlet/mydirectory.MyServlet) is not available.. The same thing runs fine with Tomcat 4.1.0., both with and without JBoss. Is this a BUG in Tomcat 4.1.12, or are there new constraints on reaching servlets from outside the container in 4.1.12? For security reasons (see the release notes for details), the invoker servlet is disabled by default now. This servlet is what makes /webapp/servlet/... paths invoke the given servlet. It's recommended that you give explicit servlet definitions and mappings in the webapps's web.xml instead. Michael -- 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/coyote/src/java/org/apache/coyote/tomcat4 CoyoteAdapter.java
billbarker2002/10/01 22:29:53 Modified:coyote/src/java/org/apache/coyote/tomcat4 CoyoteAdapter.java Log: Decode the URI as a URI, not as a query-string. Fix for bug #13162 Reported By: Mark Hampton [EMAIL PROTECTED] Revision ChangesPath 1.11 +5 -5 jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java Index: CoyoteAdapter.java === RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- CoyoteAdapter.java29 Sep 2002 17:07:44 - 1.10 +++ CoyoteAdapter.java2 Oct 2002 05:29:53 - 1.11 @@ -273,7 +273,7 @@ // URI decoding req.decodedURI().duplicate(req.requestURI()); -req.getURLDecoder().convert(req.decodedURI(), true); +req.getURLDecoder().convert(req.decodedURI(), false); req.decodedURI().setEncoding(UTF-8); // Normalize decoded URI -- 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 CoyoteAdapter.java
billbarker2002/10/01 22:30:50 Modified:coyote/src/java/org/apache/coyote/tomcat5 CoyoteAdapter.java Log: Port patch from tomcat4. Revision ChangesPath 1.2 +5 -5 jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteAdapter.java Index: CoyoteAdapter.java === RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteAdapter.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- CoyoteAdapter.java4 Aug 2002 19:39:49 - 1.1 +++ CoyoteAdapter.java2 Oct 2002 05:30:50 - 1.2 @@ -278,7 +278,7 @@ // URI decoding req.decodedURI().duplicate(req.requestURI()); -req.getURLDecoder().convert(req.decodedURI(), true); +req.getURLDecoder().convert(req.decodedURI(), false); req.decodedURI().setEncoding(UTF-8); // Normalize decoded URI -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Commons-logging setting
Hi all, I know I shouldn't send this email to the list but the tomcat-users wasn't so successfull (and since I've seen that your using commons-logging for 5.0...) I have integrated the commons-logging to Xindice and I want to execute the Xindice servlet within Tomcat before I send the patch. I can make a deployment without problem, everythings work. Well almost. The only problem is that only the SEVERE and INFO messages are logged into catalina.out. How can I set up the logger to also receive the trace and debug messages? I have tried to put a commons-logging properties almost everywhere (/webapps, /webapps/Xindice, /webapps/Xindice/META-INF, /webapps/Xindice/WEB-INF, /webapps/Xindice/WEB-INF/classes, /webapps/Xindice/conf) but nothing seems to works. The content of the commons-logging properties is rather simple : org.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.SimpleLog org.apache.commons.logging.simplelog.defaultlog=trace org.apache.commons.logging.log.org.apache.xindice=trace Does anybody have simple step-by-step instructions to configure commons-logging? Thanks A LOT in advance -Vladimir -- Vladimir Bossicard www.bossicard.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13162] - Pluses(+) in URL do not match plus(+) in file system
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=13162. 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=13162 Pluses(+) in URL do not match plus(+) in file system [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-10-02 05:32 --- This is now fixed in the CVS, and will appear in 4.1.13. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
