Richard O. Hammer wrote:
I want to add a few observations to what Danny has already said in this
thread. I mention two classes, Message and Transport, which I think
could be improved by being super-classed, by giving each of them a
simpler parent. But this is based upon my limited experience with using
JavaMail's API for developing a mail server. So my list is probably not
complete. This may be just a sample.
First, obviously, in a mail server I need an object to represent a
message. Since it might require a lot of work for me to develop the
code myself, I look hopefully in JavaMail. There I find Message and its
descendant MimeMessage. These have many great methods which I can use,
already written. But Message has more than I need in some ways too. It
has a Session and a Folder, objects which I don't think I need in a
server, and it is difficult for me to construct a Message without
supplying a Session or Folder.
Now I guess it is true, as was suggested earlier, that I could get the
functionality I want by subclassing Message (or MimeMessage) and
supplying empty stubs for any objects (such as Session or Folder) which
it wants but that I don't need. But this seems backwards given my
understanding of object-oriented design. It seems to me that Message
ought to have an ancestor, perhaps named GenericMessage, useful in both
clients and servers, which would contain the wonderful methods needed in
both clients and servers, but would not contain a Session or a Folder.
The Session and Folder should be added in a subclass for clients.
Messages without Folders are common. Having Message know about the
Folder it came from is a convenience. Rather than have people learn
about two concepts (messge within a folder and message outside a folder),
and their "internet" equivalents, we get by with one concept.
A Session is simply a place to store configuration information for
JavaMail, rather than having it be global. MimeMessage uses this
information in a few places (although it's not quite as "optional"
as perhaps it should be), and most importantly it enables the simple
Transport.send method to find the appropriate Transport object to use.
If you never use Transport.send or Message.reply, you should be able
to get by with a null Session. Or, you could create a single global
Session object and use it everywhere JavaMail needs a Session object.
Actually, that's what Session.getDefaultInstance is for!
Another class which does more than I want is Transport.
Transport.sendMessage() sure is a handy method. It takes many problems
off the shoulders of developers. It is used in James, even though I
understand it was intended only for clients. But it gives a problem to
server developers as it sets message headers in ways appropriate for
clients -- but not appropriate for servers. Here again it seems to me
that Transport could descend from a class which did less. If there were
a GenericTransport class which did not set message headers, that would
be a boon to server developers.
I'm not sure what you're referring to. Transport.sendMessage is an
abstract method so it does nothing. SMTPTransport.sendMessage doesn't
set any headers itself. Perhaps you're concerned about the headers
that are set in MimeMessage.updateHeaders?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
