Re: ServiceConfiguration vs. NtpConfiguration

[Alex Karasulu <ak...@apache.org>]

Hi Stefan,

On 9/29/07, Stefan Zoerner <st...@labeo.de> 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
remove
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
well.

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.

Alex

Re: ServiceConfiguration vs. NtpConfiguration

[Chris Custine <cc...@apache.org>]

I am so happy that these changes are already causing us to look at these
kinds of things!  This means we are doing the right thing here and we are
already seeing the benefits of simplification of the configs.  The great
thing about Spring in particular is that it doesn't care if the properties
on an object are from an interface implementation, extending an abstract
class, or just defined directly in the class...  and when setting a bean on
another bean the properties don't usually matter anyway so in many cases the
class heirarchy is more dependent of functional interfaces which we already
have...

Sorry if this doesn't make sense, the point I was trying to make is that we
will have infinitely more flexibility without the config beans and that was
one of the main reasons I have been looking forward to getting rid of them
for so long.

Thanks,
Chris

On 9/29/07, Alex Karasulu <ak...@apache.org> wrote:
>
> Hi Stefan,
>
> On 9/29/07, Stefan Zoerner <st...@labeo.de> 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
> remove
> 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 well.
>
> 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.
>
> Alex
>
>