On Wed, 15 Aug 2001 23:39, Serge Knystautas wrote:
> This sounds great! To me, the connection pooling is the last big issue to
> getting the release out, and these changes really look like a step in the
> right direction (also configuration seems to be better). I'm not sure of
> the quality of the code (since you're putting it in as a proposal), but I'd
> love to get the JDBC mail repository modified to use this approach and get
> this proposal in the main branch soon. I've been busy the past few days
> but hope to work more on new mailets/matchers, some performance testing,
> and documentation later this week.
Hi Serge,
I think the code in the proposal is at least as good as the current
UsersJdbcRepository implementation, which is in the main branch. (Whether
that's saying something good about my new code, or bad about the old stuff -
that's an exercise for the reader ;-). I just though it was standard practice
to put big chunks of new code into a proposal before shifting to the main
tree. The XML parsing of the SqlResources.xml is a little clunky (but it
works); I was hoping to find a nice DOM wrapper somewhere in Jakarta that I
could reuse (or use JDOM?).
It's very simple to convert the JdbcMailRepository to use Avalon connection
pooling - I've got it working at home (for Mail Spool only - see below), and
I could add it to the proposals if you like.
Unfortunately, I think there are problems with getting user Inboxes to work
with the new JdbcMailRepository. The problem is that, to find an Inbox for a
user, James adds the username to the end of the DestinationUrl. eg it asks
for something like:
db://../conf/inbox.propertiesusername
which obviously won't work, since there's no file called that.
A few changes I'd like to see in the configuration/setup of the
JdbcMailRepository, if others agree.
- Get rid of the separate database .properties files.
- Move "real" config out of the properties file and into the main config.xml
- Move SQL statements (which really should be considered part of the code
base) for all databases into a common SqlResources file (that's the
motivation behind SqlResources.java).
- Add automatic table generation, so that all that's needed for installation
is a valid database and dbURL.
I'm happy to help out on the above changes (and the move to Avalon), but I'd
like to get some feedback from others before starting. Whether these are in
the very next release, or slip into an Alpha2 release, I'm not too concerned.
ciao
Daz
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]