james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darrell DeBoer <li...@bigdaz.com>
Subject [PATCH] JDBC-backed UsersRepository implementation.
Date Sun, 10 Jun 2001 07:06:47 GMT

This is my first ever patch submission, so forgive me if don't get it quite 

I've managed to get a database-backed UsersRepository implementation up and 
running, which is included here. A few things to note:

1) The code currently connects directly to a database, but it shouldn't be 
too hard to get it to use the JdbcDataSource in 
org.apache.avalon.excalibur.datasource. (I haven't quite worked out how to 
set up components yet, so I haven't done this myself).  I have, however, made 
the database configuration mirror that of the JdbcDataSource component, so 
that we should be able to pass it straight through.

2) Basically, I've got vanilla SQL working with MySQL, M$SQL Server and 
Oracle8i, although I'm getting some wierd problems with M$SQL using the 
JDBC-ODBC bridge (Inet Sprinta driver (Type IV) works fine). Presently, the 
SQL strings are hard-coded, but they could easily be set up during 
configuration, if necessary.

3) One usability feature I've added is that the component checks for a table 
named "JamesUsers" at start-up. If it's not present, the table is created. 
This eliminates the need to run a database script as a separate part of 

4) I've built some JUnit tests so that I can check on all combinations 
quickly and easily - these are included. I've also added a target to the 
build file to run these, but it requires adding JUnit to the "tools/lib" 
directory. Is there a plan/framework in place for testing? I saw a mention of 
"testlets" under Avalon - but I haven't investigated further... 

One thing that would be nice is a framework for testing components. At the 
moment I can't test the UsersFileRepository with the UsersRepositoryTest I've 
written, because I'm not sure how to get an initialised ComponentManager 
instance for initialisation. Does something like this exist?

5) The UsersRepository interface takes objects of type "User", making it hard 
to access the underlying extended properties of the "JamesUser" interface 
(aliasing, forwarding). I guess this works fine for a serialisation-based 
repository, but not so well for writing to a database. I've got around this 
by type-checking and casting at run-time, but ideally the UsersRepository 
interface would access "JamesUser" objects for insertion/update. (Is there 
any reason to have separate User & JamesUser interfaces? (or 
implementations?). I'd probably look at flattening them, if not.


Attached file patch.tar.gz
---- patches ------
patch.diff 	Diff against current cvs - build.xml
---- new files ------
View raw message