I've used BladeLogic previously for this exact same purpose and it worked really well.
I didn't use an NSH script, I used a BLPackage with a payload, some external commands and some configuration from a component template.
You've probably got two types of files you need to configure if you're dealing with tomcat webapps. XML files and name = value properties files. BladeLogic has built in grammars for both of these so you don't need to write any sed statements and the substitution works every time.
First thing you'll want to do is create a copy of the config file and put it somewhere static. I call this the mapping file as this will be where we put all the placeholders that map to properties. I usually place it under some sort of config directory on my appserver or the filestore.
Now we create a Component Template:
- Right click on the component template folder -> new -> Component Template.
- Give it a name and check the browse and deploy boxes.
- Press Finish.
- Now open up the newly created component template (double click on it) and go to the local properties panel.
- Press the green + button and add a new property. Call it something like "MY_CONFIG_FILE", it's a string type and give it a default value of the full path and filename of your mapping file.
- Press OK and then go to the local configuration objects panel.
- Press the green + symbol to add and then select "Configuration File" in the wizard. Press next.
- Select the correct O/S type, and put in the property ??MY_CONFIG_FILE?? as the file path.
- Select the name = value grammar (nsvp.gm), the XML grammar or other as appropriate for the type of file.
- Press OK.
- Now over to the Parts panel, press the green + to add, expand Local Config Files and select your ??MY_CONFIG_FILE?? property. Move it to the right and then press OK.
- Save and close the component template.
So that's the template done, now we need to pick up the values from our mapping file. We do this by creating a Component which is essentially instantiating the Template.
- Right click on the Template and select New -> Component.
- Rename if you feel the need and then give it a server by selecting the [...] button and browsing to the host where you put the mapping file.
- Press OK, then Finish.
- To test it out right-click on the component and select Browse. If all the paths are okay, the grammar works and you added it as a part, you'll see your file under Live and when you click on it, you’ll see your parsed config file.
Now you need to think about how you are going to associate your properties with your package. Are they server properties? Or did you want to have a package reference a custom class or were you planning on using local properties? In any of these cases you need to make sure your property can be resolved from a package. Using server properties is probably the easiest for this example as TARGET is automatically created in the BLPackage so will always be resolvable to the SERVER class.
Keeping the above in mind, you can now edit your mapping file and replace any actual values with property placeholders. For example if you had a static value of a hostname and you wanted this to be your targets hostname you could use ??TARGET.HOST??.
Once you’ve put all your property placeholders in your mapping file you can add this Component to a BLPackage by right clicking on it, Add to Depot As -> BLPackage.
Once you’ve added it to your package, you’ll notice your local variable MY_CONFIG_FILE has been inherited and you can change this to the exact destination of the config file.
Add your WAR file and any commands to this BLPackage and you’ll have a portable and re-usable application package.
This may seem like a lot of work but it’s really not that bad and when you consider that I was using this method to set over 10,000 property values in 40 custom web applications across dev, test, preprod and prod. Once the component template and mapping files are created the rest is easily scriptable in blcli and your error rate will drop to almost zero.
thanks so much for the effort you have put in here. It's exactly the sort of thing I was after.
Although the NSH script approach works, this looks to be a better approach.
As soon as I get a bit of time I will do some testing around this and let you know how I get on.