I am not sure about Websphere but for our Tomcat applications we have a folder outside of the application path we use to store a properties file. In fact, we have a dbmanager application that stores just the type of information you mention. I am guessing that you can do that with just about any web application. We don't normally use the web.xml file for anything but more "static" application settings.

If there is a specific properties file for Websphere settings, I am guessing that you should be able to "protect" it from updates (I don't know, we don't use Websphere currently). If it is your own properties file, you should be able to put wherever you want and update it only when you need to.

Perhaps you could use Ant to build the war and have it exclude the file you are referring to. That would mean that you would have both a "new" war and and "update" war with the update war excluding the properties file.

Pete Helgren

Walden H. Leverich wrote:


If I understand the concept correctly, one should put their "softcoded"
things into a properties file. This could be connection strings (if
you're not using WebSphere data sources), Web Services addresses, URLs
you access that are different between test and production, etc.

Now, the properties file is "wrapped" into the WAR file that's deployed
to websphere. So, once deployed you go into the properties file and make
your changes? Am I good so far? If so, what's the process for deploying
updates? If I re-deploy the WAR file then I'll overwrite the properties
file, so I have to make my changes again?
Is there a way to exclude the properties file from the WAR and have WS
leave it on the server?


Walden H Leverich III
Tech Software
(516) 627-3800 x11
http://www.TechSoftInc.com <blocked::http://www.techsoftinc.com/>
Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.