I think you've identified all of the right changes to make, but I'm not
really seeing how they come together very well as implementations.
I think that for #1 we should flush out more properties than what you
listed there and try to make them as consistent as possible, for example ...
database.installation=[auto,manual]
database.connectionProvider=[built-in,jndi,custom,etc]
database.type=[mysql,oracle,etc]
database.driver=
database.url=
mail.strategy=[built-in,jndi,custom,etc]
mail.hostname=
mail.username=
mail.password=
For #2 I think we should be creating some kind of DatabaseProvider class
which knows how to look at the db config properties and provide all the
right kind of database functionality. I don't think we want to save
anything to the servlet context.
#3 sounds right, but doesn't give much details. Again, I think we want
something like a MailProvider class which wraps the functionality of
looking up the right way to get a mail session.
I think #4 is okay, but I would like to move away from using the roller
context as our initialization class. I think I had mentioned this
before, but I think what we really want is a standalone Roller
bootstrapper class which can be called from the contextInitialized()
method or other places when needed. So in the event of install/upgrade
the app can detect that there is work needed before the app should be
bootstrapped and it can do whatever install/upgrade work is needed then
do the bootstrap.
#5 sounds wacky to me. I don't really want that functionality
implemented as a filter, I think that the db upgrading should be done by
the DatabaseProvider and if we want some kind of UI for interacting with
that then we should allow for that using the bootstrapper idea. The
only thing I would potentially think a filter could be used for in this
situation is something like the InitFilter that we already have where
that filter can check some kind of flag to see if the app has been
bootstrapped yet and if not then it redirects all requests to the
install/upgrade page.
I like #6, but asking the user to restart/redeploy is no fun, so that's
where the independent bootstrapper would be useful.
And #7 is same as #6 really.
-- Allen
Dave wrote:
Based on the discussion so far, I've put together an initial proposal
for fixing the Roller installation experience. Please provide
feed-back here on the dev list.
Abstract
The Roller installation process is unacceptably complex. It's having a
negative impact on Roller adoption and distracting the Roller
community on the user mailing list. We need to make it really easy to
install Roller.
Requirements
* Easy installation, meaning:
o Ask users to provide minimum information to get Roller up
and running
o Create and upgrade tables automatically for user
* Additionally:
o It must be possible to disable automatic upgrade of database
tables
o It must be possible to specify DB and mail via properties
or JNDI names
Here's the rest:
http://cwiki.apache.org/confluence/display/ROLLER/Proposal+Easy+Install
- Dave
