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]>
