james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Benett <char...@benett1.demon.co.uk>
Subject Re: [PATCH] JDBC-backed UsersRepository implementation.
Date Sun, 10 Jun 2001 14:28:56 GMT
Darrell DeBoer wrote:
> 
> G'day,
> 
> This is my first ever patch submission, so forgive me if don't get it quite
> right.

Congratulations, Daz! Tarball is cool. Minor niggle, can you use cvs
diff -u in future?

> 
> 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.

I've got your UsersJDBCRepository up and working with mysql. Cool!
I've committed AbstractUsersRepository, UsersJDBCRepository and
mysql.jar.

However ... aliasing and forwarding doesn't seem to work. :-(

> 
> 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?

I've added junit-3.2.jar (copied from jakarta-turbine) but I get a bunch
of compile errors. Hence haven't committed testing classes yet. What
exact version are you using?

WRT testlets, long-term they may be better but short term we can use
anything.
No idea on ComponentManager q, off hand.

> 
> 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.

My original idea was to separate the basic User, which could be used in
multiple applications, so that the User/ UserStore/ UserRepository code
could be placed in Avalon (as a Cornerstone block). Then any avalon app
could use it with app-specific extensions (eg JamesUser). Which requires
writing the repository code so that it works without knowledge of
runtime type. Ideally, we would use either reflection or db metadata to
achieve that in UsersJDBCRepository (and UserLDAPRepsoitory). Open to
suggestions though.

Charles

---------------------------------------------------------------------
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