Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 2042 invoked from network); 21 May 2007 21:21:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 21 May 2007 21:21:17 -0000 Received: (qmail 5109 invoked by uid 500); 21 May 2007 21:21:13 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 5074 invoked by uid 500); 21 May 2007 21:21:13 -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 5051 invoked by uid 99); 21 May 2007 21:21:12 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 21 May 2007 14:21:12 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of akarasulu@gmail.com designates 66.249.92.175 as permitted sender) Received: from [66.249.92.175] (HELO ug-out-1314.google.com) (66.249.92.175) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 21 May 2007 14:21:04 -0700 Received: by ug-out-1314.google.com with SMTP id 71so47970ugh for ; Mon, 21 May 2007 14:20:40 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=m7655FXII/vguBseDpNn69V3RVCdNtagQwLDl6Ep6eGgD/8WnmgUH3oY+0Rvk9WAcVlEwxSwE8Ov/Ko4jDSCw1qEiwpfsRY6OPP+Jfe3/t2HJ4bVeirrr1Hd1ZEDF0gMXPH/ioiEW4VWmHajIwlH62ifPaWF+51vt/aW3LPB5YU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=HJeTZ2KNaPTG6c5rFfzTB0f+u4oDHfGzMJMVZ9MLi2P1YmFZQ6ANg5ty6/zunTwDIKRpmtzC1KuzeO4zsySR1LXgzwbBxPmhZ2hsnRJTgg0K9vKQTpXG37mRBpdWf6OL0YaKAjeWPOOAwse/Qs6221Zy7zFSu2DdsrJjfgzc+fE= Received: by 10.67.105.19 with SMTP id h19mr45513ugm.1179782434098; Mon, 21 May 2007 14:20:34 -0700 (PDT) Received: by 10.66.235.5 with HTTP; Mon, 21 May 2007 14:20:34 -0700 (PDT) Message-ID: Date: Mon, 21 May 2007 17:20:34 -0400 From: "Alex Karasulu" Sender: akarasulu@gmail.com To: "Apache Directory Developers List" , erodriguez@apache.org Subject: Re: [ApacheDS] [SASL Branch] Question regarding enabling optional services In-Reply-To: <568753d90705211414l1baf1661m6a28a96a1e6372ee@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_92523_8516087.1179782434020" References: <568753d90705211122p35b4cf8ekc7cd1c709de6fac@mail.gmail.com> <568753d90705211414l1baf1661m6a28a96a1e6372ee@mail.gmail.com> X-Google-Sender-Auth: 4bd834822528094c X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_92523_8516087.1179782434020 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cool this was what I was thinking regarding refactoring out some different base classes for the ServiceConfiguration later on. This was what I was trying to communicate a few emails back about branching out the ServiceConfiguration class hierarchy. For now I will make it just extend ServiceConfiguration and then we can look into this over time. But perhaps I should do this after merging the SASL branch since you seemed to have changed this (for the better) in that branch. Alex On 5/21/07, Enrique Rodriguez wrote: > > On 5/21/07, Alex Karasulu wrote: > > This is great. Thanks for the clarification. BTW I really would like > to > > extend this base > > ServiceConfiguration bean for these reasons and more perhaps if we start > > putting the > > configuration into the DIT and connecting it together with the > ConfigAdmin > > service. > > > > Do you recommend doing so for the Jetty based HTTP service even if there > is > > some > > additional properties that will not be utilized? > > I think the important thing is to make the configuration as similar as > possible across all the protocols, which makes it easier for users and > for the doco we have to write. So, it makes sense to start by > extending ServiceConfiguration and simply ignoring some methods. I > don't think there can always be a perfect match between a base class > and what the subclasses reuse. Once there's code in front of us it > will be easier to see whether subclassing ServiceConfiguration makes > sense. Since Spring doesn't care whether the beans all subclass > anything, you can always refactor later to NOT extend > ServiceConfiguration and simply work to make sure any overlapping > methods follow the same naming conventions. Again, an adapter config > class for the HTTP service makes sense from a usability point-of-view. > > It seems like the search base DN's are the most contentious since NTP > and HTTP won't use them, but I've been thinking more lately that we'll > be able to get rid of them. > > Enrique > ------=_Part_92523_8516087.1179782434020 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cool this was what I was thinking regarding refactoring out some different
base classes for the ServiceConfiguration later on.  This was what I was
trying to communicate a few emails back about branching out the
ServiceConfiguration class hierarchy.  For now I will make it just extend
ServiceConfiguration and then we can look into this over time.  But
perhaps I should do this after merging the SASL branch since you seemed
to have changed this (for the better) in that branch.

Alex

On 5/21/07, Enrique Rodriguez <enriquer9@gmail.com > wrote:
On 5/21/07, Alex Karasulu <akarasulu@apache.org > wrote:
> This is great.  Thanks for the clarification.  BTW I really would like to
> extend this base
> ServiceConfiguration bean for these reasons and more perhaps if we start
> putting the
> configuration into the DIT and connecting it together with the ConfigAdmin
> service.
>
> Do you recommend doing so for the Jetty based HTTP service even if there is
> some
> additional properties that will not be utilized?

I think the important thing is to make the configuration as similar as
possible across all the protocols, which makes it easier for users and
for the doco we have to write.  So, it makes sense to start by
extending ServiceConfiguration and simply ignoring some methods.  I
don't think there can always be a perfect match between a base class
and what the subclasses reuse.  Once there's code in front of us it
will be easier to see whether subclassing ServiceConfiguration makes
sense.  Since Spring doesn't care whether the beans all subclass
anything, you can always refactor later to NOT extend
ServiceConfiguration and simply work to make sure any overlapping
methods follow the same naming conventions.  Again, an adapter config
class for the HTTP service makes sense from a usability point-of-view.

It seems like the search base DN's are the most contentious since NTP
and HTTP won't use them, but I've been thinking more lately that we'll
be able to get rid of them.

Enrique

------=_Part_92523_8516087.1179782434020--