apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <BNICHO...@novell.com>
Subject Re: Disconnected ldap, abstracted dbd.
Date Fri, 23 May 2008 16:01:04 GMT
   There seems to be a mismatch in how the #define APU_DSO_BUILD is being used.  APU_DSO_BUILD
has been defined as a boolean yet much of the code is simply checking for the definition rather
than the boolean state.  Therefore setting APU_DSO_BUILD to 0 doesn't actually turn off the
code compilation paths.  Shouldn't all of the statements of #ifdef (or #ifndef) APU_DSO_BUILD
be changed to #if APU_DSO_BUILD?


>>> On 5/22/2008 at 4:52 PM, in message <4835F92B.5040601@rowe-clan.net>, "William
A. Rowe, Jr." <wrowe@rowe-clan.net> wrote:
> William A. Rowe, Jr. wrote:
>> Eric Covener wrote:
>>> +1 on wrapping it all in 2.0, but I don't think the versioning
>>> restrictions allow apr-util to stop linking against LDAP in 1.3 -- for
>>> example applications that load ldap symbols privately  ("not at all"
>>> shouldn't be an issue because they can't do anything useful with the
>>> apr-util LDAP API in that case).
>> Be aware that there is a one line change to most applications who want
>> apr-1.3.x to provide that binding for them (so they can use the symbols
>> privately).  Simply, this would just no longer be the default.  I think
>> that's a healthy thing since this affects < 10% of applications that
>> consume apr-util, and of the others, they would be better off linking
>> ldap only for specific components, e.g. mod_ldap/mod_authnz_ldap.
> http://people.apache.org/~wrowe/ldap/apr-util-1.x-dso.patch has been
> committed and is ready for review.  If I hear no objection I'll roll
> on in the morning to 1.3.0 for apr and apr-util.  There should be no
> API change going into applying this concept for dbm, iconv or xml
> so those are not showstoppers.
> The dbd and ldap are both abstracted to use the apu_dso_load.  There is
> an apu_dso_init but it will be implicitly called for apr 1.x; in apr 2.x
> we can dictate that the users must explicitly invoke a general apr-util
> initializer.  The loaded dso's lifetime is the process lifetime.
> Netware has a real problem, it's apr_pool_parent_get stops short of the
> root pool.  Two consumers with different pools will not share the loaded
> resources and can cause the 2nd consumer to segv when the 1st consumer
> frees it's highest level pool.  Bad mojo, nothing I can do about it since
> I have no clue why this exception was made on Netware.
> The changes permit us to run make test without installing the loadable
> dso dbd and ldap providers, the make file is hacked to include these in
> the shared lib path.
> Note that we keep two hashes, new is private dsos hash of modules by their
> module name.  While dbd is refactored to use the apu_dso schema, it's still
> most efficient to continue to maintain a hash by the driver's shortname.
> Please, review.  Thanks.
> Bill

View raw message