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: [VOTE] JK2 2.1
Henri Gomez wrote: 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 For the moment that is not the case. For example you may need an APR with threads and another without. 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. We should ask httpd dev list. 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 allow different versions of apr. For example if you could have Apache 2.0 using APR 0.9.2 and subversion using APR 1.0.0. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] JK2 2.1
#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: [VOTE] JK2 2.1
-Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 02, 2002 8:36 AM To: Tomcat Developers List Subject: 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). OK. But will still have to use ifdef with EBCDIC system (iSeries / BS2000), for example in JNI areas or request encoding/decoding. No problem here, cause it's a channel component not a core one. MT -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] JK2 2.1
-Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 02, 2002 8:48 AM To: Tomcat Developers List Subject: Re: [VOTE] JK2 2.1 More comments on APR and JK2. Ok, I stopped here since I feel there is many works to conduct in JK2 to make Apache 1.3 compatible with APR/JNI. Man, you've done a great job. Conclusion, let's concentrate on JK2 now, make quickly a 2.0.1 release, which will have better support for APR/JNI with Apache 1.3 and will learn many things useable for JK 2.1. Agreed. mod_jk2 linux rpm and binaries will be released today but with Apache 1.3 WITHOUT APR/JNI support ;-) Excellent. MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] JK2 2.1
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. 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 libc.so.6 (GLIBC_2.2) =
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: [VOTE] JK2 2.1
Henri Gomez wrote: 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... I will try. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] JK2 2.1
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 ! 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. 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. And I think Apache2.0 RPM should just depend on libapr.rpm, and same for mod_jk2.rpm 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. Costin 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:
Re: [VOTE] JK2 2.1
General: [+0] Drop HAS_APR flags and dissalow building of JK2 without APR [ ] Keep everything like it is (the rest doesn't interests me) Regular expressions: [ ] Add pcre from httpd-2.0 to the common/pcre [ ] Add pcre from httpd-2.0 to the srclib/pcre [+1] Wait if pcre ever comes to the apr-util Noone looks against it in apr-util. I have to find time to do it. Pools: [+0] Use the real apr_pool_t. [] Keep the jk_pool_apr wrapper renaming it to the jk_pool Sockets: [+0] Use only apr_socket and drop the socket, renaming apr to socket. [ ] Keep supporting socket. File I/O: [+1] Use the APR for file i/o replacing stdio/stdlib calls [ ] Keep the old fopen/fwrite/etc... code Static buildings: [+1] Enable Static/Dynamic APR builds of JK2 for non-Apache2 connectors [-1] Enable only dynamic builds I am not sure that all the platforms I have could run with a dynamic linked APR Cheers Jean-frederic -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [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: [VOTE] JK2 2.1
-Original Message- From: Henri Gomez Even if I agree with using APR in JK 2.1, I think we should first focus on having a stable JK 2.0 before starting thinking about JK 2.1. That's good one :). I agree with that, but would like to make the load balancer to have a timeout connection-recovery option, cause that's the only way to have JK2 serve more then 5 concurent connections (depending on the system performance), and to be 'stable' or even 'usable'. Just don't wish to write the same thing twice... Branching now since premature. Why? MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] JK2 2.1
Mladen Turk wrote: -Original Message- From: Henri Gomez Even if I agree with using APR in JK 2.1, I think we should first focus on having a stable JK 2.0 before starting thinking about JK 2.1. That's good one :). As I said it's premature to discuss what should be in JK 2.1 until JK 2.0 is in a stable state. JK2 will be adopted by users if they saw that it's both stable and as a regular release rate. Many sites won't use JK2 until it became an Apache release, which has allways been a proof of quality. So my recommandation, we'll be to finish JK 2.0, before thinking to JK 2.1 I agree with that, but would like to make the load balancer to have a timeout connection-recovery option, cause that's the only way to have JK2 serve more then 5 concurent connections (depending on the system performance), and to be 'stable' or even 'usable'. Just don't wish to write the same thing twice... Branching now since premature. Why? - fixing bugs in 2 branches is a nigthmare. - confusion for users when they'll see a stable 1.2.0, a beta 2.0 and a dev 2.1. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] JK2 2.1
De: Mladen Turk [mailto:[EMAIL PROTECTED]] Enviado el: 1 de octubre de 2002 9:16 Althought i agree with the overall goals for a 2.1 release ( i should say they are nor very ambitious for point release), i agree with Henri too in the comments he mades, is a bit premature to open a 2.1 relase, without even have finished our current release, just now support users is very very cumbersome, and adding another item to our support bag, can only make this worse.. And i agree with Henri also ( and i dont understand your writing it twice argument ) that to open a Branch right now, is another development nightmare.. Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] JK2 2.1
-Original Message- From: Ignacio J. Ortega And i agree with Henri also ( and i dont understand your writing it twice argument ) that to open a Branch right now, is another development nightmare.. Well, didn't think that it would require a new branch. Ok, can we at least agree to the following. 1. Apache2 uses APR 2. IIS uses APR 3. Apache1 can use the APR. Or to be specific: There is only one build configuration right now that doesn't necessary need the APR, but is crippled to use only the socket connector. My question is that make sense? You may name the version whatever you like 2.1.0 or 2.0.1, doesn't matter at all to me, but simply drop the option to build without APR. Would It be such a big step forward to open a new branch, I don't think so. MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] JK2 2.1
Well, didn't think that it would require a new branch. Ok, can we at least agree to the following. 1. Apache2 uses APR 2. IIS uses APR 3. Apache1 can use the APR. Did iPlanet/NES could use APR on Netware, I'm waiting for Mike Anderson advices. Also we should be very carefull with APR since APR standalone is 0.9.1 and the one bundled with Apache 2.0.42 report to be 0.9.2. I allready worked on providing apr and apr-utils as standalone shared libs, which could be used with Apache 1.3 under Linux for example, but we should know which configure flags should be use, ie --enable-threads or --without-threads since Apache 1.3 is non threaded on at least Linux platforms. Or to be specific: There is only one build configuration right now that doesn't necessary need the APR, but is crippled to use only the socket connector. My question is that make sense? You may name the version whatever you like 2.1.0 or 2.0.1, doesn't matter at all to me, but simply drop the option to build without APR. We speaked about use of APR in JK2 many times in the past, take a look at tomcat-dev mailing list archive. Making APR mandatory for JK2 was never planned for 2.0 but for 2.1, which will be a whole different story. Would It be such a big step forward to open a new branch, I don't think so. It's really a nightmare to manage 2 differents branches at the same time and port/backport fixes in two branches. That was the case for JK when living in Tomcat 3.2.x and 3.3.x repositories, it's also the case for Tomcat 4.0.x and 4.1.x. One of the goal when I started jakarta-tomcat-connectors was to remove the duplicate works in jk TC 3.2/3.3 and I really against seeing the same on JK2 in JTC. I wonder what's the problem using #idef HAVE_APR in JK2 today ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] JK2 2.1
-Original Message- From: Henri Gomez We speaked about use of APR in JK2 many times in the past, take a look at tomcat-dev mailing list archive. Know that, but often people change opinions, you cannot blame to occasionally put that back on ;) Making APR mandatory for JK2 was never planned for 2.0 but for 2.1, which will be a whole different story. Would It be such a big step forward to open a new branch, I don't think so. It's really a nightmare to manage 2 differents branches at the same time Think you miss me. Things like using APR as mandatory reflects only the build procedure, and IMO doesn't require a new branch. I even didn't think that 2.1 needs to be a new branch (3.0 perhaps). The new branch needs to be technologically different to be a new branch thought, and see no reason why the 2.0.3 wouldn't be with the APR boundled in. But if the rest of community think it does, I'll 'Adopt'. I wonder what's the problem using #idef HAVE_APR in JK2 today ? None really (except that its messy), but you can find things like that even inside the code that can be used only in the APR supported connectors. But, as I said, I can Adopt ;) MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] JK2 2.1
IMO: one of the main goals of jk2 was modularity, i.e. jk2 is composed of components, each component can use and do whatever it likes without affecting the other components. I totally agree that jk2.1 should use APR ( I'll send my vote on each point ) - but I don't think the old code should be removed yet - there's no reason. The only problem is that we'll have to maintain 2 versions - the APR one and the old/original component. But that's a good thing IMO - the old one is already stable and shouldn't be changed except for bug fixes ( in the same way important bug fixes are backported from tomcat5 to 4.1 or from 4.1 to 4.0 ). I am +1 on creating a separate target/makefiles that will exclude the 'old'/non-apr components, or changing the code so that the APR components will be used by default in 2.1. I see no reason to remove components that work well and are tested. And a branch shouldn't be needed - it should be perfectly possible to do whatever we want in the new components. The only thing that needs to be stable for that ( or change in all components ) is the 'object model' ( including configuration, factories, etc ). Right now I'm convinced that a future version of jk2 should either switch to or provide support for NSCOM and COM. Most likely this should be done on top, i.e. add an IDL and a COM factory for each component and use some conditional compilation to make sure that each jk component is compiled as COM on windows, NSCOM if mozilla COM is available ( i.e. on unix ). The only thing that I still need to check is if it is possible to also hook into gnome or kde object models. Costin Mladen Turk wrote: -Original Message- From: Ignacio J. Ortega And i agree with Henri also ( and i dont understand your writing it twice argument ) that to open a Branch right now, is another development nightmare.. Well, didn't think that it would require a new branch. Ok, can we at least agree to the following. 1. Apache2 uses APR 2. IIS uses APR 3. Apache1 can use the APR. Or to be specific: There is only one build configuration right now that doesn't necessary need the APR, but is crippled to use only the socket connector. My question is that make sense? You may name the version whatever you like 2.1.0 or 2.0.1, doesn't matter at all to me, but simply drop the option to build without APR. Would It be such a big step forward to open a new branch, I don't think so. MT. -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] JK2 2.1
Mladen Turk wrote: We speaked about use of APR in JK2 many times in the past, take a look at tomcat-dev mailing list archive. Know that, but often people change opinions, you cannot blame to occasionally put that back on ;) That's right. I totally agree that all new code and features should use APR. But I don't agree ( and I haven't seen any argument/reason ) that we should drop the non-APR components or we shouldn't allow a build without APR. That's pretty simple - the object model doesn't use APR and there's no need to ( there's no or minimal platform-specific code in it ). And the non-apr components are stable and there's no reason to change them. Just create new components. Sometime in future ( say 6 months after jk2.0 release is out ) we can discuss deprecating the old components and maybe after jk2.1 is released we can discuss removing them for jk2.2. Making APR mandatory for JK2 was never planned for 2.0 but for 2.1, which will be a whole different story. It's really a nightmare to manage 2 differents branches at the same time Think you miss me. Things like using APR as mandatory reflects only the build procedure, and IMO doesn't require a new branch. I even didn't think that 2.1 needs to be a new branch (3.0 perhaps). The new branch needs to be technologically different to be a new branch thought, and see no reason why the 2.0.3 wouldn't be with the APR boundled in. But if the rest of community think it does, I'll 'Adopt'. I don't think APR ( or anything else :-) should be 'mandatory'. Recommended - yes, default - yes. But if the 'modularity' and 'component' goals are met, then it should be possible to use any kind of components in the system, including those that don't use APR. And since we already have a (complete and functional ) set of components supporting the minimal features ( i.e. basic socket communication ) - and most of the code is stable ( as it's very close to jk1.x ), I see no reason to remove them or to not allow a build with those components only. If you want cleaner code - just create a new component ( copy the old one for example ), remove HAVE_APR and make it require APR. I wonder what's the problem using #idef HAVE_APR in JK2 today ? None really (except that its messy), but you can find things like that even inside the code that can be used only in the APR supported connectors. But, as I said, I can Adopt ;) No problem with removing the mess - in new components that will be default in 2.1. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] JK2 2.1
Well, what I was yelling about was the core components, like load balancer, uriMap, uriEnv. We can write our own functionality, copy the code from the APR, or something else if faster. These are the components that cannot easily be supported using #idfef HAS_APR #elif MOZILLA #else... So, we need a decision, are we going to use (for example) apr_time_now(), write our own, using #ifdef #else, or what for those core components? Other thing. If we say that core components has to be 'non-mandatory' of any component like apr or nspr or whatever, the code like #ifdef HAS_APR must not be in such a component, or it loose its meaning like component free. And what is component free code (APR doesn't belong to that category, it is more a system abstraction layer like posix). Is it better to use the fopen or apr_file_open? Take a look at one of the 'core components' jk_config_file (the first one that I found): #ifdef AS400 fp = fopen(workerFile, w, o_ccsid=0); #else fp = fopen(workerFile, w); #endif Is this abstractive code enough ;) So... If you wish make some draft about what are the core components, what is 'mandatory' inside them and what is not, so that we know how to write the code for such a component. -Original Message- From: news [mailto:[EMAIL PROTECTED]] On Behalf Of Costin Manolache Sent: Tuesday, October 01, 2002 7:13 PM To: [EMAIL PROTECTED] Subject: RE: [VOTE] JK2 2.1 MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] JK2 2.1
Mladen Turk wrote: Hi, Since there has been general concensus that we should use the APR for every supported API call. Here is my design proposal. General: [ ] Drop HAS_APR flags and dissalow building of JK2 without APR [ ] Keep everything like it is (the rest doesn't interests me) As I said, my option is: [X] Leave the existing components, create all new components based on APR. and make sure plugability works. In future - deprecate the non-apr components after 2.0 is released and default to apr-only components in 2.1, remove non-apr components after 2.1 is released ( i.e. for 2.2 ). I think that maximises the stability of the code. Regular expressions: [ ] Add pcre from httpd-2.0 to the common/pcre [ ] Add pcre from httpd-2.0 to the srclib/pcre [X] Wait if pcre ever comes to the apr-util If we wait to much - one of the first 2 choices. Pools: [X] Use the real apr_pool_t. [ ] Keep the jk_pool_apr wrapper renaming it to the jk_pool With the mention: use the real apr_pool_t in new code, let jk_pool_apr in the code related to component model ( and all new apr components can get and use the real apr_pool_t from jk_pool_apr struct ). Sockets: [x] Use only apr_socket and drop the socket, renaming apr to socket. [ ] Keep supporting socket. Use only apr_socket and default to it for 2.1, but without removing the old jk_socket ( until 2.2 ) File I/O: [x] Use the APR for file i/o replacing stdio/stdlib calls [ ] Keep the old fopen/fwrite/etc... code Same as before. Static buildings: [x] Enable Static/Dynamic APR builds of JK2 for non-Apache2 connectors [ ] Enable only dynamic builds -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
