"[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 must be loving throwing away man/hours :) :) :)
>>> 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.
_IF_ JK is _BUILT_ for Apache 2.0... If you're building JK for Apache 1.3
you CAN'T SIMPLY USE THE SAME .so....
Pier
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
