Installing TOMCAT as a service pitfall

Installing TOMCAT is relatively easy - xcopy deployment BUT when you want the TOMCAT to be running as a service the most common way to do it is to run several batch files that configure the service and add it. Before you jump i am not using the OOTB Installer provided because i want to do custom closure

While this is relatively "simple", its bad practice to use such custom actions (require handling of rollback and uninstall, batch problems).

I am going to do something that i dont really like, i am going to suggest a solution while implementing it later this month

1. Install the service using the batch files using all your required options
2. Goto the relevant registry key (apparently the entire configuration is saved in registry - lame as i would expect this to be file based configuration) and Export it to Reg file (static i know)
3. Create a WiX fragment using that registry and update all static parts to be dynamic based on properties or other cool features (e.g. Location of JRE, Memory limit, etc)
4. In your main product WiX add that fragment and add Install Service action (native) that will add the service (Make sure to use the correct service name as used in the configuration)

The above steps are native actions that dont depend on executions which means they are almost bullet proof and support out of the box rollback + Uninstall and repair

I know this looks hard, but it should be simple. also i can make it even more advance and wrap the extraction of the registry to a task of the heat + XSLT for the dynamic part