From dev-return-43914-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Fri Aug 2 17:13:50 2013 Return-Path: X-Original-To: apmail-directory-dev-archive@www.apache.org Delivered-To: apmail-directory-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4378510CC1 for ; Fri, 2 Aug 2013 17:13:50 +0000 (UTC) Received: (qmail 37610 invoked by uid 500); 2 Aug 2013 17:13:50 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 37361 invoked by uid 500); 2 Aug 2013 17:13:45 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 37349 invoked by uid 99); 2 Aug 2013 17:13:44 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Aug 2013 17:13:44 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of pajbam@gmail.com designates 209.85.212.176 as permitted sender) Received: from [209.85.212.176] (HELO mail-wi0-f176.google.com) (209.85.212.176) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Aug 2013 17:13:36 +0000 Received: by mail-wi0-f176.google.com with SMTP id f14so784883wiw.15 for ; Fri, 02 Aug 2013 10:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:content-type:subject:message-id:date:to:mime-version :x-mailer; bh=lM7upbppZE4tDrrDbQEQ9yIhJq+R+H/BKdp+oXfSUVw=; b=NyozkABGtSKM0BjhcfHjpsSU3GjuW6Dn4cc3S+Yclz4vnO/b6dr/5BJlsS9ZhamBs7 lMiF0M0DEKmBLnhO6xxU+ns82hPyyyPVA+LhhCmuuRAzo1Mn1WJCGIQNfkWWjsUkRt5R a//jduZ++lp2rm8x4qF/G7jdnGGPe3Ff4el1RnHAvTKBFhUiFmi0G2P/YgE8rWsb9yOA U5kgcY9Ub9lRs5jhJZRjlyIDPFeSunyV3UbuC+cHKAl+FzpYEGHWfrFpTyidcBwhFVNo pOiCoiYs77YSDXWk2d/RxVzrHcrXt/B1VmKlPWPInlerQwU2RrL1Mny0+FdGSauop/TA eJ+g== X-Received: by 10.194.9.70 with SMTP id x6mr5620547wja.19.1375463595646; Fri, 02 Aug 2013 10:13:15 -0700 (PDT) Received: from [10.0.1.9] (def92-4-82-225-58-213.fbx.proxad.net. [82.225.58.213]) by mx.google.com with ESMTPSA id nb12sm4568101wic.3.2013.08.02.10.13.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 Aug 2013 10:13:14 -0700 (PDT) Sender: Pierre-Arnaud Marcelot From: Pierre-Arnaud Marcelot 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 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-Virus-Checked: Checked by ClamAV on apache.org --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 https://issues.a= pache.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?

Regar= ds,
Pierre-Arnaud
= --Apple-Mail=_3B2E7C3A-2B49-4EC1-891B-779D8B309495--