james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer <norman.mau...@googlemail.com>
Subject Re: As far as I am concerned 0.7 is ready
Date Mon, 18 Jul 2011 17:20:24 GMT
hi there,

i think it would sense to expose those property names as public static
fields. are you guys ok with it? If so I will commit the this and
after that start the release process...

bye
norman


Am Montag, 18. Juli 2011 schrieb Stefano Bagnara <apache@bago.org>:
> 2011/7/18 Oleg Kalnichevski <olegk@apache.org>:
>> On Mon, 2011-07-18 at 13:08 +0200, Stefano Bagnara wrote:
>>> Hi all,
>>>
>>> I updated jDKIM and it worked fine. I'm also trying to update another
>>> local project I have depending on mime4j trunk and I'm a bit lost
>>> about using a custom DecodeMonitor via dom.
>>> Here is the code I'm updating...
>>> ----
>>> factory = MessageServiceFactory.newInstance();
>>> factory.setAttribute("StorageProvider", new MemoryStorageProvider());
>>> factory.setAttribute("MimeEntityConfig", mimeEntityConfig);
>>> MessageBuilder builder = factory.newMessageBuilder();
>>> builder.setDecodeMonitor(new CheckHandlerDecodeMonitor(eh));
>>> Message message = builder.parseMessage(is);
>>> -----
>>>
>>> setDecodeMonitor is not anymore exposed by the interface. I thought we
>>> discussed this very thing in past but I run some search with no
>>> success (so probably my memory is leaking).
>>> Is this feature exposed in a different way that I can't currently find?
>>> Or otherwise, how can we expose it again?
>>> - one more possibile attribute in the factory?
>>
>> That'd be my preferred choice.
>
> Done
>
>>> - adding parseMessage(InputStream,DecodeMonitor) and
>>> parseHeader(InputStream,DecodeMonitor) methods to the MessageBuilder?
>>> - simply publishing the setDecodeMonitor from MessageBuilderImpl to
>>> MessageBuilder?
>>
>> Setter methods in an interface that essentially represents a strategy
>> does not sound right to me.
>
> My main concern is that "dom" api is a lot limited unless you use
> "setAttribute" with some magic parameter that you expect to work like
> our default implementation does. This doesn't sound good to me for an
> API.
>
> That said I'm fine with a 0.7 release from current trunk. It's not
> perfect, but a step forward from previous releases.
>
> So, I'll be very happy to vote as soon as Norman will roll it!
>
> Stefano
>
>> Oleg
>>
>>
>

Mime
View raw message