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: mime4j storage changes
Date Mon, 31 Jan 2011 11:21:12 GMT
On Mon, 2011-01-31 at 11:25 +0100, Markus Wiederkehr wrote:
> On Sun, Jan 30, 2011 at 7:40 PM, Stefano Bagnara <io@bago.org> wrote:
> > IIRC mime4j 0.6 by default used temporary files to store bodies
> > whenever the body was large (switchable through the use of a system
> > property). Instead with your latest changes mime4j uses in memory byte
> > arrays unless the user provides a custom "BodyFactory" implementation
> > to the MessageServiceFactory.
> >
> > This change in the default way mime4j deals with parsing and
> > memory/storage is something that deserved its own thread as it's not a
> > API refactoring like the others.
> I'm not very enthusiastic but I would prefer to keep the previous
> design. I think it is good out-of-the-box behavior if mime4j keeps
> smaller messages in memory and automatically stores larger ones on
> disk.

(1) The advantage of using an all-in-memory backend per default is
relieving the users from having to worry about having to explicitly
dispose of Message objects. Advanced storage backends may come with
additional responsibilities such as resource deallocation, so it would
be nice to make users realize that by making them explicitly declare
dependency on the storage module.  

(2) It was a big and a very unpleasant surprise to find out that mime4j
could quietly create temp files per default when parsing messages. This
makes mime4j prone to security issues when used for parsing confidential
messages. I understand this problem can be addressed by documenting the
default behavior more prominently, but the sad fact is that people do
not RTFM.    

> The motivation probably is to make DOM independent of storage but I
> don't think that's really necessary. 

Yes, that was the main motivating factor. I felt it was regrettable that
storage classes dragged in dependency on java crypto into 'dom'

> One could think of storage as
> part of DOM (or at least part of a certain DOM implementation) that
> can also be used standalone. If you really wanted to remove that
> dependency maybe dom and dom-impl modules would do it?
> Cheers,
> Markus

Stefano, Markus 

I'll revert the change or make 'dom' depend on 'storage' if you tell
which option sounds more preferable to you.


View raw message