Having a DataMailet concept is the structure that I would prefer. Require that DataMailet configurations be provided a datasource (the configuration of that can be up to the individual implementation) during the initialization process so that during my handling of individual requests the mailet can use the DataSource to get a connection. I've done JDBC stuff before, but I'm terribly savvy with DataSources and all the spiffy things that come along with advanced use of the API, but I also agree accessing the datasources through names would be excellent so that multiple datasources can be accessed.
Kenny Smith
JournalScape.com
Danny Angus wrote:
Ok, how about this.. I think it may be a better answer to thisthere could be two kinds of mailet, Mailet's and DataMailet's the latter, by implementing DataMailet, declare their requirement for database connections. Then the container implementors can choose and declare in their specifications whether the container is a DataMailet container DataMailet would extend Mailet but DataMailetContext (getDataMailetContext()) would have to provide getConnection(datasourceName). Or.. using IOC the container could supply a mailetDatasource on initialisation which would have a single method.. getConnection(). The last would make it harder for a single mailet to access more than one datasource, so I prefer the MailetContext().getConnection(datasourceName) route. d.do we either make db connections available through the MailetAPI or do we force mailets to make other arrangements.-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
