james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Serge Knystautas" <ser...@lokitech.com>
Subject Re: Input for JDB Mail Repository
Date Tue, 31 Jul 2001 11:29:08 GMT
Charles,

This is a good idea to get feedback, but I've actually taken a stab at this
(<rant>actually I was debugging a freakin' annoying "feature" of JavaMail...
if you set new content on a message, you have to call "saveChanges()" for it
to take effect.  what a brilliant design.  I think I might change James so
it automatically calls saveChanges after a mailet makes a change as I think
the SMTP Transport engine Sun wrote already is doing this. </rant>).

Anyway, here's what I did.  If you configure db://conf/spool, this will look
for a configuration file at conf/spool (this should be a file, not a
directory).  This configuration file contains necessary JDBC connection
stuff (driver, URL, username, password), table name, repository name, all
the SQL used by the JDBCMailRepository, and a directory for message bodies
(more later).

Right now it's just reading it in as a Properties object (name=value), but
this could be changed to XML (then with includes, you could keep all the
JDBC and SQL in one shared XML file, and each conf file would only set the
repository name (and maybe table name).  I'm not incredibly pleased with
this design as I think I'd rather this all be in the avalon loaded conf
files, but what can you do?

Two other notes:
- I still haven't gotten excalibur (or any JDBC pooler) integrated yet.
>From what I've seen of excalibur, it looks like I have to let avalon do the
configuration, so I'm not sure how to back-fit my conf file into an
excalibur.
- I've written the JDBCMailRepository to store message bodies in the file
system.  Even after all this work to not parse messages, a large message (a
meg or more) would still bring my JDBC driver to a crawl.  Now, the
JDBCMailRepository will store all delivery information and the message's
headers to the database, and the message body separately to the file system.
It's hopefully written in such a way that you could turn this off and on, as
it should already read a message that is entirely stored in the database and
so you'd just have to change how it saves messages.

Anyway, I was still testing and hadn't committed anything yet.  It looks
pretty stable, but I thought this morning's error was something seriously
wrong with the parsing-avoidance code.

Serge Knystautas
Loki Technologies
http://www.lokitech.com/
----- Original Message -----
From: "Charles Benett" <charles@benett1.demon.co.uk>
To: "James Dev" <james-dev@jakarta.apache.org>; "Jakarta-James User"
<james-user@jakarta.apache.org>
Sent: Tuesday, July 31, 2001 7:15 AM
Subject: Input for JDB Mail Repository


> In cvs proposal dir is Serge's JDBCMailRepository and
> JDBCSpoolRepository.
> Serge uses Mssql server with Inet Sprinta (I think) and I have got it
> going with MySQL and the mm driver.
> This is intended to replace the town db classses in James 1.2.1
>
> At the moment, they new classes need to be re-compiled for different
> drivers and dbs.
> I want to tidy up the config and move them into the main tree.
> So I am looking for input from developers/ users.
>
> 1) At the moment the JDBCMailRepository (like the town repository) puts
> all messages in one db table.
> a) Would it be useful to allows different tables, e.g. one for spam
> another for errors etc.?
> b) If one had multiple tables, how likely is it that one would have them
> in different dbs or on different machines?
> c) If one had multiple tables, would we still want all POP3 inboxes to
> be in one table or would per-user tables make sense?
>
> Any other suggestions re storing mail in a db would be welcome.
>
> Charles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org


Mime
View raw message