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 (athena.apache.org: domain of elecharny@gmail.com
 designates 66.249.82.239 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=tT/Pv2VERY9TpZQLwbNSkRd3++IA/CuE7BOY8xq2oTlDMtHLt87od7a4OEnA/h6k8Udv1Jew2aZ/QdDZIRhAoMbm/QogKe4rwrcnX7ldLbc5Rkb8CyNB7VTMNFD8VsbLZ56FQSSDNmNUtXQmXQfYQjMlGe3rXSHp4NxUFwRYg1M=
Message-ID: <d45b08f00710100244s5d0e14fvc0fe10abab334f1a@mail.gmail.com>
Date: Wed, 10 Oct 2007 11:44:28 +0200
From: "Emmanuel Lecharny" <elecharny@gmail.com>
Reply-To: elecharny@iktek.com
To: "Apache Directory Developers List" <dev@directory.apache.org>
Subject: Re: [ApacheDS] Configuration of protocols
In-Reply-To: <6E568B8C-339D-4D5D-9720-9DA7E2E80D5D@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <a32f6b020710091210i245c6d97p7555371116be1252@mail.gmail.com>
	 <d45b08f00710091321nf021b8cj1958c2882050761@mail.gmail.com>
	 <DD75C44E-161F-4C96-88FE-C396E9127439@yahoo.com>
	 <a32f6b020710091425l19510497k588ccc3fda4206fd@mail.gmail.com>
	 <6E568B8C-339D-4D5D-9720-9DA7E2E80D5D@yahoo.com>

Hi guys,

I would be very interested (and the users too) to get some page on our
wiki explaining how to add a new interceptor in the current chain,
using xbeans. I'm trying to figure out how to have the ChangeLog
interceptor configured and used by the server, but I must admit I
don't have a clue.

Of course, it's not really urgent, but I think we need it before we
move to Phase II

Thanks a lot !

On 10/10/07, David Jencks <david_jencks@yahoo.com> wrote:
> In rev 583375  I moved all the non-ldap protocol servers into independent
> components and provided 2 NTP implementations as a basis for further
> discussion.
>
> NtpConfiguration illustrates the approach of a single component to config=
ure
> both udp and tcp versions of the same protocol.  This could trivially be
> enhanced with flags to enable/disable the tcp or udp choices.  If we deci=
de
> on this approach I would rename the class NtpServer.
>
> server.xml configuration of this looks like:
>
>   <ntpConfiguration ipPort=3D"80123">
>     <apacheDs>#apacheDS</apacheDs>
>   </ntpConfiguration>
>
>
> AbstractNtpServer, TcpNtpServer, and UdpNtpServer illustrate the approach=
 of
> a component per protocol version.  server.xml configuration of this looks
> like:
>
>   <udpNtpConfiguration ipPort=3D"81123">
>     <apacheDs>#apacheDS</apacheDs>
>   </udpNtpConfiguration>
>   <tcpNtpConfiguration ipPort=3D"81123">
>     <apacheDs>#apacheDS</apacheDs>
>   </tcpNtpConfiguration>
>
>
> I don't have a strong preference between these two approaches and think t=
hey
> both are equally good components.  I think the first, single component
> managing both servers, will be easier for our users to understand and
> configure, although it might be conceptually slightly less pure.
>
> Whatever the outcome of this discussion I think the next step, other than
> conforming the protocol servers to whatever we decide, is to move the min=
a
> setup code in ApacheDS into a separate component: this would replace the
> ApacheDS reference in all these servers.
>
> thanks
> david jencks
>
>
> On Oct 9, 2007, at 2:25 PM, Alex Karasulu wrote:
> On 10/9/07, David Jencks <david_jencks@yahoo.com> wrote:
> > NTP is pretty darn simple and I'm going to code up a couple of
> > examples using it so we can better see what we are talking about.
>
> NTP is simple and one of the reasons why I picked it for the example.  Al=
so
> as you
> say it can be used for a simple experiment to see the impact of what we w=
ant
> to do
> without a massive investment in time.
>
> On the other hand although NTP is the easiest to understand the same
> reasoning may not
> apply to the other protocols.  Enrique understands these best so he might
> have something to share
> about it.  Knowing that he's not on IRC I made sure he got wind of it by
> posting it here.
>
> > There's an extreme danger here of making a mountain out of a
> > molehill :-)
>
> Well the plan was simple: get rid of the configuration beans and directly
> wire up the components.
> As I said this was your idea and a damn good one.  I just don't want
> configuration beans floating
> around with one exception here and one exception there.
>
> Let's set a standard pattern to follow and stick to it.
>
> Alex
>
>
>


--=20
Regards,
Cordialement,
Emmanuel L=E9charny
www.iktek.com