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.
On 5/21/07, Alex Karasulu <firstname.lastname@example.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
> Do you recommend doing so for the Jetty based HTTP service even if there is
> 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.