From dev-return-43936-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Mon Aug 5 07:23:43 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 3F594106D5 for ; Mon, 5 Aug 2013 07:23:43 +0000 (UTC) Received: (qmail 21916 invoked by uid 500); 5 Aug 2013 07:23:42 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 21843 invoked by uid 500); 5 Aug 2013 07:23:32 -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 21836 invoked by uid 99); 5 Aug 2013 07:23:29 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Aug 2013 07:23:29 +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 74.125.82.178 as permitted sender) Received: from [74.125.82.178] (HELO mail-we0-f178.google.com) (74.125.82.178) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Aug 2013 07:23:23 +0000 Received: by mail-we0-f178.google.com with SMTP id u57so2171887wes.9 for ; Mon, 05 Aug 2013 00:23:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:content-type:message-id:mime-version:subject:date :references:to:in-reply-to; bh=rTf7XZsn8O7G0vM5LumJVTBRvnCzpXhu8VC/++9gJ3w=; b=hq+gx2Satj/jW2+hOjBEMVngVDH7NoIleZ4hipsmDTYzNa64SAxmb33kzEA1G+KO7D WXsMyJM2Ib3hZBlqgOS+jvnCzvxN7XFQ45MuNRWzM1IQrV2Z/sH4hBHVDgzvMYjRCOnK thNej/wOA4FTKNrlqmNynhStBGgSzrdrSMzrdV+KoNs5xW+g1XYMd7M39vNiUwBH31eM OQaqKVBKzInxvgEtPedbSaA5dXByk8dJCW4AZ7+9fsMi/SPKCUwtkZkcGo9Jlsz8x3NF ggfswpJAqepOULxwAp2mT+lHTANnIE2oEDjg+NUFr2zODNLFaAoOhIDJucY2iGRF0i+S 2LcA== X-Received: by 10.180.160.165 with SMTP id xl5mr5684095wib.46.1375687383392; Mon, 05 Aug 2013 00:23:03 -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 z2sm19443314wiv.11.2013.08.05.00.23.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 Aug 2013 00:23:02 -0700 (PDT) Sender: Pierre-Arnaud Marcelot From: Pierre-Arnaud Marcelot Content-Type: multipart/alternative; boundary="Apple-Mail=_FC532FA6-F59B-4F97-BA54-E1DB4D584E35" Message-Id: <92BF65B6-3DD8-4ACE-A057-02A9BE6B6E8F@marcelot.net> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [API] [ApacheDS] Problems with extended operations Date: Mon, 5 Aug 2013 09:23:04 +0200 References: <3197CDFB-BC77-4D44-A978-6ADC4D66336F@marcelot.net> To: "Apache Directory Developers List" In-Reply-To: X-Mailer: Apple Mail (2.1508) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail=_FC532FA6-F59B-4F97-BA54-E1DB4D584E35 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 2 ao=FBt 2013, at 20:50, Kiran Ayyagari wrote: > On Fri, Aug 2, 2013 at 10:43 PM, Pierre-Arnaud Marcelot = wrote: > Hi, >=20 > 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. >=20 > 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. >=20 > On the server, Emmanuel also found that responses were not correctly = encoded. >=20 > We're currently fixing that. >=20 > 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 >=20 > 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). >=20 > I simplified it to two simple properties: > - apacheds.controls > - apacheds.extendedOperations >=20 > +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. >=20 > Thoughts? >=20 > Regards, > Pierre-Arnaud >=20 >=20 >=20 > --=20 > Kiran Ayyagari > http://keydap.com --Apple-Mail=_FC532FA6-F59B-4F97-BA54-E1DB4D584E35 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 kayyagari@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

<= blockquote type=3D"cite">
All tests, scripts = and installers have been updated to reflect this change, so everything = should be = covered.

Thoughts?

Regar= ds,
Pierre-Arnaud



--
Kiran Ayyagari
http://keydap.com

= --Apple-Mail=_FC532FA6-F59B-4F97-BA54-E1DB4D584E35--