Hi guys ! After controls, I have worked on extended operations.
It's a bit of more refactoring, as an extended operation (request or response) is an LDAP operation, not a sub-element of a ldap operation (the difference being in the way we process it). At this point, I started with the Cancel Request, and have it working fine, but there is one issue : this request requires a value, which can't be enforced by the current implementation (An extended operation has a name and optionally a value. This 'optionally' part cannot be made 'mandatory' unless we know which extended operation we are dealing with). That means the decoding creates an 'invalid' CancelRequest instance (ie, if the CancelID value is not present, then it will contain '0'). As a result, it will be up to the server to deal with this incorrect value. Per se, it's not really a big deal, as the part responsible for using the decoded instance also has the responsability to check that the instance is valid. I was just trying to find a way to simply throw an exception while decoding the instance (hint: it's not easy. The solution would have to make the extended operation implementation to 'know' that the value part is mandatory, and make it so that the Ldap deocder grammar be informed about it). Anyway, atm, the mechanism used to decode and encode extended operation without a Decorator is in place, and I still have to remove the 8 extendedRequest decorators and the 10 extendedResponse decorators. That should not take too much time, the hard part having been done. More later ! -- Emmanuel Lecharny Symas.com directory.apache.org
pEpkey.asc
Description: application/pgp-keys
