RE: mod_jk2 (native2) autoconf preliminary works
Back to earth If that's provided with Apache 2.0... What if it's not provided with the web-server (AKA, apache 1.3?) We either don't use APR, or use the APR that is included with Apache2.0. Since the only available APR release are those from Apache 2.0 release, my shared apr lib, is ALLWAYS the one from Apache 2.0. For our purpose, that's the only 'stable' APR we can refer to, otherwise we'll be in a maintainance nightmare where everyone will have his own version/variation of APR. Hum, I agree for with/without threads. But otherwise APR should be a common piece of code ? ie: everything hidden behind apr_. If you tell us that they could be custom APR version, you're signing de facto the end of APR as an Apache Portable Runtime Library which was planned to be used for projects others than just Apache 2.0. But not using APR with Apache1.3 is another choice - using 'native' apache1.3 pools for example instead of APR pools, native apache1.3 maps, etc will be even slightly better ( and using the same code as jk1 will be good too ) Yep. APR libs should/could be installed in /usr/lib, /usr/include, and considered 'system' ( like glib, qt, nspr, etc ). If you build a non-threaded version, it shouldn't be called libapr.so in any case. I strongly disagree with that, considering the bazillion of options that you have in building APR, and the different features that the library _can_ support (but doesn't all times)... Even when building Apache 2.0 the APR library is built differently depending on _how_ you build your Apache 2.0... Yes - that's the main reason for using a single libapr.so. If you have 2 programs using different libapr.so, say with different locking mechanisms - they'll not work togheter, each will use a different lock. +1 It has never been released indipendently because of the API changes that (are still) going on to some extent... Look at the APR_ATOMICS, or the locking which got completely rewritten few months ago... The version that was shiped with Apache2.0 is stable and I think that's what we should use with jk2. I use today the one from Apache 2.0.35 (2.0.36 as soon as I can release a new rpm for 2.0.36) We may have to change our code when Apache2.1 is released - but coding against one API in jk2 ( i.e. APR-head ) and using it with Apache2 ( with another APR API ) is looking for trouble. +1, and that's one of my major concern with mod_webapp. Majority of people need to works against release, and don't wan't (or can't) track HEAD projects (APR/APACHE2/) The idea that you can release a product without some parts still changing is crazy. I understand Apache2's APR is not called APR1.0 because people don't want to support that particular API in future - but we can't ship jk2 with dependencies on APR-head ( whatever that is ). Yes, jk2 will need a known APR (ie the one from Apache 2.0.36) and if we want to have a jk2 for apache 1.3 with APR support, we should include the APR source tarball next to jk sources, (JF does like this for mod_webapp) Even if APR1.0 is released, we should use it only when a stable release of Apache2.x with APR1.0 is made. Any date ? Static apr may be a workaround, but I would avoid that if possible. libapr.so should be a 'deterministic' entity, if someone has a problem we should know he uses a certain version. I believe that the dynamic build of libapr is better if you have plugins that your code needs to read: when you compile those, you link them against a library, rather than to a binary (which you can't easily do anyway)... I believe the main benefit of using shared libraries is not saving memory, but having consistency - the same code will be used in Apache2 and jk2. You can't get into a situation when Apache2 is locking in one way, and jk2 in another way. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: mod_jk2 (native2) autoconf preliminary works
As a secondary note, if anyone has some time we should look at sourceforge's ant-contrib and their CC task and eventually merge jkant into it, we shouldn't duplicate the effort. Hum, why didn't they include ant-contrib in ant cvs ? I think it's sometimes easier to work on sourceforge. Without Jon and politics. :) LOL -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk2 (native2) autoconf preliminary works
GOMEZ Henri [EMAIL PROTECTED] wrote: We may have to change our code when Apache2.1 is released - but coding against one API in jk2 ( i.e. APR-head ) and using it with Apache2 ( with another APR API ) is looking for trouble. +1, and that's one of my major concern with mod_webapp. Majority of people need to works against release, and don't wan't (or can't) track HEAD projects (APR/APACHE2/) So far we haven't had one single problem with HEAD, also because we simply don't use it for release balls Even if APR1.0 is released, we should use it only when a stable release of Apache2.x with APR1.0 is made. Any date ? Maybe in the next couple of months... Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk2 (native2) autoconf preliminary works
jean-frederic clere [EMAIL PROTECTED] wrote: GOMEZ Henri wrote: I started to works on adding autoconf stuff for mod_jk2 (native2) for Apache 1.3/2.0 and will need some help and advice since it's not fluent in this area (JF/Pier are jtc specialists). Initial works in on Makefile for apxs. 1) What about moving scripts from jk/native to just jk ? It avoid duplicate between native and native2. That may bring problems: the configure.in normaly contains the files you want to generate. Every autoconf M4 definition file (configure.in) is (should) be tied to the bone of what it's trying to actually configure... If there's enough stuff in common (like all you want is something like --enable-native=[native/native2]) that could work, but otherwise, it's just going to mess stuff around. If you see (for example) what I did for WebApp, the whole configure.in has a common part (top and bottom) but all decisional steps are dependant on the APXS we find (and we're lucky since we only deal with APXS, not with all the issues you might find when building stuff with a generic compiler and such). 2) What should be done for APR in Apache 1.3 ? Should we use external shared apr lib ? That is probably the best. I disagree... APR is not a shared library like (for example) the C library, or the ZLIB library. It's a runtime, therefore each time you build it, you can have (or not) support for certain features and so on. Linking dynamically to such a library is (IMO) wrong unless you do it in a conservative way (like Apache 2.0 does, placing it in your Apache 2.0 distribution tree). I don't think we'll ever see a /usr/lib/libapr.so-x.x.x (and _THAT_ would create some problems) Should we use static build apr (like does webapp) ? In all case should the apr for 1.3 must be with or without pthread ? Therefore, why linking it dynamically? Just to have the extra overhead of referencing function pointers all the time? Do it static and compile it in, rely on the dynamic one only if your web server provides it for you (in that case it's because DSO modules are easier to link against a shared library than against an executable binary) 1.3 needs threads on win32 at least. On Win32 and Netware (that's it)... But AFAIK those should be different makefiles. 4) What about jni support ? Costin is the one that knows. Remember that on Darwin it's JNI_CreateJavaVM_Impl()... :) Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk2 (native2) autoconf preliminary works
On Tue, 7 May 2002, jean-frederic clere wrote: 1) What about moving scripts from jk/native to just jk ? It avoid duplicate between native and native2. That may bring problems: the configure.in normaly contains the files you want to generate. IMHO autoconf is justified only for jk2/apache1.3 ( eventually ). But if we decide to use it for apache2 and jni - then probably that may be a good idea. 2) What should be done for APR in Apache 1.3 ? Should we use external shared apr lib ? That is probably the best. Building mod_jk without APR is another option here. ( i.e. only with socket and what was in jk1 ). If we use apr, I think ( a bit strongly ) that we should use exactly the same library as apache2 does. APR libs should/could be installed in /usr/lib, /usr/include, and considered 'system' ( like glib, qt, nspr, etc ). If you build a non-threaded version, it shouldn't be called libapr.so in any case. Also I think the version that comes with Apache2's binary is to be considered the 'reference' - since Apr was not released independently, the apache2 package can be considered as the 'dependency'. Should we use static build apr (like does webapp) ? In all case should the apr for 1.3 must be with or without pthread ? Static apr may be a workaround, but I would avoid that if possible. libapr.so should be a 'deterministic' entity, if someone has a problem we should know he uses a certain version. 4) What about jni support ? Costin is the one that knows. It should use libapr.so, the one from Apache2 preferably. libjkjni.so should be generated - it won't be used from apache, but from java, and the same version of libjkjni can be used with any server ( apacheX, iis, etc ). In other words - you only compile libjkjni with Apache2 and APR, that's what java will use in all cases. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk2 (native2) autoconf preliminary works
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: If we use apr, I think ( a bit strongly ) that we should use exactly the same library as apache2 does. If that's provided with Apache 2.0... What if it's not provided with the web-server (AKA, apache 1.3?) APR libs should/could be installed in /usr/lib, /usr/include, and considered 'system' ( like glib, qt, nspr, etc ). If you build a non-threaded version, it shouldn't be called libapr.so in any case. I strongly disagree with that, considering the bazillion of options that you have in building APR, and the different features that the library _can_ support (but doesn't all times)... Even when building Apache 2.0 the APR library is built differently depending on _how_ you build your Apache 2.0... Consider that all other projects using them are building APR in their sources as Apache 2.0 and WebApp does (namely, SubVersion and in the future PostGreSQL)... Also I think the version that comes with Apache2's binary is to be considered the 'reference' - since Apr was not released independently, the apache2 package can be considered as the 'dependency'. It has never been released indipendently because of the API changes that (are still) going on to some extent... Look at the APR_ATOMICS, or the locking which got completely rewritten few months ago... Should we use static build apr (like does webapp) ? In all case should the apr for 1.3 must be with or without pthread ? Static apr may be a workaround, but I would avoid that if possible. libapr.so should be a 'deterministic' entity, if someone has a problem we should know he uses a certain version. I believe that the dynamic build of libapr is better if you have plugins that your code needs to read: when you compile those, you link them against a library, rather than to a binary (which you can't easily do anyway)... Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk2 (native2) autoconf preliminary works
[EMAIL PROTECTED] wrote: On Tue, 7 May 2002, jean-frederic clere wrote: 1) What about moving scripts from jk/native to just jk ? It avoid duplicate between native and native2. That may bring problems: the configure.in normaly contains the files you want to generate. IMHO autoconf is justified only for jk2/apache1.3 ( eventually ). But if we decide to use it for apache2 and jni - then probably that may be a good idea. 2) What should be done for APR in Apache 1.3 ? Should we use external shared apr lib ? That is probably the best. Building mod_jk without APR is another option here. ( i.e. only with socket and what was in jk1 ). If we use apr, I think ( a bit strongly ) that we should use exactly the same library as apache2 does. APR libs should/could be installed in /usr/lib, /usr/include, and considered 'system' ( like glib, qt, nspr, etc ). If you build a non-threaded version, it shouldn't be called libapr.so in any case. But we have to deliver the apr.so corresponding to mod_jk.so. Pier is right... That is more easy to link apr staticly to mod_jk. Having to deliver 2 files instead 1 will only bring more problems. Also I think the version that comes with Apache2's binary is to be considered the 'reference' - since Apr was not released independently, the apache2 package can be considered as the 'dependency'. We need one mod_jk.so for each version of apache2. Should we use static build apr (like does webapp) ? In all case should the apr for 1.3 must be with or without pthread ? Static apr may be a workaround, but I would avoid that if possible. libapr.so should be a 'deterministic' entity, if someone has a problem we should know he uses a certain version. 4) What about jni support ? Costin is the one that knows. It should use libapr.so, the one from Apache2 preferably. libjkjni.so should be generated - it won't be used from apache, but from java, and the same version of libjkjni can be used with any server ( apacheX, iis, etc ). In other words - you only compile libjkjni with Apache2 and APR, that's what java will use in all cases. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: mod_jk2 (native2) autoconf preliminary works
1) What about moving scripts from jk/native to just jk ? It avoid duplicate between native and native2. That may bring problems: the configure.in normaly contains the files you want to generate. Ok, I keep 2 set of files. 2) What should be done for APR in Apache 1.3 ? Should we use external shared apr lib ? That is probably the best. Good, it's allready available as shared lib with pthread support ;) Apache 1.3 on Linux will need to have LoadLibrary added, to avoid core dump (damn't ld loader) Should we use static build apr (like does webapp) ? In all case should the apr for 1.3 must be with or without pthread ? 1.3 needs threads on win32 at least. 3) Who could take a look at Makefile I'll commit for static mod_jk2 built ? I will try. I hope to be able to commit it today, it's mainly your own from native -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: mod_jk2 (native2) autoconf preliminary works
I must say I don't like autoconf too much :-) Ditto, ant is better than m4 but we couldn't ask people to have a jvm+ant+... to build native code ;( But I know many people find it easier, so I won't opose this. Thanks and JF is a great specialist of autoconf At the moment the compilation of jk2 is controlled by 4-5 'defines', easy to include in a build.properties ( which is used by both Ant-based and Makefile-based builds ). In addition, for Apache2's mod_jk2 we don't need autoconf - in fact I'm pretty convinced we shouldn't use it. autoconf chould just detect apxs location and grab java include (jni) Assume you install an apache2 binary, compiled with a certain type of locking, shm, etc ( the stuff that is detected/selected at compile time on the build machine ). It can be very bad if mod_jk2 detects/selects different options, strange bugs will happen. And it's a waste of time, the information is already available in the build/ dir of apache2. Please try first the Makefile in jk/native2. If it doesn't fit your needs, I'm ok with an autoconf. makefile.apxs allready works on native2 for apache 2.0 and apache 1.3 and configure just detect if APR should be used for apache 1.3. Also, for building jni you can use the Makefile in jni/, it requires an apache2 binary to be installed ( or built ) before - to get the libapr.so and includes. And it works when apache 2 / apr includes are in /usr/include/apache2 and libapr in /usr/lib IMHO apr should be used for all system-dependent stuff, we shouldn't have to autoconf. exact, just have to set apxs location for apache module. apxs know what to do to build a module, I submitted a patch some times ago to make apxs for Apache 2.0 build modules with many dependants sources file, from Ralf code in apache 1.3 apxs. As a secondary note, if anyone has some time we should look at sourceforge's ant-contrib and their CC task and eventually merge jkant into it, we shouldn't duplicate the effort. Hum, why didn't they include ant-contrib in ant cvs ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: mod_jk2 (native2) autoconf preliminary works
But we have to deliver the apr.so corresponding to mod_jk.so. Exact and and it's not a big problem, if you use packaging tools like rpm/deb. mod_jk will depend on libapr rpm or /usr/lib/libapr.so I could produce and place both of them in download dir Pier is right... That is more easy to link apr staticly to mod_jk. Having to deliver 2 files instead 1 will only bring more problems. Are you sure ? If there is bug fix in apr, you'll have to rebuild mod_jk. if you like apr and want it more widely used, you should consider it like zlib. Also I think the version that comes with Apache2's binary is to be considered the 'reference' - since Apr was not released independently, the apache2 package can be considered as the 'dependency'. We need one mod_jk.so for each version of apache2. Yep, I'll stick with Apache 2.0 release (alpha/beta/GA). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk2 (native2) autoconf preliminary works
On Tue, 7 May 2002, Pier Fumagalli wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: If we use apr, I think ( a bit strongly ) that we should use exactly the same library as apache2 does. If that's provided with Apache 2.0... What if it's not provided with the web-server (AKA, apache 1.3?) We either don't use APR, or use the APR that is included with Apache2.0. For our purpose, that's the only 'stable' APR we can refer to, otherwise we'll be in a maintainance nightmare where everyone will have his own version/variation of APR. But not using APR with Apache1.3 is another choice - using 'native' apache1.3 pools for example instead of APR pools, native apache1.3 maps, etc will be even slightly better ( and using the same code as jk1 will be good too ) APR libs should/could be installed in /usr/lib, /usr/include, and considered 'system' ( like glib, qt, nspr, etc ). If you build a non-threaded version, it shouldn't be called libapr.so in any case. I strongly disagree with that, considering the bazillion of options that you have in building APR, and the different features that the library _can_ support (but doesn't all times)... Even when building Apache 2.0 the APR library is built differently depending on _how_ you build your Apache 2.0... Yes - that's the main reason for using a single libapr.so. If you have 2 programs using different libapr.so, say with different locking mechanisms - they'll not work togheter, each will use a different lock. It has never been released indipendently because of the API changes that (are still) going on to some extent... Look at the APR_ATOMICS, or the locking which got completely rewritten few months ago... The version that was shiped with Apache2.0 is stable and I think that's what we should use with jk2. We may have to change our code when Apache2.1 is released - but coding against one API in jk2 ( i.e. APR-head ) and using it with Apache2 ( with another APR API ) is looking for trouble. The idea that you can release a product without some parts still changing is crazy. I understand Apache2's APR is not called APR1.0 because people don't want to support that particular API in future - but we can't ship jk2 with dependencies on APR-head ( whatever that is ). Even if APR1.0 is released, we should use it only when a stable release of Apache2.x with APR1.0 is made. Static apr may be a workaround, but I would avoid that if possible. libapr.so should be a 'deterministic' entity, if someone has a problem we should know he uses a certain version. I believe that the dynamic build of libapr is better if you have plugins that your code needs to read: when you compile those, you link them against a library, rather than to a binary (which you can't easily do anyway)... I believe the main benefit of using shared libraries is not saving memory, but having consistency - the same code will be used in Apache2 and jk2. You can't get into a situation when Apache2 is locking in one way, and jk2 in another way. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk2 (native2) autoconf preliminary works
On Tue, 7 May 2002, jean-frederic clere wrote: APR libs should/could be installed in /usr/lib, /usr/include, and considered 'system' ( like glib, qt, nspr, etc ). If you build a non-threaded version, it shouldn't be called libapr.so in any case. But we have to deliver the apr.so corresponding to mod_jk.so. Pier is right... That is more easy to link apr staticly to mod_jk. Having to deliver 2 files instead 1 will only bring more problems. If you use Apache2 with mod_jk.so, then you _have_ a version of libapr.so. Having 2 variations of the apr code will bring more problems. If you don't use Apache2, jk2 will require you install a libapr.so - the same version that is shiped/taged with Apache2. First, you may install apache2 later :-) And second, that's the only stable/tested/deterministic version of APR that exist. If APR1.0 is released in the meantime, we'll have to decide what to do, but I hope an Apache2.1 will be released at that time too. If we would use Glib/Qt/NSPR - we would use the same mechanism, you would install one of those libarary ( each having one common goal with APR - of shielding you against OS-specific code ). Also I think the version that comes with Apache2's binary is to be considered the 'reference' - since Apr was not released independently, the apache2 package can be considered as the 'dependency'. We need one mod_jk.so for each version of apache2. Of course. But mod_jk for Apache1.3 should use the same version of APR as mod_jk for Apache2. And preferably the same binary. Apache1.3 doesn't include apr, so we can treat libapr as any other external library that a module depends on. Same for IIS - apr.dll from Apache2 is the stable/tested version, that's the API we use in jk2 until another stable release of apr is available. It may be tough to require IIS users to install Apache2, since apr.dll is not distributed separately ( but I can live with that :-). So we may have to include apr.dll and the headers in the jk distribution for IIS. That's my opinion at least - I don't see myself using/supporting a system where diferent components use different variation of a library. Autoconf is not a deterministic process - especially if you use a binary distribution, where the binaries may have been built on different machine. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: mod_jk2 (native2) autoconf preliminary works
On Tue, 7 May 2002, GOMEZ Henri wrote: I must say I don't like autoconf too much :-) Ditto, ant is better than m4 but we couldn't ask people to have a jvm+ant+... to build native code ;( I agree - but doing autoconf twice ( once in APR, once for jk ) is _bad_. Not only because it's double-ugly, but because it can result in inconsistencies. If you have APR built once, all you need is a Makefile. I already added Makefiles for JNI and Apache2, for IIS we can use the DSP. Apache13 is the only open issue, and I think a Makefile using APXS will be the best solution, plus using the APR detection results. As I said, I'm happy with any other tool that simplifies the life of other people. autoconf chould just detect apxs location and grab java include (jni) JAVA_HOME is what's typically used to locate java. And setting one env variable ( or editing build.properties-like file ) is trivial and common practice for jakarta projects. ( curently you have to pass options or edit Makefile, but the settings can easily go in a build.properties include ). makefile.apxs allready works on native2 for apache 2.0 and apache 1.3 and configure just detect if APR should be used for apache 1.3. That's perfect. Just make sure it sets the defines that we need ( that select what we want ). And it works when apache 2 / apr includes are in /usr/include/apache2 and libapr in /usr/lib Perfect. As a secondary note, if anyone has some time we should look at sourceforge's ant-contrib and their CC task and eventually merge jkant into it, we shouldn't duplicate the effort. Hum, why didn't they include ant-contrib in ant cvs ? I think it's sometimes easier to work on sourceforge. Without Jon and politics. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk2 (native2) autoconf preliminary works
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Tue, 7 May 2002, Pier Fumagalli wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: If we use apr, I think ( a bit strongly ) that we should use exactly the same library as apache2 does. If that's provided with Apache 2.0... What if it's not provided with the web-server (AKA, apache 1.3?) We either don't use APR, or use the APR that is included with Apache2.0. So, you'd better not going to use APR at all, because if you're building a module for Apache 1.3, and you link against an APR who has been compiled for an Apache 2.0 server with the Worker MPM, you're down in troubles... For our purpose, that's the only 'stable' APR we can refer to, otherwise we'll be in a maintainance nightmare where everyone will have his own version/variation of APR. The stable version of APR are _there_... The stable version of APR are all in CVS, and all carry a tag... Simply because noone ever rolled a source tarball, that doesn't mean that you can't identify what's stable or not... But not using APR with Apache1.3 is another choice - using 'native' apache1.3 pools for example instead of APR pools, native apache1.3 maps, etc will be even slightly better ( and using the same code as jk1 will be good too ) That's a choice I can't make, but as I don't consider myself as a JK committer, I'm not going to comment... I'm just pointing out that if you want to use APR, there is one easy way to do it (probably the right way to do it), and several other more difficult (and probably some even wrong)... Just consider the fact that it's more than 1 year that I'm using that code, and I know every single line of C code that is in that repository APR libs should/could be installed in /usr/lib, /usr/include, and considered 'system' ( like glib, qt, nspr, etc ). If you build a non-threaded version, it shouldn't be called libapr.so in any case. I strongly disagree with that, considering the bazillion of options that you have in building APR, and the different features that the library _can_ support (but doesn't all times)... Even when building Apache 2.0 the APR library is built differently depending on _how_ you build your Apache 2.0... Yes - that's the main reason for using a single libapr.so. If you have 2 programs using different libapr.so, say with different locking mechanisms - they'll not work togheter, each will use a different lock. Do _you_ know how DYLD loading works? You can have 2 same exact libraries called libapr.so and (if your ld.so is not broken) have them to coexist easily on the same system. That's WHY you don't want to have libapr.so in /usr/lib, but rather bundled with your application, because if you put it as a shared library inside some standard OS-location directory, and that's not the right one you want, you're screwed... Why do you think all those suckers using APR are embedding it into their distros? Just because there's not an official tarball that will install itself in /usr/lib? NO, because _THAT_ is the _WRONG_ approach It has never been released indipendently because of the API changes that (are still) going on to some extent... Look at the APR_ATOMICS, or the locking which got completely rewritten few months ago... The version that was shiped with Apache2.0 is stable and I think that's what we should use with jk2. You talking about binaries or sources? On sources I agree, on binaries, well, it depends on _what_ you're building... We may have to change our code when Apache2.1 is released - but coding against one API in jk2 ( i.e. APR-head ) and using it with Apache2 ( with another APR API ) is looking for trouble. Err, ehemm... That clearly _shows_ that you don't know what's going on in APR land :) APIs are changing, right, but don't worry because some of the APIs that were shipped with the current 2.0.35 won't even be there in 2.0.40 or something like that... There are stuff which are being deprecated and everyone who has a clue knows they shouldn't be using them... They're there just because of some legacy code that hasn't been backported yet... An APR 1.0 is close, but if you want to be so rigid about what the runtime provides you well, then just go off and don't even think about using it until it's not 1.0 final and out-of-the-friggin' door... :) The idea that you can release a product without some parts still changing is crazy. I understand Apache2's APR is not called APR1.0 because people don't want to support that particular API in future - but we can't ship jk2 with dependencies on APR-head ( whatever that is ). Apache 2.0.36 is shipped in GA on a library which is still changing (and look, it's approximately 50% of its code)... But goddamit that's the best web server I've seen so far... Even if APR1.0 is released, we should use it only when a stable release of Apache2.x with APR1.0 is made. Ok, I'd give it another 6 months... Why then did you kids just included it in JK? You
