Database connections (was RE: Avalon dependance in mailets)

[Danny Angus <da...@apache.org>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Database connections (was RE: Avalon dependance in mailets)

[Serge Knystautas <se...@lokitech.com>]

----- Original Message -----
From: "Danny Angus" <da...@apache.org>


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

I should have responded to this email with my last comment, but again I
don't think we should tie db connections to the mailet API.  While database
connections are significantly less contentious than logging, I feel the same
argument applies that the mailet API doesn't need to create dependencies
with these related libraries to address these issues.

Serge Knystautas
Loki Technologies
http://www.lokitech.com/


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Database connections (was RE: Avalon dependance in mailets)

[Kenny Smith <ke...@journalscape.com>]

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:   
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail: 
>> <ma...@jakarta.apache.org>
>>
>>
> 
> 
> -- 
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
> 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Database connections (was RE: Avalon dependance in mailets)

[Kenny Smith <ke...@journalscape.com>]

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:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
> 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Database connections (was RE: Avalon dependance in mailets)

[Stephen McConnell <mc...@apache.org>]

Danny Angus wrote:

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

The IOC approach using MailetContext().getConnection( key ) gets my vote
(where key is a key to one of possibly multiple datasource URLs declared by
a particular mailet type).

Cheers, Steve.

(who is watching the Mailet spec subject with interest as it is terribly
consistent with thoughts I have about containment/containers and the 
freedom
developers should have with respect to lifecycles, lifestyle, etc.).

:-)

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>