Re: [Vote] (was Re: Top Level Project? Time for Top Level Lists?)
Bugs [ ] forward to [EMAIL PROTECTED] [X ] forward to [EMAIL PROTECTED] Commits [ ] forward to [EMAIL PROTECTED] [ X] forward to [EMAIL PROTECTED] Vote away :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with mod_jk 1.2.8 (and 1.2.10) and Tomcat 4.0.4
From: Mladen Turk [EMAIL PROTECTED] Laurent LE PRIEUR wrote: Hello, I have a problem of ping pong between the connector mod_jk and tomcat 4.0.4 which entraine a significant load network. Did you tried your app with Tomcat5 or Tomcat5.5? Perhaps the problem is not with the native side of mod_jk. This sounds similar to a problem that is fixed in 3.3.2, 4.1.31 and 5.x. http://marc.theaimsgroup.com/?l=tomcat-devm=107846357610458w=2 You can post your application if unable to install the Tomcat5. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] PMC Chair
From: Yoav Shapira [EMAIL PROTECTED] Below is the draft resolution we agreed on previously, so it should be pretty close. We need to make sure the PMC names are correct and complete. Congrats to Remy and thanks everyone for voting, and of course thanks Henri ;) Yoav While my low level of involvement probably doesn't merit being in the PMC, I'm concerned that only those names that appear in the PMC list will retain active committer status. I'm sure there are other committers who fall into my category. Will the 50+ committers who are not on the PMC be move to emeritus status? If not how will that be decided? Congratulations to Remy. Also thank you Yoav for moving the formalities along. Regards, -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] PMC Chair
From: Remy Maucherat [EMAIL PROTECTED] Kurt Miller wrote: From: Yoav Shapira [EMAIL PROTECTED] Below is the draft resolution we agreed on previously, so it should be pretty close. We need to make sure the PMC names are correct and complete. Congrats to Remy and thanks everyone for voting, and of course thanks Henri ;) Yoav While my low level of involvement probably doesn't merit being in the PMC, I'm concerned that only those names that appear in the PMC list will retain active committer status. I'm sure there are other committers who fall into my category. Will the 50+ committers who are not on the PMC be move to emeritus status? If not how will that be decided? The official ASF policy calls for a 6 month inactivity. No Tomcat committer has ever been removed in 5+ years. It seems reasonable to me that if they don't at least ask for it that they would now be removed. Okay, that makes sense. Thanks for the clarification. Congratulations to Remy. Also thank you Yoav for moving the formalities along. Rémy -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release JK 1.2.9 as stable
From: Mladen Turk [EMAIL PROTECTED] Vote 1.2.9 as stable: [X ] Yes Built and basic operation tested on OpenBSD 3.7-current i386/sparc64/macppc with Apache 1.3.29. The source distribution used to contain a copy of the html docs. Not that it matters much, but do we want to include them anymore? -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Propose Jim Jagielski and William A. Rowe as JakartaTomcatConnectors commiters
[x] Yes, Jim is really a cool guy. [x] Sure, wellcome Bill. both +1, welcome. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK Todo List
From: Henri Gomez [EMAIL PROTECTED] Well JK using APR will be a good solution for every webservers but Apache 1.3.x. Apache 2.x came with APR, IIS, Domino and others should have no problems to use an external APR library (.so, .dll). So the remaining question will be shoud we drop Apache 1.3.x support in future JK 1.2.x or should we start a 'new' APR JK 1.2.x based implementation ? I think there are two other options. I've listed all them in my order of preference. 1) Don't APR'ize JK and keep Apache 1.3 support 2) APR'ize JK 3) start a new APR JK 1.2 based 4) drop Apache 1.3 support I'd like to keep Apache 1.3 support going longer. If 1 is ruled out, I'd want APR to be build separately and loaded via the LoadFile directive. The JK2 integrated build of APR and static linking is/was to complex. If there's consensus to go with option 2, I would be willing to do the work on the Apache 1.3 native build. -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Tomcat 4.1.31
From: Keith Wannamaker [EMAIL PROTECTED] Ballot [ ] Alpha [ ] Beta [X] Stable /Ballot I tested connector bugs 20184 24763 are fixed with this release. All the major branches have this fix now (3.x 4.1 and 5.x). I'm now aware that this release passes all the watchdog tests, too. -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK Todo List
From: Mladen Turk [EMAIL PROTECTED] Remy Maucherat wrote: Over all, I don't, personally, think that it's worth trying to build on the existing Jk code base. However, if you have an itch Well, we deceased JK2, for Apache2.1 we have proxy_ajp. Until Apache2.1 becomes the only server around the net, I'll stick with JK for all those not running my preferred web server :). Right. However, I think JK 1.2.x needs some level of stability. So APR, large architectural changes, etc seem bad ideas. Of your list, I think documentation (yah !) and the Unix sockets backport would be good (if not too complex), but that's about it. Modifications to the Java side is something independent. I think it would rise the stability, but introduce new problems like building APR, etc.. so you are probably right. We'll see. I'm not very happy with the integrated APR build in JK2 for Apache 1.3. I did much of the work there and if I had to do it again, I'd prefer APR to be a build/runtime depend, built separately by the user first and loaded with LoadFile directive. With respect to JK, I'd rather not see it get APR'ized. Mostly so that Apache 1.3 support is kept simple and straightforward. For the long term, if you would want better support for the other servers, you can start a 100% APR replacement for JK 1.2 (I think it was a bit like your mod_ajp) if you want to. I'm surely do. The IIS6 support is something to chase :). MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 4.1.31 stability
From: Keith Wannamaker [EMAIL PROTECTED] I have uploaded a Tomcat 4.1.31 release canidate to http://apache.org/~keith/rc1/ In the binary releases, the servletapi documentation was installed into /webapps/tomcat-docs/servletapi/api/ instead of /webapps/tomcat-docs/servletapi/. This breaks the 'Servlet/JSP Javadocs' link in tomcat-docs. -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 4.1.31 maintenance release
ballot The 4.1.31 maintenance release should happen: [X ] Yes [ ] No /ballot I'd like to see the fix for bug 20148 get released on the 4.x branch. -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev]
From: Bill Barker [EMAIL PROTECTED] From: Filip Hanik - Dev [EMAIL PROTECTED] The Java VM does this through file handling, we would have to find out where it issues this call and if we can get around it. The Tomcat developers are not calling stat anywhere in the code, but the underlying JVM code does, we just don't know where My guess would be File.getCanonicalPath() in FileDirContext. I can confirm from the SCSL 1.4 jdk source that File.getCanonicalPath() eventually calls realpath(3) in the jdk src. On OpenBSD (and probably all unixes) realpath(3) causes an lstat on each dir in the path. -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.0.26 release ?
From: Henri Gomez [EMAIL PROTECTED] jk 1.2.6 seems to be in a good shape and a release should be welcome for many users. I'd like to release jk 1.2.6 next week. Any objections ? Vote please ;-) +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: why is jk_registry.h in ./jk/native2/common? /2
From: Günter Knauf [EMAIL PROTECTED] [X ] dont know If moving the file loses its CVS history it may be a good reason for it to stay put. -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compiling mod_jk 2.0.4 on macos X (10.2)
From: Marco Baringer [EMAIL PROTECTED] i'm trying to compile mod_jk (just the apache side, not the tomcat side). I downloaded jakarta-tomcat-connectors-jk2-2.0.4-src. apr-0.9.4 and apr-util-0.9.4 and was able to successfully run configure (i'm building against apache 1.3). however trying to do make results in an error about build/jk2/apache13/mod_jk2.so not existing (it doesn't). i have all the .o files and i have mod_jk2.a and mod_jk2.la, why isn't the .so file being built? Is there a jk/build/jk2/apache13/usr/local/libexec/mod_jk2.dylib? You could try editing jk/native2/server/apache13/Makefile and change all .so to .dylib and see if that helps. Attempts to build against apache2 result in configure errors about libapr not being found. This has been reported and fixed post 2.0.4. A quick workaound would be to edit jk/native2/configure, find all the referances to libapr-1.so, libapr-0.so and libapr.so and change to libapr-1.dylib, libapr-0.dylib and libapr.dylib respectively. -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compiling mod_jk 2.0.4 on macos X (10.2)
From: Marco Baringer [EMAIL PROTECTED] twas libtool after all. I grabbed a clean cvs tree, deleted jk/native2/libtool, copied in my version of gnu libtool (1.5.2) and everything went smoothly. compiled, built mod_jk2.so and apache seems to like it. Great! I'm assuming that you got it working for apache2, right? From your last email it apears that apache13 on macos X might need some changes. Could you try apache13 and let us know how it goes? -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compiling mod_jk 2.0.4 on macos X (10.2)
From: Marco Baringer [EMAIL PROTECTED] On Venerdì, apr 2, 2004, at 19:43 Europe/Rome, Kurt Miller wrote: Great! I'm assuming that you got it working for apache2, right? From your last email it apears that apache13 on macos X might need some changes. Could you try apache13 and let us know how it goes? no, i got it working an apache13. i haven't tried apache2 yet. OK, great. I believe the person who found the dylib problem got it working with apache2. 2.0.5 may be good for macos X. -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Segmentatio fault in Apache 2
From: Thorsten Kamann [EMAIL PROTECTED] Hello, jean-frederic clere schrieb: jk2 2.0.4 and Apache 2.0.48, hard to improve. - Try to get a core file by adding in httpd.conf: +++ CoreDumpDirectory /home/cores this dosnt work. I have appended CoreDumpDirectory /tmp/apache_cores to the httpd.conf. Make the dir writable for everyone. Restart the apache. But the dir is empty. Any ideas? You could try an active debug session: gdb /path/to/httpd r -X 'should crash here' bt More information is output if you compile apache and mod_jk2 with debug symbols. (more == better :) Regards, -Kurt Thorsten -- Thorsten Kamann Email: [EMAIL PROTECTED] ICQ: 40746578 Yahoo: ThorQue - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problem with new 2.04 mod_jk2
From: [EMAIL PROTECTED] Hello, I decided to try the new mod_jk2 today. I put all the files in the right place, but got this error when starting up httpd: Starting httpd: Syntax error on line 5 of /etc/httpd/conf.d/jk2.conf: Cannot load /etc/httpd/modules/mod_jk2.so into server: /etc/httpd/modules/mod_jk2.so: undefined symbol: apr_socket_send has anyone seen this or know what I have done wrong? apr_socket_send is included in apr-0.9.2 and apache 2.0.44 and up. I suppose that makes mod_jk2-2.0.4 minimally require those versions. Background: this is a redhat9 box running Tomcat 4.1.27 and apache 2.0.40-21.9 I have also downloaded, compiled, and installed the newest apr source. I have added the path to the /etc/lib.so.conf and run ldconfig -v to rebuild the cache. I still keep getting the same error. mod_jk2 will use apr that is linked to apache. upgrade apache and the problem will go away. Thanks, Devin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 2.0.4 tagged
From: Henri Gomez [EMAIL PROTECTED] Henri Gomez wrote: Henri Gomez wrote: Mladen Turk wrote: First set of Linux binaries available : http://www.apache.org/dist/jakarta/tomcat-connectors/jk2/binaries/linux/ FreeBSD 4.9 packages are available: http://www.apache.org/dist/jakarta/tomcat-connectors/jk2/binaries/freebsd/ I needed to change my pgp key to a non-patented algorithm. I committed the new key, but should I update: /www/www.apache.org/dist/jakarta/tomcat-connectors/KEYS manually or is there some automated process? -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 2.0.4 tagged
From: Henri Gomez [EMAIL PROTECTED] Henri Gomez wrote: Jess Holle wrote: Is there a source tarball for 2.0.4 available for download somewhere yet? -- Jess Holle Henri Gomez wrote: jk2 2.0.4 has been tagged. jk2_2_0_4 We're now in HEAD at 2.0.5-dev yes : http://jakarta.apache.org/~hgomez/ Hi to all, What's the status of the various binaries ? I've done the Fedora 1, Suse 9.0 and Suse SLES 8.0 (PPC) and I'm waiting for others bins (Mladen, Kurt, Mike ?) Regards I'm working on updating the FreeBSD port of www/mod_jk2. Previously it was building mod_jk for apache2 which is quite misleading (being called mod_jk2 and all). The www/mod_jk port builds mod_jk for either apache13 or apache2 anyway. I should be done with it shortly. Thanks for fixing the name of the tarball. Could I ask you to make another change? The tarball extracts into a directory name that doesn't match the tarball name ( missing the jk2 again ). Could you recreate the tarball with the directory name jakarta-tomcat-connectors-jk2-2.0.4-src? The *BSD porting schemes assume the source tarball extracts into a dir name that matches the tarball name (can be overridden if necessary). For OpenBSD 3.4 it shipped with tomcat 4.0.6, so I'll skip the binary for that and make one for 3.5 when its available. Thanks, -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 2.0.4 tagged
From: Henri Gomez [EMAIL PROTECTED] Henri Gomez wrote: Jess Holle wrote: Is there a source tarball for 2.0.4 available for download somewhere yet? -- Jess Holle Henri Gomez wrote: jk2 2.0.4 has been tagged. jk2_2_0_4 We're now in HEAD at 2.0.5-dev yes : http://jakarta.apache.org/~hgomez/ Hi to all, What's the status of the various binaries ? I've done the Fedora 1, Suse 9.0 and Suse SLES 8.0 (PPC) and I'm waiting for others bins (Mladen, Kurt, Mike ?) Packages for FreeBSD 4.9 and the port that I used to create them are available at: http://jakarta.apache.org/~truk/ Mladen you may want to use the port I created for FreeBSD 5 for consistency. One item to note, you will need to set WITH_APACHE2=YES in your environment to get the package depends to work right for apache2. I followed Guenter's proposed structure with adjustment for the OS directory conventions and some file additions. We must include LICENSE and NOTICE files. I added the docs in jk/docs/ too. -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 2.0.4 tagged
From: Henri Gomez [EMAIL PROTECTED] Mladen Turk wrote: -Original Message- From: Henri Gomez Will you build the sources? I'm preparing a source tarball, and will build Linux binaries for Fedora Core 1, Suse 9.0 and Suse SLES 8.0 (PPC). Others archs, are welcomed Did we agreed on binary dist? I was thinking providing something very similar to the one in jk 1.2.5, but we could still discuss. What's gonna be the dir layout and files included? Do you think at your proposal ? Why not Can you write some guidelines? The one proposed by Guenter ? ./apache2 /conf /workers2.properties.minimal /mod_jk2.conf /modules /mod_jk2.dll|nlm|so /ver-info /mod_jk2 /README /CHANGES /STATUS /INSTALL We should add LICENCE to the above list of files in /ver-info. I will do packages for OpenBSD/i386 3.4 and FreeBSD 4.9. I'd like to use the ports/package conventions of these OS's instead of the above directory structure. In general do we need one directory layout for all OS's? I'll build all the WIN32 executables, and can do FreeBSD 5.2.1 package. Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Connectors makefile typo...
Hi Adam,
I committed a fix for the hardcoded -lapr-0. Now libapr.so, libapr-0.so or
libapr-1.so will be detected while configuring.
Detection could be better but this works for now.
-Kurt
- Original Message -
From: Adam Fowler [EMAIL PROTECTED]
To: [EMAIL PROTECTED] Apache. Org (E-mail) [EMAIL PROTECTED]
Sent: Monday, March 22, 2004 6:05 AM
Subject: Connectors makefile typo...
Hello guys,
I have found a bug in the Makefile. Not sure whether to put this in the bug
DB as its a problem with the make file and not the connectors. Apologies if
I shouldn't have posted here. Here's the problem below, anyway.
I downloaded the connectors tar.gz
(jakarta-tomcat-connectors-jk2-src-current.tar.gz version 2.0.2) and went
into jk/native2 to build the thing.
I used the instructions Kurt/Henri posted to dev (couldn't get the one in
README.txt working). I basically did the following:
./configure --with-apxs2=/usr/sbin/apxs
make
This failed miserably due to a problem in the server/apache2/Makefile make
file. This is the error output form the original try:
...
/usr/bin/ld: cannot find -lapr-0
collect2: ld returned 1 exit status
make[1]: *** [../../../build/jk2/apache2/jkjni.la] Error 1
make[1]: Leaving directory
`/root/work/jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/server/apache
2'
make: *** [jk2-build] Error 1
The problem is on line 37 as follows:
JK_LDFLAGS=-L${APACHE2_LIBDIR} -lcrypt -lapr-0
Obviously the -lapr-0 should read -lapr -0. I fixed this and re-ran make and
all was lovely.
Thought you'd want to know. If you need anymore info, please feel free to
e-mail.
Adam.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Minimal HOWTO for jk2 2.0.4 - proposal
From: Guenter Knauf [EMAIL PROTECTED] Hi, Here are the HOWTOs I use for binary distributions: NetWare: This is a binary package of mod_jk2. If you have installed Apache2 to the default location /Apache2 then simply extract this archive directly to the root of your volume. Use the 'Include' directive to add mod_jk2.conf to your httpd.conf. Rename the workers2.properties.minimal to workers2.properties, then edit the file and change the host and port setting if necessary. On NW 6.0 the default Tomcat listens on 9009 while with NW 6.5 Tomcat listens on 9010. After restarting Apache2 you should be able to browse the Tomcat documentation with this link: http://your.domain.com/tomcat-docs/ This docs also include mod_jk2. version : 2.0.4 license : http://www.apache.org/licenses/LICENSE-2.0.txt Win32: This is a binary package of mod_jk2. If you have installed Apache2 to the default location /Apache2 then simply extract this archive directly to the root of your volume. Use the 'Include' directive to add mod_jk2.conf to your httpd.conf. Rename the workers2.properties.minimal to workers2.properties, then edit the file and change the host and port setting if necessary. After restarting Apache2 you should be able to browse the Tomcat documentation with this link: http://your.domain.com/tomcat-docs/ This docs also include mod_jk2. version : 2.0.4 license : http://www.apache.org/licenses/LICENSE-2.0.txt here follows the directory structure I use: ./apache2 /conf /workers2.properties.minimal /mod_jk2.conf /modules /mod_jk2.dll|nlm|so /ver-info /mod_jk2 /README /CHANGES /STATUS /INSTALL comments? I like the idea of this and the text is good. I would think you would need to cover how to install if the user is using a non-default directory structure. I'm not sure if its common on Netware and W32, but the *BSD's each use different locations for conf and modules. I'd like to see the mod_jk2.conf. At what location in httpd.conf should it be included? You probably want to be specific about that. Just a nitpick, but you may want to change 'volume' to 'drive' for win32. -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Minimal HOWTO for jk2 2.0.4 - proposal
From: Guenter Knauf [EMAIL PROTECTED] Hi Kurt, I like the idea of this and the text is good. I would think you would need to cover how to install if the user is using a non-default directory structure. I'm not sure if its common on Netware and W32, but the *BSD's each use different locations for conf and modules. right, that's missing; will add soon. I'd like to see the mod_jk2.conf. At what location in httpd.conf should it be included? You probably want to be specific about that. hmm, since we have fixed recently the hooks it shouldnt matter anymore where you load mod_jk2; D'oh!. ;-) Out of habbit I always do the LoadModule in the DSO section, but. you're right it shouldn't matter. here's the rest od my minimal config, and my main goal was that the host:port does only appear _once_ in the config: http://www.gknw.com/development/apache/docs/win32/mod_jk2/ http://www.gknw.com/development/apache/docs/win32/mod_jk2/min_w2.properties another thing we should get around are the sometimes nasty defaults: if you specify f.e. myworkers2.prop as file, but have also a workers2.properties in the conf dir, then _both_ are used by mod_jk2, this isnt a good behavior; but unfortunately I had no time yet to look at this closer... Just a nitpick, but you may want to change 'volume' to 'drive' for win32. ups! copypaste error, will fix. Guenter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2 BUILD.txt
Hi Henri, I hope you don't mind, but I rewrote the build instructions for Unix-like systems. If its OK with you I'd like to commit this (or something like it). Of course comments, additions or criticisms welcome too. ;-) -Kurt Information on building mod_jk2: Starting with 2.0.4, APR is mandatory for jk2. For Apache 2.0 or greater jk2 will use APR that was used to build Apache 2.0. For Apache 1.3, jk2 must build APR and APR_UTIL from source. DSO build instructions for Unix-like systems: The compiler used to build jk2 must match the one used to build Apache. You may need to set an environment variable before configuring such as CC=cc. `apxs -q CC` will tell you what compiler was used for Apache. The most straightforward way to configure jk2 is to use apxs that comes with Apache. Linux distributions may need to have additional rpm's installed such as Apache2 devel rpm, httpd-devel or apache2-devel or for Apache 13, Apache devel rpm, httpd-devel or apache-devel depending on your distribution. Example Apache2 build and install: cd jakarta-tomcat-connectors/jk/native2 ./configure --with-apxs2=/your/path/to/apxs make cd ../build/jk2/apache2 apxs -n jk2 -i mod_jk2.so Example Apache13 build and install: apr and apr-util will be configured and built for you while configuring and building jk2. There is no need to separately configure and build them. cd jakarta-tomcat-connectors/jk/native2 ./configure --with-apxs=/your/path/to/apxs \ --with-apr=/your/path/to/apr-source \ --with-apr-util=/your/path/to/apr-util-source make cd ../build/jk2/apache13 apxs -n jk2 -i mod_jk2.so NOTE: pthread support may be automatically detected and built into apr. If apache13 was not built with pthread support, you can either disable it by adding --disable-apr-threads while configuring, or load the pthread library in httpd.conf using the LoadFile directive. Optional configure arguments (for 1.3 and 2.0): If you want to have JNI support, add --with-jni and be sure to have the JAVA_HOME environment variable point to your Java Environment. This will build inprocess jni support into mod_jk2.so and additionally build libjkjni.so. libjkjni.so can be used by tomcat to provide support for channel unix and should be installed in the apache libexec dir. Use `apxs -q LIBEXECDIR` if you are unsure of its location. Libjkjni.so will be located in the same directory as mod_jk2.so after building with this option. If you want to have PCRE (Perl Compatible Regular Expressions) support for jk2 uri directives, add --with-pcre while configuring. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Releasing JK 2.0.4]
From: jean-frederic clere Henri Gomez wrote: jean-frederic clere wrote: Henri Gomez wrote: jean-frederic clere wrote: Henri Gomez wrote: jean-frederic clere wrote: Mladen Turk wrote: -Original Message- From: jean-frederic clere I have the following error: +++ # sbin/apachectl start Syntax error on line 250 of /opt/SMAWoIS/apache13/conf/httpd.conf: Cannot load /opt/SMAWoIS/apache13/libexec/mod_jk2.so into server: ld.so.1: /opt/SMAWoIS/apache13/sbin/httpd: fatal: relocation error: file /opt/SMAWoIS/apache13/libexec/mod_jk2.so: symbol jk_jni_status_code: referenced symbol not found sbin/apachectl start: httpd could not be started The jk_jni_status_code is int defined in jni/jk_jni_aprImpl.c Something went wrong during compilation? Nothing but jk_jni_aprImpl.o is not in mod_jk2.so so jk_jni_status_code is undefined. So jk_jni_aprImpl.c has not been compiled. What's your configure line ? CC=cc -xtarget=ultra -xarch=v8plus -xO5 -xstrconst -xdepend -Xa \ ./configure --with-apxs=/opt/SMAWoIS/apache13/sbin/apxs --with-apr=/export/home3/jfclere/tmp/apr-0.9.4 --with-apr-util=/export/home3/jfclere/tmp/apr-util-0.9.4 --with-jni Ok. Could you see if the jk_jni_aprImpl.c is built ? No it is not build. So that's the problem. Could you send a compile log ? That is just a note to tell that not using --with-jni helps. --with-jni and --with-pcre now works for apache13 and apache2 for both Makefile.in and Makefile.apxs.in methods. -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 Makefile.apxs.in Makefile.in
Whoops. This commit message had a copy paste error. Should have read ... for
apache2... throughout.
From: [EMAIL PROTECTED]
truk2004/03/18 18:52:23
Modified:jk/native2/server/apache2 Makefile.apxs.in Makefile.in
Log:
Rearrange Makefile.apxs.in to be more consistant with Makefile.in
Arrange --with-pcre support for apache13 for both Makefile.in and
Makefile.apxs.in
Arrange --with-jni support for apache13 for Makefile.apxs.in
(excluding libjkjni.so)
Slight adjustments to the prepare and clean targets in Makefile.in
Revision ChangesPath
1.11 +16 -11
jakarta-tomcat-connectors/jk/native2/server/apache2/Makefile.apxs.in
Index: Makefile.apxs.in
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/Makefile.apxs.in,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- Makefile.apxs.in 10 Mar 2004 23:52:34 - 1.10
+++ Makefile.apxs.in 19 Mar 2004 02:52:22 - 1.11
@@ -1,4 +1,6 @@
## configure should make the Makefile out of this file.
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
@@ -6,30 +8,33 @@
JK_DIR := ../..
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
-COMMON_C_FILES := $(wildcard ${JK_DIR}/common/*.c )
-
-
-JK=${JK_DIR}/common/
-JKINC=${JK_DIR}/include/
-JK_INCL=-DUSE_APACHE_MD5 -I ${JK} -I ${JKINC} -DHAS_APR @HAVE_JNI@ @HAS_PCRE@
ifneq ($(strip $(JAVA_HOME)),)
JAVA_INCL=-I ${JAVA_HOME}/include -I ${JAVA_HOME}/include/${OS}
JAVA_LIB=-L ${JAVA_HOME}/jre/lib/${ARCH} -L
${JAVA_HOME}/lib/${ARCH}/native_threads
endif
-APACHE2_OBJECTS=jk_logger_apache2.c jk_map_aprtable.c jk_service_apache2.c
+INCLUDES= -I${JK_DIR}/include \
+ ${JAVA_INCL}
-## Must include the jni stuff
+JK_CFLAGS=-DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 @HAVE_JNI@ @HAS_PCRE@
+
+COMMON_C_FILES := $(wildcard ${JK_DIR}/common/*.c )
+JNI_C_FILES := $(wildcard ${JK_DIR}/jni/*.c )
+A2_C_FILES := $(wildcard *.c )
all: mod_jk2.la
mod_jk2.la:
- $(APXS) -c -o $@ -Wc,${JK_INCL} ${JAVA_INCL} mod_jk2.c ${APACHE2_OBJECTS}
${COMMON_C_FILES}
+ $(APXS) -c -o $@ -Wc,${INCLUDES} ${JK_CFLAGS} ${JAVA_LIB} @PCRE_LIBS@ \
+ ${A2_C_FILES} ${COMMON_C_FILES} ${JNI_C_FILES}
install: mod_jk2.la
$(APXS) -i mod_jk2.la
clean:
- rm -f *.o *.so *.lo *.la *.slo
- rm -rf .libs
+ rm -f *.o *.so *.lo *.la *.slo ${JK_DIR}/common/*.o ${JK_DIR}/common/*.so \
+ ${JK_DIR}/common/*.lo ${JK_DIR}/common/*.la ${JK_DIR}/common/*.slo \
+ ${JK_DIR}/jni/*.o ${JK_DIR}/jni/*.so ${JK_DIR}/jni/*.lo \
+ ${JK_DIR}/jni/*.la ${JK_DIR}/jni/*.slo
+ rm -rf .libs ${JK_DIR}/common/.libs ${JK_DIR}/jni/.libs
1.24 +7 -5
jakarta-tomcat-connectors/jk/native2/server/apache2/Makefile.in
Index: Makefile.in
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/Makefile.in,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- Makefile.in 12 Mar 2004 08:23:46 - 1.23
+++ Makefile.in 19 Mar 2004 02:52:22 - 1.24
@@ -2,6 +2,8 @@
# use -D options to overrides defaults
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
@@ -37,7 +39,7 @@
${APR_INCL} \
${JAVA_INCL}
-JK_CFLAGS=-DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 -DHAS_APR @HAVE_JNI@ @HAS_PCRE@
+JK_CFLAGS=-DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 @HAVE_JNI@ @HAS_PCRE@
ifdef APR_LIBDIR_LA
JK_LDFLAGS=-L${APACHE2_LIBDIR} -lcrypt @PCRE_LIBS@
else
@@ -106,13 +108,11 @@
${BUILD_DIR}/mod_jk2.so: ${BUILD_DIR}/${APACHE2_LIBEXEC}/mod_jk2.so
$(CP) $^ $@
${BUILD_DIR}/${APACHE2_LIBEXEC}/mod_jk2.so: ${BUILD_DIR}/mod_jk2.la
- mkdir -p ${BUILD_DIR}/${APACHE2_LIBEXEC}
$(MOD_INSTALL) $^ `pwd`/${BUILD_DIR}/${APACHE2_LIBEXEC}
${BUILD_DIR}/libjkjni.so: ${BUILD_DIR}/${APACHE2_LIBEXEC}/libjkjni.so
$(CP) $^ $@
${BUILD_DIR}/${APACHE2_LIBEXEC}/libjkjni.so: ${BUILD_DIR}/libjkjni.la
- mkdir -p ${BUILD_DIR}/${APACHE2_LIBEXEC}
$(MOD_INSTALL) $^ `pwd`/${BUILD_DIR}/${APACHE2_LIBEXEC}
${BUILD_DIR}/libjkjni.la: ${JNI_LO_FILES} ${COMMON_LO_FILES}
@@ -124,7 +124,9 @@
${COMMON_C_FILES} ${A2_C_FILES}: ${H_FILES}
prepare:
- mkdir -p ${BUILD_DIR}
+ mkdir -p ${BUILD_DIR}${APACHE2_LIBEXEC}
clean:
- rm -rf ${BUILD_DIR}/*.lo ${BUILD_DIR}/*.la ${BUILD_DIR}/*.o ${BUILD_DIR}/.libs
${BUILD_DIR}/*.so
+ rm -rf ${BUILD_DIR}/*.lo ${BUILD_DIR}/*.la ${BUILD_DIR}/*.o ${BUILD_DIR}/*.a \
+ ${BUILD_DIR}/.libs ${BUILD_DIR}/*.so ${BUILD_DIR}${APACHE2_LIBEXEC}/*.so \
+
Re: [Vote] Guenter Knauf as commiter
+1 -Kurt From: Henri Gomez [EMAIL PROTECTED] Hi to all, jk2 2.0.4 seems in a good shape and I'd like to thanks all of you commiter, and tomcat-dev members for your feedback, patches and time. I'd like to see Guenter Knauf promoted to commiter since he provided us may fine patches on jk2 and help make this release happen. We need more and more people involved in the native side of jakarta-tomcat-connectors and Guenter show us these lasts week that he's a good candidate. Vote please, he's got of course my +1. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Releasing JK 2.0.4]
From: jean-frederic clere [EMAIL PROTECTED]
Henri Gomez wrote:
If Jean-Frederic, Mladen, Kurt (commiters) agreed,
and if Gueunter, NorW and users didn't complain, I think
I could tag tomorrow and prepare the 2.0.4 release
I have a new problem on (one) FreeBSD:
+++
if [ ! -d /usr/local/apr/include/apr-0 ]; then
/home/com5/jfc/tmp/apr-0.9.4/build/mkdir.sh /usr/local/apr/include/apr-0; fi;
mkdir /usr/local/apr
mkdir: /usr/local/apr: Permission denied
mkdir /usr/local/apr/include
mkdir: /usr/local/apr: No such file or directory
mkdir /usr/local/apr/include/apr-0
mkdir: /usr/local/apr/include: No such file or directory
*** Error code 1
Stop in /home/com5/jfc/tmp/apr-0.9.4.
gmake: *** [apr-build] Error 1
+++
It seems like you don't have the most recent support/jk_apr.m4. The current version
sets the prefix to the --with-apr dir.
The make install of APR is not a good idea. A DESTDIR=./build probably helps.
OK. I was trying to avoid hardcoding the location of libapr-0.a for the apache13 apxs
build. It doesn't use libtool and needs to
link to it. When apr is not installed, apr-config --link-ld doesn't generate the
correct location for the library (it is missing the
.libs).
Cheers
Jean-Fredreric
The following patch doesn't install apr (and apr-util). It appends the /.libs to the
--link-ld using sed. You or I can commit this
or something like it tomorrow if you prefer not to install apr.
Index: native2/Makefile.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/Makefile.in,v
retrieving revision 1.6
diff -u -r1.6 Makefile.in
--- native2/Makefile.in 10 Mar 2004 09:47:34 - 1.6
+++ native2/Makefile.in 18 Mar 2004 04:22:47 -
@@ -57,7 +57,6 @@
apr-build:
( cd @APR_DIR@ make cd @APR_UTIL_DIR@ make )
- ( cd @APR_DIR@ make install cd @APR_UTIL_DIR@ make install )
apr-clean:
( cd @APR_DIR@ make clean cd @APR_UTIL_DIR@ make clean )
Index: native2/server/apache13/Makefile.apxs.in
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache13/Makefile.apxs.in,v
retrieving revision 1.10
diff -u -r1.10 Makefile.apxs.in
--- native2/server/apache13/Makefile.apxs.in 13 Feb 2004 21:38:26 - 1.10
+++ native2/server/apache13/Makefile.apxs.in 18 Mar 2004 04:22:47 -
@@ -7,8 +7,8 @@
[EMAIL PROTECTED]@
C_FILES=jk_service_apache13.c mod_jk2.c
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@/bin/apr-config --link-ld`
[EMAIL PROTECTED]@/bin/apu-config --link-ld`
[EMAIL PROTECTED]@/apr-config --link-ld | sed 's|@APR_DIR@|@APR_DIR@/.libs|'`
[EMAIL PROTECTED]@/apu-config --link-ld | sed 's|@APR_UTIL_DIR@|@APR_UTIL_DIR@/.libs|'`
ifneq ($(strip $(JAVA_HOME)),)
JAVA_INCL=-I ${JAVA_HOME}/include -I ${JAVA_HOME}/include/${OS} @HAVE_JNI@
Index: support/jk_apr.m4
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/support/jk_apr.m4,v
retrieving revision 1.13
diff -u -r1.13 jk_apr.m4
--- support/jk_apr.m4 24 Feb 2004 08:41:40 - 1.13
+++ support/jk_apr.m4 18 Mar 2004 04:22:47 -
@@ -88,7 +88,7 @@
tempret=0
JK_EXEC(
[tempret],
- [${SHELL} ./configure --prefix=${APR_DIR}
--with-installbuilddir=${APR_DIR}/instbuild --disable-shared
${APR_CONFIGURE_ARGS}],
+ [${SHELL} ./configure --disable-shared ${APR_CONFIGURE_ARGS}],
[apr],
[${APR_DIR}])
if ${TEST} ${tempret} = 0; then
@@ -97,7 +97,7 @@
AC_MSG_ERROR(apr configure failed with ${tempret})
fi
JK_APR_LIBNAME(apr_libname,${APR_DIR})
-APR_LDFLAGS=${APR_DIR}/lib/${apr_libname}
+APR_LDFLAGS=${APR_DIR}/${apr_libname}
APR_LIBDIR=
use_apr=true
COMMON_APR_OBJECTS=\${COMMON_APR_OBJECTS}
@@ -154,7 +154,7 @@
tempret=0
JK_EXEC(
[tempret],
- [${SHELL} ./configure --prefix=${APR_UTIL_DIR} --with-apr=${APR_DIR}],
+ [${SHELL} ./configure --with-apr=${APR_DIR}],
[apr-util],
[${APR_UTIL_DIR}])
if ${TEST} ${tempret} = 0; then
@@ -163,7 +163,7 @@
AC_MSG_ERROR(apr-util configure failed with ${tempret})
fi
JK_APR_UTIL_LIBNAME(apr_util_libname,${APR_UTIL_DIR})
-APR_LDFLAGS=${APR_LDFLAGS} ${APR_UTIL_DIR}/lib/${apr_util_libname}
+APR_LDFLAGS=${APR_LDFLAGS} ${APR_UTIL_DIR}/${apr_util_libname}
APR_UTIL_LIBDIR=
use_apr=true
COMMON_APR_OBJECTS=\${COMMON_APR_OBJECTS}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Releasing JK 2.0.4]
From: jean-frederic clere [EMAIL PROTECTED] Henri Gomez wrote: jean-frederic clere wrote: Henri Gomez wrote: jean-frederic clere wrote: Henri Gomez wrote: jean-frederic clere wrote: Mladen Turk wrote: -Original Message- From: jean-frederic clere I have the following error: +++ # sbin/apachectl start Syntax error on line 250 of /opt/SMAWoIS/apache13/conf/httpd.conf: Cannot load /opt/SMAWoIS/apache13/libexec/mod_jk2.so into server: ld.so.1: /opt/SMAWoIS/apache13/sbin/httpd: fatal: relocation error: file /opt/SMAWoIS/apache13/libexec/mod_jk2.so: symbol jk_jni_status_code: referenced symbol not found sbin/apachectl start: httpd could not be started The jk_jni_status_code is int defined in jni/jk_jni_aprImpl.c Something went wrong during compilation? Nothing but jk_jni_aprImpl.o is not in mod_jk2.so so jk_jni_status_code is undefined. So jk_jni_aprImpl.c has not been compiled. What's your configure line ? CC=cc -xtarget=ultra -xarch=v8plus -xO5 -xstrconst -xdepend -Xa \ ./configure --with-apxs=/opt/SMAWoIS/apache13/sbin/apxs --with-apr=/export/home3/jfclere/tmp/apr-0.9.4 --with-apr-util=/export/home3/jfclere/tmp/apr-util-0.9.4 --with-jni Ok. Could you see if the jk_jni_aprImpl.c is built ? No it is not build. So that's the problem. Could you send a compile log ? That is just a note to tell that not using --with-jni helps. Yes, there's still some arranging to do for --with-jni. This is what I think is working and not. server/apache2/Makefile.in - OK server/apache2/Makefile.apxs.in - probably needs work. server/apache13/Makefile.in - needs work server/apache13/Makefile.apxs.in - needs work I've also noted that --with-pcre needs some tweaking at least for FreeBSD. For apache2 I needed to add -L/usr/local/lib to PCRE_LIBS in jk_pcre.m4 For apache13 I think I needed to add -I /usr/local/include too. All the above is on my personal todo list (help is welcome;-). I have some time tomorrow and Friday to look at some of this, but I'm not sure if its worth holding up the release or not. -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 2.0.4 release
From: Mladen Turk [EMAIL PROTECTED] Have you (or pehaps others too) been able to test the new shm implementation? I've tested it on FreeBSD Apache/2.0.48 prefork. anon is working ok, but file is not. Looks like I've got a similar problem as Greg. I'm getting permission errors (httpd runs as user/group www/www). [Mon Mar 15 07:59:49 2004] [notice] shm.create() Created head 30048000 size 8192 [Mon Mar 15 07:59:50 2004] (debug ) [jk_shm.c (160)] shm.init(): file=/var/log/jk2.shm size=2162688 [Mon Mar 15 07:59:50 2004] (error ) [jk_shm.c (102)] shm.create(): error creating shm 13 Permission denied [Mon Mar 15 07:59:50 2004] (error ) [jk_shm.c (168)] shm.create(): error creating shm /var/log/jk2.shm [Mon Mar 15 07:59:50 2004] (debug ) [jk_shm.c (160)] shm.init(): file=/var/log/jk2.shm size=2162688 [Mon Mar 15 07:59:50 2004] (error ) [jk_shm.c (102)] shm.create(): error creating shm 13 Permission denied [Mon Mar 15 07:59:50 2004] (error ) [jk_shm.c (168)] shm.create(): error creating shm /var/log/jk2.shm -rw-r--r-- 1 root wheel 4 Mar 15 07:59 /var/log/jk2.shm UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 0 4835 1 0 2 0 6916 3480 select Ss??0:00.05 /usr/local/sbin/httpd -k start 80 4836 4835 0 2 0 6924 3516 accept I ??0:00.02 /usr/local/sbin/httpd -k start 80 4837 4835 0 2 0 6916 3492 accept I ??0:00.01 /usr/local/sbin/httpd -k start 80 4838 4835 0 2 0 6916 3492 accept I ??0:00.01 /usr/local/sbin/httpd -k start 80 4839 4835 0 2 0 6916 3492 accept I ??0:00.01 /usr/local/sbin/httpd -k start 80 4840 4835 0 2 0 6916 3492 accept I ??0:00.01 /usr/local/sbin/httpd -k start 80 4861 4835 0 2 0 6916 3492 accept I ??0:00.01 /usr/local/sbin/httpd -k start - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_shm.c
As of this commit my shm file rights problem on FreeBSD Apache/2.0.48
prefork is gone. ;-)
I've also tested both anon and file shm on OpenBSD Apache/1.3.29
successfully.
The new shm implementation is looking good to me.
-Kurt
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, March 15, 2004 3:09 PM
Subject: cvs commit: jakarta-tomcat-connectors/jk/native2/common
jk_shm.c
mturk 2004/03/15 12:09:30
Modified:jk/native2/common jk_shm.c
Log:
Supress duplicate initialization for shm, that causes duplicate
shm initialization.
There is also unneded call to shm-init inside the
workerEnv-parentInit,
since it is caled after workerEnv-init, but now it doesn't mater.
Revision ChangesPath
1.43 +6 -0
jakarta-tomcat-connectors/jk/native2/common/jk_shm.c
Index: jk_shm.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_shm.c,v
retrieving revision 1.42
retrieving revision 1.43
diff -u -r1.42 -r1.43
--- jk_shm.c 13 Mar 2004 08:47:31 - 1.42
+++ jk_shm.c 15 Mar 2004 20:09:30 - 1.43
@@ -141,6 +141,12 @@
int rv=JK_OK;
+/* In case the shm has been initialized already
+ * for the current process.
+ */
+if (shm-head shm-image)
+return rv;
+
shm-privateData = NULL;
if (shm-fname == NULL) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 new shmem using APR
From: Andy Armstrong [EMAIL PROTECTED] Guenter Knauf wrote: I believe there's a problem with the file rights, not with SHM self. I think the scoreboard is created by the init process, but later on when the child wants to access it it has insufficient rights. I think I'm seeing that same problem with Apache 2.0.48 and the latest j-t-c code on Debian. Did it include Mladen's latest commit? I'm no longer experiencing this problem with the most recent source. -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 2.0.4 release
From: Henri Gomez [EMAIL PROTECTED] Hi, We see many bug fixes in the last 2 weeks in jk2, and I wonder if some of you still have some corrections to commit. I plan to tag jk2 next Monday morning, and make the release on monday afternoon. If nobody object, I'll do like this +1 as soon as Mladen is ready. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
libjkjni and pcre build
libjkjni is built when --with-jni is not specified at configure time. When this happens it is not usable, so I'll be changing the build to only build libjkjni when --with-jni is specified. I overlooked one thing with the recent pcre changes I committed. The functions ap_pregcomp and ap_regexec will not be available to libjkjni.so and are left unresolved. This will be a problem for jni inprocess mode. I have to make a change to correct this. Two options I see are: 1) Revert to old behavior and not use ap_pregcomp and ap_regexec at all. This is the most straightforward. If you want pcre then you must specify it with --with-pcre. 2) Use ap_pregcomp and ap_regexec only when --with-jni is not specified. This would behave as follows: a) if --with-pcre and --with-jni are not specified then use ap_pregcomp and ap_regexec. b) if --with-jni is specified but -with-pcre is not, then no pcre support. c) if --with-jni and --with-pcre are specified then use regcomp and regexec. Option two is a bit more confusing but gives more flexibility. I'm leaning towards reverting to the old behavior. Thoughts anyone? -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: libjkjni and pcre build
Embarrassingly replying to myself I misstated something before. The pcre change is not a problem for inprocess mode, its a problem for jni out of process mode (i.e. apr.NativeSo=libjkjni.so). I think the most reasonable solution is to work as follows: --with-pcre and no --with-jni, use apache pcre functions --with-pcre and --with-jni, use external pcre functions --with-pcre is absent, no pcre support. So if you want pcre you will need to specify it when configuring. You will get either apache pcre or external pcre depending if you specify --with-jni or not. I'll go forward with this unless someone has a better idea. -Kurt From: Kurt Miller [EMAIL PROTECTED] libjkjni is built when --with-jni is not specified at configure time. When this happens it is not usable, so I'll be changing the build to only build libjkjni when --with-jni is specified. I overlooked one thing with the recent pcre changes I committed. The functions ap_pregcomp and ap_regexec will not be available to libjkjni.so and are left unresolved. This will be a problem for jni inprocess mode. I have to make a change to correct this. Two options I see are: 1) Revert to old behavior and not use ap_pregcomp and ap_regexec at all. This is the most straightforward. If you want pcre then you must specify it with --with-pcre. 2) Use ap_pregcomp and ap_regexec only when --with-jni is not specified. This would behave as follows: a) if --with-pcre and --with-jni are not specified then use ap_pregcomp and ap_regexec. b) if --with-jni is specified but -with-pcre is not, then no pcre support. c) if --with-jni and --with-pcre are specified then use regcomp and regexec. Option two is a bit more confusing but gives more flexibility. I'm leaning towards reverting to the old behavior. Thoughts anyone? -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: libjkjni and pcre build
Hi Guenter, Your welcome. ;-) Your email made me realize there no difference between using the ap_pregcomp and ap_regexec functions and the regcomp and regexec functions on platforms that use configure. So I can simplify this a bit more and always use regcomp and regexec when --with-pcre is specified. Netware and Windows can still use the ap_ functions since they don't have to deal with libjkjni. -Kurt From: Guenter Knauf [EMAIL PROTECTED] Hi Kurt, thanks for going this way - I have no choice on NetWare since the PCRE functions are not exported at all. Guenter. I misstated something before. The pcre change is not a problem for inprocess mode, its a problem for jni out of process mode (i.e. apr.NativeSo=libjkjni.so). I think the most reasonable solution is to work as follows: --with-pcre and no --with-jni, use apache pcre functions --with-pcre and --with-jni, use external pcre functions --with-pcre is absent, no pcre support. So if you want pcre you will need to specify it when configuring. You will get either apache pcre or external pcre depending if you specify --with-jni or not. I'll go forward with this unless someone has a better idea. -Kurt From: Kurt Miller [EMAIL PROTECTED] libjkjni is built when --with-jni is not specified at configure time. When this happens it is not usable, so I'll be changing the build to only build libjkjni when --with-jni is specified. I overlooked one thing with the recent pcre changes I committed. The functions ap_pregcomp and ap_regexec will not be available to libjkjni.so and are left unresolved. This will be a problem for jni inprocess mode. I have to make a change to correct this. Two options I see are: 1) Revert to old behavior and not use ap_pregcomp and ap_regexec at all. This is the most straightforward. If you want pcre then you must specify it with --with-pcre. 2) Use ap_pregcomp and ap_regexec only when --with-jni is not specified. This would behave as follows: a) if --with-pcre and --with-jni are not specified then use ap_pregcomp and ap_regexec. b) if --with-jni is specified but -with-pcre is not, then no pcre support. c) if --with-jni and --with-pcre are specified then use regcomp and regexec. Option two is a bit more confusing but gives more flexibility. I'm leaning towards reverting to the old behavior. Thoughts anyone? -Kurt --- - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2
From: Al Banard [EMAIL PROTECTED] /bin/sh /usr/lib/apache2/build/libtool --silent --mode=install /bin/cp ../../../build/jk2/apache2/mod_jk2.la `pwd`/../../../build/jk2/apache2 ... /bin/sh /usr/lib/apache2/build/libtool --silent --mode=install /bin/cp ../../../build/jk2/apache2/libjkjni.la `pwd`/../../../build/jk2/apache2 make[1]: Leaving directory `/usr/src/redhat/BUILD/jakarta-tomcat-connectors/jk/native2/server/apa che2' This appears to have finished without error. Is mod_jk2.so in ../build/jk2/apache2 now? -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
Could one of the more senior jtc committers review this for me please?
The problem was that jk_lb_refresh was being called for each channel
parsed and adding all the workers to the workersTable each time. The
result was that the first channel was added to the table n+1 times
(where n = total number of workers), the second channel was added n
times and the third channel n-1, etc. Consequently the table was
getting overrun.
I believe this problem may also account for the first channel(s)
getting more load because of the extra copies in the table.
-Kurt
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, March 08, 2004 6:01 PM
Subject: cvs commit: jakarta-tomcat-connectors/jk/native2/common
jk_worker_lb.c
truk2004/03/08 15:01:07
Modified:jk/native2/common jk_worker_lb.c
Log:
Fix bug 23483
Only add worker to the workerTable if it is not already there.
Add check for maximum workers too.
Revision ChangesPath
1.38 +21 -5
jakarta-tomcat-connectors/jk/native2/common/jk_worker_lb.c
Index: jk_worker_lb.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_worker_lb.c,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- jk_worker_lb.c 27 Feb 2004 08:34:18 - 1.37
+++ jk_worker_lb.c 8 Mar 2004 23:01:06 - 1.38
@@ -448,7 +448,8 @@
char *name = lb-lbWorkerMap-nameAt( env,
lb-lbWorkerMap, i);
jk_worker_t *w= env-getByName( env, name );
int level=0;
-int pos=0;
+int pos;
+int workerCnt;
if( w== NULL ) {
env-l-jkLog(env, env-l, JK_LOG_ERROR,
@@ -463,12 +464,27 @@
/* It's like disabled */
if( level = JK_LB_LEVELS ) continue;
-pos=lb-workerCnt[level]++;
+/* check if worker is already in the table */
+workerCnt = lb-workerCnt[level];
+for(pos = 0 ; pos workerCnt ; pos++) {
+if( lb-workerTables[level][pos] == w ) {
+break;
+}
+}
+
+if( pos == workerCnt ) {
+if( pos == JK_LB_MAX_WORKERS ) {
+env-l-jkLog(env, env-l, JK_LOG_ERROR,
+ lb_worker.init(): maximum lb
workers reached %s\n, name);
+continue;
+}
+pos=lb-workerCnt[level]++;
-lb-workerTables[level][pos]=w;
+lb-workerTables[level][pos]=w;
-w-lb_value = w-lb_factor;
-w-in_error_state = JK_FALSE;
+w-lb_value = w-lb_factor;
+w-in_error_state = JK_FALSE;
+}
}
return JK_OK;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf CharChunk.java
From: Remy Maucherat [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: remm2004/03/05 05:08:00 Modified:util/java/org/apache/tomcat/util/buf CharChunk.java Log: - Same fix. - Make calls to realReads compatible with marking (which is just for cleaness, as the parameters are not used in our use case). - Make makeSpace compatible with marking, which needs to be supported by char chunks. I hope I didn't break anything with these changes ... Maybe it would be a good idea to tag 3.3.x before these, to be safe. If 3.3.x is tagged before this change it probably would be a good idea to pick up the JkInputStream change I committed earlier. It fixes a problem where small packets were getting dropped and causing the last one or two bytes of post data to be lost for certain sized posts. Of course, it should only impact char buffers which are allowed to grow significantly, which aren't used a lot (AFAIK). In Tomcat 5, I believe we play with setLimit dynamically only for char input. Please test it :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2
Are you using the current source from CVS or http://cvs.apache.org/snapshots/jakarta-tomcat-connectors/ yet? libtool is set correctly for you in the current version. Simply configure with --with-apxs2 with current source and it should be correctly set for you. From: Al Banard [EMAIL PROTECTED] Thanks, Unfortunately my OS is Gentoo and after installing there ebuild (basically equivalent to an RPM) directories are all over the place. The base location of apache is actually /etc/apache2 but when I try using this as a configure option I get this message: building connector for apache-2.0 configure: error: can't locate /etc/apache2/ and configure dies. Here is a list of the more relevant files that were installed with the package. Do you have any idea as to what I should put as my argumernt to the configure option? libtool is in /usr/lib/apache2/build/libtool but I've tried passing different combinations of this path without any luck. bash-2.05b# qpkg -l apache net-www/apache-2.0.48-r1 * CONTENTS: /usr /usr/include /usr/include/apache2 /usr/include/apache2/apr.h /usr/include/apache2/apr_allocator.h /usr/include/apache2/apr_atomic.h ... /usr/include/apache2/ssl_util_ssl.h /usr/include/apache2/ssl_util_table.h /usr/include/apache2/pcre.h /usr/include/apache2/unixd.h /usr/lib /usr/lib/libapr-0.so.0.9.5 /usr/lib/libapr-0.so.0 - libapr-0.so.0.9.5 /usr/lib/libapr-0.so - libapr-0.so.0.9.5 /usr/lib/libapr-0.la /usr/lib/libapr-0.a /usr/lib/apr.exp /usr/lib/apache2 /usr/lib/apache2/build /usr/lib/apache2/build/libtool /usr/lib/apache2/build/apr_rules.mk /usr/lib/apache2/build/config_vars.mk /usr/lib/apache2/build/library.mk /usr/lib/apache2/build/ltlib.mk /usr/lib/apache2/build/program.mk /usr/lib/apache2/build/rules.mk /usr/lib/apache2/build/special.mk /usr/lib/apache2/build/instdso.sh /usr/lib/apache2/build/config.nice /usr/lib/apache2/build/envvars /usr/lib/apache2/build/envvars-std /usr/lib/apache2/mod_access.so /usr/lib/apache2/mod_auth.so /usr/lib/apache2/mod_auth_anon.so ... /usr/lib/apache2/mod_userdir.so /usr/lib/apache2/mod_alias.so /usr/lib/apache2/mod_rewrite.so /usr/lib/apache2/httpd.exp /usr/lib/libaprutil-0.so.0.9.5 /usr/lib/libaprutil-0.so.0 - libaprutil-0.so.0.9.5 /usr/lib/libaprutil-0.so - libaprutil-0.so.0.9.5 /usr/lib/libaprutil-0.la /usr/lib/libaprutil-0.a /usr/lib/aprutil.exp /usr/lib/ssl /usr/lib/ssl/apache2-mod_ssl /usr/lib/ssl/apache2-mod_ssl/gentestcrt.sh /usr/lib/apache2-extramodules /usr/lib/apache2-extramodules/mod_ssl.so /usr/bin /usr/bin/apr-config /usr/bin/apu-config /usr/sbin /usr/sbin/ab2 /usr/sbin/logresolve2 /usr/sbin/apxs2 /usr/sbin/dbmmanage2 /usr/sbin/ab2-ssl /usr/sbin/suexec2 /usr/sbin/htdbm /usr/sbin/htdigest2 /usr/sbin/checkgid2 /usr/sbin/rotatelogs2 /usr/sbin/apache2 /usr/sbin/apache2logserverstatus /usr/sbin/apache2splitlogfile /usr/sbin/list_hooks2.pl /usr/sbin/logresolve2.pl /usr/sbin/apache2ctl /usr/sbin/htpasswd2 /usr/sbin/split-logfile2 /usr/sbin/log_server_status2 /usr/share /usr/share/man /usr/share/man/man1 ... /usr/share/man/man8/apache2.8.gz /usr/share/man/man8/apache2ctl.8.gz /usr/share/man/man8/logresolve2.8.gz /usr/share/doc /usr/share/doc/apache-2.0.48-r1 /usr/share/doc/apache-2.0.48-r1/manual ... From: jean-frederic clere [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2 Date: Tue, 24 Feb 2004 16:16:31 +0100 Al Banard wrote: Hi Henri, Thanks for giving me help. OK, I have to admit I don't know a lot about libtool. I'm using apache 2.0.48 and have also installed apr-0.9.2. How do I specify to use the libtool from Apache 2.0 / APR? That is what is done when you use --with-apache2=$HOME/httpd-2.0.48. It works for me with the actual CVS and libtool-1.5.2 and automake-1.6.1 (I build and install automake after libtool). From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2 Date: Tue, 24 Feb 2004 14:57:49 +0100 Continuing this thread on tomcat-dev. Well you should use the libtool from Apache 2.0 / APR. Which version of Apache 2.0 are you using ? [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=27006. 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=27006 libtool: install: error: cannot install
Re: [PATCH] use ap_ prefixed PCRE functions - take 3
Hi Guenter,
Just a tweak or two and its ready. The preg calloc only applies to the
HAS_PCRE case and PREGCOMP isn't needed. Otherwise it looks good. I'll
test and commit it tomorrow.
-Kurt
From: Guenter Knauf [EMAIL PROTECTED]
Hi Kurt,
I've reviewed your patch and have some comments included inline
below.
regcomp and ap_pregcomp are not interchangeable like this.
ap_pregcomp
needs an apr_pool to be passed to it and it returns the regex_t. I
think (apr_pool_t *)uriEnv-pool-_private is correct here
(Henri?,
Jean-Frederic?).
ok, I believe I got that now. For easier review I copy here the
relevant parts of the headers, followed by the new patch. Please
review again - if it is ok so, I put the patchfile on my host, and add
the other suggestions to the makefiles.
thanks, Guenter.
/**
* Compile a regular expression to be used later
* @param p The pool to allocate from
* @param pattern the regular expression to compile
* @param cflags The bitwise or of one or more of the following:
* @li #REG_EXTENDED - Use POSIX extended Regular Expressions
* @li #REG_ICASE- Ignore case
* @li #REG_NOSUB- Support for substring addressing of matches
* not required
* @li #REG_NEWLINE - Match-any-character operators don't match
new-line
* @return The compiled regular expression
*/
AP_DECLARE(regex_t *) ap_pregcomp(apr_pool_t *p, const char
*pattern,
int cflags);
/**
* Match a null-terminated string against a pre-compiled regex.
* @param preg The pre-compiled regex
* @param string The string to match
* @param nmatch Provide information regarding the location of any
matches
* @param pmatch Provide information regarding the location of any
matches
* @param eflags Bitwise or of any of:
* @li #REG_NOTBOL - match-beginning-of-line operator always
* fails to match
* @li #REG_NOTEOL - match-end-of-line operator always fails to
match
* @return 0 for successful match, #REG_NOMATCH otherwise
*/
AP_DECLARE(int)ap_regexec(regex_t *preg, const char *string,
size_t nmatch, regmatch_t pmatch[],
int eflags);
extern int regcomp(regex_t *, const char *, int);
extern int regexec(regex_t *, const char *, size_t, regmatch_t *,
int);
##
#
--- jk_uriEnv.c.orig Tue Feb 24 12:30:10 2004
+++ jk_uriEnv.c Thu Feb 26 20:34:46 2004
@@ -28,9 +28,15 @@
#include jk_uriMap.h
#include jk_registry.h
+#ifdef HAS_AP_PCRE
+#include httpd.h
+#define PREGCOMP ap_pregcomp
+#else
#ifdef HAS_PCRE
#include pcre.h
#include pcreposix.h
+#define PREGCOMP regcomp
+#endif
#endif
/* return non-zero if pattern has any glob chars in it */
@@ -65,7 +71,7 @@
int pcre = 0;
if (*name == '$') {
-#ifdef HAS_PCRE
+#if defined(HAS_PCRE) || defined(HAS_AP_PCRE)
++name;
uriEnv-uri = uriEnv-pool-pstrdup(env, uriEnv-pool,
name);
uriEnv-match_type = MATCH_TYPE_REGEXP;
@@ -74,7 +80,11 @@
name);
{
regex_t *preg = (regex_t *)uriEnv-pool-calloc( env,
uriEnv-pool, sizeof(regex_t));
+#ifdef HAS_AP_PCRE
+if ((preg = ap_pregcomp((apr_pool_t
*)uriEnv-pool-_private, uriEnv-uri, REG_EXTENDED)) == NULL) {
+#else
if (regcomp(preg, uriEnv-uri, REG_EXTENDED)) {
+#endif
env-l-jkLog(env, env-l, JK_LOG_DEBUG,
uriEnv.parseName() error compiling
regexp %s\n,
uri);
@@ -132,14 +142,18 @@
if (pcre) {
++uri;
uriEnv-match_type = MATCH_TYPE_REGEXP;
-#ifdef HAS_PCRE
+#if defined(HAS_PCRE) || defined(HAS_AP_PCRE)
uriEnv-uri = uriEnv-pool-pstrdup(env, uriEnv-pool,
uri);
env-l-jkLog(env, env-l, JK_LOG_DEBUG,
uriEnv.parseName() parsing regexp %s\n,
uri);
{
regex_t *preg = (regex_t *)uriEnv-pool-calloc( env,
uriEnv-pool, sizeof(regex_t));
+#ifdef HAS_AP_PCRE
+if ((preg = ap_pregcomp((apr_pool_t
*)uriEnv-pool-_private, uriEnv-uri, REG_EXTENDED)) == NULL) {
+#else
if (regcomp(preg, uriEnv-uri, REG_EXTENDED)) {
+#endif
env-l-jkLog(env, env-l, JK_LOG_DEBUG,
uriEnv.parseName() error compiling
regexp %s\n,
uri);
##
#
--- jk_uriMap.c.orig Tue Feb 24 12:30:10 2004
+++ jk_uriMap.c Thu Feb 26 19:03:32 2004
@@ -34,9 +34,15 @@
#include jk_uriMap.h
#include jk_registry.h
+#ifdef HAS_AP_PCRE
+#include httpd.h
+#define REGEXEC ap_regexec
+#else
#ifdef HAS_PCRE
#include pcre.h
#include pcreposix.h
+#define REGEXEC regexec
+#endif
#endif
static INLINE const char *jk2_findExtension(jk_env_t *env, const
char *uri);
@@ -304,7 +310,7 @@
return uriMap-vhosts-get(env,
Re: [PATCH] use ap_ prefixed PCRE functions - take 2
Hi Guenter,
I've reviewed your patch and have some comments included inline below.
From: Guenter Knauf [EMAIL PROTECTED]
Hi all,
the previous patch seems to break non-Apache connectors, so here's
another patch which shouldnt break anything unless you set the
HAVE_AP_PCRE.
I would like to get this patch into CVS in order to use PCRE on
NetWare where only the ap_ prefixed pcre functions are exported. I
have tested that the patch below compiles fine with NetWare, Linux and
Win32.
As a positive side effect on Win32 the binary is about 24 kb
smaller.
Also this time tested that the isapi redirector still compiles fine.
thanks, Guenter.
http://www.gknw.com/test/pcre_patch2
##
#
--- ./jk/native2/common/jk_uriEnv.c.orig 2004-02-24
12:30:10.0 +0100
+++ ./jk/native2/common/jk_uriEnv.c 2004-02-26 00:12:57.0
+0100
@@ -29,8 +29,16 @@
#include jk_registry.h
#ifdef HAS_PCRE
-#include pcre.h
-#include pcreposix.h
+ #ifdef HAS_AP_PCRE
+#include httpd.h
+#undef regcomp
+#define regcomp ap_pregcomp
regcomp and ap_pregcomp are not interchangeable like this. ap_pregcomp
needs an apr_pool to be passed to it and it returns the regex_t. I
think (apr_pool_t *)uriEnv-pool-_private is correct here (Henri?,
Jean-Frederic?).
I'm not a fan of undef/def functions like this. If the functions were
interchangeable, I would have just created a new define like PREGCOMP
that points to the correct function.
+#define REGEX_POOL apr_pool_t
+ #else
+#include pcre.h
+#include pcreposix.h
+#define REGEX_POOL regex_t
+ #endif
#endif
Since Apache2 always comes with pcre whole define section would be
better like this:
#ifdef HAS_AP_PCRE
#include httpd.h
#else
#ifdef HAS_PCRE
#include pcre.h
#include pcreposix.h
#endif
#endif
This way Apache2 will not require the --with-pcre configure argument
that also includes -lpcre -lpcreposix libs when linking (not needed
for Apache2).
Along with this change you need to change server/apache2/Makefile.in
and Makefile.apx.in to remove @HAS_PCRE@ and @PCRE_LIBS@ and
add -DHAS_AP_PCRE.
/* return non-zero if pattern has any glob chars in it */
@@ -73,7 +81,7 @@
uriEnv.parseName() parsing %s regexp\n,
name);
{
-regex_t *preg = (regex_t *)uriEnv-pool-calloc( env,
uriEnv-pool, sizeof(regex_t));
+REGEX_POOL *preg = (REGEX_POOL
*)uriEnv-pool-calloc( env, uriEnv-pool, sizeof(regex_t));
Similar to my comments above, this calloc and casting to apr_pool_t is
not correct for ap_pregcomp.
if (regcomp(preg, uriEnv-uri, REG_EXTENDED)) {
env-l-jkLog(env, env-l, JK_LOG_DEBUG,
uriEnv.parseName() error compiling
regexp %s\n,
@@ -138,7 +146,7 @@
uriEnv.parseName() parsing regexp %s\n,
uri);
{
-regex_t *preg = (regex_t *)uriEnv-pool-calloc( env,
uriEnv-pool, sizeof(regex_t));
+REGEX_POOL *preg = (REGEX_POOL
*)uriEnv-pool-calloc( env, uriEnv-pool, sizeof(regex_t));
if (regcomp(preg, uriEnv-uri, REG_EXTENDED)) {
env-l-jkLog(env, env-l, JK_LOG_DEBUG,
uriEnv.parseName() error compiling
regexp %s\n,
##
#
--- ./jk/native2/common/jk_uriMap.c.orig 2004-02-24
12:30:10.0 +0100
+++ ./jk/native2/common/jk_uriMap.c 2004-02-26 00:13:09.0
+0100
@@ -35,8 +35,14 @@
#include jk_registry.h
#ifdef HAS_PCRE
-#include pcre.h
-#include pcreposix.h
+ #ifdef HAS_AP_PCRE
+#include httpd.h
+#undef regexec
+#define regexec ap_regexec
+ #else
+#include pcre.h
+#include pcreposix.h
+ #endif
#endif
Similar to above comments, I'd like to something like this instead:
#ifdef HAS_AP_PCRE
#include httpd.h
#define REGEXEC ap_regexec
#else
#ifdef HAS_PCRE
#include pcre.h
#include pcreposix.h
#define REGEXEC regexec
#endif
#endif
static INLINE const char *jk2_findExtension(jk_env_t *env, const
char *uri);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2
From: Al Banard [EMAIL PROTECTED] Hi Henri, Thanks for giving me help. OK, I have to admit I don't know a lot about libtool. I'm using apache 2.0.48 and have also installed apr-0.9.2. How do I specify to use the libtool from Apache 2.0 / APR? Could you try building from current source via CVS or a source snapshot? Many issues have been adressed in the current version (soon to be released). Download a source snapshot here: http://cvs.apache.org/snapshots/jakarta-tomcat-connectors/ From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2 Date: Tue, 24 Feb 2004 14:57:49 +0100 Continuing this thread on tomcat-dev. Well you should use the libtool from Apache 2.0 / APR. Which version of Apache 2.0 are you using ? [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=27006. 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=27006 libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2 --- Additional Comments From [EMAIL PROTECTED] 2004-02-24 13:53 --- I just tried libtool 1.5.2-r3 and I still get the same error. Can you think of anything else (program versions / configure options / steps) I might be doing differently to you? Here is a recap of my steps: cd jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/ chmod 0777 buildconf.sh ./buildconf.sh ./configure --with-java-home=/opt/sun-jdk-1.4.2.03 --with-apxs2=/usr/sbin/apxs2 --with-tomcat41=/usr/local/tomcat make clean build libtool --finish /usr/lib/apache2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Hot chart ringtones and polyphonics. Go to http://ninemsn.com.au/mobilemania/default.asp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK2 release Expat
Thanks Greg for all the detailed information. I've committed the fix for this. Could you update your source and let us know how it goes? -Kurt From: [EMAIL PROTECTED] Few, apr-utils has a dependency on expat, yet when linking mod_jk2 apr-config --libs is used: `/var/tmp/temo/apr-0.9.4/apr-config --libs` However apr-config / apr does not have a dependency on expat, so it does not return the right line with -L/usr/local/bin -lexpat (in my case added) The the line that gets spat out should look like (notice I've added the expat bit at the end): /bin/sh ../../libtool --mode=link cc -avoid-version -module -rpath /WWW/app/apache/1.3.26c/libexec -L/WWW/app/apache/1.3.26c/lib -o ../../../build/jk2/apache13/mod_jk2.la ../../../build/jk2/apache13/jk_channel.lo ../../../build/jk2/apache13/jk_channel_apr_socket.lo ../../../build/jk2/apache13/jk_channel_jni.lo ../../../build/jk2/apache13/jk_channel_un.lo ../../../build/jk2/apache13/jk_config.lo ../../../build/jk2/apache13/jk_config_file.lo ../../../build/jk2/apache13/jk_endpoint.lo ../../../build/jk2/apache13/jk_env.lo ../../../build/jk2/apache13/jk_handler_logon.lo ../../../build/jk2/apache13/jk_handler_response.lo ../../../build/jk2/apache13/jk_logger_file.lo ../../../build/jk2/apache13/jk_logger_win32.lo ../../../build/jk2/apache13/jk_map.lo ../../../build/jk2/apache13/jk_md5.lo ../../../build/jk2/apache13/jk_msg_ajp.lo ../../../build/jk2/apache13/jk_mutex.lo ../../../build/jk2/apache13/jk_mutex_proc.lo ../../../build/jk2/apache13/jk_mutex_thread.lo ../../../build/jk2/apache13/jk_nwmain.lo ../../../build/jk2/apache13/jk_objCache.lo ../../../build/jk2/apache13/jk_pool_apr.lo ../../../build/jk2/apache13/jk_registry.lo ../../../build/jk2/apache13/jk_requtil.lo ../../../build/jk2/apache13/jk_shm.lo ../../../build/jk2/apache13/jk_signal.lo ../../../build/jk2/apache13/jk_uriEnv.lo ../../../build/jk2/apache13/jk_uriMap.lo ../../../build/jk2/apache13/jk_user.lo ../../../build/jk2/apache13/jk_vm_default.lo ../../../build/jk2/apache13/jk_workerEnv.lo ../../../build/jk2/apache13/jk_worker_ajp13.lo ../../../build/jk2/apache13/jk_worker_jni.lo ../../../build/jk2/apache13/jk_worker_lb.lo ../../../build/jk2/apache13/jk_worker_run.lo ../../../build/jk2/apache13/jk_worker_status.lo ../../../build/jk2/apache13/jk_service_apache13.lo ../../../build/jk2/apache13/mod_jk2.lo /var/tmp/temo/apr-0.9.4/lib/libapr-0.la /var/tmp/temo/apr-util-0.9.4/lib/libaprutil-0.la `/var/tmp/temo/apr-0.9.4/apr-config --libs` -L/usr/local/bin -lexpat ldd now has an entry for libexpat, and the mod_jk2.so loads. Perhaps other expats are build differently? Clear as mud? Greg -Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED] Sent: 19 February 2004 15:56 To: Tomcat Developers List Subject: Re: JK2 release Expat [EMAIL PROTECTED] wrote: -Original Message- From: jean-frederic clere [mailto:[EMAIL PROTECTED] Sent: 18 February 2004 17:05 To: Tomcat Developers List Subject: Re: JK2 release Expat Henri Gomez wrote: a ldd /var/tmp/mod_jk2_new.so would be nice to have. Close but no cigar ( I checked that before posting) but here for completeness; $ ldd /var/tmp/mod_jk2_new.so libsendfile.so.1 = /usr/lib/libsendfile.so.1 librt.so.1 =/usr/lib/librt.so.1 libm.so.1 = /usr/lib/libm.so.1 libsocket.so.1 =/usr/lib/libsocket.so.1 libnsl.so.1 = /usr/lib/libnsl.so.1 libresolv.so.2 =/usr/lib/libresolv.so.2 libpthread.so.1 = /usr/lib/libpthread.so.1 libdl.so.1 =/usr/lib/libdl.so.1 libc.so.1 = /usr/lib/libc.so.1 libaio.so.1 = /usr/lib/libaio.so.1 libmp.so.2 =/usr/lib/libmp.so.2 libthread.so.1 =/usr/lib/libthread.so.1 /usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1 Greg How did you build apr ? If it's in DSO, could you make a ldd on it ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jK2 and bugzilla
From: Henri Gomez [EMAIL PROTECTED] Many others errors need investigation, and I need help to see what could be fixed, and what should wait until next release. JK2 commiters, we need you :) The timing of the release is not good for me. My kids are off from school this week. I'll try to make some time available, but I cant make any promises. -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK2 release delayed one week ? WAS: POST recovery in JK and JK2 HEAD
From: Henri Gomez [EMAIL PROTECTED] Did you see my request for release delay ? The POST patch is important, and I'd like to see it in jk2 2.0.4, I think I may delay the release for one week if others tomcat-dev agreed. I wan't to make the behaviour configurable, ie abort or/not if Tomcat failed during sending the reply and if Tomcat get the request but didn't send the reply, configuration should be at worker level since the admins/devels know about the remote side application level. Gleen, Jf, Mladen, Kurt, are you agree to delay the jk2 release for one week, time for us to include these code in both jk and jk2 and make it configurable ? Vote please +0 I'm ok with the delay but I don't have time this week to help. -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] ./jk/native2/Makefile.in - add apxs install target
There isn't an install target in server/apache13/Makefile.apxs yet. I will be committing one soon (along with some other changes). From: Guenter Knauf [EMAIL PROTECTED] Hi, the patch below adds an install target for apxs build to the Makefile. http://www.gknw.com/test/Makefile.in.diff == --- ./jk/native2/Makefile.in.orig Mon Nov 10 12:15:04 2003 +++ ./jk/native2/Makefile.inWed Feb 11 23:54:12 2004 @@ -22,6 +22,15 @@ fi; \ done; +jk2-build-apxs-install: + list='@WEBSERVERS@'; \ + for i in $$list; do \ + echo Making $$target in $$i and installing; \ + if test $$i != .; then \ + (cd $$i $(MAKE) -f Makefile.apxs install) || exit 1; \ + fi; \ + done; + jk2-clean: list='@WEBSERVERS@'; \ for i in $$list; do \ Guenter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
karma please
Could I have karma for jakarta-tomcat-connectors please? I'd like to start working on native jk2 build. Thanks, -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: karma please
From: Kurt Miller [EMAIL PROTECTED] Could I have karma for jakarta-tomcat-connectors please? I'd like to start working on native jk2 build. Sorry. Ignore that. -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.15] Test build available
From: Remy Maucherat [EMAIL PROTECTED] 5.0.15 is available for testing. Please be extra careful about regressions. If there are significant regressions, those will need to be fixed ASAP, and I'll release a new build shortly after that. http://www.apache.org/dist/jakarta/tomcat-5/v5.0.15-alpha/ Rémy Hi Rémy, Would there be any harm in excluding the jk/native* directories from the src distribution? I think it would help avoid people from building the native connectors from this src archive. What happens frequently is that people build the native connectors from tomcat src distribution thinking that they are building the stable released versions. -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Kurt Miller as commiter
From: Henri Gomez [EMAIL PROTECTED] jean-frederic clere a écrit : Henri Gomez wrote: Hi to all, I would like to propose you a new tomcat commiter, Kurt Miller which as proposed many usefull patches for JK2 Since we want to deprecated jk and focus jk2, we need more people involved on jk2. Vote please. Ok, it seems that nobody object to this vote, so we should consider that Kurt is a new tomcat commiter. Welcome on board. I'm quite glad to be hear. :-) Thanks for all the positive votes and comments. Initially, I plan to continue to refine the jk2 native build process. Building a DSO for apache13 is in good shape now so I'll be looking at other areas next. -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why is mod_jk distributed both as 2.0.2 and 2.0.4?
From: Henri Gomez [EMAIL PROTECTED] Kurt Miller a écrit : From: Glenn Nielsen [EMAIL PROTECTED] Perhaps the mod_jk connector should not be released with Tomcat 4/5 since it has its own release cycle and we are already doing separate releases of these. Regards, Glenn Would this work... When a stable version of mod_jk or mod_jk2 is released put the stable jar files in the jakarta/tomcat-connectors/jk(2)/binaries/ directories. Then have Tomcat 4/5 use the released stable jars instead of building them. If this works, then it may also serve as a way for users to upgrade both the native and the java side when a new jk/jk2 release is made. I think that we should decouple jk/jk2 release from tomcat3/4/5 release, in some case jk 1.2.x add a faster release rate that tomcats :) I guess the simplest solution is to exclude the following directories from the jakarta-tomcat-connectors-4.X-src archives to avoid confusion: jk/native jk/native2 webapp/apache-1.3 webapp/apache-2.0 webapp/lib webapp/support webapp/include - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why is mod_jk distributed both as 2.0.2 and 2.0.4?
From: Palle Girgensohn [EMAIL PROTECTED]
Hi!
How come this confusion about the latest version of mod_jk2? With the
jakarta-tomcat-connectors-4.1.2X, a mod_jk2 version 2.0.4 is distributed.
With
http://www.apache.org/dist/jakarta/tomcat-connectors/jk2/source/jakarta-tom
cat-connectors-jk2-src-current.tar.gz, the version is 2.0.2. Which one is
really current? Why this confusion?
As I understand it, the stable versions of the connector source are released
under the following directories:
mod_jk (currently 1.2.5):
jakarta/tomcat-connectors/jk/source/
mod_jk2 (currently 2.0.2):
jakarta/tomcat-connectors/jk2/source/
There are two parts to the connectors; the web server side (c) and the
tomcat side (java). I took a quick look at the current FreeBSD jk jk2
makefiles and they only make the apache portion. Assuming your ports are
tracking stable then they should be using the above source directories.
The FreeBSD jk2 port makefile has some problems. It is pointing to the jk
source dist file and building in the wrong wrksrc dir. Try these instead:
DISTNAME=jakarta-tomcat-connectors-jk2-${PORTVERSION}-src
WRKSRC=${WRKDIR}/jakarta-tomcat-connectors-jk2-${PORTVERSION}-src/jk/native2
For the java side, when tomcat is built it pulls from jtc HEAD. I'm not sure
why this is. Maybe someone else could elaborate on this?
-Kurt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why is mod_jk distributed both as 2.0.2 and 2.0.4?
From: Glenn Nielsen [EMAIL PROTECTED] Perhaps the mod_jk connector should not be released with Tomcat 4/5 since it has its own release cycle and we are already doing separate releases of these. Regards, Glenn Would this work... When a stable version of mod_jk or mod_jk2 is released put the stable jar files in the jakarta/tomcat-connectors/jk(2)/binaries/ directories. Then have Tomcat 4/5 use the released stable jars instead of building them. If this works, then it may also serve as a way for users to upgrade both the native and the java side when a new jk/jk2 release is made. -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache13 mod_jk2.c Makefile.in
jk_exec_ret=${jk_exec_line}^M
else^M
if test -n ${jk_exec_line} ; then^M
echo $3: ${jk_exec_first} ${jk_exec_line}^M
fi^M
fi^M
fi^M
done^M
echo ${jk_exec_ret} retvalue.tmp^M
unset jk_exec_first^M
unset jk_exec_line^M
unset jk_exec_ret^M
}^M
^M
$1=`cat retvalue.tmp`^M
rm -f retvalue.tmp^M
echo execution of \$2\^M
echo returned with value \${$1}\^M
^M
cd ${jk_exec_curdir}^M
unset jk_exec_curdir^M
])^M
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, November 10, 2003 6:05 AM
Subject: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache13
mod_jk2.c Makefile.in
hgomez 2003/11/10 03:05:33
Modified:jk/native2 configure.in Makefile.in
jk/support jk_apr.m4 jk_exec.m4
jk/native2/server/apache13 mod_jk2.c Makefile.in
Log:
Latest jk2/apache 1.3 patch
Obtained from: Kurt Miller
Revision ChangesPath
1.14 +14 -11jakarta-tomcat-connectors/jk/native2/configure.in
Index: configure.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/configure.in,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- configure.in 5 Nov 2003 09:15:19 - 1.13
+++ configure.in 10 Nov 2003 11:05:33 - 1.14
@@ -175,15 +175,10 @@
JK_APR_THREADS()
JK_APR([include/apr.h.in])
+JK_APR_UTIL([include/apu.h.in])
JK_APR_INCDIR([apr.h])
JK_APR_LIBDIR()
-dnl Set these to empty until we know what to do with them
-
-AC_SUBST(APR_UTIL_INCL)
-AC_SUBST(APR_UTIL_LIB)
-
-
dnl Java settings
JK_JNI()
@@ -205,11 +200,16 @@
AC_SUBST(WEBSERVERS)
+dnl if --with-apr is specified, --with-apr-util must be too
+if ${TEST} ! -z $APR_BUILD -a -z $APR_UTIL_DIR; then
+ AC_MSG_ERROR([--with-apr and --with-apr-util must be used together])
+fi
+
dnl apache 1.3 consistancy checks
if ! ${TEST} -z $APACHE_HOME ; then
dnl check if apache 1.3 was selected without apr sources
if ${TEST} -z $APR_BUILD; then
-AC_MSG_ERROR([Apache 1.3 requires apr to built from
source, use --with-apr])
+AC_MSG_ERROR([Apache 1.3 requires apr to built from
source, use --with-apr and --with-apr-util])
fi
dnl make sure compiler matchs apxs
if ${TEST} $APACHE_CC != $CC; then
@@ -222,9 +222,9 @@
fi
dnl apache 2 consistancy checks
-if ! ${TEST} -z $APACHE2_HOME ; then
+if ${TEST} ! -z $APACHE2_HOME ; then
dnl check if apache 2 was selected with apr sources
-if ${TEST} -z $APR_BUILD; then
+if ${TEST} ! -z $APR_BUILD; then
AC_MSG_ERROR([Use apr that comes with Apache 2,
remove --with-apr])
fi
dnl make sure compiler matchs apxs
@@ -245,9 +245,12 @@
AC_SUBST(APR_CFLAGS)
AC_SUBST(APR_CLEAN)
AC_SUBST(APR_DIR)
+AC_SUBST(APR_UTIL_DIR)
AC_SUBST(APR_HOME)
AC_SUBST(APR_INCDIR)
+AC_SUBST(APR_UTIL_INCDIR)
AC_SUBST(APR_LIBDIR)
+AC_SUBST(APR_UTIL_LIBDIR)
AC_SUBST(APR_CONFIGURE_ARGS)
AC_SUBST(APR_LDFLAGS)
AC_SUBST(COMMON_APR_OBJECTS)
1.4 +2 -2 jakarta-tomcat-connectors/jk/native2/Makefile.in
Index: Makefile.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/Makefile.in,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- Makefile.in 4 Nov 2003 12:48:05 - 1.3
+++ Makefile.in 10 Nov 2003 11:05:33 - 1.4
@@ -41,10 +41,10 @@
done;
apr-build:
- ( cd @APR_DIR@ make )
+ ( cd @APR_DIR@ make cd @APR_UTIL_DIR@ make )
apr-clean:
- ( cd @APR_DIR@ make clean )
+ ( cd @APR_DIR@ make clean cd @APR_UTIL_DIR@ make clean )
apidocs: common/*.h
mkdir -p ./docs/api
1.8 +100 -9jakarta-tomcat-connectors/jk/support/jk_apr.m4
Index: jk_apr.m4
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/support/jk_apr.m4,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- jk_apr.m4 5 Nov 2003 09:14:28 - 1.7
+++ jk_apr.m4 10 Nov 2003 11:05:33 - 1.8
@@ -103,6 +103,7 @@
[
case ${withval} in
|yes|YES|true|TRUE)
+AC_MSG_ERROR(valid apr source dir location required)
;;
no|NO|false|FALSE)
AC_MSG_ERROR(valid apr source dir location required)
@@ -120,16 +121,15 @@
if ${TEST} ! -z $tempval ; then
APR_BUILD=apr-build
-APR_CFLAGS=-I ${tempval}/include -DHAS_APR
+APR_CFLAGS=-I ${tempval}/include
jk2/apache13 patch
Attached is a patch to jk2 for the remaining changes that are needed for
using HEAD with apache13. In addition to this patch I needed to delete
common/jk_channel_socket.c and common/jk_pool.c from my tree (perhaps these
should be moved to the attic).
This patch does the following things:
1) adds --with-apr-util to jk_apr.m4 and configure.in and will be a required
configure argument for apache13.
2) fixes some small problems in jk_apr.m4 and jk_exec.m4.
3) removes the remaining ifdefs HAS_APR from server/apache13/mod_jk2.c
and -DHAS_APR from jk_apr.m4 (I couldn't find any remaining code that needs
it now).
4) reverts server/apache13/Makefile.in to create mod_jk.so without creating
mod_jk.la (this may of interest to jean-frederic clere). I wasn't able to
figure out how to get apr-0 and apr-util-0 statically linked in to mod_jk.so
the way it was changed. To be honest libtool is not my strong point, help
with this would be appreciated. I also removed -lcrypt too.
I think that covers it. Please review and comment.
-Kurt
Index: native2/Makefile.in
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/jk/native2/Makefile.in,v
retrieving revision 1.3
diff -u -r1.3 Makefile.in
--- native2/Makefile.in 4 Nov 2003 12:48:05 - 1.3
+++ native2/Makefile.in 7 Nov 2003 23:50:15 -
@@ -41,10 +41,10 @@
done;
apr-build:
- ( cd @APR_DIR@ make )
+ ( cd @APR_DIR@ make cd @APR_UTIL_DIR@ make )
apr-clean:
- ( cd @APR_DIR@ make clean )
+ ( cd @APR_DIR@ make clean cd @APR_UTIL_DIR@ make clean )
apidocs: common/*.h
mkdir -p ./docs/api
Index: native2/configure.in
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/jk/native2/configure.in,v
retrieving revision 1.13
diff -u -r1.13 configure.in
--- native2/configure.in5 Nov 2003 09:15:19 - 1.13
+++ native2/configure.in7 Nov 2003 23:50:15 -
@@ -175,15 +175,10 @@
JK_APR_THREADS()
JK_APR([include/apr.h.in])
+JK_APR_UTIL([include/apu.h.in])
JK_APR_INCDIR([apr.h])
JK_APR_LIBDIR()
-dnl Set these to empty until we know what to do with them
-
-AC_SUBST(APR_UTIL_INCL)
-AC_SUBST(APR_UTIL_LIB)
-
-
dnl Java settings
JK_JNI()
@@ -205,11 +200,16 @@
AC_SUBST(WEBSERVERS)
+dnl if --with-apr is specified, --with-apr-util must be too
+if ${TEST} ! -z $APR_BUILD -a -z $APR_UTIL_DIR; then
+ AC_MSG_ERROR([--with-apr and --with-apr-util must be used together])
+fi
+
dnl apache 1.3 consistancy checks
if ! ${TEST} -z $APACHE_HOME ; then
dnl check if apache 1.3 was selected without apr sources
if ${TEST} -z $APR_BUILD; then
-AC_MSG_ERROR([Apache 1.3 requires apr to built from source, use
--with-apr])
+AC_MSG_ERROR([Apache 1.3 requires apr to built from source, use
--with-apr and --with-apr-util])
fi
dnl make sure compiler matchs apxs
if ${TEST} $APACHE_CC != $CC; then
@@ -222,9 +222,9 @@
fi
dnl apache 2 consistancy checks
-if ! ${TEST} -z $APACHE2_HOME ; then
+if ${TEST} ! -z $APACHE2_HOME ; then
dnl check if apache 2 was selected with apr sources
-if ${TEST} -z $APR_BUILD; then
+if ${TEST} ! -z $APR_BUILD; then
AC_MSG_ERROR([Use apr that comes with Apache 2, remove --with-apr])
fi
dnl make sure compiler matchs apxs
@@ -245,9 +245,12 @@
AC_SUBST(APR_CFLAGS)
AC_SUBST(APR_CLEAN)
AC_SUBST(APR_DIR)
+AC_SUBST(APR_UTIL_DIR)
AC_SUBST(APR_HOME)
AC_SUBST(APR_INCDIR)
+AC_SUBST(APR_UTIL_INCDIR)
AC_SUBST(APR_LIBDIR)
+AC_SUBST(APR_UTIL_LIBDIR)
AC_SUBST(APR_CONFIGURE_ARGS)
AC_SUBST(APR_LDFLAGS)
AC_SUBST(COMMON_APR_OBJECTS)
Index: native2/server/apache13/Makefile.in
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/native2/server/apache13/Makefile.in,v
retrieving revision 1.7
diff -u -r1.7 Makefile.in
--- native2/server/apache13/Makefile.in 28 Nov 2002 15:54:51 - 1.7
+++ native2/server/apache13/Makefile.in 7 Nov 2003 23:50:15 -
@@ -23,7 +23,7 @@
${APACHE_INCL}
JK_CFLAGS=-DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 @APR_CFLAGS@ -DHAVE_MMAP ${JAVA_INCL}
-JK_LDFLAGS=-L${APACHE_HOME}/lib -lcrypt @APR_LDFLAGS@ ${JAVA_LIB}
+JK_LDFLAGS=-L${APACHE_HOME}/lib ${JAVA_LIB}
## Based on rules.mk ##
ALL_CFLAGS = $(EXTRA_CFLAGS) $(NOTEST_CFLAGS) $(CFLAGS)
@@ -36,7 +36,7 @@
COMPILE = $(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(ALL_INCLUDES)
SH_COMPILE = $(LIBTOOL) --mode=compile $(COMPILE) $(JK_CFLAGS)
-MOD_LINK = $(LIBTOOL) --mode=link $(CC) -avoid-version -module -rpath
$(APACHE_LIBEXEC) $(LT_LDFLAGS) $(ALL_LDFLAGS) $(JK_LDFLAGS)
+MOD_LINK = $(LIBTOOL) --mode=link $(CC) -avoid-version -module -shared -rpath
$(APACHE_LIBEXEC) $(LT_LDFLAGS) $(ALL_LDFLAGS) $(JK_LDFLAGS)
MOD_INSTALL = $(LIBTOOL) --mode=install $(CP)
Re: jk2/apr patch v2
From: jean-frederic clere [EMAIL PROTECTED]
Kurt Miller wrote:
Thanks to jean-frederic clere for input on this. Ok, here goes again...
;-)
Attached is a patch that makes the following changes for building jk2
via
configure and make:
1) Introduces a new configure argument called --enable-apr-threads=val
for
use with --with-apr. This argument allows for threading to be configured
for
apr because apr doesn't always guess threading the same way apache is
configured.
2) Changes --with-apr to configure apr while configuring jk2. This
allows
for the correct naming of the apr library name instead of hard coding it
and
compiler consistency with apache13 (I copied stuff from the webapp
connector
for this)
3) Added compiler consistency checks for apache13 and apache2. The same
compiler must be used for jk2 as was used for apache. For apache13 a
side
effect is that apr is also configured to use the same compiler (picked
up
via the environment).
4) Added checks to force the use of --with-apr for apache13 and disallow
use
of --with-apr for apache2.
Please review and consider for committing if there are no issues or
objections.
+++
+APR_LDFLAGS=${APR_DIR}/.libs/${APR_LDFLAGS}
+++
That is still weird...
Yea. I was hoping that apr-config would let me know where the .a file was,
but it only tells you where the .la file is and there not in the same place.
--apr-la-file gives the path to the apr library when installed. (better
than
--link-libtool).
I think we should install the library something like:
+++
$(LIBTOOL) --mode=install \
cp $(APR_DIR)/$(APR_LIBNAME) $(LIB_DIR)/$(APR_LIBNAME)
$(LIBTOOL) --mode=finish $(LIB_DIR)
+++
Humm. I kinda like not having apr installed since we're staticly linking it
in. For apache13 we're forcing them to build from source but I'm not sure
that an install of apr should be forced too. I guess it conceivable that apr
could already be installed and used by other applications (subversion
maybe?), but be configured differently then is needed for jk2/apache13.
Anyway the proposed patch is already much better than the actual code.
Thanks. :)
On another thread I noted that jk_md5 is now depending on apr-util. Since
I'm familiar with the m4 macros now would it be worthwhile for me to make a
patch to add configure support for apr-util following the same pattern as
apr? I'd be focusing on the apache13 case only (--with-apr-util) since that
is what I can test easily now.
-Kurt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2/apr patch
From: Henri Gomez [EMAIL PROTECTED] Ok, Who is handling today the many configure/m4 suggestions ? BTW, I'm using Redhat 9.0 and the apr-config is available so it should be a common situation even when it's a distro and not by hand build Hi Henri, I'm about completed with the patch for the Apache13 case (--with-apr) that I described earlier in this thread. I'll post it for review later-today. Thanks for the commits ;-) -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2/apr patch
From: jean-frederic clere [EMAIL PROTECTED] Kurt Miller wrote: Before I start making a patch, I'd like to make sure I've got the new behavior nailed down... It seems like there is some conflicting stuff going on. Apr may need to be configured without threads at times (without for Apache13 on OpenBSD and Apache2 on FreeBSD 4.7 (pre fork MPM)). When using --with-apr currently it doesn't specify with or without threads while configuring apr. So it just guesses and will likely be with threads at times it shouldn't be. I'd like to add a new configure argument called --with-apr-threads that will indicated if apr should be with or without threads. This argument will ignored, unless -with-apr is also specified and will used to configure apr. Not sure what the default should be. It is possible to configure apr with --enable-threads=pthread or --enable-threads=system_threads. Ok, I'll make it called --enable-apr-threads=val. If not specified, it will just let apr configure take its guess. Currently --with-apr-include and --with-apr-lib override --with-apr. So I'm thinking after all three arguments have been processed do the following if APR_BUILD is not empty: 1) For Apache13 and Apache2 get the compiler used by apxs. 2) configure apr with --enable-static --disable-shared (override compiler for Apache13 and Apache2) --with-threads or --without-threads based on the --with-apr-threads argument. 3) Use apr-config to get lib name. In --with-apr-lib processing set the lib name using your find + awk technique. Does the above sound acceptable so far? For Apache13 yes. For Apache2 no, Apache2 contains a compiled apr we must use this one. (And may be give an error when using --with-apr-include/-with-apr-lib/--with-apr and --with-apxs2). Ok, just for Apache13. For Apache2 give an error when --with-apr is specified, but how should lib name be found if --with-apr-lib is not also given with --with-apxs2? (Currently the lib name is hardcoded in servers/Apache2/Makefile.in) I don't have Apache2 setup yet, so I can't check it out myself. Maybe I should leave Apache2 changes till later or someone else. Hummm, if neither --with-apr or --with-apr-lib is specified what do we do for the lib name (it may be there already for Apache2)? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_md5.c
While testing the apr m4 patches I'm working on, I noticed that this commit
has introduced a dependency on apr-util (via apr_md5.h). I guess that means
./configure will need --with-apr-util etc. etc. to support apache13. Yes?
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, November 01, 2003 9:46 AM
Subject: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_md5.c
mturk 2003/11/01 06:46:13
Modified:jk/native2/common jk_md5.c
Log:
Use the apr-uti md5.
Removed some licence that I thought are irrelevant now.
Please check...
Revision ChangesPath
1.6 +15 -414
jakarta-tomcat-connectors/jk/native2/common/jk_md5.c
Index: jk_md5.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_md5.c,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- jk_md5.c 25 Sep 2003 15:23:22 - 1.5
+++ jk_md5.c 1 Nov 2003 14:46:13 - 1.6
@@ -1,36 +1,3 @@
-/*
- * This is work is derived from material Copyright RSA Data Security,
Inc.
- *
- * The RSA copyright statement and Licence for that original material
is
- * included below. This is followed by the Apache copyright statement
and
- * licence for the modifications made to that material.
- */
-
-/* MD5C.C - RSA Data Security, Inc., MD5 message-digest algorithm
- */
-
-/* Copyright (C) 1991-2, RSA Data Security, Inc. Created 1991. All
- rights reserved.
-
- License to copy and use this software is granted provided that it
- is identified as the RSA Data Security, Inc. MD5 Message-Digest
- Algorithm in all material mentioning or referencing this software
- or this function.
-
- License is also granted to make and use derivative works provided
- that such works are identified as derived from the RSA Data
- Security, Inc. MD5 Message-Digest Algorithm in all material
- mentioning or referencing the derived work.
-
- RSA Data Security, Inc. makes no representations concerning either
- the merchantability of this software or the suitability of this
- software for any particular purpose. It is provided as is
- without express or implied warranty of any kind.
-
- These notices must be retained in any copies of any part of this
- documentation and/or software.
- */
-
/*
* The Apache Software License, Version 1.1
*
@@ -89,17 +56,6 @@
* University of Illinois, Urbana-Champaign.
*/
-/*
- * The ap_MD5Encode() routine uses much code obtained from the FreeBSD
3.0
- * MD5 crypt() function, which is licenced as follows:
-
* --
--
- * THE BEER-WARE LICENSE (Revision 42):
- * [EMAIL PROTECTED] wrote this file. As long as you retain this
notice you
- * can do whatever you want with this stuff. If we meet some day, and
you think
- * this stuff is worth it, you can buy me a beer in return.
Poul-Henning Kamp
-
* --
--
- */
-
/***
* Description: MD5 encoding wrapper
*
* Author: Henri Gomez [EMAIL PROTECTED]
*
@@ -109,11 +65,8 @@
/*
* JK MD5 Encoding function (jk_MD5Encode)
*
- * Jk delegate MD5 encoding to ap_MD5Encode when used in Apache
Web-Server.
- * When another web-server is used like NES/IIS, we should use
corresponding calls.
- * NES/IIS specialists will add the necessary code but until that, I
reused the code
- * from Apache HTTP server.
- *
+ * Use the APR_UTIL apr_md5
+ *
* Nota: If you use an EBCDIC system without Apache, you'll have to use
MD5 encoding
* corresponding call or have a ebcdic2ascii() functions somewhere.
* For example current AS/400 have MD5 encoding support APIs but olders
not
@@ -122,6 +75,7 @@
#include jk_global.h
#include jk_env.h
#include jk_md5.h
+#include apr_md5.h
char * JK_METHOD jk2_hextocstr(unsigned char *org, char * dst, int n)
{
@@ -139,375 +93,22 @@
return (os);
}
-#ifndef USE_APACHE_MD5
-
-/* Constants for jk2_MD5Transform routine.
- */
-
-#define S11 7
-#define S12 12
-#define S13 17
-#define S14 22
-#define S21 5
-#define S22 9
-#define S23 14
-#define S24 20
-#define S31 4
-#define S32 11
-#define S33 16
-#define S34 23
-#define S41 6
-#define S42 10
-#define S43 15
-#define S44 21
-
-static void jk2_MD5Transform(JK_UINT4 state[4], const unsigned char
block[64]);
-static void jk2_Encode(unsigned char *output, const JK_UINT4 *input,
unsigned int len);
-static void
jk2/apr patch v2
Thanks to jean-frederic clere for input on this. Ok, here goes again... ;-)
Attached is a patch that makes the following changes for building jk2 via
configure and make:
1) Introduces a new configure argument called --enable-apr-threads=val for
use with --with-apr. This argument allows for threading to be configured for
apr because apr doesn't always guess threading the same way apache is
configured.
2) Changes --with-apr to configure apr while configuring jk2. This allows
for the correct naming of the apr library name instead of hard coding it and
compiler consistency with apache13 (I copied stuff from the webapp connector
for this)
3) Added compiler consistency checks for apache13 and apache2. The same
compiler must be used for jk2 as was used for apache. For apache13 a side
effect is that apr is also configured to use the same compiler (picked up
via the environment).
4) Added checks to force the use of --with-apr for apache13 and disallow use
of --with-apr for apache2.
Please review and consider for committing if there are no issues or
objections.
-Kurt
Index: native2/Makefile.in
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/jk/native2/Makefile.in,v
retrieving revision 1.2
diff -u -r1.2 Makefile.in
--- native2/Makefile.in 24 May 2002 07:14:08 - 1.2
+++ native2/Makefile.in 3 Nov 2003 19:15:44 -
@@ -41,7 +41,7 @@
done;
apr-build:
- ( cd @APR_DIR@ ./configure make )
+ ( cd @APR_DIR@ make )
apr-clean:
( cd @APR_DIR@ make clean )
Index: native2/configure.in
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/jk/native2/configure.in,v
retrieving revision 1.11
diff -u -r1.11 configure.in
--- native2/configure.in3 Nov 2003 09:49:58 - 1.11
+++ native2/configure.in3 Nov 2003 19:15:44 -
@@ -64,6 +64,7 @@
dnl sinclude(../support/jk_apache_static.m4)
sinclude(../support/jk_apxs.m4)
sinclude(../support/jk_ws.m4)
+sinclude(../support/jk_exec.m4)
sinclude(../support/jk_apr.m4)
sinclude(../support/jk_tchome.m4)
sinclude(../support/jk_java.m4)
@@ -172,6 +173,7 @@
dnl APR settings
+JK_APR_THREADS()
JK_APR([include/apr.h.in])
JK_APR_INCDIR([apr.h])
JK_APR_LIBDIR()
@@ -203,16 +205,37 @@
AC_SUBST(WEBSERVERS)
-dnl check if apache 1.3 selected with jni support
+dnl apache 1.3 consistancy checks
if ! ${TEST} -z $APACHE_HOME ; then
-dnl check jni wanted
- if ${TEST} ${use_jni} = true; then
- if ! ${TEST} ${use_apr} = true; then
- AC_MSG_ERROR(Apache 1.3 need apr to use jni)
- fi
- fi
+dnl check if apache 1.3 was selected without apr sources
+if ${TEST} -z $APR_BUILD; then
+AC_MSG_ERROR([Apache 1.3 requires apr to built from source, use
--with-apr])
+fi
+dnl make sure compiler matchs apxs
+if ${TEST} $APACHE_CC != $CC; then
+AC_MSG_RESULT([error])
+AC_MSG_RESULT([compiler discovered by configure: ${CC}])
+AC_MSG_RESULT([compiler used by apache: ${APACHE_CC}])
+AC_MSG_RESULT([delete config.cache and try CC=${APACHE_CC}
./configure])
+AC_MSG_ERROR([jk2 and apache compilers must be the same])
+fi
fi
+dnl apache 2 consistancy checks
+if ! ${TEST} -z $APACHE2_HOME ; then
+dnl check if apache 2 was selected with apr sources
+if ${TEST} -z $APR_BUILD; then
+AC_MSG_ERROR([Use apr that comes with Apache 2, remove --with-apr])
+fi
+dnl make sure compiler matchs apxs
+if ${TEST} $APACHE2_CC != $CC; then
+AC_MSG_RESULT([error])
+AC_MSG_RESULT([compiler discovered by configure: ${CC}])
+AC_MSG_RESULT([compiler used by apache: ${APACHE2_CC}])
+AC_MSG_RESULT([delete config.cache and try CC=${APACHE2_CC}
./configure])
+AC_MSG_ERROR([jk2 and apache compilers must be the same])
+fi
+fi
AC_SUBST(APACHE20_OEXT)
AC_SUBST(LIB_JK_TYPE)
AC_SUBST(INSTALL_TYPE)
@@ -225,6 +248,7 @@
AC_SUBST(APR_HOME)
AC_SUBST(APR_INCDIR)
AC_SUBST(APR_LIBDIR)
+AC_SUBST(APR_CONFIGURE_ARGS)
AC_SUBST(APR_LDFLAGS)
AC_SUBST(COMMON_APR_OBJECTS)
Index: support/jk_apr.m4
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/jk/support/jk_apr.m4,v
retrieving revision 1.5
diff -u -r1.5 jk_apr.m4
--- support/jk_apr.m4 3 Nov 2003 09:59:45 - 1.5
+++ support/jk_apr.m4 3 Nov 2003 19:15:44 -
@@ -64,6 +64,31 @@
dnl --
dnl --
+dnl JK_APR_THREADS
+dnl Configure APR threading for use with --with-apr.
+dnl Result goes into APR_CONFIGURE_ARGS
+dnl
Re: jk2/apr patch
From: jean-frederic clere [EMAIL PROTECTED]
Clere, Jean-Frederic wrote:
Kurt Miller wrote:
Checking out the apache2 makefile it looks like apr-0 is right. Here's
a revised
patch (I missed a spot).
Index: jk/support/jk_apr.m4
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/support/jk_apr.m4,v
retrieving revision 1.3
diff -u -r1.3 jk_apr.m4
--- jk/support/jk_apr.m4 25 Sep 2003 15:23:56 - 1.3
+++ jk/support/jk_apr.m4 30 Oct 2003 22:11:05 -
@@ -99,7 +99,7 @@
APR_CLEAN=apr-clean
APR_DIR=${tempval}
APR_INCDIR=${tempval}/include
-APR_LDFLAGS=${tempval}/.libs/libapr.a
+APR_LDFLAGS=${tempval}/.libs/libapr-0.a
APR_LIBDIR=
use_apr=true
COMMON_APR_OBJECTS=\${COMMON_APR_OBJECTS}
@@ -189,7 +189,7 @@
APR_CLEAN=
APR_DIR=
APR_LIBDIR=${tempval}
- APR_LDFLAGS=-lapr -L${tempval}
+ APR_LDFLAGS=-lapr-0 -L${tempval}
COMMON_APR_OBJECTS=\${COMMON_APR_OBJECTS}
use_apr=true
fi
- Original Message - From: Kurt Miller [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Thursday, October 30, 2003 4:32 PM
Subject: jk2/apr patch
Getting ready for jk2 requiring apr (even for Apache13)... Building
jk2
using:
./configure --with-apxs=/usr/sbin/apxs --with-apr=apr src loc
make
linking fails because the apr library is not named libapr.a it is
named
libapr-0.a. I'm not sure if this naming problem is universal for all
platforms, but libapr-0.a appears to be the correct name for OpenBSD,
FreeBSD and NetBSD. If it is universal then here's a quick patch to
change
it:
Index: jk/support/jk_apr.m4
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/support/jk_apr.m4,v
retrieving revision 1.3
diff -u -r1.3 jk_apr.m4
--- jk/support/jk_apr.m4 25 Sep 2003 15:23:56 - 1.3
+++ jk/support/jk_apr.m4 30 Oct 2003 21:03:16 -
@@ -99,7 +99,7 @@
APR_CLEAN=apr-clean
APR_DIR=${tempval}
APR_INCDIR=${tempval}/include
-APR_LDFLAGS=${tempval}/.libs/libapr.a
+APR_LDFLAGS=${tempval}/.libs/libapr-0.a
APR_LIBDIR=
use_apr=true
COMMON_APR_OBJECTS=\${COMMON_APR_OBJECTS}
If this name needs to be libapr.a for other platforms, then I guess I
could
patch the apr-build target in Makefile.in to rename it. Any thoughts?
-1. We have to use apr-config to get the name of the apr library.
Look in the web-app deprecated code (in wa_apr.m4).
For example I have with APR for CVS:
+++
[EMAIL PROTECTED]:~/apr apr-config --link-ld --libs
-L/home/jfclere/apr -lapr-1 -lrt -lm -lcrypt -lnsl -lpthread -ldl
[EMAIL PROTECTED]:~/apr find . -name *.so -print
./.libs/libapr-1.so
+++
Ok thanks for the heads up, I've look briefly at wa_apr.m4 now. I've got a
question or two I think there are two cases:
1) when --with-apr is specified
2) when --with-apr-include and --with-apr-lib are specified
In case one the apr src directory is given and jk2 builds apr using the
apr-build target in the native2 makefile. The apr-build target does a
./configure make for apr when building jk2. When configuring jk2,
apr-config is not guaranteed to be available.
The webapp connector required apr to be built from source for Apache13 and
configured apr while configuring itself. Should jk2 also make this
requirement? It appears the webapp connector did it to ensure the same
complier was used and that apr was configured without threads for Apache13.
In the second case the apr src dir is not specified, so apr-config is not
available again. The webap connector used it to get the lib name. I'm not
sure what the best method for determining the lib name in this case.
Currently the the lib name is hardcoded to libapr.a for apache13 and
libapr-0 for apache2. Any suggestions?
-Kurt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK2 is using APR as mandatory
- Original Message - From: Mladen Turk [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, October 30, 2003 3:35 PM Subject: JK2 is using APR as mandatory As said in the subject... plus the jk_pool and jk_channel socket are marked as deprecated. Are configurations using channel.socket depreciated now? Does this just mean that the code in jk_channel_socket.c is depreceated becuase jk_channel_apr_socket.c will always be used now? Couple of things to do. 1. APR-ize jk_file_logger to use apr_file API instead stdio's FILE. 2. All methods will return apr_status_t instead int (work in progress). 3. Henri, what about those AS400 defines, can they be removed now? 4. IIS is now presumed to have apr, apr-util, apr-iconv, and pcre in the srclib folder. Tested with apr-0.9.4. Need to document that. 5. ??? Comments? MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK2 is using APR as mandatory
From: Mladen Turk [EMAIL PROTECTED] From: Kurt Miller As said in the subject... plus the jk_pool and jk_channel socket are marked as deprecated. Are configurations using channel.socket depreciated now? Does this just mean that the code in jk_channel_socket.c is depreceated becuase jk_channel_apr_socket.c will always be used now? No, the channel.socket is actually channel.apr, and the channel.apr has been removed from registry (channel.apr was very intuitive name for a tcp channel). Got it. Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2/apr patch
From: jean-frederic clere [EMAIL PROTECTED]
Kurt Miller wrote:
Ok thanks for the heads up, I've look briefly at wa_apr.m4 now. I've got
a
question or two I think there are two cases:
1) when --with-apr is specified
2) when --with-apr-include and --with-apr-lib are specified
In case one the apr src directory is given and jk2 builds apr using the
apr-build target in the native2 makefile. The apr-build target does a
./configure make for apr when building jk2. When configuring jk2,
apr-config is not guaranteed to be available.
Right apr-config is not available before configuring apr.
The webapp connector required apr to be built from source for Apache13
and
configured apr while configuring itself. Should jk2 also make this
requirement?
Yes.
It appears the webapp connector did it to ensure the same
complier was used and that apr was configured without threads for
Apache13.
In the second case the apr src dir is not specified, so apr-config is
not
available again. The webap connector used it to get the lib name. I'm
not
sure what the best method for determining the lib name in this case.
Currently the the lib name is hardcoded to libapr.a for apache13 and
libapr-0 for apache2. Any suggestions?
find + awk?
+++
NUMVERAPR=`find ${tempval} -name *.la | awk -F - '{ print $2 }' | awk -F
. '{
print $1 }'
APR_LDFLAGS=-lapr-${NUMVERAPR} -L${tempval}
+++
Before I start making a patch, I'd like to make sure I've got the new
behavior nailed down...
It seems like there is some conflicting stuff going on. Apr may need to be
configured without threads at times (without for Apache13 on OpenBSD and
Apache2 on FreeBSD 4.7 (pre fork MPM)). When using --with-apr currently it
doesn't specify with or without threads while configuring apr. So it just
guesses and will likely be with threads at times it shouldn't be.
I'd like to add a new configure argument called --with-apr-threads that will
indicated if apr should be with or without threads. This argument will
ignored, unless -with-apr is also specified and will used to configure apr.
Not sure what the default should be.
Currently --with-apr-include and --with-apr-lib override --with-apr. So I'm
thinking after all three arguments have been processed do the following if
APR_BUILD is not empty:
1) For Apache13 and Apache2 get the compiler used by apxs.
2) configure apr with --enable-static --disable-shared (override
compiler for Apache13 and Apache2) --with-threads or
--without-threads based on the --with-apr-threads argument.
3) Use apr-config to get lib name.
In --with-apr-lib processing set the lib name using your find + awk
technique.
Does the above sound acceptable so far?
Hummm, if neither --with-apr or --with-apr-lib is specified what do we do
for the lib name (it may be there already for Apache2)?
-Kurt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
jk2/jni/jdk patch
I noticed when building jk2 using ./configure make that the configure script checks for and requires a jdk even when --with-jni is not specified. I've attached a patch that removes the need for a jdk when --with-jni is not specified. Actually, the patch ignores the --with-java-home, --with-java-platform, and --with-os-type arguments unless --with-jni is specified. The patch is quite simple but due to indentation changes it got a little long. It changes the check for jni to be before the jdk checks. Then each jdk check is either performed or not performed based on if jni was specified. Please consider committing this if there are no objections or issues. -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2/jni/jdk patch
Looks like the patch was stripped. Here it is again...
- Original Message -
From: Kurt Miller [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Thursday, October 30, 2003 3:48 PM
Subject: jk2/jni/jdk patch
I noticed when building jk2 using ./configure make that the configure
script checks for and requires a jdk even when --with-jni is not
specified.
I've attached a patch that removes the need for a jdk when --with-jni is
not
specified. Actually, the patch ignores
the --with-java-home, --with-java-platform, and --with-os-type arguments
unless --with-jni is specified.
The patch is quite simple but due to indentation changes it got a little
long. It changes the check for jni to be before the jdk checks. Then each
jdk check is either performed or not performed based on if jni was
specified.
Please consider committing this if there are no objections or issues.
-Kurt
Index: jk/native2/configure.in
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/jk/native2/configure.in,v
retrieving revision 1.10
diff -u -r1.10 configure.in
--- jk/native2/configure.in 25 Sep 2003 15:23:23 - 1.10
+++ jk/native2/configure.in 30 Oct 2003 20:30:26 -
@@ -184,9 +184,9 @@
dnl Java settings
+JK_JNI()
JK_JDK()
JK_JDK_OS()
-JK_JNI()
JK_PCRE()
AC_SUBST(JAVA_HOME)
Index: jk/support/jk_java.m4
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/jk/support/jk_java.m4,v
retrieving revision 1.3
diff -u -r1.3 jk_java.m4
--- jk/support/jk_java.m4 25 Sep 2003 15:23:56 - 1.3
+++ jk/support/jk_java.m4 30 Oct 2003 20:30:26 -
@@ -71,73 +71,98 @@
dnl
dnl --
AC_DEFUN(
+ [JK_JNI],
+ [
+AC_ARG_WITH(jni,
+ [ --with-jni Build jni support],
+ [
+ case ${withval} in
+ y | yes | true) use_jni=true ;;
+ n | no | false) use_jni=false ;;
+ *) use_jni=true ;;
+ esac
+
+ if ${TEST} ${use_jni} ; then
+ HAVE_JNI=-DHAVE_JNI
+ fi
+ ])
+ ])
+
+AC_DEFUN(
[JK_JDK],
[
-tempval=
-AC_MSG_CHECKING([for JDK location (please wait)])
-if ${TEST} -n ${JAVA_HOME} ; then
- JAVA_HOME_ENV=${JAVA_HOME}
-else
- JAVA_HOME_ENV=
-fi
+if ${TEST} ${use_jni} = true; then
+ tempval=
+ AC_MSG_CHECKING([for JDK location (please wait)])
+ if ${TEST} -n ${JAVA_HOME} ; then
+JAVA_HOME_ENV=${JAVA_HOME}
+ else
+JAVA_HOME_ENV=
+ fi
-JAVA_HOME=
-JAVA_PLATFORM=
+ JAVA_HOME=
+ JAVA_PLATFORM=
-AC_ARG_WITH(
- [java-home],
- [ --with-java-home=DIR Location of JDK directory.],
- [
+ AC_ARG_WITH(
+[java-home],
+[ --with-java-home=DIR Location of JDK directory.],
+[
- # This stuff works if the command line parameter --with-java-home was
- # specified, so it takes priority rightfully.
+# This stuff works if the command line parameter --with-java-home was
+# specified, so it takes priority rightfully.
- tempval=${withval}
+tempval=${withval}
- if ${TEST} ! -d ${tempval} ; then
- AC_MSG_ERROR(Not a directory: ${tempval})
- fi
+if ${TEST} ! -d ${tempval} ; then
+AC_MSG_ERROR(Not a directory: ${tempval})
+fi
- JAVA_HOME=${tempval}
- AC_MSG_RESULT(${JAVA_HOME})
-],
-[
- # This works if the parameter was NOT specified, so it's a good time
- # to see what the enviroment says.
- # Since Sun uses JAVA_HOME a lot, we check it first and ignore the
- # JAVA_HOME, otherwise just use whatever JAVA_HOME was specified.
-
- if ${TEST} -n ${JAVA_HOME_ENV} ; then
-JAVA_HOME=${JAVA_HOME_ENV}
-AC_MSG_RESULT(${JAVA_HOME_ENV} from environment)
- fi
-])
+JAVA_HOME=${tempval}
+AC_MSG_RESULT(${JAVA_HOME})
+ ],
+ [
+# This works if the parameter was NOT specified, so it's a good time
+# to see what the enviroment says.
+# Since Sun uses JAVA_HOME a lot, we check it first and ignore the
+# JAVA_HOME, otherwise just use whatever JAVA_HOME was specified.
+
+if ${TEST} -n ${JAVA_HOME_ENV} ; then
+ JAVA_HOME=${JAVA_HOME_ENV}
+ AC_MSG_RESULT(${JAVA_HOME_ENV} from environment)
+fi
+ ])
+
+ if ${TEST} -z ${JAVA_HOME} ; then
-if ${TEST} -z ${JAVA_HOME} ; then
+# Oh well, nobody set neither JAVA_HOME nor JAVA_HOME, have to guess
+# The following code is based on the code submitted by Henner Zeller
+# for ${srcdir}/src/scripts/package/rpm/ApacheJServ.spec
+# Two variables will be set as a result:
+#
+# JAVA_HOME
jk2/apr patch
Getting ready for jk2 requiring apr (even for Apache13)... Building jk2
using:
./configure --with-apxs=/usr/sbin/apxs --with-apr=apr src loc make
linking fails because the apr library is not named libapr.a it is named
libapr-0.a. I'm not sure if this naming problem is universal for all
platforms, but libapr-0.a appears to be the correct name for OpenBSD,
FreeBSD and NetBSD. If it is universal then here's a quick patch to change
it:
Index: jk/support/jk_apr.m4
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/jk/support/jk_apr.m4,v
retrieving revision 1.3
diff -u -r1.3 jk_apr.m4
--- jk/support/jk_apr.m4 25 Sep 2003 15:23:56 - 1.3
+++ jk/support/jk_apr.m4 30 Oct 2003 21:03:16 -
@@ -99,7 +99,7 @@
APR_CLEAN=apr-clean
APR_DIR=${tempval}
APR_INCDIR=${tempval}/include
-APR_LDFLAGS=${tempval}/.libs/libapr.a
+APR_LDFLAGS=${tempval}/.libs/libapr-0.a
APR_LIBDIR=
use_apr=true
COMMON_APR_OBJECTS=\${COMMON_APR_OBJECTS}
If this name needs to be libapr.a for other platforms, then I guess I could
patch the apr-build target in Makefile.in to rename it. Any thoughts?
-Kurt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2/apr patch
Checking out the apache2 makefile it looks like apr-0 is right. Here's a revised
patch (I missed a spot).
Index: jk/support/jk_apr.m4
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/jk/support/jk_apr.m4,v
retrieving revision 1.3
diff -u -r1.3 jk_apr.m4
--- jk/support/jk_apr.m4 25 Sep 2003 15:23:56 - 1.3
+++ jk/support/jk_apr.m4 30 Oct 2003 22:11:05 -
@@ -99,7 +99,7 @@
APR_CLEAN=apr-clean
APR_DIR=${tempval}
APR_INCDIR=${tempval}/include
-APR_LDFLAGS=${tempval}/.libs/libapr.a
+APR_LDFLAGS=${tempval}/.libs/libapr-0.a
APR_LIBDIR=
use_apr=true
COMMON_APR_OBJECTS=\${COMMON_APR_OBJECTS}
@@ -189,7 +189,7 @@
APR_CLEAN=
APR_DIR=
APR_LIBDIR=${tempval}
- APR_LDFLAGS=-lapr -L${tempval}
+ APR_LDFLAGS=-lapr-0 -L${tempval}
COMMON_APR_OBJECTS=\${COMMON_APR_OBJECTS}
use_apr=true
fi
- Original Message -
From: Kurt Miller [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Thursday, October 30, 2003 4:32 PM
Subject: jk2/apr patch
Getting ready for jk2 requiring apr (even for Apache13)... Building jk2
using:
./configure --with-apxs=/usr/sbin/apxs --with-apr=apr src loc make
linking fails because the apr library is not named libapr.a it is named
libapr-0.a. I'm not sure if this naming problem is universal for all
platforms, but libapr-0.a appears to be the correct name for OpenBSD,
FreeBSD and NetBSD. If it is universal then here's a quick patch to change
it:
Index: jk/support/jk_apr.m4
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/jk/support/jk_apr.m4,v
retrieving revision 1.3
diff -u -r1.3 jk_apr.m4
--- jk/support/jk_apr.m4 25 Sep 2003 15:23:56 - 1.3
+++ jk/support/jk_apr.m4 30 Oct 2003 21:03:16 -
@@ -99,7 +99,7 @@
APR_CLEAN=apr-clean
APR_DIR=${tempval}
APR_INCDIR=${tempval}/include
-APR_LDFLAGS=${tempval}/.libs/libapr.a
+APR_LDFLAGS=${tempval}/.libs/libapr-0.a
APR_LIBDIR=
use_apr=true
COMMON_APR_OBJECTS=\${COMMON_APR_OBJECTS}
If this name needs to be libapr.a for other platforms, then I guess I
could
patch the apr-build target in Makefile.in to rename it. Any thoughts?
-Kurt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
jk2/libcrypt patch
Last one for today...
Building on mod_jk2 OpenBSD libcrypt is not available or needed.
Does -lcrypt have to be specified in the Makefile.in files for other platforms?
Will libtool add it on the appropriate platforms? If it will here's a patch
to remove it:
Index: jk/native2/server/apache13/Makefile.in
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/native2/server/apache13/Makefile.in,v
retrieving revision 1.7
diff -u -r1.7 Makefile.in
--- jk/native2/server/apache13/Makefile.in 28 Nov 2002 15:54:51 - 1.7
+++ jk/native2/server/apache13/Makefile.in 30 Oct 2003 22:25:58 -
@@ -23,7 +23,7 @@
${APACHE_INCL}
JK_CFLAGS=-DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 @APR_CFLAGS@ -DHAVE_MMAP ${JAVA_INCL}
-JK_LDFLAGS=-L${APACHE_HOME}/lib -lcrypt @APR_LDFLAGS@ ${JAVA_LIB}
+JK_LDFLAGS=-L${APACHE_HOME}/lib @APR_LDFLAGS@ ${JAVA_LIB}
## Based on rules.mk ##
ALL_CFLAGS = $(EXTRA_CFLAGS) $(NOTEST_CFLAGS) $(CFLAGS)
Index: jk/native2/server/apache2/Makefile.in
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/native2/server/apache2/Makefile.in,v
retrieving revision 1.12
diff -u -r1.12 Makefile.in
--- jk/native2/server/apache2/Makefile.in 9 Apr 2003 18:05:03 - 1.12
+++ jk/native2/server/apache2/Makefile.in 30 Oct 2003 22:25:58 -
@@ -34,7 +34,7 @@
${JAVA_INCL}
JK_CFLAGS=-DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 -DHAS_APR @HAVE_JNI@ @HAS_PCRE@
-JK_LDFLAGS=-L${APACHE2_LIBDIR} -lcrypt -lapr-0 @PCRE_LIBS@
+JK_LDFLAGS=-L${APACHE2_LIBDIR} -lapr-0 @PCRE_LIBS@
## Based on rules.mk ##
ALL_CFLAGS = $(EXTRA_CFLAGS) $(NOTEST_CFLAGS) $(CFLAGS)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Re: /www/www.apache.org/dyn/mirrors/mirrors.cgi]
From: jean-frederic clere [EMAIL PROTECTED] Kurt Miller wrote: I guess a user would be willing to manually check the keys of one binary download, but would not be likely to check the keys of multiple downloads. Maybe a solution similar to what the BSD porting systems use would be a possible solution to the trust issue. They automatically download AND check the keys of the files. Right but how could I check the keys in ant? Good question. I know it is good practice to post a patch with a suggestion like mine... but I've got two other mini projects half completed that I want to finish. ;-) Maybe before the end of the year, I could look into this (if someone else doesn't do it first). -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Re: /www/www.apache.org/dyn/mirrors/mirrors.cgi]
From: jean-frederic clere [EMAIL PROTECTED] Tetsuya Kitahata wrote: On Tue, 07 Oct 2003 13:49:39 +0200 Remy Maucherat [EMAIL PROTECTED] wrote: There is no guarantee that the binaries d/led are not corrupted on your random mirror, or haven't been tampered with, or if the mirror is available at all. This is for the build process, so mirrors are not a good solution. If so, archive.apache.org would be better? (Seems that it would be against the policy of infrastructure team, though) Yes. The download task is used to build the Tomcat, so we must be sure that the files we use to build it are reliable. Using archive.apache.org would allow us to build old versions of Tomcat: this is interesting for bug fixing. Doesn't this mean that anyone who tries to build Tomcat from source using the download task will not use the mirrors? If apache doesn't trust downloading from mirrors how would you expect users to trust them? I guess a user would be willing to manually check the keys of one binary download, but would not be likely to check the keys of multiple downloads. Maybe a solution similar to what the BSD porting systems use would be a possible solution to the trust issue. They automatically download AND check the keys of the files. -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problems with ant download
From: jean-frederic clere [EMAIL PROTECTED] ... but the interesting would be to have cgi that redirects to the result of closer.cgi instead displaying it. This would be useful for the *BSD porting systems to use. A method to download source tar files (without viewing/parsing an html page) from the closest mirror would allow *BSD ports to more effectively use the mirrors. If the 'closer' mirror fails they could fall back to a static list of the mirrors and put apache.org last. -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.5 test release source distribution
From: Glenn Nielsen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, September 07, 2003 12:26 AM Subject: mod_jk 1.2.5 test release source distribution I have generated a test release source distribution for mod_jk 1.2.5, you can find it at: http://jakarta.apache.org/~glenn/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz Please build and test on as many OS/web servers as possible. I have already tested on Solaris7/8 Sparc. If there are no problems with this source release I will call for a release vote Friday 9/12 and release Monday 9/15 if the vote passes. Regards, Glenn I have tested the test release on OpenBSD i386 and sparc64. No problems have been found. Regards, -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk 1.2.5 and ipv6
It is supported on OpenBSD. int inet_pton(int, const char *, void *); Regards, -Kurt From: Henri Gomez [EMAIL PROTECTED] Hi to all, Still working on finding why iSeries couldn't use Unix98 def in_addr_t. BTW, what about adding ipv6 support in jk_connect.c by using inet_pton instead of inet_addr ? I'd like to have replies from people who have differents OS to know if they have support for inet_pton... Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release mod_jk 1.2.5
From: Glenn Nielsen [EMAIL PROTECTED] Henri Gomez wrote: Joseph Shraibman a écrit : Glenn Nielsen wrote: No problems have been reported since the last test source distribution of mod_jk 1.2.5 was made available for testing July 26. ballot Please vote on a release of mod_jk 1.2.5: [ ] +1 release, and I will help build binaries for _ os/web server [ ] +0 ok to release [ ] -0 release, but I still have a problem with _ [ ] -1 don't release, there is a problem with _ /ballot The votes will be counted Monday August 4 and the source dist release made if the vote passes. So whatever happened? Why wasn't 1.2.5 released? Glenn could you tag jk (with my latest jk_connect.c patch) for jk 1.2.5 and make the release ? It will make jk compatible with OpenBSD/64 Yeah, I was waiting on that. Plus there is that recent thread safe issue which was raised with the uri mapping. Thank you Glenn and Henri. -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release mod_jk 1.2.5
From: Henri Gomez [EMAIL PROTECTED] The future will be mod_jk2, and I think we should focus on it after the 1.2.5 release. Ok. I jumped in on this thread because I thought that a new problem was introduced, but that is how it was in prior releases. I can report 1.2.5 works fine on OpenBSD-current/i386. I will keep working on OpenBSD/sparc64 and post patches here when it is working. If there's a 1.2.6 release maybe they can be incorporated then. Surely, jk 1.2.6 could be the release with OpenBSD/sparc64 support, we should fix this hack around the in_addr_t and of course add the Ipv6 support since an IP adress won't fix into a 32 bits integer for too long. Work on patch and we'll see how to make them useable for other OS, I think the rigth way is via in_addr_t I done more testing this morning and have determined that the u_long is the only bug preventing mod_jk from working on OpenBSD/sparc64. The other issues on OpenBSD/sparc64 that I was referring to seem to be related to my install of tomcat 4.0.6. I setup a new tomcat 4.1.27 install on a different box and mod_jk on OpenBSD/sparc64 works fine with it (with the datatype change). Is it too late to incorporate a change for the 1.2.5 release? You and David Rees have pointed out the in_addr_t is the correct type to use for inet_addr. Would it not make sense to change it to that and have a define for the iSeries? I would supply a patch, but I don't have an iSeries available. -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release mod_jk 1.2.5
From: Glenn Nielsen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, August 01, 2003 6:39 AM Subject: [VOTE] Release mod_jk 1.2.5 No problems have been reported since the last test source distribution of mod_jk 1.2.5 was made available for testing July 26. I've found one problem on the OpenBSD/sparc64 platform in jk_resolve. The recent change of the datatype of laddr from in_addr_t to u_long has broken this function. Could this be reverted back before release? Below is a copy of the commit that caused the problem: hgomez 2003/07/25 07:58:22 Modified:jk/native/common jk_connect.c Log: Use u_long instead of in_addr_t which make unhappy some platforms like iSeries Revision ChangesPath 1.10 +2 -3 jakarta-tomcat-connectors/jk/native/common/jk_connect.c Index: jk_connect.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_connect.c,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- jk_connect.c 24 Jul 2003 08:17:10 - 1.9 +++ jk_connect.c 25 Jul 2003 14:58:22 - 1.10 @@ -110,8 +110,7 @@ int x; /* TODO: Should be updated for IPV6 support. */ -/* for now use the correct type, in_addr_t */ -in_addr_t laddr; +u_long laddr; rc-sin_port = htons((short)port); rc-sin_family = AF_INET; -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release mod_jk 1.2.5
From: Henri Gomez [EMAIL PROTECTED] It was u_long before I change it in in_addr_t and then change it back to u_long. Oh. I guess I should have done a bit more research.;-) I just started attempting to get mod_jk going on sparc64 a few days ago. However, using a u_long for laddr is the cause of jk_resolve failing on OpenBSD/sparc64. The memcpy at the end copies all zeros into rc-sin_addr when u_long is used. There are some other issues going on with mod_jk OpenBSD/sparc64, so its not yet working even with this corrected. Given that, it may not make sense to hold up the release for this. I will need to put in more time to investigate the next issue. OpenBSD-3.3/sparc64 uses Apache 1.3.27 so this is not an issue with the new APR code. I tested releases 1.2.1 - 1.2.5 on OpenBSD/sparc64 and they all don't work. It wasn't until recently that I had time to start investigating it. I'll post patches here as I make progress. -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] mod_jk - chroot and user issues
Ok, it's in jk CVS and you'll just have to add -DCHROOTED_APACHE
to check it.
Thanks to give some feedback.
Thank you for commiting the patches. :-)
I tested them and noted one problem with apache-1.3/Makefile.in. It includes
../common/list.mk which requires the JK=../common line to be there.
Regards,
-Kurt
$OpenBSD$
--- apache-1.3/Makefile.in.orig Fri Dec 6 09:31:40 2002
+++ apache-1.3/Makefile.in Fri Dec 6 09:32:02 2002
@@ -21,6 +21,7 @@ BUILD_DIR = ${JK_DIR}/../build/jk/apache
APACHE_FILES = Makefile.tmpl Makefile.libdir libjk.module
+JK=../common/
JK_INCL=-DUSE_APACHE_MD5 -I ${top_srcdir}/common
JAVA_INCL=-I ${JAVA_HOME}/include -I ${JAVA_HOME}/include/${OS}
JAVA_LIB=-L ${JAVA_HOME}/jre/lib/${ARCH} -L ${JAVA_HOME}/lib/${ARCH}/native_threads
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] mod_jk - chroot and user issues
Henri Gomez wrote:
I'm fine with the makefile updates but there is a problem with change in
apache-1.3/mod_jk.c since there is no ap_server_strip_chroot call
available on my Linux box.
Is it an OpenBSD specific call ?
Yes. My bad here. I mistakenly assumed that the chroot feature in OpenBSD's
Apache was not specific to OpenBSD. I thought they just changed the default
setting of an existing feature.
If so we'll have to add some #ifdef OPEN_BSD and I'd like to
have others jk commiters opinion. (I allready put too much
#ifdef AS400 ;)
I'll be to use a #ifdef CHROOTED_APACHE :
FWIW, I like the feature based define. If other OS's or Apache incorporate
OpenBSD's chroot option, then it wouldn't need to be changed. On the other
hand, if the consensus is not to commit the patch into mod_jk to keep the
cruft down, the OpenBSD port can apply the patch (assuming my port is
committed).
@@ -1742,7 +1746,7 @@ static void jk_init(server_rec *s, ap_po
/* Open up log file */
if(conf-log_file conf-log_level = 0) {
if(!jk_open_file_logger((conf-log), conf-log_file,
conf-log_level)) {
#ifdef CHROOTED_APACHE
conf-log = main_log;
#else
conf-log = NULL;
#endif
} else {
main_log = conf-log;
}
I'm thinking the jk_init change is not OpenBSD chroot specific. If someone
configures Apache's ServerType as standalone combined with the User/Group
directives, I think the problem I described with the log file would occur.
Isn't the conf-log = main_log behavior more generally more desirable?
Regards,
-Kurt
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] mod_jk - chroot and user issues
I recently created a port of mod_jk-1.2.1 for OpenBSD and needed to make
some minor patches to mod_jk. OpenBSD 3.2 has Apache 1.3.26 configured as
ServerType standalone, to chroot to /var/www and run as user www by default.
This combination requires a few minor patches so that mod_jk will continue
to work after an Apache restart.
Both jk_set_worker_file and jk_set_log_file need to call
ap_server_strip_chroot to account for the path changes while chrooted.
The log file is initially created as user/group = root/daemon, but after a
restart Apache is running as www/www so it doesn't have permission to reopen
the log file. In order to have the log file continue working after a
restart, I patched jk_init. Instead of setting conf-log to NULL when
jk_open_file_logger fails, I set it to main_log. In other words, if the new
log file can't be opened it falls back to the already open one. Other
possible solutions are to change the user and/or group of the log file to
match the Apache User/Group directives, however if the admin changes the log
file name the open will still fail unless the directory has write access for
the Apache User/Group.
I made some Makefile.in patches to allow the object files to be built
outside the source tree. I think these patches will work for other archs/OSs
too.
Please review and consider commiting. Please cc me if replying. Thank You.
-Kurt
$OpenBSD$
--- apache-1.3/mod_jk.c.origTue Nov 26 12:26:25 2002
+++ apache-1.3/mod_jk.c Mon Dec 9 01:59:18 2002
@@ -734,6 +734,8 @@ static const char *jk_set_worker_file(cm
/* we need an absolut path */
conf-worker_file = ap_server_root_relative(cmd-pool,worker_file);
+ap_server_strip_chroot(conf-worker_file,0);
+
if (conf-worker_file == worker_file)
conf-worker_file = ap_pstrdup(cmd-pool,worker_file);
@@ -762,6 +764,8 @@ static const char *jk_set_log_file(cmd_p
/* we need an absolut path */
conf-log_file = ap_server_root_relative(cmd-pool,log_file);
+ap_server_strip_chroot(conf-log_file,0);
+
if ( conf-log_file == log_file)
conf-log_file = ap_pstrdup(cmd-pool,log_file);
@@ -1742,7 +1746,7 @@ static void jk_init(server_rec *s, ap_po
/* Open up log file */
if(conf-log_file conf-log_level = 0) {
if(!jk_open_file_logger((conf-log), conf-log_file, conf-log_level)) {
-conf-log = NULL;
+conf-log = main_log;
} else {
main_log = conf-log;
}
$OpenBSD$
--- common/Makefile.in.orig Thu Dec 5 11:30:30 2002
+++ common/Makefile.in Thu Dec 5 11:32:29 2002
@@ -19,7 +19,7 @@ include list.mk
JAVA_INCL=-I @JAVA_HOME@/include -I @JAVA_HOME@/include/@OS@
CFLAGS=@apache_include@ @CFLAGS@ ${APXSCFLAGS} ${APXSCPPFLAGS} ${JAVA_INCL}
-include ../scripts/build/rules.mk
+include @top_srcdir@/scripts/build/rules.mk
JK=./
$OpenBSD$
--- apache-1.3/Makefile.in.orig Tue Nov 26 12:26:25 2002
+++ apache-1.3/Makefile.in Fri Dec 6 05:30:44 2002
@@ -1,6 +1,8 @@
## configure should make the Makefile out of this file.
-
+srcdir=@srcdir@
+top_srcdir=@top_srcdir@
+VPATH=@srcdir@
APXS=@APXS@
OS=@OS@
JAVA_HOME=@JAVA_HOME@
@@ -17,14 +19,13 @@ libexecdir=${APACHE_DIR}/libexec
JK_DIR := ..
BUILD_DIR = ${JK_DIR}/../build/jk/apache13
-#VPATH=.:../common
APACHE_FILES = Makefile.tmpl Makefile.libdir libjk.module
JK=../common/
-JK_INCL=-DUSE_APACHE_MD5 -I ${JK}
+JK_INCL=-DUSE_APACHE_MD5 -I ${top_srcdir}/common
JAVA_INCL=-I ${JAVA_HOME}/include -I ${JAVA_HOME}/include/${OS}
JAVA_LIB=-L ${JAVA_HOME}/jre/lib/${ARCH} -L ${JAVA_HOME}/lib/${ARCH}/native_threads
-APACHE_CFLAGS=@apache_include@ @APXSCFLAGS@ @APXSCPPFLAGS@ -I../common
+APACHE_CFLAGS=@apache_include@ @APXSCFLAGS@ @APXSCPPFLAGS@ -I${top_srcdir}/common
# Compile commands
JK_CFLAGS = $(JK_INCL) $(JAVA_INCL) $(APACHE_CFLAGS)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
