datasources management

[mike m <st...@wryse.com>]

What is the benefit of configuring datasources in the struts-config.xml
file?

My meaning is, I am revising an existing webapp to use struts.  Obviously, I
replaced my home-grown controller because struts has so many more features.

But, I'm not sure I gain by replacing my home-grown "datasource manager".  I
am using WebSphere, so presumably I don't need pool man.  Data sources are
defined in a property file (not xml, but good enough) and are cached.

Am I over-looking something?  Will I miss out on some features if I keep
datasource management separate from struts classes?  Isn't limiting access
to datasources to the ActionServlet rather limiting?

Mike


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

Re: datasources management

[Ted Husted <hu...@apache.org>]

It's really more of a convenience for people just getting started.
Personally, I'd say stick with what works. Passing the connection up
from the Action can be problematic in a strict MVC design. When you can,
it's better to let the business tier handle all that, and just pass a
collection of beans, or a rowset, back to the Action.  

-- Ted Husted, Husted dot Com
-- For priority Struts support, 
-> visit http://husted.com/about/services


mike m wrote:
> 
> What is the benefit of configuring datasources in the struts-config.xml
> file?
> 
> My meaning is, I am revising an existing webapp to use struts.  Obviously, I
> replaced my home-grown controller because struts has so many more features.
> 
> But, I'm not sure I gain by replacing my home-grown "datasource manager".  I
> am using WebSphere, so presumably I don't need pool man.  Data sources are
> defined in a property file (not xml, but good enough) and are cached.
> 
> Am I over-looking something?  Will I miss out on some features if I keep
> datasource management separate from struts classes?  Isn't limiting access
> to datasources to the ActionServlet rather limiting?
> 
> Mike
> 
> --
> 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>