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]

Reply via email to