I'll look over your code. :-) I don't think we need THREE sets of matchers
and mailets for list serving, though, right? Based upon your earlier
comments regarding the API, is it OK to use sqlResources as a utility class?
I don't expect that you'd want the Avalon Frameworks as a necessary
substrate.
> AvalonListServeManager works for JDBCListserve even if you don't expect it
> to from the code.
I really am not finding this to be true. JDBCListserv requires two tables.
A member table and a list description table. The important queries look
like:
SELECT members_only, attachments_allowed, reply_to_list, subject_prefix,
list_address
FROM + listservTable + WHERE listserv_id = ?;
SELECT member FROM + membersTable + WHERE listserv_id = ?;
sqlResources.xml defines the table as
CREATE TABLE ${table} (listName VARCHAR(50) NOT NULL, listSubscriber
VARCHAR(50) NOT NULL)
The list definition table isn't created or managed by AvalonListservManager.
More to the point, although the structures of the subscriber tables are
compatible, the column names are not; either the JDBCListserv code or the
XML needs to be changed to match.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
