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 Knystautas
Loki Technologies
http://www.lokitech.com/


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to