On 06/01/2022 23:09, Marc Boorshtein wrote:
the PasswordModify extended request is natively supported by the LDAP
API, there is no need to cast it. The class hierarchy is the following:
[[AbstractRequest]]
^
|
+-- [[AbstractExtendedReques]]
| ^
| |
| +-- [PasswordModifyRequestImpl]
|
+-- [OpaqueExtendedRequest]
It's a bbit a pity we havn't made the OpaqueExtendedRequest class
extending the AbstractExtendedReques class, but anyway.
Right, I never want to cast an extended request to an existing class.
We're a virtual directory so we'll pass it through directly downstream
unless operated on by the user. Is there a way to disable casting to a
specific implementation? Would excluding the existing implementations
listed below force everything to OpaqueExtendedRequest?
As I said, the decision we made years ago to differentiate known
extended requests and unknown ones was wrongly implemented.
We end up with two incompatible classes, while what we would have liked
to have is a class that stores the value as a byte[], with inherited
classes that have dedicated semantic semantic.
The proper hierarchy should have been :
[[AbstractRequest]]
^
|
+-- [[AbstractExtendedReques]]
^
|
+-- [OpaqueExtendedRequest]
^
|
+-- [PasswordModifyRequestImpl]
This way, you would be able to either use the opaque impl, or the
specific impl, depending on your need.
The reason we have the API designed this way is that we use factories to
create extended requests instances, and the code looks like :
ExtendedOperationFactory factory = container.getLdapCodecService().
getExtendedRequestFactories().get(
extendedRequest.getRequestName() );
// We have to handle the special case of a 0 length matched
// value
try
{
if ( factory == null )
{
if ( tlv.getLength() == 0 )
{
( ( OpaqueExtendedRequest ) extendedRequest
).setRequestValue( Strings.EMPTY_BYTES );
}
else
{
( ( OpaqueExtendedRequest ) extendedRequest
).setRequestValue( tlv.getValue().getData() );
}
}
else
{
factory.decodeValue( extendedRequest,
tlv.getValue().getData() );
}
}
If the factory can't create the specific ExtendedRequest, then it
creates an OpaqueExtendedRequest instance...
I'm pretty sure we can safely change the hierarchy without breaking
things (ie from the existing code PoV), but then that would also break
the API compatibility. Another option would be to add the intermediary
class, name it DefaultExtendedRequest, made the OpaqueExtendedRequest
deprecated and move on, except that when we create the instance, we
can't create both the Opaque and Default at the same time...
Atm, withh the current API, I see no other way than checking if the
instance is an OpaqueExtendedRequest, or not...
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
[email protected] https://www.busit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
