On Fri, 16 Aug 2002, Robert Taylor wrote:
> Date: Fri, 16 Aug 2002 12:27:10 -0400
> From: Robert Taylor <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: RE: Connection pool question
>
> 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.
>
That mechanism is provided by your container. It's nothing that an
application (or an application framework) needs to worry about.
Craig
> 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]>
