Page History

...

• Easy installation, meaning:
  • Ask users to provide minimum information to get Roller up and running
  • Create and upgrade tables automatically for user
• Additionally:
  • It must be possible to disable automatic upgrade
  • It must be possible to specify DB and mail via properties or JNDI names

Issues: four options

and I'd like to fix that. I've been thinking about the problem for a couple of weeks now and I've talked to folks in Sun, at ApacheCon and JavaOne about the problem. I looked at configuration features After investigating configuration options in Tomcat and Glassfish . I also looked and looking at installation instructions procedures for popular Java webapps Confluence, JIRA, Liferay Portal and Blojsom. So far, Iweb applications, we've identified four these options:types of install.

Option 1) Property file based configuration

In this case, a user configures the webapp by editing a simple configuration file that specifies the DB connection and mail server configuration; effectively by-passing all application server configuration files. When the webapp loads, it creates and upgrades database tables as needed.

If we take this approach, we should also support JNDI – some folks won't want to by-pass app server resources. We can do this by first checking for DB and mail properties and if they are not found, we fall back to JNDI resources.

Summary

• User puts JDBC and mail-session connection parameters in roller-custom.properties
• If no DB and mail properties found, Roller falls back to JNDI names
• Roller can create/upgrade tables as needed
• Pros:
  • Easy, just one properties file for all Roller configuration
• Cons:
  • To use JNDI, user still needs to configure resources

Option 2) Separate installer for each Servlet container / app server

In this scenario, we provide an installation program for each application server we wish to support. The installer prompts the user for DB and mail parameters, sets up the server resources and/or creates the Roller property override file and deploys Roller.

This can work in combination with option #1.

• Installer prompts user for configuration parameters
• Installer sets properties or sets up JNDI resources
• Installer does all setup and deploys Roller
• Roller can create/upgrade tables as needed
• Pros:
  • Easy UI driven installation
  • Can support properties or JNDI resources
  • Complements option #1
• Cons:
  • Need to develop separate installer for each Servlet container / app server

Option 3) Standalone bundle with Roller, Servlet container / app server and database

In this case, we provide a complete bundle with everything the user needs to run Roller, all pre-configured and ready to run. We could provide such a bundle with Tomcat, Derby and Roller. Obviously, this is only going to satisfy a portion of our users; i.e. those who are OK with Tomcat and Derby.

• User downloads, unpacks, runs startup script... done!
• Pros:
  • Amazingly easy for user
  • We can steal creation script from Blogapps project for Roller, Derby, Tomcat bundle
    Cons:
  • We'll need a separate bundle for each server
  • Not a complete solution if user wants database other than one we bundle

Option 4) Roller completely handles it's own installation

In this scenario, the Roller WAR does it all. You just drop it in, browse to the main page, enter database connection parameters and Roller automatically creates all server resources, creates/upgrades tables and restarts itself if necessary.

• Roller prompts user for configuration parameters, does all setup
  • Creating JNDI data-source and mail-session if needed
  • Or creating property file for non-JNDI based installation
• Roller can create/upgrade tables as needed
• Pros:
  • Easy UI driven installation
  • Does everything!
• Cons:
  • Need to develop separate logic for each Servlet container / app server
  • May be difficult or impossible for some servers
  • May require application server jars in Roller's WEB-INF/lib directory

Consensus on the Roller dev list is that option #1 is a must have, #2 and #3 are nice to have and #4 is too complex. Note that the options are not mutually exclusive. Once #1 is in place, #2 is easier to implement because all of the options can take advantage of property-based configuration and automatic database creation and update.

So, this This proposal covers option #1 and those only. Those who wish to development develop #2, #3 and #4 installers can propose those separately.

...