Err... that should read "I'm _not_ terribly savvy with DataSources..."
Kenny Kenny Smith wrote:
Hi Danny,
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 this
there 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]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
