Thanks for help, it's little bit more clear than mud now. I'll search the archives.
Jf Robert Taylor wrote: > Hmmm...let me clarify. > > First JDNI is supposed to be JNDI (dyslexia sets in). > > Second, when I said Struts does not (yet?) support JNDI lookups, I meant > that the Struts framework does not bind the datasources that can be defined > in struts-config.xml to the InitialContext. Within Struts, you can use JNDI > to look up data sources, but you have to have some mechanism that binds the > data sources to the InitialContext. > > As mentioned earlier, Craig has stated some "best practices" for accessing > data sources in a web application. > I don't know the thread off hand, but you should be able to find it in the > archives. > > robert > > >>-----Original Message----- >>From: Robert Taylor [mailto:[EMAIL PROTECTED]] >>Sent: Friday, August 16, 2002 12:12 PM >>To: Struts Users Mailing List >>Subject: RE: Connection pool question >> >> >>Jan, >> >>Struts, itself, does not (yet?) support JDNI lookups, although the >>Servlet2.3 spec mandates that container must. So you must define your >>datasources to your servlet container. The manner in which this is >>implemented is not standardized, so it depends on your >>application server / >>servlet container. >> >>I use ServletExec >>(http://www.newatlanta.com/products/servletexec/) and the >>admin ui allows me to define data sources so when my web app >>boots up, they >>are available via a JNDI lookup (see example in this thread). >> >>I'm not sure how this is done in Tomcat, although I'm very sure >>many others >>on this list know, or it is probably well documented in Tomcat. >> >>HTH, >> >>robert >> >> >>>-----Original Message----- >>>From: Jan Fetyko [mailto:[EMAIL PROTECTED]] >>>Sent: Friday, August 16, 2002 9:32 AM >>>To: Struts Users Mailing List >>>Subject: Re: Connection pool question >>> >>> >>>Robert, >>> >>>How would I define the DB connection in struts-config.xml so it's >>>accessible through the syntax you provided bellow ? I'm sorry but this >>>is very new to me, so some poor level questions might follow. >>> >>>Jf >>> >>>Robert Taylor wrote: >>> >>>>Standardization: All servlet containers that support the >>> >>Servlet2.3 spec >> >>>>must provide a way to look up data sources via JNDI. All or >>> >>>most application >>> >>>>servers support general object location via JNDI. >>>> >>>>Simplicity: To look up a data source, all you have is the >>> >>>following code. >>> >>>>Context ctx = new InitialContext(); >>>>DataSource ds = (DataSource)ctx.lookup( "jdbc/<data source name>" ); >>>> >>>>Flexibility: You can define your datasources in some file >>> >>>external to your >>> >>>>code, such as a properties or xml file. This allows you to >>> >>make changes >> >>>>without affecting your code. >>>> >>>>Decoupling: By accessing your datasources via JNDI lookup, >>> >>your business >> >>>>objects don't depend on the web tier to provide access via the >>> >>>application, >>> >>>>session, or request scope. This makes them reusable in other >>> >>>applications. >>> >>>>Those are four reasons I can think of. There are probably more. >>> >>>Craig, has >>> >>>>discussed the "best practices way" of using data sources in >>> >>>Struts. You may >>> >>>>want to browser the archives. >>>> >>>>HTH, >>>> >>>>robert >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Howard Miller [mailto:[EMAIL PROTECTED]] >>>>>Sent: Thursday, August 15, 2002 7:33 AM >>>>>To: 'Struts Users Mailing List' >>>>>Subject: RE: Connection pool question >>>>> >>>>> >>>>>Thanks, >>>>> >>>>>I don't know much about JNDI (apart from in general terms what >>>> >>>it is); why >>> >>>>>would doing it this way be a good thing? >>>>> >>>>>Howard >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: Robert Taylor [mailto:[EMAIL PROTECTED]] >>>>>>Sent: 15 August 2002 12:10 >>>>>>To: Struts Users Mailing List >>>>>>Subject: RE: Connection pool question >>>>>> >>>>>>One solution might be to define several datasources in your >>>>>>application/servlet container where each datasource >>>>> >>corresponds to its >> >>>>>>respective database. >>>>>>Then use JNDI to access the datasources from your application. >>>>>> >>>>>>robert >>>>>> >>>>>> -----Original Message----- >>>>>> From: Howard Miller [mailto:[EMAIL PROTECTED]] >>>>>> Sent: Thursday, August 15, 2002 6:47 AM >>>>>> To: '[EMAIL PROTECTED]' >>>>>> Subject: Connection pool question >>>>>> >>>>>> Hi, >>>>>> >>>>>> Newbie, JDBC connection pool question: >>>>>> >>>>>> My application uses a central control database. This is ok, and I >>>>>>can see how to use a connection pool for my application to >>>>> >>access this. >> >>>>>> BUT... The application allows a user to recover data from a range of >>>>>>additional databases. That is the central database verified >>>>> >>>>>logins etc and >>>>> >>>>> >>>>>>then lists a number of databases for the user to connect to. >>>>>> >>>>>> I am very unsure how to handle this "sub -connection". I have a >>>>>>number of thoughts... all bad: >>>>>> 1. Set up connection pools to ALL possible databases (there are less >>>>>>than 10), at the start in the application scope. >>>>>> 2. Set up a dedicated connection in the session scope. >>>>>> 3. Set up a dedicated connection in the request scope (cgi style). >>>>>> >>>>>> I don't like any of these answers. Anybody have experience of this >>>>>>sort of "dynamic database connection" or have any thoughts. >>>>>> >>>>>> Regards, << File: ATT00047.txt >> << File: ATT203342.txt >> >>>>> >>>>>-- >>>>>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]> >> >> >>-- >>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]>
