james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: MessageBuilder refactoring; was Re: dom / message refactoring
Date Wed, 26 Jan 2011 16:13:05 GMT

> > 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.


View raw message