How about having a separate "auto-install" Struts2 module that will do
all that and adding a servlet filter as the boostrap to detect when the
auto-install module should be triggered?
You can then separate the Actions responsible for this, as well as avoid
coupling in the current business layer and the roller webapp to address
this specific feature.
The fact that it is a feature that can be enabled/disabled makes me
think that it should not be an integral part of the Roller monolith. I
am not confortable with the idea of mixing this with the rest of the
Roller business layer (adding methods to either static classes or
interfaces just because the feature requires it - it sounds wrong to me).
It would probably be good if the auto-installer had a business interface
on its own in order to decouple things a bit more, which would allow
people to implement a version of that feature, or modify its behaviour
without necessarly be tied to a webapp or the rest of the Roller code.
Also, having a business interface will help make a modular component out
of it, which you can just plug in. And you guessed it, this opens the
door to injecting various implementations.
My 2 cents..
Denis Balazuc
Dave wrote:
On 6/19/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
So, I found a couple things that weren't quite working right for me
which I plan to modify a little bit, but as I thought about this more
I'd like to suggest that we consider these 5 phases of the app lifecycle
(at least these 5 for now) ...
1. preparation - app being prepared to be bootstrapped (install/ugprade
stuff happens here)
2. bootstrap - wiring up the backend so the app can function
3. initialization - initializing services, such as starting background
tasks, etc
4. app running - pretty self explanatory
5. shutdown - again, pretty simple
Breaking that down into actual code I see things working something like
this ...
1. preparation - RollerStartup (or something) controls this phase. key
requirement is that we can't rely on the app being bootstrapped here.
most work will be just with raw sql and services outside of the
Weblogger business tier such as the database provider and config.
2. bootstrap - RollerFactory controls this phase. key requirement is
that preparation is considered to have been done already.
3. initialization - the Roller instance should control this. key
requirement is that bootstrapping has already been done.
4. app running - work is done by Roller instance. technically only
bootstrapping is required for this, not initialization.
5. shutdown - Roller instance controls this. bootstrapping has to have
happened for this to work.
So, to accomplish this I want to make a couple simple tweaks to what we
have now ...
1. create the RollerStartup class so that preparation work can be
managed there. this is the only piece we are really missing right now
and we have all of Dave's new EZ install code, it just needs to be
managed through this class.
2. tidy up RollerFactory a little bit to make bootstrapping process
simple and clear. i already have this in my workspace.
3. setup initialization process through Roller instance. this is really
just the complement to the Roller.shutdown() method, so I plan to add a
Roller.init() method and add that method to our existing manager methods
so that this happens in the most logical fashion. again, this is just a
small amount of code shuffling, not much new code.
That's pretty much it. The only other thing is some restructuring of
the RollerContext which is the normal place where we run through these
phases.
sound good?
+1 all sounds good. - Dave
