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 >>>> >>>>
