Jason Dillon wrote: > How does the script know to pick it up. Got a cli example of how the > invoke would look?
Pseudo code for geronimo.sh: scripts = read(bin/scripts); for each script in scripts do call script endfor Jeff > > --jason > > > On Jul 16, 2007, at 9:45 PM, Jeff Genender wrote: > >> Use case needed now: >> >> Terracotta is developing a plugin. It needs to pass a setting to the >> JVM (i.e. -xbootclasspath=). So when the Geronimo script is run, it >> needs to pick up this "setting" from a script that is installed by the >> plugin. The script would normally set a JAVA_OPTS and the geronimo.sh >> script would then pick this up. >> >> These scripts would be installed by plugins (or created by someone), but >> the great part is, when the plugin is uninstalled, the script goes away, >> and the options are not set. >> >> Did this make sense? >> >> Jeff >> >> >> >> Jason Dillon wrote: >>> Can you provide a wee bit detail on hat the use cases are you have in >>> mind? I'm still a bit fuzzy what you are going for. >>> >>> --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 >>>>>>>> >>>>>>>>
