Serge Knystautas wrote:
>
> I've got the JDBC repository pretty much working, but it's forced me to open
> a can of worms I was hoping to avoid. The approach isn't perfect, so maybe
> someone has suggestions (or tell me it isn't worth it).
>
> I'm trying improve on the "MimeMessage" that only instantiates parses the
> stream when accessed. This already exists and was JamesMimeMessage. This
> class does 4 things:
> 1. In all accessor methods, it will parse the stream into a MimeMessage (if
> not already parsed)
> 2. In all setter methods, it will parse the stream (if needed), and flag
> that the message was modified.
> 3. Provide an isModified() method
> 4. Provide a few convenience methods including getMessageSize()
> (MimeMessage.getSize() returns the size of the content, not including
> headers), getLineCount(), and writeContentTo(OutputStream).
>
> So far, so good.
>
> I tried to change a couple of things though:
> 1. Merge the EnhancedMimeMessage features into the JamesMimeMessage. most
> methods were already implemented, and the ones that weren't could just be
> copied over. Unfortunately this changed a lot of the IMAP code.
> 2. Change how it references an InputStream. Previously JamesMimeMessage was
> given an InputStream, and it would read this once to parse. I wanted to
> allow getInputStream() to work without parsing the message. This requires
> having a resetable InputStream. I changed the approach then to have
> JamesMimeMessage take a MessageSource object. This source object can open
> multiple inputstreams to the same message data.
>
> I like this because you can stream data from SMTP into a "mimemessage"
> (though not parse it) and then into a repository. Or read from one
> repository into a "mimemessage" (again, not parsing it) and into another
> repository.
>
> My problem is storing an inputstream to database requires that you know the
> length. This means what I'll have to do (from SMTP for instances, when you
> don't know the length of the message), is stream it to a temp file, then
> stream it into the database from there. I think this is an ok workaround as
> it doesn't create transaction problems, but it does create a bunch of extra
> disk writing.
>
> I hope to commit tonight if the brain is still working.
Serge,
I think you may have been closer with your mail of 17 May, when you
talked about reducing the use of MimeMessage.
Why do we need JamesMimeMessage - or MimeMessage? Can we eliminate them
completely?
For example, can we amend Matt's SizeLimitedSMTPInputStream to provide
the message size and Line count? That virtually eliminates the need for
MimeMessage.
Ideally, when a message is received by the SMTP server, it would extract
the following:
a) SMTP 'envelope': MAIL FROM, RCPT TO, remote host (which we do
already), Auth status, SSL status
b) Message size in ocets (incl. headers), line count.
c) The rfc822 'envelope' per the IMAP spec (includes subject, from,
sender, to, cc, bcc, reply-to, in-reply-to and message-id) or the full
headers.
These would be passed around with either an input stream or a byte
array(ie an extention to Mail - with a writeTo(outputStream) method).
So, I guess I come back to my question - what does MimeMessage give us?
Charles
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
