Bill de hOra wrote: > Hi Steve,
Hi, happy new year etc. > > Tbh, the more I think about it*, outside the WAR/exploded and add that > to the classpath, but to start with into the exploded (WEB-INF/classes) > would do; I can worry about how to deal with lost updates (when the WAR > is redeployed) later. hmm. The way I like to do these configurations is start up the app server with the specific properties I choose; you deploy the WAR file as is, but set up tomcat or JBoss with the properties for the jdbc binding and such like. You set those properties up from SmartFrog or Ant, and all is well -provided that is how you start the application. I've played in the past with machines picking up machine-specific property files based on their hostname, letting us have one WAR for different clusters. This worked until operations decided to give the staging machines the same hostname as production. > >> 2. what kind of CMDB are you thinking of? > > A custom webapp built on top of a vcs (eg subversion/mercurial); CMDBs > I've looked at seem to do everything except configuration management. If it supports GET, you can get the properties file somehow. > Either way I'd like to split publishing of these files from their > management. So in theory I can start with just some files in a folder > and push those. > > cheers > Bill > > * Since writing the first post, I'm starting to conclude that war/ear > model is just busted. But I figure the Java world must have solved this > problem at some point. It is broken. The whole vision of 'assemblers' building WAR/EAR files from reusable EJB beans bought off the shelf turned out to be wrong. And while they had all these various roles for people 'developer', 'assembler', 'administrator' they left out tester and 'operations team'. What you can't really pull off is a WAR file that targets >1 installation, yet contains all the configuration information. Not in the web.xml file, log4j.properties, etc. The whole idea of a self contained WAR/EAR file fails when you -want to work with multiple installations -need to add a JDBC driver to the app server itself. This is why in Ant in Action I defined a EAR file to be 'an installation specific bundling of an application'. Once you accept that, you can have a build that creates custom EAR files for different machines. The alternative is to have a single WAR/EAR file and do the configuration *outside* the war, through -JVM properties -LDAP configuration -name-value pairs in the database (with some way of getting to the database preconfigured) -hostnames (e.g edit DNS or /etc/hosts with the specific addresses of 'database' and 'filestore'); your code assumes they are set up right somehow -- ----------------------- Hewlett-Packard Limited Registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Smartfrog-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/smartfrog-users
