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