In my test I also restarted geoserver to be able to use the new /etc/hosts, Mark says a restart is probably necessary using JNDI too.
If restarting is a given, a script may be inserted in the container initialization to alter the datastore xml to lookup the correct database and point it to the correct one. The container inicialization is made at some file like /etc/init.d/tomcat8 or /etc/systemd/system/xxxxxxxx.service in case your container is initialized using systemd. I do not like the idea of restarting geoserver frequently. In my case it has taken up to 7 minutes. I can think of the following approaches: 1. Do the lookup only in the web application and the Ruby backend. Publish everything in geoserver in different workspaces (workspaceA and workspaceB, for example) and let the applications decide (by querying the database, an environment variable, etc.) from which workspace they will pull the data. That way you do not have to reconfigure or restart geoserver and I can envision near to zero downtime when transitioning. The disavantage is that you have to mirror configuration changes in two workspaces at the same time. 2. Have a job running as a daemon to watch this "variable" (database, environment, config file, etc.) and automate the geoserver switch. That can be done by stopping the service and directly editing the datastore xml configuration or by using the more civilized REST interface. I have not tested if changing a datasource database address using REST has immediate effects, but I assume it does. This approach should also have negligible downtime if REST behaves as assumed, with the disadvantage that you have to develop, test and maintain that daemon. 3. Change the datasource database manually every time you change databases using the geoserver web interface. Best regards, --Daniel Em 19/08/2016 12:42, Mark Prins escreveu: > On 19-08-16 16:25, David Haynes II wrote: >> Thanks Daniel, that's not exactly what I am looking for does this clear >> it up? >> >> We have an instance of GeoServer that serves up layers through a >> particular database. That database is also used, primarily, by another >> application (this other application might be thought of as the 'owner' >> of the database). This other application employs an A/B set of >> databases. That is, we build database A, and point our application and >> GeoServer at this database. In the mean time, we are working on data >> updates, meta data changes and the like in our B database. When we are >> comfortable with where B is at, we point our application and GeoServer >> at the B database. >> >> Is there a way to dynamically have GeoServer "lookup" it's connection >> information? We're looking to have GeoServer automatically pickup that >> the application is now using "B" and appropriately switch over itself to >> using "B" > JNDI comes to mind, but I think geoserver initializes the connections > during startup so a geoserver restart would probably be necessary, while > pointing your application to another database seems manual you could > probably switch over the connection behind the JNDI lookup as well; it > depends on your servlet container how dynamic ths actually is; it may > need to be restarted as well. > > >> On Fri, Aug 19, 2016 at 8:13 AM, Daniel Araujo Miranda >> <miranda....@dpf.gov.br <mailto:miranda....@dpf.gov.br>> wrote: >> >> Hi David, >> I am not sure I quite understood your use case, but here's an idea: >> >> You may point you datasources to a local host address defined in >> /etc/hosts (for example: "geoserverdatabase"), preferably one that >> is not resolvable by your internal dns. >> To change between demo/staging/live db servers, you just have to >> change the address that your "geoserverdatabase" server points to in >> /etc/hosts, without changes to your application code or geoserver >> configuration. >> I have just tested this here and it works. >> >> Best, >> Daniel >> >> Em 18/08/2016 18:37, David Haynes II escreveu: >> >> Hello Everyone, >> >> This isn't necessarily a Geoserver question, but I am hoping to >> get some advice from this group on what tools and tips will make >> this work. I have a web application that consumes wms produced >> by Geoserver. Currently we have a large number of layers and >> view that connect directly to the PostGIS database. Generally >> speaking our applications using Ruby on Rails for connecting to >> the database. >> >> As the database changes the applications reflect these changes. >> We have three ruby environments (demo, staging, live) each with >> multiple database, which may or may not be serving the active >> application. I want to abstract out the connection logic when >> defining a layers/view so that and when they are when created >> they look to the environment not the actual database. Is anyone >> doing something like this and can offer some ideas. >> >> >> -- >> David Haynes, Ph.D. >> Research Associate Terra Populus >> Minnesota Population Center >> 612-626-3933 <tel:612-626-3933> >> www.terrapop.org <http://www.terrapop.org> <http://www.terrapop.org> >> >> >> >> ------------------------------------------------------------------------------ >> >> >> _______________________________________________ >> Geoserver-users mailing list >> Geoserver-users@lists.sourceforge.net >> <mailto:Geoserver-users@lists.sourceforge.net> >> https://lists.sourceforge.net/lists/listinfo/geoserver-users >> <https://lists.sourceforge.net/lists/listinfo/geoserver-users> >> >> >> >> >> >> -- >> David Haynes, Ph.D. >> Research Associate Terra Populus >> Minnesota Population Center >> 612-626-3933 >> www.terrapop.org <http://www.terrapop.org> >> >> >> ------------------------------------------------------------------------------ >> >> >> >> _______________________________________________ >> Geoserver-users mailing list >> Geoserver-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geoserver-users >> > > ------------------------------------------------------------------------------ > _______________________________________________ > Geoserver-users mailing list > Geoserver-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-users > ------------------------------------------------------------------------------ _______________________________________________ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
