The old Attribute.isAttribute would allow objects lacking the toBer
method to be attached to Change objects. This would result in errors
during serialization.
With the stricter Attribute detection, it's necessary to convert
Attribute-like objects containing type (string) and vals (array)
properties into real Attribute objects. This precise detection is
necessary to avoid falling back to the object-keys-into-attributes
That other logic which will turn a well structured Attribute-like object
such as this:
{ type: 'valid', vals: ['something'] }
... and turn it into something broken like this:
[
{ type: 'type', vals: ['valid'] },
{ type: 'vals', vals: ['something'] }
]
The pooled client would automatically bind when initializing connections
if bindDN and bindCredentials were passed to during construction.
This convenience should be supported in the plain client too.
If the client queue was enabled and requests were made during the
reconnect process (but after one unsuccessful connection attempt), they
would spawn concurrent reconnection attempts.
A client configured to reconnect should do so on socket close unless
unbind was called explicitly. This covers cases where the connection
undergoes clean but unexpected termination.
- Emit setupError for errors during client setup
- Client accepts more generic options.reconnect
- Fix unbind hang in client.destroy
- Add tests for client reconnect/setup scenarios
It appears that in node.js (at least recent versions), the 'close' event
is not emitted by TLS sockets. The CleartextStream class specifies that
the 'close' event is optional, so such operation is allowed. In order
to compensate, the event can be trapped at the raw net.socket instead.
Fixmcavage/node-ldapjs#161
Client actions utilizing an EventEmitter may generate unhandled errors,
especially during initial connection. Tracking whether the emitter has
been sent via callback is critical for proper routing of such errors.
Fixmcavage/node-ldapjs#144