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