Re: Fixing the Roller installation process

[Sean Gilligan]

Hi Dave,

Lately, I've been using JNDI and Tomcat's context.xml for configuring 
webapps (in turn I use Spring to do JNDI lookups and inject config 
parameters, so components don't have dependencies on JNDI).  By doing it 
this way it is possible to produce an immutable WAR that doesn't need 
any changes for deployment.  All deployment-specific configuration 
options go in context.xml (for Tomcat)

Pros:
 1) WAR file is "immutable" artifact and compatible with all Servlet 
containers
 2) For releases where configuration options don't have mandatory 
changes you
     just deploy the new WAR with your existing configuration
 3) You use the configuration method of each app server/container to 
configure the war

Cons:
  1) Sometimes you still have to insert context.xml into the WAR (jar 
update) for deployment on Tomcat
  2) Development time/integration issues?
  3) Caveats could turn into cons

Caveats:
  1) I've only actually used this with Tomcat
  2) I haven't done this (in a clean way) for a legacy properties 
file/object or a large number of config parameters (Is there a way of 
pushing a properties file/object through JNDI? - Perhaps pulling a 
properties file from a configured location - this would be helpful on 
load-balanced configurations where multiple instances are being installed)

(BTW,  I found helpful information on configuring webapps (for Tomcat) 
in the book "Tomcat 5 Unleashed" by Lajos Moczar)

I haven't looked at recent Roller releases, but I get the impression 
that making things 100% Apache license compatible has complicated 
installation.  So perhaps the WAR file version could be in the Roller 
Support Java.net project and include all the software with 
verboten-licenses.

Another thing that could be nice is to create a Xen Image (virtual 
server appliance) for the whole thing (Roller - Tomcat - Apache - Java - 
PostgreSQL).

Regards,

Sean

p.s. I wish I had time these days to be more than just a lurker.  It 
looks like you guys are continuing to do great work!


Dave wrote:
The Roller installation process is unacceptably complex 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 in Tomcat and
Glassfish. I also looked at installation instructions for popular Java
webapps Confluence, JIRA, Liferay Portal and Blojsom.

So far, I've identified four these options:


1) Property file based configuration
  - User puts JDBC and mail-session connection parameters in
roller-custom.properties
  - If no JDBC and mail-session properties are found, falls back to
JNDI resources
  - Roller creates/upgrades tables as needed (prompts user 1st and
can be disabled)
Pros:
  - Easy, just one properties file for all Roller configuration
Cons:
  - User still has to do configuration if they want to use JNDI resources


2) Separate installer for each Servlet container / app server
  - Installer prompts user for configuration parameters
  - Installer does all setup and deploys Roller
  - Roller creates/upgrades tables as needed (prompts user 1st and
can be disabled)
Pros:
  - Easy UI driven installation
  - Supports JNDI resources
Cons:
  - Need to develop separate installer for each Servlet container / 
app server


3) Standalone bundle with Roller, Servlet container / app server and 
database
  - User downloads, unpacks, runs startup script... done!
Pros:
  - Amazingly easy for user
  - We can steal creation script from Blogapps for the 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


4) Roller does completely handles it's own installation
  - 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 creates/upgrades tables as needed (prompts user 1st and
can be disabled)
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


Before I go further with my proposal, I'd like to get some feedback.
At this point, I'm learning towards doing both options #1 and #2.
Option #3 is too limiting and option #4 is just too complex.

- Dave