As mentioned elsewhere today, I've been using this ConnectionAdaptor:
http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/scaffold/src/java/org/apache/commons/scaffold/sql/
But I'd wouldn't mind refactoring it into more of a DataSource manager,
with the functionality seen in Struts 1.1. The idea being you could
register several different DataSources, and then have the business layer
say I want this one, or just give me the default (null) one.
-Ted
Craig R. McClanahan wrote:
>
> On Fri, 6 Sep 2002, Craig Tataryn wrote:
>
>
>>Date: Fri, 06 Sep 2002 15:16:13 -0500
>>From: Craig Tataryn <[EMAIL PROTECTED]>
>>Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
>>To: [EMAIL PROTECTED]
>>Subject: Re: Alternative Datsource Hot-potatoing...
>>
>>Thanks Craig. I'll take a look into option 3.
>>
>>Could you see a problem with me creating a class called "DataAdaptor" with a
>>static method called "getConnection()" which is initialized apon application
>>startup with the DataSource setup by Struts? Then using this static method
>>in my data objects to grab a connection?
>>
>>
>
> Isn't that basically option 2?
>
> The only disadvantage is that, unless you're careful, your DataAdaptor
> class will be dependent on Struts unless you make it have a static
> setDataSource() method or something. But you're still tying your business
> logic classes to the presence of DataAdaptor in every program that uses
> this approach (which may or may not be a big deal).
>
>
>>Craig.
>>
>
> Craig
>
>
>>>From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
>>>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>>>To: Struts Users Mailing List <[EMAIL PROTECTED]>
>>>Subject: Re: Alternative Datsource Hot-potatoing...
>>>Date: Fri, 6 Sep 2002 11:40:48 -0700 (PDT)
>>>
>>>
>>>
>>>On Fri, 6 Sep 2002, Craig Tataryn wrote:
>>>
>>>
>>>>Date: Fri, 06 Sep 2002 12:41:26 -0500
>>>>From: Craig Tataryn <[EMAIL PROTECTED]>
>>>>Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
>>>>To: [EMAIL PROTECTED]
>>>>Subject: Alternative Datsource Hot-potatoing...
>>>>
>>>>I was wondering if someone could give me a heads up on some alternative
>>>>means for which to give my data access layer access to my datasource.
>>>>
>>>>I don't really like the idea of my controller grabbing the Datasource,
>>>>passing it off to my business layer, who in turn passes it along to my
>>>>
>>>data
>>>
>>>>layer. I guess I'm sort of a purest, but I don't think the Business
>>>>
>>>layer
>>>
>>>>should know anything about the database, and that means it shouldn't
>>>>
>>>even
>>>
>>>>have methods that take connections or datasourses as parameters.
>>>>
>>>>I think the only thing I like about the Controller passing along a
>>>>connection to my business/data layer is the fact that I can first open a
>>>>transaction before passing the connection along, and then I can commit
>>>>
>>>the
>>>
>>>>transaction when everything is done. Thus my transactions are at the
>>>>controller level, and can be managed there.
>>>>
>>>>Back in my old VB/COM days, we had a sort of DB Utilities class which
>>>>
>>>could
>>>
>>>>be accessed from the datalayer. You would ask it to give you a
>>>>
>>>connection,
>>>
>>>>and it would get it for you. Should I make my own class for datasource
>>>>access which is intitalized upon application start with the Datasource
>>>>object found by struts? Then the rest of my datalayer can simply use
>>>>
>>>it?
>>>
>>>Three basic options exist:
>>>
>>>* Hand a DataSource (I normally prefer to send a Connection instead, but
>>> either works) to your business logic method as a parameter to each call
>>> that needs it. Advantage: no binding to anything. Disadvantage: can
>>> be a pain to hand it around.
>>>
>>>* Static methods ... Most DB connection pool implementations offer a way
>>> to retrieve a DataSource or Connection via a static method. Advantage:
>>> no handing around extra method parameters. Disadvantage: ties you to
>>> that connection pool's APIs.
>>>
>>>* JNDI resources -- All J2EE app servers (and some servlet containers like
>>> Tomcat 4) offer support for JNDI resources that are accessible to your
>>> business logic directly like this:
>>>
>>> import javax.naming.Context;
>>> import javax.naming.InitialContext;
>>>
>>> InitialContext ic = new InitialContext();
>>> Context ctx = (Context) ic.lookup("java:comp/env");
>>> DataSource ds = (DataSource) ctx.lookup("jdbc/EmployeeDb");
>>>
>>> where "jdbc/EmployeeDb" is a resource reference you have declared in
>>> your web.xml file. Advantage: No parameter passing, no connection
>>> pool API lock-in. Advantage: configuration of the data source is
>>> external to your webapp (it's done with the server configuration
>>> capabilities). Disadvantage: container must support this.
>>>
>>>For info on how to use the third option in Tomcat, see:
>>>
>>>
>>>http://jakarata.apache.org/tomcat/tomcat-4.1-doc/jndi-resources-howto.html
>>>
>>>(NOTE -- if you're going to use Tomcat, definitely go for 4.1; 4.0's
>>>support has problems for many users).
>>>
>>>
>>>>Thanks,
>>>>
>>>>Craig.
>>>>
>>>>Craig W. Tataryn
>>>>Programmer/Analyst
>>>>Compuware
>>>>
>>>Craig
>>>
>>>
>>>--
>>>To unsubscribe, e-mail:
>>><mailto:[EMAIL PROTECTED]>
>>>For additional commands, e-mail:
>>><mailto:[EMAIL PROTECTED]>
>>>
>>
>>Craig W. Tataryn
>>Programmer/Analyst
>>Compuware
>>
>>_________________________________________________________________
>>Send and receive Hotmail on your mobile device: http://mobile.msn.com
>>
>>
>>--
>>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]>
>
>
--
Ted Husted, Husted dot Com, Fairport NY US
co-author, Java Web Development with Struts
Order it today:
<http://husted.com/struts/book.html>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
