james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer <nor...@apache.org>
Subject Re: As far as I am concerned 0.7 is ready
Date Wed, 20 Jul 2011 06:27:05 GMT
Am 19.07.2011 11:29, schrieb Stefano Bagnara:
> 2011/7/19 Oleg Kalnichevski<olegk@apache.org>:
>> On Tue, 2011-07-19 at 11:00 +0200, Stefano Bagnara wrote:
>>> 2011/7/19 Oleg Kalnichevski<olegk@apache.org>:
>>>> On Mon, 2011-07-18 at 22:18 +0200, Stefano Bagnara wrote:
>>>>> 2011/7/18 Oleg Kalnichevski<olegk@apache.org>:
>>>>>> On Mon, 2011-07-18 at 21:48 +0200, Stefano Bagnara wrote:
>>>>>>> 2011/7/18 Norman Maurer<norman.maurer@googlemail.com>:
>>>>>>>> Hi there,
>>>>>>>> just to be more clear. I'm not very strong with it, so if
>>>>>>>> prefer we can just release it like it is...
>>>>>>> I leave this to you and Oleg. Either way it is not an elegant
>>>>>>> and we'll need to fix that part of the api (configuration + advanced
>>>>>>> features) in future releases (IMO).
>>>>>>> Stefano
>>>>>> Sorry for being blunt but MessageServiceFactory / ServiceLocator
>>>>>> was not of my making. I had nothing to do with it and have nothing
>>>>>> contribute there.
>>>>> What we have now is the result of what I did in a first place and how
>>>>> you changed it to make it pass your review.
>>>>> You wanted to remove the abstract classes in favor of interfaces for
>>>>> parser/builders and wanted to remove that methods I added (e.g:
>>>>> setDecodeMonitor was a method of the public api abstract class), so
>>>>> you can't say "I had nothing to do with it", now ;-)
>>>> Stefano
>>>> MessageServiceFactory is an abstract class, not an interface. So, I have
>>>> no idea what you are talking about. Feel free to add whatever methods to
>>>> that class you please.
>>> http://svn.apache.org/viewvc/james/mime4j/trunk/dom/src/main/java/org/apache/james/mime4j/dom/MessageBuilder.java?revision=923012&view=markup&pathrev=1137643
>>> You see we had an abstract MessageBuilder (now it is an interface) and
>>> that abstract class exposed setDecodeMonitor.
>>> http://svn.apache.org/viewvc/james/mime4j/trunk/dom/src/main/java/org/apache/james/mime4j/dom/MessageBuilder.java?r1=958717&r2=1063904&pathrev=1137643
>>> You see this revision is when YOU changed from abstract class to
>>> interface and removed the setDecodeMonitor. I'm talking of this very
>>> method and that very class/interface.
>>> I simply found that after your refactorings I was not able anymore to
>>> use the decodemonitor (while previously I used them and used in a
>>> typed manner), so I asked if this was intended and how you wanted me
>>> to deal with it (I know how I would like it to work, but we already
>>> saw that my solution is not acceptable to you, so I simply asked you
>>> what was acceptable and it sounded weird when you replied that you had
>>> nothing to do with this stuff).
>>> I now added the DecodeMonitor as a setAttribute for the factory as for
>>> your request but it was not in the factory previously.
>>> If adding typed methods to the MessageServiceFactory (for things we
>>> now have in setAttribute) is acceptable to you then I'll vet them and
>>> add methods I think are to there stay for 0.8. It is an abstract class
>>> so we can add this new methods in future with no backward
>>> compatibility issues.
>>> Hope this explains "what I'm talking about" :-)
>> Not really. What does this all have to do with the brokenness of
>> MessageServiceFactory / ServiceLocator stuff and the original issue
>> raised by Norman?
> I'll try again :-)
> We didn't talk about "brokenness". We talked about the fact that to
> use DecodeMonitor you now have to use setAttribute using a type unsafe
> method. I was explaining that I don't like too much this and he
> proposed to push the attribute names as public static fields. Hope you
> understand how this is related: if setDecodeMonitor for in the
> MessageBuilder then we wouldn't have to use
> setAttribute("DecodeMonitor", decodeMonitor) in the factory.
> If you don't see the relationship it's not a problem. My mind often
> does weird mental links. I record that you don't care of the
> MessageServiceFactory/ServiceLocator and I'll plan a refactory "the
> way I like it" for the next release.
> Thank you,
> Stefano
Said enough ;) Let us just release now ... I will start the VOTE thread 
within the next few minutes..


View raw message