G'day,
I've added a new "userstore" proposal to the proposals directory. I've
haven't made any modifications to the main CVS tree; the proposal directory
contains all of the changes, including a modified Ant buildfile. (There were
too many changes to cleanly add it to the existing build file. I reckon that
keeping a separate buildfile for a proposal is probably cleaner, as well).
The following detail is taken from the proposal README.
enjoy
Daz
PROPOSAL: - Modifications to UserStore.
=================================
GOALS:
- use Avalon and Cornerstone DataSource components for connection serving and
pooling (done)
- Remove hard-coded SQL statements from UsersJdbcRepository (done)
- 'SqlResources.java' - detect db product from jdbc connection and select
appropriate SQL statements from SQL definition file for specific product
(done)
- Simpler to create database-backed UserRepository implementations for
different User implementations (done)
- Consolidate existing UserRepository implementations - refactor out common
functionality
- Simplify UserRepository specification in config - make it URL:// based,
like MailRepository.
- Have UserStore serve up repository implementations based on: storage, User
implementation, and location.
OTHER GOALS (reuse development in JdbcMailRepository):
- use Avalon and Cornerstone DataSource components in JdbcMailRepository
- Use SqlResources.java to provide db-specific SQL to JdbcMailRepository
- Automatic table generation for JdbcMailRepository
TO BUILD:
../build.sh -buildfile proposals/userstore/build.xml
I haven't modified the original buildfile, but instead provided a build.xml
within the proposals dir. (I think this is a cleaner approach, since we don't
pollute the "real" buildfile.)
The "javadocs" target builds javadoc from the build/src directory, so it
includes docs for the proposal.
TO USE:
The main configuration is setting up the "database-connections" section of
the config file. There's an example there using MySql - I haven't yet tested
on other databases (although the SQL statements haven't changed much, so I
imagine it will still work on other platforms).
The only properties you should need to set are:
<driver>-- Class name of database driver to use --</driver>
<dburl>-- the jdbc connection string for your database</dburl>
<user>-- database user --</user>
<password>-- database password --</password>
TEST INSTRUCTIONS:
- Telnet to the remote manager: "telnet localhost 4555".
- Do some user management - type "help" for options.
- type "use list-james", to switch to the repository for this list.
- list the users
- send an email to "james-on@localhost"
- list the users again
(note: some user management commands fail for repositories other than
"LocalUsers").
NOTES:
I've added an "AbstractJdbcUsersRepository", which takes care of most of the
work of a JdbcUsersRepository, making it pretty easy to add new ones. The
abstract implementation doesn't have knowledge of actual User
implementations; this is restricted to overridden methods in concrete
repository implementations.
The AbstractJdbcUsersRepository obtains SQL statements via an "SqlResources"
object, which reads an sql definition file, finds the appropriate <sqlDefs>
element, and provides the sql strings contained. In addition, the
SqlResources class handles 2 other things:
a) Parameter replacement in SQL (eg replace all occurances of ${table}
within an sql statement with the parameter value for "table". Currently, all
parameters are taken from the configuration <sqlParameters> element. It is
also possible to define parameters (defaults, if you like) within the sql
definition file itself (a <parameters> element).
b) Examines the Jdbc Connection to determine what database product is
being used. SQL statements specific to a db product (eg mysql) can then be
used automatically. (Detection is done by regexp matches on
Connection.getMetaData.getDatabaseProductName())
I've added 3 concrete subclasses of AbstractJdbcUserRepository: for
DefaultUser, DefaultJamesUser, and "ListUser" (which for now is nothing more
than a name). These give an example of how little work there is to implement
a new repository. The ListUsersJdbcRepository can store multiple lists of
names in a single table.
I've made a simple modification to "RemoteManagerHandler", to allow testing.
The "use [userRepositoryName]" command will switch the Remote manager to
manage the named repository. This isn't really intended for production, makes
for easier testing.
The "james-config.xml" included in the proposal sets up 4 jdbc repositories:
- "localUsers" - a JamesUsersJdbcRepository.
- "list-james" - a ListUsersJdbcRepository, used by the ListServ mailet.
- "list-test" - another ListUsersJdbcRepositor, for testing.
- "default-users" - a DefaultUsersJdbcRepository, for testing.
Note that in order for the Avalon DataSource components to work, I've included
an upgraded "avalon-excalibur.jar" in the proposal.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
