directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: ServiceConfiguration vs. NtpConfiguration
Date Sat, 29 Sep 2007 19:09:13 GMT
Hi Stefan,

On 9/29/07, Stefan Zoerner <> wrote:
> Hi all!
> Due to the nice XBean documentation feature David depicted in his mails
> I learned that the NTP configuration carries 12 values
> bufferSize       int
> catalogBaseDn   java.lang.String
> enabled         boolean
> initialContextFactory   java.lang.String
> ipAddress       java.lang.String
> ipPort  int
> searchBaseDn    java.lang.String
> securityAuthentication  java.lang.String
> securityCredentials     java.lang.String
> securityPrincipal       java.lang.String
> serviceName     java.lang.String
> servicePid      java.lang.String
> Only some them seem te be used (ipPort, serviceName, servicePid), most
> of them are not. Does it really make sense to derive NtpConfiguration
> from a base ServiceConfiguration (javadoc: Base class shared by all
> protocol providers for configuration.), if there are only a minoriry of
> the attributes in common?

Yes I asked Enrique this question a while back and I think he said something

can be done later with the configuration hierarchy.  However we may need to
see what happens with all this as we strip out configuration beans and
JNDI in the bigbang branch.  It may change many factors.

Maybe it is handy to have a common abstraction for all protocol provider
> configurations. But if we generate the documentation from the beans, and
> attributes are listed for NTP (or any other protocol) which are not used
> at all (including the default documentation text), it will look quite
> confusing to the users.

I think in the end what will happen is the NTP service itself will be the
bean.  Perhaps
some hierarchy will exist to standardize common properties in these
services.  However
you're right in this that we should not have a service with properties it
does not use.

Perhaps we should make a point of cleaning this up in the bigbang branch as

Perhaps we can introduce a base class called MinimalServiceConfiguration
>    and derive both NtpConfiguration and ServiceConfiguration (probably
> other name) from it ...
> Or do I miss something?

No you're right we do need something else for services that really do not
store request specific
data within the DIT and thus need these additional parameters for
configuring how they search
for information.  Perhaps we can have interfaces which can be stacked on to
protocol services
for common characteristics.

We can have a ProtocolService interface with the minimum required of a
protocol service running
inside ApacheDS.  This just exposes the configuration parameters needed for
it to service requests
on the network.  Another interfaces can extend this for protocols that store
request level information
needed for each request which might have this search base etc as
properties.  Don't know what to
call it tho at this point.  We'll figure out the best descriptive name with
time I am sure, so for now we
can name it anything.


View raw message