I meant stop waiting for _more_ feedback :-P
So far its all been good, but its a bigish change so I wanted to wait
for a bit before I did it.
I've also been sexying up gshell... :-P
--jason
On Sep 10, 2007, at 5:54 PM, Jeff Genender wrote:
Jason Dillon wrote:
Aighty... I'm gonna stop waiting for feedback and implement this
stuff
for all assemblies.
Ummmm...what am I...chopped liver? ;-)
--jason
On Sep 9, 2007, at 6:41 AM, Jeff Genender wrote:
No...no reasons...move forward ;-)
Jeff
Jason Dillon wrote:
Hey, have you played with the rc.d bits in the
assemblies/geronimo-jetty6-javaee5-gshell enough to know if what I
whipped up will work for you?
Any more comments or suggestions on how that stuff should work?
I think this is done, quite powerful and flexible... though to
really
know for sure we'd need to have a few plugins actually using it to
augment the Server's bootstrap configuration a?
So... are there any reasons (significant or not) for not moving
forward
with this?
--jason
On Jul 16, 2007, at 6:09 AM, Jeff Genender wrote:
Jason Dillon wrote:
I still think that G could do with a tiny bootstrap JVM to handle
all of
the required flags and properties that are needed now for the
server to
opperate properly (and in a platform neutral manner). This
could also
be used to spawn clones or cluster nodes. As well as handling
remote
restarts and recovery from JVM crashes.
Ok...cool...wanna help? ;-)
If we can have a GShell, etc set an env property like
JAVA_OPTS, please
how an example and I am all game ;-)
Jeff
IMO this is critical for uber massive enterprise deployments as
well as
smaller scale cluster management.
I also think that GShell would be ideal for the base platform for
such a
bootstrap JVM.
I think it should be realativly easy to setup a POC if folks are
interested.
--jason
P.S. Typed on my iPhone. Still not quite as fast as my
blackberry...
But I dropped in beer at the Giants/Doggers game. Ooops ;-)
On Jul 14, 2007, at 6:41 AM, Jeff Genender <[EMAIL PROTECTED]>
wrote:
Donald Woods wrote:
Is this a scenario that would be better handled by the gshell
code in
sandbox or some daemon code that also handles the multiple
server
instance support?
Thought here, would be gshell could read a standard Java
properties
file
for JVM args and then launch the server with them.....
As long as one JVM launches, the other (ie. gshell or groovy can
start
another instance of a JVM) then this is doable. Otherwise, this
won't
work...with my Terracotta example being a reason.
In my eyes, scripts are a no-go, unless you can make them
platform
neutral and not require users to install a third-party
solution like
Perl (on Windows) to make it work.
We already ship sh and bat code...why would this be a no-go? If
this is
the case, then we shouldn't be shipping startup scripts in
bat and sh
format.
-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
