G'day,
This is my first ever patch submission, so forgive me if don't get it quite
right.
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
installation.
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.
ciao
Daz
Attached file patch.tar.gz
---- patches ------
patch.diff Diff against current cvs - build.xml
proposals/v1.3/java/org/apache/james/userrepository/DefaultUser.java
proposals/v1.3/conf/james-config.java
---- new files ------
proposal/v1.3/java/org/apache/james/userrepository/AbstractUsersRepository.java
proposal/v1.3/java/org/apache/james/userrepository/UsersJDBCRepository.java
proposal/v1.3/java/org/apache/james/testing/TestUsersRepository.java
proposal/v1.3/java/org/apache/james/testing/TestUsersJDBCRepository.java
patch.tar.gz
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
