Re: Apache 2.0.42
JK 1.2.0 is tagged (JK_1_2_0_rel) and source tarball is being constructed (without webapp, jk/native2, java parts). I'll provide rpm for Redhat users, against Apache 1.3.22 (with ssl), Apache 2.0.42 (also with SSL). mod_jk.so for Apache 1.3 (with and without SSL), and 2.0.42 will also be provided. IIS binaries should follow shortly, may be even iSeries V5R1 SAVF. Stay tuned -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapijk2_install.vbs
[EMAIL PROTECTED] wrote: mturk 2002/09/26 11:45:55 Very interesting stuff... I didn't expect to see VBS one days in an Apache CVS ;) But in JTC we found more exotic stuff like iSeries CL sources... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapijk2_install.vbs
Henri Gomez wrote: [EMAIL PROTECTED] wrote: mturk 2002/09/26 11:45:55 Very interesting stuff... I didn't expect to see VBS one days in an Apache CVS ;) But in JTC we found more exotic stuff like iSeries CL sources... Read, didn't expected -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [ANNOUNCEMENT]: JK 1.2.0 is now available
Marx, Mitchell E (Mitch), ALCNS wrote: Where is Solaris 8, Apache 1.3? to be released, but contributions are welcomed ;-) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [ANNOUNCEMENT]: JK 1.2.0 is now available
Henri Gomez wrote: Marx, Mitchell E (Mitch), ALCNS wrote: Where is Solaris 8, Apache 1.3? to be released, but contributions are welcomed ;-) Just uploaded by JF Clere. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[ANNOUNCEMENT]: JK 1.2.0 is now available
Hi all, The Jakarta-Tomcat-Connector team is pleased to announce the availability of JK 1.2.0. JK, also known as mod_jk, is a Tomcat / WebServers plug-in that handles the communication between Tomcat and webservers. Currently Apache 1.3.x and 2.0.x, IIS, Netscape/iPlanet are supported. binaries and source versions of the release are available and can be downloaded from : http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.0/ Binaries allready available are : - Linux i386 (Apache 1.3/2.0.42) - Solaris 8 (Apache 1.3/2.0.39/2.0.42) - Win32 (IIS/Apache 1.3/2.0.42) MacOS X, AIX, iSeries binaries to be released shortly (I hope) Feel free to contact us to provide binaries for your own operating system. Enjoy! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] [5.0] Milestones
Remy Maucherat wrote: Hi, Now that the first stable releases of Tomcat 4.1 are out (and according to reports, of good overall quality), it could be appropriate to start releasing 5.0.x milestones. It should be pointed out that 5.0.x is still far from being feature complete (esp the configuration code needs to be unified if possible, and some optimizations are needed), so the milestones should be considered alpha or pre alpha until further notice. ballot [ ] +1 Yes, start releasing milestones [ ] -1 No, because: +1 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_socket.c
Did you source tarball include latest patches from Nacho ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
tomcat 3.3.2 cleanup
If everybody agree, what about removing src/native for tomcat 3.3.2 ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
garbaged image jpeg in jk documentation from tc 4.1.12
A quick note to say that TC 4.1.12 which included jk/jk2 documentation, as a garbled mod_jk.jpeg images (dos-unix conversion ?). I changed mod_jk.jpeg to mod_jk.jpg to avoid cvs client to change that file. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_socket.c
Either we'll retag that as 2_0_0 or 2_0_1. What do you think? 2_0_0_rel, as I did for JK 1.2.0 I would like to make that as JK2_2_0_1, and rerelease, as 2.0.1 It's just a fix, so make a new tarball and tell you get it from 2_0_0_rel (unless you put an announce to tomcat-user which in that case make greated audience and the 2.0.1 is really required) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-5 KEYS
Stefan Bodewig wrote: Henri, let me know if you need changes to Ant's KEYS file as well. Yes, you should remove the old one, since it has been revoked. PS: I use the new one to produce rpm with jpackage.org project -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-5 KEYS
Stefan Bodewig wrote: On Mon, 30 Sep 2002, Henri Gomez [EMAIL PROTECTED] wrote: Yes, you should remove the old one, since it has been revoked. What if we are still distributing RPMs that have been signed with the old key? Will you create a new RPM with your new key? Yes, I suggest users to switch to rpm I've done for jpackage project. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JK2 Tagged as JK2_2_0_0_rel
jean-frederic clere wrote: Mladen Turk wrote: JK2 has been retagged cause of socket bug (for some of us it was a feature :-). The sources are on: http://jakarta.apache.org/~mturk/ Cannot write to the builds dir, so if someone is willing to copy that to the builds/release. Nacho, Henri? I have removed the old release subdirection and recreated it with enough permissions: The file http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/release/v2.0.0/src/jakarta-tomcat-connectors-jk2-2.0.0.tar.gz need to be signed. Mladen could you change the tarball : Change it's name to jakarta-tomcat-connectors-jk2-2.0.0-src.tar.gz directory changed to jakarta-tomcat-connectors-jk2-2.0.0-src Keep the jtc layout, ie jk/native2 ? The current layout prevent me from using the same spec files for jk and jk2 (duplicate works = duplicates bugs) Regards -- 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: jean-frederic clere wrote: Mladen Turk wrote: JK2 has been retagged cause of socket bug (for some of us it was a feature :-). The sources are on: http://jakarta.apache.org/~mturk/ Cannot write to the builds dir, so if someone is willing to copy that to the builds/release. Nacho, Henri? I have removed the old release subdirection and recreated it with enough permissions: The file http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/release/v2.0.0/src/jakarta-tomcat-connectors-jk2-2.0.0.tar.gz need to be signed. Mladen could you change the tarball : Change it's name to jakarta-tomcat-connectors-jk2-2.0.0-src.tar.gz directory changed to jakarta-tomcat-connectors-jk2-2.0.0-src Keep the jtc layout, ie jk/native2 ? The current layout prevent me from using the same spec files for jk and jk2 (duplicate works = duplicates bugs) Also include generated doc in jk/docs, even if it could be regenerated by ant, it's still native code area and many peoples may don't have/want to use ant to generate the doc -- 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: Ok did, could you check on the same place (my home dir). Where cvs or jakarta ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: tomcat 3.3.2 cleanup
Larry Isaacs wrote: Now that mod_jk 1.2.0 is released, I'm fine with this. Nota, that it will remove also mod_jserv -- 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: Ok did, could you check on the same place (my home dir). Where ? http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/release/v2.0.0/src/ -- 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: If everybody agree, what about removing src/native for tomcat 3.3.2 ? +1 Yes or no ? -- 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]
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: [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: [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]
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]
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: 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]
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]
Re: [VOTE] JK2 2.1
#ifdef AS400 fp = fopen(workerFile, w, o_ccsid=0); #else fp = fopen(workerFile, w); #endif Is this abstractive code enough ;) That was the initial price to have iSeries support in JK2. But that's rigth, I'll create a jk_os.c to hide this from main code (in both jk 1.2.0 and 2.0.0). But will still have to use ifdef with EBCDIC system (iSeries / BS2000), for example in JNI areas or request encoding/decoding. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] JK2 2.1
More comments on APR and JK2. While making tomcat-connectors rpm for jk2, and also jk2 binaries for Linux, I wanted to have apache 1.3 jk2 built with JNI support. JNI support in JK2 requires APR. So I build an apr 0.9.1 rpm, which include apr-utils since apr-utils couldn't be built without apr ;-[ To avoid conflict with Apache 2.0 rpms, I've installed apr libs in /usr/lib/apr/ and includes in /usr/include/apr. And here we allready discover many interesting things : With Apache 2.0, libapr shared lib in name libapr.so.0.9.2. With APR build, it's called libapr-0.so.0.9.2. What you see also is that is seems that parts of apr-utils are included in Apache2 binaries (ie md5 stuff), so when you're using APR libs, you should add apr and aprutils to ldpath (-lapr -laprutils). With that I was thinking being ready to make Apache 1.3 works with APR, for JNI use purposes. I've used : ./configure --with-apxs=/usr/sbin/apxs --with-jni --with-apr-lib=/usr/lib/apr --with-apr-include=/usr/include/apr The build works but I saw that the mod_jk2.so was linked against /usr/lib/libapr.so (the one from Apache 2.0 built) against the one in /usr/lib/arp. So I patched Makefile.in to change -lapr to -lapr-0. here correct build and link. But the JNI support was still not there since the Makefile.in need a little rework. I tried first to use and adapt the one from Apache 2.0 but this one didn't works since Apache 2.0.42 provide it's own libtool 1.4.2 and make use of rpath, which didn't works with the standard libtool 1.4 bundled with Redhat 7.2 No problem, I adapted the original Makefile.in from Apache 1.3 (patch attached) and do the build. I finally got a mod_jk2.so and jkjni.so to be used with my Apache 1.3. I installed mod_jk2.so and jkjni.so in Apache 1.3 modules dir, /usr/lib/apache, tried a restart but it failed with : Starting httpd: Syntax error on line 1536 of /etc/httpd/conf/httpd.conf: Cannot load /etc/httpd/modules/mod_jk2.so into server: /etc/httpd/modules/mod_jk2.so: undefined symbol: jk_jni_status_code Urg, I think it could be related to missing stuff in mod_jk2.so, since it's not linked against apr-util shared lib, so I rechange the Makefile.in, does the configure and make. But still same error : Cannot load /etc/httpd/modules/mod_jk2.so into server: /etc/httpd/modules/mod_jk2.so: undefined symbol: jk_jni_status_code When I take a look at binaries, the jkjni.so for Apache 2 is 126180 long but the one for Apache 1.3 is only 8796 ? Here is was ldd -v report about mod_jk2.so / jkjni.so for Apache 1.3 and 2.0 : mod_jk2.so for Apache 1.3 libcrypt.so.1 = /lib/libcrypt.so.1 (0x4002f000) libapr-0.so.0 = /usr/lib/apr/libapr-0.so.0 (0x4005c000) libaprutil-0.so.0 = /usr/lib/apr/libaprutil-0.so.0 (0x4007a000) libc.so.6 = /lib/i686/libc.so.6 (0x4008f000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) Version information: /usr/lib/apache/mod_jk2.so: libc.so.6 (GLIBC_2.1.3) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.1) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.0) = /lib/i686/libc.so.6 /lib/libcrypt.so.1: libc.so.6 (GLIBC_2.1.3) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.0) = /lib/i686/libc.so.6 /usr/lib/apr/libapr-0.so.0: libc.so.6 (GLIBC_2.1.3) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.2) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.1.2) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.1) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.0) = /lib/i686/libc.so.6 /usr/lib/apr/libaprutil-0.so.0: libc.so.6 (GLIBC_2.1.3) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.1) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.0) = /lib/i686/libc.so.6 /lib/i686/libc.so.6: ld-linux.so.2 (GLIBC_2.1.1) = /lib/ld-linux.so.2 ld-linux.so.2 (GLIBC_2.2.3) = /lib/ld-linux.so.2 ld-linux.so.2 (GLIBC_2.1) = /lib/ld-linux.so.2 ld-linux.so.2 (GLIBC_2.2) = /lib/ld-linux.so.2 ld-linux.so.2 (GLIBC_2.0) = /lib/ld-linux.so.2 libcrypt.so.1 = /lib/libcrypt.so.1 (0x40012000) libapr-0.so.0 = /usr/lib/apr/libapr-0.so.0 (0x4003f000) libaprutil-0.so.0 = /usr/lib/apr/libaprutil-0.so.0 (0x4005d000) libc.so.6 = /lib/i686/libc.so.6 (0x40072000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) jkjni.so for Apache 1.3 Version information: /usr/lib/apache/jkjni.so: libc.so.6 (GLIBC_2.1.3) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.0) = /lib/i686/libc.so.6 /lib/libcrypt.so.1: libc.so.6 (GLIBC_2.1.3) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.0) = /lib/i686/libc.so.6 /usr/lib/apr/libapr-0.so.0: libc.so.6 (GLIBC_2.1.3) = /lib/i686/libc.so.6
Re: JK 1.2.1-beta
Glenn Nielsen wrote: You are currently working on mod_jk 1.2 and have done alot of work on the docs. Would you like to do it? We could add in the faq the common error messages and give an explanation. Idea, even put an url to the online documentation on jakarta ;-) I can do it if you can't, but I don't know when I would have the time. I'm pretty busy these days, and I was thinking releasing jk 1.2.1 since there was many fixes for iSeries, so jk 1.2.1 = jk 1.2.0 iSeries compatible. Adding better error messages informations could be planned for jk 1.2.2 even if I think we should concentrate on jk2 now ;-) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JK 1.2.1-beta
Bojan Smojver wrote: On Tue, 2002-10-01 at 23:41, Glenn Nielsen wrote: 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. 2 sounds like quite a bit of work. yes, it's too much works 3 I think is a must (your e-mail is a great start for it - maybe you can whack it in FAQ). Yes, extend faq.xml/faq.html with error message. 1 would be nice, but people should be able to live with 3 if you don't have time for 1. Why not put an URL to faq.html, for the common error messages, ie : http://jakarta.apache.org/builds/jk/docs/faq.html#canconnect ? Up to date documentation could be provided like this ? What about same behaviour for jk2 ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] JK2 2.1
jean-frederic clere wrote: Henri Gomez wrote: More comments on APR and JK2. While making tomcat-connectors rpm for jk2, and also jk2 binaries for Linux, I wanted to have apache 1.3 jk2 built with JNI support. JNI support in JK2 requires APR. So I build an apr 0.9.1 rpm, which include apr-utils since apr-utils couldn't be built without apr ;-[ To avoid conflict with Apache 2.0 rpms, I've installed apr libs in /usr/lib/apr/ and includes in /usr/include/apr. And here we allready discover many interesting things : With Apache 2.0, libapr shared lib in name libapr.so.0.9.2. With APR build, it's called libapr-0.so.0.9.2. What you see also is that is seems that parts of apr-utils are included in Apache2 binaries (ie md5 stuff), so when you're using APR libs, you should add apr and aprutils to ldpath (-lapr -laprutils). With that I was thinking being ready to make Apache 1.3 works with APR, for JNI use purposes. I've used : ./configure --with-apxs=/usr/sbin/apxs --with-jni --with-apr-lib=/usr/lib/apr --with-apr-include=/usr/include/apr The build works but I saw that the mod_jk2.so was linked against /usr/lib/libapr.so (the one from Apache 2.0 built) against the one in /usr/lib/arp. So I patched Makefile.in to change -lapr to -lapr-0. here correct build and link. That is not enough you should use apr-config. I have already patched mod_webapp for that. Could you do the same for jk2, but it should be only if --with-apr is present... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Ajp13 wrong Response
Vince Clark wrote: I found this post while researching the mail list archives for a problem I am having. The description Henri provides sounds exactly like what is happening with my application. I have included the original threads below. Prior to reading this posting I had not come to Henri's conclusion: Under certain conditions some request get the response for some other request Hum, it came from prehistory ;-) With ajp13 and Tomcat 3.2.x, and should really be fixed with Tomcat 3.3.1. i didn't see such behaviour for months -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Strange problem with tomcat 4.1.2
While working on 4.1.2 rpms I noticed the following error at startup : 4732 [main] INFO modeler.Registry - Creating MBeanServer 5705 [main] INFO http11.Http11Protocol - Initializing Coyote HTTP/1.1 on port 8080 Starting service Tomcat-Standalone Apache Tomcat/4.1 7324 [main] ERROR digester.Digester - Parse Fatal Error at line 307 column 39: The string -- is not permitted within comments. org.xml.sax.SAXParseException: The string -- is not permitted within comments. at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown Source) at org.apache.xerces.impl.XMLScanner.scanComment(Unknown Source) at org.apache.xerces.impl.XMLDTDScannerImpl.scanComment(Unknown Source) at org.apache.xerces.impl.XMLDTDScannerImpl.scanDecls(Unknown Source) at org.apache.xerces.impl.XMLDTDScannerImpl.scanDTDExternalSubset(Unknown Source) at org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.commons.digester.Digester.parse(Digester.java:1514) at org.apache.catalina.startup.ContextConfig.tldScanStream(ContextConfig.java:977) at org.apache.catalina.startup.ContextConfig.tldScanTld(ContextConfig.java:1006) at org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:870) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3493) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardHost.start(StandardHost.java:738) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347) at org.apache.catalina.core.StandardService.start(StandardService.java:497) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2189) at org.apache.catalina.startup.Catalina.start(Catalina.java:510) at org.apache.catalina.startup.Catalina.execute(Catalina.java:400) at org.apache.catalina.startup.Catalina.process(Catalina.java:180) at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) 8720 [main] ERROR digester.Digester - Parse Fatal Error at line 307 column 39: The string -- is not permitted within comments. org.xml.sax.SAXParseException: The string -- is not permitted within comments. at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source) Admin log show me the following error : 2002-10-02 13:29:01 WebappLoader[/admin]: Deploying class repositories to work directory /var/tomcat4/work/Standalone/localhost/admin 2002-10-02 13:29:01 WebappLoader[/admin]: Deploy class files /WEB-INF/classes to /var/tomcat4/webapps/../server/webapps/admin/WEB-INF/classes 2002-10-02 13:29:01 WebappLoader[/admin]: Deploy JAR /WEB-INF/lib/struts.jar to /var/tomcat4/webapps/../server/webapps/admin/WEB-INF/lib/struts.jar 2002-10-02 13:29:02 ContextConfig[/admin] Exception processing TLD at resource path /WEB-INF/controls.tld javax.servlet.ServletException: Exception processing TLD at resource path /WEB-INF/controls.tld at org.apache.catalina.startup.ContextConfig.tldScanTld(ContextConfig.java:1010) at org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:870) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3493) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:821) at
Re: Strange problem with tomcat 4.1.2
Matt Fury wrote: I BELIEVE that is due to some incorrect commenting in your server.xml file. I had this problem once and I thats what caused it. Double check your server.xml file. I triple checked ALL xml files, and they are correct and the error show up first in digester. I suspect something elsewhere, since the error is also present when you're using the original tarball if you replace the bundled xercesImpl.jar by a xerces 2.2.0.jar The difference is that the same error didn't prevent tomcat to load example, admin or manager webapps. I attached a log done using tomcat 4.1.12 tarball (full) and with xerces 2.2.0 replacing the original xercesImpl.jar I does the change before launching tomcat for the first time. 2002-10-03 10:09:18 WebappLoader[/admin]: Deploying class repositories to work directory /home/root/jakarta-tomcat-4.1.12/work/Standalone/localhost/admin 2002-10-03 10:09:18 WebappLoader[/admin]: Deploy class files /WEB-INF/classes to /home/root/jakarta-tomcat-4.1.12/webapps/../server/webapps/admin/WEB-INF/classes 2002-10-03 10:09:18 WebappLoader[/admin]: Deploy JAR /WEB-INF/lib/struts.jar to /home/root/jakarta-tomcat-4.1.12/webapps/../server/webapps/admin/WEB-INF/lib/struts.jar 2002-10-03 10:09:19 ContextConfig[/admin]: Configured an authenticator for method FORM 2002-10-03 10:09:19 StandardManager[/admin]: Seeding random number generator class java.security.SecureRandom 2002-10-03 10:09:19 StandardManager[/admin]: Seeding of random number generator has been completed 2002-10-03 10:09:19 StandardWrapper[/admin:default]: Loading container servlet default 2002-10-03 10:09:19 StandardWrapper[/admin:invoker]: Loading container servlet invoker 2002-10-03 10:09:21 action: null org.xml.sax.SAXParseException: The string -- is not permitted within comments. at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at javax.xml.parsers.SAXParser.parse(SAXParser.java:363) at javax.xml.parsers.SAXParser.parse(SAXParser.java:137) at org.apache.struts.digester.Digester.parse(Digester.java:755) at org.apache.struts.action.ActionServlet.initServlet(ActionServlet.java:1434) at org.apache.struts.action.ActionServlet.init(ActionServlet.java:474) at org.apache.webapp.admin.ApplicationServlet.init(ApplicationServlet.java:152) at javax.servlet.GenericServlet.init(GenericServlet.java:256) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:924) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:813) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3341) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3534) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:821) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:579) at org.apache.catalina.core.StandardHostDeployer.addChild(StandardHostDeployer.java:529) at java.lang.reflect.Method.invoke(Native Method) at org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.java:228) at org.apache.commons.digester.SetNextRule.end(SetNextRule.java:260) at org.apache.commons.digester.Digester.endElement(Digester.java(Compiled Code)) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.commons.digester.Digester.parse(Digester.java:1514) at org.apache.catalina.core.StandardHostDeployer.install(StandardHostDeployer.java:335) at org.apache.catalina.core.StandardHost.install(StandardHost.java:803) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:452) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:409) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:879) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:368) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1196) at org.apache.catalina.core.StandardHost.start(StandardHost.java:738) at
Re: [VOTE] JK2 2.1
Costin Manolache wrote: Henri Gomez wrote: More comments on APR and JK2. While making tomcat-connectors rpm for jk2, and also jk2 binaries for Linux, I wanted to have apache 1.3 jk2 built with JNI support. Do you have a multithreaded apache1.3 ? It's very important to compile it as multithreaded and link pthread ! No but added the LoadModule pthread directive. For the apr issues - I still think that apr should be treated as a general-purpose library, and we shouldn't have more than one varaiant in the system. Yes Probably some APR expert could clarify this - but my opinion is that on linux the right place for apr is /usr/lib/libapr.so.0.9.2 and /usr/include/apr. When you create an Apache 2.0.42, apr shared lib goes in /usr/lib, with /usr/lib/libapr.so.0.9.2. The includes goes in /usr/include/apache2. When you're just build apr/apr-util, you should put them elsewhere to avoid collision with the one which are provided by apache2. If you don't do this, you'll have a strange situation where you have to specify that you need apache2 to build apache 1.3 jk2 ! Also as I said the shared/static libs which came from apr 0.9.1 have major version in name, libapr-0.so, libaprutil-0.so... And I think Apache2.0 RPM should just depend on libapr.rpm, and same for mod_jk2.rpm I seems you could build Apache 2.0.42 against an allready present APR shared lib, and trying it right now but I still wonder why Apache 2.0.42 bundle an APR 0.9.2 where only APR 0.9.1 is available as release. It's just too confusing to have 2 variants of the same library, and it should be a portability library that can be used outside apache - without apache having a special copy. I agree, but it's something which should be fixed by Apache 2.0 and APR teams, ie make Apache 2.0 use the latest APR release (0.9.1 or 0.9.2 ?). May be JF could do something for us and also ask why the apr goes with the -0 in names -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tagging JK2_2_0_1?
Mladen Turk wrote: There has been some major fixes inside the uriMap, uriEnv, apr_socket and lb that makes the 2_0_0 IMO unusable, and personally I'm ashamed as a RM that this was a release after all :(. Since we tagged and released JK2 as beta, seems to me that we could easily do the same for the 2.0.1, and just pretend that 2.0.0 ewer existed :) As JF said, we should wait a little more before releasing a 2.0.1 (even beta). The question is are we going to wait for a Apache1.3/APR/JNI builds or just go without that. But before going to the 2_0_1 (What doesn't kill you makes you stronger ;) could you guys do the testing against current CVS for all the discussed items. I think Apache 1.3 / APR / JNI should be resolved before 2.0.1 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: isapi_redirect.dll file
Ashley Huang Wanyi wrote: Hello, Can you email me this file isapi_redirect.dll , as i couldn't find it. Thank You. http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.0/bin/win32/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tagging JK2_2_0_1?
Something which should done will be to tag in C sources for use by scandoc (or doxygen). I'll try to do this for jk/native. Comments ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 13241] - Tomcat 4.1.12 / Webapps:Examples/ Disabled
[EMAIL PROTECTED] wrote: 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=13241. 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=13241 Tomcat 4.1.12 / Webapps:Examples / Disabled --- Additional Comments From [EMAIL PROTECTED] 2002-10-03 11:28 --- At this point, I am not using Jikes (at least I haven't got it defined or compiled anywhere in the project). When I downgraded to xerces-1_4_4 rather than use xerces-2_2_0, I am able to get a clean compile and I am able to use the Servlets and JSPExamples page. Looks like there might be a slight problem/incompatability in the xerces-2_2_0 library. Yes, the comment check was not present in previous xerces release (or disabled by default) and I still wonder where digester find problem with --. Any help will be welcomed. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Is Compile Failure? was Re: Need some clarifications
Steve Downey wrote: Actually, with the recent release of commons-logging, we should be able to get rid of the explicit LogKit and Log4J. They're there so as to get a complete build of commons-logging. Tomcat 5 itself doesn't use either directly. Xerces is a different issue. There was a bug that was preventing Tomcat from migrating to the latest version. Unfortunately, I no longer remember the details. Anyone know why we're using 2.1.0 instead of 2.2.0? From what I experienced with Xerces j 2.2.0 it seems it does much more validity check and for instance found a '--' somewhere in comments (1 EUR to the first who find where). Previous version of Xerces or crimson didn't got that problem. if we could see which xml/dtd/tld is reported buggy, which will able to see if it's a bug or a features (ie a more strict check of xml rules) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
No, but extending one dtd would be better than reinventing everything. I will try to make a cleanup as soon as I have time. (docs need a lot of time). I confirm ;-) BTW, any DTD will be fine but we should take a look at what others jakarta and xml projects are using. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [VOTE] Removal of the LE distribution
My opinion on this issue is that Tomcat 5 should have J2SE 1.4 in compliance with JSP 2.0 spec basically. Sorry but making JDK 1.4 mandatory for Tomcat 5 will prevent us to use it on many systems. Many still use IBM SDK and the IBM SDK 1.4 is only available on zSeries. So a big -1 to make JDK 1.4 mandatory for TC5. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [VOTE] Removal of the LE distribution
For example - is JDK1.4 available for BSD or Sparc/Linux or Arm/Linux ? I think BSD and linux are fine operating systems and Tomcat should run on them. And that's not only true for Linux/BSD. For example IBM OS (AIX, OS/2, OS400) have still no JDK 1.4 (and these are not hackers OS ;) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Is Compile Failure? was Re: Need some clarifications
Steve Downey wrote: On Thursday 03 October 2002 12:14 pm, Henri Gomez wrote: Steve Downey wrote: Actually, with the recent release of commons-logging, we should be able to get rid of the explicit LogKit and Log4J. They're there so as to get a complete build of commons-logging. Tomcat 5 itself doesn't use either directly. Xerces is a different issue. There was a bug that was preventing Tomcat from migrating to the latest version. Unfortunately, I no longer remember the details. Anyone know why we're using 2.1.0 instead of 2.2.0? From what I experienced with Xerces j 2.2.0 it seems it does much more validity check and for instance found a '--' somewhere in comments (1 EUR to the first who find where). Previous version of Xerces or crimson didn't got that problem. if we could see which xml/dtd/tld is reported buggy, which will able to see if it's a bug or a features (ie a more strict check of xml rules) OK, from the 'this shouldn't work department', this patch 'fixes' the problem: Index: ./jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd === RCS file: /home/cvspublic/jakarta-servletapi-5/jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 web-jsptaglibrary_1_2.dtd --- ./jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd13 Aug 2002 16:20:58 - 1.1.1.1 +++ ./jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd3 Oct 2002 20:42:30 - @@ -304,6 +304,7 @@ java.lang.String is default. declare Whether the variable is declared or not. + True is the default. scopeThe scope of the scripting varaible Something quite strange is going on. You just add an empty line in this dtd and it works now ? I was thinking it could be with -- in some dtd, ie line in web-app_2_3.dtd : !-- Copyright 2000-2001 Sun Microsystems, Inc. 901 San Antonio Road, Palo Alto, CA 94303, U.S.A. All rights reserved. This product or document is protected by copyright and distributed under licenses restricting its use, copying, distribution, and decompilation. No part of this product or documentation may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Third party software, including font technology, is copyrighted and licensed from Sun suppliers. Sun, Sun Microsystems, the Sun Logo, Solaris, Java, JavaServer Pages, Java Naming and Directory Interface, JDBC, JDK, JavaMail and Enterprise JavaBeans, are trademarks or registered trademarks of Sun Microsystems, Inc in the U.S. and other countries. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the U.S. and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc. PostScript is a registered trademark of Adobe Systems, Inc. Federal Acquisitions: Commercial Software - Government Users Subject to Standard License Terms and Conditions. DOCUMENTATION IS PROVIDED AS IS AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID. _ Copyright 2000-2001 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA 94303, Etats-Unis. Tous droits re'serve's. Ce produit ou document est prote'ge' par un copyright et distribue' avec des licences qui en restreignent l'utilisation, la copie, la distribution, et la de'compilation. Aucune partie de ce produit ou de sa documentation associe'e ne peut e^tre reproduite sous aucune forme, par quelque moyen que ce soit, sans l'autorisation pre'alable et e'crite de Sun et de ses bailleurs de licence, s'il y en a. Le logiciel de'tenu par des tiers, et qui comprend la technologie relative aux polices de caracte`res, est prote'ge' par un copyright et licencie' par des fournisseurs de Sun. Sun, Sun Microsystems, le logo Sun, Solaris, Java, JavaServer Pages, Java Naming and Directory Interface, JDBC, JDK, JavaMail, et Enterprise JavaBeans, sont des marques de fabrique ou des marques de'pose'es de Sun Microsystems, Inc. aux Etats-Unis et dans d'autres pays. Toutes les marques SPARC sont utilise'es sous licence et sont des marques de fabrique ou des marques de'pose'es de SPARC International, Inc. aux Etats-Unis et dans d'autres pays. Les produits portant les marques SPARC sont base's sur une architecture de'veloppe'e par Sun Microsystems, Inc. Postcript est une marque enregistre'e d'Adobe Systems Inc. LA DOCUMENTATION EST FOURNIE EN L'ETAT ET TOUTES AUTRES CONDITIONS, DECLARATIONS ET GARANTIES EXPRESSES OU TACITES SONT FORMELLEMENT EXCLUES, DANS LA
Re: [5.0] [VOTE] Removal of the LE distribution
Remy Maucherat wrote: Hi all, Before starting to release 5.0.x milestones, I would like to propose having only one distribution for Tomcat 5.0.x, and standardize on what the LE distribution contains (so well, it's more the other distribution which gets removed). It has some advantages: - it is slightly smaller (less these days now that the XML parser has to be shipped again with Tomcat) - runs as-is on JDK 1.3 (because of the Xerces inclusion) - 99% Apache or Apache-style licence (the JDBC 2 standard extension is needed for JDK 1.3 DataSource support :-() - less user confusion The main problem is that the user will need additional downloads for some of the more advanced features, and the package will also not run on JDK 1.2 as is (but from what I've seen, JDK 1.2 compatibility may not be a priority for developers). ballot +1 [ ] Yes, remove the LE distribution -1 [ ] No, keep both distributions /ballot I'm OK till we could add easily missing stuff to make Tomcat 5.0 works. It's exactly what we does in jpackage.org project in our 'strict' distribution. There is 3 set of distro for Tomcat 4.1.12 RPMS : - One is the full distro, including everything, so it's the same that jakarta-tomcat-4.1.12.tar.gz - Second one is the LE distro, ie without XML parser, JDBC-STDEXT, ACTIVATION, JTA, MAIL, JAAS, JNDI. In this case at install time, rpm install via symlink XML stuff (parser/apis) from a known location (/usr/share/java). The other components activation, mail, jdbc-stdext, jaas and jndi should be installed by users. - In the strict mode, only tomcat jars, ie all jars (including jakarta-commons-*, servlet.jar, mx4j), should be present at rpm install time and will be automatically installed via symlink in tomcat directories. So I'm fine with having a single tomcat distribution, if we explains users WHERE it could find the missing jars. And having a Tomcat 5.0 containing only 100% OSS stuffs seems natural for an ASF project. BTW, support should be added in TC 5.0 to detect missing jars, ie JDBC-EXT, JNDI, JAAS, and automatically (with reports log) remove functionalities. Regards -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0 build.properties.sample
[EMAIL PROTECTED] wrote:
jfclere 2002/10/04 01:46:33
Modified:.build.properties.sample
Log:
Upgrade to the lastest xerces.
Revision ChangesPath
1.52 +3 -3 jakarta-tomcat-4.0/build.properties.sample
Index: build.properties.sample
===
RCS file: /home/cvs/jakarta-tomcat-4.0/build.properties.sample,v
retrieving revision 1.51
retrieving revision 1.52
diff -u -r1.51 -r1.52
--- build.properties.sample 4 Oct 2002 08:43:48 - 1.51
+++ build.properties.sample 4 Oct 2002 08:46:33 - 1.52
@@ -117,9 +117,9 @@
# - Xerces XML Parser, version 2.0.0 or later -
# Note: Optional with JDK 1.4+, or if Xerces 1.x is present
-xerces.home=${base.path}/xerces-2_1_0
+xerces.home=${base.path}/xerces-2_2_0
xerces.lib=${xerces.home}
-xerces.loc=http://xml.apache.org/dist/xerces-j/Xerces-J-bin.2.1.0.tar.gz
+xerces.loc=http://xml.apache.org/dist/xerces-j/Xerces-J-bin.2.2.0.tar.gz
xercesImpl.jar=${xerces.lib}/xercesImpl.jar
xmlParserAPIs.jar=${xerces.lib}/xmlParserAPIs.jar
Shouln't we stay with xerces 2.1.0 until we found the problem with 2.2.0 ?
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Apache 2.0.43 is out
Henri Gomez wrote: We should provide new binaries for JK and JK2. I'll do JK/JK2 for Linux boxes (and FreeBSD) Who could do the same for Windows, Netware and Solaris ? BTW, I'm still waiting an account on moof to build a MacOSX version. It seems that the Magic Module Number didn't change between 2.0.42 and 2.0.43 so the modules built on 2.0.42 works also on 2.0.43. But rpm requires same versions, so I'll release new rpms for 2.0.43 (apache 2.0.43 rpm being uploaded to falsehope.com). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0 build.properties.sample
jean-frederic clere wrote:
Henri Gomez wrote:
[EMAIL PROTECTED] wrote:
jfclere 2002/10/04 01:46:33
Modified:.build.properties.sample
Log:
Upgrade to the lastest xerces.
Revision ChangesPath
1.52 +3 -3 jakarta-tomcat-4.0/build.properties.sample
Index: build.properties.sample
===
RCS file: /home/cvs/jakarta-tomcat-4.0/build.properties.sample,v
retrieving revision 1.51
retrieving revision 1.52
diff -u -r1.51 -r1.52
--- build.properties.sample4 Oct 2002 08:43:48 -1.51
+++ build.properties.sample4 Oct 2002 08:46:33 -1.52
@@ -117,9 +117,9 @@
# - Xerces XML Parser, version 2.0.0 or later -
# Note: Optional with JDK 1.4+, or if Xerces 1.x is present
-xerces.home=${base.path}/xerces-2_1_0
+xerces.home=${base.path}/xerces-2_2_0
xerces.lib=${xerces.home}
-xerces.loc=http://xml.apache.org/dist/xerces-j/Xerces-J-bin.2.1.0.tar.gz
+xerces.loc=http://xml.apache.org/dist/xerces-j/Xerces-J-bin.2.2.0.tar.gz
xercesImpl.jar=${xerces.lib}/xercesImpl.jar
xmlParserAPIs.jar=${xerces.lib}/xmlParserAPIs.jar
Shouln't we stay with xerces 2.1.0 until we found the problem with
2.2.0 ?
yep, 2.1.0 moved to :
http://xml.apache.org/dist/xerces-j/old_xerces2/
Did someone contacted Xerces Team about our problem of comment checking ?
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0 build.properties.sample
Did someone contacted Xerces Team about our problem of comment checking ? No, and I have another problem probably due to 2.2.0: ant didn't find you Xalan 2.4.0 jar ? Is it in ant/lib ? build-main: [style] DEPRECATED - xslp processor is deprecated. Use trax or xalan instead. [style] java.lang.NoClassDefFoundError: com/kvisco/xsl/XSLProcessor [style] at org.apache.tools.ant.taskdefs.optional.XslpLiaison.init(XslpLiaison.java:80) [style] at java.lang.Class.newInstance0(Native Method) [style] at java.lang.Class.newInstance(Class.java:232) [style] at org.apache.tools.ant.taskdefs.XSLTProcess.resolveProcessor(XSLTProcess.java:376) [style] at org.apache.tools.ant.taskdefs.XSLTProcess.getLiaison(XSLTProcess.java:557) [style] at org.apache.tools.ant.taskdefs.XSLTProcess.execute(XSLTProcess.java:195) [style] at org.apache.tools.ant.Task.perform(Task.java:319) [style] at org.apache.tools.ant.Target.execute(Target.java:309) [style] at org.apache.tools.ant.Target.performTasks(Target.java:336) [style] at org.apache.tools.ant.Project.executeTarget(Project.java:1306) [style] at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:371) [style] at org.apache.tools.ant.Task.perform(Task.java:319) [style] at org.apache.tools.ant.Target.execute(Target.java:309) [style] at org.apache.tools.ant.Target.performTasks(Target.java:336) [style] at org.apache.tools.ant.Project.executeTarget(Project.java:1306) [style] at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:371) [style] at org.apache.tools.ant.Task.perform(Task.java:319) [style] at org.apache.tools.ant.Target.execute(Target.java:309) [style] at org.apache.tools.ant.Target.performTasks(Target.java:336) [style] at org.apache.tools.ant.Project.executeTarget(Project.java:1306) [style] at org.apache.tools.ant.Project.executeTargets(Project.java:1250) [style] at org.apache.tools.ant.Main.runBuild(Main.java:610) [style] at org.apache.tools.ant.Main.start(Main.java:196) [style] at org.apache.tools.ant.Main.main(Main.java:235) [style] java.lang.NoClassDefFoundError: org/apache/xalan/xslt/XSLTProcessorFactory [style] at org.apache.tools.ant.taskdefs.optional.XalanLiaison.init(XalanLiaison.java:84) [style] at java.lang.Class.newInstance0(Native Method) [style] at java.lang.Class.newInstance(Class.java:232) [style] at org.apache.tools.ant.taskdefs.XSLTProcess.resolveProcessor(XSLTProcess.java:379) [style] at org.apache.tools.ant.taskdefs.XSLTProcess.getLiaison(XSLTProcess.java:554) [style] at org.apache.tools.ant.taskdefs.XSLTProcess.execute(XSLTProcess.java:195) [style] at org.apache.tools.ant.Task.perform(Task.java:319) [style] at org.apache.tools.ant.Target.execute(Target.java:309) [style] at org.apache.tools.ant.Target.performTasks(Target.java:336) [style] at org.apache.tools.ant.Project.executeTarget(Project.java:1306) [style] at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:371) [style] at org.apache.tools.ant.Task.perform(Task.java:319) [style] at org.apache.tools.ant.Target.execute(Target.java:309) [style] at org.apache.tools.ant.Target.performTasks(Target.java:336) [style] at org.apache.tools.ant.Project.executeTarget(Project.java:1306) [style] at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:371) [style] at org.apache.tools.ant.Task.perform(Task.java:319) [style] at org.apache.tools.ant.Target.execute(Target.java:309) [style] at org.apache.tools.ant.Target.performTasks(Target.java:336) [style] at org.apache.tools.ant.Project.executeTarget(Project.java:1306) [style] at org.apache.tools.ant.Project.executeTargets(Project.java:1250) [style] at org.apache.tools.ant.Main.runBuild(Main.java:610) [style] at org.apache.tools.ant.Main.start(Main.java:196) [style] at org.apache.tools.ant.Main.main(Main.java:235) BUILD FAILED file:/home6/clere/jakarta-tomcat-4.1.12-src/webapps/tomcat-docs/build.xml:82: javax.xml.transform.TransformerFactoryConfigurationError: Provider for javax.xml.transform.TransformerFactory cannot be found +++ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0 build.properties.sample
Ooops that has nothing to do with xerces but the ant installation: xalan was missing in my installation... That's what I thinked (cf my prev message) ;-) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JK 1.2.0 binaries for iSeries
Well it may be a premiere on Apache.
You could find an iSeries binary at:
http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.0/bin/iseries/
It's an OS400 SAVF, built on V5R1, but should works on V5R2,
which is zipped to save place.
On V5R1/V5R2 you should have the latest Apache 2.0 PTFs installed, the
one's which provide Apache 2.0.39.
Quicks instructions :
- Unzip MOD_JK.zip on you workstation (PC/Unix) and will get a MOD_JK.SAVF.
- Go to iSeries, create a SAVF enveloppe, ie :
CRTSAVF FILE(MYLIB/MOD_JK) TEXT('MOD_JK VERSION 1.2.0 iSeries')
- Send the MOD_JK file via ftp in binary into MYLIB.
- on iSeries restore SAVF :
RSTLIB SAVLIB(MOD_JK) DEV(*SAVF) SAVF(MYLIB/MOD_JK)
- You could use the new MOD_JK Apache module from the MOD_JK
library :
# Apache Default server configuration
# LoadModule jk_module /QSYS.LIB/QHTTPSVR.LIB/QZTCJK.SRVPGM
LoadModule jk_module /QSYS.LIB/MOD_JK.LIB/MOD_JK.SRVPGM
- Or if you want to have it next to others Apache modules,
you should copy the MOD_JK.SRVPGM to iSeries Apache 2.0.39
module library :
CRTDUPOBJ OBJ(MOD_JK) FROMLIB(MOD_JK) OBJTYPE(*SRVPGM)
TOLIB(QHTTPSVR) NEWOBJ(MOD_JK)
MOD_JK SRVPGM is now installed on iSeries Apache modules :
- You should next add MOD_JK module to one of your Apache Server
instance by editing the Server Configuration and commenting
IBM provided MOD_JK (QZTCJK.SRVPGM)
# Apache Default server configuration
# LoadModule jk_module /QSYS.LIB/QHTTPSVR.LIB/QZTCJK.SRVPGM
LoadModule jk_module /QSYS.LIB/QHTTPSVR.LIB/MOD_JK.SRVPGM
...
I recommand you to read the documentation about configuring
Apache 2.0 on iSeries at :
http://www-1.ibm.com/servers/eserver/iseries/software/http/product/gui.html
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JK 1.2.0 updated mod_jk-1.3-noeapi.so for Linux/i386 uploaded
I sent a new build of mod_jk-1.3-noeapi.so which has been built against Apache 1.3.22 without mod_ssl. Thanks to Gary Henson to report the problem. NB: eapi / noeapi files size is different eapi = 386010 noeapi = 386078 Regards -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JK2 linux binaries available
Hi to all, JK 2.0.0 beta binaries for Linux are ready : http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/release/v2.0.0/bin/linux/i386/ rpm are also available (built on Redhat 7.2 + updates + Apache 1.3.22 (mod_ssl) and Apache 2.0.42) http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/release/v2.0.0/rpms/ Regards Apache 2.0.42 rpms are available : http://ftp.falsehope.com/home/gomez/apache2 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Apache 2.0.43 and JK/JK2
You should know that Apache 2.0.43 as been released to fix security failures. The JK and JK2 connectors who has been built under 2.0.42 will WORKS with 2.0.43, no need to recompile anything. For rpms users, I've uploaded new JK and JK2 rpms to be used against 2.0.43 since rpm requires to have an apache 2 matching the one which with the mod_jk has been built : JK : mod_jk-ap20-1.2.0-1jpp.i386.rpmis for Apache 2.0.42 mod_jk-ap20-1.2.0-2jpp.i386.rpmis for Apache 2.0.43 http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.0/rpms/ JK2 : mod_jk-ap20-1.2.0-1jpp.i386.rpm is for Apache 2.0.42 mod_jk-ap20-1.2.0-2jpp.i386.rpm is for Apache 2.0.43 http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/release/v2.0.0/rpms/ Regards PS: As usually RPM for Apache 2.0.42/2.0.43 are at falsehope.com : http://ftp.falsehope.com/home/gomez/apache2/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 13300] - Incorrect system id's in variousxml files
[EMAIL PROTECTED] wrote: 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=13300. 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=13300 Incorrect system id's in various xml files Did someone take a look at Ville patches ? It works with me on jpackage.org and make some debugginh to see how to fix tc 4.1.12 and xerces-2.2.0 problem. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [ANNOUNCEMENT] JK2 Released as 2.0.1
Mladen Turk wrote: Hi all, The Jakarta-Tomcat-Connector team is pleased to announce the availability of JK2 2.0.1. Binaries and source versions of the release are available and can be downloaded from : http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/release/v 2.0.1/ I copied jk/jk2 docs in docs dir from the one generated by JFC. http://jakarta.apache.org/~jfclere/jk2_docs/ BTW, mladen could you remove olddoc in v2.0.0 release dir ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_ajp13.c
Costin Manolache wrote: Mladen - time for a jk2.0.2 :-) ? I think this was a serious bug - if Nacho confirms the other tests are passing, we need to push it into a milestone. As a note: breaking the ajp connection on error is IMO the best solution for now. If we start doing strong authentication ( i.e. the ajp extensions that Henri proposed ) - then it may be expensive, and we should explore sending an error packet and ignoring all further incoming messages from tomcat. The java side should also check available() before sending any message. That will still avoid the roundtrips. +1 on using error packets. And we should be able to include Error Packets into REQUEST AND REPLIES processing, for example included when a user hit stop when uploading/downloading datas which are larger than 8K... I'll take a look at it, and it should be done in a way which is compatible with current ajp13. The idea will be to determine if we're using an ajp13 extension level 1 (no more ajp14), which support strong authentication and so also error packets in post side (webserver forwarding requests data to tomcat, and tomcat replying to webserver). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JSP 2.0's J2SE 1.4 Requirement
Costin Manolache wrote: iasandcb wrote: Now it's almost clear that SRV 2.4 requires JDK 1.2 and JSP 2.0 does JDK 1.4. The main issue is discrepancy of J2SE requirement between SRV 2.4 and JSP 2.0, which are supposed to come up together. Actually, it isn't. All we know is that the current draft has this requirement. We should find a proper procedure ( for example a vote on tomcat dev ) and then ask our representative in JCP ( Geir for example - he's a very nice person ) to request a change. I don't know what's the proper mechanism yet - but Apache does have a representative and a vote, and we should have a way to have the opinion of tomcat-dev expressed. If the final JSP2.0 will require 1.4 - then we'll have to do that. It would be very unfortunate ( especially for jsp people ), and will require ( IMO ) a separate tomcat without JSPs. My opinion ( and it seems a lot of people have the same opinion ) that portability ( in the sense of beeing able to run on most OS and platforms ) seems to agree with what Apache is doing in most projects ( Apache server runs on more platforms than java - and did that even before 'write once, run everywhere'). We should first explore the alternative for having this opinion confirmed ( vote ? ) and expressed in the expert group. If the EG prefers features over portability - then we need to find a way to create a distribution without JSP ( is this possible ?) and maybe compensate by including cocoon or velocity. +1 here . If Tomcat 5 require JDK 1.4, I'll have to stay with Tomcat 3.3.x or 4.1.x on my Linux and iSeries productions boxes. Could we imagine alternatives ? - Tomcat 5 using Serlvet 2.3/JSP 1.2 ? - Tomcat 5 using Servlet 2.4 and JSP 1.2 ? - Tomcat 5 using Servlet 2.4 and JSP 1.2 or JSP 2.0 depending the JVM found at runtime ? - Tomcat 5 bundled without JSP 2.0 ? - Tomcat 5 bundled with velocity or tea instead of JSP 2.0 ? I'm afraid that making JDK 1.4 mandatory for Tomcat 5 (or JSP 2.0) will delay for a long time its adoption by companies, until all platform got JDK 1.4, which means for example that people which use IBM SDK on Linux or mainframes systems will have to wait up to the end of year ad minima. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
tomcat4 write in conf files which is not FHS compliant
Hi to all, Tomcat 4 make write access to 2 files in the conf directory, jk2.properties and tomcat-users.xml (and may be others). The problem is that FHS indicate that a conf directory should be read only. For instance, tomcat4 rpm install the conf directory in /etc/tomcat4 and use symlink to map it to /var/tomcat4/conf. What could be done to have a behaviour following FHS recommandations ? Could we imagine having jk2.properties and tomcat-users.xml (and other files in conf which may be updated by tomcat4) in another directory, ie work/conf ? Regards -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[POLL/VOTE] tcpnodelay to true by default ?
What about setting tcpnodelay to true by default for Ajp13 connectors java implemtations ? It should fix MacOS X latency problems and should be the default for any persistant connections... Comments welcome... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [POLL/VOTE] tcpnodelay to true by default ?
Costin Manolache wrote: I'm convinced, thank you very much for taking the time to test and analyze this. We should switch the setting in the main branch - not sure if Remy has a branch for 4.1/4.0, and if he has I think he should decide if he wants this backported. If anything happens we can roll back. I'll make the change in JTC for Ajp connectors. I hope we'll hear more from Han Ming in future :-) Hope so, welcome Apple members. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tomcat 4.1.12 rpm release 2 uploaded
A quick note to warn rpms users that rpm release 2 of tomcat 4.1.12 has been released and fix : - fix tomcat4.conf to use /etc/java/java.conf - fix tomcat4 initd to be sure that we'll stop/start the task owner by TOMCAT_USER and running catalina - fix perms on /etc/tomcat4, contents is owned by root.tomcat4, and only jk2.properties and tomcat-users.xml could be updated by tomcat4 user. - change ref and use of xerces-j2.jar by jaxp_parser_impl.jar. - include ant 1.5.1 - remove commons-lang as no more required - copy a correct mod_jk.jpeg Regards -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JK 2.0.1 for Linux (binaries and rpms) uploaded
JK 2.0.1 for Linux i386 binaries and rpms (including sources) are available : http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/release/v2.0.1/bin/linux/i386/ http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/release/v2.0.1/rpms/ Regards -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
apps conversion from 3.3.1 to 4.1.12
Hi to all, While converting some applications from 3.3.1 to 4.1.12 I noticed some little problems. 1) We used to define our own default servlet, but 4.1.x definie its own default in conf/web.xml. Could we change from org.apache.catalina.servlets.DefaultServlet to our actual default servlet, knowing that all webapps use the same code base ? In that case should the jar containing the default servlet could be in common/lib ? 2) We also used to include external entities in web.xml which live outside webapp dir : ie : ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN http://java.sun.com/j2ee/dtds/web-app_2.2.dtd; [ !ENTITY % settings SYSTEM ../../../settings.xml %settings; ] ... Digester find settings.xml only when it's located in WEB-INF or webapp directories (ie ROOT/WEB-INF/settings.xml or ROOT/settings.xml). How could I make it find the settings.xml outside webapps area ? via conf/catalina.policy ? Thanks for you help. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: apps conversion from 3.3.1 to 4.1.12
Remy Maucherat wrote: Henri Gomez wrote: Hi to all, While converting some applications from 3.3.1 to 4.1.12 I noticed some little problems. 1) We used to define our own default servlet, but 4.1.x definie its own default in conf/web.xml. Could we change from org.apache.catalina.servlets.DefaultServlet to our actual default servlet, knowing that all webapps use the same code base ? In that case should the jar containing the default servlet could be in common/lib ? AFAIK, yes. You should be able to put it in shared/lib. The webapp settings also override the global settings. Great. 2) We also used to include external entities in web.xml which live outside webapp dir : ie : ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN http://java.sun.com/j2ee/dtds/web-app_2.2.dtd; [ !ENTITY % settings SYSTEM ../../../settings.xml %settings; ] ... Digester find settings.xml only when it's located in WEB-INF or webapp directories (ie ROOT/WEB-INF/settings.xml or ROOT/settings.xml). How could I make it find the settings.xml outside webapps area ? via conf/catalina.policy ? This is likely the protection against reading anything outside the webapp root (see the allowLinking of FileDirContext), although I don't know how the digester will try to load the included file. I'll check for it, thanks. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/commonChannelSocket.java
[EMAIL PROTECTED] wrote: hgomez 2002/10/08 23:58:31 Modified:jk/java/org/apache/jk/common ChannelSocket.java Log: tcpnodelay to true by default, but could be turned off by Only ChannelSocket need to be updated. Ajp14Interceptor allready called tcpnodelay(true), and other java parts set tcpdelay var to true by default. Regards -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [VOTE] Remove deprecated and unsupported components
Remy Maucherat wrote: The connectors which depend on the org.apache.catalina.connector package (including JK 1, webapp, and the old HTTP connectors) will either need to be updated or removed. The Coyote family of connectors is well supported and provides a suitable replacement (IMO). Coyote is the default connector in the current Tomcat 4.1.x releases, and should be reaching maturity by the time Tomcat 5 is released. I'd like to remove the deprecated org.apache.catalina.connector classes (and move the remaining facade and wrapper classes to other new packages). Even if they are removed from the main tree, the deprecated components could also be distributed with updated versions of the affected connectors should it is decided they should be made available for Tomcat 5 (but in any case, some work will be needed). ballot [X] Remove deprecated org.apache.catalina.connector components from the j-t-catalina module [ ] Leave them in /ballot In case the second option is voted, volunteers will be needed to update and maintain the components (right now, I don't think the connectors based on them would even build against the new API). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: apps conversion from 3.3.1 to 4.1.12
This is likely the protection against reading anything outside the webapp root (see the allowLinking of FileDirContext), although I don't know how the digester will try to load the included file. Digester code is derived from XmlMapper which is able to locate entities in ../../../ directories. My concern here is : Specs didn't mentions restriction on use of external entities outside the webapp. So it should be granted by default isn't it ? I take a look at FileDirContext but I didn't understand what allowLinking is ? So my question is : bug or feature ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
commons-daemon release ?
I wonder if a release of commons-daemon is planned. JF ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: apps conversion from 3.3.1 to 4.1.12
Remy Maucherat wrote: Henri Gomez wrote: This is likely the protection against reading anything outside the webapp root (see the allowLinking of FileDirContext), although I don't know how the digester will try to load the included file. Digester code is derived from XmlMapper which is able to locate entities in ../../../ directories. My concern here is : Specs didn't mentions restriction on use of external entities outside the webapp. So it should be granted by default isn't it ? I take a look at FileDirContext but I didn't understand what allowLinking is ? So my question is : bug or feature ? There's a pretty strict check on the canonical path of a resource which I added. I consider it a security feature. I think a webapp should be self contained, so I think it's reasonable to have the check as the default. allowLinking disables the check. Don't be lazy, just do a search in FileDirContext ;-) I take a look at this but but digester didn't use FileDirContext so the allowLinking didn't fit. The problem seems be only in Digester which fail to load ../../../settings.xml What could we do ? PS: I tried with TC 4.1.x and all commons from CVS. at org.apache.naming.resources.DirContextURLConnection.getInputStream(DirContextURLConnection.java:344) at java.net.URL.openStream(URL.java:793) at org.apache.xerces.impl.XMLEntityManager.startEntity(XMLEntityManager.java:807) at org.apache.xerces.impl.XMLEntityManager.startEntity(XMLEntityManager.java:738) at org.apache.xerces.impl.XMLDTDScannerImpl.startPE(XMLDTDScannerImpl.java:609) at org.apache.xerces.impl.XMLDTDScannerImpl.skipSeparator(XMLDTDScannerImpl.java:1927) at org.apache.xerces.impl.XMLDTDScannerImpl.scanDecls(XMLDTDScannerImpl.java:1889) at org.apache.xerces.impl.XMLDTDScannerImpl.scanDTDInternalSubset(XMLDTDScannerImpl.java:359) at org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(XMLDocumentScannerImpl.java:808) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:329) at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:525) at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:581) at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152) at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1175) at org.apache.commons.digester.Digester.parse(Digester.java:1542) at org.apache.catalina.startup.ContextConfig.applicationConfig(ContextConfig.java:282) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:639) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3567) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardHost.start(StandardHost.java:738) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347) at org.apache.catalina.core.StandardService.start(StandardService.java:497) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: apps conversion from 3.3.1 to 4.1.12
org.apache.naming.resources.DirContextURLConnection.getInputStream(DirContextURLConnection.java:344) at java.net.URL.openStream(URL.java:793) Well, that's exactly the same. Where do you think that weird URL connection goes ?? (hint: to the aforementioned FileDirContext, through some classloader binding) Well it's my initial diggs in TC 4.1.x, let me some time to discover it. The place where it gets rejected should be the FileDirContext.file() method, as far as I can remember. FileDirContext.file() is used to get webapps/ROOT/web.xml ref and validate access, but the external entity is grabbed from Digester so outside FileDirContext control (from my debug analyze). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: apps conversion from 3.3.1 to 4.1.12
Haven't looked at the code, but here's a couple of thoughts that might help: If your path above (../../../settings.xml) is attempting to go above the context root of the webapp, it's pretty much guaranteed to fail because of the security restrictions. Undoing that restriction would just create a bunch of CERT reports about Tomcat letting you browse the entire directory structure of your disk. I agree but the ../../../settings.xml was set in web.xml, under administrator control, and tomcat can't even overwrite it. We've got another problem here since Tomcat 3.3.x allow this and but Tomcat 4.1.x prevent it. Should we fix Tomcat 3.3.2 ? One of the important enablers for using external entity files in Digester is to use the Digester.parse() that takes an InputSource (rather than an InputStream), and be sure you have configured your InputSource to include the source URL. That is necessary for the XML parser to be able to resolve relative system ids. The code in ContextConfig that parses web.xml and TLD files was modified (a while back) to do this kind of thing, if you need an example. Didn't have access on it since the external entity is set in web.xml so under org.apache.catalina.startup.ContextConfig.applicationConfig control, not application control. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: apps conversion from 3.3.1 to 4.1.12
If this reference is in your web.xml file, then my suggestion is already being done. To test it, try temporarily copying the settings.xml file into the WEB-INF directory and changing the relative URL appropriately. Putting the file in WEB-INF works, even if I use ../settings, ie directly in webapps/ROOT. I'd be -1 on removing the security check in 4.x/5.x. Fixing 3.3.2 sounds like a good idea. I'll be -1 to fix the 3.3.2 for many reasons : - It will brake all deployment strategy - I'm still not sure it's a security problem since nobody prevent you to change to PUBLIC and goes outside : !ENTITY % settings SYSTEM ../../../settings.xml %settings; to !ENTITY % settings PUBLIC hackme http://hackme.com/settings.xml; %settings; That's more than insecure isn't it ? I take a look in specs and didn't see anything preventing you to have entities located outside WEBAPP so I feel it's a regression and not a security feature. Ad minima, in TC 4.x and 5.x, there should be a setting in web.xml, or server.xml to enable this behaviour even if it's prevented by default. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.1.12: Xerces 2.2 problems - Struts 1.0.2 bug.
Jean-Francois Arcand wrote: Hi, with Tomcat 4.1.12, Xerces 2.2 is throwing the following exception: org.xml.sax.SAXParseException: The string -- is not permitted within comments. at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) This is a bug in the org.apache.struts.digester.Digester class. If you uses Struts 1.1 beta 2 jar file, the bug will not happen. Xerces 2.2 generates a lot of Warnings and the Digester version of Struts 1.0.2 logs an exception instead of a warning. This has been corrected in the current Digester (1.3) we are using. You means in the struts implementation of Digester ? So we have to decide which combinaison we want to support with 4.1.x: 4.1.x = Xerces 2.1 + Struts 1.0.2 5.x = Xerces 2.2 + Struts 1.1b2 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jk2 and daemon ( was Re: commons-daemon release ?)
Pier Fumagalli wrote: On 11/10/02 3:14, Jon Scott Stevens [EMAIL PROTECTED] wrote: on 2002/10/10 6:50 PM, Pier Fumagalli [EMAIL PROTECTED] wrote: I can tell you that our main Java instance for VNUNET.COM takes approximately 4 to 5 minutes to start... OUCH. Our main web-app has roughly 400 JSP pages to compile (you never know), 20 servlets loaded on startup, 4 lucene indexes to open, 500 connections to the database, 350/400 megabytes of cached objects to de-serialize and put down into memory, and some initial synchronization checks with the DB to find out what are the articles that need to be displayed first (articles ranking) out of an history of some hundred thousand of them (all on line)... It is a big bubba, the JVM memory size is somewhat in the range of 640 Mb... :-) (and it's just 1 web-application out of 6) Only problem? Tomcat doesn't scale that high :-( Couldn't you split the load on different tomcat engines and use for JK for example to spray the load ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jk2 and daemon ( was Re: commons-daemon release ?)
Costin Manolache wrote: Pier Fumagalli wrote: Costin Manolache [EMAIL PROTECTED] wrote: - starting a VM using exec / monitor the child process. It is not implemented yet in jk2 - but pretty important ( it's one of the features from jserv that wasn't yet ported). It seems daemon has a bit of code - as I mentioned from reading it I don't think it works, and it would be better to use the code from jserv for this - whenever we do implement this. That was the feature which created more problems in JServ... I remember me and Ed hammering on it for months in 97/98. My hint, forget about it, also because if you tie it to the web server process, when you take down the Web Server, also your servlet engine is going to go down, and that's not a very desirable feature given how much time it takes to initialize 7/8 web applications I know about this - and I wasn't thinking to implement it in the same way ( i.e. have the web server directly start/stop tomcat ). The 'feature' is that all tomcat processes ( and you may run more than one in a load balanced mode ) can be started automatically and monitored. If one dies, it'll be automatically restarted. What do you plan to use to do the real-time monitoring ? Threads embedded in Apache 2.0 or will Apache 2.0 execing daemon/service monitors which in turn launch and monitor the JVM ? To make things interesting, this information ( and other like that ) needs to be communicated to apache servers ( to stop sending requests to not-ready servers ), and potentially to an eventual JMX proxy. This is the kind of 'control channel' that was proposed several times and will have to be implemented for other purposes. Ajp13++ ? Well with that proposal, we'll be very similar to WebSphere for example, which have such features, and allow a sysadmin to launch instance (JVM) from a single control panel. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] tomcat-commiters list
Costin Manolache wrote: I would like to propose a new mailing list. The list will be closed to commiters only. The main purpose will be discussions of security and other special issues. This should avoid [Cc] threads. The main target should be active commiters - so it should start empty. This is a majority vote. [ ] I agree with the proposal [ ] I don't agree with the proposal I agree if it cover only discussions about security, but discussions and features should stay in tomcat-dev. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
TC 3.3.x - TC 4.1.x : more questions (argh)
Did there is a way to specify a context loading order. ie : ROOT, then app1, app2, zorg1, app3 ? Regards PS: It's the case in TC 3.3, and settings context in server.xml in 4.1.12 didn't seems to works, TC 4.1.x loading context in alphabetically order -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Newbie] Need some help
Todd Cary wrote: I currently have PHP running on my Linux learning server along with Apache. Though I have been programming for a living since 1973, my knowledge of Java, how serverside Java works, how to implement JSP is nil. Is there some documentation that can get me started without overloading me with a plethora if details? I would like to install TomCat on my RH Linux server, but the Install docs are rather daunting.. You should go to tomcat-user list and since you're using RH Linux, take a look at the rpm available at : http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.12/rpms/ Regards -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Newbie] Need some help
Henri Gomez wrote: Todd Cary wrote: I currently have PHP running on my Linux learning server along with Apache. Though I have been programming for a living since 1973, my knowledge of Java, how serverside Java works, how to implement JSP is nil. Is there some documentation that can get me started without overloading me with a plethora if details? I would like to install TomCat on my RH Linux server, but the Install docs are rather daunting.. You should go to tomcat-user list I mean, tomcat-user list which be able to provide much more users informations and experience than tomcat-dev which is focused on tomcat developpement. Regards ;) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Context loading order in TC 4.1/5 ?
How did I specify a context loading order with Tomcat 4.1/5 ? ie : ROOT, then app1, app2, zorg1, app3 ? In tomcat 3.3.1, it was easy by adding Context ... in server.xml, but it seems that TC 4.1.x didn't follow the order of appareance in its server.xml. Thanks for your advices ;) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Possible mod_jk patch with ap_get_server_name
[EMAIL PROTECTED] wrote: Hi, I am a new subscriber and have a potential patch to mod_jk. It uses the apache api to get the s-servername value. This has a benefit in that is pays attention to the UseCanonicalName setting within apache. So if a site has lots of ServerAlias entries only 1 entry in server.xml is needed if UseCanonicalName is on for that VirtualHost. The patch was against the jakarta-tomcat-connectors-4.1.12 source I downloaded and I have tested it with Apache/1.3.26 and Tomcat 3.2.3 in a virtual hosted situation with some vhosts enabled via UseCanonicalName and some not. Comments welcome, it seems to work fine. --- mod_jk.c.orig Thu Oct 17 18:06:21 2002 +++ mod_jk.cThu Oct 17 18:07:06 2002 @@ -466,7 +466,7 @@ s-remote_host = NULL_FOR_EMPTY(s-remote_host); s-remote_addr = NULL_FOR_EMPTY(r-connection-remote_ip); -s-server_name = (char *)(r-hostname ? r-hostname : r-server- server_hostname); +s-server_name = ap_get_server_name(r); s-server_port = htons( r-connection-local_addr.sin_port ); s-server_software = (char *)ap_get_server_version(); It's seems correct. JF, Mladen what do you think ? -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [5]: ant native for Connectors fails:
Brzezinski, Paul J wrote: Trying to build Jakarta Tomcat Connectors from 5.0.0 source: In jakarta-tomcat-connectors/jk Ant native complains about cc not being found, on Solaris 8, I have gcc in /em/opt/bin/gcc. I have no idea how to tell ant that it should use gcc or /em/opt/bin/gcc instead of cc, and no idea how to configure the args to libtool that it should gcc instead of cc. I'd like to figure this out, but need assistance. Assuming this isn't a known bug, is this something that should be reported as a bug using bugzilla? You could put /em/opt/bin/ in PATH before compiling ? export PATH=/em/opt/bin:$PATH Or set the ant project property : buid.native.cc=/em/opt/bin/gcc -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Vote results + Security Audit redirection
For what it's worth, I'm not disagreeing that there needs to be another list. Clearly, really serious security issues should at least be delayed from being made public. However, I think there needs to be a bit more paranoia about how this list manifests itself. Any behind closed doors discussions have the potential for alienating the non-committer community. Determining what conversations are appropriate for this other list is a very slippery slope. It's already been proposed that votes for new committers be discussed there first. What's next? And if the other list starts being used for determining what should be discussed on the other list, it's all over. Sort of like the U.S. congress being in charge of their own pay raises. As a commiter I voted +1 if the discussions on the list where ONLY about security and not features and others devel related subjects. It shouldn't be a 'behind closed doors' discussion area. As a non-committer but long-time subscriber to this list, my opinion is that _all_ messages on the other list must absolutely show up here eventually, at some delay. Otherwise, there is no longer any transparency. (This is also the biggest reason it's better than CCed e-mails; because the messages will always be public at some point.) Since the discussion will be about security, we could send a digest in the CVS fixes as soon as the thread has been closed and problems fixed. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Possible mod_jk patch with ap_get_server_name
Mladen Turk wrote: -Original Message- From: Henri Gomez +s-server_name = ap_get_server_name(r); s-server_port = htons( r-connection-local_addr.sin_port ); s-server_software = (char *)ap_get_server_version(); It's seems correct. JF, Mladen what do you think ? Beter use the following: s-server_name = ap_get_server_name(r); s-server_port = ap_get_server_port(r); That's how it's done on JK2. Ok, commited to jk 1.2.1-dev, for Apache 1.3 and 2.0. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: mime settings for SVG in TC4/5 ?
I didn't see the mime settings for SVG format in TC 4/5 (and didn't see it also on Apache 1.3/2.0). I added the following : image/svg+xml svg image/svg+xml svgz More info from new http list : http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12241 Regards -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [PROPOSAL] JK2 uriMap using native regex
Costin Manolache wrote: Something like that was discussed on commons ( I think ). The problem seems to be that different regex packages use different rules ( Perl-like, etc ), there is not standard syntax for regexp. That means the behavior would be dependent on which regexp engine is used. I would rather pick one and use it, and deal with the build problems. Probably we should just use what apache uses, it seems like a reusable piece of code. Other opinions ? We should use a regexp implementation which use a synthax similar to the one in Apache 1.3/2.0. And as for APR/SHM, make it build/run conditional if possible. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
mime settings for SVG in TC4/5 ?
I didn't see the mime settings for SVG format in TC 4/5 (and didn't see it also on Apache 1.3/2.0). I added the following : image/svg+xml svg image/svg+xml svgz I'll send a mail to new httpd team. Regards -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [Off-topic] FYI Xerces 2.2
Jean-Francois Arcand wrote: HI, just a quick update with Xerces 2.2. Two weeks ago, I tough I've found the problem Tomcat was having with Xerces 2,2 (by replacing struts.jar file with the 1.1 beta version, the bug did not show up again). I did some tests last week and the bug starts to re-appear, but not all the time (sometimes 10 runs works fine). First I was under the impression it was a bug in Digester, but that was a wrong assumption. I have discussed the issue with the Xerces team and sent a small test case to them that reproduce consistently the bug. They have changed the threading model in Xerces 2.2 and, IMO, seems to be the cause (thread race). The bug doesn't occurs all the time, but the struts-config.xml is the perfect candidate to reproduce the problem. More news to come :-) Thanks for the feed back ;) -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: IIS JK Connector.
Steven Velez wrote: I have run in to a problem using the JK (version 1) connector for IIS in conjunction with an ISAPI filter put out in closed source. Basically, this other filter randomly deletes request headers for some reason and that interrupts the communication between the filter and the extension that implement the JK connector. I was planning on working around this problem by passing request information from the filter to the extension using shared memory (using a lookup table and passing the index in the query string). However, I was wondering if the patch would be more likely to be accepted if the new mechanism was enabled via a configuration option (or compile setting) or if I could just go ahead make that the communication mechanism. Also, is there a place I can go to read the coding standards for Jakarta, C-language projects? The place is on apache.org, coding standards. http://www.apache.org/dev/styleguide.html -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: IIS JK Connector.
Mladen Turk wrote: -Original Message- From: Henri Gomez The place is on apache.org, coding standards. http://www.apache.org/dev/styleguide.html So why don't we follow that ;). Well it's a pretty long story ;-) -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: DO NOT REPLY [Bug 13827] - mod_jk load balancing does notset proper JSESSIONID with tomcat 4.x
[EMAIL PROTECTED] wrote: 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=13827. 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=13827 mod_jk load balancing does not set proper JSESSIONID with tomcat 4.x The jmvroute, which was present in TC 3.3.1, is not found in JTC. Shouldn't it be added ? -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: DO NOT REPLY [Bug 13827] - mod_jk load balancing does notset proper JSESSIONID with tomcat 4.x
[EMAIL PROTECTED] wrote: 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=13827. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. --- Additional Comments From [EMAIL PROTECTED] 2002-10-22 07:58 --- This looks invalid. You need to set the jvmRoute attribute on the Engine element. Right, I didn't see the ref on jvmroute in documentation : http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/jk.html http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/engine.html I'll add it as comment in server.xml to help users locate it -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: 4.0.7 release?
Jon Scott Stevens wrote: on 2002/10/24 1:12 AM, Henri Gomez [EMAIL PROTECTED] wrote: Do you plan to make scarab works with 4.1.x ? Read: http://scarab.tigris.org/faq.html Blame the Xerces team for breaking backwards compatibility. Bah. Ok, so we should wait an updated version of Scarab ? -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [JK2] RedHat 8.0 JNI totaly bogus
Mladen Turk wrote: -Original Message- From: Henri Gomez I didn't tried RH 8.0 yet, but the experience I've got from RH 7.2 with JNI make me some serious headaches. Before launching Apache 2.0 you need : 1) set the LD_LIBRARY_PATH export LD_LIBRARY_PATH=$jre/bin:$jre/bin/classic:$LD_LIBRARY_PATH Thanks man, that's the cache! Did it works now ? For 1.4.1/RH8: export LD_LIBRARY_PATH=$JAVA_HOME/jre/lib/i386:$JAVA_HOME/jre/lib/i386/client:$ LD_LIBRARY_PATH 2) make JDK use the non floating stacks export LD_ASSUME_KERNEL=2.2.5 No need for that to start the JVM, but will check how it works. There is good information about floating stack in IBM SDK But important: 'which java' _must_ point to the jre/bin/java so jre's path has to precede jdk one, like $JAVA_HOME/jre/bin:$JAVA_HOME/bin Are you using IBM, Sun or Blackdown SDK ? -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: dos xml files in 4.1.12
jean-frederic clere wrote: Hi, I have noted that some files of the http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.12/bin/jakarta-tomcat-4.1.12.tar.gz are in msdos format. For example: webapps/ROOT/WEB-INF/web.xml but others are OK like: conf/tomcat-users.xml Remy is a windows users ;) -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: TOMCAT memory usage : how to manage and benchmark ?
Pier Fumagalli wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: So, My first question is : why tomcat use all the memory while there is no users connected (or just one) ? You should first see if your application is not eating memory. My second question is : how much memory is needed if I want to use tomcat with many users (500, 1000,...) ? The question should be 'how many concurrents users' ? On a 5 millions hits/day server (not running Tomcat, another servlet container since Tomcat doesn't work for us), we have the VM starting with 1 Gigs of RAM (java -server -Xmx 1024m -Xms 1024m ...) but we use half of it (roughly) to cache data from the DB... I already read in the forum Tomcat don't manage the memory, it is the JVM... so why the jvm use so many processes ? Also you could have many threads if you're using ajp13 connectivity since there is one thread by connection with server. Those are _not_ processes, they are threads... Use a decent operating system that supports them nicely (not Linux) and you'll see the difference (how many times do I have to repeat this?)... Linux sucks :-( On Linux threads are +/- process and are really cheap to create, so it's should be a problem. And if you have problem handling load with one Linux boxes, just use more Linux boxes and use jk load-balancing to spray the load. I never find Linux to suck, it's really depend on which architecture it run, and what you want to do with it. You could quickly start a small tomcat handling 50 concurrents users on recent ia32 boxes, multiply the number of boxes when the load increase, and use software load-balancing/fault-tolerance features of JK to make the tomcat/linux farm works well better than high-end (and pricy Unix workstations). With a very good performance/buck ratio ;) -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: TOMCAT memory usage : how to manage and benchmark ?
On Linux threads are +/- process and are really cheap to create, so it's should be a problem. Read, it shouldn't be a problem -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
