Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (nike.apache.org: domain of pajbam@gmail.com designates
 209.85.212.176 as permitted sender)
Sender: Pierre-Arnaud Marcelot <pajbam@gmail.com>
From: Pierre-Arnaud Marcelot <pa@marcelot.net>
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_3B2E7C3A-2B49-4EC1-891B-779D8B309495"
Subject: [API] [ApacheDS] Problems with extended operations
Message-Id: <3197CDFB-BC77-4D44-A978-6ADC4D66336F@marcelot.net>
Date: Fri, 2 Aug 2013 19:13:13 +0200
To: Apache Directory Developers List <dev@directory.apache.org>
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))


--Apple-Mail=_3B2E7C3A-2B49-4EC1-891B-779D8B309495
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

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=

--Apple-Mail=_3B2E7C3A-2B49-4EC1-891B-779D8B309495
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
">Hi,<div><br></div><div>Recently, a user raised an issue on the LDAP =
API indicating that result codes from extended operations were =
lost.</div><div>See&nbsp;<a =
href=3D"https://issues.apache.org/jira/browse/DIRAPI-151">https://issues.a=
pache.org/jira/browse/DIRAPI-151</a>.</div><div><br></div><div>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.</div><div>The result code =
returned from the server is completely forgotten, same thing for the =
specific values included in the extended operation =
response.</div><div><br></div><div>On the server, Emmanuel also found =
that responses were not correctly =
encoded.</div><div><br></div><div>We're currently fixing =
that.</div><div><br></div><div>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.</div><div>We had properties =
like:</div><div>-&nbsp;default.controls</div><div>-&nbsp;extra.controls</d=
iv><div>-&nbsp;default.extendedOperation.requests</div><div>-&nbsp;default=
.extendedOperation.responses</div><div>-&nbsp;extra.extendedOperations</di=
v><div><br></div><div>In the end, those default/extra distinctions =
didn't mean much and we needed to have them all the =
time.</div><div>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).</div><div><br></div><div>I simplified it to two simple =
properties:</div><div>- apacheds.controls</div><div>- =
apacheds.extendedOperations</div><div><br></div><div>All tests, scripts =
and installers have been updated to reflect this change, so everything =
should be =
covered.</div><div><br></div><div>Thoughts?</div><div><br></div><div>Regar=
ds,</div><div>Pierre-Arnaud</div></body></html>=

--Apple-Mail=_3B2E7C3A-2B49-4EC1-891B-779D8B309495--