> On Feb 21, 2024, at 4:21 PM, Emmanuel Lécharny wrote:
>
> On 21/02/2024 22:09, Brian Demers wrote:
>> (Mostly thinking out loud)
>> Is there any downside in us wrapping the NetworkLdapConnection returned by
>> the LdapConnectionPool to call releaseConnection instead of close?
>
> We could
On 21/02/2024 22:09, Brian Demers wrote:
(Mostly thinking out loud)
Is there any downside in us wrapping the NetworkLdapConnection returned by
the LdapConnectionPool to call releaseConnection instead of close?
We could do that, to some extent. LdapNetworkConnection can be extended,
so we
(Mostly thinking out loud)
Is there any downside in us wrapping the NetworkLdapConnection returned by
the LdapConnectionPool to call releaseConnection instead of close?
Possibly a new `PooledLdapConnection` that _basically_ delegates everything
except the `close` method?
That would allow
Hi Brian,
long story short: the LdapConnection interface (and implementation)
already has a close() method that shutdowns the IO connection, so it's
not possible to use the try-with-resources feature, because that would
have meant changing the LDAP API to make the close() method actually
I'm hacking away on a SCIMple + ApacheDS + LDAP API example.
I haven't used the LDAP API project before, but the docs have been a big
help!
One thing I'm struggling with is the way connection pooling _should_ be
used.
For example, a non-pooled request could be created doing something like
this:
