>-----Original Message----- >From: André Warnier [mailto:a...@ice-sa.com] >Sent: Friday, November 30, 2012 4:45 PM >To: Tomcat Users List >Subject: Re: Context Path for a subdirectory > >Maybe a bit of lateral thinking here. >What does the admin webapp really do ? For what it is doing, does it need to >even "live" >in the same website/host as the main application ? >If it's actions are confined to managing some files on disk, or some data in a >back-end database, maybe it can do that without being really integrated into >your main application ? >You could then set up a separate Host, running under SSL or whatever, to run >this admin part. It's URL would never be visible under your main site. And >you'd have all the flexibility to set up any security constraints you want, >without interfering with the main user site. >
Fair question. The "rest" web app was configured using a product called ArcGIS Server. There are at least 4 servers involved in the end product you see. Server 1 - The ArcGIS Server - This is where you publish map documents as web services, and where you can export the "web services handler" (rest.war) to a production web server. Which I've done. Server 2 - The ArcSDE Server - This is where the GIS data physically resides in a SQL Server. Server 3 - The GIS Storage server - This is where Server 1 writes out the map images you see. I have a context on Server 4 that maps to a share on Server 3 as a virtual output directory. Server 4 - The production Tomcat server - This is where I deploy the rest web app that is created from Server 1 Any changes that I make to the rest web app are done on Server 1, in which I then need to generate a new rest.war file to be deployed on Server 4. Anything custom that I configure for the rest webapp, like the filter in web.xml, I have to remember to unpack the war file, make edits and re-pack it, or leave it exploded. Changes can be things like adding new output directories, map cache directories, adding features like the ability to generate KMZ files for Google Earth, and there is even an option to configure deploying the rest.war file with a security store. The rest/admin web app has one thing that I need, which is a clear cache feature. Any new web services that you deploy, or changes you make to existing services such as changing the color of a feature or what not, have to have the cache cleared. The way the Server 1 is configured, there are accounts that the rest/admin web app will take which let you do things like shutdown the services and other stuff, if you were able to brute force the rest/admin username/password. Leo --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
