> > I am sorry I do not see how the service locator pattern can help with > > maintaining forward compatibility between releases. I always thought > > that it's goal was primarily to decouple layers and to enable multiple > > implementations of a service interface. > > > > http://en.wikipedia.org/wiki/Service_locator_pattern > > I wrote "the ServiceLoader, ..., is simply an abstraction layer." so > I'm in line with wikipedia, I'm sorry if I mislead you with some other > sentence. >
Fine. The problem is that Service Locator is considered an anti pattern by many, an opinion I fully subscribe to. > I try to explain with other words: > - abstract model was there to allow forward compatibility (it is the > only way I know that allows adding a method in the model without > breaking everything) What is wrong with plain old java classes? What is it _exactly_ that was wrong with Message classes in 0.6? > I'm not sure I understand what part of the ServiceLocator is "horrid" > in your opinion (I don't want to force you explaining anything or to > waste your time, but I'm always interested learning from other > developers). > See above. > The fact that I prefer the "previous" design and I don't see critical > "inconsistencies" in that design is just a comment (an IMHO). I accept > to loose that stuff as in turn you'll give me back a release soon. So > I think for both me and the community having a release with the many > bugfix/features introduced in trunk is a big win. (hope this makes > sense) > I am not sure. Now we have a situation when neither you nor I like the existing DOM API that much. Anyway, I'll stick to my original plan, bring mime4j to a state in which it could be released as 0.7 and step back again. Oleg
