Hehehe...Jason...messing with you is like going to Disneyland...all fun ;-)
Dude...you rock :-) Keep up the awesome work! Jefff Jason Dillon wrote: > 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 >>>>>>>>>> >>>>>>>>>>
