You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Pierre-Arnaud Marcelot <pa...@marcelot.net> on 2013/08/02 19:13:13 UTC
[API] [ApacheDS] Problems with extended operations
Hi,
Recently, a user raised an issue on the LDAP API indicating that result codes from extended operations were lost.
See https://issues.apache.org/jira/browse/DIRAPI-151.
I took some time to debug the issue and it turns out it's true and it's even bigger than that, the response is simply not parsed correctly and internally in the API the object we return is just a newly created response for the given extended operation.
The result code returned from the server is completely forgotten, same thing for the specific values included in the extended operation response.
On the server, Emmanuel also found that responses were not correctly encoded.
We're currently fixing that.
This issue lead us to have a look at how the extended operations are loaded and I took a chance at simplifying a bit (which will help resolving the issue) the list of factories we need to append in the command line.
We had properties like:
- default.controls
- extra.controls
- default.extendedOperation.requests
- default.extendedOperation.responses
- extra.extendedOperations
In the end, those default/extra distinctions didn't mean much and we needed to have them all the time.
Also, the titles of the properties like 'default.extendedOperation.responses' were misleading as it was only intended for some specific kind of unsolicited response (having no request).
I simplified it to two simple properties:
- apacheds.controls
- apacheds.extendedOperations
All tests, scripts and installers have been updated to reflect this change, so everything should be covered.
Thoughts?
Regards,
Pierre-Arnaud
Re: [API] [ApacheDS] Problems with extended operations
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
On 2 août 2013, at 20:50, Kiran Ayyagari <ka...@apache.org> wrote:
> On Fri, Aug 2, 2013 at 10:43 PM, Pierre-Arnaud Marcelot <pa...@marcelot.net> wrote:
> Hi,
>
> Recently, a user raised an issue on the LDAP API indicating that result codes from extended operations were lost.
> See https://issues.apache.org/jira/browse/DIRAPI-151.
>
> I took some time to debug the issue and it turns out it's true and it's even bigger than that, the response is simply not parsed correctly and internally in the API the object we return is just a newly created response for the given extended operation.
> The result code returned from the server is completely forgotten, same thing for the specific values included in the extended operation response.
>
> On the server, Emmanuel also found that responses were not correctly encoded.
>
> We're currently fixing that.
>
> This issue lead us to have a look at how the extended operations are loaded and I took a chance at simplifying a bit (which will help resolving the issue) the list of factories we need to append in the command line.
> We had properties like:
> - default.controls
> - extra.controls
> - default.extendedOperation.requests
> - default.extendedOperation.responses
> - extra.extendedOperations
>
> In the end, those default/extra distinctions didn't mean much and we needed to have them all the time.
> Also, the titles of the properties like 'default.extendedOperation.responses' were misleading as it was only intended for some specific kind of unsolicited response (having no request).
>
> I simplified it to two simple properties:
> - apacheds.controls
> - apacheds.extendedOperations
>
> +1 for the move, but please support the old properties as well to keep this change backward compatible
> cause these properties(old and new as well) are not so explicit and many users may not think of these
> while debugging an issue, so backward compatibility saves them a lot of time when they update their
> server libraries (but using the old scripts/classes in their applications to start the server)
Sure, good idea.
Regards,
Pierre-Arnaud
> All tests, scripts and installers have been updated to reflect this change, so everything should be covered.
>
> Thoughts?
>
> Regards,
> Pierre-Arnaud
>
>
>
> --
> Kiran Ayyagari
> http://keydap.com
Re: [API] [ApacheDS] Problems with extended operations
Posted by Kiran Ayyagari <ka...@apache.org>.
On Fri, Aug 2, 2013 at 10:43 PM, Pierre-Arnaud Marcelot <pa...@marcelot.net>wrote:
> Hi,
>
> Recently, a user raised an issue on the LDAP API indicating that result
> codes from extended operations were lost.
> See https://issues.apache.org/jira/browse/DIRAPI-151.
>
> I took some time to debug the issue and it turns out it's true and it's
> even bigger than that, the response is simply not parsed correctly and
> internally in the API the object we return is just a newly created response
> for the given extended operation.
> The result code returned from the server is completely forgotten, same
> thing for the specific values included in the extended operation response.
>
> On the server, Emmanuel also found that responses were not correctly
> encoded.
>
> We're currently fixing that.
>
> This issue lead us to have a look at how the extended operations are
> loaded and I took a chance at simplifying a bit (which will help resolving
> the issue) the list of factories we need to append in the command line.
> We had properties like:
> - default.controls
> - extra.controls
> - default.extendedOperation.requests
> - default.extendedOperation.responses
> - extra.extendedOperations
>
> In the end, those default/extra distinctions didn't mean much and we
> needed to have them all the time.
> Also, the titles of the properties like
> 'default.extendedOperation.responses' were misleading as it was only
> intended for some specific kind of unsolicited response (having no request).
>
> I simplified it to two simple properties:
> - apacheds.controls
> - apacheds.extendedOperations
>
> +1 for the move, but please support the old properties as well to keep
this change backward compatible
cause these properties(old and new as well) are not so explicit and many
users may not think of these
while debugging an issue, so backward compatibility saves them a lot of
time when they update their
server libraries (but using the old scripts/classes in their applications
to start the server)
> All tests, scripts and installers have been updated to reflect this
> change, so everything should be covered.
>
> Thoughts?
>
> Regards,
> Pierre-Arnaud
>
--
Kiran Ayyagari
http://keydap.com