"Using the server admin lets you take the same web application and deploy it *unmodified* in different environments where you really want to connect to different services (such as a testing server, a staging server, and a production server)."
If you make your build system smart enough, you can have it generate your context.xml file with the correct settings (Velocity comes in handy here) depending upon your targeted environment (test vs. prod). I usually do this using a build.properties file in Ant. In order to change your targeted environment, all you have to do is change the build.properties file and that's it. On 1/22/07, Craig McClanahan <[EMAIL PROTECTED]> wrote:
On 1/22/07, Garth Keesler <[EMAIL PROTECTED]> wrote: > > So, if I read you right, I need to do one or the other but not both and > either one does pretty much the same thing. It also appears that doing > it in the Admin page does it for all Axis web services, right? You are correct about "one or the other but not both." So why two approaches? * Using context.xml makes it easier to deploy a self contained webapp that configures its own resources. * Using the server admin lets you take the same web application and deploy it *unmodified* in different environments where you really want to connect to different services (such as a testing server, a staging server, and a production server). The same general principles apply to things like configuring JDBC data sources, EJBs, and pretty much anything else you can look up via JNDI. Craig
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
