directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: [ApacheDS] Configuration of protocols
Date Wed, 10 Oct 2007 15:43:34 GMT

On Oct 10, 2007, at 2:44 AM, Emmanuel Lecharny wrote:

> 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

Let's preview an explanation here to see if it explains enough.

1. Make sure xbean can find your interceptor by including  
@org.apache.xbean.XBean in the class level javadoc.  Simple single- 
valued configuration attributes don't need any special attention, but  
collection-valued configuration attributes need additional info so  
xbean can figure out the type:  @org.apache.xbean.Property  
nestedType=""  on  
a setter for instance.  I haven't figured out how to annotate  
collection-valued constructor args yet.

2. If your interceptor is part of apacheds you just need to make sure  
that the source jar for the module is a dependency of the apacheds- 
xbean-spring module so xbean will process your annotations with all  
the others.  If you are writing a 3rd-party interceptor you need to  
configure the xbean maven plugin to produce the schema and property  
files for your components.   If there's only one jar involved you  
should configure the x-m-p in the module itself, whereas if there are  
multiple jars involved you may wish to have maven compile source jars  
and generate a single schema as in apacheds-xbean-spring so all  
components share the same schema namespace.   A typical x-m-p  
configuration would look like:


       <!--  lets ensure that the XSD gets deployed  -->

Note the namespace that you should adjust to something appropriate  
for your project.

3. To include and configure your interceptor you need to modify the  
server.xml used by your server.  Here's the bit that configures the  
interceptors with a mythical fooInterceptor from the mythical third  
party project included:


           <!-- Uncomment to enable the password policy interceptor
           <fooInterceptor size="1" color="blue" xmlns="http://">
                  <bar width="2000"/>

           <!-- Uncomment to enable replication interceptor
               <replicationConfiguration serverPort="10390"  
                   <replicaId id="instance_a"/>

david jencks

> Thanks a lot !
> On 10/10/07, David Jencks <> 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  
>> configure
>> 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 decide
>> on this approach I would rename the class NtpServer.
>> server.xml configuration of this looks like:
>>   <ntpConfiguration ipPort="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="81123">
>>     <apacheDs>#apacheDS</apacheDs>
>>   </udpNtpConfiguration>
>>   <tcpNtpConfiguration ipPort="81123">
>>     <apacheDs>#apacheDS</apacheDs>
>>   </tcpNtpConfiguration>
>> I don't have a strong preference between these two approaches and  
>> think they
>> 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 mina
>> 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 <> 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.  Also
>> as you
>> say it can be used for a simple experiment to see the impact of  
>> what we want
>> 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
> -- 
> Regards,
> Cordialement,
> Emmanuel L├ęcharny

View raw message