avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Royal <pro...@apache.org>
Subject Re: New DefaultKernel parameter
Date Sat, 03 Aug 2002 13:05:01 GMT
On Saturday 03 August 2002 03:29 am, Peter Donald wrote:
> On Sat, 3 Aug 2002 01:20, Peter Royal wrote:
> > I added a (awkwardly named) new parameter to the DefaultKernel,
> > add-invalid-applications
> >
> > Giving this element a value of true will cause applications that fail to
> > start() to still be added to phoenix. Why is this useful? Say you have a
> > SAR with incomplete config info (and you know this because you validated
> > it against your schemas), the app can be installed into phoenix but not
> > started and you can they use Phyre to fix the config (and save the
> > missing bits on disk with the
> > FileSystemPersistentConfigurationRepository) and then start the app back
> > up :)
>
> It may be better to do it slightly differently.
> 1. Deploy/install app
> 2. Configure app if necessary
> 3. Manually Start App
>
> The difference being that you wont try to start an application and fail. I
> am nervous about that as some blocks may have unintended sideeffects even
> when they fail.

Valid concern :) I just did what was easiest to do in 30m :)

> However for backwards compatability we include a flag "quickdeploy" (or
> something) that will automatically start an app when it is deployed
> (effectively skippin [2]).
>
> Thoughts?

I like the "start phoenix and start all apps behavior". I only need what you 
describe above for the very first installation of our application. Subsequent 
installations (upgrades) should just run the app if possible. (So when our 
users inevitable restart their win32 servers, when the phoenix service starts 
back up it will restart the app w/o manual intervention).

My sole motivation for the switch was to allow for the modification of 
configuration information on the initial installation (so we could ship the 
app w/o a jdbc dburl configured plus a few other options that we can't really 
default).

The ideal solution (in my eyes) would be to gather/validate all the 
configuration information for an application before starting any blocks. That 
way any errors could be detected before the app is started. Unfortunately 
this does not mesh will with how Phoenix loads an app currently, as it only 
attempt to retrieve configuration information if a block implements 
Configurable. Perhaps we could augment the .xinfo document to include whether 
or not a block has config? 

Just more thoughts... I'm out and about this weekend so may be slow replying.
-pete

-- 
peter royal -> proyal@apache.org

--
To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>


Mime
View raw message