directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [ApacheDS] [SASL Branch] Question regarding enabling optional services
Date Mon, 21 May 2007 21:20:34 GMT
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
>

Mime
View raw message