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 <[email protected]>: > 2011/7/18 Oleg Kalnichevski <[email protected]>: >> 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 >> >> >
