Denis Balazuc wrote:
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.
That is effectively what I am doing. There is a struts2 module for the
install actions and it's only ever used when the BootstrapFilter
recognizes that the install type is 'auto' and the that the application
hasn't been bootstrapped yet.
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.
I am not sure what you mean when you say "mixing this". What I layed
out below is effectively just proper application lifecycle management.
We are better defining the various states of the application and
providing code to better analyze what happens in each state and make
sure that the state transitions happen appropriately.
In the past the app did nothing to try and detect that the db connection
was available and working properly before trying to bootstrap, which
makes no sense because why startup Hibernate or JPA when you can't even
connect to the db? i.e. calling RollerFactory.getRoller() has no value
when the Roller instance hasn't been properly bootstrapped, so we should
handle that better, and that's basically what we are working on.
The actual auto-install feature is just a small slice of the overall
work that we are doing here. It represents only a single possible path
in the app startup sequence and it won't intrude on the code in any way.
-- Allen
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
