From: "Craig R. McClanahan" <[EMAIL PROTECTED]> Sent: Tuesday, July 09, 2002 3:45 PM
> > > On Tue, 9 Jul 2002, Will Hartung wrote: > > > From: Will Hartung <[EMAIL PROTECTED]> > > > > 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. > > 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. Ah! That's great. That's precisely the type of thing they need to "write down", but that's the kind of thing that can go in the README of a WAR for particular servlet engines. I know that the They figure that all of this stuff will be done through some handy GUI util that explodes the WAR (or EAR, or whatever) for you, presents the XML files to be edited etc, and then squeezes them all back together in a nice friendly fashion. That's more relevant for EARs I suppose, but I still think a method external to the archive files is a better way to go. That way, you can potentially perform some kind of signing mechanism on the archive that doesn't get screwed up when its deployed. Anyway, thanx for the tip! Regards, Will Hartung ([EMAIL PROTECTED]) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
