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 <[EMAIL PROTECTED]> wrote:
On 5/21/07, Alex Karasulu <[EMAIL PROTECTED]> 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
