Maybe a few more thoughts on this...
What I am thinking of is a relatively small JVM which is a process
controller. With some basic administration muck built into it to
start, stop, kill, list, fork, spawn, clone, blah, blah... server
processes... or if needed any support processes. IMO that is a bit
more than what the commons-launcher bits do, though probably whatever
the start bits do will most certainly end up re-using the ant-
launcher bits, as that code is already really solid for starting up
new JVM instances.
The controller process can also serve as a watchdog to make sure
processes are responsive and restart them if/when they barf, and if
supported periodically tickle them for basic health information etc.
This is kinda what I had always envisioned for the g-twiddle stuff
way, way, back. Gshell gets us much closer to making that actually
happen, though its still a work in progress, but I think that its put
together enough to try to implement an example so others might have a
better idea for the general vision.
Perhaps use of commons-launcher could do as a much shorter-term
implementation, though I would rather spend my time working on a few
GShell commands and massage the assembly to make it work, then work
on trimming down the GShell size, which is already kinda small, but
could be smaller if I tried. GShell already has the basic
underpinnings to handle most of what I'm thinking of, though the
telnet/ssh stuff is being a PITA right now. I may drop that for now
and just implement my own tiny shell client over ssl as a work around
until I can finally get the ssh support sorted.
--jason
On Jul 19, 2007, at 7:28 AM, Jeff Genender wrote:
Lets let Jason chime in here as I think he volunteered to stitch a lot
of this together.
Jeff
Donald Woods wrote:
Could we use Jakarta commons-launcher, which uses a subset of ANT?
We'd probably have to make a few changes, so it would use the
existing
manifest settings in the server/client.jar and to handle our multiple
server instance directory structure.....
-Donald
Jeff Genender wrote:
Hi,
As we move forward and we integrate with more and more 3rd party
products, we will need the ability to be able to change an
environment
variable through a plugin, or add a commandline JAVA_OPTS, etc.
Currently our startup scripts call the setjavaenv.sh to set
environment
properties. It would really be nice to have the ability to have a
"scripts" directory, where all of the scripts get executed before
Geronimo is launched. Why do we want this?
As we grow in our plugins, they will need to set environment or java
options set before running G. They may also have a need to start
or run
other outside processes that are not a part of G.
It would be great to allow plugins to install an rc script that gets
executed to do activities before and perhaps after G is run?
I would propose we create a scripts directory under bin or under var
that could be similar to init.d, and have it called with start/stop,
etc. This way plugins can install specific scripts in these
directories
for execution.
Thoughts?
Jeff
