On Tue, 9 Jul 2002, Will Hartung wrote:

> Date: Tue, 9 Jul 2002 14:18:12 -0700
> From: Will Hartung <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: Tomcat Users List <[EMAIL PROTECTED]>
> Subject: Re: Need Ideas... big problem! (long)
>
> The only detail with that is that the app.war is still different with each
> deployment.
>
> I always felt that there should be a bit in the Servlet (and J2EE for that
> matter) specs that has some kind of "local properties" file so deployers
> don't have to rebuild the WAR and EAR to make a configuration change. There
> are all sorts of mechanisms, they just need to write one of them down.
>
> If the app is deployed to seperate Tomcat engines, the URL could be defined
> on the command line (to steal Bobs example):
> java -Ddatasource.url=jdbc:cloudscape://localhost:1313/user/pwd.
>
> Or, as a simple JNDI like thing, simply stored in a properties file in the
> classpath.
>

It's already available, and it already is a simple JNDI thing :-).

Check out the <env-entry> element in web.xml, which lets you define
configuration parameters.  You would do something like this in web.xml:

  <env-entry>
    <env-entry-name>db.url<env-entry-name>
    <env-entry-type>java.lang.String</env-entry-type>
  </env-entry>

App servers let you customize the actual value assigned to this entry at
deployment time.  In Tomcat, you do that with an entry like this:

  <Environment name="db.url" type="java.lang.String"
     value="jdbc:cloudscape://localhost:1313/user/pwd"/>

nested inside the <Context> element for this webapp.  The net effect is
that you can install the same unmodified WAR file on different servers
(say, test and production) with connections automatically established to
different databases.

Getting the value inside your servlet is trivial:

  InitialContext context = new InitialContext();
  String dburl = (String) context.lookup("java:comp/env/db.url");

The "java:comp/env" thing is the standard place where environment entries
get put.

> Properties p = new Properties();
> p.load(ClassLoader.getSystemResourceAsStream("app.properties"));
> String jdbcInfo = p.getProperty("datasource.url");
>

This won't work if you have more than one application on the same Tomcat
instance, each trying to get it's own resources.  Nothing stops you from
implementing it yourself though.

> Mind you, this is essentially what Bobs JNDI suggestion does, but you don't
> have to actually understand anything about JNDI to use it, particularly for
> something this simple. (Though JNDI is worth looking into...)
>
> If they are all deployed in the same engine, from the same WAR, then this
> clearly will not work.
>
> If you want it to work in "any" servlet engine, then the Init Parameter in
> the WAR is the way to go.
>

The <env-entry> thing is not quite that universal, but it will work on
Tomcat and any J2EE app server -- that covers quite a bit of territory.

> It sort of depends on how your apps are deployed.
>
> Regards,
>
> Will Hartung
> ([EMAIL PROTECTED])
>

Craig


> ----- Original Message -----
> From: <[EMAIL PROTECTED]>
> To: "Tomcat Users List" <[EMAIL PROTECTED]>
> Sent: Tuesday, July 09, 2002 1:24 PM
> Subject: RE: Need Ideas... big problem! (long)
>
>
> >
> > If you don't want to go the JNDI route, you could also do something like
> set
> > init params in each application's web.xml file with the db connection info
> or
> > create a .properties file for each application and read in the db
> connection
> > info from that.
> >
> > HTH,
> > -Jeff
> >
> >
> >
> >
> >                     "Kranson, Bob"
> >                     <Bob_Kranson@comp        To:     "'Tomcat Users List'"
> <[EMAIL PROTECTED]>
> >                     uware.com>               cc:
> >                                              Subject:     RE: Need
> Ideas... big problem! (long)
> >                     07/09/02 02:41 PM
> >                     Please respond to
> >                     "Tomcat Users
> >                     List"
> >
> >
> >
> >
> >
> >
> > Why don't you store the JDBC URL in JNDI and have DAO look it up
> > dynamically....
> >
> > Bob Kranson
> > Software Technical Support Analyst
> > UNIFACE and Optimal Products Technical Support
> > U.S. Support Center 888-551-0404
> >     New Calls: [EMAIL PROTECTED]
> >     31440 Northwestern Hwy, Farmington Hills, MI 48334-2564
> >    (248)737-7300 x12702 Fax:(248)737-7574
> >
> >
> > > -----Original Message-----
> > > From: Christian J. Dechery [mailto:[EMAIL PROTECTED]]
> > > Sent: Tuesday, July 09, 2002 2:38 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Need Ideas... big problem! (long)
> > >
> > >
> > > I have a huge problem here... and I can't think of a simple
> > > solution for it, I'm hoping u guys can give some "light". :)
> > >
> > > Let me first describe the "environment" here, then the problem.
> > >
> > > We have here a webapp called FAP (c:\tomcat\fap). It is
> > > composed of: /fap/*.jsp (like a hundred of them)
> > > /fap/WEB-INF/classes/finep (this package finep has a lot of
> > > subpackages) /fap/WEB-INF/classes/finep/DAO.class <-- here
> > > the problem resides... /fab/lib/OracleDrivers.jar
> > >
> > > the class DAO provides the Connection to an Oracle database...
> > >
> > > so far, everything is fine... but here's the thing... this
> > > webapp gets replicated... the whole dir, because there are
> > > other instances of this system with small changes, and we
> > > didn't have the time to create a self-configuring app to
> > > allow that... so we copy the whole dir and make the necessary
> > > changes... BUT... the classes never change... only the
> > > JSPs... AND another thing that may change is the database
> > > (and of course DAO)... so how it is done?
> > >
> > > we have /fap with DAO.class pointing to a specific db URL
> > > and; we have (for example) /fap2 with a few JSPs changes and
> > > DAO.class pointing to another URL.
> > >
> > > this of course sux! If we wanna change the database of a
> > > specific webapp we have to re-compile DAO and place it
> > > there... and if we change a class (any class) we have to
> > > update it in ALL the contexts...
> > >
> > > What I want:
> > > I would like to place the package "finep" and the
> > > OracleDrivers in the global context
> > > (c:\tomcat\common\classes, \lib), so all would be pretty and
> > > centralized; and create something like a Connection
> > > Dispatcher (also in the global context) that would receive
> > > requests from the JSPs and provide a Connection to the
> > > specific URL based in which context that JSP was when the
> > > request was made. I don't know if that's possible... I'm just
> > > guessing... of course I want do this as painless as
> > > possible... cuz we have like 80 classes and more than 150 JSPs...
> > >
> > > to confuse??? My english also sux... sorry!
> > >
> > >
> > > .:| Christian J. Dechery
> > > .:| FINEP - Depto. de Sistemas
> > > .:| [EMAIL PROTECTED]
> > > .:| (21) 2555-0332
> > >
> > >
> >
> >
> >
> > The contents of this e-mail are intended for the named addressee only. It
> > contains information that may be confidential. Unless you are the named
> > addressee or an authorized designee, you may not copy or use it, or
> disclose
> > it to anyone else. If you received it in error please notify us
> immediately
> > and then destroy it.
> >
> >
> > --
> > 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]>

Reply via email to