geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "n. alex rupp" <rupp0...@umn.edu>
Subject Re: [Deployment] IM #2 Summary for Directory Issue
Date Fri, 03 Oct 2003 23:23:00 GMT
I wish Richard and David B. would chime in on this subject.  The stuff below
makes sense to me, and I'm sure Jeremy has very good reasons for wanting to
keep the JSR 88 stuff separate (maybe he wrote them already and I missed
that post?)  Any details would be well appreciated (but I have faith, as
well--do as thou wilt)

Richard and some others spoke earlier about keeping the application archives
100% non-proprietary and having geronimo-specific information in its own
deployment descriptor outside of the archives, which can be easily adjusted
through the management console.  I like the simplicity of that approach from
the perspective of the user, so I'd like to press strongly for that.  If we
bog down the archives with geronimo specific deployment descriptors it won't
be the end of the world, but we won't exactly be putting the mints on the
pillows, either.

Night,
--
N. Alex Rupp (n_alex_rupp@users.sf.net)

----- Original Message ----- 
From: "Aaron Mulder" <ammulder@alumni.princeton.edu>
To: <geronimo-dev@incubator.apache.org>
Sent: Friday, October 03, 2003 5:38 PM
Subject: [Deployment] IM #2 Summary for Directory Issue


> Okay, had another IM conversation with Jeremy, and some new things
> came to light, and I'll present this as an alternative to the previous
> option.  As before, please feel free to chime in with feedback.
>
> 1) There will be some way of saving the current MBean state of the server
> and reloading it later.  That way when you start the server, instead of
> reprocessing all the config files, it will just "deserialize" the MBeans
> into their previous state.  Then the deployment scanner will update that
> state according to the current deploy directory (redeploying a service if
> the config file changed, for example).  (Apparently this saving and
> loading is a work in progress at the moment.)
>
> 2) There will be a "service controller" that manages the JSR-77 state of
> various objects in the server.  I need to get more information about this
> from Dain.  But the relevant part is that based on the above, all the
> applications that were previously deployed have MBeans, and those MBeans
> would brought back in the "stopped" state when the server is started.
> Then with the service controller in place, the service controller can go
> try to start the ones that were formerly running.  Thus it is the service
> controller (or if not, then the MBeans), not the individual app DDs, which
> remember what state the different components are in.
>
> 2a) A possible corollary of "2" is that if the service controller knows
> what should be running or not at any given time, that solves the problem
> of what to do when something in the "deploy" directory is stopped.  The
> service controller knows it was stopped, so we won't try to redeploy it
> immediately.
>
> 3) Jeremy feels strongly that if you deploy an app via JSR-88, we should
> just save it in a "working" directory and unpack it there, and not mix and
> match JSR-88 deployment actions with "deploy directory" deployment
> actions.  On the whole, I think we should focus on the larger differences
> between this proposal and the last, and we can figure out whether to save
> downloads to the "working" directory or the "deploy" directory later.
>
> Aaron
>
>



Mime
View raw message