All, > > if we are adding value to Avalon's service, > > why don't we push this into Avalon. > > As I understand it from Peter and Andrei (I don't consider myself an > Avalon > guru), the question is what value does AbstractService provide? It isn't > a > generic interface, it is a particular subclassable implementation provided > by Cornerstone. In the case of AbstractService and AbstractJamesService, > every method would need to be overridden, as well as the new ones added. > > If you want to argue that there should be an Avalon Frameworks interface > for > these kinds of services, that'd be for the Avalon folks to take up, and > I'm > sure that Peter and Peter could do something about the service model if > Peter thought it worthwhile (I'll leave interpretation of the overloaded > name as an exercise for the reader ;-)). But in the meantime, > AbstractJamesService models the behavior James needs, and would gain > nothing > from extending AbstractService. > > Frankly, Peter and Andrei are far more Avalon knowledgable than I, and > ought > to be able to explain (or correct) this better to everyone. >
Noel is correct, on all points. To put this in perspective, not a single application in the Avalon-apps repository uses AbstractService as a base class for their components. That includes applications such as an FTP server for which such an implementation might make sense. AbstractService is just a random implementation that someone wrote - there's nothing special about it. Andrei and I rewrote AbstractService because it didn't meet our needs - it was tied to the old ConnectionManager implementation, didn't match our configuration, etc. --Peter -- To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
