Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: local policy)
Message-Id: <48369655.6720.00AC.0@novell.com>
Date: Fri, 23 May 2008 10:01:04 -0600
From: "Brad Nicholes" <BNICHOLES@novell.com>
To: "Jr. William A. Rowe" <wrowe@rowe-clan.net>
Cc: "APR Developer List" <dev@apr.apache.org>
Subject: Re: Disconnected ldap, abstracted dbd.
References: <482CB65C.1000306@rowe-clan.net> <482CBBA8.3060100@sharp.fm>
 <1404e5910805160533v5be0279r4b937c22d58c3735@mail.gmail.com>
 <482D9D32.6090704@rowe-clan.net> <4835F92B.5040601@rowe-clan.net>
In-Reply-To: <4835F92B.5040601@rowe-clan.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

   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?

Brad


>>> 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).
>>=20
>> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> Please, review.  Thanks.
>=20
> Bill